2023/02/03 TIL | AWS Pipeline을 통한 배포 자동화

💭 오늘의 학습 전략

# 배포 자동화_AWS Pipeline

◻️ 배포 자동화 파이프라인

　◽Source stage

　◽Build stage

　◽Deploy stage

◻️ AWS Pipeline 서비스

　◽Code Build

　◽Code Deploy

　◽Code Pipeline

◻️ 환경 변수

　◽Parameter Store

◻️ 실습

🌼 학습한 것들

◾ 배포 자동화

　▪️ 한 번의 클릭으로 전체 배포 과정이 실행

　　- 시간 절약

　　- 휴먼 에러 방지

　▪️ 파이프라인

　　- 소스코드 관리~실제 서비스 배포 과정 연결 구조

　　- 전체 배포 과정을 여러 단계로 분리 -> 각 단계 순차 수행

　　- 기본 단계 및 수행 작업

　　  필요에 따라 세분화/간소화되기도 한다.

　　▪️ Source Stage

　　　- 버전 컨트롤 도구를 이용한 소스코드 관리 및 전달

　　　- 원격 저장소 소스코드 변경 감지

　　▪️ Build Stage

　　　- 코드 컴파일링

　　　- 유닛 테스트

　　　- 빌드 결과물 생성

　　▪️ Deploy Stage

　　　- 변경사항 실시간 반영

　　　- 서비스 업데이트

◾ AWS 개발자 도구 서비스 간략 정리

　▪️ Code Commit (Source)

　　- 버전 관리

　　- 보안에 강점

　　- 프리티어 이상 사용 시 과금 주의

　▪️ Code Build (Build)

　　- 빌드 단계에서 수행될 작업들을 명령어 통해 수행

　　- buildspec.yml

　　  codedeploy-agent가 인식

　　  phases.install, build, post_build ... ==> 각 단계에 실행할 동작 특정

　▪️ Code Deploy (Deploy)

　　- 실행 중인 서버에 실시간으로 변경사항 전달

　　- S3 버킷에 업로드된 정적 웹 사이트 실시간 전달, 반영

　　- appspec.yml

　　  codedeploy-agent가 인식

　　  hooks.Before(After)Install, ApplicationStart(Stop) ... ==> 각 단계에 실행할 미리 작성된 쉘 스크립트 지정

　▪️ Code Pipeline

　　- 각 단계를 연결하는 파이프라인 구축

　▪️ Parameter Store

　　- 파라미터 생성

　　- bootstrap.yml 생성: Parameter Store에 저장된 변수 조회

　　- applicaion.properties에는 Parameter Store에 설정한 변수를 적지 않아도 됨

◾ 실습: EC2 인스턴스에서 AWS CLI을 통해 실습 (CodeDeploy Agent)

　▪️ EC2 인스턴스 역할 부여 (권한 정책 연결)

　▪️ buildspec.yml, appspec.yml, sh 작성

　▪️ 파이프라인 구축

　　- CodeDeploy 애플리케이션 생성

　　- CodePipeline 구축

　　  source는 github(버전 2)로 진행

　　  build는 AWS CodeBuild

　　  deploy는 AWS CodeDeploy

🔥 보충이 필요한 것들

◾https://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/reference-appspec-file-structure-hooks.html

💨 하루를 마치며

1. 실습 후기

따라하는데 어려움은 없었다. 다만 Parameter Store를 통해 변수를 설정했을 때는 자꾸 결과 확인에 실패했다.

알고 보니 라이브러리 설정을 제대로 하지 않아서였다😓

Parameter Store를 사용하기 위해서는 아래와 같이 둘 다 추가해주어야 하는데

dependencies {
	implementation 'org.springframework.cloud:spring-cloud-starter-aws-parameter-store-config'
}

dependencyManagement {
	imports {
		mavenBom "org.springframework.cloud:spring-cloud-starter-parent:Hoxton.SR12"
	}
}

dependentcyManagement만 추가해놨다,,

이런 경우에는 파이프라인 상태가 소스, 빌드, 배포 모두 성공이라 codedeploy-agent 로그를 확인해도 별다른 에러가 찍혀있지 않아서 파악하는 데 조금 힘들었던 것 같다.

빌드 산출물을 다 지우고 파이프라인을 돌렸을 때 다시 배포까지 성공하는 걸 미루어 봤을 때 서버 실행에서 문제가 있는 거라고 생각했고, appspec.yml과 ApplicationStart.sh에 별다른 문제가 없다는 걸 확인해서

직접 jar 파일을 실행해보면서 로그를 읽고 파악했다.

역시 환경변수 문제였는데, Parameter Store에는 잘 등록이 되어있는 것 같아서 찾아보다가 위처럼 build.gradle이 제대로 작성되지 않아 생긴 문제라는 걸 파악할 수 있었다.ㅎㅎㅎ🥲

 

무튼 실습을 마치고 느낀 점은 참 편하다는 거였다.

github에 소스코드를 반영하면 저절로 감지해서 build, 배포 그리고 서버 재실행까지 해주니까 말이다.

예전에는 production 소스코드의 jar 파일을 클라우드가 아닌 서버에 직접 올려서 작업했기도 했고

항상 직접 빌드 > ssh 접속으로 산출물 옮기고 > 서버 재실행(sh) 까지 하나하나 해줬어야 했는데.

하지만 개발서버는 gitlab과 jenkins를 연결해두었어서 자동 빌드를 조금은 수월하게 이해할 수 있었던 것 같다.