따라하며 배우는 도커와 CI환경 [2023.11 업데이트]인프런 강의(링크)를 보고 직접 실습하며 학습한 내용입니다.
최종 배포한 디렉토리 구조
Dockerfile,Dockerfile.dev,docker-compose.yml을 직접 작성하고 이해하기.
Elastic Beanstalk을 통해 애플리케이션과 환경을 직접 생성하고,Github Actions를 통해 CI/CD까지 마무리 짓는 것이 본 실습의 목표였다.
그래서 디렉토리 구조도 단순하고, 내부 코드 내용도 별 것은 없다.
- 요약
Docker-fullstack-app
-- .github/workflows
- deploy.yaml
-- backend
- Dockerfile
- Dockerfile.dev
- server.js
- package.json
-- frontend
- nginx
- default.conf
- public
- src
- Dockerfile
- Dockerfile.dev
- package.json
-- mysql
- Dockerfile
- my.conf
-- nginx
- default.conf
- Dockerfile
- docker-compose.yml- docker-compose.yml
version: "3"
services:
frontend:
image: <docker username>/docker-frontend
volumes:
- /app/node_modules
- ./frontend:/app
stdin_open: true
mem_limit: 128m
nginx:
restart: always
image: <docker username>/docker-nginx
ports:
- "80:80"
backend:
image: <docker username>/docker-backend
container_name: app_backend
volumes:
- /app/node_modules
- ./backend:/app
mem_limit: 128m
environment:
MYSQL_HOST: $MYSQL_HOST
MYSQL_USER: $MYSQL_USER
MYSQL_ROOT_PASSWORD: $MYSQL_ROOT_PASSWORD
MYSQL_DATABASE: $MYSQL_DATABASE
MYSQL_PORT: $MYSQL_PORTElastic Beanstalk
AWS에는 다양한 서비스들이 많다. AWS는 각 서비스를 필요에 맞게 선택하고, 사용해서 직접 인프라를 설계하여 사용할 수 있는 유연성을 제공한다. 하지만 100개가 넘는 서비스가 있기 때문에, 어떤 상황에 어떤 서비스를 사용할지 선택하고 프로비저닝 방법까지 이해하는 것이 어려울 때가 있다.
프로비저닝이란?
IT 인프라를 설정하는 프로세스이자, 데이터와 리소스에 대한 엑세스를 관리하는데 필요한 단계
이것이 Elastic Beanstalk을 사용하는 가장 핵심 이유다.
인프라 설계 환경을 구축해주기 때문에, Elastic Beanstalk을 사용하게 되면 애플리케이션을 신속하게 배포하고 관리할 수 있다.
또한 애플리케이션 업로드 시, 용량 프로비저닝, 로드 밸런싱, 조정, 모니터링 등의 작업을 자동으로 처리한다.
Workflow
-
다이어그램
-
작업 순서
- 애플리케이션 생성- 애플리케이션 버전 업로드
- 환경 실행 및 AWS 리소스 생성 및 구성
- 환경을 관리하고 새로운 앱 버전 배포 준비
비용
Elastic Beanstalk을 사용하는 비용은 없고, 애플리케이션에서 사용하는 AWS 리소스에 대한 비용만 지불하면 된다.
생성방법
1. 애플리케이션 생성
- 이름과 설명 입력
2. 환경 구성
웹서버환경 선택- 플랫폼 유형 :
Docker - 플랫폼 브랜치, 버전 :
Multi-container - 샘플 애플리케이션 선택
- 단일 인스턴스 선택(프리티어)
- 프로젝트 규모가 크지 않고, 로드밸런서를 사용할만큼 트래픽이 없어서 - 있다면, 고가용성 선택
3. 서비스 엑세스 구성
aws-elasticbeanstalk-service-role역할 사용- ec2 키페어는 아직 만들지 않아서 없음.
EC2 인스턴스 프로파일에는 미리 만들어둔,IAM을 선택해서 넣어줘야 함. 이것 때문에 계속 EB 환경 세팅까지 마친 후 계속 종료되는 문제가 있어서, 관련 글은 따로 포스팅해두었음. (링크)
4. 네트워킹, 데이터베이스, 태그 설정
VPC는 우선 기본 세팅된 값으로 설정함.- 여기서 데이터베이스 활성화가 되지 않는 문제가 있어서, 나는 직접 RDS 세팅해주었고,
VPC도 동일한 값으로 세팅해주었다.
하지만 같은 VPC에 있다고 해도, RDS와 EB 사이에는 3306 인바운드 포트를 열어주어야 한다. 그래서 이건 따로 Security Group을 만들어서 설정해주었고, 해당 보안그룹을 RDS, EB의 인스턴스에 각각 적용해주었다.
VPC
Amazon Virtual Private Cloud(VPC)를 사용하면, AWS 클라우드에서 논리적으로 격리된 공간을 프로비저닝하여 고객이 정의하는 가상 네트워크에서 AWS 리소스를 시작할 수 있다. 그래서 인스턴스를 만들고 나면, 이 인스턴스들을 나의 아이디에서만 접근이 가능하게 논리적으로 격리된 네트워크에서 생성이 되게 해준다.ElasticBeanstalk 인스턴스나RDS를 생성하면, 자동적으로기본 VPC가 할당된다. 그리고 할당이 될 때는 지역별로 다르게 할당이 된다. 같은VPC안에 있어도 통신할 수 없다. 그래서Security Group을 만들어서 따로 허용을 해주어야 한다.
Security Group
EC2 인스턴스 또는 EB 인스턴스 <- Security Group(방화벽) <- inbound from 외부
EC2 인스턴스 또는 EB 인스턴스 -> Security Group(방화벽) -> outbound to 외부
- 인바운드 : 외부에서 EC2 인스턴스나 EB 인스턴스로 요청을 보내는 트래픽 (ex. HTTP, HTTPS, SSH)
- 아웃바운드 : EC2 인스턴스나 EB 인스턴스에서 외부로 나가는 트래픽
EB 환경 생성하고 배포하기
- S3에도 버킷 자동으로 생성되어 있고, EC2도 생성되어 있음을 확인할 수 있다.
- EB의 환경 변수에는
docker-compose.yml에서backend service에서 사용하는 MYSQL 엔드포인트, USERNAME, PW 등의 값을 넣어주었다. AdministratorAccess-AWSElasticBeanstalk권한을 준IAM사용자를 생성하여 해당 사용자의ACCESS KEY,SECRET KEY를 Github Actions 환경변수에 넣어주었다.- S3의
bucket,region값은 확인해서.github/workflows의deploy.yaml파일에 넣어준다.
그리고 나서, 배포를 하니, Github Actions을 통해서 버전 정보는 S3에서 관리되고, EB의 인스턴스에서 애플리케이션이 잘 실행되는 것을 확인할 수 있었다.
참고자료
