작심삼일ing

Git에 Push 이벤트 발생시 자동으로 Jenkins 빌드까지 했으니 이번 포스팅에서는 Jenkins에서 EC2 서버 자동배포까지 해보겠습니다.

1. Jenkins SSH 설치

EC2 서버 배포를 위해 Jenkins 관리 -> 플러그인 관리에서 Publish Over SSH를 설치합니다.

2. SSH 연결 서버 정보 입력

Jenkins 관리 -> 시스템 설정에서 배포할 서버 정보를 입력해 줍니다.

정보를 모두 입력했다면 Use password authentication, or use a different key 를 체크해줍니다.

그리고 고급을 눌러서 EC2를 생성할 때 받은 pem 키를 열어서 해당 값을 Key 부분에 전부 넣어줍니다. 

마지막으로 Test Configuration을 눌러서 Success 가 나오는 것을 확인하고 저장합니다.

만약 Success가 나오지 않는다면 위에 입력한 정보가 맞는지, 배포할 EC2 서버에 SSH(22) 포트가 열려있는지 확인해야합니다.

2. Build 스크립트 작성 

Jenkins 프로젝트 -> 구성에 들어가서 빌드 스크립트를 작성해줍니다.

저는 배포 후 수행할 스크립트를 프로젝트에서 관리하도록 했기 때문에 deploy 폴더를 생성해 jar, 스크립트 파일을 SSH로 전송하도록 작성했습니다.

3. 배포 후 실행할 스크립트 작성

위에 언급한 것처럼 프로젝트에서 scripts 폴더 생성 및 delpoy.sh 이라는 스크립트를 작성했습니다.

#!/bin/bash

REPOSITORY=/home/ubuntu/test
PROJECT_NAME=jenkins-springboot

echo ">>> Build 파일 복사"

cp $REPOSITORY/deploy/*.jar $REPOSITORY/

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

CURRENT_PID=$(pgrep -fl jenkins-springboot | grep java | awk '{print $1}')

echo ">> PID : " $CURRENT_PID

if [ -z "$CURRENT_PID" ]; then
  echo "구동중인 애플리케이션 없음."
else
  echo ">>> kill -15 $CURRENT_PID"
  kill -15 $CURRENT_PID
  sleep 10
fi

echo ">>> 애플리케이션 배포"

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

echo ">>> JAR NAME : $JAR_NAME"

chmod +x $JAR_NAME

echo ">>> $JAR_NAME 실행"

nohup java -jar \
    -Dspring.config.location=classpath:/application.properties \
    $JAR_NAME > $REPOSITORY/nohup.out 2>&1 &

배포가 완료되면 자동으로 deploy.sh 이 실행되어 스프링부트가 실행되는 것을 확인할 수 있습니다.

참고 :

https://wellbell.tistory.com/9?category=976634 

이번 포스팅에서는 Webhook을 사용해서 Github에서 Push 이벤트가 발생할 때 자동으로 Jenkins 가 자동으로 빌드하도록 설정해보겠습니다.

1. Webhook 이란 ?

Webhook은 이벤트 핸들러입니다.

Github에서 Push 이벤트가 발생했을 때 설정된 EndPoint로 Post요청을 보내게 되고 Jenkins는 빌드를 수행하게 됩니다.

https://simsimjae.medium.com/%EC%9B%B9%ED%9B%85%EC%9D%B4%EB%9E%80-e41cf1ba92f0

2. Jenkins 설정

-  Jenkins 프로젝트 -> 구성 -> GitHub hook trigger for GITScm polling 를 체크하고 저장합니다.

3. Github Repository Webhook 설정

- Repository -> Settings -> Webhook에서 Add Webhook 을 클릭한 후 

젠킨스 주소 +/github-webhook/을 추가해줍니다.

그리고 Push를 하면 빌드가 자동으로 되는 것을 확인할 수 있습니다.

Docker 로 Jenkins 컨테이너를 생성 후 AWS EC2 서버에 자동 배포까지 해보겠습니다. 

이번 포스팅에서는 Jenkins 실행 후 GitHub 연동까지 하도록 하겠습니다.

1. Docker 를 설치 후 docker pull jenkins/jenkins:lts로 젠킨스 이미지를 받습니다.
2. Jenkins 이미지를 컨테이너로 실행합니다. docker run -d -p 9090:8080 -u root jenkins/jenkins:lts
   1. docker images로 이미지를 확인할 수 있다.
      1. -d 백그라운드 실행
      2. -p 포트 지정 
      
   2. 그리고 도커 컨테이너에 접속해서 암호를 가지고 와서 화면에 입력합니다.
      1. docker exec -it 20e3e7d7b78f /bin/bash
      2. cat /var/jenkins_home/secrets/initialAdminPassword
   
3. 정보들을 입력후 Jenkins 페이지가 뜨면 새로운 Item 을 클릭합니다.

   4. Item 이름을 입력하고 Freestyle project를 선택합니다.

   5. 연동할 Github Project URL과 Repository URL을 입력합니다.

   6. Build에서 Execute Shell을 선택하고 빌드시 사용할 스크립트를 작성합니다.

  7. Jenkins에서 생성한 Item에 들어가 Build Now를 클릭해주면 빌드가 진행됩니다.

8. Build 완료 후 클릭해서 Console Output을 클릭하면 Build 수행 로그를 확인할 수 있습니다.

* 혹시 EC2 프리티어에서 Jenkins를 실행중이고 Build시 젠킨스가 죽는 현상이 발생하면 https://ywook.tistory.com/35 참고하시면됩니다.

요즘 소프트웨어 개발에 가장 큰 변화는 배포 빈도입니다. 운영팀은 릴리즈를 운영에 더 자주, 빠르게 배포합니다

달 혹은 년 릴리즈 주기는 드물어 지고 있습니다.

오늘날, 서비스 지향 아키텍처 및 마이크로서비스 접근 방식을 사용하여 코드 기반의 모듈을 설계할 수 있습니다.

이를 통해 소스 수정과 배포를 동시에 할 수 있습니다.

하지만, 이런 변화는 운영, DevOps팀에 새로운 문제를 만듭니다. 잦은 배포는 사이트의 신뢰도와 고객들에게 부정적인 영향을 미칠 수 있습니다. 그래서 리스크를 최소화하는 배포 전략이 중요합니다.

Big Bang Deployment

Big Bang 배포는 어플리케이션의 전체 혹은 대부분을 한번에 업데이트 합니다. 그래서 릴리즈 하기전 광범위한 개발과 테스트 수행을 필요로 합니다.

특징

• 하나의 배포에 모든 중요 부분이 포함됨
• 기존 소프트웨어 버전을 한번에 새로운 것으로 교체함
• 오랜기간 개발 및 테스트를 거치고 배포함
• 롤백이 불가능할 수 있으므로 실패를 최소로 가정한다.
• 배포 완료 시간이 매우 오래걸린다.

Rolling Deployment

Rolling 배포는 어플리케이션의 버전을 점진적으로 교체하는 방식이다. 실제 배포는 오랜 기간동안 진행된다. 배포 동안 old, new 버전은 user experience, 기능에 영향을 주지 않으면서 동시에 존재하게 된다. 이러한 프로세스를 통해 새로운 component에 대해 더 쉽게 롤백할 수 있다.

즉, 서버를 한 대씩 구 버전에서 새 버전으로 교체해가는 배포전략이다. 이와 같은 방식은 서버 수의 제약이 있을 경우 유용하나 배포 중 인스턴스의 수가 감소하므로 서버 처리 용량을 미리 고려해야 한다.

Blue-Green

이 방법에서는 두개의 동일한 운영환경의 서버가 병렬로 동작한다.

하나는 현재 모든 트래픽을 받고 있는 운영 서버이고, 다른 하나는 운영 서버와 동일한 클론 서버다. 둘 다 모두 동일 환경, 설정을 가지고 있다.

새로운 버전 어플리케이션이 클론서버에 배포되고 기능 및 성능 테스트가 진행된다. 테스트 후 어플리케이션 트래픽을 기존 운영서버에서 새로운 클론서버로 전환한다.

만약 클론서버에서 문제가 발생할 경우 기존 운영서버로 트래픽을 전환하면 된다.

특징

• 빠른 롤백이 가능하다.
• 운영 환경에 영향을 주지 않고 실제 서비스 환경으로 테스트 할 수 있다.
• 자원이 두배로 필요하다.

Canary Deployment

Canary

• 우리가 흔히 알고 있는 카나리아 새를 의미한다. canary라 쓰는데 새 이름은 카나리아이다.
• 탄광에서 유독가스의 누출 위험을 알리는 용도로 사용됨
• 유독가스가 많이 누출되어 사람이 느낄 수 있게 되면 매우 위험한 상태
  • 유독가스에 민감한 카나리는 그 보다 먼저 반응하여 죽기 때문에, 누출을 사전에 인지 가능

새로운 어플리케이션 코드를 운영 인프라 일부에만 배포한다.

그리고 일부 트래픽을 새 버전으로 분산하여 영향을 최소화 한다.

오류가 없을 경우 새로운 버전의 코드는 점진적으로 나머지 인프라에 점진적으로 롤아웃한다.

Canary Deployment의 주요 챌린지는 일부 사용자를 새로운 어플리케이션으로 라우팅하는 것이다.

아래와 같은 방법으로 일부 사용자를 라우팅한다.

• 외부 사용자가 접속하기 전에 내부 사용자에게만 라우팅한다.
• Source IP ragnge를 기반으로 라우팅한다.
• 특정 지역에만 어플리케이션을 릴리즈 한다.
• 어플리케이션 로직을 사용하여 특정 유저, 그룹에게만 새로운 기능을 사용할 수 있도록 한다.

특징

• 카나리 버전에 심각한 버그가 발생된다고 해도 사용하는 사용자가 적기 때문에 피해 최소화 가능
• 안정적인 버전과 테스트 버전이 모두 배포된 상태이기 때문에 A/B 테스트, 블루그린 배포 가능

참고

- https://dev.to/mostlyjason/intro-to-deployment-strategies-blue-green-canary-and-more-3a3

- https://onlywis.tistory.com/10

- https://itwiki.kr/w/%EC%B9%B4%EB%82%98%EB%A6%AC