10. 비교를 위한 동일 환경
• create-react-app 기본 환경
• dockerfile
• Elastic Beanstalk 도커 플랫폼
11. 환경 구축
1. 레포지토리 생성
2. Git 연결 (HTTPS를 이용하면 Github와 동일)
Code Commit
12. 환경 구축
1. 빌드 프로젝트 생성
2. Buildspec.yml 파일 생성 후 레포지토리에 추가
Code Build
13. 환경 구축
• 소스 공급자: 소스를 받을 주체 (여기선 CodeCommit)
• 레포지토리: 생성한 레포지토리
• 참조 유형: 소스 참조 유형 선택
14. 환경 구축
• 환경 이미지: Codebuild 관리 이미지와 도커 이미지 중 선택
• 환경: Ubuntu: aws/codebuild/standard:4.0 버전
(다른 버전 사용시 오류 多)
• 권한: Code build를 통해서 도커 이미지 빌드시 필요한 권한
15. 환경 구축
• 서비스 역할: 역할 지정
• Buildspec: 빌드시 필요한 명령을 저장하는 파일
16. 환경 구축
# buildspec.yml
Version: 0.2
phases:
pre_build:
commands:
- echo Logging in to Amazon ECR...
- aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com
build:
commands:
- echo Build started on `date`
- echo Building the Docker image...
- docker build -t $IMAGE_REPO_NAME:$IMAGE_TAG .
- docker tag $IMAGE_REPO_NAME:$IMAGE_TAG $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$IMAGE_REPO_NAME:$IMAGE_TAG
post_build:
commands:
- echo Build completed on `date`
- echo Pushing the Docker image...
- docker push $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$IMAGE_REPO_NAME:$IMAGE_TAG
• 나중에 생성할 AWS ECR 레포지토리의 내용과 IAM 계정의 정보, 소스와 함께 있는 Dockerfile,
저장될 컨테이너의 위치를 작성해야 Codebuild시 해당 설정을 통해 ECR에 docker 이미지를 생성합니다.
17. 환경 구축
Elastic Container Registry
(ECR)
1. 레포지토리 생성
2. Buildspec.yml 파일 ECR 설정 부분 채우기
https://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/sample-docker.html#sample-docker-docker-hub
18. 환경 구축
• 푸시 명령 보기를 통해서 AWS CLI 인증, 도커 이미
지 build & tag, push 명령을 Buildspec.yml 파일에
지정
19. 환경 구축
Elastic Beanstalk
1. 어플리케이션 및 환경 생성
2. Dockerrun.aws.json 파일 작성
https://docs.aws.amazon.com/ko_kr/elasticbeanstalk/latest/dg/single-container-docker-configuration.html
https://docs.aws.amazon.com/ko_kr/elasticbeanstalk/latest/dg/create_deploy_docker_v2config.html
20. 환경 구축
• Elastic beanstalk에서 Docker 이미지를 통한
배포를 위해 플랫폼을 Docker로 지정하며,
Linux2가 아닌 Linux로 지정해야 버전 오류가 없다.
21. 환경 구축
// dockerrun.aws.json
{
"AWSEBDockerrunVersion": 1,
"containerDefinitions": [
{
"name": "web_container",
"image": "089802069060.dkr.ecr.us-east-1.amazonaws.com/web_container:latest"
}
]
}
• Dockercompose를 사용하지 않는 경우에는 꼭 작성해야 하는 설정 파일
• v1: 도커 컨테이너
• v2: 멀티 컨테이너
• v3: 프라이빗 레포지토리 사용하여 S3 버킷 이용
31. 비교 배포 테스트
• 소스: 즉시
• 대기: 약 10분
• 빌드: 약 2분
• 배포: 약 8분
• 결과:
32. 비교 결과
• 소요시간 비교
비교군 AWS DevOps 비교 환경
소스 즉시 즉시
빌드 약 3분 약 2분
배포 약 6분 약 8분
• 언뜻 보면 비슷한 수치이나, Travis CI의 경우 빌드를 위한 Travis Queue에 들어가는 시간이
약 10분 소요되어 총 약 20분 소요
• 따라서 Travis CI의 Queue가 대기 중이면 비슷한 성능
• 허나, 대부분 Queue 진입시간은 약 10분 소요
33. 비교 결과
• 설정 필요한 파일
비교군 AWS DevOps 비교 환경
dockerfile O O
dockerrun.aws.json O X
.travis.yml X O
buildspec.yml O X
• AWS 개발자 도구를 사용한 배포는 유기적인 연결을 위해 여러 설정파일이 필요함
• 그에 반해 Travis CI를 사용한 배포는 Travis CI 설정 파일만 필요
34. 비교 결과
• 과정 시각화
비교군 AWS DevOps 비교 환경
소스 O O
빌드 O O
배포 O X
• AWS DevOps로 배포시엔 모든 과정이 시각화로 오류 부분을 바로 체크 가능
• Travis CI는 빌드까지 시각화 되어있지만 배포는 Elastic Beanstalk에서 이뤄지므로
배포까지 책임지지 않음
35. 결론
• 설정하는 시간은 AWS DevOps가 더 소요되며 체크 해야 할 부분이 많다.
• Commit 이후 배포까지의 속도는 AWS DevOps가 더 빠르다.
• 에러 검출과 시각화의 경우 AWS DevOps가 더 편리하다.
• Travis CI의 경우에는 무료인 만큼 속도가 느리나, 설정이 편리하다.
• 프로젝트가 AWS 다른 서비스와 접목이 이뤄지거나, 유지보수에 중점을 준다면
AWS DevOps를 사용하는 것이 장기적으로 도움이 된다.
