로컬에서 젠킨스로 블루/그린 무중단 배포 테스트하기 (1) - 젠킨스 설치, 스프링 부트 서버 세팅

💡 이 글에서 테스트해 볼 내용은 nginx + jenkins + springboot + github를 사용하여 프로젝트 서버의 배포 자동화 및 무중단 배포를 로컬 환경에 구현하는 것이다.

 

📌 젠킨스 설치

• 로컬에서 젠킨스를 설치하는 방법은 간단하다.
• https://www.jenkins.io/
• 위 링크에 접속하여 다운로드를 클릭한다. 

 

• 그럼 젠킨스를 다운로드 할 수 있는 페이지가 나오는데 각 운영체제나 컨테이너 환경에서 맞는 걸 클릭하면 다운로드하는 방법이 나온다.
• MAC을 기준으로 설명하면 macOS를 클릭한다.

 

• 그럼 이렇게 Homebrew로 다운로드하는 방법이 나온다. 

 

brew install jenkins
brew services start jenkins

• 처음 설치라면 위 두 명령어로 간단히 설치하고 실행시킬 수 있다.

 

https://suzuworld.tistory.com/415

로컬 환경에서 도커 젠킨스(Jenkins) 컨테이너로 깃허브 레파지토리 클론 테스트하기(with Ngrok)

• 젠킨스를 실행하고 Github 레파지토리에 저장된 프로젝트 파일을 젠킨스 워크스페이스로 클론하는 방법을 위 링크에 매우 자세히 설명해 놓았다.
  • 여기에서는 젠킨스 설치 후 스프링 부트 서버 세팅과 쉘 스크립트 & 젠킨스 파일 작성을 메인으로 다룬다.
• 만약 젠킨스가 완전히 처음이라면 꼭 클론까지의 테스트를 따라 해 보는 것을 추천한다.
• 위 링크의 글은 도커 컨테이너 기준으로 설명하고 있으니 로컬 젠킨스 설치와 다른 부분에 대해 이야기하겠다.
  • 도커의 경우 젠킨스 포트를 <docker run> 명령어로 쉽게 변경이 가능하지만, mac에 직접 설치하는 경우에는 초기 포트가 8080으로 실행된다.
  • macOS 기준으로 젠킨스 포트를 변경하는 방법 등 로컬에 젠킨스를 설치한 경우에도 따라할 수 있게 설명을 추가해 놓았으니 위 링크의 글을 따라 Jenkins 기본 설정을 끝내고 돌아오자.

 

❓ 왜 클론 테스트는 도커 컨테이너로 하고 배포 테스트는 로컬 PC의 젠킨스로 하시나요?

• 원래는 젠킨스 컨테이너로 하고 싶었으나, 특정 외부 서버에 배포하는 것이 아닌 100%하나의 로컬 서버에 배포 테스트를 하는 것이었으므로 문제가 발생했다.
  • 컨테이너 내부에서 빌드 과정이 끝나고 호스트 PC에 빌드 파일을 전송(배포)까지는 할 수 있으나(docker cp 명령어 사용해서), 컨테이너 내부에서 호스트 PC에게 쉘스크립트를 실행시키라고 명령을 내릴 방법이 도저히 생각나지 않았다. 
• 물론 방법을 찾으려고 하면 해결책이야 있었겠지만 복잡할 것이 뻔하고 이건 말그대로 실제 서버에 적용해보기 전의 로컬 테스트였기 때문에 도커 젠킨스 컨테이너를 종료하고 로컬 PC에 젠킨스를 설치하여 테스트했다.

 

😀 블루/그린 배포를 위한 준비

• 위 글을 그대로 따라했다면 스프링 부트 서버를 ngrok으로 외부에 노출시키고 이를 깃허브의 웹훅을 이용해 젠킨스 워크스페이스에 클론하는 것까지 되어있을 것이다. 
• 이 글은 이후에 과정부터 설명한다.
  • 이 글의 마지막 테스트에서는 ngrok으로 외부에 서버를 노출 시켜 로컬에서 깃허브 레파지토리로 푸시하는 걸 트리거로 배포 자동화하는 테스트 과정을 생략하고 젠킨스 UI에서 직접 빌드하기 버튼을 눌러 진행한다.(무중단 배포만 테스트 진행)
  • 따라서 ngrok까지 해보고 싶다면(배포 자동화) 위 글을 참고하여 테스트하면 된다.
• 내가 만들 블루/그린 무중단 배포 과정에 대한 계획은 

blue -> green

green -> blue

• 위와 같은 방식이다.
  • 실제 3편 글의 배포테스트에서는 깃허브 푸시 과정을 생략하고 젠킨스에서 직접 빌드하는 방식으로 진행했다.

 

https://suzuworld.tistory.com/416

젠킨스(jenkins)에 대해 알아보고 무중단 배포 계획을 세워보자

• 자세한 배포 설명은 이 글에서 확인할 수 있다.
• 읽고 아래의 내용을 봐야 진행상황이 쉽게 이해될 것이다.
• 위 글에서는 로컬 서버에서 외부 서버로 배포하는 방식을 설명하는데(로컬 -> 깃허브 -> 외부 서버 젠킨스 -> 외부 서버 배포)
• 여기서 진행할 테스트에서는 (로컬 -> 깃허브 -> 로컬 젠킨스 -> 로컬 배포)로 진행 방식으로 변경되었다는 점을 참고하길 바란다.
  • 크게 달라지지는 않았고 그저 외부서버로 배포하는냐 로컬에 배포하느냐에 차이가 있을 뿐이다.
  • 로컬 -> 깃허브는 테스트 과정에서 생략한다.

 

⚒️ 스프링부트 서버 세팅

import lombok.RequiredArgsConstructor;
import org.springframework.core.env.Environment;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

import java.util.Arrays;

@RestController
@RequiredArgsConstructor
public class MainController {

    private final Environment environment;

    @GetMapping("/")
    public String getVersion() {
        return "이 서버는 V1입니다. 빌드 테스트입니닷!!!";
    }

    @GetMapping("/profile")
    public String getProfile() {
        return Arrays.stream(environment.getActiveProfiles()).findFirst().orElse("default");
    }
}

• 먼저 스프링부트 서버를 세팅하겠다.
• 스프링 부트 프로젝트를 만든 뒤 컨트롤러 클래스에 위 두 메서드를 추가한다.
  • getVersion()의 경우 localhost:8080으로 접속하면 위 리턴문이 출력될 것이다.
  • getProfile()의 경우에는 localhost:8080/profile로 접속하면 스프링부트 서버의 프로퍼티 프로필이 출력될 것이다.

 

• 로컬 서버에는 총 3개의 application.yml 파일이 존재한다.
• application.yml에는 spring.profiles.active: blue만 적는다.
  • 로컬에서 인텔리제이로 직접 서버를 실행할 때는 default로 blue를 실행할 것이다.
• blue의 포트는 8081이며, 그린의 포트는 8082이다.
• 여기서 주의할 점은 반드시" applicaiion-" 다음 원하는 프로필 이름을 적어야 한다는 것이다.

 

• /profile로 서버에 접속해 보자.
• application.yml에 blue로 설정하여 실행하면 blue가 출력되고, green으로 설정하면 green으로 출력될 것이다.

 

💡 build.gradle 설정

implementation 'org.springframework.boot:spring-boot-starter-actuator'

 

• 위 의존성을 추가하자.
  • 나중에 health check를 할 때 서버가 정상적으로 실행되었는지를 확인하는 데 사용된다.
  • 컨트롤러에 따로 get 요청 메서드를 만들지 않아도 위 의존성을 추가하는 것만으로 서버의 정상 실행 여부를 체크할 수 있는 api가 자동으로 추가된다.
  • api 엔트포인트는 /actuator/health이다.
  • 실제로 접속해 보면 json 형태로 "UP"이라고 value가 출력됨을 확인할 수 있다.
    • 이 "UP"이라는 문자는 쉘 스크립트에서 서버의 정상 실행 여부를 확인할 때 사용될 것이다.(health check)

 

다음 글에 계속된다.

 

 

 

참고

뤼튼

https://hyunminh.github.io/nonstop-deploy/