🌈 [Section4] 12. [Cloud] 배포 자동화

📕 오늘 배운 내용!

• 배포 자동화
• AWS Pipeline을 이용한 배포 자동화
• Github Actions를 이용한 배포 자동화

---

✏️ 배포 자동화

• 한번의 클릭 or 명령어 입력을 통해 전체 배포 과정을 자동으로 진행하는 것

• 시간 절약

• 휴먼 에러(Human Error) 방지

  ✔️ 휴먼 에러 (Human Error)

  • 사람이 수동적으로 배포 과정을 진행하는 중에 생기는 실수들

✔ 배포 자동화 파이프라인

✔️ 파이프라인 (Pipeline)

• 소스 코드의 관리부터 실제 서비스로의 배포 과정을 연결하는 구조
• 각 배포 단계는 파이프라인 안에서 순차적으로 실행됨

1. Source 단계

• 원격 저장소에 관리되고 있는 소스 코드에 변경 사항이 일어날 경우,
  이를 감지하고 다음 단계로 전달하는 작업 수행

2. Build 단계

• Source 단계에서 전달받은 코드를 컴파일, 빌드, 테스트하여 가공

• Build 단계를 거쳐 생성된 결과물을 다음 단계로 전달하는 작업 수행

3. Deploy 단계

• Build 단계로부터 전달받은 결과물을 실제 서비스에 반영하는 작업 수행

❗ 파이프라인의 단계는 상황과 필요에 따라 더 세분화되거나 간소화될 수 있음 !!
( 위의 단계가 무조건적인 단계가 아님 )

---

✏️ AWS의 배포 자동화 관련 서비스

➜ AWS의 개발자 도구 섹션에서 제공하는 서비스들을 활용하여 배포 자동화 파이프라인 구축 가능

✔️ CodeCommit

• Source 단계 구성할 때 이용

• GitHub과 유사한 서비스를 제공하는 버전 관리 도구

  💡 CodeCommit vs GitHub
  ( 어떤 서비스가 우월하다기보다, 각 서비스가 가지는 장단점이 다름 )
  ⠀
  ✅ CodeCommit 서비스

  • 보안과 관련된 기능에 강점
    ➜ 소스 코드의 유출이 크게 작용하는 기업에서는 매우 중요한 요소
    ⠀
  • But, 사용 시 과금 가능성 고려해야함
    ( 프리티어 한계 이상으로 사용할 시 사용 요금이 부과될수도 있음 )

  ---

  ✅ GitHub⠀

  • CodeCommit 서비스의 과금 가능성의 이유로,
    사이드 프로젝트나 가볍게 작성한 소스 코드를 저장해야 할 경우에는 GitHub을 이용하는 것이 효과적

✔️ CodeBuild

• 빌드 단계에서 필수적으로 실행되어야 할 작업들을 명령어를 통해 실행 가능
  Ex. 유닛 테스트, 컴파일, 빌드 등

• 사용자가 작성한 buildspec.yml 파일을 참조하여 작업 수행
  ( 한 빌드 프로젝트에 하나의 buildspec만 지정 가능 )
  CodeBuild 빌드 사양 참조

💡 CodeBuild Phase ( buildspec.yml )
1. install
➜ 런타임 설치
Ex. Java, node.js 등
⠀
2. pre_build
➜ 종속성 설치 / 테스트 진행
( 이번 실습에서는 생략함 )
⠀
3. build
➜ 실질적인 빌드 진행
Ex. ./gradlew build
⠀
4. post_build
➜ 빌드 후, 추가적인 작업이 필요할 경우 진행

✔️ CodeDeploy

• Deploy 단계 구성할 때 이용

• 실행되고 있는 서버 애플리케이션에 실시간으로 변경 사항을 전달 가능

• 사용자가 작성한 appspec.yml 파일을 참조하여 작업을 수행
  CodeDeploy AppSpec 파일 참조

• S3 서비스의 S3 버킷을 통해 업로드된 정적 웹 사이트에 변경 사항을 실시간으로 전달 / 반영 가능

💡 CodeDeploy Phase ( appspec.yml )
( 로드밸런서 사용 X )
⠀
1. Application Stop
➜ (기존에 실행중인) 애플리케이션 종료
⠀
2. Download Bundle
➜ 새 버전을 인스턴스로 가져옴
⠀
3. Before Install
➜ 기존의 빌드 내역 삭제
⠀
4. Install
➜ 새 버전 압축 해제 후, 파일의 내용에 따라 복사
⠀
5. After Install
➜ 실행에 필요한 의존성 설치 ( 우리는 권한 부여 )
Ex. npm / pm2 등
⠀
6. Application Start
➜ nohup으로 빌드파일 실행
⠀
7. Validate Service
➜ 배포가 잘 되었는지 확인하는 과정 ( 우리는 사용 X )

✔️ nohup

• 리눅스, 유닉스에서 셸 스크립트파일 (*.sh)을 데몬 형태로 실행시키는 프로그램
• 터미널 세션이 끊겨도 실행을 멈추지 않고 동작하도록 함

✔️ CodePipeline

• 각 단계를 연결하는 파이프라인을 구축할 때 이용

  ⚠️ AWS 프리티어 계정 사용 시, 한 계정에 두 개 이상의 파이프라인을 생성하면 추가 요금이 부여될 수 있음 !!

---

✏️ AWS Pipeline을 이용한 배포 자동화

( AWS에 모든 것을 맡김 )

1. CodePipeline을 이용해서 각 단계를 연결하는 파이프라인 구축

2. Source 단계
   ➜ 소스 코드가 저장된 GitHub 리포지토리 연결
   ( 코드를 수정 후 push하면 3번 build 자동 실행 )

3. Build 단계
   ➜ CodeBuild 서비스를 이용하여 빌드 후, EC2 인스턴스로 빌드된 파일 전달
   ( 빌드된 결과물은 객체 스토리지인 S3 버킷에 저장됨 )

4. Deploy 단계
   ➜ CodeDeploy 서비스를 이용하여 EC2 인스턴스에 변경 사항 실시간으로 반영
   ( 각자에게 배정된 AWS IAM 계정을 key로 사용 )

⭐ 자동화 방식 순서

• 내 레포에 push ➜ AWS 변경 감지 ➜ pull ➜ build ➜ ec2 delivery ➜ sh로 스크립트 실행 ➜ ec2에서 서버 실행

💡 올라가면 안되는 정보들은 파라미터 스토어에서 읽어올 수 있도록 설정하고,
코드 내의 bootstrap.yml 파일에 어떠한 이름 구조로 되어있는 변수를 읽어올지 설정

---

💡 build.gradle 파일도 의존성 설치하고 클라우드에 접근할 수 있게끔 수정

---

💡 be-sprint-deployment/DeployServer 경로에 추가된 파일들

• buildspec.yml
  ➜ CodeBuilder가 읽는 파일 ( be-sprint-deployment/DeployServer 경로에 추가 )
  ➜ CodeBuild가 지정한 각 단계별로 어떤 동작을 할지 명령
  ( appspec.yml 파일을 읽게끔 되어있고, 각 셸 스크립트의 위치도 알려줌 )
  ⠀⠀
• appspec.yml
  ➜ CodeDeploy가 읽는 파일 ( be-sprint-deployment/DeployServer/ 경로에 추가 )
  ➜ CodeDeploy에서 지정한 각 단계별로 어떤 셸 스크립트를 실행할지 지정
  ⠀⠀
• scripts/server_clear.sh
  ➜ 이전에 빌드된 결과물이 저장되어있는 build 디렉토리 제거하는 셸 스크립트
  ( be-sprint-deployment/DeployServer/scripts/ 경로에 추가 )
  ⠀⠀
• scripts/server_stop.sh
  ➜ 이전에 실행중이던 Spring Boot 프로젝트 종료하는 셸 스크립트
  ( be-sprint-deployment/DeployServer/scripts/ 경로에 추가 )
  ⠀⠀
• scripts/initialize.sh
  ➜ 빌드 결과물을 실행할 수 있도록 실행 권한 추가하는 셸 스크립트
  ( be-sprint-deployment/DeployServer/scripts/ 경로에 추가 )
  ⠀⠀
• scripts/server_start.sh
  ➜ DeployServer-0.0.1-SNAPSHOT.jar라는 빌드 결과물을 실행하는 셸 스크립트
  ( be-sprint-deployment/DeployServer/scripts/ 경로에 추가 )

---

✏️ Github Actions

• Github이 공식적으로 제공하는 빌드, 테스트 및 배포 파이프라인을 자동화할 수 있는 CI/CD 플랫폼

  ✔️ CI/CD (Continuous Integration / Continous Deployment)
  하나의 서비스를 계획부터 실행까지 진행하는 것을 말하는 것

• 특정 파일(.yml)에 따라 Github Repository에 특정 변동사항을 트리거로 작동

• 레포지토리에서 Pull Request 나 push 같은 이벤트를 트리거로 GitHub 작업 워크플로(Workflow) 구성 가능

  ✔️ 워크플로 (Workflow)

  • 하나 이상의 작업이 실행되는 자동화 프로세스
  • 각 작업은 자체 가상 머신 또는 컨테이너 내부에서 실행
  • .yml or .yaml 파일에 의해 구성
  • 기능에 따라 여러개의 워크플로 생성 가능
    Ex. 테스트 / 배포 ..
    ( 생성된 워크플로는 .github/workflows 디렉토리 이하에 위치 )

• 레포지토리의 공개 / 비공개에 따라 요금 제한이 다름

  • 비공개 레포지토리
    ➜ Github Actions가 작동할 때의 용량과 시간이 제한됨

  • 공개 레포지토리
    ➜ 무료로 사용 가능

공식 문서 참고
사용법 참고

✔ Github Actions를 통한 배포 Flow

1. 프로젝트 레포에 코드 수정 후 push

2. 해당 레포의 Actions 메뉴에서 workflow 생성

3. Settings - Secrets - Actions 경로에 Access Key/Secret Access Key 추가

   💡 Github Actions가 AWS에 접근하기 위해서 Access Key/Secret Access Key가 필요 !!
   이 키들은 코드에 직접 작성 XXX
   윈도우 환경변수 설정과 같이 Setting에 설정해주고,
   .yml 코드 내의 ${{설정해준 이름}}} 부분에서 Setting으로 설정한 값을 읽어옴

4. Github Actions가 빌드를 위해 읽을 .yml 파일 수정

   💡 .github/.workflow/ 하위에 있는 yml이면 되고, 이름은 상관 X
   [참고] https://github.com/gradle/gradle-build-action

5. 레포지토리에 변화가 생기면 Github Actions 작동하여 우리가 작성한 .yml 파일 읽음

6. .yml 파일에 있는 동작대로,
   프로제트 빌드 결과물(.jar)을 S3로 전송 / 저장

   💡 S3

   • 정적 웹 페이지를 배포하는 데 사용됐던 저번 실습과 다르게,
     압축된 빌드 결과물을 저장할 저장소(버킷)로써 사용

7. .yml 파일에 있는 동작대로,
   Github Actions가 AWS의 CodeDeploy로 배포 명령

8. CodeDeploy가 S3 버킷에 저장되어 있는 프로젝트 빌드 결과물(.jar) 가져옴

   💡 CodeDeploy

   • 프로젝트 최상단에 위치한 appepec.yml 설정 파일에 의해 단계에 따라 특정 동작을 함
     ⠀
   • Code Deploy가 S3 버킷에서 EC2 인스턴스로 프로젝트를 이동할 수 있도록
     EC2 인스턴스에 Code Deploy Agent 설치 필요
     ( ❗ 설치 방법이 다 달라서 공식 문서 참고 )

9. AWS CodeDeploy가 가져온 결과물을 EC2에 배포 / 실행

   💡 EC2

   • .yml(설정 파일)과 .sh(쉘 스크립트)에 의해 각 배포 결과를 로그로 저장하고,
     CodeDeploy로 부터 받은 빌드 파일(.jar) 실행
     ⠀⠀
   • 원활한 진행을 위해 알맞은 Code Deploy Agent의 설치와 JDK 11 버전 설치가 필요

---

😜 실습

• git - be-sprint-deployment

=============================================================

☃️ AWS Pipeline을 이용한 배포 자동화 실습

여러가지 파일 생성 후 환경 설정을 한 후에 fork한 내 레포에 push를 하니

생성한 파이프라인의 빌드 과정이 자동으로 진행되면서 배포 후 실행까지 자동으로 되어서

S3 엔드포인트 주소로 들어가보면 배포 자동화 실습 완료..!!

( 실습 과정은 나중에 작성할 예정 ! )

=============================================================

☃️ Github Actions를 이용한 배포 자동화 실습

위에 적어놓은 순서대로 실습을 하고 내 EC2 퍼블릭 DNS로 들어가봤더니 페이지 로드 성공 !!

( 아래 페이지가 오류같이 생겼지만 내가 아직 뭘 안적어줘서 저렇게 뜨는 것이다 ㅎㅎ )

그래서 해당 프로젝트에 따로 컨트롤러를 만들어서 아래 메세지를 출력하도록 코드를 수정하고

다시 내 레포로 push한 후에 자동배포 과정이 진행되고 다시 해당 주소로 들어가보니

아래와 같이 잘 뜬 것을 볼 수 있다 ㅎㅎㅎㅎ

❗ 참고로 둘 다 퍼블릭 DNS 뒤에 :8080 적어줘야함 !

---

🌈 느낀점

어제는 그래도 무난무난 했는데 마지막에 로그인이 안돼서 이 에러를 해결하는 데에 많은 시간을 쏟았다.
원인은 내가 intellij에서 파일을 수정했을 때 포트번호를 잘못 쓴 것도 있었고,
파라미터 스토어에서 파라미터의 password 값을 잘못 지정해주어서 그런 것도 있었다 !
결국은 해결해서 다행 ~
그리고 오늘은 어제 에러를 만나서 여러가지 +로 알게되는 것들이 있었다보니
오늘은 더 쉬웠고 에러도 더 빨리 해결할 수 있었다 !!

요즘 느끼는 게
에러를 만나도 한번에 성공할 때보다 더 많은 걸 알 수 있어서 뭔가 나쁘진 않다!
물론 엄청 오래 걸리거나 결국 고생해서 찾았는데 정말 작은 실수이면 허무하지만
그래도 바로 성공한 사람들보다는 다음에 같은 오류가 났을 때 더 잘 해낼 수 있을테니까 !!