Share
Sign In
CodeCommit, CodeBuild, CodeDeploy
1. CodeCommit
용량 제약 없이 private repository를 제공하는 완전 관리형 Git이다. 내 계정의 VPC에만 코드를 저장하여 보안과 compliance를 높이고 다른 툴들과 통합이 용이하다.
HTTPS, SSH로 접근한다.
IAM 유저를 만들고 해당 유저의 Git credential로 인증한다.
IAM으로 유저별 권한 제어할 수 있다.
notification, trigger 지원한다.
Trigger를 통해 Lambda와 연결해 자동화 구현 가능하다.
2. CodeBuild
Jenkins 등을 대체하며, 도커 위에서 동작하는 완전 관리형 빌트 툴이다.
개요
보안 서비스(KMS, IAM, VPC, CloudTrail)과 통합 가능하다.
GitHub, CodeCommit 등에서 소스 코드를 가져온다.
명령을 buildspec.yml에 미리 정의할 수 있다.
S3와 CloudWatch Logs에 결과 로그를 저장한다.
buildspec.yml
version: 0.2
env:
...
phases:
install:
runtime-versions:
nodejs: 10
commands:
- command
finally: # 성공 여부와 상관없이 실행
- command
pre_build:
...
artifects:
files:
- location
name: artifect-name환경 변수
printenv 커맨드로 모든 환경 변수를 출력할 수 있다.
$AWS_REIGON 형식으로 CodeBuild에서 제공하는 환경 변수를 가져다 쓸 수 있다.
buildspec.yml이나 콘솔에서 커스텀 환경 변수를 선언할 수 있다.
각 환경 변수값은 PlainText 혹은 SSM Parameter Store에서 읽을 수 있다.
SSM Parameter Store을 환경 변수로 쓸 때, 적합한 IAM 권한이 있어야지만 값을 읽을 수 있다.
아티펙트
빌드하고 난 결과물을 말한다. 빌드별로 S3에 담아둔다.
콘솔 설정 : 어떤 버킷에 저장할 것인가?
files : 어떤 파일들을 압축할 것인가?
name : 어떤 이름으로 저장할 것인가?
# buildspec.yml
...
artifacts:
files:
# - '**/*' # 전체 경로를 나타냄
- target/myapp.jar
name: myapp-$(date +%Y-%m-%d)아래는 CodeBuild Artifacts 설정 중 일부이다.
S3에서 버저닝을 할 것인가?
암호화할 것인가?
압축할 것인가?
Build ID 폴더에 저장할 것인가?
CloudWatch (CW) 통합
CW Logs나 S3에 로그를 기록할 수 있다.
CW Metrics으로 CodeBuild 성공/실패 등 지표 추적하고 Alarm을 설정할 수 있다.
CW Events를 통해 매 시간마다 빌드를 트리거할 수 있다.
CW Events로 CodeBuild의 이벤트를 다른 서비스로 보낼 수 있다.
CodeCommit과 통합
3. CodeDeploy
Ansible, Chef 등을 대체하여 EC2에 자동으로 어플리케이션을 배포하는 완전 관리형 서비스이다.
EC2/On-premise 머신에는 CodeDeploy agent가 설치되어 있어야 한다.
agent는 주기적으로 CodeDeploy를 검사해 배포 여부를 확인하고, 배포 결과를 보고한다.
CodePipeline, Auto Scaling 등과 연동된다.
CloudWatch와 연동이 가능하다.
# 로컬의 프로젝트를 aws에 배포할 때 사용하는 명령어
aws deploy push --application-name <name> \
--s3-location <s3 location to save artifact> \
--ignore-hidden-files \
--region eu-east-1 \
--profile aws-devops배포 그룹
하나의 어플리케이션을 dev, prod 등 다른 환경에 배포해야 할 필요가 있다. 각 배포 그룹마다 각자의 배포 전략을 가지고 있으며, 태그를 통해 배포를 진행할 EC2를 추가한다.
배포 구성
AllAtOnce : 한 번에 모든 인스턴스에 배포
HalfAtATime : 50% 인스턴스를 배포 한 후 다음 50%를 배포
OneAtATime : 한 번에 한 인스턴스에만 배포
Custom : 직접 배포 구성을 만들 수 있다.
배포 타입
In-place : 배포 그룹에 있는 인스턴스에 어플리케이션 배포
Blue/Green : 새로운 인스턴스 그룹을 만들어 배포 후, 기존 그룹을 교체. 온프레미스에서는 불가능하다.
appspec.yml
배포 생명 주기에 따라 실행 명령들을 appspec.yml 파일에 적는다. 각 명령들은 스크립트 파일로 만들어져 실행되어야 한다. 명령에는 CodeDeploy에서 제공하는 환경 변수를 사용할 수 있다.
In-place deployment
ECS deployment
Lambda는 트래픽 허용 전, 후만 있다.
ECS는 도커이기 때문에, Test Traffic을 통해 서비스를 검증한다.
롤백
수동 롤백 : 수동으로 이전 버전을 재배포한다.
자동 롤백 : 배포가 실패하거나, Alarm이 트리거되었을 때 롤백한다.
온프레미스에 배포
온프레미스를 등록하기 위한 방법은 2가지이다.
IAM User : 단일 인스턴스에 유저를 할당한다. 쉬운 방법.
IAM Role : STS 임시 토큰을 사용해 인스턴스에 할당한다. 다수의 인스턴스에 유리하지만 복잡하다.
머신 등록이 되면 해당 온프레미스 머신에 태그를 붙여 EC2 인스턴스처럼 배포 그룹에 등록한다.
Lambda에 배포
Canary : 처음에 약간 트래픽만 새 버전으로 보내고, 정상이면 전부 새 버전으로 보낸다.
Linear : 점진적으로 트래픽을 새 버전으로 보낸다.
All-at-once : 한 번에 모든 트래픽을 새 버전으로 보낸다.
Lambda는 인스턴스를 실행하지 않기 때문에 트래픽을 관리하는 Hook만 존재한다.
