2026. 1. 3. 01:40ㆍ카테고리 없음
- 0. AWS 시작하기
- 1. EC2에 서버 환경 구축하기 (Spring Boot 배포 준비)
- 2. Docker Compose로 Spring Boot 애플리케이션 실행하기
- 3. Route53으로 도메인 연결하기
- 4. HTTPS 적용하기: ELB vs Nginx + Cerbot
- 5. S3로 파일 관리하기
지난 시간에는 AWS를 사용하여 프로젝트를 서버에 구축하기 위한 준비를 했습니다.
이번 시간에는 AWS EC2를 활용해 가상 서버를 만들고, Docker를 사용하여 Spring Boot 애플리케이션을 띄워보겠습니다.
우선, AWS 사용에 있어 항상 체크해주어야할 것이 있습니다.
바로 '리전'(region) 인데요. AWS 로그인을 하면 콘솔 우측 상단에서 확인할 수 있습니다.
리전이란?
AWS는 전 세계에 데이터 센터를 운영하고 있습니다. 데이터 센터 안에는 굉장히 많은 서버(컴퓨터)가 존재하고, 리전을 선택한다는 것은 그 위치의 데이터 센터에 있는 컴퓨터 자원을 원격으로 빌려 쓰겠다는 의미입니다.
따라서, EC2를 생성하고 서비스를 활용할 때는 본인이 작업 중인 리전이 맞는지 항상 체크해줘야합니다.
리전마다 자원이 분리되어 있기 때문에, 같은 서비스라도 반드시 동일한 리전 내에서 생성해야 연동이 가능하기 때문입니다.
( ex. 서울 리전에 만든 EC2에서, 도쿄 리전에 만든 RDS로는 직접 연결이 안됨 )
💡 리전 선택 시 참고사항
1. 사용자와 서버의 물리적 거리
리전과 사용자와의 거리에 따라 네트워크 지연(레이턴시)가 발생할 수 있습니다.
따라서 사용자와 가까운 리전을 선택해야 응답 속도가 빨라집니다.
만일 국내 사용자를 타겟으로 하는 서비스라면 서울 리전을 쓰는게 좋겠죠?
2. 요금
리전마다 요금이 다르기도 합니다.
같은 사양의 EC2 인스턴스라도 서울 리전과 버지니아 리전의 요금이 다를 수 있습니다.
이는 지역별 운영 비용이 다르고, 수요 차이가 발생하기 때문입니다.
3. 서비스 가능여부
모든 리전에 모든 서비스가 제공되는 것은 아닙니다.
따라서 본인이 사용하려는 서비스가 해당 리전에서 제공하고 있는지 꼭 살펴보세요.
AWS 계정 로그인 후, 리전을 확인했다면 본격적으로 EC2를 사용해보겠습니다. 저는 리전을 서울에 두고 진행하겠습니다.
EC2란?
EC2는 AWS에서 제공하는 클라우드 서버 서비스로 컴퓨터를 사서 직접 운영하지 않고도 원하는 성능의 가상 서버를 빌려쓸 수 있는 서비스 이름입니다. 필요한만큼 탄력적으로 서버를 늘리거나 줄일 수 있는게 특징이며, EC2에서 생성된 가상 서버 한대를 인스턴스라고 말합니다.
따라서 EC2 서비스를 사용하기 위해서는 우선 인스턴스(instance)를 생성해야 합니다.
이 과정을 통해 서버가 만들어지고, 해당 서버에 애플리케이션을 배포해 서비스를 운영할 수 있게 됩니다.
1. 인스턴스 생성하기
우선 EC2 서비스를 사용할 것이기 때문에 검색창에 'EC2'를 검색한 후, [ 인스턴스 시작 ] 버튼을 눌러 가상 서버를 생성해보겠습니다.
EC2 설정
가상 서버를 생성할 때, 어떤 운영체제를 설치할지, 어떤 사양의 서버를 빌릴지 선택할지 등등 필요한 설정들이 있습니다.
차근차근 진행해보도록 하겠습니다. 우선, 프로젝트를 올릴 서버 이름을 적어주세요.
운영체제 선택
운영체제는 우분투를 선택, 프리 티어 사용 가능한 AMI를 사용하겠습니다.
💡 AMI란?
사양 선택
이제 어떤 스펙의 서버를 빌릴지 선택할겁니다. CPU, 메모리, 네트워크 성능 등 필요하나 리소스에 따라 인스턴스 유형을 고를 수 있는데요.이번 과정에서는 프리티어 제공 인스턴스인 t3.micro를 선택하겠습니다. 실습용이나 작은 규모의 프로젝트 배포까지 무리없이 사용할 수 있는 사양이라고 합니다.
월 750시간(30일 X 24시간 X 1대) 무료사용가능하며, 이는 다시말해, 프리티어라면 EC2 1대는 무료라는 의미입니다.
프리티어 초과시, 시간당 $0.0108이 부과되는데요. 과금 기준은 리소스 사용량기준이 아니라 시간기준이며, 초 단위로 계산됩니다. 정말 쓴 '시간'만큼 청구된다는 걸 알 수 있습니다.
키 페어
EC2 인스턴스에 접속하기 위해서는 키 페어라는 보안 인증 파일이 필요합니다. 키 페어는 암호화된 파일형태(.pem 또는 .ppk)로 인스턴스 생성과정에서 발급받을 수 있습니다. 이 파일을 가지고 있어야 SSH 인증을 통해 서버에 접속할 수 있게 됩니다. 발급된 키 페어는 잘 보관해두시길 바랍니다.
[ 새 키 페어 생성 ] 을 눌러 진행하겠습니다. 해당 인스턴스의 키라는 걸 알아볼 수 있도록 이름을 작성하겠습니다.
저는 '프로젝트명-서버에 대한-키-페어'형식으로 명명했습니다.
키 페어의 암호 방식으로 RSA나 ED25519를 선택할 수 있는데요. RSA는 예전부터 널리 쓰이는 암호방식으로, 호환성이 좋은 것이 특징이라고 합니다. 반면에 ED25519는 최근 암호방식으로, 키 페어 파일이 가볍고 처리속도가 빠른 것이 특징입니다. 하지만 오래된 시스템이 지원하지 않을 수도 있다는 가능성이 있습니다. 저는 RSA 방식을 선택하겠습니다.
또 서버에 접속하는 환경에 따라서 키 파일 형식을 선택해줘야하는데요.
Windows에서 PuTTy를 활용해 서버에 접속하시는 경우는 .ppk형식의 키 파일을 선택하셔야하고, 이외의 Mac이나 리눅스로 접속하신다면 .pem 형식으로 발급받으시면 됩니다.
[ 키 페어 생성 ] 을 누르시면 파일이 다운로드 된 것을 보실 수 가 있으실텐데요.
이것이 키 페어 파일입니다. 해당 파일을 가지고 있어야 서버접속이 가능하기 때문에 꼭 잘 보관해주세요.
네트워크 설정
네트워크 설정에 있어 알아야할 개념에는 VPC, 서브넷, 보안 그룹등이 있습니다.
이를 통해 서버가 어디에 위치하고, 누가 접근할 수 있으며 어떤 경로로 통신할 수 있는지 정의할 수 있게 됩니다.
1. VPC (Virtual Private Cloud)
AWS가 가지고 있는 네트워크 인프라 중에서, 사용자가 직접 구성하고 제어할 수 있는 가상 네트워크 영역을 VPC라고 합니다.
마치 AWS에서 빌려쓰는 가상 서버를 EC2라고 부르듯, 가상 네트워크를 VPC라고 이해하시면 됩니다. VPC에 대한 자세한 개념은 추후 포스팅에서 다루겠습니다.
2. 서브넷 (Subnet)
VPC 내부를 기능과 보안수준에 따라 구분한 세부 네트워크 구역입니다.
VPC 가 집이라면, 서브넷은 거실, 작은방, 큰방 이런 세부구역이라고 이해하시면 좋습니다.
방의 역할이 다르듯 서브넷도 용도에 따라 다르게 구성해야하는데요. 용도에 따라 보안수준도 달라지고 외부와 직접통신이 가능한지 여부(보안수준)에 따라 공용 서브넷, 사설 서브넷으로 나눌 수 있습니다.
3. 보안 그룹
보안 그룹은 EC2 인스턴스의 네트워크 방화벽으로, 서버에 누가 들어올 수 있는지(인바운드), 나갈 수 있는지(아웃바운드)에 대한 트래픽 규칙을 설정합니다. 이를 통해 특정 ip나 포트에 대한 접근을 허용하거나 차단하여 서버를 보호할 수 있습니다.
AWS에서는 VPC와 서브넷을 기본으로 자동 생성해주고 있습니다. 저는 간단한 구조의 프로젝트를 띄우려고 하기 때문에 다중 서브넷 구성이나 프라이빗, 퍼블릿 서브넷 분리가 필요하지 않았습니다. 따라서 이번 실습에서는 기본 VPC와 기본 서브넷 설정을 그대로 사용했습니다.
네트워크 설정에서 [ 편집 ]을 눌러주세요. 별다른 설정 없이 보안 그룹쪽 설정만 추가해주겠습니다.
보안그룹 이름을 작성한 후, 인바운드 규칙을 추가하겠습니다.
[ 인바운드 보안 그룹 규칙 ] 은 어떤 IP가 어떤 포트를 통해 내 서버에 접근할 수 있는지 정의하는 부분입니다.
필요한 포트만 열어두고 나머지는 차단하여 서버를 보호할 수 있는거죠.
일반적으로 자주 사용되는 포트번호는 관례적으로 정해져있고, 각 포트는 고유한 용도를 가지고 있습니다.
서버 설정에서는 기본적으로 22번, 80번, 443번 포트는 꼭 알고 있어야하는데요.
이 세 포트는 서버 관리와 웹 서비스 운영에서 가장 자주 사용됩니다.
- 22번 포트 (SSH)
개발자가 서버에 직접 접속할 때 사용하는 원격 접속용 포트입니다.
SSH 프로토콜을 통해 서버에 접속하므로, 보안을 위해 반드시 본인 IP만 허용해야 합니다.
다른 IP까지 허용할 경우 누구나 서버 접속을 시도할 수 있어 보안상 위험합니다.
💡 왜 SSH는 내 IP만 허용해야 할까요?
SSH 포트(22번)를 모든 IP(0.0.0.0/0)에 열어두면, 전 세계 누구나 내 서버에 접속을 시도할 수 있게 됩니다.
실제로 서버를 생성하자마자 수많은 외부 트래픽이 유입되며, 이는 대부분 자동화된 공격입니다.
대표적인 위험은 다음과 같습니다.
- SSH 포트 스캔
외부 공격자는 SSH 포트가 열려 있는 서버를 무작위로 스캔해 접속 가능한 대상을 찾습니다. 이 단계에서는 키 파일이 필요하지 않으며, 단순히 SSH가 열려 있다는 사실만으로도 공격 시도의 대상이 될 수 있습니다. - 무차별 브루트포스 공격
아이디와 비밀번호 조합을 무작위로 대입하며 로그인 시도
-> 비밀번호 기반 인증을 사용하는 경우, 언젠가는 계정이 뚫리게 됩니다. - 기본 계정명 자동 공격
root, admin, ec2-user, ubuntu 같은 서버 기본 계정들을 공격
-> 실제 로그를 보면 이런 계정으로 수천 번의 로그인 시도가 발생합니다.
따라서 SSH는 반드시 본인의 IP만 허용해야 하며, 불필요한 공격 자체를 차단하는 기본 수칙입니다.
웹 서비스용 포트(80, 443)는 외부에 열어두더라도, 서버 관리용 포트인 22번은 최대한 닫아두는 것이 안전합니다.
- 80번 포트 (HTTP)
사용자가 웹사이트에 접속할 때 사용하는 일반적인 웹 통신 포트입니다.
브라우저에서 http://로 접근할 때 사용되며, 외부 사용자가 접속해야 하므로 모든 사용자(0.0.0.0/0)를 허용해야 합니다.
- 443번 포트 (HTTPS)
SSL 인증서가 적용된 보안 웹 통신용 포트입니다.
https://로 시작하는 주소로 접속할 때 사용되며, 통신 내용이 암호화되어 보안성이 높아 실제 운영 환경에서는 80번 포트보다 더 많이 사용됩니다. HTTPS 역시 외부 사용자 접근이 필요하므로 모든 사용자에게 허용합니다.
따라서, 이 세가지 포트 모두 규칙에 추가하겠습니다.
우선, 기본 22번 SSH 통신 포트부터 설정하겠습니다.
SSH는 서버에 직접 접속하기 위한 관리용 포트이기 때문에, 반드시 내 IP만 허용하는 것이 원칙입니다.
다만, 실습용으로 따라하시는 분들 중엔 집이나 회사가 아닌 노트북으로 카페 등 외부 환경에서 접속하는 경우도 종종 있으신데요.
이때, 사용할때마나 외부 IP를 허용하는 것은 보안상 매우 위험하므로, 이경우에는 VPN을 통해 IP를 고정하거나, SSM과 같은 대체 접속 방식을 사용하는 것이 좋습니다. 이 부분에 대해서는 뒤에서 따로 자세히 다뤄보겠습니다.
[ 보안 그룹 규칙 추가 ] 를 통해 나머지 80번, 443번 포트도 설정해주겠습니다.
스토리지 구성
스토리지는 서버의 저장공간(하드디스크)을 의미하며, EC2에서는 이를 EBS(Elastic Block Store) 라고 부릅니다. 프리 티어 계정의 경우 최대 30GB까지 무료로 제공됩니다. 이후 언제든지 확장할 수 있으니, 처음에는 적당한 크기로 설정해두시면 됩니다.
저는 20GB로 설정하였습니다. 여기까지 인스턴스 관련 설정을 모두 진행해보았고, 이제 하단의 [ 인스턴스 시작 ] 버튼을 눌러주세요.
생성된 인스턴스는 [ 메뉴 > 인스턴스 ] 에서 확인할 수 있습니다.
2. Elastic IP (탄력적 IP)
EC2는 컴퓨터 하나를 빌려 사용하는 서비스라고 했었죠. 컴퓨터에는 당연히 IP 주소가 할당되는데, 여기서 주의할 점은 AWS에서 EC2에 자동으로 부여되는 IP는 고정되어 있지 않다는 것입니다. 저도 처음에는 EC2의 IP가 고정되어 있을 거라고 생각했습니다. 하지만 실제로는 인스턴스를 중지하거나 재시작할 때마다 퍼블릭 IP 주소가 변경될 수 있습니다. 접속 주소가 계속 바뀔 수 있기 때문에 바뀔 때마다 설정을 다시 해줘야 서비스를 이용할 수 있게 되는거죠.
AWS에서는 서버 주소가 바뀌지 않도록 고정 IP를 사용하려면 탄력적 IP(Elastic IP)를 따로 할당한 뒤, 해당 IP를 EC2 인스턴스에 직접 연결하는 과정이 필요합니다.
탄력적 IP 주소 할당
우선, [ 메뉴 > 네트워크 및 보안 ] > 탄력적 IP ] 로 이동해서, [ 탄력적 IP 주소 할당 ] 버튼을 눌러주세요.
설정에서는 크게 변경할 것은 없습니다. 다만 앞에 생성한 인스턴스와 동일한 리전으로 되어있는지만 체크해주세요.
이후, [ 할당 ] 버튼을 눌러주세요.
탄력적 IP 주소 연결
앞서 할당된 ip 주소를 인스턴스에 연결해보겠습니다. 아래 이미지처럼 사용할 주소를 선택하여 [ 탄력적 IP 주소 연결 ] 을 진행하겠습니다.
인스턴스를 지정하고 [ 연결 ] 을 눌러주세요.
3. EC2 접속하기
인스턴스 생성 및 IP 연결을 완료했으면 이제 실제로 서버에 접속해볼 차례입니다.
EC2 접속은 원격 접속 방식인 SSH를 통해 이루어지며, 앞에서 생성했던 키 페어 파일(.pem) 이 반드시 필요합니다.
저는 macOS 환경에서 작업하고 있어, Windows 환경에서는 접속 방법이나 화면 구성이 일부 다를 수 있습니다.
[ EC2 > 인스턴스 ] 에서 인스턴스의 상세 내용을 확인할 수 있습니다.
이를 참고하여 터미널을 통해 EC2 서버에 직접 접속해보겠습니다.
SSH로 EC2에 접속하기 위해서는 서버 IP 주소, 사용자 계정명, 키 페어 파일(.pem)이 필요합니다.
키 페어 파일이 저장되어 있는 경로(폴더)로 이동한 뒤, 해당 위치에서 터미널을 열어주세요.
키 페어 권한 확인하기
SSH는 보안상 개인 키 파일(.pem)의 권한을 매우 엄격하게 검사합니다.
만약 키 파일에 다른 사용자(그룹/기타 사용자)에게 읽기 권한이라도 허용되어 있다면, SSH는 이를 보안 위험 요소로 판단해 접속을 차단합니다. 따라서 키 파일 권한이 올바르게 설정되어 있는지 확인해야 합니다.
아래 명령어로 키 페어 파일의 권한을 확인할 수 있습니다.
ls -l 키페어파일명.pem
# 권한 설정이 올바른 경우
-r-------- 1 younggalee staff 1678 12 29 22:42 yesul-server-key.pem
# 권한 설정이 잘못된 경우
-rw-r--r--@ 1 younggalee staff 1678 12 29 22:42 yesul-server-key.pem
💡 권한 해석하는 법
권한 표시는 맨 앞의 -를 제외하고 3비트씩 끊어서 해석하시면 됩니다.
각각 소유자 / 그룹 / 기타 사용자의 권한을 의미하며 각 비트는 순서대로 r(읽기), w(쓰기), x(실행) 권한을 나타냅니다.
키 페어 파일의 경우, 파일 소유자만 읽을 수 있는 상태여야하기에 소유자만 읽기가 허용(r--)되고 나머지는 제한(---)되어야합니다.
키 페어 권한 변경하기
소유자 이외의 사용자에게도 권한이 부여된 상태라면 소유자만 읽기가 허용되도록 권한을 변경해야합니다.
아래 명령어로 키 페어 파일의 권한을 변경할 수 있습니다.
chmod 400 키페어파일명.pem
400은 소유자만 읽기 권한을 가지도록 설정 한다는 의미입니다. (-r--------)
💡 권한 숫자 표기법
유닉스 계열 운영체제에서 파일과 디렉터리의 권한은 숫자 또는 문자(rwx) 형태로 표현됩니다.
문자 권한은 r(읽기)=4, w(쓰기)=2, x(실행)=1로 대응되며, 이 값들을 더해 0~7 사이의 숫자로 나타냅니다.
숫자 권한은 항상 소유자/그룹/기타사용자 순서로 적용되며, 각 자리는 해당 주체가 가지는 권한의 합을 의미합니다.
따라서, 400은 소유자에게만 4(읽기) 권한을 주겠다는 표현입니다.
SSH로 서버 접속하기
권한 설정이 끝났다면, 아래 명령어로 SSH 접속을 시도하겠습니다.
ssh -i 키페어파일명.pem 접속할계정명@서버IP주소
-i 는 파일을 지정하는 옵션이며, AWS EC2에서 Ubuntu AMI를 사용하면 기본 계정명은 보통 ubuntu로 설정되어 있습니다. 서버 ip 주소는 앞서 언급했던 [ EC2 > 인스턴스 ] 에서 확인하실 수 있습니다.
최초 접속에 있어서는 아래와 같은 메시지가 출력될 수 있습니다.
The authenticity of host '13.124.xxx.xxx' can't be established.
Are you sure you want to continue connecting (yes/no)?
정상적인 키 등록과정이며, yes 입력해주시면 됩니다.
💡 Permission denied (publickey) 발생한다면
대부분은 키 파일 권한 문제입니다. 다시 한번 키 페어 파일이 저장된 경로에서 chmod 400권한이 제대로 설정되어있는지 확인해주세요.
여전히 발생한다면 등록된 키 파일명을 제대로 입력했는지 확인해보세요. 계속 안되신다면 다시 발급받아 진행해보시는걸 추천드립니다.
정상적으로 접속되면, 아래와 같이 서버 정보가 보이게 됩니다.
ubuntu@ip-172-31-xx-xx:~$
원격 접속이 완료되었습니다. 이제 터미널은 내 로컬 PC가 아니라 AWS 빌린 EC2 서버의 터미널입니다.
이제부터는 할일은 로컬 컴퓨터에서 했던 것과 유사합니다. 이 서버 환경에서 서비스를 실행하기 위한 환경 세팅을 진행하고, 프로젝트를 가져오는 것입니다.
4. Docker 기반 서버 환경 구성
서버에서 실제로 애플리케이션을 실행하기 위해 필요한 환경을 세팅해보겠습니다.
Spring Boot 프로젝트를 실행하려면 Java 실행 환경(JDK), 코드를 내려받을 Git, 그리고 데이터를 저장할 MySQL과 같은 데이터베이스가 필요합니다. 이러한 프로그램들을 EC2에 직접 설치하여 소스코드를 github에서 내려받아 서버에서 직접 빌드하여 배포할 수도 있지만, 이번 프로젝트에서는 Docker를 활용해보겠습니다.
💡 Docker 란?
Docker는 애플리케이션 실행에 필요한 모든 요소를 컨테이너로 묶어, 어떤 환경에서도 동일하게 실행될 수 있도록 도와주는 도구입니다.
실무에서도 Docker는 매우 널리 사용되며, 서버 환경을 코드로 관리할 수 있어 환경 차이로 인한 문제를 줄이고, 배포와 운영을 훨씬 간단하고 안정적으로 만들어줍니다.
이번 프로젝트에서는 Docker를 활용해 애플리케이션, MySQL, Redis를 각각 컨테이너로 구성해 실행해볼 예정이며, 이를 효율적으로 관리하기 위해 Docker Compose를 사용하겠습니다.
💡 Docker Compose 란?
Docker Compose는 여러 개의 컨테이너를 하나의 설정 파일(docker-compose.yml)로 정의하고, 한 번의 명령어로 함께 실행할 수 있도록 도와주는 도구입니다. 각 컨테이너의 이미지, 포트, 환경 변수, 네트워크, 볼륨 설정 등을 하나의 파일에서 통합 관리할 수 있어, 여러 개의 컨테이너 환경을 한눈에 이해하고 관리하기 쉬운 구조로 만들 수 있다는 장점이 있습니다.
Docker / Docker Compose 설치하기
Docker Compose를 이용해 서버에서 애플리케이션 실행 환경을 구성하려면 로컬 개발 환경과 서버 환경 모두에 Docker와 Docker Compose를 설치해야 합니다.
로컬 개발 환경에 설치하기
로컬 개발 환경에서는 Docker Desktop이라는 통합 도구를 설치하면 Docker와 Docker Compose가 함께 설치되기 때문에, 별도의 추가 설치 없이 바로 Docker Compose 환경을 구성할 수 있습니다.
- windows : https://docs.docker.com/desktop/setup/install/windows-install/
- mac : https://docs.docker.com/desktop/setup/install/mac-install/
위 페이지에서 Docker Desktop을 설치해주세요.
설치가 완료되셨다면, Docker Desktop에 들어가 회원가입 및 로그인까지 진행해주시기 바랍니다.
서버 개발 환경에 설치하기
우선 서버에 원격으로 접속해보겠습니다. 키 페어 파일이 있는 경로에서 터미널을 열고, 아래 명령어를 입력합니다.
ssh -i yesul-server-key.pem ubuntu@(EC2 public IP)
해당 명령어를 실행하면 EC2 서버에 SSH로 접속할 수 있습니다.
(이후 과정부터는 SSH 접속 과정은 생략하고 진행하겠습니다.)
이제 아래 명령어를 통해 Docker와 Docker Compose를 한 번에 설치해보겠습니다.
Ubuntu 환경에서 공식 Docker 저장소를 추가한 뒤, 최신 버전의 Docker Engine과 Docker Compose를 설치하는 과정입니다.
아래 명령어를 그대로 복사하여 실행해주세요.
sudo apt-get update && \
sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common && \
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - && \
sudo apt-key fingerprint 0EBFCD88 && \
sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" && \
sudo apt-get update && \
sudo apt-get install -y docker-ce && \
sudo usermod -aG docker ubuntu && \
newgrp docker && \
sudo curl -L "https://github.com/docker/compose/releases/download/2.27.1/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose && \
sudo chmod +x /usr/local/bin/docker-compose && \
sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose위 명령어를 실행하면 다음 작업이 한 번에 수행됩니다.
- Docker 공식 저장소 추가
- Docker Engine 설치
- 현재 사용자에게 Docker 실행 권한 부여
- Docker Compose 설치
즉, EC2에서 컨테이너 기반 애플리케이션을 실행하기 위한 기본 환경 구성이 완료되었습니다.
설치가 정상적으로 완료되었다면 아래 명령어로 버전을 확인해보세요.
docker --version
docker-compose --version
이로써 컨테이너 기반으로 애플리케이션을 실행할 수 있는 기본 환경 구성이 마무리되었습니다.
다음 단계에서는 Docker Compose를 활용해 Spring Boot 애플리케이션과 MySQL, Redis를 실제로 실행해보겠습니다. 또한 단순히 컨테이너를 실행하는 것에 그치지 않고, Spring Boot 애플리케이션을 Docker 이미지로 직접 빌드한 뒤, 이를 서버에서 실행하는 과정까지 함께 다뤄보겠습니다.
뭐든지 ‘처음’은 참 어려운 것 같습니다.
낯설고, 생각보다 오래 걸리고,
분명 맞게 하고 있는 것 같은데 자꾸 꼬이기도 하죠.
그래도 포기하지 말고, 꼭 해냅시다!
첫 배포를 준비하고 계신 모든 분들을 진심으로 응원합니다.
※ 이번 <AWS에서 Spring Boot 프로젝트 배포하기> 시리즈에서 다루는 프로젝트는 프론트엔드(React, Vue 등)와 분리된 구조가 아닌, Spring Boot와 Thymeleaf를 사용한 서버사이드 렌더링(SSR) 방식의 애플리케이션입니다. 또한 Docker Compose를 활용하여 애플리케이션과 데이터베이스를 각각 분리된 컨테이너로 구성하여 실행하는 내용을 담고 있음을 참고하시기 바랍니다.