[Cloud] 배포 자동화

see1237·2022년 10월 8일

Section4

목록 보기

7/13

소스 코드의 관리부터 실제 서비스로의 배포 과정을 연결하는 구조
파이프라인의 세 단계 (단계는 상황과 필요에 따라 더 세분화되거나 간소화될 수 있음)
1. Source 단계: 원격 저장소에 관리되고 있는 소스 코드에 변경 사항이 일어날 경우, 이를 감지하고 다음 단계로 전달
2. Build 단계: Source 단계에서 전달받은 코드를 컴파일, 빌드, 테스트하여 가공 / Build 단계를 거쳐 생성된 결과물을 다음 단계로 전달
3. Deploy 단계: Build 단계로부터 전달받은 결과물을 실제 서비스에 반영

CodeCommit
- Source 단계를 구성할 때 이용
- GitHub과 유사한 서비스를 제공하는 버전 관리 도구(보안 관련 기능 강점)
CodeBuild
- Build 단계에서 이용
- buildspec.yml
- 유닛 테스트, 컴파일, 빌드와 같은 빌드 단계에서 필수적으로 실행되어야 할 작업들을 명령어를 통해 실행할 수 있다.
CodeDeploy
- Deploy 단계를 구성할 때 이용하는 대표적인 서비스: CodeDeploy와 S3 서비스
- appsepc.yml
- CodeDeploy 서비스를 이용하면 실행되고 있는 서버 애플리케이션에 실시간으로 변경 사항을 전달할 수 있다. 또한 S3 서비스를 통해 S3 버킷을 통해 업로드된 정적 웹 사이트에 변경 사항을 실시간으로 전달하고 반영할 수 있다.
CodePipeline
- 각 단계를 연결하는 파이프라인을 구축

개발환경 구축
1. JAVA 설치
2. AWS CLI 설치
3. CodeDeploy Agent 설치
EC2 인스턴스 역할 부여
1. IAM 역할 권한 추가 → 각 서비스끼리의 접근 허용(결과물끼리의 접근 X)
2. 신뢰 관계(해당 역할을 취할 수 있는 서비스나 사용자를 명시) 추가
파이프라인 구축

💡 appsepc.yml : CodeDeploy-Agent가 인식하는 파일
→ 내부의 파일은 appspec.yml 파일이 구성하고 있는 배포 수명 주기에 따라서 실행된다.

AWS CodeDeploy ⇒ 애플리케이션 생성 ⇒ 생성한 애플리케이션의 배포 그룹 생성
AWSCodePipeline ⇒ 파이프라인 생성

💡 CodeDeploy-Agent는 파이프라인 실행 때마다 로그를 해당 EC2 instance에 저장한다.
cd /opt/codedeploy-agent/deployment-root/deployment-logs 에서 로그파일 목록을 확인 후 열어보면 로그를 확인할 수 있다.

레포지토리에서 Pull Request 나 push 같은 이벤트를 트리거로 GitHub 작업 워크플로(Workflow)를 구성할 수 있다. 워크플로는 하나 이상의 작업이 실행되는 자동화 프로세스로, 각 작업은 자체 가상 머신 또는 컨테이너 내부에서 실행된다다.
워크플로는 .yml (혹은 .yaml ) 파일에 의해 구성되며, 테스트, 배포 등 기능에 따라 여러개의 워크플로도 만들 수 있다. 생성된 워크플로는 .github/workflows 디렉토리 이하에 위치.

실습 과정

Gtihub Actions 생성
- gradle.yml 파일 알맞게 생성
  - Github Secret을 이용해 AWS 리소스와 연결을 위한 액세스 키 값을 저장
- push 하면 Github Actions 동작 → 워크플로가 완료되어 S3 버킷에 빌드한 결과물이 전송됨
빌드파일 배포 및 실행
- S3 버킷에 저장된 빌드 결과물을 CodeDeploy를 통해 EC2로 전달
  - CodeDeploy로 애플리케이션, 배포그룹 생성하고 appspec.yml 파일 설정
  - deploy.sh파일 작성 후 이를 토대로 gradle.yml에 배포 명령 추가하여 push → Github Actions 실행됨
배포 결과 및 로그 확인
- EC2 인스턴스로 퍼블릿 DNS로 접속하여 접근이 가능한지 확인
- 생성된 로그파일로 로그읽기