야 너두 자동 배포 할 수 있어 with AWS CodeDeploy

안녕하세요 !!

오늘은 AWS CodeDeploy + Github Action + EC2 + S3 를 사용해 자동 배포를 구현한 경험을 공유하려고 합니다.

 

들어가기에 앞서, 저는 devOps 생초보이므로 중간에 어색하거나 쓸모 없는 로직이 포함되어 있을 수 있습니다 :( 

만약 수정이 필요한 내용이 있다면 댓글이나 jong951005@gmail.com 으로 메일을 보내주시면 감사하겠습니다!!

 

글의 내용은 AWS CodeDeploy에 대한 간단한 설명과 구현 순서로 이루어집니다.

 

AWS CodeDeploy 가 뭐지...??

 

AWS CodeDeploy는 EC2 / on-premises 인스턴스들, ECS, serverless lambda function 등 여러 서비스 애플리케이션 배포를 자동화하는 서비스입니다. 자세한 설명은 공식 문서에 정리되어있습니다.

 

해당 2분짜리 영상을 보시면 빠르게 컨셉을 이해할 수 있습니다.

AWS CodeDeploy는 여러 장점이 있지만, 크게 4가지 설명을 할 수 있을 것 같습니다.

 

1. 배포 진행 상황을 모니터링 할 수 있습니다. 저는 인프라 초보이기 때문에 수행하는 과정에서 발생하는 많은 오류에 대한 로그가 필요했고, CodeDeploy에서 제공하는 console 이 큰 도움이 됐습니다. 이와 관련해 본문에서 설명하도록 하겠습니다.

2. (거의) 무료다!! 우리는 EC2에서 CodeDeploy를 사용할 것이므로 배포를 하는데 추가 비용이 들지 않습니다. 다만 저희의 배포 과정에서는 하나의 파일을 S3에 업로드 하고 이에 따른 비용을 지불해야 하는데, 이와 관련한 약간의 비용이 나갈 수는 있겠네요 :)

 

공짜조아

 

3. 가동 중지 시간을 최소화 시킬 수 있습니다. 공식 문서에 따르면 blue / green 배포 과정에서 거의 즉시 트래픽을 리다이렉션 시켜준다고 합니다. 즉, 새 애플리케이션 버전 변경으로 인한 중단을 최소화합니다. 자동 배포 과정에서 잠깐이나마 서비스가 죽는 것을 원하지 않는다면, CodeDeploy에서 blue / green 배포 설정을 해줄 수 있습니다.

 

4. 동시 배포를 할 수 있습니다. 하나 이상의 EC2 컴퓨팅 플랫폼을 사용하는 애플리케이션에 배포가 필요할 경우, CodeDeploy를 사용하면 큰 효과를 보실 것으로 예상됩니다! 

 

Blue-Green은 또 뭐야...?

 

 

Blue-Green deployment는 배포 전략 중 하나입니다. 라이브 환경을 Blue 라고 지칭하며 새로운 환경은 Green 이라고 지칭합니다. 새로운 배포는 Green 환경에서 수행되며, 에러 검출이 되지 않을 경우 traffic을 Green 으로 옮깁니다.

 

가장 큰 장점은 downtime이 없다는 것입니다!! 배포 중에도 애플리케이션이 실행중이므로 사용자는 배포가 진행되었다는 사실을 거의 알 수 없습니다.

 

설명은 여기까지하고, 자동 배포를 위해 작업했던 순서에 대해 설명하겠습니다 :)

 

---

작업 순서

수행할 작업의 순서는 아래와 같습니다.

 

1. CodeDeploy 사용을 위한 EC2 IAM 인스턴스 프로파일 생성

2. EC2에 CodeDeploy agent 설치

3. CodeDeploy 애플리케이션 생성

4. Github Action workflow 를 위한 yml 파일 생성 

5. CodeDeploy Action을 위한 appspec.yml, script 파일 추가

 

 

1. CodeDeploy 사용을 위한 EC2 IAM 인스턴스 프로파일 생성

우리는 배포 대상이 될 EC2 인스턴스가 CodeDeploy를 사용할 수 있도록 권한을 부여해야 합니다!!

 

우선, AWS IAM에 들어오셔서 역할 만들기를 클릭합니다.

 

EC2를 클릭하시고 S3, CodeDeploy 모든 권한을 넣어주고, 네이밍을 붙여 역할을 만들어줍니다.

우리는 배포 코드를 압축해서 s3에 업로드하고, 해당 빌드 파일을 CodeDeploy를 통해 EC2로 배포할 것이기 때문에 두 권한을 부여하는 것입니다. 자세한 설명은 아래에서 하도록 할게요!

 

이제 만든 IAM Role을 우리의 인스턴스에 붙여줘야 합니다. 인스턴스 목록에서 체크하시고 작업, 보안 탭을 들어가시면 IAM 역할을 수정해주시면 우리의 EC2는 S3, CodeDeploy 에 대한 접근 권한을 부여받게 됩니다.

 

 

 

2. EC2 에 CodeDeploy agent 설치

배포를 원하는 인스턴스에 CodeDeploy agent를 설치하여 해당 인스턴스를 배포에서 사용할 수 있도록 설정해야 합니다!!

 

해당 명령어를 입력해주세요.

 

위의 명령어에 대한 자세한 설명은 링크를 참조해주세요 :)

 

sudo service codedeploy-agent status 명령을 입력하여 에이전트가 실행 중인지 확인할 수 있습니다.

 

 

3. CodeDeploy 애플리케이션 생성

 

자동 배포를 위한 메인 서비스인 CodeDeploy 애플리케이션을 만들어줘야 합니다!!

 

CodeDeploy에서는 배포 EC2 인스턴스를 식별하기 위한 EC2 식별자와, CodeDeploy 권한이 있는 IAM 인스턴스 프로파일이 필요합니다. 각 설정을 해주고 옵니다.

 

EC2 Name 태깅을 하고, IAM CodeDeploy 사용 사례를 선택하여 IAM 인스턴스 프로파일을 만듭니다.

 

 

이제 CodeDeploy 애플리케이션 설정을 해보죠! 우리는 EC2를 사용하는 CodeDeploy를 하게 되므로, 컴퓨팅 플랫폼을 EC2/온프레미스로 지정합니다. 컴퓨팅 플랫폼에 대한 자세한 설명은 해당 링크를 참조해주세요.

 

배포를 위해서 우리는 배포 그룹을 생성해야 합니다.

배포 그룹에는 배포 대상 인스턴스를 포함하게 되며, 해당 그룹 내에서 우리의 배포 작업이 실행되게 됩니다.

 

배포 그룹 이름을 만드시고, 서비스 역할에 조금 전 만든 CodeDeploy 권한이 있는 IAM 인스턴스를 연결해줍니다.

저희 팀은 배포 유형을 현재 위치로 설정하였지만, 배포 간에 발생할 수 있는 downtime을 원하시지 않는다면 블루/그린 설정을 하시면 됩니다.

환경 구성 탭에서 우리가 태깅했던 EC2 인스턴스를 추가해주고,

저희 팀은 여러 인스턴스를 사용하지 않기 때문에 배포 설정은 OneAtATime으로 하였습니다. 배포 설정 관련한 자세한 설명은 해당 링크를 참고바랍니다.

마지막으로 저희 팀은 로드 밸런서를 사용하지 않기 때문에 해당 옵션을 꺼줬습니다.

 

 

 

4. Github Action workflow를 위한 yml 파일 생성

 

저희 팀은 Github Action을 사용하여 repository main 브랜치에 merge 될때마다 workflow가 트리거 되도록 설정하였습니다.

 

workflow는 .github/workflow를 만드셔서 추가해줘도 되고, New workflow를 클릭해서 추가해줄 수도 있습니다.

 

저희 팀이 사용하고 있는 deploy workflow 는 다음과 같습니다.

 

secrets가 어디서 나온 건지에 대한 의문이 있을 텐데, 이는 곧 설명하도록 하겠습니다.

 

저희 레포지토리에서는 client, server 폴더가 있습니다. client 폴더에서는 정적 파일을 빌드 해주고, server 폴더에서는 dependency과 사용할 env 파일을 추가해줍니다.

 

이후, 프로젝트 파일을 압축하기 위해 tar, gzip 으로 압축해줍니다.

tar은 용량 압축 없이 단순히 번들을 해주고, 용량을 압축하기 위해 gzip을 사용합니다. 해당 링크를 참고해주시면 run 의 명령어에 대해 빠른 이해가 될 것입니다! (-cpzvf...)

tar, gzip 파일 압축

이후 AWS 인증을 해줍니다. secrets은 곧 설명할게요!!

 

다음으로 우리가 만든 압축 파일을 S3에 업로드 해주어야 합니다. 저희 팀은 빌드 압축 파일을 한 곳에서 관리하기 위해 build/ 폴더를 만들어 해당 폴더 내에 보관중입니다,

 

이후 CodeDeploy에게 deploy 요청을 하게 됩니다.

 

앞서 언급한 secrets는 Github 레포지토리의 settings - secrets 에서 설정할 수 있습니다. 

 

 

 

5. CodeDeploy Action을 위한 appspec.yml, script 파일 추가

 

정신이 없죠... 이제 얼마 안남았습니다!!

 

현 작업 상황으로도 CodeDeploy 요청이 들어 갈겁니다!! 다만 CodeDeploy console 창을 보면 다음과 같은 에러가 나있을 겁니다.

 

띠요옹

 

에러 로그를 보시면, appspec.yml 파일이 없어서 생기는 문제임을 알 수 있습니다.

CodeDeploy가 어떤 시나리오로 동작할지 AppSpec 파일을 통해 결정되므로, tar 파일에 우리는 appspec.yml을 넣어줘야 합니다!!

 

루트 디렉토리에 appspec.yml을 파일을 만들어 다음과 같은 내용을 넣어줍니다. 

hooks 를 주의깊게 봐야 할 필요가 있습니다!! 

AppSpec에서는 배포 수명 주기 이벤트 중에 AWSLambda 훅을 한번씩 실행하게 됩니다. 해당 링크를 참고해주세요!

각 훅이 실행되는 과정은 CodeDeploy 콘솔에서 View events를 클릭하시면 확인할 수 있습니다.

 

저희 팀은 이 중 BeforeInstall, AfterInstall 을 사용합니다.

각각의 shell 파일은 루트 폴더에 scripts 폴더를 만들어서 정의했습니다. 내용은 다음과 같습니다.

왼쪽부터 script 폴더 위치, before-deploy.sh, after-deploy.sh

 

시나리오는 팀마다 맞게 수정해서 사용하시면 됩니다 :)

 

---

마무리

자동 배포에 대한 이해도가 전혀 없어 처음에 흐름을 익히는데 무진장 애를 먹었습니다 ㅜ ㅜ

그러나 여러 레퍼런스를 참고하며 천천히 이해가 됐고, devOps 관련한 이해도도 많이 늘은 것 같습니다 :)

추후엔 다른 방식으로 자동 배포를 구현해 보고 싶네요!

 

 

참고

What is CodeDeploy? - AWS CodeDeploy

 

Github Actions + CodeDeploy + EC2 자동배포하기

 

Understanding Blue-Green Deployments in AWS

 

[리눅스/명령어] tar 구조와 사용방법