배포 자동화

말그대로 배포 자동화란 기존에 배포를 위한 복잡한 작업을
클릭 혹은 명령어 입력을 통해 전체 배포 과정을 자동으로 진행하는 과정이다.

배포 자동화 파이프 라인

파이프 라인이라하면, 이전에 Stream API 공부할 때
들어보았었다. 무언가 연결해준다는 의미를 가지고 있었다.
배포 자동화에서 파이프 라인은 소스 코드의 관리부터 실제 서비스로의
배포 과정을 연결하는 구조를 뜻한다. 파이프라인은 전체 배포 과정을
여러 Stage(단계)로 분리한다. 가장 많이 쓰이는 3가지를 알아보자

image

  • Source 단계 원격 저장소에 관리되고 있는 소스 코드에 변경 사항이 일어날 경우
    이를 감지하고 다음 단계로 전달하는 작업을 수행하는 단계이다.
  • Build 단계 Source 단계에서 전달받은 코드를 컴파일, 빌드, 테스트하여 가공한다.
  • Deploy 단계 Build 단계에서 전달받은 결과물을 실제 서비스에 반영하는 작업을 수행한다.

기본적으로 위와 같이 단계가 있고, 상황과 필요에 따라
더 세분화되거나 간소화될 수 있다.

AWS 개발자 도구 섹션에는 배포 자동화 파이프 라인을
구출할 수 있는 서비스를 제공해준다.

CodeCommit - Source 단계때 구성할때 사용
CodeBuild - Build 단계를 구성할때 사용
CodeDeploy - Deploy 단계를 구성할때 사용
CodePipeline - 각 단계를 연결하는 파이프라인을 구축할때 사용

image

CodeCommit을 제외한 파이프라인 구성이다.
GitHub 레포지포티와 연결하여, 후에 변경사항을 반영했을 경우
배포 과정이 자동으로 진행되는 방식이다.


개발환경 구축

이와 같이 구성을 하기 위해서
EC2 인스턴스에 java,aws-cli,ruby를 설치하여 개발환경을 구축해야한다.

sudo apt update

apt를 업데이트를 먼저 진행한다.


1). Java 설치

sudo apt install openjdk-11-jre-headless


2). AWS CLI 설치

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
sudo apt install unzip
unzip awscliv2.zip
sudo ./aws/install

AWS CLI 공식 문서를 참고하면 동일하게 나온다.
unzip이 설치되어있다면 생략해도 가능하다.

aws --version

설치가 완려되면 버젼확인이 가능하다.


3). CodeDeploy Agent 설치

sudo apt install ruby-full             
sudo apt install wget
cd /home/ubuntu
sudo wget https://aws-codedeploy-ap-northeast-2.s3.ap-northeast-2.amazonaws.com/latest/install
sudo chmod +x ./install
sudo ./install auto > /tmp/logfile

AWS CodeDeploy 공식 문서를 참조하면 확인이 가능하다. wget이 없을 경우 wget 설치.

설치가 완료되면 서비스가 실행중인다 확인할 수 있다.

sudo service codedeploy-agent status

를 입력하였을 경우 active(running)문구를 확인할 수 있다. 만약 확인이 되지 않을 경우

sudo service codedeploy-agent start
sudo service codedeploy-agent stop

start와 stop을 반복하여 확인할 수 있다..


파이프라인 구축

우선 AWS에서 파이프라인을 만들기전에
애플리케이션에서 설정을해줘야하는 정보가 있다.
설정 후 GitHub 레포지토리에 push해 놓으면 후에 파이프라인 구성완료 시
자동으로 EC2로 빌드가 되어진다.

appspec.yml,buildspec.yml파일을 프로젝트 하위폴더로 만들어 설정해 놓아야한다.
AWS CodeDeploy hooks, AWS CodeBuild reference를 참조해 설정이 가능하다.
그에 따른 여러 Script(.sh) 파일도 만들어 줘야한다.


설정을 완료하였다면 AWS측을 설정해보자 우선 IAM 계정을 사용하고 있을 경우
EC2 인스턴스의 IAM 역할 권한을 추가해줘야한다.

image

image

AmazonS3FullAccess
AmazonEC2RoleforAWSCodeDeploy
AWSCodeDeployRole
AmazonSSMFullAccess
정책 생성을 진행 해주면 된다.

그리고 신뢰 관계 정책 설정에서

image

Service의 "codedeploy.ap-northeast-2.amazonaws.com"를 할당해주면 된다.


그 다음엔 CodeDeploy에서 애플리케이션을 생성해주자

image


그리고 CodePipeline에서 파이프라인을 생성해주면 된다.

image

파이프라인을 만들때 Source 단계에서는
GiuHub에 연결해서 사용하면 된다.

이제 파이프라인 구성을 완료하면

image

위와 같이 파이프라인이 실행이 완료된 것을 볼 수 있다.
이제 우리가 Github에 push를 하는 순간

해당 내용이 EC2 인스턴스 서버에 빌드되는게
자동화가 되었다는 사실 !!!

엄청 대단한 기술이다… 물론 알아야할 것도 엄청 많아서 난해했지만
현재는 따라하는 단계만 마친 것 같다.


서버 환경 변수 설정

기존에는 .yml, .properties 파일에 환경변수를
설정하여 파싱해서 가져다 사용했었다.
이제는 EC2에 서버가 배포되어있으니 AWS의 Parameter Store
서비스를 이용하면 환경변수가 쉽게 설정이 가능하다.

우선 EC2에 배포하려는 프로그램에 설정해주자

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

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

build.gradle의 의존관계를 설정해주어야한다.

aws:
  paramstore:
    enabled: true
    prefix: /spring-boot-aws
    name: be-88-MyCatlikesChuru # 리소스 이름을 작성합니다.
    profileSeparator: _

파라미터 스토어에서는 /prefix/name/key의 순서로 네이밍 규칙에
맞게 작성해야한다. name은 EC2 인스턴스이름과 동일하게 설정해주자.

그리고 .yml, .properties에 설정해 주었던
환경변수는 EC2 파라미터 스토어에서 대체되니
삭제하거나 주석처리를 하면 된다.

이제 AWS의 파라미터 스토어에서 파라미터를 생성해주면된다.

image

이름에는 네이밍 규칙을 넣어주면 되고
값에는 우리가 실제로 환경변수를 사용할 값을 넣어주면 된다.

예를들어 mysql을 사용하려는데 username을 설정한다고 가정하면
spring.datasource.username=admin과 같은 형태로 .properties에
사용한다고 가정을 하였을 경우

이름 : /spring-boot-aws/be-88-MyCatlikesChuru/spring.datasource.username
값 : admin
과 같은 형태로 파라미터를 만들어 준다면
우리가 EC2에 정상적으로 배포해둔 서버에 해당 환경변수가 적용될 것이다.


오늘은 이렇게 배포를 자동화하는 기술을 배워보았다.
AWS에서 지원하는 파이프라인 구성을 통해
EC2 인스턴스 빌드가 자동으로 되는 과정을 지켜보았고
이번에 공부하면서 느낀건데… AWS에 대한 깊은 공부가
정말 필요하다고 절실히 느꼈다.

Java와 Spring이 어느정도 익숙해진다면
AWS 공부를 열심히 해볼 생각이다.

오늘 공부는 여기서 끝 !!


오늘의 커피량: ☕️ ☕️
오늘의 점심: 콩나물 김치찌개, 계란야채부침, 밥