무중단 배포 실습 기본 셋팅 (Github Actions, Nginx 활용)

무중단 배포 이론에 대해서 학습을 하였고, 무중단 배포를 이젠 실습해보겠습니다. 

이론에 관해서는 아래 포스팅을 참고 해주세요.
https://programmer-may.tistory.com/209

무중단 배포(Zero-downtime Deployment) 전략

 

본 실습에서 무중단 배포 진행 과정

제 무중단 배포 실습은 아래와 같이 진행됐습니다. 최소한의 기술로 무중단 배포를 처음 도입해보는 실습자에게 부담없이 다가갈 수 있게 하였습니다. 도커를 함께해서 도커 이미지를 바꿀 수도 있지만, 러닝 커브를 최소한으로 하게 하는 것이 목표였습니다. 어려움은 최대한 덜되 탄탄한은 갖도록 저의 기준에서 최소한으로 필요한 기술들을 적용해 보았습니다.

 

 

 

1. Github Actions : 액션스를 활용하여 자동 배포 파이프라인을 구축하였고, cicd를 통해서 무중단 배포 도입 전엔 직접 jar 파일을 디렉토리로 옮기고, jar 파일을 실행 시켰습니다. 무중단 배포 도입 후엔 AWS EC2 특정 디렉토리 안에 deploy.sh 쉘 스크립트를 두어 Github Actions 을 통해 cd yml 파일에서 명령어로 그 쉘 스크립트를 실행하도록 하였습니다.

 

2. Sell Script : 쉘 스크립트를 활용하여, 배포 및 헬스 체크를 진행하고, 롤백 또한 가능하도록 하였습니다. 또한 엔직엔스의 설정 파일을 동적으로 바꾸어 트래픽을 신 버전이 실행된 어플리케이션으로 바꾸거나 로드 밸런싱을 설정을 동적으로 변화시켜줬습니다.

 

3. Nginx : 엔진엑스의 /etc/nginx/sites-available/default 파일을 동적으로 변화시켜 로드 밸런싱을 무중단 배포 전략에 맞게 바꾸었습니다. 엔진엑스에 SSL Termination 까지 적용하려면 도메인도 있어야 하고, 과정이 복잡하여 HTTPS 가 아닌 HTTP 요청을 기준으로만 진행하였습니다. Nginx 에서 SSL Termination 까지 진행하고 싶으신 분은 제 블로그에 Nginx 구축 포스팅을 참고해주세요!

 

4. Spring Boot : 기본적으로 8081 포트엔 구버전이, 8082포트엔 신버전 어플리케이션 구동 되고 설정 했고, 롤링 전략 경우 두 포트 모두에서 구 버전, 신 버전이 돌아가게끔 했습니다.
헬스 체크로는 Spring actuator 의존성을 받아, {http:// EC2 퍼블릭 IP }:{헬스 체크 하려는 포트번호}/autator/health 를 통해 응답이 잘 오는 지 확인하였습니다.

 

5. Termius : SSH Client 로는 Termius 를 활용했습니다. 원래는 MobaXterm 을 사용했지만, 전자책을 읽는 독자의 컴퓨터 OS 가 Window 가 아닌 경우엔 사용이 불가능 하기에, macOS, Window 두가지 OS 모두 지원하는 툴을 사용했습니다.

Termius 를 활용하여 CLI 로 JDK 와 엔진엑스를 설치하고 디렉토리를 만들고, deploy.sh 파일도 작성하였습니다.

 

6. Apache JMeter : 테스팅 툴로는 아파치 제이미터를 활용했습니다. 저에게 익숙하기도 하고, simple http request 템플릿도 지원해주기에 사용했습니다. {호스트 주소}/hello 요청을 지속적으로 보내어 응답값을 확인 하여, 제대로 무중단 배포가 다운 타임 없이 진행이 됐는지 확인하였습니다. 특히나 롤링 전략이나 카나리 전략은 트래픽을 동적으로 바꾸는 부분이 크기에 실시간으로 어디 포트엔 트래픽이 안가고 가는지도 확인이 가능했습니다.

 

7. Postman : 아파치 제이미터로 요청에 대한 응답을 계속 확인했다면, 포스트맨을 이용해서는 로컬에서 헬스 체크를 진행 했습니다. 실제로 무중단 배포가 이루어지고나서, 구버전이 있던 포트의 프로세스는 kill 되어야 하기 때문에 헬스 체크를 해도 커넥션 에러가 생겨야합니다. 무중단 배포가 잘 이뤄졌는지 로컬에서 확인 용으로 포스트맨을 사용했고,

{ http:// EC2 퍼블릭 IP }:{구버전의 jar 가 실행된 프로세스의 포트번호}/autator/health 통하여 요청이 가는 것이 아닌 에러가 잘 오는지 확인했습니다.

 

실습 브랜치 전략

실습 브랜치 전략은 아래 그림으로 정리해두었습니다.

 

ver1은 각각의 브랜치의 무중단 배포 적용 전 배포 환경을 구축한 것이고, ver2 는 각각의 브랜치에 맞는 무중단 배포 전략을 적용한 브랜치입니다.

bluegreen, rolling, canary 브랜치는 각각 push 트리거가 정해져 있어 ver1 또는 ver2 을 풀리퀘스트 보내고 해당 브랜치에 merge 하면 Github Actions 가 실행되게 됩니다.

on:
  push:
    branches:
      - [각각의 브랜치]

 

실습 전 셋팅

실습을 따라하시기 전에 셋팅은 다음과 같습니다.

 

1. 환경 셋팅

먼저 EC2에 원격 접속을 하여 JDK17 과 Nginx 를 설치해주어야 합니다.

Termius 를 통해 진행 할 것인데, Termius 에서 EC2 원격 접속은 아래 블로그 포스팅에 자세하게 정리 해두었습니다.

https://programmer-may.tistory.com/212

Termius 다운로드 및 실행, EC2 접속

 

접속을 한 뒤 CLI 에 명령어를 입력하여 필요한 파일을 다운을 받아 보겠습니다.

 

먼저 업데이트를 하기 위해 apt update를 입력해줍니다.

$ sudo apt update

 

JDK 17 설치, 중간에 동의 구하는 건 디스크를 얼만큼 차지하는데 설치 할 것인가에 관한 것이니 y 를 입력해줍니다.

$ sudo apt install openjdk-17-jdk

 

JDK가 잘 설치 되었는지 버전 확인

$ java -version

이렇게 17.xxx 로 버전이 잘 나오면 잘 설치 된 것입니다.

 

Nginx 설치

$ sudo apt install nginx

$ nginx -v

엔진엑스의 버전을 확인하여 잘 설치 되어 있는지 확인해봅니다.

 

 

설정 파일을 켜서 설정 파일 예시를 확인해 봅니다.

$ sudo nano /etc/nginx/sites-available/default

 

막대한 주석문으로 설정파일 예시와 설명이 있는 파일이 켜졌다면, 제대로 설치가 된 것이고, 텅 비어있거나 경로를 찾을 수가 없다고 나타나면 경로를 잘못 기입한 것입니다.

 

ctrl +k 를 눌러 주석문과 예시를 모두 날려 버리고 기본 nginx 설정 파일을 복붙 하겠습니다.

각각 전략마다 초기 엔진엑스 설정이 다른데, 블루 그린 기준으로 먼저 해주겠습니다.

server {
    listen 80;
    server_name _;

    location / {
        proxy_pass http://127.0.0.1:8081;  # 이 부분은 deploy.sh에서 동적으로 변경됩니다.
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Termius 기준 복사는 ctrl + shift + c 이고 붙여넣기는 ctrl + shift + v 입니다.
nano 명령어로 킨 편집기에 저장을 위해선 ctrl + o 를 입력하고 엔터를 눌러주면 됩니다. 나가기를 하려면 ctrl + x 를 하면 됩니다.

설정 파일이 잘 저장했는지 위에 명령어를 다시 한번 입력하여 확인 후 나가줍니다.

 

테스트를 하여 엔진엑스 설정이 문제가 없는지 확인해줍니다.

$ sudo nginx -t

다음과 같이 ok가 나오면 별 문제 없는 것입니다.

 

설정을 해주었기에 엔진엑스를 실행해주겠습니다.

$ sudo systemctl start nginx

엔진엑스의 상태를 확인해주겠습니다.

$ sudo systemctl status nginx

위와 같이 active (running) 이 되어있으면 정상 실행중인 것입니다.

 

이젠 jar 파일을 scp 할 디렉토리와 각각 전략에 맞는 deploy.sh 를 실행하기 위한 디렉토리를 만들겠습니다.

먼저 루트 경로에서 디렉토리를 만들 것입니다. 루트로 오려면 cd ~ 입력하면 루트로 와집니다.

$ mkdir cicd

cicd 폴더를 만들어서 앞으로 저희가 만든 어플리케이션의 신 버전의 jar 파일은 이곳에 둘겁니다.

 

cicd 디렉토리로 경로를 이동하겠습니다.

$ cd cicd

 

이동후 다음 명령어를 한줄 씩 입력합니다.

$ mkdir old_build
$ mkdir bluegreen
$ mkdir rolling
$ mkdir canary

 

cicd 디렉토리 아래에 old_build 디렉토리에는 배포후 구버전의 jar 파일이 이곳으로 옮겨질 것입니다.

그리고 각각의 배포 전략에 맞는 deploy.sh 쉘 스크립트를 각각 배포전략 디렉토리 아래에 생성할 것입니다.

 

2. 프로젝트 셋팅

프로젝트의 cd yml 파일을 보면 Repository Secrets 를 두어 동적으로 바인딩하여 배포하는 걸 볼 수 있습니다.

 

개인적인 정보가 들어가기에 깃허브에 오픈된 공간에 저장하지 않기 위해 Secrets 만들어서 관리하게 됩니다.

총 4가지를 만들것입니다.

 

 

자신의 EC2의 pem Key 를 열어 내용을 전체 복붙 해줍니다. 만약 OpenSSH  키가 아니라면 변환해야하는데, 변환하는 과정은 제 블로그의 다른 글을 참고해주세요.

 

Name에 SSH_PRIVATE_KEY 를 적고 붙어 넣어줍니다.

생성한 뒤 다음도 똑같이 하면 됩니다.

 

APPLICATION_YML

management:
  endpoints:
    web:
      exposure:
        include: health,info
  endpoint:
    health:
      show-details: always

 

SERVER_IP

자신의 EC2의 퍼블릭 IP 주소 또는 퍼블릭 DNS 주소

 

SERVER_USERNAME

ubuntu

SERVER_USERNAME의 경우 EC2 AMI 의 OS 마다 각각 다를 수 있습니다. 저는 EC2의 AMI 를 우분투로 하였기 때문에 username 이 ubuntu 입니다. 자신에게 맞는 것을 넣어야 합니다.

 

모두 다 했다면 다음과 같습니다.

 

main 브랜치 셋팅

메인 브랜치는 각각 bluegreen, rolling, canary 브랜치의 토대가 되는 브랜치로 bulid.gradle 설정, Test API 생성, Custom Health Indicator 생성, ci.yml 생성을 하겠습니다. 

 

bulid.gradle 

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
    implementation 'org.springframework.boot:spring-boot-starter-actuator'
    developmentOnly 'org.springframework.boot:spring-boot-devtools'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
    testRuntimeOnly 'org.junit.platform:junit-platform-launcher'
}

tasks.named("jar") {
    enabled = false
}

 

의존성 으로는 Spring web 과 Spring actuator 를 주입 받고 jar 파일 생성을 false 로 하겠습니다. 왜냐하면 깃허브 액션스의 명령어에서도 jar 파일을 만들기 때문에 false 해주지 않으면 jar 파일이 복수개라서 어느 것을 배포할 jar인지 모르기 때문입니다.

 

Test API 생성

import org.springframework.boot.web.server.WebServer;
import org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class TestController {
    private final ServletWebServerApplicationContext webServerAppContext;
    private static final String RESPONSE_BODY_MESSAGE = "버전 1 응답값입니다. 무중단 배포 도입 전입니다.";

    public TestController(ServletWebServerApplicationContext webServerAppContext) {
        this.webServerAppContext = webServerAppContext;
    }

    @GetMapping("/hello")
    public ResponseEntity<String> test() {
        WebServer webServer = webServerAppContext.getWebServer();
        int port = webServer.getPort();
        String response = RESPONSE_BODY_MESSAGE + "\n실행 중인 포트는 " + port + "입니다.";
        return ResponseEntity.ok(response);
    }
}

 

어느 버전인지 응답을 받을 수 있고 포트 번호를 알 수 있겠끔 API 를 만들었습니다. 생성자 주입을 했기때문에 자동으로 생성된 Test 폴더의 TestController 테스트 파일은 지워주셔야합니다. 안그러면 나중에 pr 시 CI 체크에서 빌드 테스트를 통과 못하기 때문입니다. 여긴 의존성 주입이 됐는데, Test 파일엔 의존성 주입이 안됐기 때문이죠.

 

Custom Health Indicator 생성

import org.springframework.boot.actuate.health.Health;
import org.springframework.boot.actuate.health.HealthIndicator;
import org.springframework.stereotype.Component;

@Component
public class CustomHealthIndicator implements HealthIndicator {

    @Override
    public Health health() {
        boolean isHealthy = checkSomeCondition();
        if (isHealthy) {
            return Health.up().withDetail("customHealth", "All systems go!").build();
        } else {
            return Health.down().withDetail("customHealth", "Something is wrong!").build();
        }
    }

    private boolean checkSomeCondition() {
        long freeMemory = Runtime.getRuntime().freeMemory();
        long totalMemory = Runtime.getRuntime().totalMemory();
        return freeMemory > (totalMemory * 0.15);
    }
}

 

Actuator 를 활용하여 커스텀으로 헬스 확인을 할 수 있습니다. DB 커넥션을 확인 한다거나, 외부 API가 잘 호출 되는지 확인 한다거나, 아니면 자신이 만든 서비스의 기능이 잘 동작하는지 확인을 할 수도 있겠죠.

전 DB 연동이나 다른 외부적인 요인이 없기에, 그냥 return true 로 하면 심심하니 가용 메모리가 전체 메모리의 15% 이상인지 확인하는 로직을 넣어 봤습니다.

 

모든 셋팅은 끝났기에 이젠 각각의 전략에 맞는 실습을 진행해 보겠습니다.