AWS Elastic Beanstalk - (6)

Elastic Beanstalk에서 환경 분리를 통해 서로 다른 버전의 애플리케이션을 서로 다른 환경에 배포할 수 있다.

- dev, staging, production 등 분리가 가능하다.

--> 즉, 1개의 어플리케이션에 여러개의 환경을 만들고, 그 환경에 자동 배포가 가능하도록, github action, 로드밸런서, 도메인 설정 등을 해주면 되는 것이다.

 

이 글에서는 django 환경분리를 다루지는 않을 것이다.

다른 글에서 한 번 다뤄보겠당

 

---

 

1. 환경 구성

우선 eb create 로 환경을 만들어준다.

AWS Elastic Beanstalk - (6) 번에서 eb create로 환경을 만들어주고 배포하고 로드밸런서, 도메인 설정한 걸 똑같이 만들면 된다.(그럼 도메인이 2개가 되야하는게 맞당)

 

그럼 환경이 2개가 될것이다. 그럼 한 개는 dev server로 사용하고 다른 한 개는 release 서버로 사용하면 된다.

 

그럼 준비는 다 끝났다.

만든 환경만 github action에 넣어주면 된다.(참고로 도커 포트도 바꿔줘야한다. 8000으로 배포했으면 다른 서버는 8001번이든 다른걸로 만들어서 겹치지 않게 해라)

 

2. github action 배포

파일을 2개 만들어준다. 한개는 개발용, 한개는 배포용 github action yml을

 

그리고 워크플로우 구문을 작성한다.

내가 원하는 배포는 이렇다.

 

2-1. Dev 서버

 

main 브런치와 develop 브런치 이외에 푸쉬했을 때만 github action이 작동했으면 좋겠다.

왜냐면 main 브런치는 직접 푸쉬를 하면 안되게 해놨구,

develop 브런치는 개발용이기 때문이다.

 

name: DEV Server Beanstalk Deploy

on:
    push:
        branches:
            - '!main'
            - '!develop'

 

근데, 이렇게 써도 되지만, 좀 더 좋은 방식으로 써보자.

어차피 코드를 develop 브런치에 merge 시켜야한다.

-> develop 브런치에 pull_request 날릴때만 workflow가 작동되게 해주면 된다.

 

 name: DEV Server Beanstalk Deploy

on:
    pull_request:
        types: [opened, reopened]
        branches:
            - develop

이와 같이 리팩토링을 해볼 수 있겠다.

 

추가적으로 작업이 실행되는 시기를 추가로 제어하고 싶어서, pull_request가 열려 있는 동안에만 github action workflow가 작동되게 작성하였다.

 

전체 워크 플로우는 이렇고, 나는 ECR 이미지도 Dev, Release 저장 경로는 나누고 싶어서 나눴고,

EB 환경변수는 Dev, Release 다르게 하고, 어플리케이션 이름은 Dev, Release가 같아야한다.

(어플리케이션 이름도 사실 달라도 2개 환경이 달라도 된다. 그냥 자기 맘이다. 다르게 하고 싶다면 어플리케이션도 2개가 되겠지?)

 

참고로 Dev 서버는 무한 push 를 해도 상관없는 환경으로 해서

IMAGE_TAG: ${{ github.sha }}

 

---

 

2-2. Release 서버

 

이미지 태그명이 commit id이다. -> ECR주소:akwmdawldmawdlk (이렇게 난수로 되어있는거)

 

근데, Relase server는 배포를 버전 V1.0.0 이렇게 관리하는게 대부분이다.

 

그래서 Release server는 살짝 다르다.

 

on:
    push:
        branches:
            - main
        tags:
            - v1.**

버전이 1점대로 관리하고 싶어서 이렇게 하고, v1.*.* 일 때만 푸쉬되게 했다.

 

그럼 태그를 자연스럽게 workflow에서 작동되도록 코드를 살짝 수정해보자.

 

- name: Extract tag name
    id: extract-tag
    run: |
        echo "::set-output name=tag::${GITHUB_REF#refs/tags/}"

- name: Build and push Docker image
    id: build-image
    env:
        ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
        ECR_REPOSITORY: <ECR 레포지토리 이름>
        IMAGE_TAG: ${{ steps.extract-tag.outputs.tag }}

    run: |
        docker buildx build --platform=linux/amd64 -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
        docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
        echo "::set-output name=image::$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG"

이와 같이 id: extract-tag 로 지정해서 tag로 v1.0.0 과 같은 태그를 출력시킵니다.

 

그리고 IMAGE_TAG: ${{ steps.extract-tag.outputs.tag }} 로 해서 image_tag를 사용하는 것이지요.

 

그 외에는 코드가 똑같습니다~

 

 

 

끝!

 

[참고]

https://fe-developers.kakaoent.com/2022/220106-github-actions/

카카오웹툰은 GitHub Actions를 어떻게 사용하고 있을까?

https://docs.github.com/ko/actions/using-workflows/events-that-trigger-workflowshttps://docs.github.com/ko/enterprise-server@3.3/actions/using-workflows/workflow-syntax-for-github-actions#using-activity-types

Events that trigger workflows - GitHub Docs

---

이제 왠만한 설정은 다 끝난것 같은데도 아직도 여러개가 남아있긴 하다.

1. 블루 그린 배포로 무중단 배포하기

-> 왜냐면 배포할 때 최소 3~5분은 걸리기 때문에 이 공백기 동안 서비스가 멈춤 그래서 이걸 방지하고자 함.

 

2. nginx 설정하기

-> 요즘 이미지가 고해상도라서 엄청 사이즈가 큰데, nginx에서 max_image_size_max를 수정해줘야한다.

-> 왜냐하면, 1mb인가로 default가 지정되어 있을 텐데 그럼 핸드폰의 고화질 이미지를 받질 못한다.

-> beanstalk default web server가 nginx 임

-> 따라서 beanstalk config 설정으로 nginx 설정 수정 가능함.

 

이것까지만 하면 보통 초창기 회사에서의 배포 사이클은 끝일 것이다.

 

다음 글도 가보자고~!