Jenkins 와 Docker 를 이용한 Bitbucket CI / CD

콜트·2022년 5월 19일
0

Jenkins를 이용한 CI/CD 파이프라인 작업을 해야할 일이 있었다. 해당 작업을 진행하면서 그 과정을 기록한다. 필자는 도커를 이용해서 Jenkins 와 ubuntu 컨테이너를 띄운 환경에서 진행했음을 미리 밝힌다.

본 환경에서는 Bitbucket 을 이용하지만, GitHub를 이용해도 크게 달라지지는 않을 것이다. 아마 달라진다면 GitHub Repository에 대한 SSH Key Access, webhook 설정 부분에 약간의 차이가 있을 것이다.

1. Jenkins + Bitbucket 환경 설정

본 가이드는 Jenkins 의 설치가 완료되었고, Docker를 약간 사용할 줄 안다고 가정한다(Docker, Local, Web 환경 등).

Docker를 사용하여 구성한다면, Jenkins - Official Image | Docker Hub 참조(jenkins/jenkins:lts 이미지를 대신 사용할 것).

1-1. Bitbucket Plugin 설치

Bitbucket 을 사용하므로, Bitbucket 플러그인을 설치한다.

1-1-1. Jenkins 관리 → 플러그인 관리

1-1-2. 설치 가능 → Bitbucket 검색 및 Bitbucket Plugin 설치(재실행 하지 않아도 됨)

1-1-3. 설치 완료

1-2. New Item 생성

1-2-1. 파이프라인 설정을 위해 새로운 Item 을 생성한다.

1-2-2. Freestyle project 생성

1-3. Jenkins Pipeline Settings

1-3-1. Freestyle project 생성이 완료되면 아래와 같이 설정 화면에 진입할 수 있다.

1-3-2. 소스 코드 관리 설정

Repository URL 에 연결할 git repository 주소를 입력한 뒤, Credentials 를 생성한다.

아래와 같이 Credentials 설정을 진행한다(SSH Credentials Plugin).

브랜치 설정은 아래와 같이 직접 입력하여 원하는대로 진행할 수도 있고 환경변수를 사용하도록 설정할 수도 있다.

그 외에도 우측의 ? 를 누르면 여러가지 설정 방법을 볼 수 있다.

1-3-3. 빌드 유발 설정

아래와 같이 Build when a change is pushed to BitBucket 에 체크한다.

1-4. Bitbucket Repository Settings

1-4-1. Webhook 설정

Bitbucket Repository → Repository settings → Webhooks 메뉴로 이동.

아래와 같이 Webhook 을 입맛에 맞게 설정해준다. Triggers 에 설정된 동작이 현재 Repository에서 수행되면 Webhook이 Jenkins 로 날아가게 된다.

이때, URL은 반드시 /bitbucket-hook/ 으로 끝나야 한다(/ 생략하지 말 것).

이제 Repository 에 변경사항을 Push 하면 Jenkins에서 Bitbucket Webhook을 받아 자동으로 build를 진행하는 것을 확인 할 수 있다.

localhost 에서 webhook 테스트를 진행하고자 한다면 ngrok 라는 툴을 사용해볼 수 있겠다.
Outsider 님의 블로그 에 잘 설명되어 있다.

2. Jenkins Build 설정 및 Download Artifacts

2-1. Build 설정

설정을 진행하기 전에, 먼저 Gradle Plugin 을 설치하도록 한다.

이후, 구성 → Build 탭 → Add build step → Invoke Gradle script 선택한 뒤, 아래처럼 설정해준다.

Wrapper location은 Gradle Plugin 이 알아서 찾아준다고 하므로, 비워두었다.

만약 build 시에 test(또는 그 외에 Gradle check Task에 속한 작업들)까지 모두 수행하고 싶다면 Tasks 에 bootJar대신 build 를 입력하도록 한다.

2-2. jar 파일 저장

빌드의 결과물인 jar 파일을 저장해야 하므로, 빌드 후 조치 탭에서 Archive the artifacts 항목을 선택하여 아래와 같이 설정한다.

2-3. jar 파일 다운로드

빌드의 결과물인 jar 파일을 다운로드 하는 방법은 아래와 같다.

대시보드를 통해 파이프라인을 실행한(또는 배포를 시도한) 프로젝트를 클릭해서 들어간다.

‘작업공간’ 메뉴에 진입한다.

‘작업공간’ 메뉴에 진입하면 아래와 같은 화면이 나온다.

여기서, 파이프라인에 설정해준 디렉토리로 찾아가면 아래와 같이 jar 파일이 존재하는 것을 볼 수 있고, 해당 파일을 클릭하면 다운로드 할 수 있다.

3. Jenkins + Deploy 설정 (with Publish Over SSH plugins)

3-1. Plugins 설치 및 설정

Jenkins 의 Plugins 중에서 Publish Over SSH 를 설치하도록 한다.

그 다음으로 Jenkins 관리 메뉴 - 시스템 설정에 진입하면,

아래와 같이 Publish over SSH 항목이 생겼을 것이다.

이 메뉴에 추가해준 SSH Server 에 대한 설정을 바탕으로 Deploy 가 이루어지게 된다.

사진에서 보이는 공란들은 Jenkins 에 등록된 SSH Server 에 일괄적으로 Default 설정을 적용하고 싶을 때 사용하면 된다.

추가 버튼을 누른 뒤, 고급 버튼을 누르면 아래와 같은 화면을 볼 수 있는데, 각각의 항목들의 설명을 읽어보고 잘 채워넣도록 하자.

이때, Use password authentication, or use a different key 항목에 체크하도록 한다. 그러면 아래와 같은 화면을 추가로 볼 수 있다.

3-1-1. SSH Server 연결 설정

3-1-1-1. 비밀번호를 이용한 SSH 연결 설정

비밀번호를 사용한 연결 설정을 하고 싶다면 Passphrase / Password 항목에 비밀번호를 입력하면 된다. 단, 이 비밀번호는 앞선 항목중에서 현재 등록하려는 SSH Server 의 Username 에 해당하는 비밀번호를 입력해야 한다. 그리고 나머지 항목들은 비워두면 된다.

3-1-1-2. SSH Key 를 이용한 연결 설정

SSH Key 를 이용한 연결 설정을 하고 싶다면 기본적으로 Key 를 제외한 모든 항목은 비워두도록 한다.

그리고 Jenkins 에서 접속하고자 하는 SSH Server 에서 ssh-keygen 을 이용하여 SSH Key 를 생성한다(이름과 생성 디렉토리는 자유롭게 입력. 이때 생성되는 SSH Key의 디렉토리와 이름 기본값을 확인할 수 있다).

이때, SSH Key 의 타입이 있는데 RSA, OPENSSH 가 있다. Mac에서 아무런 옵션도 주지 않고 ssh-keygen 명령을 실행하면 아래와 같이 OPENSSH 타입의 Key 가 생성된다.

SSH Key 를 생성했다면 -----BEGIN OPENSSH PRIVATE KEY----- 부터 -----END OPENSSH PRIVATE KEY----- 까지의 내용을 Jenkins 설정 항목 중 Key 항목에 입력한다.

다음으로는, SSH Server의 root directory 를 뒤져보면 .ssh 디렉토리가 보일 것이다. 못 찾겠으면 find -name ".ssh" 명령어로 찾아보자.

해당 디렉토리 안에 authorized_keys 파일을 만들고 방금 우리가 Key 항목에 넣어준 Private SSH Key 와 함께 생성된 Public key 를 입력해준다.

다음으로는 각각의 파일마다 권한을 설정해주어야 한다. 아래의 명령어를 이용해 authorized_keys 파일은 700, id_rsaid_rsa.pub 파일은 600 으로 설정해준다.

chmod 700 authorized_keys
chmod 600 id_rsa
chmod 600 id_rsa.pub

그리고 openssh-server 를 설치해준 뒤 sshd 를 실행해준다(필자의 환경은 도커를 이용해 구성되었으며, SSH Server 이미지는 Ubuntu 임을 고려하자).

3-1-1-3. SSH 연결 테스트

마지막으로 아래에 보이는 Test Configuration 버튼을 누르면 왼쪽 하단과 같이 Success 문구를 볼 수 있다. 즉, 연결이 잘 된 것이다.

3-2. Deploy 설정

아래와 사진과 같이 배포하고자 하는 프로젝트의 구성 으로 진입한다.


그러면 아래와 같은 화면을 볼 수 있다.

여기서 소스 코드 관리, 빌드유발 등등.. 여러 가지 설정들을 할 수 있는데, 이러한 것들은 CI 라고 볼 수 있고, 우리가 하려는 것은 배포이다. 즉, CD 를 말한다. 이를 위해서 Build 항목에 설정을 추가하도록 한다.

3-2-1. Build & Send files(or artifacts) 설정

3-2-1-1. Send files or execute commands over SSH

Build 항목에 존재하는 Add build step 버튼을 누르면 아래와 같이 드롭다운 메뉴가 보이는데, 그 중에서 Send files or execute commands over SSH 를 선택하여 파일을 전송하는 방법이 있다.

간단한 예시로, 아래와 같이 build step 을 추가하여 등록된 SSH Server 에 파일을 전송할 수 있다. build step은 추가한 순서대로 실행됨에 주의하도록 하자.

좌측 메뉴의 Build Now 를 클릭해서 빌드를 진행한 뒤 SSH Server 의 remote directory 를 확인해보면 파일이 전송되어 있는 것을 확인할 수 있다(첫번째 ls 명령어 → 빌드 전, 두번째 ls 명령어 → 빌드 후).

3-2-1-2. Send build artifacts over SSH

빌드 후 조치 항목의 빌드 후 조치 추가 버튼을 클릭하면 아래와 같이 드롭다운 메뉴를 볼 수 있다. 그 중에서 Send build artifacts over SSH 를 선택한다.

그러면 아래와 같이 SSH Server 를 등록하는 창이 나오는데, 적절한 값을 입력하여 등록해준다.

위 작업 자체는 빌드가 완료된 이후에 실행되는 것으로, Build 항목에서 Add build step 을 통해 적절한 빌드 과정을 정의해주어야 한다.

그리고 마찬가지로 Build Now 버튼을 클릭해서 빌드를 진행하면 아래와 같이 SSH Server 에 파일이 전송되어 있는 것을 볼 수 있다.

3-2-2. Exec command 설정

우리의 목표는 애플리케이션을 SSH Server에 배포하는 것이다.

따라서 파일을 옮긴 뒤(애플리케이션을 배포한다면 여기서는 애플리케이션 실행 파일이 될 것이다) 애플리케이션의 실행까지 완료해야 배포가 끝난 것이라고 할 수 있다.

2-1-2. Send build artifacts over SSH 예제에서 success.txt 파일이 생성된 것을 볼 수 있는데, SSH Server 를 등록해줄 때 Exec command 에 해당 파일을 생성하는 스크립트를 작성해놓았기 때문이다. 이는 2-1-1. Send files or execute commands over SSH 예제에서도 마찬가지로 적용할 수 있다.

즉, Exec command 항목에 각자의 설정에 맞춰 SSH Server 에서 애플리케이션을 실행시키는 스크립트를 작성해주면 된다.

참고자료

profile
개발 블로그이지만 꼭 개발 이야기만 쓰라는 법은 없으니, 그냥 쓰고 싶은 내용이면 뭐든 쓰려고 합니다. 코드는 깃허브에다 작성할 수도 있으니까요.

0개의 댓글