EB 정복하기 - 1

EB 정복하기 - 2

EB 정복하기 - 3

EB 정복하기 - 4

EB 정복하기 - 5

EB 정복하기 - 6

EB 정복하기 - 7

 

Github Action, CodePipeline 비교

 

CodePipeline CI/CD를 구현해 보기 앞서 Github Action과 비교해 보자.

 

1. Trigger

Github Action: workflow.yaml 파일 기준으로 merge시 동작

CodePipeline: CodeStar로 Github 레포지토리와 브랜치 연결 merge시 동작

 

workflow 파일에서 on: push: branches와 마찬가지로 CodePipeline에서도 특정 브랜치를 지정할 수 있다.

물론 다른 방법도 있지만, 자동화하기에 좋은 방법이라고 생각한다.

 

2. Build

 

Github Action: workflow.yaml 파일 작성한 대로, Github Action Machine에서 동작

CodePipeline: buildspec.yaml 파일 작성한대로, CodeBuild 인스턴스에서 동작

 

Github Action Machine -> CodeBuild 인스턴스로 변경된다.

 

장점은 CodeBuild는 VPC 설정을 할 수 있고, AccessKey 설정을 하지 않고, Role 부여를 통해서 권한 관리를 할 수 있다.

AccessKey를 외부에 저장하지 않기에, 보안상 이점을 가져갈 수 있다. 

 

3. Deploy

 

Github Action: einaregilsson/beanstalk-deploy@v22 모듈을 사용

CodePipeline: Codebuild에서 AWS CLI사용

 

Github Action은 einaregilsson/beanstalk-deploy@v22에 필요한 인자만 넘겨서 처리할 수 있지만, AccessKey 보안 인증이 필요하다.

 

CodeBuild에서 AWS CLI를 직접 적용한다. Role에 정책을 추가해 주면 돼서, AccessKey가 필요 없다.

 

CodePipeline 구성

 

 

CodePipeline에 들어가서 파이프라인 생성을 시작한다. 

 

이름 설정과 파이프라인 유형, 실행 모드를 선택해 준다.

 

실행 모드는 각자의 환경에 맞게 구성하면 된다.

새 서비스 역할을 생성해 주는데, 최소 권한은 필요한 것들만 선택해서 나중에 수정하면 된다.

 

 

Gitbub를 기준으로 Trigger를 선택해야 하기에, Source는 Github Version2를 선택해 준다. 

 



Github 연결을 선택하고, 연결을 진행한다. 연결을 완료하면 레포지토리와 기준 브랜치를 설정해 준다. 

 

 

AWS 측에서 제공해 주는 Amazon Linux Standard5.0 버전을 선택한다. 

 

 

VPC는 선택해 주는 게 가장 좋지만, 예제에서는 선택하지 않겠다. 만약 Private Subnet을 선택한 경우 Nat Gateway가 필요하다.

Codebuild에서 쓰일 환경 변수를 기입해 준다. 

 

 

Codebuild 내에서 buildspec.yaml을 작성할 수 있고, 프로젝트에 생성하고 위치를 지정해 줄 수 있다. 나는 ROOT위치에 buildspec.yaml을 생성해 줬다.

 

 

생성했다면, CodeBuild를 Build Stage로 넣어준다. 

IAM 수정

 

Codebuild Role -> ECR, S3 정책 주기 (이전에 만든 github-action-deploy 유저의 ECR, S3 권한 복사)

ElasticBeanstalk CLI를 직접 사용해야 하기에, AdministratorAccess-AWSElasticBeanstalk 관리형 정책을 넣어준다. 

 

 

BuildSpec.yaml

 

version: 0.2

phases:

  pre_build:
    commands:
      - aws ecr get-login-password --region $REGION | docker login --username AWS --password-stdin $AWS_ECR_URL
      - NOW=$(date +%Y-%m-%d-%H:%M:%S)

  build:
    commands:
      - chmod +x ./gradlew
      - ./gradlew clean build -x test
      - |
        echo '{
          "AWSEBDockerrunVersion": "1",
          "Image": {
            "Name": "'"${AWS_ECR_URL}/elastic-beanstalk:latest"'",
            "Update": "true"
          },
          "Ports": [
            {
              "ContainerPort": "8080",
              "HostPort": "80"
            }
          ]
        }' > Dockerrun.aws.json

  post_build:
    commands:
      - docker build -t $AWS_ECR_URL/elastic-beanstalk:latest .
      - docker push $AWS_ECR_URL/elastic-beanstalk:latest
      - mkdir -p deploy
      - cp Dockerrun.aws.json deploy/Dockerrun.aws.json
      - cp -r .ebextensions deploy/.ebextensions
      - cd deploy && zip -r deploy.zip .
      - aws s3 cp deploy.zip s3://elastic-beanstalk-deploy-zip/deploy.zip-${NOW}
      - aws elasticbeanstalk create-application-version --application-name elastic-beanstalk --version-label ${NOW} --source-bundle S3Bucket="elastic-beanstalk-deploy-zip",S3Key="deploy.zip-${NOW}"
      - aws elasticbeanstalk update-environment --environment-name elastic-beanstalk-dev --version-label ${NOW}

 

Github Action 사용할 때 와 달라진 부분은 직접 AWS CLI를 사용한다는 점이다. 

 

aws elasticbeanstalk CLI를 이용해서 배포 플로우가 진행된다.

 

1. S3에 deploy.zip 생성

2. 애플리케이션 버전 생성

3. 환경을 애플리케이션 버전으로 업데이트

 

그렇다면 자동으로 배포가 완료될 것이다. 

 

CodePipeline Deploy Stage에서 ElasticBeanstalk을 직접 지정해 줄 수 있지만, 출력되는 아티팩트 관리와 같은 다른 부분을 신경 써줘야 해서 나는 AWS CLI로 codebuild 단계에서 처리하는 게 더 편한 거 같다.

 

다음은 Elastic Beanstalk 고급 활용법으로, .ebextentions 옵션들과 스폿 인스턴스 사용해볼 예정이다.