교재 6장, 7장
Chap 6. AWS 서버 환경을 만들어보자 -AWS EC2
클라우드 서비스 : AWS, Azure, GCP …
- 외부에서 생성한 서비스에 접근 가능한 방법 ⇒ 24시간 작동하는 서버가 필수적
- 이때 집 PC를 24시간 내내 구동은 사실상 불가능 → 클라우드 서비스를 통해 제공
- 인터넷(클라우드)를 통해 서버, 스토리지, 데이터베이스, 네트워크, 소프트웨어, 모니터링 등 컴퓨터 서비스 제공
- 클라우드 서비스 중 하나
- 모든 AWS 서비스는 IaaS 사용
- IaaS (Infrastructure as a Service)
- 기존 물리 장비 + 미들웨어 함께 묶어둔 추상화 서비스
- 가상머신, 스토리지, 네트워크, 운영체제 등 IT 인프라 대여 서비스
- EX) AWS - EC2, S3 등 존재
- IaaS (Infrastructure as a Service)
AWS 서버 환경 만들기 - EC2 인스턴스 생성
EC2란?
AWS 제공 성능, 용량을 유동적으로 사용 가능한 서버
- S3 : 마찬가지로 서버 서비스. Simple Storage Server의 약자
- 월 750시간의 제한 있음 - 1대의 t2.micro만 사용하면 24시간 사용 가능
인스턴스
EC2 서비스에 생성된 가상머신
- 이름 및 태그 (=EC2 이름 붙이기)
- 웹 콘솔에 표기될 태그인 Name 태그 등록 → 해당 인스턴스 표현하는 이름으로 사용 가능
- 아마존 리눅스 사용하는 이유
- AWS 각종 서비스와 상성 좋음, yum 빠름 → AWS 적극 지원 OS
- 인스턴스 유형 :
t2.micro
(범용 시리즈인 t 시리즈 유형 중 하나)- 크레딧 (CPU를 사용할 수 있는 일종의 포인트) 존재
- 인스턴스 크기에 따라 정해진 비율로 CPU 크레딧 공급받아 축적하거나 사용함 → 크레딧 소진 시 더이상 EC2 사용 불가능 ⇒ 트래픽 높은 서비스들은 t 시리즈 사용 지양함
- 크레딧 (CPU를 사용할 수 있는 일종의 포인트) 존재
- 스토리지 선택
- 서버의 (디스크) 용량 : 30GB까지 프리티어로 가능 → 최대로 변경하자
- 네트워크
- SSH + 포트번호 22 ⇒ AWS 에서 EC2에 터미널로 접속하는 경우 의미
- 이때 pem키를 전체 오픈하지 않도록 주의 (추후 깃허브에 pem키 노출할 가능성 O)
- pem키 관리 + 지정된 IP에서만 ssh 접속 가능하도록 구성하기
- Source type : AnyWhere → My IP로 변경, 집 밖에서 사용할 때마다 해당 장소의 IP를 SSH 규칙에 각각 추가해줌
- 보안 그룹 규칙 추가 : 현재 프로젝트의 기본포트인 8080도 추가해줌
- 키 페어
- 인스턴스 접근하기 위해 할당 필요한 pem키(비밀 키) 선택
- 인스턴스는 지정된 pem키와 매칭되는 공개 키 소유 → 해당 pem키 외에는 접근 막기 가능
- 즉, pem키 == 일종의 마스터 키 (⇒ 유출에 각별히 주의하자.)
- 이후 EC2 서버에 접속 시 필수 파일
- 절대!!! 분실하면 안됨 ∴ 디렉토리로 저장하자
⇒ IP와 도메인 할당 완료
- 이때, 인스턴스마다 각각 다른 IP를 할당 받는다
- 같은 인스턴스를 중지하고 다시 시작할 때도 새 IP 할당됨 → 고정 IP 할당 지정 필요
- EIP 할당: 고정 IP 할당
- EIP : AWS의 고정 IP
- EIP 생성 후 EC2 주소와 연결
- 이때 탄력적 IP는 생성하고 EC2 서버에 연결하지 않으면 비용 발생함
- 생성한 탄력적 IP는 무조건 바로 EC2에 연결할 것!
- IF) 더는 사용할 인스턴스가 없다면 → 탄력적 IP는 삭제해줘야 함
EC2 서버에 접속하기 - 윈도우
윈도우의 경우 putty를 사용함 (ssh 접속용 클라이언트)
- putty 사이트 : putty.exe / puttygen.exe 다운 후 설치
- puttygen 실행
- 역할 :
pem키 → ppk파일
로 변환 해주는 클라이언트 (∵ putty는 pem키 사용 불가능)
- 역할 :
- putty 실행
- HostName : [username]@[public_Ip; 탄력적 IP주소] 등록
- 아마존 리눅스의 경우 username ⇒
ec2-user
- 아마존 리눅스의 경우 username ⇒
- Port : ssh 접속 포트 (22) 입력
- Connection type : SSH
- ppk파일 등록 : Connection > SSH > Auth >Credential
- HostName : [username]@[public_Ip; 탄력적 IP주소] 등록
아마존 리눅스 서버 생성 시 꼭 해야 할 설정
자바 기반의 웹 애플리케이션(=톰캣, 스프링 부트)가 작동해야 하는 서버들에겐 필수
Java 설치
현재 프로젝트 버전에 맞춰 설치
⇒ 프로젝트 생성 시 java 버전을 11로 설정 했음… 따라서 버전을 맞춰 java 11을 설치해줘야 함
yum list java*
로 java 설치 가능 리스트 검색- 자바 11 버전 中
java-11-amazon-corretto.x86_64
가 EC2에서 설치 가능한 java11 jdk임- Amazon Corretto = 무료로 사용 가능한 OpenJDK의 프로덕션용 멀티플랫폼 배포판
- 참고 (https://mchch.tistory.com/223)
- 자바 11 버전 中
yum install java-11-amazon-corretto.x86_64
로 설치- 인스턴스의 Java 버전 11로 변경
sudo /usr/sbin/alternatives --config java
타임존 변경
기본 서버 시간은 미국 시간대 → 한국 시간대로 맞춰주기
- 서버 시간을 한국 시간으로 변경
sudo rm /etc/localtime
sudo ln -s /usr/share/zoneinfo/Asia/Seoul /etc/localtime
호스트 네임 변경
현재 접속한 서버의 별명 등록하기 (IP 대신 식별하기 쉬운 이름 = 호스트 네임)
- 각 서버가 어느 서비스인지 표현하기 위해 →
HOSTNAME
을 변경하자
- 현재 hostname 확인
- 현재 퍼블릭 DNS 이름이 추가적으로 등록이 되어있지 않은 상태이므로 시스템 호스트 이름 반영
- HOSTNAME 잘 등록 됐는지 확인 →
curl freelec-springboot2-webservice
- 아직 80포트로 실행된 서비스가 없기에 fail이 뜬다.
/etc/hosts
- hosts 파일
- 도메인의 IP를 찾을 때 컴퓨터가 맨 처음 조사하는 파일
- 즉, DNS 파일
- 127.0.0.1
- 서버 컴퓨터 자신을 가리키는 IP 주소
- 해당 IP주소의 hostname으로 현재 로컬에서 개발 중인 사이트 도메인 걸어줌
- freelec~ 도메인은 공식 등록 X 상태임. 따라서 직접 지정해줘야 컴퓨터가 도메인의 IP 주소 찾을 수 있음
- ::1 은 ipv6에서 내 컴퓨터를 가리키는 ip 주소
EC2 서버 완성!
Chap 7. AWS에 데이터베이스 환경을 만들어보자— AWS RDS
데이터베이스를 구축하고 앞 장에서 만든 EC2 서버와 연동
서버에 직접 데이터베이스를 설치하면 모니터링, 알람, 백업, HA 구성 등을 모두 직접해야 하기에, RDS 사용
7.1 RDS 인스턴스 생성하기
- MariaDB 사용
- 상용 데이터베이스인 오라클, MSSQL이 오픈소스인 MySQL, MariaDB, PostgreSQL보다 동일 사양 대비 가격이 더 높음
- MySQL과 PostgreSQL을 클라우드 기반에 맞게 재구성한 데이터베이스인 Amazon Aurora로 교체가 용이함
- MariaDB의 장점
- MariaDB is used because it is fast, scalable and robust, with a rich ecosystem of storage engines, plugins and many other tools make it very versatile for a wide variety of use cases.(https://mariadb.org/about/)
- 데이터베이스 생성
-
- 네트워크에서 퍼블릭 엑세스 [예]로 설정, 이후 보안 그룹에서 지정된 IP만 접근하도록 막음
7.2 RDS 운영환경에 맞는 파라미터 설정하기
- 파라미터 그룹 생성
- 방금 생성한 MariaDB의 버전(10.6.10)과 같은 버전대(10.6) 선택
- 파라미터 편집 버튼을 눌러 편집 모드로 전환
- 타임존
- time_zone Asia/Seoul로 지정
- Character Set
- character_set_client
- character_set_connection
- character_set_database
- character_set_filesystem
- character_set_results
- character_set_server
- collation_connection
- collation_server
- utf8mb4로 지정, utf8mb4는 이모지 저장 가능
- Max Connection
- max_connection 150으로 수정
- 파라미터 그룹 데이터베이스에 연결
- 데이터베이스 수정 버튼을 클릭해서, 데이터베이스 파라미터 그룹을 방금 생성한 파라미터 그룹으로 변경
- 예약된 다음 유지 관리 기간에 적용을 선택하면, 수정사항이 반영되는 동안 데이터베이스가 작동되지 않을 수 있으니 예약시간을 걸어둠. 지금은 서비스가 오픈되지 않았으므로, 즉시 적용
7.3 내 PC에서 RDS에 접속해 보기
- RDS의 보안 그룹에 본인 PC의 IP를 추가하기
-
- RDS >데이터베이스 >freelec-springboot2-webservice >연결&보안 >보안 >VPC 보안그룹
- 클릭해서 들어간 화면에서 필터 제거하면 숨겨진 ec2 보안그룹이 나옴
EC2 보안그룹 ID = 이름이 freelec-springboot2…인 보안 그룹의 보안그룹 ID
- 체크된 보안그룹(RDS 보안그룹) > 인바운드 규칙 편집 > 규칙 추가
| Mysql/Aurora | 3306 | ec 그룹 ID 복붙 | ec2 |
| Mysql/Aurora | 3306 | 내 IP | - |
RDS와 개인 PC, EC2 간의 연동 설정 완료
- Database GUI 클라이언트 사용해서 RDS 설정하기
- MySQL workbench 다운 받기
- Workbench 시작 화면에서 MySQL Connections 옆에 + 버튼 눌러서 Setup New Connection 시작하기
- Hostname : RDS 엔드포인트 (RDS >데이터베이스 >freelec-springboot2-webservice >연결&보안 >엔드포인트 및 포트 >엔드포인트)
- Username : 마스터 계정 이름(7.1에서 RDS 생성할 때 설정했던 계정 이름)
- Password : Store in Vault → 비밀번호 입력
- Test Connection 후 OK 버튼 눌러서 DB 생성
- SQL 쿼리 실행하기
// character_set, collation 설정 확인하는 코드
show variables like '%c';
//파라미터 그룹 변경 못한 값 변경하기
ALTER DATABASE freelec_springboot2_webserver;
CHARACTER set = 'utf8mb4'
COLLATE = 'utf8mb4_general_ci';(한번에 실행)
//타임존 확인하기
select @@time_zone, now();
//한글명이 들어가는지 확인해보기
CREATE TABLE test(
id bigint(20) NOT NULL AUTO_INCREMENT,
content varchar(255) DEFAULT NULL,
PRIMARY KEY (id)
) ENGINE=innoDB;
insert into test(content) values ('테스트');
select * from test;
7.4 EC2에서 RDS에서 접근 확인
- EC2 접속하기
- putty실행 → freelec~.ppk파일 Load → OPEN
- EC2 창에서 MySQL CLI 설치하기
sudo yum install mysql
- RDS 접속하기RDS 가입할 때 입력한 비밀번호 입력하면 접속 성공!
mysql -u 계정 -p -h Host 주소
계정: RDS 가입 계정 이름, Host 주소: RDS 엔드포인트 주소- RDS 확인하기
show databases;
성공!
⏳래퍼런스 추가 공부
localhost란?
- localhost:8080 = ip 주소 127.0.0.1에 해당하는 도메인
- 엄밀히 따지면 도메인 자체는 localhost. 뒤에 8080이 붙는 것은 사용하는 포트번호를 나타낸다. (톰캣 서버가 8080번 포트를 이용하니까?)
- 이때 127.0.0.1는 특수한 IP주소. ⇒
루프백 or 로컬호스트 주소
- 웹 사이트에 접속해서 이것저것 하는 것은 클라이언트가 서버에게 http 프로토콜을 사용해 request와 response message를 packet 단위로 주고 받는 것
⇒ 이것은 크게 보면 네트워크 통신이기도 하다.
❓그래서 네트워크 통신과 localhost가 뭔 상관??
→ 네트워크 시간에 배웠던 내용을 떠올려보자.
- 네트워크 통신 == end host끼리 패킷을 주고 받는 것
- 이때 패킷은 logical하게는 host들 사이에 message를 교환하는 것이다~ 라고 말할 수 있지만 사실 message는 도
착하기까지 수많은 layer를 거치며 encapsulation , decapsulation을 반복한다.
- 이때 패킷은 logical하게는 host들 사이에 message를 교환하는 것이다~ 라고 말할 수 있지만 사실 message는 도
- 네트워크 → link 과정에서 header에 목적지 까지 필요한 제어정보 (IP주소 등)가 붙는데, 이 과정에서 주소가 특정한 루프백 주소를 붙여서 보낸 경우 ⇒ 목적지가 자신이 되어 외부로 나가지 않음
- 즉, 출발지 = 목적지 = 본인 = localhost 가 되는 것
- 따라서, 루프백을 활용하면 별도의 서버 구축이 요구되지 않고, 자기 컴퓨터로 양쪽 host 역할을 하는 것이다. → 외부에선 접근 불가능하다.
🤔 고민해 볼 거리
저번 Chap 5 실습 중 OAuth로 구글 로그인 구현 하는 과정에서, 이름이 자꾸 컴퓨터에 설정 해 놓은 사용자 이름으로 떴었다.
⇒ 찾아보니 index.mustache 파일에 엑세스 토큰을 받아온 사용자 정보 중 이름을 화면에 출력하기 위해 userName이란 변수를 사용했었는데, 이 이름이 기존 윈도우 환경변수에서 선점한 변수명이기에 충돌이 발생했을 수 있다는 글을 보았다.
실제로 loginUserName으로 변수명을 변경하니 이름이 정상적으로 출력 되고, 오류로 떴던 이름이 계속해서 프로젝트가 존재하는 상위 폴더의 사용자 이름이였던 것을 생각해보면… 납득이 간다.
- 진정한 클라이언트-서버 구조에서 서버 역할을 수행하려면?
- 서버는 24시간 내내 가동되어야 한다. (유일하게 data를 제공하므로)→ 따라서 기업의 경우 서버 돌리기용(?) 전용 컴퓨터를 모아놓은 서버실이 존재하는 것
- → 이러기 위해선 한 컴퓨터에서 서버를 내내 구동(어플리케이션 실행)하고 있어야 함
- 비용적 부담 + 관리의 어려움… →
클라우드 컴퓨팅
탄생
<<localhost = 개발 환경>>
- 루프백 주소로 취급되는 특별한 주소의 도메인이기에, 혼자서 client, server 역할을 다 한다.
- 외부에서 localhost에 접속 → 내 컴퓨터에 요청 보내기란 불가능
- = 항상 가동되는 서버의 별도 구축 필요
클라우드를 사용해야 하는 이유?
- 서버를 띄우는 방법이 클라우드 컴퓨팅만 존재하는 것은 아님. → 온프레미스 방법 존재
- 위에서 말한대로 직접 컴으로 24시간 풀가동시키면 가능 (클라우딩 컴퓨팅 전 실제 방식)
- 여러 서버를 보유하고 직접 유지 관리 = 엄청난 인력 소모, 초기 비용 막대함
- 무엇보다 사용자들의 요청에 유연한 대처가 힘들다 (당장 무슨 수로 기기와 사람은 구함??)
온프레미스
- 서버 관련 인프라를 직접 구축하는 것
- 특별한 요구사항이 있고 운영할 여건이 되는 기업에게 더 적합한 방식이다.
클라우드 컴퓨팅
- 온프레미스의 바탕이 되는 물리적 장비와 운영에 필요한 기능을 다른 누군가가 대신 구축해놓고, 그 서비스를 고객이 대여해 사용하는 형식
- 비단 개인 뿐만 아니라 기업도 자주 사용한다(Ex. 금융권)
- 기업은 왜?? → 앞서 언급했듯이 온프레미스에 비해 클라우드는 유연한 대처가 쉽다. 사용자 요구사항이 급변하는 요즘시대에 맞춰 비즈니스 모델도 빠르게 변화를 반복하는데, 그러기에 안성맞춤임
- 고객의 데이터 또한 그 양이 급증하여 관리에 집중하기엔 기업도 부담 → 분업을 하자
- AWS의 다른 서비스를 이용해 빅데이터 처리 or ML 모델 학습 후 배포, 서버리스 서비스 등 다양한 사용이 가능하다.
EC2 인스턴스를 생성한다는 것의 의미
EC2 인스턴스 생성 = 가상 서버 구축
- AWS가 가진 HW 장비 일부를 대여해, 내 서버 돌리는데 사용하겠다 → OS(ex. 아마존 리눅스2) 설치하고 네트워크 구성해 거기서 나의 애플리케이션을 구동시키면 → 누구나 접속 가능!
인스턴스 설정 값의 의미
- 📍 AMI (Amazon Machine Image) : SW 구성을 기록한 탬플릿 (안내서)
-
- 서버 디스크에 설치된 내용 자체가 AMI에 들어있음 ⇒ AMI에서 인스턴스 생성하면 그것들이 다 복사됨. 동일한 설정의 서버를 손쉽게 대량 생산 가능함
- EX) Amazon Linux AMI : 아마존이 제공하는 레드햇 기반 리눅스 세트
- 인스턴스 접속 시 리눅스 환경으로 접속 → 그래서 윈도우에선 putty를 경유해야 됐던 것
- AMI는 개인이 제작 가능하다
- 같은 구성의 서버 복제 or 구축한 서버의 백업용으로 사용
- 💡 if 웹 서버로 사용할 서버 여러 개 만들고 싶다 → AMI에 사용한 서버 OS, 아파치 + α 등 넣어 AMI 선택
- 📍 인스턴스 유형 : 머신의 용도
- 인스턴스 유형에 따라 → 컴퓨터 자원 (CPU, 메모리, 스토리지, 네트워크 …) 조합 차이 발생
- 서비스 규모에 따라 크기도 선택 필요 (→ 유형, 크기에 따라 단가 책정됨)
- 💡 현재 생성한 t2.micro 유형의 인스턴스
- t2 : 범용 시리즈 중 하나인 t 시리즈 유형에 속함. 크레딧 존재함 (=트래픽 낮은 유형에 적합)
- micro : 인스턴스 크기
- 📍VPC, 서브넷
- VPC : 가상 네트워크 구축해주는 서비스
- 서브넷: IP주소에서 네트워크 영역의 부분 집합(망)
- 서버 (ex. 웹, DB…)들은 같은 네트워크에 연결 되어있어야 함
- EC2, RDS도 마찬가지로 같은 네트워크에 연결 돼야 함 → 이 네트워크를 구축해주는 서비스 = Amazon VPC
- Amazon VPC
- AWS 계정 전용 가상 네트워크 서비스
- AWS에서 제공하는 리소스만 설치 가능 (+ EC2, RDS는 얘 선택 강제)
- 서버 (ex. 웹, DB…)들은 같은 네트워크에 연결 되어있어야 함
- 📍 보안 그룹 : VPC의 가상 방화벽(= 네트워크 통신 제어 방식)
- 인바운드 규칙
- 외부 네트워크 → 인스턴스로 들어오는 통신에 대한 정책
- 외부에서 해당 인스턴스 접속 시도하면, 어떤 접근을 허용할 것인지 정함
- 22번 포트(SSH 접속 담당 - BASH창으로 접속)로 들어오는 접속(따라서 다른 장소에서도 설정 건드리고 싶으면 인바운드 규칙에 거기 IP주소 추가) → 허용한 IP 주소 (당시 현재 장소 등록함)로 들어오는 요청만 수락함
- 8080 포트로는 어떤 IP든 요청 보내기 가능 (서버니까)
- 아웃바운드 규칙
- 인스턴스 → 외부 네트워크로 나가는 통신에 대한 정책
- 반대로 아웃바운드 규칙엔 IP 제한을 두지 않음 → 어떤 클라이언트(외부 네트워크)가 접속해 리퀘스트를 보낼 지 모르니까
- 인바운드 규칙
- 📍SSH 접속 / 키 페어
- SSH 접속
- 원격 접속으로 서버 관리하기 위한 접속 방식
- 서버에 설치한 SW 설정 변경하기 위해 사용하는 접속 방식 (관리자모드)
- 사용 조건 : 서버에 SSH 사용하기 위한 데몬 돌아고 있으면 OK
- 키 페어
- SSH 접속하기 위해 필요한 일종의 암호
- 로그인 시 인증으로 사용되는 공개키-비밀키 쌍
- 키 페어 파일의 활용 : 인스턴스 쪽(공개키), 접속자(비밀키)로 각각 설정해 사용
- SSH 접속
- 📍Elastic IP : 서버가 사용하는 고정IP
- 서버는 항상 돌아가되, 주소도 permanent 해야 함
- 하지만 인스턴스 정지 후 재시작 할 때마다 공인 IP주소 달라짐 ⇒ permanent (X)
- 고정 IP 별도로 지정 (Elastic IP)
- 서버는 항상 돌아가되, 주소도 permanent 해야 함
- 📍ELB
- 서버 엑세스 상태에 따라 → 서버 대수 조정해주는 기능 (오토 스케일링)
- EC2에도 auto scaling 기능이 탑재됨.
가상화
- 어플리케이션 당 1대의 HW가 할당 되는 것이 아니다
- HW 1개를 logical하게 분할 → 조합해 가상의 시스템을 생성 : 가상화
- 이것을 가상의 시스템에 활용 (→ 이래도 서로 독립적인 시스템으로 인지됨)
- 효율적인 리소스 사용 가능, 독립적 시스템이므로 각자에게 영향 미치지 않음
RDS와 EC2 연동
- 데이터베이스 서버 만드는 방법
- EC2 인스턴스에 별도의 DB 서버 프로그램 설치 → EC2 인스턴스가 DB서버 역할도 하게끔 함
- DB관리를 직접 해줘야 하는데 고려할게 너무 많다
- EX) 모니터링, 알람, 백업, HA 구성 …
- RDS 서비스 사용하기
- AWS가 제공해주는 DB 서버 프로그램 → 당연히 AWS가 자동 관리 해줌
- 따라서 특별한 요구사항이 없다면 RDS를 사용하자.
- EC2 인스턴스에 별도의 DB 서버 프로그램 설치 → EC2 인스턴스가 DB서버 역할도 하게끔 함
RDS와 EC2의 네트워크 설정 방법? (연동)
- RDS는 EC2에 설치된 SW와 연동해 사용 가능함 == EC2와 네트워크 공유해야 함 == 같은 VPC
- VPC ID가 동일한지 확인
- RDS의 DBMS를 사용하기 위해, EC2 인스턴스 → RDS로 접속 가능해야 함 ⇒ 인바운드 규칙
- RDS의 인바운드 규칙 (EC2 → RDS) 설정 : RDS 보안그룹 인바운드 규칙에 EC2 접속 허용
- EC2에 사용된 보안 그룹 ID, (+ 개인 PC용 본인 IP) 복사 해 추가함
- RDS의 인바운드 규칙 (EC2 → RDS) 설정 : RDS 보안그룹 인바운드 규칙에 EC2 접속 허용
RDS 인스턴스 설정 값
- 데이터베이스 엔진
- DBMS로 사용할 종류 선택 (실습에선 Maria DB 사용)
- 실무에선 Amazon Aurora를 많이 사용하는 듯. Maria DB, MySQL과 호환성이 우수하다고 함
- 데이터베이스 인스턴스
- 인스턴스 클래스, 스토리지 유형, 스토리지 용량, 자동 스케일링, 마스터 사용자 정보등을 담고 있음
- 네트워크 설정 : VPC, 서브넷 그룹, 보안 그룹 등… (연동 위해 조작 필수)
- 데이터베이스 환경 : 데이터베이스 명, 포트 번호, 데이터베이스 파라미터, 백업, 로그 등
RDS 서비스는 EC2 서비스와 다르게 AWS에서 어느정도 관리를 해준다
- 이를테면 백업 및 업데이트, 모니터링 등을 제공해줌 → 자동이므로 주의할 것
'Group Study (2022-2023) > Spring 입문' 카테고리의 다른 글
[spring 입문] 토이 프로젝트 - BDNSook (1) | 2022.12.20 |
---|---|
[spring 입문] 6주차 스터디 - EC2에서 소셜 로그인 하기 + 자바 웹 애플리케이션의 동작과 배포 (0) | 2022.11.20 |
[Spring 입문] 4주차 스터디 - 스프링 시큐리티와 OAuth 2.0으로 로그인 기능 구현하기 (0) | 2022.11.09 |
[Spring 입문] 3주차 스터디 - 머스테치로 화면 구성하기 (0) | 2022.11.01 |
[Spring 입문] 2주차 스터디 - 스프링 부트에서 JPA로 데이터베이스 다뤄보기 (0) | 2022.10.10 |