5회. Ch9 - 코드가 푸시되면 자동으로 배포해보자- Travis CI 배포 자동화

지난 챕터 6-8까지는 5장까지 만들었던 게시판 프로젝트를 EC2에 배포하고 배포과정을 진행하는 쉘스크립트를 작성하는 작업, 그리고 깃헙에 공개되면 안되는 프로젝트 설정 파일들을 EC2 서버에 등록하는 과정을 진행했다. 

이제, 9장에서는 코드가 작성되고 깃허브에 푸시되면 자동으로 배포가 되는 과정을 진행하기로 한다. 

 

24시간, 365일 운영되는 서비스에서 여러 개발자의 코드가 실시간으로 병합되고, 테스트 수행, master 브랜치에 푸시가 되면 자동으로 배포가 되는 환경을 구축해야 실수를 방지할 수 있다고 저자는 이야기한다.

 

9.1 CI & CD 소개

8장에서 쉘 스크립트를 개발자가 실행하며 EC2에 배포를 진행했다. -> 불편하니 CI,CD 환경을 구축해 이 과정을 개선하자

 

CI란?

Continuous Intergration - 지속적 통합의 약자로, 코드 버전을 관리하는 VCS시스템 (Git, SVN)에 PUSH가 발생하면 자동으로 테스트 + 빌드를 수행해 안정적인 배포 파일을 만드는 과정을 이야기한다.

 

CD란?

Continuous Deployment - 지속적 배포의 약자로, CI를 통해 만들어진 빌드 결과를 자동으로 운영 서버에 무중단 배포까지 진행하는 과정을 이야기함.

 

CI/CD는 보통 따로 구축되어있지 않고 함께 구축되어있다. 

 

이들의 등장배경은 다음과 같다. 여러 개발자가 개발을 진행하고 CI가 존재하기 이전에는 병합일을 지정해 코드를 합쳤다. 이 과정에서 생산성이 떨어졌고 이를 방지하기 위해 코드를 푸시할때마다 자동으로 병합되는 CI환경을 구축했다.

CD 역시 한 두대의 서버는 직접 배포가 가능하지만 수십대의 서버에 배포를 하면 시간이 오래 걸리기 때문에 이 과정을 단축하고자 도입되었다.

 

CI도구를 도입했다고 CI를 하고 있는 것일까? 아니다. CI에 대한 4가지 규칙이 존재한다.

https://www.martinfowler.com/articles/continuousIntegration.html

Continuous Integration

 

• 모든 소스코드가 살아있고(실행중이고) 누구든 현재 소스에 접근할 수 있는 단일 지점을 유지할 것.
• 빌드 프로세스를 자동화해서 누구든 소스로부터 시스템을 빌드하는 단일 명령어를 사용할 수 있게 할 것.
• 테스팅을 자동화해서 단일 명령어로 언제든지 시스템에 대한 건전한 테스트 수트를 실행할 수 있게 할 것
• 누구나 현재 실행 파일을 얻으면 지금까지 가장 완전한 실행 파일을 얻었다는 확신을 하게 할 것

가장 중요한 것은 테스팅의 자동화이다. 지속적으로 통합을 이어가기 위해선 이 프로젝트가 완전한 상태임을 보장하기 위한 테스트 코드가 구현되어 있어야한다는 것이다.

 

TDD 관련 강의 링크

https://www.youtube.com/watch?v=wmHV6L0e1sU&list=PLagTY0ogyVkIl2kTr08w-4MLGYWJz7lNK&index=8&t=1538s

 

9.2 Travis CI 연동하기

 

Travis CI는 깃헙에서 제공하는 무료 CI 서비스이다. 

젠킨스라는 서비스도 존재하는데 해당 서비스는 EC2 인스턴스가 하나 더 필요하기에 부담스럽다. 따라서, Travis CI를 이용할 계획이다.

( AWS의 CI도구로 CodeBuild도 존재하는데 이는 빌드 시간만큼 요금이 발생한다. 실제 서비스 되는 부분인 EC2, RDS, S3를 제외하고는 비용을 최소화하는게 좋다. )

 

https://travis-ci.org/ 에 github 계정으로 로그인을 하자.이후 [계정] -> [Settings]로 이동해 Repository활성화를 해줘야한다. 

선택한 프로젝트만 activate하게 해주자.

 

프로젝트 설정

Travis CI의 상세 설정은 프로젝트에 존재하는 .travis.yml 파일로 한다. .yml 확장자를 YAML(야믈)이라고 한다.

이 확장자는 JSON에서 괄호를 제거한 것이다. 

YAML은 기계의 파싱이 쉽게, 사람이 다루기 쉽게 발전했으며 많은 설정을 이렇게하고 있다.

 

build.gradle과 같은 위치에 .travis.yml을 다음과 같이 생성해주자.

language: java
jdk:
    - openjdk8

branches:
    only:
      -master

# Travis CI 서버의 Home
cache:
  directories:
    - '$HOME/.m2/repository'
    - '$HOME/.gradle'

script: "./gradlew clean build"

# CI 실행 완료 시 메일로 알람
notifications:
  email:
    recipients:
      - 본인 메일 주소

branches

-Travis CI를 어느 브랜치가 푸시될 때 수행할지 지정한다.

- 즉, master 브랜치에 푸시가 진행될때 CI를 수행한다.

 

cache

- 그레이들을 통해 의존성을 받으면 이들을 해당 디렉토리에 캐시하여, 같은 의존성은 다음 배포부터 다시 받지 않도록 설정한다.

 

script

- master 브랜치에 푸시가 진행되었을때 수행되는 명령어. 여기서는 clean&build가 수행된다.

 

notifications

- Travis CI가 수행된 후, 자동으로 알람이 가도록 진행함.

 

이 yml 파일을 이제 master 브랜치에 커밋 / 푸쉬하면 저장소에서 자동 빌드가 되는 것을 확인해야하는데 여기서 오류가 발생했다.

'

에러로그는 다음과 같았다.

• Branch "master" not included per configuration.

띄어쓰기와 이메일 관련 오류가 있어서 수정하고 다시 커밋, 푸시를 진행했다.

 그러자 다음과 같은 오류가 발생했다.

• Sender Youthhing is not allowed to trigger build in this repo.

내가 이 repository에 build권한을 허용하지 않았다? 이런 오류 같은데... 

이런 오류가 travis-ci.com에 발생한다. 

 

여러 관련 오류들을 가지고 travis 연동 오류를 찾아봤다. 해당 오류는 가격정책에 대한 문제인듯 하다. plan에서 사용할수 있는 회수를 초과했다는 이야기이다. 따라서, plan을 등록해야하는데 계정설정 -> free plan에 카드 등록을 했다. 이 과정에서도 zip-code, val ID를 추가해야해서 상당히 복잡했다. 

zip - code 는 구글에 검색해서 시흥시의 코드를 입력했고 val ID는 사업자 등록번호를 등록해야하는데 이건 진짜 찾아보고 뭐하기 귀찮아서 그냥 no라고 적어버렸다. 아무튼 카드등록도하고 플랜등록이 되었는데도 아래와 같이

You exceede the number of users allowed for your plan. Please switch to a bigger plan.

이런 에러가 뜬다.

팀원들에게 물어보니까 직접 메일을 보내야한다고 한다.

상당히 귀찮네 이거 기다려야겠다.

 

 

문의를 해보니 바로 exceeded the number에 대한 오류가 해결되었다.

그러나 Send is not allowed to trigger build on this repo 에러가 계쏙 발생했다. 구글에 관련 사례가 거의 없어서 ChatGPT에 물어봤다.

ㄹㅇ똑똑함

 

아무튼 리포지토리를 삭제하고 다시 연동ㅇ했다. 그 과정에서 [more options] - [settings]에 들어가서 user management를 들어가서 다시 activate를 해줬다.

user management에서 권한 추가해주자

 

그러니 다음과 같이 푸쉬가 되었을때 빌드가 되는것을 볼 수 있었다. 처음엔 허가 오류가 떴는데 이는 

before_install:
  - chmod +x gradlew

해당 코드를 추가해주니 해결이 되었다.

 

이메일로도 알림이 왔다.

 

9.3 Travis CI와 AWS S3 연동하기

 

S3란? 

- AWS에서 제공하는 일종의 파일 서버. 이미지 파일등 정적 파일과, 배포파일들을 관리하는 기능을 가지고 있다. 이미지를 업로드하고 싶다면 해당 S3를 이용한다.

 

 Travis CI와 연동 시 구조는 다음과 같은데,

 

 

CodePlay에는 저장 기능이 없기 때문에 Travis CI가 빌드한 결과를 저장할 공간이 필요하다. 따라서, S3에 저장하고 S3에 받아올 수 있도록하자.

 

Codeplay에서도 빌드와 배포가 가능하지만 빌드와 배포는 분리하는게 좋다. 

배포만 필요할때 빌드까지 해야하는일은 확장성이 떨어지기 때문이다. 따라서, 빌드는 Travis에서 배포는 Codeplay에서 하도록 하자.

 

Travis CI 와 S3연동

 

AWS Key 발급하기

AWS서비스에는 외부서비스가 접근할 수 없다. 접근 권한이 있는 key를 생성해서 사용해야하는데 이때 IAM(Identity and Access Management) 서비스를 이용한다.

IAM을 통해서 AWS에서 제공하는 서비스의 접근 방식, 권한을 관리한다.

 

IAM 검색 - [사용자Tab] - [사용자 추가]

 

AWS 엑세스 유형에서 '프로그래밍 방식 엑세스'를 선택하라는데 해당 체크박스가 없었다.

 

이 부분이 나중에 문제가 되었는데 액세스 방식을 잘 선택해야 해당 액세스 키를 활용해 Travis에 키를 등록할 수 있다. 그러나, '프로그래밍 방식 액세스' 가 존재하지 않았다. 해당 방식은 ' AWS API,CLI과 SDK 그리고 기타 개발도구'에 대해 액세스 키쌍을 발급하는데 해당 선택지가 아닌 액세스 키에 대한 다음 옵션들이 존재했다.

 

나는 CLI관련 옵션을 선택헀다.

 

권한 선택은 기존 정책 연결을 진행하고 S3full 과 CodedeployFullAccess 관련 기존 정책을 선택해준다. S3와 CodeDeploy를 분리하지 않고 하나로 합쳐서 관리하는 것이다.

 

 

위에서 생성한 액세스 키에 대해 Travis에 들어가서 다음과 같은 이름으로 키를 등록했다.

해당 내용들은 .travis.yml에서 $을 붙여서 사용할 수 있따.

 

S3 버킷 만들기

해당 버킷에서는 jar 파일을 관리한다. S3 서비스는 일종의 파일 서버로 순수하게 파일들을 저장하고, 권한을 관리, 검색등을 지원하는 파일 서버의 역할을 한다. 주로 게시글 작성시 첨부 파일 등록을 구현할 때 많이 사용한다. 또한, Travis CI에서 생성된 Build 파일(jar파일)을 저장하도록 구성했다.

 

S3를 검색후 버킷을 만들자, 이름은 자유롭게 설정을 하되 zip 파일에 어떤 내용이 모여있을지를 생각하며 설정한다. 이어서 모든 퍼블릭 액세스를 차단하자. 프로젝트는 github등에 오픈소스로 풀려있지만, jar파일이 퍼블릭이면 주요 설정, 코드, 키값이 탈취될 수 있음을 유의해야한다.

 

또한 버전 관리 활성화를 선택해주자.

 

이제 S3로 배포파일을 전달하기 위해 .travis.yml을 수정해주자.

 

before_deploy:
  - zip -r springboot1 *
  - mkdir -p deploy
  - mv springboot1.zip deploy/springboot1.zip

deploy:
  - provider: s3
    access_key_id: $AWS_ACCESS_KEY #Travis repo setting에서 설정한 값
    secret_access_key: $AWS_SECRET_KEY #위와 동일

    bucket: springboot-youth-build
    region: ap-northeast-2
    skip_cleanup: true
    acl: private # zip 파일 접근을 private로 접근
    local_dir: deploy # before_deploy에서 생성한 디렉토리로
    wait-until-deployed: true

before_deploy:

deploy 명령어 실행전, 즉 배포 되기전에 수행됨.

CodeDeploy는 Jar파일을 인식하지 못하므로 Jar파일과 기타설정 파일을 zip으로 묶어야한다.

 

zip -r springboot1(파일이름) *(압축대상)

- 해당 폴더의 모든 내용을 springboot1.zip으로 묶는 내용

- -r 명령어 뒤에는 현재 프로젝트의 이름이 와야한다. 

- *을 사용해서 현재폴더를 압축할 것 임을 명시해야한다.

 

여기서 오류가 왕창 발생했음!

 

mkdir -p deploy : deploy라는 이름의 폴더를 Travis CI가 실행중인 위치에 생성하자.

 

deploy 

- S3로 파일 업로드, CodeDeploy로 배포와 같은 외부 서비스와 연동된 행위를 할 때 해당 행위들을 선언하자.

 

local_dir: deploy

앞에서 생성한 deploy 디렉토리를 지정해 해당 위치로 S3파일들을 전송한다.

 

S3 버킷을 확인해보면 잘 생성되어있다.

 

 

9.4 Travis CI와 AWS S3, CodeDeploy 연동하기

 

우선, EC2와 CodeDeploy를 연동하기 위한 IAM을 하나 생성하자.

[IAM 검색] - [ 역할 탭 ] - [ 역할 만들기 ]

 

앞서서 우리는 '사용자'를 생성했다. 그러나 이번엔 '역할'을 생성하는데 둘의 차이는 무엇일까?

 

역할

- AWS 서비스에서만 할당할 수 있는 권한

- EC2, CodeDeploy, SQS

 

사용자

- AWS 서비스 외에도 사용할 수 있는 권한

- local PC, IDC 서버 등

 

지금 만들 권한은 EC2에서만 사용될 것이기에 역할로 처리한다.

 

AWS서비스, EC2를 선택하고, 권한으로 AmazonEC2RoleForAWS-CodeDeploy를 선택한다. 역할 이름과 네임태그를 입력하고 생성을 마무리한다.

 

이제, 해당 역할을 EC2 서비스에 등록해야한다. 

내 EC2 인스턴스  목록을 들어가서 우클릭 - 보안 - IAM 역할 설정을 클릭하자. 방금 만들었던 역할을 추가하고 EC2를 재부팅한다.

 

CodeDeploy 에이전트 설치

 

 

aws s3 cp s3://aws-codedeploy-ap-northeast-2/latest/install .--region ap-northeast-2

해당 명령어를 EC2에 입력해서 설치를 해줘야하는데 오류가 뜬다! 

 

Unknown ap-northeast-2

 

구글링 결과 업데이트부터 해주라고 한다.

따라서, EC2에 

Sudo yum update를 하고 실행하니 실행이 잘 되었다.

 

실수로 home에 안받아서 지우고 다시 home에 다운해줬다.

 

sudo ./install auto명령어를 실행해도 진행이 되지 않았다. usr/bin이 없다나 따라서 아래 블로그를 참고해 codedeploy 설치를 해줬다.

https://samtao.tistory.com/81

AWS AMI2에 CodeDeploy 설치하기

 

이후, 아래의 명령어를 통해 Agent가 제대로 실행되고 있는지 확인해주자.

sudo service codedeploy-agent status

 

CodeDeploy를 위한 권한 생성

 

CodeDeploye 에서 EC2에 접근하려면 권한이 필요하다. 따라서 AWS IAM역할을 생성해주자.

 

AWS IAM -> 역할 생성 -> AWS서비스 -> CodeDeploy

위는 권한이 하나밖에 없기때문에 따로 추가해줄 필요가 없다.

 

*참고

AWS의 배포체계 3가지가 존재하는데 CodeDeploy도 그중 하나이다.

- Code Commit : 깃허브와 같은 코드 저장소, private기능을 지원하나 깃허브 또한 제공중이라 우리는 깃헙을 사용함

- Code Build : 코드를 빌드하는 서비스, 우리는 Travis CI를 사용할 계획.

- CodeDeploy : AWS의 배포 서비스. 현재 다른 대체제가 없기때문에 대부분 이것을 사용한다.

 

따라서 AWS - CodeDeploy에서 어플리케이션 생성을 해주자.

 

 

이후, 배포 그룹을 생성해야한다. 이름은 자율적으로, 서비스 역할은 아까 만들었던 IAM을 선택하자.

배포 유형은 서비스의 개수에 따른 두 가지 옵션이 존재한다. 

- 현재 위치 : 1대의 EC2에만 배포할때

- 블루/그린 : 두 대 이상의 EC2에 배포할때.

 

환경 구성은 Amazon Ec2 인스턴스 : 해당 과정에서 Name 태그를 작성할때 반드시 Ec2 인스턴스의 이름을 선택하자.

배포 설정은 CodeDeployDefault.AllAtOnce를 선택하고 '로드 밸런서'는 해제하자.

 

배포 설정(배포 구성)이란 한 번 배포를 할때 몇 대의 서버에 배포를 할지 결정하는 것이다. 1대의 서버를 사용할때는 전체 배포를 해주면 상관이 없지만 2대 이상의 서버를 운용할때는 전체에서 몇 개의 서버에 배포를 할 것인지 백분율을 통해 표현할 수 있다.

 

Travis Ci, S3, CodeDeploy 연동하기.

 

우선, S3에 넘겨줄 zip 파일을 저장할 디렉토리를 만들자.

EC2의 ~/app/step2/zip 디렉토리를 만들고 [Travis CI Build] -> [S3에 ZIP 파일 전송] -> [복사되어 EC2 해당 폴덩 ㅔ전송]되게 만들 예정이다.

관련 Travis CI 설정은 .travis.yml에 AWS CodeDeploy 설정은 appspec.yml에 작성한다.

 

appspec.yml

version: 0.0 #CodeDeploy의 버전을 이야기함
os: linux
files:
  -source:  /
  destination: /home/ec2-user/app/step2/zip
  overwrite:yes

version : CodeDeploy의 버전을 이야기함.

* 프로젝트 버전을 의미하는 것이 아니기에 0.0외에 다른 버전을 사용하지 않도록 유의하자.

 

source

- CodeDeploy에서 전달해준 파일 중 destination으로 이동시킬 대상을 정한다.

- / 는 루트 디렉토리를 의미하며 따라서 전체파일을 의미한다.

즉, [CodeDeploy에서 만든 파일 중 destination으로 보낼 파일을 선택한다.]

 

Destination : source에서 지정한 파일을 받을 위치

- Jar 파일을 실행하는 등의 행동은 destination에서 옮긴 파일들로 진행함.

 

Overwrite : 기존 파일을 덮어쓸지 설정하는 결정하는 것

 

.travis.yml에도 이어서 다음과 같은 설정을 추가해주자.

  - provider: codedeploy  
    access_key_id: $AWS_ACCESS_KEY #Traivs repo settings에서 설정한 값
    secret_access_key: $AWS_SECRET_KEY

    bucket: springboot-youth-build #S3 번들 이름
    key: springboot1.zip

    bundle_type: zip
    application: springboot1 #웹 콘솔에 등록한 codedeploy어플리케이션
    
    deployment_group: springboot1-group #생성한 CodeDeploy 배포그룹 이름
    
    region: ap-northeast-2
    wait-until-deployed: true

 

이후 두 개의 파일을 커밋하고, 푸시하면 ~app/step2/zip의 파일 목록에 해당 파일들()이 잘 도착해있는 것을 확인할 수 있어야하는데 다음과 같은 오류가 발생했다.

 

오류 로그 failed to deploy? 배포에 실패했다는 뜻이다.

S3에 들어가 s3.zip 파일 (springboot1.zip) 파일도 제대로 생성되어있는 것을 확인했다.

 

이렇다면 코드에 문제가 아니고 배포과정의 문제라는건데 배포는 CodeDeploy의 담당이니 우선 AWS Codedeploy에 들어가서 오류 로그를 확인해봤다.

 

다음과 같은 에러가 발생했는데 연결된 EC2 인스턴스가 없다는 내용이었다. 차근차근 CodeDeploy를 생성하는 과정을 돌이켜보니 EC2의 정보를 입력한적이 없었다. 따라서, 어디에 이를 ㄷ입력하는게 좋을까 생각해보니 AWS EC2 인스턴스 연결과정에서의 Name 태그를 인스턴스의 이름이 아닌 다른 이름으로 입력해 생기는 오류였다.

 

이를 수정하니 해당오류는 해결되었다.

정상적으로 연동되어 파일들이 도착했다.

 

9.5 배포 자동화 구성.

이제 Travis CI, S3 CodeDeploy까지 연동을 했다. 이것을 기반으로 실제 Jar를 배포하여 실행하는 과정을 해보자.

 

우선 deploy.sh를 프로젝트의 scripts하위 폴더에 생성한다. ( scripts 폴더는 src폴더와 동일한 디렉토리에 생성한다. ) 

#!/bin/bash

REPOSITORY=/home/ec2-user/app/step2
PROJECT_NAME=springboot1

echo "> Build 파일 복사"

cp $REPOSITORY/zip/*.jar $REPOSITORY

echo "> 현재 구동 중인 어플리케이션 pid 확인"

CURRENT_PID=$(pgrep -fl springboot1 | grep jar | awk '{print $1}')

echo "> 현재 구동 중인 어플리케이션 pid: $CURRENT_PID"

if [ -z "$CURRENT_PID" ]; then
  echo "> 현재 구동중인 어플리케이션이 없으므로 종료하지 않습니다."
else
  echo "> kill -15 $CURRENT_PID"
  kill -15 $CURRENT_PID
  sleep 5

fi

echo "> 새 어플리케이션 배포"

JAR_NAME=$(ls -tr $REPOSITORY/*.jar | tail -n 1)

echo "> JAR_NAME: $JAR_NAME"
echo "> $JAR_NAME 에 실행 권한 추가"

chmod +x $JAR_NAME

echo "> $JAR_NAME 실행"

nohup java -jar \
  -Dspring.config.location=classpath:/application.properties,classpath:/application-real.properties,/home/ec2-user/app/application-oauth.preoperties,/home/ec2-user/app/application-real-db.preoperties \
  -Dspring.profiles.active=real \
  $JAR_NAME > $REPOSITORY/nohup.out 2>&1 &

 

 

이어서 .travis.yml파일을 수정하자.

기존까지 만들었던 zip 파일내에는 프로젝트의 모든 파일이 들어있었다. 하지만, 실제 프로젝트에서 필요한 파일들은 Jar, appspec.yml, 배포 스크립트 이들이다. 따라서 해당 파일들만 포함하도록 before_deploy를 수정해야한다.

 

before_deploy:
  - mkdir -p before-deploy
  - cp scripts/*.sh before-deploy/
  - cp appspec.yml before-deploy/
  - cp build/libs/*.jar before-deploy/
  - cd before-deploy && zip -r before-deploy *
  - cd ../ && mkdir -p deploy
  - mv before-deploy/before-deploy.zip deploy/springboot1.zip

기존에는 아래의 코드를 통해 해당 프로젝트의 모든 파일을 압축해줬으나 현재는 일부 파일들만 옮겨 놓고 해당 파일만 zip으로 압축하는 과정을 거친다.

- zip -r springboot1 *

 

 

appspec.yml 파일엔 location, timeout, runas의 들여쓰기를 주의하며 파일에 다음 코드를 추가하자.

들여쓰기를 맞춰주지 않으면 배포가 실패하는 경험을 할 수 있다.

 

permission:
  - object: /
    pattern: "**"
    owner: ec2-user
    group: ec2-user

hooks:
  ApplicationStart:
    - location: deploy.sh
      timeout: 60
      runas: ec2-user

 

permission : CodeDeploy에서 EC2 서버로 넘겨준 파일을 모두 ec2-user권한을 갖도록 한다.

 

hooks

- CodeDeploy 배포 단계에서 실행할 명령어를 지정한다.

- ApplicationStart 단계에서 deploy.sh를 ec2-user권한으로 실행하게 만든다.

- timeout: 스크립트 실행시간이 60초 이상이 되면 실패로 넘어간다.

 

이를 커밋하고 푸시하니 Travis CI와 CodeDeploy 모두 성공적으로 완료가 되었다.

 

문제는 배포를 완료하고 ec2 uri로 서비스에 접근을 해봤는데 사이트에 접근할 수 없다는 오류가 발생했다.

CodeDeploy에도 성공이 떴는데 배포 시간이 너무 짧은게 아닌가?하는 생각이 들었다.

 

나만 그런가..? EC2에 접근해 nohup.out을 봤는데 다음과 같은 오류가 발생했다.

8.2에서 진행할때 발생했던 오류와 동일한 듯 하다. 이는 ClientRegistrationRepository를 찾을 수 없다는 에러이다.

이때는 deploy.sh에 -Dspring.config.location으로 위치 설정을 해줘서 해결했다. 그러나, 분명 맞춰서 코드를 썼는데 왜..?

 

해결.

nohup java -jar \
    -Dspring.config.location=classpath:/application.properties,classpath:/application-real.properties,/home/ec2-user/app/application-oauth.properties,/home/ec2-user/app/application-real-db.properties \
    -Dspring.profiles.active=real \
    $JAR_NAME > $REPOSITORY/nohup.out 2>&1 &

 

applicaiton-real-db.properties와 application-oauth.properties 를 설정할때 오타가 있었다. 이를 수정해주니 해결이 되었다.

 

실제 배포 과정 체험

build.gradle에서 프로젝트 버전을 변경해보자.

version '1.0.1-SNAPSHOT'

 

버전 변경을 위해 templates의 index.mustache 내용에 Ver.2텍스트를 추가하자.

 

<h1>스프링 부트로 시작하는 웹 서비스 Ver1.2</h1>

해당 내용을 사실 ver.1 -> ver2로 바꿔야했으나 나ㅡㄴㄴ 전에 완성본 복붙을 해버려서 Ver.2로 되어있어 약간의 수정을 해주었다.

 

9.6 CodeDeploy 로그 확인

 

다음 디렉토리로 이동하면 /opt/codedeploy-agent/deployment-root/ 코드 디플로이 관련 오류로그를 모아놓은 디렉토리를 확인할 수 있다. 아래 명령어 입력후 codedeploy-agent-deployments.log 파일을 확인해보면 로그를 확인할 수 있다.

cd /opt/codedeploy-agent/deployment-root/deployments-log/

 

 

이렇게, 9장에서 우리는 테스트 ,빌드,배포를 자동화하는 과정을 구현해봤다.

 

마지막 남은 문제는 배포하는 동안엔 프로젝트는 종료 상태가 되어 서비스를 이용할 수 없다는 것이다.

 

배포하는동안에도 서비스를 유지할 방법을 고민해보자 ㅋ