이번 hands on에서는 django 와 awsebcli를 활용하여 애플리케이션과 환경을 구성해 보도록 하겠습니다.
1. 개발환경
- Amazon Linux 2
- Python 3.7
- Django 2.2
- mysql
[Hands on 동작과정]
- EC2 서버에 awsebcli를 설치합니다.
- django 프로젝트를 생성 또는 자신의 프로젝트를 복사합니다.
- 환경 구성을 위한 .ebextensions 폴더를 만들고 config 파일을 작성합니다.
- ebcli 명령어를 통해 애플리케이션을 생성하고 환경을 구축 후 배포합니다.
- 코드 수정 후 ebcli 명령어를 통해 새로운 버전을 배포합니다.
Elastic Beanstalk 배포 시 버전에 따른 제한 사항이 있으니 자세한 내용은 공식 문서를 참고 바랍니다.
https://docs.aws.amazon.com/ko_kr/elasticbeanstalk/latest/dg/concepts.platforms.html
2. awsebcli를 이용한 배포
환경 구성을 위한 .ebextensions 를 작성하고 ec2에서 aws의 Elastic Beanstalk 와 S3에 접근이 가능하도록 Role 생성 후 해당 인스턴스에 Role을 설정합니다.
1. django 프로젝트 생성
새로운 django 프로젝트를 생성 또는 자신의 소스코드를 EC2 서버로 복사합니다.
2. awsebcli 설치
1 2 3 |
$ python3 -m pip install --upgrade pip $ python3 -m pip install awsebcli $ eb --version |
3. requirements.txt 파일 생성
가상환경을 실행하여 설치된 패키지를 requirements.txt에 저장합니다.
Elastic Beanstalk는 requirements.txt를 사용하여 애플리케이션을 실행하는 EC2 인스턴스에 설치할 패키지를 결정합니다.
1 |
$ (venv) python3 -m pip freeze > requirements.txt |
2-1 .ebextensions 작성
기본적으로 Elastic Beanstalk는 application.py라는 파일을 찾아 애플리케이션을 시작합니다. 이 파일은 생성한 Django 프로젝트에는 존재하지 않기 때문에 애플리케이션 환경을 약간 조정해야 합니다. 또한 애플리케이션의 모듈을 로드할 수 있도록 환경 변수를 설정해야 합니다. 구성 파일(.ebextensions)을 추가하여 환경을 구성해 보겠습니다.
.ebextensions를 추가하여 vpc, ec2 인스턴스 타입 등 배포에 사용할 aws 리소스를 지정할 수 있으며 배포 중 사용할 명령어와 환경변수등을 설정할 수 있습니다. .config 파일 확장명을 사용하는 YAML이나 JSON 형식 문서로, .ebextensions 폴더에 놓고 애플리케이션 소스 번들로 배포합니다.
1. django.config 파일 작성
프로젝트 폴더 내의 최상단 위치에 .ebextensions 폴더를 만들고 django.config 파일을 생성하여 아래 내용을 작성합니다.
WSGIPath는 Elastic Beanstalk가 애플리케이션을 시작하는 데 사용하는 WSGI 스크립트의 위치를 지정합니다.
DJANGO_SETTINGS_MODULE 환경 변수를 구성하고 django 프로젝트 내 settings.py 파일의 위치를 적어줍니다.
1 2 3 4 5 |
option_settings: aws:elasticbeanstalk:container:python: WSGIPath: mypjt.wsgi:application aws:elasticbeanstalk:application:environment: DJANGO_SETTINGS_MODULE: mypjt.settings |
2. migrate.config 파일 작성
container_commands에서 ec2 인스턴스에서 구동되는 실행 명령을 기술할 수 있습니다. 같은 역할로 commands 키를 쓸 수 있지만 둘의 차이가 있습니다. commands는 container commands 보다 먼저 실행되는데 application과 web server가 아직 설정되기 전, application version 파일이 적용되기 전에 실행되며 container commands는 application과 web server가 모두 준비되고 deploy 되기 직전인 상태에서 실행되는 차이가 있습니다.
데이터베이스와 마이그레이션 하는 작업은 application과 web server가 모두 준비된 후 실행되어야 하기때문에 migrate.config 파일을 생성하여 container_commands 키를 이용하여 마이그레이션 명령코드를 작성합니다.
1 2 3 |
container_commands: 01_migrate: command: "source /var/app/venv/staging-LQM1lest/bin/activate && python3 manage.py migrate --noinput" |
3. eb_setting.config 파일 작성
다음으로는 환경 구성에 대한 eb_setting.config 파일을 작성합니다.
여기서 VPC, 오토 스케일링, Loadbalancer 에 대한 설정을 정의합니다.
![](https://tech.cloud.nongshim.co.kr/wp-content/uploads/2021/10/Untitled.png)
1 2 3 4 |
aws:autoscaling:asg: MinSize: '2' MaxSize: '4' Cooldown: 600 |
환경의 오토 스케일링 그룹을 구성합니다.
- MinSize : 오토 스케일링 그룹에 필요한 최소 인스턴스 수입니다.
- MaxSize : 오토 스케일링 그룹에 필요한 최대 인스턴스 수입니다.
- Cooldown : 휴지 기간을 지정합니다.
1 2 3 |
aws:ec2:instances: EnableSpot: false InstanceTypes: "t2.micro, t3.micro" |
스팟 옵션을 포함하여 환경의 인스턴스를 구성합니다. 이 네임스페이스는 aws:autoscaling:launchconfiguration 및 aws:autoscaling:asg를 보완합니다.
- EnalbeSpot : 환경에 대한 스팟 인스턴스 요청을 활성화합니다
- InstanceTypes : 환경에서 사용할 인스턴스 유형의 쉼표로 구분된 목록입니다. 2개 이상을 권장합니다. 스팟 인스턴스가 비활성화된 경우(EnableSpot이 false인 경우) 목록의 첫 번째 인스턴스 유형만 사용됩니다.
1 2 3 4 5 6 |
aws:autoscaling:launchconfiguration: EC2KeyName: ************ SecurityGroups: sg-************ RootVolumeType: gp3 RootVolumeSize: 8 RootVolumeIOPS: 3000 |
환경의 EC2 인스턴스를 구성합니다.
- EC2KeyName : 사용할 keypair를 작성합니다.
- SecurityGroups : 인스턴스에 적용할 보안 그룹의 ID를 작성합니다.
- RootVolumeType : EC2 인스턴스에 연결된 EBS 볼륨에 사용할 볼륨 유형을 작성합니다.
- RootVolumeSize : EBS 루트 볼륨의 전체 스토리지 용량을 작성합니다.
- RootVolumeIOPS : 루트 볼륨에 필요한 IOPS를 작성합니다.
1 2 3 4 5 6 7 |
aws:autoscaling:trigger: MeasureName: CPUUtilization Unit: Percent LowerThreshold: 20 UpperThreshold: 60 LowerBreachScaleIncrement: -1 UpperBreachScaleIncrement: 1 |
환경의 오토 스케일링 그룹에 대한 확장 조정 트리거를 구성합니다.
- MeasureName : 오토 스케일링 트리거에 사용되는 지표입니다.
- Unit : 트리거 측정 단위입니다.
- LowerThreshold : 측정값이 이 값 아래로 떨어지면 트리거가 호출됩니다.
- UpperThreshold : 측정값이 이 값 위로 올라가면 트리거가 호출됩니다.
- LowerBreachScaleIncrement : 조정 작업 수행 시 제거할 Amazon EC2 인스턴스 수를 지정합니다.
- UpperBreachScaleIncrement : 조정 작업 수행 시 추가할 Amazon EC2 인스턴스 수를 지정합니다.
1 2 |
aws:elbv2:loadbalancer: SecurityGroups: sg************ |
Application Load Balancer를 구성합니다.
- SecurityGroups : 로드밸런서에 연결할 보안 그룹입니다.
1 2 3 4 |
aws:ec2:vpc: VPCId: "vpc-************" Subnets: "subnet-************,subnet-************" ELBSubnets: "subnet-************,subnet-************" |
AWS VPC에서 리소스를 시작하도록 환경을 구성합니다. 이 네임스페이스에서 설정을 구성하지 않으면 기본 VPC에서 리소스를 시작합니다.
- VPCId : Amazon VPC의 ID입니다.
- Subnets : 오토 스케일링 그룹 서브넷의 ID입니다.
- 해당 Hands on 에서는 Private subnet으로 설정하였으며 Public Subnet 을 사용할 경우 ‘AssociatePublicIpAddress : true‘ 옵션값을 추가하여 Public IP 를 할당해주어야 합니다.
- Private subnet으로 설정할경우 NAT Gateway 혹은 NAT Instance로 외부 통신이 가능하게 설정 해야 합니다. ( NAT Instance 생성은 다음 링크를 참고 바랍니다. https://tech.cloud.nongshim.co.kr/2018/10/16/초보자를-위한-aws-웹구축-5-1-nat-서버-생성1/ )
- ELBSubnets : 로드 밸런서에 대한 서브넷의 ID입니다.
- DBSubnets : 데이터베이스 서브넷의 ID를 포함합니다. 이는 Amazon RDS DB 인스턴스를 애플리케이션의 일부로 추가하려는 경우에만 사용됩니다.
1 2 |
aws:elasticbeanstalk:command: DeploymentPolicy: Rolling |
애플리케이션 코드에 대한 배포 정책을 구성합니다.
- DeploymentPolicy : 애플리케이션 버전 배포에 대한 배포 정책을 선택합니다.
AllAtOnce – 새 버전을 모든 인스턴스에 동시에 배포합니다. 배포가 수행되는 동안 환경에 있는 모든 인스턴스가 잠시 서비스 중지됩니다.
Rolling – 새 버전을 배치로 배포합니다. 각 배치는 배포 단계 동안 서비스에서 제외되므로 배치에 있는 인스턴스의 수만큼 환경의 용량이 감소합니다.
RollingWithAdditionalBatch – 새 버전을 배치로 배포하지만, 먼저 새로운 배치의 인스턴스를 시작하여 배포 프로세스 중에 모든 용량이 유지되도록 합니다.
Immutable – 새로운 오토 스케일링 그룹을 만들어 단일 인스턴스를 배치합니다. 원래 있던 오토 스케일링 그룹과 같이 트래픽을 처리하며 새로 배치된 인스턴스의 상태가 양호하면 원래 있던 인스턴스의 수만큼 추가하여 배포합니다.
TrafficSplitting – 카나리 배포 방식입니다. 새로운 오토 스케일링 그룹을 만들고 로드밸런서에서 트래픽의 일정 부분을 보내 상태가 양호하다면 모든 트래픽을 새로 업로드한 인스턴스로 처리합니다.
4. healthcheckurl.config 파일 작성
다음으로 로드 밸런서 상태 검사에 대한 설정 파일 healthcheckurl.config를 작성합니다. 해당 파일에서는 상태 검사 url을 변경합니다. (상태 검사 URL : ‘/health/’)
1 2 3 |
option_settings: aws:elasticbeanstalk:environment:process:default: HealthCheckPath: /health/ |
5. packages.config 파일 작성
마지막으로 필요한 linux 패키지에 대한 설정을 위한 packages.config 파일을 작성합니다. 서비스 구동에 필요한 패키지들을 다운로드 받아서 시스템에 install 할 수 있습니다.
해당 hands on 에서는 파이썬 패키지 중 mysqlclient를 위한 패키지를 설치하였습니다.
1 2 3 4 5 |
packages: yum: python3-devel: '' gcc: '' mariadb-devel: '' |
폴더 구조를 살펴보겠습니다.
![](https://tech.cloud.nongshim.co.kr/wp-content/uploads/2021/10/Untitled-1-1.png)
<주의할 점>
config 파일 작성 시 파일 이름의 사전 순으로 실행되기 때문에 위의 사진과 같이 파일명 앞에 숫자를 붙여 순서를 고려하여 작성하는 것이 좋습니다.
.ebextensions, requirements.txt 파일은 최상단 위치에 저장해야 합니다.
참고 자료
https://docs.aws.amazon.com/ko_kr/elasticbeanstalk/latest/dg/command-options-general.html
https://docs.aws.amazon.com/ko_kr/elasticbeanstalk/latest/dg/create-deploy-python-django.html
2-2. IAM Role 생성
해당 인스턴스에서 awsebcli 설치 후 ebcli 명령어를 통해 beanstalk에 접근이 가능하도록 하려면 인스턴스에 Role을 부여해야 합니다.
- AWS IAM → 역할 → 역할 만들기 → AWS 서비스 선택 → EC2 선택 → 정책 설정
![](https://tech.cloud.nongshim.co.kr/wp-content/uploads/2021/10/Untitled-2.png)
- 다음과 같이 S3와 Elastic Beanstalk에 대한 모든 권한을 부여한 역할을 생성합니다.
![](https://tech.cloud.nongshim.co.kr/wp-content/uploads/2021/10/Untitled-3.png)
- 해당 인스턴스에 생성한 Role을 설정합니다.
![](https://tech.cloud.nongshim.co.kr/wp-content/uploads/2021/11/13-1-1024x208.png)
2-3. ebcli를 통한 애플리케이션 및 환경 생성
EC2 인스턴스에 접속해 ebcli를 통해 Elastic Beanstalk 애플리케이션 및 환경을 생성합니다.
1. eb init
‘eb init’ 명령어를 통해 애플리케이션을 생성합니다.
![](https://tech.cloud.nongshim.co.kr/wp-content/uploads/2021/11/Untitled-5.png)
![](https://tech.cloud.nongshim.co.kr/wp-content/uploads/2021/11/캡처.png)
- 리전 선택 ( 도쿄 리전을 선택하였습니다.)
- 애플리케이션 이름 설정 (django-tutorial로 설정하였습니다.)
- 플랫폼 설정 (해당 hands on에서는 python 3.7 버전을 사용하였습니다.)
- CodeCommit 사용 여부 설정 (나중에 GitLab과 연동을 할 것이기 때문에 사용하지 않습니다.)
- SSH 접속 여부 및 keypair 설정 (새로 만들어질 인스턴스에 자신이 가진 key pair를 이용하여 ssh 접속을 할 수 있도록 설정합니다.)
2. eb create
‘eb create’ 명령어를 통해 환경을 생성하고 애플리케이션을 배포합니다.
![](https://tech.cloud.nongshim.co.kr/wp-content/uploads/2021/11/Untitled-7.png)
- 환경 이름 설정 (django-env로 설정하였습니다.)
- DNS CNAME 설정 (공백으로 입력 시 환경 이름을 기준으로 CNAME이 작성됩니다.)
- load balancer type 설정 (application Load Balancer를 선택하였습니다.)
- 스팟 플릿 여부 설정 (스팟 플릿을 사용하지 않습니다.)
3. CNAME 추가
![](https://tech.cloud.nongshim.co.kr/wp-content/uploads/2021/10/Untitled-8.png)
‘eb status’ 명령어를 통해 CNAME을 복사하여 django 프로젝트 내의 settings.py 파일의 ALLOWED_HOSTS에 추가합니다.
![](https://tech.cloud.nongshim.co.kr/wp-content/uploads/2021/10/Untitled-9.png)
추가 후 ‘eb deploy’ 명령어를 통해 수정된 django 프로젝트를 배포합니다.
![](https://tech.cloud.nongshim.co.kr/wp-content/uploads/2021/10/Untitled-10-1024x432.png)
‘django-env.ap-northeast-1.elasticbeanstalk.com’ 해당 url로 접속 후 웹 페이지에 정상적으로 접속이 되는 것을 확인합니다.
2-4 배포 확인
- Elastic Beanstalk
![](https://tech.cloud.nongshim.co.kr/wp-content/uploads/2021/10/Untitled-11-1024x307.png)
- S3
![](https://tech.cloud.nongshim.co.kr/wp-content/uploads/2021/10/Untitled-12-1024x503.png)
새로운 버킷이 생성되며 애플리케이션과 같은 이름으로 폴더가 생성되고 배포할 zip 파일이 업로드됩니다.
코드 수정 후 새로운 버전의 애플리케이션을 배포할 경우 ‘eb deploy’ 명령어를 통해 간단하게 새로운 버전을 배포할 수 있습니다.
다음 포스팅에서 이어서 Jenkins, GitLab, Elastic Beanstalk 를 활용하여 CI/CD 환경을 구축해보도록 하겠습니다.
이상으로 Hands On을 마치겠습니다.
감사합니다.
문의 사항이 있으시면, NDS Sales팀으로 연락 주시길 바랍니다.
cloud.sales@nongshim.co.kr
SA 설재홍