ECR + EB + Github Action을 사용한 배포

0. 무엇을 기록하는가?

배포 자동화를 구성하며 어려웠던 내용 + 대략적인 과정 기록 + 잡담

---

배포 자동화 기술 선택에 고려한 점

1. 앞으로도 개인 서비스에 꾸준히 사용할 것 같은 스택
2. 현업에서도 사용하는 기술인가?
3. 가성비 기술

처음에는 ECS + ECR을 생각했다.
멀티 컨테이너도 아니고 당장에 사용할 일은 없다 생각하여 ECS는 넘어간다.

EB가 좋을 것같다.
배포와 부하 관리도 편하게 처리하고 작은 회사에서는 메인 기술로 사용한다.

되도록이면 컨테이너로 서비스한다.
로컬 환경에서 사용되는 애플리케이션 서버와 인프라 모두 컨테이너에 올려서 사용했다.
여건이 된다면 환경을 통일시키는게 좋다.
(가상화를 사용하면 편리한 점이 많아서 겸사 겸사 연습도 할 수있다.)

결론적으로 시작은 Github Action + ECR + EB로 한다.

---

1. ECR (Elastic Container Registry)

https://aws.amazon.com/ko/ecr/

'완전관리형 컨테이너 레지스트리로, 이미지와 아티팩트를 어디서나 쉽게 보관, 관리, 공유 및 배포하도록 지원'

Registry는 '등록', '등기', '기록', '등록소'같은 의미를 가진다.
고로 ECR(Registry)은 이미지 저장소(ECR repository)를 생성하고 관리하는 API을 제공한다.

Docker Hub와 같은 역할인 것 같은데 다른 클라우드 서비스(GCP, Naver Cloud...)로 이사를 생각하면 Docker Hub가 괜찮은 것 같다.
플랫폼 종속적인 것은 별로다.

만들어보기

ECS 대시 보드 좌측에서 ECR 탭으로 들어간다.

저장소는 Private, Public 2개가 존재한다.

private
https://docs.aws.amazon.com/AmazonECR/latest/userguide/Repositories.html
public
https://docs.aws.amazon.com/ko_kr/AmazonECR/latest/public/public-repositories.html

public 저장소를 사용하면 Amazon ECR 공개 갤러리(저장소)에 표시된다.
(ECR에 이미지 제어 권한을 가진 사람만이 푸시할 수 있다.)

https://gallery.ecr.aws/
여기에서 public 저장소에 올린 이미지가 노출된다.
자신의 작업물이 노출되면 안되는 코드라면 private 저장소를 사용하자.
물론 금액적인 차이도 존재한다.

나는 그냥 퍼블릭으로 사용했다.
이제 리포지토리 생성버튼을 누르고 들어가자

얘들은 대시보드가 1~2년만 지나면 변신을 해서 기존 포스팅 자료 참조하기도 쉽지가 않다.
아래 2개 덩어리가 필수 항목이며 나머지는 선택이다.

리포지 토리 이름 'public.ecr.aws/[registry]/[repository]'값을 다른 서비스에서 참조해서 사용한다. (로고는 무시하자)

아래에 콘텐츠 유형같은 것도 있는데 오픈소스처럼 만들 것이라면 검색 필터로 선택해야 하는데
아니라면 무시하자

생성을 완료하면 저장소 리스트에 내역이 보이며 URI 컬럼에 노출되는 값을 앞으로 자주 복사하게 된다.
빌드한 이미지를 push하거나 pull할 때 저 URI를 넣으면 저장소를 참조하게 된다.

2. Github Action

https://docs.github.com/ko/actions

자신의 깃허브 저장소에 들어가보자

Github Repository에 들어가면 상단탭에 Actions에 들어간다.
ecs로 검색해서 Deploy to Amazon ECS를 선택한다.

ECS 관련 스텝은 버리고 ECR만 살려준다.

AWS에서 들고와야 하는 정보는
IAM 사용자의 AccessKey, SecretKey (ECR, EB에 관한 권한이 필요하다.)
사용하는 Region, Registry, Repository 정보가 필요하다.

name: Deploy to Amazon ECS # 원하는 이름 기입!

# workflow 실행 조건을 설정, pull request로도 변경할 수 있다.
on:
  push:
    branches: [ "main" ]

# 환경 변수
env:
  AWS_REGION: MY_AWS_REGION                   
  ECR_REPOSITORY: MY_ECR_REPOSITORY           
             
# 뭐지?
permissions:
  contents: read

# 실제 작업 내역
jobs:
  # deploy job (별칭이다.)
  deploy:
    name: Deploy
    # job을 수행하는 OS
    runs-on: ubuntu-latest
    environment: production

    steps:
    # 코드 저장소의 코드를 내려받는다.
    - name: Checkout
      uses: actions/checkout@v3

	# aws 자격 증명 구성
    - name: Configure AWS credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: ${{ env.AWS_REGION }}
        
	# ECR Login
    - name: Login to Amazon ECR
      id: login-ecr
      uses: aws-actions/amazon-ecr-login@v1

	# Build Push to ECR
    - name: Build, tag, and push image to Amazon ECR
      id: build-image
      env:
        ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
        IMAGE_TAG: ${{ github.sha }}
      run: |
        # 빌드한 이미지를 ECR에 푸시한다.
        docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
        docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
        echo "image=$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG" >> $GITHUB_OUTPUT

참고1

Push to ECR의 run에 있는 내용은 ECR Repository의 푸시 명령 보기를 참고해도 된다.
docker build, push, tag 명령어 예시가 적혀있다.

참고2

${{ }} prefix github나 steps 같은 것들은 github 자체에서 제공해주는 값이나 다른 step의 id를 참조해서 제공해주는 값을 사용한다. 위에서는 'steps.login-ecr.outputs.registry'이 예시다.
login-ecr id를 가진 step에서 반환하는 값을 사용한다.

$ 달러표시만 있는 것은 workflow에 env의 값을 참조한다.

정확한 정보는 uses의 값을 참조하자.(github repository로 등록)
1. aws-actions/amazon-ecr-login@v1
2. aws-actions/configure-aws-credentials@v1
3. actions/checkout@v3

참고3

${{ }} prefix secret, env는 아래 Environments의 값을 사용한다.

이렇게 작성을 하고 트리거에 맞는 액션(push, pullRequest...)을 하면 아까 만든 ECR Repository 이미지 리스트에서 볼 수 있다.

3. EB (Elastic Beanstalk)

https://aws.amazon.com/ko/elasticbeanstalk/

'웹 애플리케이션 및 서비스의 배포 및 조정을 위한 서비스, 코드를 업로드하면 용량 프로비저닝, 로드 밸런싱, 모니터링, 배포를 모두 자동으로 처리합니다.'

EB 시작을 위한 설정 과정은 다른 블로그에도 많으니깐 내가 정리하고 싶은 내용을 정리하겠다.

EB를 세팅하고 나온 구조를 작성했다.(Router 53은 추가적으로 적용했다.)

1. 로드밸런서, 대상그룹, AutoScailing이 생성된다.
2. 대상그룹의 범위는 로드밸런서의 네트워크 매핑에서 정한다.
3. AutoScailing 범위는 자신의 대시보드에서 정한다.
4. 연관 서비스 설정을 해당 대시보드에 가서 직접 수정하면 관련된 설정까지 직접 수정해야 한다.
   되도록이면 Elastic Beanstalk 대시보드에서 수정하자

https://tech.cloud.nongshim.co.kr/2021/11/01/hands-on-elastic-beanstalk를-사용한-웹-애플리케이션-배포-aws-console/

---

발생한 문제