[AWS] AWS Code Series

 

CodeSeries

AWS에서 Developer Tools로 분류가 되어있는 CodeCommit, CodeBuild, CodeDeploy, Codepipeline을 통칭하는 단어이다. CI와 CD를 단계적으로 수행할 수 있도록 적용할 수 있다. 하지만 각 서비스들이 CodeSeries 끼리만 연동되는 것은 아니다. CodeCommit 대신에 S3나 별도 Github을 쓸 수 도있고 CodeBuild 대신에 Jenkins를 쓸 수도 있다.

이외에도 CodeStar의 경우 프로젝트 단위로 개발언어와 배포대상, IAM, Code Pipeline 등을 종합적으로 쓸 수 있는 서비스이다.

 

 

CodeCommit

code series에서 repository를 담당하고 있는 서비스이다. 초기 생성시, 외부의 github, bitbucket 등에서 긁어 오도록 만들 수도 있다. 사용법은 git과 같은 버전관리 툴을 활용하면 된다.

 

git 사용시에는 aws cli에서 제공하는 credential-helper로 접근해야 한다.

git config user.name "Yunsang Jeong"
git config user.email "tbvjehr9999@gmail.com"
git config credential.helper "!aws codecommit credential-helper $@"
git config credential.UseHttpPath true

 

HTTP 403 Error 혹은 별도로 ID, PW를 타이핑을 요구할 시에는, git 설치시에 기본적으로 OS에 맞춰 설정되는 credential helper를 주석처리하고 git config로 설정하면된다. Windows의 경우 manager이고 MAC의 경우 osxkeychain이다.

git config --list --show-origin # Show all config value with config file location.
...
[credential]
#       helper = manager

 

테스트 해보자.

git add --all && git commit -m "First Commit(test)" && git push

EC2 Instance에서 CodeCommit의 소스코드를 가져올때에는 관련된 IAM Role을 만들어서 EC2 Instance에 붙여주면된다.

 

 

CodeBuild

code series에서 build를 담당하는 서비스이다. Codecommit, S3, Github 등의 Repository로 부터 resource를 가져와서 buildspec(yml)으로 정의된 절차대로 build를 진행한다.  

 

build는 별도로 구성된 docker에서 실행되며 docker에 대한 구성은 어느정도 커스텀이 가능하다. 또한, 이 docker가 실행될 VPC와 Subnet, Security group에 대해서도 지정이 가능하다. build의 결과물인 artifacts는 설정에 따라 생성되지 않을 수 있으나, 생성 시에는 지정한 S3로 저장된다. 저장될때 S3에서의 경로, 네임스페이스, 압축여부, 암호화여부 등을 추가적으로 설정할 수 있다.

 

Code Build 프로젝트에서 artifacts를 A라는 S3에 저장하도록 설정했더라도, Code Pipleline을 생성할 때 지정하게 되는 B라는 S3에만 저장된다. 게다가 A와 B를 동일한 S3로 설정하더라도 , pipeline이 생성하는 artifacts는 고정된 디렉토리 구성 및 파일양식(S3 / Pipeline_Name / BuildArtif/ 임의의문자열)이 존재하므로 동일한 S3에 저장된다는 것 말고는 관리적 이점이 없는 것 같다.

 

buildspec은 build project 당 1개만 적용 가능하며 경로 및 파일명을 원하는대로 변경이 가능하다. 이를 통해 하나의 Repository에 buildspec_debug.yml과 buildspec_release.yml를 저장해놓고 build project를 debug용과 release용으로 2개 만들어서 운영이 가능하다.

 

build를 진행할 때 설정으로 buildspec를 over-ride가 가능한데, 이를 통해 debug용 build project에서 buildspec_release.yml를 사용하도록 하는 부적절한 관계를 맺을 수도 있다.

 

buildspec에는 phases에서 각 단계 별로 실행될 쉘 명령어를 기입하면된다. 명령어는 각 라인별로 순차적으로 한 번씩만 실행되며 명령어들이 실행되는 위치는 resource의 루트 디렉토리이다. 명령어를 실행할 때에는 interactive하게 진행되지 않도록 yes | command와 같은 조치가 필요하며 환경변수에 대해서도 생각할 필요가 있다. artifacts는 build작업의 산출물을 지정하면된다. 특정 디렉토리의 파일들을 recursive하게 지정하고 싶으면 **/* 키워드를 이용하면 된다.

# 여기다가 형상관리를 위해 buildspec의 버전넘버를 적으면 안된다... buildspec 포맷에 대한 버전이다.
version: 0.2 

phases:
  install:
    commands:
      - PYTHON=python2 amazon-linux-extras enable nginx1
      - yum clean metadata && yum install -y nginx
  pre_build:
    commands:
      - yes | cp nginx/imys.conf /etc/nginx/conf.d/imys.conf
      - yes | cp nginx/nginx.conf /etc/nginx/nginx.conf
  build:
    commands:
      - nginx -t
  post_build:
    commands:
      - echo Build completed on `date`

artifacts:
  files:
    - 'codebuild/buildspec_web.yml'
    - 'codedeploy_web/**/*'
    - 'static/**/*'
    - 'nginx/imys.config'
    - 'nginx/nginx.config'
    - 'appspec.yml'

 

특정 phases에서 실패를하게 되면 다음 phases는 실행이 되지 않는다. 실패의 기준은 명령어를 실행했을 때 Stderr으로 에러가 출력되면 실패이다. 좋지 않은 방법이지만 2>/dev/null과 같이 처리해버리면 실패할 일은 없어진다.

 

 

CodeDeploy

CodeDeploy는 Application과 Deployment groups으로 구성된다. Application은 배포하고자 하는 대상을 의미하고 다수의 Deployment group을 가질 수 있다. Deployment group은 Deploy 대상이 되며 EC2/On-premises, AWS Lambda, AWS ECS로 총 3가지 유형이며 유형별로 필요한 IAM policy와 config 파일이 달라질 수 있다. 배포를 위해서 EC2의 경우 별도 Agent 설치가 필요하다. Agent는 Ruby로 작성되어 있어서 까봐도 될 것 같다.

 

Agent 설치가 완료된 Instance를 이미지로 만들어서 배포할 경우 제대로 동작하지 않을 수 있다(고 한다). 그러므로 Userdata에 설치를 진행하는 코드를 넣어서 설치해야 한다.

 

구성과정에서 Agent를 이미 설치한 상황에서 IAM을 붙이거나 수정한 경우 Agent를 재시작해줘야 적용된다.

 

배포타입(전략; Deployment type)은 In-Place와 Blue/Green 두 가지를 지원한다.

 

In-Place

배포 대상인 인스턴스 그룹을 중지시키고 배포를 끝낸 이후에 다시 시작시킨다. 10개의 인스턴스에 배포했을 때, 1개라도 성공하면 성공으로 간주된다.

 

Blue/Green

Blue/Green의 경우 배포대상과 동일하게 환경을 구축한 이후, 배포하고 기존의 것을 삭제하는 절차로 진행된다.

 

Step 1 : Provisioning replacement instances
Step 2 : Installing application on replacement instances
Step 3 : Rerouting traffic to replacement instances
Step 4 : Terminating original instances

 

이 과정에서 In-Place보다 더 많은 Policy를 요구한다.

> iam:PassRole, ec2:CreateTags, ec2:RunInstances,