[CI/CD] Jenkins와 Gitlab 연동

 

 

COUPANG

"이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다."

 

🗂 목차

✅[CI/CD] Jenkins와 Gitea 연동
✅ [CI/CD] Jenkins와 Gitlab 연동
✅[CI/CD] Jenkins Trigger 정보 Discord로 보내기
✅[CI/CD] 정적 코드 분석 툴 SonarQube와 Jenkins 연동
✅[CI/CD] SonarQube를 통해 Code Convention 적용
✅[DevOps] JAVA Gradle JaCoCo (Code coverage) 설정하기
✅[DevOps] JAVA Gradle JaCoCo (Code coverage) 설정하기 (추가)
✅[CI/CD] Jenkins + Docker를 이용한 무중단 배포 - ① Application Linuxt(Ubuntu)에 SSH를 이용한 파일 전송
✅[CI/CD] Jenkins + Docker를 이용한 무중단 배포 - ② Create Docker Image And BackUp
✅[CI/CD] Jenkins + Docker를 이용한 무중단 배포 - ③ Application Server Docker Job ① Application 도커 존재 여부 확인)
✅[CI/CD] Jenkins + Docker를 이용한 무중단 배포 - ③ Application Server Docker Job (② Application Docker Run)
✅[CI/CD] Jenkins + Docker를 이용한 무중단 배포 - ③ Application Server Docker Job(③ Application Docker Health Check)
✅[CI/CD] Jenkins + Docker를 이용한 무중단 배포 - ④ NGINX Server Docker Job (① NGINX 각 종 설정)
✅[CI/CD] Jenkins + Docker를 이용한 무중단 배포 - ④ NGINX Server Docker Job (② NGINX Docker 존재 여부 확인)
✅[CI/CD] Jenkins + Docker를 이용한 무중단 배포 -④NGINX Server Docker Job(③ NGINX Docker Run & Health Check)
✅[CI/CD] Jenkins + Docker를 이용한 무중단 배포 - ④ NGINX Server Docker Job (③ NGINX 재 설정)





🤔 내가 만난 문제

⛔️ [Jenkins] java.lang.OutOfMemoryError: Java heap space

 

 

 

 

🚀 게시판 만들기 - 삭제

    🔽  개요

        📦 소개

안녕하세요? 이 전에 주니는 Jenkins와 Gitea를 연동하는 방법을 통해 CI/CD를 할 수 있도록 구성해 보았어요.

[CI/CD] Jenkins와 Gitea 연동

 

하.지.만 실무에서 Gitea를 쓰는 곳은 많지 않을 것으로 사료되고, 현재 보유한 서버에 자원이 넉넉해서 Gitlab-CE를 내부 서버에 설치하고, Jenkins와 연동해 보려고 해요.

Gitlab은 이렇게 설치했어요.

[Ubuntu] Docker gitlab 설치

 

 

[Gitlab][CI/CD] GitLab Runner 설치

 

 

 

    🔽 Jenkins  & GitLab 초기 구성

        📦 Gitlab SSH 연결 구성

최초 Client에서 Gitlab에 연결할 때, SSH를 이용한 Key 값으로 연결이 가능하게 하기 위해 작업을 해 볼게요.

주니는 위와 같이 도커를 이용해서 젠킨스를 설치해 주었어요. 도커를 이용한 젠킨스 설치 방법은 이렇게 했어요.

[가상화 - Container] Docker를 이용한 Jenkins 설치

 

젠킨스에서 Gitlab에 연결을 해야 하기 때문에 위 컨테이너에 접속해서 작업해 줄게요.

docker exec -it <Container ID> /bin/bash

위 명령어는 Container에 명령어를 전달하는데, /bin/bash 라는 명령어를 전달하여
Shell을 얻어오도록 해 주는 명령어에요.

 

apt-get update && apt-get upgrade

git Package를 설치할건데, 설치하기 앞 써 위와 같이 패키지를 최신화 해 주었어요.

 

apt-get install git

주니는 이미 설치가 되어 있으나, 설치가 되어있지 않을 수 있으니 위와 같이 명령어를 입력해 주었어요.

 

adduser jenkins_admin

최초 위와 같이 다른 서비스에서 접속하여 사용할 수 있는 계정을 만들어 주었어요.

 

ssh-keygen -t ed25519 -C "<gitlab Email 계정>"

728x90

위와 같이 SSH 접속용 서명 Key 쌍을 생성해 주었어요. 

- Enter file in which to save the key (/root/.ssh/id_ed25519): 이 부분은 Key 파일이 저장될 위치를 묻는 곳으로 Default Path는 해당 계정 Home Directory 밑에 .ssh 입니다.

- Enter passphrase (empty for no passphrase): 이 부분은 해당 Key 파일의 비밀번호를 입력하는 부분이에요. 만약 입력한다면 연동 시 반드시 필요하니 적어두는게 좋고, 필요없다면 그냥 엔터를 누르고 넘어가면 됩니다.

- Enter same passphrase again: 2번에서 비밀번호를 입력했다면 다시 한번 확인하기 위한 부분이에요.

 

chmod 700 ~/.ssh/id_ed25519*

만든 키 쌍에 대해 권한을 수정해 주었어요. jenkins_admin 이라는 사용자만 읽기, 쓰시, 실행 권한을 주었어요.

 

cat ~/.ssh/id_ed25519.pub

이렇게 cat 명령어를 통해 만들어진 키 쌍 중 공개키를 확인할 수 있는데,
이 공개키를 gitlab에 등록 시켜 주시 위해서 모든 부분을 다 복사해 줄게요. 

 

 

        📦 Gitlab 연결

gitlab에 접속한 뒤 위와 같이 프로필 편집(Edit profile)을 눌러 줍니다.

 

SSH 키(SSH Keys)를 눌러 줍니다.

여기서 새 키 추가를 눌러 키를 추가해 줄게요.

위와 같이 젠킨스 서버에서 만든 공개키를 붙혀 넣어주면 자동으로
Title Filed에 Email 주소가 들어가는 걸 확인할 수 있어요.

이 부분은 임의로 수정이 가능하기 때문에 주니는 아래처럼 변경해 주었어요.

만료일의 경우 해당 Key를 이용한 접속 만료일을 설정해 주는건데, 주니는 공란으로 두어 만료되지 않게 해 줄거에요.

여기까지 되었다면 키 추가(Add key)를 눌러줍니다.

위와 같이 키 등록을 성공하였어요.

 

 

 

        📦 Jenkins Plugin

이번에는 Jenkins(젠킨스)에서 필요한 Plugin(플러그인)을 설치해보도록 할게요.

위와 같이 플러그인 탭으로 이동해 줄게요.

반응형

위 사진처럼 Git plugins를 설치해 주어야 하는데, 주니는 이미 설치가 되어 있어요.

 

 

그리고 gitlab 플러그인도 설치해 줍니다.

플러그인 설치가 완료되면 재기동을 해주어야 해요.

 

이런식으로 해서 아래 플러그인들을 설치해 줄게요.

jenkins lts 설치시 설치되어 있는 플로그인: git plugin, Gradle Plugin

설치 필요 플러그인: GitLab, GitLab Brtanch Source Generic Webhook Trigger, Post build task, Docker, Docker Commons, Docker Pipeline, Docker API, SSH Agent, Multibranch Scan Webhook Trigger

 

 

        📦 GitLab Personal Access Token 발급

Main -> Profile Icon -> 환경설정

위와 같이 프로필 아이콘을 클릭하고, 환경 설정으로 들어가 줍니다.

Access Token(액세스 토큰) -> 신규 토큰 추가

위와 같이 새로운 토큰을 발급 받아 줄게요.

위와 같이 토큰 이름을 지정하고, 해당 토큰의 만료일을 지정하는데,
만료일을 비워두면 만료되지 않고 계속 사용할 수 있어요.

그리고, 범위 선택에서 사용할 역할에 대해 선택해 줍니다.

여기까지 되었다면 개인 액세스 토큰 생성을 눌러 토큰을 만들어 줄 수 있어요.

그럼 위와 같이 토큰이 생성되고, 여기서 Your new 개인 액세스 토큰을 따로 적어두는 걸 추천드려요.

 

 

        📦 GitLab Project API Token 발급

이번에는 배포 대상 Project(프로젝트)의 API 토큰을 발급 받아 볼게요.

최초 프로젝트에서 위와 같이 액세스 토큰으로 이동해 줍니다.

위와 같이 신규 토큰 추가를 눌러줄게요.

위와 같이 토큰 이름을 설정하고, 만료일을 공백으로 두어 만료되지 않게 하였어요.

역할에는 해당 프로젝트의 토큰을 통해 작업할 역할을 지정해 주었고, 범위는 모두 선택해 주었어요.
역할 선택의 경우 해당 토큰 사용을 어떨 때 하느냐에 따라 달라질 것이고,
범위 선택은 되도록 꼭 필요한 역할만 부여하는 걸 추천해요.

여기까지 되었다면 project access token 생성을 눌러 토큰을 생성합니다.

토큰의 경우 빨간 네모칸 표시의 아이콘을 누르면 클립보드에 복사가 돼요.

이 토큰을 젠킨스에 등록해 줄거에요.

 

 

 

 

        📦 Jenkins Personal Access Token Credentials 추가

Dashboard -> Jenkins 관리 -> Credentials

플러그인 설치가 완료되면 위와 같이 이동해 줍니다.

(global) -> Add credentials

그리고 위와 같이 이동해 줍니다.

최초 Kind 부분을 위와 같이 선택해 줄게요.
이 부분은 gitlab Access Token (인증 토큰)을 등록하는 곳이에요. 

위와 같이 gitlab 계정 인증용 토큰을 등록해 주었어요.

 

 

 

 

 

        📦 Jenkins Project API Token Credentials 추가

Dashboard -> Jenkins 관리 -> Credentials -> Global credentials(unrestricted)

이번엔 프로젝트 API 토큰 등록을 위해 다시 Credentials 등록을 진행해 볼게요.

위와 같이 kind를 GitLab API token으로 선택해 줍니다.

API token에 gitlab에서 발급한 토큰을 입력해주고, ID와 설명을 써 준 뒤 Create를 눌러 등록해 줄게요.

이렇게 두 개의 Credentials가 젠킨스에 등록 되었어요.

 

 

 

 

 

    🔽  Jenkins 설정

        📦 GitLab 연동

이번에는 젠킨스에서 gitlab 등록을 해주려고 해요.

Dashboard -> Jenkins 관리 -> System

gitlab 등록을 위해 위와 같이 System으로 이동해 줄게요.

스크롤을 내리다 보면 위와 같은 화면을 만나게 될거에요.
이 곳에서 작업해 볼게요.

최초 위와 같이 연결할 gitlab에 대한 구분을 위해 이름을 지어주고, Server URL에 gitlab 서버 주소를 입력해 줍니다.
Credentials에는 gitlab Personal Access Token에 대한 Credentials를 선택해 주면 돼요.

Web Hook (웹훅)은 일단 모두 선택해 주고, 자세한 내용은 아래에서 진행해 볼게요.

그런 뒤 아래에 Test connection을 눌러 위와 같이 나오면 정상 연결된 것이에요.


여기까지 되었다면 맨 밑에 저장을 눌러 System 창을 빠져 나와 줍니다.

 

 

 

        📦 Item 만들기

 

위와 같이 Item을 만들어 주는데, 주니는 Multibranch Pipeline으로 만들어 줄거에요.

해당 Item 이름을 Display Name에 적어주고, Description에 상세 설명을 적어 주었어요.

그런 뒤 Branch Sources 섹션에 Add source 버튼을 눌러줍니다.

여기서 GitLab Project를 선택해 줄게요.

그럼 위와 같이 나오게 될거에요.

종   류	상 세  내 용
Server	젠킨스 System에서 등록한 gitlab 정보가 자동으로 할당. 여러 gitlab 등록 시 선택 필요.
Checkout Credentials	Git 인증을 위한 Username과 Password 혹은 gitlab에서 발급한 Personal Access Token에 대한 Credentials 선택.
Owner	해당 Repository의 소유자 정보 입력. (개인 Repository 일 시 개인 gitlab ID를 명시하고, 조직으로 설정되어 있는 Repository의 경우 조직 이름을 명시)
Projects	위 3가지의 정보가 제대로 입력 되었을 경우 해당 소유자의 Repository 목록이 Dropdown 형식으로 보이게 되며, 배포를 진행할 Project 이름 선택.

이번엔 해당 Item에서만 사용할 수 있는 Checkout Credentials를 만들어 볼게요.

 

종   류	상 세  내 용
Kind	Credentials 종류.
Username	GitLab Username (ID).
Password	GitLab에서 발급받은 Personal Access Token.
ID	해당 Credentials를 구분한 Unique 문자열.
Description	해당 Credentials에 대한 상세 설명 기재.

주니는 Kind에 Username with password를 선택해 주고 진행해 주려고 해요.

Add 버튼을 눌러 등록해 줄게요.

생성한 Credentials를 선택해 줍니다.

현재 주니의 프로젝트는 조직으로 설정 되어 있기 때문에 gitlab에 위의 빨간색 네모칸의 표시된 정보와 같이 조직 정보를
Owner 부분에 명시해 주어야 해요.

그럼 위와 같이 Projects에 자동으로 프로젝트 목록이 보일텐데, 현재 주니는 한 개 밖에 없어서 바로 선택 되었어요.

 

이번엔 Behaviours에 대해 설정해 보도록 할게요.

최초 Discover branches는 탐색할 Branch를 선택할 수 있는 부분이에요.

이 부분은 위와 같이 총 세 가지 중 하나를 선택할 수 있어요.

종   류	상 세  내 용
Only branches that are not also field as MRs	Merge Request로 제출되지 않은 Branch만 탐색.
Only branches that are also field as MRs	Merge Request로 제출된 branch만 탐색.
All Branches	모든 Branch 탐색.

 

Discover pull requests from forks Strategy

주니는 모든 Branch(브런치)를 탐색할 수 있도록 All Branches를 선택해 줄거에요.

이 곳에서는 Pull Request가 어떻게 발견되는지 설정할 수 있어요.

종   류	상 세  내 용
Merging the merge request with the current target branch revision	현재 branch 버전과 병합된 요청에 대해 탐색.
The current merge request revision	각 Pull Requtest를 한 번씩 발견하고 병합하지 않고, Pull Requtest Head 리비전에 해당하는 리비전 검색.
Both the current merge request revision and the merge request merged with the current target branch revision	현재 병합 요청된 버전과 현재 branch 와 병합요청되어 병합된 버전에 대해 탐색.

이 곳에서 주니는 Merging the merge request with the current target branch revision 사용해 보려고 해요.

Discover pull requests from forks Trust

Repository에 대한 읽기 액세스 권한을 가진 모든 사용자가 Repository를 포크하고,
자신의 포크에 몇 가지 변경 사항을 적용한 다음,
변경 사항이 있는 원래 Repository에 대해 Pull Request를 만들 수 있어요.

이 곳에는 소스 코드 제어에 저장된 중요한 파일이 있을 거에요. 예를 들어 Jenkins 파일에는 악의적인 꺼내기 요청을 완화하기 위해 샌드박스 꺼내기 요청에 대한 구성 세부 정보가 포함될 수 있답니다. Jenkins 파일을 수정하여 보호를 제거하는 악의적인 꺼내기 요청 자체로부터 보호하기 위해 포크에서
꺼내기 요청에 대한 신뢰 정책을 정의할 수 있는 부분이 이 부분이에요.

즉, Fork된 Repository에 대해 병합 요청을 탐색하는 조건에 대해 설정해 주는 부분이에요.

종   류	상 세  내 용
Everyone	모든 곳에 대해 신뢰.
Members	Fork된 Repository의 Member인 경우 신뢰.
Nobody	Fork된 곳에서의 병합 요청은 모두 비 신뢰.
Trusted Memebers	Fork된 Repository에서 신뢰하는 Member인 경우 신뢰.

주니는 이 곳에서 Trusted Members를 선택해 줄거에요.

이번에는 Filter by name (with regular expression) 활성화를 위해 위와 같이 Add 버튼을 눌러 줄거에요.
이 부분은 Discover에서 선택한 Branch 전략 중 정규 표현식(Regular)를 사용하여 CI/CD를 유발할 Trigger 대상에
포함할 Branch를 다시 정하는 부분으로 설정할 수 있어요.

 

주니는 위와 같이 개발 환경용 Branch dev와 운영 환경용 Branch Master를 설정해 줄거에요.

이 곳에 입력되지 않은 Branch는 CI/CD Trigger가 발동되지 않아요.

이번에는 위와 같이 Filter by name (with wildcards)를 활성화 해 줄게요.

이 부분은 Discover 전략에 해당되는 Branch 중 *으로 대상에 포함할 Branch를 다시 선정해 주는 곳이에요.
Filter by name은 하나만 정해서 구성하는 것이 혼란스럽지 않을거에요.

이 곳도 마찬가지로 개발 환경용 Branch와 운영 환경용 Branch만 Trigger가 발동 되도록 설정해 주었어요.
Exclude에 특정 Branch 이름을 넣게 되면 해당 Branch는 Trigger가 발동되지 않게 막을 수 있어요.

이 곳 Build 설정 부분은 jenkins File을 읽을 수 있도록 설정해 주는 부분이에요.
주니는 소스 코드 내에 jenkins File을 둘 것이기 때문에 해당 위치를 위와 같이 지정해 주었어요.

Scan Multibranch Pipeline Triggers

이번엔 해당 Job을 통해 CI/CD가 걸릴 수 있는 Trigger 설정을 해 보도록 할게요.

두 항목을 모두 활성화 시켜 줄게요.

최초 pericdically if not otherwise run 설정이에요.

이 설정은 일부 폴더 유형은 외부 이벤트를 수신하는 즉시 자동으로 다시 인덱싱 되게 되요.
예를 들어, 다중 분기 프로젝트는 SCM 변경 알림을 수신할 때 SCM 저장소에서 새 분기 또는 제거되거나 수정된 분기를 다시 확인하게 된답니다. (푸시 알림은 각 분기 소스에 사용되는 SCM 플러그인에 따라 구성될 수 있습니다.) 그러나 이러한 알림은 때때로 신뢰할 수 없거나 Jenkins가 알림을 받기 위해 실행하지 않을 수도 있습니다. 예를 들어 젠킨스가 방화벽 뒤에 있고 외부 시스템만 폴링할 수 있기 때문에 즉각적인 알림이 불가능한 경우도 있습니다.

이 Trigger는 필요한 경우 주기적인 폴백을 허용합니다. 지정된 간격 동안 인덱싱이 수행되지 않은 경우 인덱싱이 예약됩니다. 예를 들어, 다중 분기 프로젝트의 경우 푸시 알림에 대해 소스 제어 시스템이 구성되어 있지 않은 경우 짧은 간격을 설정합니다(대부분의 사용자가 15분에서 1시간 사이를 선택함). 푸시 알림을 위해 소스 제어 시스템이 구성된 경우 푸시 알림이 손실된 경우 최대 허용 지연 시간에 해당하는 간격을 하루의 마지막 커밋으로 설정합니다. (이후 커밋은 어쨌든 인덱싱을 트리거해야 하고 커밋이 픽업되는 결과를 초래하므로 대부분의 사람들은 4시간에서 1일 사이를 선택합니다.)

Scan Multibranch Pipeline Triggers -> pericdically if not otherwise run

 

이 곳에서는 마지막 인덱싱 이후 인덱싱이 트리거되기 전에 경과할 수 있는 최대 시간을 설정할 수 있어요.
예: 간격('5m') // 또는 '2h', '7d', '5000ms', '60s'

주니는 이 설정을 1 day로 해 줄게요.

Scan Multibranch Pipeline Triggers -> Scan by Webhook

이 곳은 멀티브런치 검색 웹 훅 Trigger를 사용하여 
이 멀티브런치 작업의 검색을 Trigger할 수 있도록 설정할 수 있는 곳이에요.

위와 같이 ?를 누르게 되면 Payload URL 예시를 확인할 수 있어요.
토큰은 임의의 값을 넣어주고, JENKINS_URL/multibranch-webhook-trigger/invoke?token=[Trigger token] 을 미리 작성해놓고 아래에 webhook 추가 시 넣어주려고 해요.

좀 더 자세히 설명해 보자면

Trigger token 부에 들어갈 내용은 gitlab에서 Webhook 설정 시 Request header에 담을 Webhook Token을 지정해 주는 부분이에요. 즉, Webhook Token과 일치시킬 Token을 설정하는 부분이에요.
HTTP Request로 JENKINS_URL/multibranch-webhook-trigger/invoke?token=[트리거 토큰]
위의 URI를 이용해서 Token이 일치하는 경우 다중 분기 검색이 bi trigger 된답니다.

이 곳은 위에서 Gitlab Access Token 저장 시 이용했던 ID 값을 지정해 주면 된답니다.

이 부분 설정을 위해 gitlab에서 웹훅 생성을 해보려고 해요.

gitlab -> 프로젝트 -> 설정 -> 웹훅

위와 같이 웹훅 설정으로 들어가 줄게요.

그리고 새 웹훅 추가를 눌러 줍니다.

 

URL엔 위에서 미리 작성한 Trigger URL, Secret token은 Trigger Token을 넣어주었어요.

그리고 생성을 눌러줍니다.

만약 위와 같은 문제가 생기면 Local Network(로컬 네트워크)에 대한 Request(요청)이 허용되지 않는다는 것이에요.

이 부분을 해결해 볼게요.

 

최초 관리자 계정으로 로그인 한 뒤 위와 같이 관리자 영역으로 진입합니다.

 

그리고 위와 같이 두 개를 체크해 주고, 변경사항 저장을 눌러 줍니다.

다시 웹훅을 만들어 줄게요.

웹훅을 만들고, 잘 설정 되었는지 확인해 볼 수 있어요.

Test(테슽) 버튼을 누르면 여러 Event(이벤트)에 대해 테스트를 해볼 수 있어요.

주니는 푸쉬 이벤트 테스트를 진행해 보았고, 위와 같이 200 OK 응답을 받은걸 확인할 수 있어요.

다시 젠킨스로 돌아와서
위와 같이 설정이 모두 마쳤으면 맨 밑에 Save 혹은 저장을 눌러 해당 설정창을 나가도록 합니다.

 

 

COUPANG

"이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다."

 

 

 

🧐 참고 자료

[CI/CD] Jenkins와 Gitea 연동

https://giggal-people.tistory.com/entry/CICD-Jenkins-Node-%EC%B6%94%EA%B0%80%ED%95%98%EA%B8%B0