오늘
- AWS 배포 자동화
오늘은 클라우드 배포를 자동으로 해주는 실습을 해 볼 것이다.
배포자동화
배포자동화란?
Pipeline (파이프라인)
소스 코드부터 배포 과정을 연결하는 구조를 말한다.
Source
원격 저장소에 관리되고 있는 소스 코드에 변경 사항이 일어 날 경우, 이를 감지해서 Build 에게 전달.
Build
전달 받은 코드를 컴파일, 빌드, 테스트해서 가공. Deploy 에게 전달한다.
buildspec.yml 파일을 참조하여 작업 진행.
Deploy
전달받은 결과물을 실제 서비스에 반영한다.
appspec.yml 파일 참조하여 작업 진행.
왜 사용하는가?
지난주에 EC2 로 가상의 컴퓨터를 빌려서 S3 로 클라이언트 배포를 한 다음 RDS 로 데이터베이스 까지 연결을 했었다.
그런데 매번 이런식으로 한다면 매우 번거롭고, 비효율적인 방식이 될 것이다.
조금만 수정해도 다시.env 파일 수정하고, 다시 파일 등록하고...
하지만 자동화를 사용하면 이런 생각을 덜 수 있다.
-
수동으로 작업을 수행 할 필요 없이 자동으로 작업을 수행해주므로 생산성이 향상된다.
-
사람이 직접하다보면 에러가 발생 할 가능성도 있는데 그럴 가능성을 낮출 수 있다.
그럼 지난주에 배운 Docker(도커) 와의 차이점은?
Docker
컨테이너 기반 가상화 기술을 사용하는 소프트웨어이다.
컨테이너라는 격리된 환경에서 운영 체제나 버전에 구애받지 않고 실행 결과를 얻을 수 있다.
또, 이미지라는 형태로 패키지를 관리해서 여러대의 서버나 클라우드 인스턴스에서 쉽게 소프트웨어 배포, 관리를 할 수 있다.
클라우드 자동화
클라우드 서비스를 자동으로 관리하고 운영하는 기술.
클라우드 인프라를 프로그래밍적으로 제어 할 수 있다.
즉 Docker 는 소프트웨어 패키지를 관리하고 배포하는 기술이고, 클라우드 자동화는 클라우드 인프라를 자동으로 운영하는 기술이다.
이 두개의 기술을 동시에 사용 가능하며 다른 기술이다. (Docker 이미지로 클라우드 자동화를 구현 할 수 있다)
내가 헷갈려서 다시 한번 더 기록하고...
과정
출처 : 코드스테이츠 유어클래스
파이프라인을 구축하기 위해 필요한 과정.
-
Source 단계에서 소스 코드가 저장되어 있는 Git repository 연결한다.
-
Build 단계에서 CodeBuild 서비스를 이용해서 EC2 인스턴스로 빌드된 파일을 전달한다.
-
Deploy 서비스를 이용해 Deploy 단계에서 EC2 인스턴스에 변경 사항을 실시간으로 반영한다.
실습
$ cd ~
$ curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
$ sudo apt install unzip
$ unzip awscliv2.zip
$ sudo ./aws/installAWS EC2 인스턴스에 해당 명령어로 AWS CLI 를 설치한다.
$ cd ~
$ sudo apt update
$ sudo apt install ruby-full # [Y / n] 선택 시 Y 입력
$ 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위 명령어로 Code Deploy Agent 설치한다.
sudo service codedeploy-agent status
라고 입력했을 때 위 사진처럼 active 라고 나오면 정상 설치가 된 것이다.
권한 설정
인스턴스에 연결되어 있는 IAM 역할에 권한을 줘야한다.
권한은 총 5개의 권한을 추가하면 된다.
파일 설정
appspec.yml 파일은 CodeDeploy-Agent 가 인식하는 파일이다.
6번 라인의 destination 은 파이프라인의 결과물이 EC2 의 어느위치에 복사 될 지를 의미한다.
8번 라인의 hooks 는 CodeDeploy 에서 지정한 단계에 맞춰 어떤 셀 스크립트를 실행 할지 지정한다.
buildspec.yml 파일은 CodeBuild 가 읽는 파일이다.
그리고
4개의 셀 스크립트를 생성해준다.
각각의 셸 스크립트에는 아래의 내용을 적는다.
빌드 결과물을 실행 할 수 있도록 실행 권한을 준다.
빌드 결과물이 저장되어 있는 build 디렉토리를 제거한다.
빌드 결과물을 실행한다.
실행중인 boot 프로젝트를 종료한다.
파이프라인이 성공적으로 완료되었다.
실행하면 위와 같은 화면이 뜨는 것을 확인.
환경변수 설정
파이프라인에 올린 EC2 인스턴스에 환경 변수를 전달해보자.
파라미터로 환경변수를 보내자.
build.gradle 파일을 수정하자.
dependencies {
implementation 'org.springframework.boot:spring-boot-starter-web',
'io.jsonwebtoken:jjwt-api:0.11.2'
implementation 'junit:junit:4.13.1'
implementation 'org.springframework.cloud:spring-cloud-starter-aws-parameter-store-config' //추가
runtimeOnly 'io.jsonwebtoken:jjwt-impl:0.11.2',
'io.jsonwebtoken:jjwt-jackson:0.11.2'
compileOnly "com.fasterxml.jackson.core:jackson-databind:2.9.4"
compileOnly 'org.projectlombok:lombok'
compileOnly "org.springframework.boot:spring-boot-starter-security"
runtimeOnly 'mysql:mysql-connector-java'
developmentOnly 'org.springframework.boot:spring-boot-devtools'
annotationProcessor 'org.projectlombok:lombok'
testImplementation 'org.springframework.boot:spring-boot-starter-test'
}
dependencyManagement { // 추가
imports {
mavenBom "org.springframework.cloud:spring-cloud-starter-parent:Hoxton.SR12"
}
}
test {
useJUnitPlatform()
}
그리고 bootstrap.yml 이라는 파일을 만들자.
aws:
paramstore:
enabled: true
prefix: /spring-boot-aws
name: be-0-SEYUN # 리소스 이름을 작성한다.
profileSeparator: _파라미터 스토어에 저장된 변수를 조회하는 파일이다.
S3 엔드포인트로 서버를 실행시키면 정상적으로 화면이 출력되는 것을 볼 수 있다.
