서비스 규모가 복잡해지고 커지면 배포 과정이 복잡해지고 소요되는 시간이 늘어나게 됩니다.

배포를 매번 수동으로 진행하면 시간 허비가 커지기 때문에 자동화 과정이 필요합니다.

배포 자동화

  • 수동적이고 반복적인 배포 과정을 자동화함으로써 시간이 절야된다.
  • 휴먼 에러를 방지할 수 있습니다.

배포 자동화 파이프라인 (배포 과정)

  • Source Stage: 버전 컨트롤 도구를 이용한 소스 코드 관리 및 전달
  • Build Stage: 코드 컴파일링, 유닛 테스트, 빌드 결과물 생성
  • Deploy Stage: 변경 사항 실시간 반영, 서비스 업데이트

과정은 상황과 필요에 따라 더 세분화되거나 간소화될 수 있습니다.

AWS 개발자 도구

개발자 도구 섹션에서 제공하는 서비스를 활용하여 배포 자동화 파이프라인을 구축할 수 있습니다.

CodeCommit

버전 관리 도구입니다.

CodeBuild

유닛 테스트, 컴파일, 빌드와 같은 빌드 단계에서 필수적으로 실행되어야 할 작업을 명령어를 통해 실행할 수 있습니다.

CodeDeploy

서버 애플리케이션에 실시간으로 변경 사항을 전달할 수 있습니다. 또한 S3서비스를 통해 S3버킷을 통해 업로드된 정적 웹 사이트에 변경 사항을 실시간으로 전달하고 반영할 수 있습니다.

CodePipeline

각 단계를 연결하는 파이프라인을 구축할 때 이용됩니다.


클라이언트 배포 파이프라인 구축

codeBuild 서비스를 이용하는 데 필요한 buildspec.yml 파일을 생성

version: 0.2

phases:
  pre_build:
    commands:
      - cd client
      - npm install
  build:
    commands:
      - npm run build

artifacts:
  files:
    - '**/*'
  base-directory: client/build

최상위 디렉토리에 buildspec.yml 파일을 생성한 뒤, 변경사항을 저장하고 commit 후 push 합니다.

파이프라인 구성

AWS CodePipeline에 접속합니다.

소스 공급자를 GitHub 레포지토리를 연결합니다.

소스 단계를 통해 GitHub 변경 사항이 생길 경우 자동으로 변경 사항이 파이프라인에 반영됩니다.

GitHub 앱을 선택한 뒤, 연결 버튼을 클릭합니다.

해당 레포지토리 이름과 master 브랜치를 선택한 뒤 CodeBuild 프로젝트를 생성합니다. 소스 단계를 통해 전달받은 코드를 테스트하거나 빌드하여 배포 단계로 전달하는 역할을 합니다.

프로젝트 생성에서 운영체제를 선택하고 이미지 버전은 항상 최신 버전을 이용합니다.

로그 파일을 저장하는 서비스로 CloudWatch 혹은 S3를 이용할 수 있습니다.
(S3에는 정적 웹 호스팅을 위한 호스팅의 수가 많아지면 과금 될 가능성이 높아집니다. 따라서 CloudWatch 서비스를 통해 리소스를 분산합니다.)

배포 스테이지 단계에서 빌드 과정 후 최종적으로 결과물이 전달 및 반영됩니다. 배포 공급자는 S3를 선택합니다.

이후 각 스테이지 성공/실패 여부를 확인 할 수 있습니다.

CodePipeline을 통해 배포 과정을 진행하고 성공적일 경우 초록색 체크를 확인할 수 있습니다.


빌드 로그 파일 확인

파이프라인을 구축하고 배포 자동화를 하는 과정에서 오류가 발생할 수 있습니다.
발생한 오류를 찾고 해결 방안을 모색하기 위해서 배포 기록이 담긴 로그 파일을 확인해야 합니다.

생성된 빌드를 클릭 후 실패한 빌드 실행 기록을 클릭하면 빌드 과정의 사이클의 흐름, 정확히 어떤 오류가 발생했는지 확인 할 수 있습니다.
(오류나 핵심적인 내용은 로그 파일 끝부분에 위치한 경우가 많습니다.)

CloudWatch를 통해 로그 파일 확인

정상적으로 작동하고 있는 걸 확인할 수 있습니다.

로그 파일을 확인하는 습관은 큰 자산이 됩니다. 시간을 들여 많은 연습이 필요합니다.


배포 자동화 (실습)

EC2 Instance를 생성 한 뒤, 터미널을 통해 nvm, npm, nodejs를 설치하여 개발 환경을 구축합니다.

EC2 생성 후 개발 환경 구축 과정

sudo apt update

패키지 매니저가 관리하는 패키지의 정보를 최신 상태로 업데이트 하기 위해 위 명령어를 터미널에 입력

이후 nvm, nodejs를 설치해야 합니다.

정상적으로 설치 된 경우 nvm --version 명령어를 통해 확인 할 수 있습니다.

nvm install node

nvm 설치 후 node를 설치하고 node.js의 설치가 끝나면 npm 명령어가 작동합니다.

sudo apt install npm

EC2 Instance에 태그와 역할 부여 (Hands-on)

EC2 Instance에 태그와 역할 부여

태그를 추가하기 위해, 작업 → 인스턴스 설정 → 태그 관리 순서로 클릭해 이동합니다.

다음으로 IAM 서비스를 이용해 EC2 Instance 역할을 부여합니다.

작업 → 보안 → IAM 역할 수정 을 통해 역할(Role) AWS의 개체가 다른 서비스에 접근할 수 있도록 해주는 방법입니다.

EC2 Instance 역할을 부여해 다른 AWS 서비스를 호출할 수 있는 권한을 가집니다.
(AWS IAM 서비스)

  • 역할 만들기 클릭
  • AWS 서비스, EC2 선택 후 다음:권한 버튼 클릭
  • S3 AmazonS3FullAccess 선택
  • SSM AmazonSSMFullAccess 선택
  • CodeDeploy AWSCodeDeployRole 선택

(선택 사항의 경우 정말 선택 사항..)

역할 이름 정하고, 역할 만들기 버튼을 클릭!

태그/역할이 생성됐다면, 신뢰 관계 편집을 해야 합니다.

신뢰 관계란?

해당 역할을 취할 수 있는 서비스나 사용자를 명시하는 부분
access 정책 부여를 통해 역할을 생성해 주었지만, access 할 수 있는 서비스를 신뢰 관계에서 명시함으로써 역할이 확실히 완성됩니다.

편집에서 Service 부분에 역할 설정을 해주면 됩니다.

EC2 Instance에 생성한 역할을 적용해 줍니다.
이후 EC2는 S3, CodeDeploy, SSM 서비스에 접근할 수 있습니다.

보안

EC2 Instance에 보안 그룹을 갖고 있는지 확인해야 합니다.
EC2 대시 보드에서 보안 그룹으로 이동합니다.

보안 탭을 클릭 후 보안 그룹에 접근합니다.

보안 그룹의 인바운드 규칙은 80과 443 포트가 포함되어 있는지 확인합니다.

80번 포트는 서버 배포를 위해 필요하고, 443 포트는 CodeDeploy의 정상적인 작동을 위해 필요합니다.

HTTP와 HTTPS에 대한 유형을 위치 무관으로 추가한 뒤 규칙 저장을 클릭하면 됩니다.

저장하면 20,80,443 포트가 포함되어 있는지 확인하고 EC2 보안 세팅은 끝납니다.


EC2를 활용한 파이프라인 구축

레포지토리 최상위에 appspec.yml 파일을 추가합니다.

appspec.yml은 배포 자동화를 도와주는 CodeDeploy가 인식하는 파일입니다.

version: 0.0
os: linux
files:
  - source: /
    destination: /home/ubuntu/im-sprint-practice-deploy

hooks:
  ApplicationStop:
    - location: scripts/stop.sh
      runas: root
  AfterInstall:
    - location: scripts/initialize.sh
      runas: root
  ApplicationStart:
    - location: scripts/start.sh
      runas: root

최상위에 scripts 디렉토리를 생성 후 그 안에 initialize.sh, start.sh, stop.sh 파일 3개를 생성합니다.

각 파일은 appspec.yml 파일이 구성하고 있는 배포 수명 주기에 따라 실행됩니다.

ex) scripts/initialize.sh

#!/bin/bash
cd /home/ubuntu/im-sprint-practice-deploy/server
npm install
npm install pm2@latest -g
sudo apt-get update
sudo apt-get install authbind
sudo touch /etc/authbind/byport/80
sudo chown ubuntu /etc/authbind/byport/80
sudo chmod 755 /etc/authbind/byport/80

ex) scripts/start.sh

#!/bin/bash
cd /home/ubuntu/im-sprint-practice-deploy/server
authbind --deep pm2 start app.js

ex) scripts/stop.sh

#!/bin/bash
cd /home/ubuntu/im-sprint-practice-deploy/server
pm2 stop app.js 2> /dev/null || true
pm2 delete app.js 2> /dev/null || true

변경 사항을 저장하고 commit 한 뒤, master로 push 합니다.

AWS CodeDeploy 대시보드로 이동해 애플리케이션으로 이동합니다.

애플리케이션 생성 버튼을 클릭 후 이름을 입력, EC2/온프레미스로 선택한 뒤 애플리케이션을 생성합니다.

애플리케이션이 생성되면, 생성한 애플리케이션의 배포 그룹 탭을 클릭해 배포 그룹 생성 버튼을 클릭합니다.

배포 그룹의 이름을 임의로 입력하고, 서비스 역할 영영을 클릭한 후 EC2Role을 선택합니다.

환경 구성 중 AWS EC2 Instance를 선택하고, 태그 그룹에 EC2 Instance에 설정해놓았던 태그 키와 값을 선택합니다.

로드 밸런싱 활성화 체크 해제 후, 배포 그룹 생성 까지 진행하면 AWS CodeDeploy 세팅은 끝입니다.


CodePipeline 생성

AWS CodePipeline을 이용해 서버 배포 자동화 파이프라인 구축이 가능합니다.

소스 공급자는 GitHub 버전 2를 사용합니다.

GitHub 연결 후 자도 배포를 진행 할 레포지토리를 선택합니다.
(브랜치 이름은 master or main 으로 진행하는 것이 좋습니다. 이후 로컬(개발)환경에서는 master를 사용하기 보다 branch를 사용하는 것이 좋습니다.)

서버 코드의 경우 컴파일과 빌드 과정이 필요 없기 대문에 빌드 스테이지 컨너뛰기를 통해 빌드 단계를 생략합니다.

파이프라인 생성과 동시에 소스 코드의 배포는 자동으로 실행됩니다.

터미널 접근 EC2 Instance를 통해 로그를 확인 할 수 있습니다.

'cd /opt/codedeploy-agent/deployment-root/deployment-logs'

codedeploy-agent-deployments.log 라는 파일이 존재하고, nano를 이용해 해당 파일을 확인 할 수 있습니다.
(stderr은 standard error, stdout은 standard output을 뜻합니다.)

profile
메일은 매일 확인하고 있습니다. 궁금하신 부분이나 틀린 부분에 대한 지적사항이 있으시다면 언제든 편하게 연락 부탁드려요 :)

0개의 댓글