AWS CodeDeploy
이전 글을 통해서 GitHub Actions를 하는 방법과 현재 프로젝트에 어떻게 적용했는지 알아보았다.
지금부터는 AWS CodeDeploy를 통해서 어떻게 EC2로 프로젝트를 배포할 것인지 살펴보자.
AWS CodeDeploy
AWS CodeDeploy는 EC2, 온프레미스 인스턴스, Lambda 함수, ECS 등 여러 서비스로 애플리케이션 배포를 자동화하는 배포 서비스라고 설명해 준다.
배포할 수 있는 리소스들을 살펴보면 아래와 같이 있다.
- 코드
- 서버리스 함수
- 웹 및 구성 파일
- Executables
- 패키지
- 스크립트
- 멀티미디어 파일
배포할 수 있는 여러 리소스들 중에서 패키지와 스크립트를 배포할 예정이다.
AWS CodeDeploy의 이점
공식 문서를 살펴보면 CodeDeploy가 가지는 여러 이점들이 있지만 그중에서 중요하다고 생각되는 3가지를 알아보자.
1. 서버, 서버리스 및 컨테이너 애플리케이션 배포가 가능
프로젝트를 개발하다 보면 일반적인 서버만 쓰는 게 아니라 서버리스나 컨테이너 등 여러 가지 종류의 서비스를 사용할 수 있다. 예를 들어 내가 지금 개발하고 있는 프로젝트는 당장은 서버만 필요할 수 있으나 서비스가 확장되면 상황에 맞는 다른 서비스가 필요할 수도 있다. 이러한 경우에서 CodeDeploy는 일반적인 EC2 인스턴스나 Lambda 함수, ECS 등 여러 종류의 애플리케이션을 배포할 수 있다.
2. 자동 배포
현재 내 프로젝트에서 CI/CD를 구성하기 위해서는 자동 배포가 가능한 서비스가 필요하다. CodeDeploy는 자동 배포를 제공하여 내가 원하는 CI/CD 구성을 할 수 있게 된다.
3. 가동 중지 최소화
자동 배포를 할 때 가장 문제가 되는 점은 기존 프로젝트의 가동이 중지된다는 것이다. 쉽게 말해서 새로운 버전의 프로젝트를 배포한다고 하면 서버에서 돌아가던 기존 프로젝트는 구버전이 되어 종료되고 새로운 버전이 실행된다.
새로운 버전의 프로젝트가 시작되면 서비스가 정상적으로 실행되기까지 일정 시간 소요되고 그에 따라서 사용자가 서비스를 이용하지 못하는 상황이 발생하게 된다.
이러한 점을 해결하기 위해 롤링 업데이트 방식이나 블루/그린 배포 방식을 통해서 무중단 배포를 해야 되는데 CodeDeploy가 해당 배포 방식들을 지원해 준다.
AWS CodeDeploy 배포 흐름
본격적인 배포 과정을 설명하기 전 AWS CodeDeploy의 배포 흐름에 대해서 살펴보자.
1. Create Application
먼저 프로젝트를 배포하려면 CodeDeploy에 애플리케이션을 새로 생성해야 한다.
애플리케이션은 CodeDeploy가 배포 중 올바른 수정, 배포 구성 및 배포 그룹을 참조하기 위해 사용하는 이름 또는 컨테이너이다.
2. Specify deployment group
CodeDeploy 애플리케이션을 생성하고 난 뒤에 배포 그룹을 생성해야 한다.
배포 그룹에서는 어떻게 배포할 것인지 배포 유형과 배포 환경, 배포 설정 등 여러 가지 배포 옵션을 설정한다.
3. Specify deployment configuration
배포 그룹을 생성한 뒤 배포 구성을 지정해 준다.
배포 구성은 CodeDeploy에 대한 설정 혹은 배포 성공 및 실패 조건, 배포해야 할 인스턴스의 수 등을 설정하는 것으로 이전 포스팅을 확인해 보면 Deploy to EC2 부분이다.
- name: Deploy to EC2
run: aws deploy create-deployment
--application-name ${{ secrets.AWS_CD_APPLICATION_NAME }}
--deployment-config-name CodeDeployDefault.AllAtOnce
--deployment-group-name ${{ secrets.AWS_CD_GROUP_NAME }}
--s3-location bucket=${{ secrets.AWS_S3_BUCKET_NAME }},bundleType=zip,key=backend/$GITHUB_SHA.zip
4. Update revision
배포 구성을 완료했으면 그다음으로는 어떤 파일을 배포할 것인지 지정해 준다.
이때 배포할 프로젝트 외에 애플리케이션 사양 파일인 AppSpec 파일도 포함돼야 한다.
- name: Make Zip File
run: |
mkdir ssm-cicd
ls -al
cp ./backend/target/*.jar ./ssm-cicd
cp ./appspec.yml ./ssm-cicd
cp ./scripts/backend-deploy-start.sh ./ssm-cicd
zip -r ./$GITHUB_SHA.zip ./ssm-cicd
이전에 작성했던 GitHub Actions를 보면 .jar 파일과 appspec.yml파일, backend-deploy-start.sh(빌드 스크립트)를 하나의 zip 파일로 압축한 것을 확인할 수 있다.
5. Deploy
이전에 만든 배포 파일을 실제 배포하는 과정으로 AWS S3 또는 GitHub에 배포 파일을 복사한다.
복사가 완료되면 CodeDeploy 에이전트가 해당 파일을 번들링 하고 AppSpec 파일을 사용하여 파일을 지정된 위치에 복사한 다음 배포 스크립트를 실행한다.
6. Check results
AWS CodeDeploy 페이지에서 배포 결과를 확인한다.
7. Redeploy as needed
프로젝트 배포가 실패해서 수정하거나 배포 스크립트를 변경하는 경우 다시 배포를 진행한다.
더 자세한 내용은 공식 홈페이지를 통해서 확인해 보자. 정리가 잘 되어 있어서 이해하기 편하다.
IAM 설정하기
이제 본격적으로 CodeDeploy를 진행하는 과정을 살펴보자.
IAM Role 설정
먼저 IAM에서 역할을 하나 생성해 준다.
AWS 서비스에서 IAM을 클릭하고 액세스 관리 --> 역할로 이동한다.
그다음 역할 생성을 클릭하고 밑의 과정을 진행한다.
1. 어떤 엔티티 유형의 역할을 생성할 것인지 지정해 주는데 EC2에 배포해야 돼서 AWS 서비스를 선택해 준다.
2. 사용 사례에서는 AWS 서비스 중에서 어떤 서비스인지 선택하는 곳으로 EC2를 선택해 준다.
3. 선택한 서비스에 대한 사용 사례를 선택하는데 다른 사례 필요 없이 그냥 EC2를 선택해 준다.
4. 다음 단계에서는 지금 만드는 역할에 어떤 권한을 부여할 것인지 선택하는 곳으로 프로젝트를 S3에 업로드하고, CodeDeploy가 해당 프로젝트를 EC2에 배포해야 되기 때문에 AWSCodeDeployFullAccess와 AmazonS3FullAccess를 추가해 준다.
5. 추가가 완료되면 다음으로 넘어가준다.
6. 다음으로는 생성할 역할의 이름을 지정해 준다.
7. 처음에 내가 선택한 엔티티가 맞는지 잘 확인한다.
8. 마지막으로 이전에 선택한 권한이 잘 추가되었는지 확인한다.
IAM User 설정
역할을 새로 생성했다면 이제 IAM에 User를 생성해야 한다.
1. 생성할 사용자 이름을 지정해 준다.
2. 이름을 지정했으면 다음으로 넘어간다.
1. 생성할 사용자의 권한을 추가해야 되는데 직접 정책 연결을 선택하여 내가 원하는 권한을 찾아 추가하도록 한다.
2. EC2에 배포할 계획이니 AWSCodeDeployFullAccess를 추가해 준다.
3. 권한 추가가 완료되면 다음으로 넘어간다.
마지막으로 내가 추가한 권한이 정상적으로 추가되었는지 확인하고 사용자를 생성을 클릭해 준다.
EC2 생성
이제 프로젝트를 배포할 EC2를 새로 생성해 보자.
EC2를 생성하는 방법은 밑의 글을 참고해서 생성하면 되고 기준은 프리티어로 한다.
EC2를 생성할 때 바로 생성하지 말고 밑의 사진을 참고해서 고급 세부 정보를 꼭 확인해서 IAM 역할을 선택하고 생성해야 한다.
EC2 생성하기 전까지 왔다면 고급 세부 정보에서 전에 만든 IAM 역할을 선택해 주고 생성해 주면 된다.
혹시나 역할 추가 없이 그냥 EC2를 생성했다면 EC2 관리 페이지에서 작업을 클릭하고 보안 --> IAM 역할 수정에 들어가서 추가해 주면 되니 당황하지 말자.
에이전트 설치
EC2 생성이 완료되면 ssh 클라이언트로 접속하여 CodeDeploy의 에이전트를 설치해야 한다.
위의 공식문서를 참고해서 자신이 선택한 OS 버전에 맞게 설치를 진행하면 된다.
1. sudo service codedeploy-agent start
2. sudo service codedeploy-agent status
설치가 완료되면 start 명령어로 에이전트를 실행시켜 주고 status 명령어를 통해서 agent가 정상적으로 실행되고 있는지 확인한다.
S3 생성
배포 파일을 업로드할 S3 버킷을 새로 생성해 준다.
밑의 글을 참고해서 버킷을 생성하면 된다.
AWS CodeDeploy 설정
이제 AWS CodeDeploy에서 배포를 위한 애플리케이션 생성과 배포 그룹 생성을 시작해 보자.
IAM Role 설정
먼저 애플리케이션을 생성하기 전 IAM 역할을 하나 생성해줘야 한다.
1. 엔티티 유형으로 AWS 서비스를 선택한다.
2. 서비스는 CodeDeploy를 선택하고 사용 사례는 EC2에 배포해야 되니 그냥 CodeDeploy를 선택한다.
1. 그다음으로는 역할에 권한을 추가해 주는데 AWSCodeDeployRole을 추가해 준다.
2. 권한 추가가 완료되면 다음을 클릭해서 넘어간다.
1. 새로 생성할 역할의 이름을 지정해 준다.
2. 처음 내가 선택했던 AWS 서비스가 맞는지 확인한다.
3. 내가 선택한 권한이 맞는지 확인하고 역할을 생성한다.
애플리케이션 생성
역할 생성이 완료되면 이제 배포에 필요한 애플리케이션과 배포 그룹을 생성해 준다.
1. 먼저 서비스에서 CodeDeploy로 이동하여 사이드에 있는 애플리케이션을 선택한다.
2. 우측 상단에 애플리케이션 생성을 클릭한다. (처음 생성하는 거면 애플리케이션에 아무것도 없음)
1. 애플리케이션 구성에서 애플리케이션 이름을 지정해 준다.
2. 어떤 서비스에 배포할 것인지 선택을 해주는데 EC2에 배포할 계획이면 EC2/온프레미스로 선택해 준다.
3. 구성 설정이 완료되면 애플리케이션 생성을 클릭하여 생성해 준다.
배포 그룹 생성
애플리케이션 생성이 완료되면 이제 배포 그룹을 생성해줘야 한다.
1. 방금 내가 만든 애플리케이션을 클릭해 준다.
2. 배포 그룹 생성을 클릭하여 배포 그룹 생성 페이지로 넘어간다. (처음 생성하는 거면 아무것도 없음)
1. 먼저 배포 그룹 이름을 지정해 준다.
2. 서비스 역할을 선택해야 되는데 이전에 CodeDeploy 서비스로 생성한 IAM 역할을 선택해 준다.
1. 배포할 대상이 되는 EC2 인스턴스는 따로 블루/그린 배포 방식을 사용하지 않을 예정이라 현재 위치로 선택한다.
2. 환경 구성에서는 Amazon EC2 인스턴스를 선택해 준다.
3. 태그를 구성해줘야 하는데 이전에 생성한 EC2를 살펴보면 Name으로 생성된 태그가 하나 있을 것이다. 그걸 선택해 주면 된다. 위의 설명과 같이 현재는 단일 인스턴스를 사용하기 때문에 태그도 하나만 설정해 주면 된다.
1. 배포 설정에서는 CodeDeployDefault.AllAtOnce를 선택해 주는데 모든 인스턴스에 동시에 배포를 수행하는 옵션으로 가장 빠르지만 배포 중 모든 서비스가 중단될 수 있다는 문제가 있다. 하지만 지금은 단일 인스턴스를 사용하기 때문에 AllAtOnce를 선택하였다.
2. 마지막으로 로드 밸런서를 설정해 주는데 해당 옵션을 활성화하면 추가적인 비용이 들 수 있어서 비활성화했다.
3. 설정이 모두 완료되면 배포 그룹 생성을 클릭하여 생성해 준다.
백엔드 배포
이전 포스팅에서 진행했던 GitHubActios와 이번에 AWS CodeDeploy 구성까지 완료되었다면 이제 IDE에서 프로젝트를 자신이 설정한 브랜치로 push 하면 자동으로 배포되는 것을 확인할 수 있다.
프론트엔드 배포 구성이 따로 없는 건 S3에만 업로드하여 정적 웹 사이트 호스팅을 구성했기 때문이다.
따라서 EC2에는 백엔드 프로젝트만 돌아가기 때문에 백엔드만 AWS CodeDeploy로 구성하였다.
다음 계획
이제 본격적인 CI/CD 구성까지 완료했다.
지금 계획하고 있는 건 특정 기능을 MSA로 분리하여 AWS Lambda에 함수로 등록시킬 생각이다.
특정 기능은 아마 프로필 이미지가 될 예정인데 파이썬 진영에서 Fast API 프레임워크를 사용하여 해당 기능을 구현해 볼 생각이다.
현재 nGrinder로 프로필 이미지 성능 테스트까지 완료한 상태이고 이제 Fast API를 학습하여 기능을 구현할 계획이다.
다음 포스팅 주제는 nGrinder로 프로필 이미지 기능을 성능 테스트한 과정과 내가 겪었던 삽질(?)을 가지고 작성할 생각이다.
'프로젝트' 카테고리의 다른 글
[SSM_프로젝트] - Spring Cloud Gateway 적용하기 (0) | 2024.06.12 |
---|---|
[SSM_프로젝트] - 프로필 이미지 성능 개선하기 (0) | 2024.06.12 |
[SSM_프로젝트] 다시 처음으로... (0) | 2024.06.03 |
[SSM_프로젝트] - GitHub Actions와 AWS Code Deploy를 활용한 CI/CD 적용 - (1) (0) | 2024.05.21 |
한화 시스템 부트캠프 수료 및 향후 계획 (0) | 2024.05.10 |