[CI/CD] Jenkins와 Gitea 연동

 

 

 

 

 

젠킨스 마스터

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

 

 

 

 

 

 

 

🗂 목차

⚠️ 아래 목차 중 몇몇개의 링크가 걸리지 않는 문제로 글 맨 하단에 다음 글로 이동할 수 있게 해 두었습니다.

✅ [CI/CD] Jenkins와 Gitea 연동
✅ [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) 설정하기 (추가)(https://junyharang.tistory.com/392)
✅ [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)(https://junyharang.tistory.com/406)
✅ [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 무중단 배포 구성도

 

 

 

 

 

deploy Directory Path

 

        📦 소개

안녕하세요?

오늘은 Jenkins와 Gitea를 연결하여 CI/CD 하는 방법을 진행해보려고 해요.

주니는 Git Hub이나, Git Lab을 사용하지 않고, 내부 서버에 Gitea를 구성했고, 그 곳을 통해 형상 관리를 하고 있어요.

주니가 만든 Gitea 설치 방법에 대해서는 이 곳에 준비해 두었어요.

[Synology NAS] 나만의 GitHub 만들기 - Git Server와 Gitea 설치

그리고, Jenkins도 설치해 주어야 하는데, 주니는 Docker를 이용해서 Jenkins를 구성해 주었어요.

이 역시 설치 방법은 이 곳에 준비해 두었어요.

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

 

 

    🔽  Jenkins 구성

        📦 Gitea 연결

최초 Jenkins와 Gitea와 연결해 보려고 해요.

Jenkins 관리 -> PlugIn Manager

구성을 하기 전 Gitea와 연결을 위해 PlugIn을 설치해 주어야 해요.
위와 같이 Gitea PlugIn을 받아 주도록 할게요.

Jenkins 관리 -> 시스템 설정

이번에는 시스템 설정으로 들어가서 Gitea 연결 작업을 해 줄게요.

Jenkins 관리 Configure System -> Gitea Servers

위와 같이 Gitea 이름을 Name에 지정해 주고, Gitea IP 주소를 입력해 줍니다.

그런 뒤 Add를 눌러 Credentials를 등록해 주도록 할게요.

Gitea -> 설정 -> 애플리케이션

Credentials 등록을 위해 Gitea에서 Access Token 값을 만들어 주려고 해요.

Token 이름을 입력하고, 생성을 누르면 위와 같이 Access Token이 발급되는 것을 확인할 수 있어요.

이 값을 복사하여 Jenkins에 넣어줄거에요.

Jenkins에서 위와 같이 Kind 부분에 Gitea Personal Access Token을 선택해 줄게요.

Token에는 Gitea에서 발급 받은 Access Token 값을 입력해 줍니다.
ID 부분은 해당 Credentials의 이름을 지정해 주는 곳이고, Description은 해당 Credentials에 대한
상세 내용을 입력해 주면 됩니다.

그런 뒤 Add를 눌러줄게요.

Credentials에 위에서 만든 ID를 찾아 선택을 해주면 위와 같이 Gitea Version이 나오게 되요.
만약 Version이 나오지 않는다면 Network 연결이 되지 않거나, Access Token이 제대로 설정되지 않은 거에요.

위와 같이 되었다면 제일 밑에 저장 혹은 Save를 눌러 설정창을 나가 줍니다.

반응형

        📦 Multibranch Pipeline Job 구성

이제 Jenkins에 Multibranch Pipeline Job을 만들어 보려고 해요.
Multibranch Pipeline은 개발 환경에 Server와 운영 환경에 Server가 각각 다를 때, 사용할 수 있어요.

주니는 두 서버 환경을 다르게 구성했기 때문에 개발 환경은 개발 환경에 맞는 Server에 운영 환경은 운영 환경에 맞는 Server에 Application이 올라갈 수 있도록 구성해 보려고 해요.

Jenkins 관리 -> PlugIn Manager

최초 위와 같이 Multibranch Scen Webhook Trigger PlugIn을 설치해 주도록 할게요.

Jenkins Main 화면 왼쪽에 새로운 Item을 선택해 줄게요.

이 곳에서 Enter an Item name에 해당 Job 이름을 입력해 주고, Multibranch Pipeline을 선택해 줄게요.

그리고, 밑에 OK를 눌러줍니다.

위와 같이 설정창이 나오면 Gitea와 Webhook 연결을 위한 설정을 해 줄 수 있어요.

Display Name

최초 해당 Job에 이름을 지정해 줍니다.

최초 Branch Sources에서 위와 같이 Gitea를 선택해 줄게요.

최초 이 곳에서 이 전에 Gitea 연결을 위해 설정했던 값들을 선택해 주면 된답니다.

다만 Credentials 부분에는 연결하고자 하는 Repository가 Public이라면 입력하지 않아도 되지만,
Private이라면 반드시 입력해 주어야 해요.

현재 Jenkins와 Gitea가 연결되어 있는 상태 이기 때문에 Owner에 연결하고자 하는 Repository 소유자의 Gitea ID(Username)을 넣어주면 Respository 부분에 해당 소유자가 소유하고 있는 Repository 목록이 나타날거에요.

알 맞는 것을 설택해 주면 됩니다.

 

Discovery branches의 Strategy는 여러 항목을 선택할 수 있어요.

종      류	상 세 내 용
only branches that are not also filed as PRs	Pull Request로 제출되지 않은 Branch만 Trigger
only branches that are also filed as PRs	Pull Request로 제출된 Branch만 Trigger
All branches	모든 Branche Trigger
Only branches that are also filed as PRs or master / main branch	Pull Request로 제출된 Branch 또는 Master / Main Branche만 Trigger

모든 Branch에 Trigger를 걸게 되면 Jenkins는 정신없이 일하게 될 거고, 서버 자원도 낭비되는 결과가 나올 거에요.

주니는 Only branches that are also filed as PRs or master / main branch 를 선택하여 구성해 보려고 해요.

Discover pull requests from forks Strategy

이 곳에서는 풀 요청이 어떻게 발견되는지 설정할 수 있어요.

종      류	상 세 내 용
Merging the pull request with the current target branch revision	대상 Branche의 현재 내용과 병합 된 결과에 해당하는 발견 된 수정 사항에서 각 Pull Request를 발견하여 동작
The current pull request revision	각 Pull Requtest를 한 번씩 발견하고 병합하지 않고, Pull Requtest Head 리비전에 해당하는 리비전 검색
Both the current pull request revision and the pull request merged with the current target branch revision	각 Pull Request을 두 번 검색. 첫 번째로 발견된 수정 사항은 각 검색에서 대상 분기의 현재 개정판과 병합한 결과에 해당. 두 번째 병렬로 발견된 리비전은 병합하지 않고 풀 요청 헤드 리비전에 해당.

주니는 Merging the pull request with the current target branch revision 사용해 보려고 해요.

Discover pull requests from forks Trust

Repository에 대한 읽기 액세스 권한을 가진 모든 사용자가 Repository를 포크하고, 자신의 포크에 몇 가지 변경 사항을 적용한 다음, 변경 사항이 있는 원래 Repository에 대해 Pull Request를 만들 수 있어요.
이 곳에는 소스 코드 제어에 저장된 중요한 파일이 있을 거에요. 예를 들어 Jenkins 파일에는 악의적인 꺼내기 요청을 완화하기 위해 샌드박스 꺼내기 요청에 대한 구성 세부 정보가 포함될 수 있답니다. Jenkins 파일을 수정하여 보호를 제거하는 악의적인 꺼내기 요청 자체로부터 보호하기 위해 포크에서 꺼내기 요청에 대한 신뢰 정책을 정의할 수 있는 부분이 이 부분이에요.

종      류	상 세 내 용
Nobody	포크에서 Pull Request는 모두 비 신뢰 처리. 즉, Jenkins가 신뢰할 수 있는 파일(예: Jenkins 파일)을 요구하는 경우 해당 파일의 내용이 포크 Repository의 Pull Request 분기가 아닌 Origin Repository의 대상 분기에서 검색.
Contributors	공동작업자에서 Origin Repository로 Pull Request는 신뢰할 수 있는 것으로 처리되고, 포크 Repository의 다른 모든 Pull Request는 신뢰할 수 없는 것으로 처리. Jenkins가 저장소를 검색하는 데, 사용한 자격 증명에 Origin Repository에 대한 기여자 목록을 Query 할 수 있는 권한이 없는 경우 Origin 계정만 신뢰할 수 있는 것으로 처리. 즉, 'Nobody' 설정과 같이 반환.
Everyone	포크의 모든 Pull Request는 신뢰할 수있는 것으로 취급 주의: 이 옵션은 외부 가입을 허용하는 Gitea에서 호스팅 된 공개 저장소에서 사용하는 경우 위험.

이 부분에서는 주니는 Everyone을 선택해 주려고 해요.

주니가 현재 구성한 Gitea는 내부 서버에서 구현이 되어 있고, 외부에서는 VPN 연결이 없다면 접속할 수 없기 때문이에요.

 

그런 뒤 위와 같이 Add 버튼을 눌러 Filter by name (with regular expression)을 선택해 활성화 해 줄게요.

이 부분은 Discover에서 선택한 Branch 전략 중 정규 표현식(Regualr)을 사용하여 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 Configuration

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

Scan Multibranch Pipeline Triggers

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

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

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

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

이 트리거는 필요한 경우 주기적인 폴백을 허용합니다. 지정된 간격 동안 인덱싱이 수행되지 않은 경우 인덱싱이 예약됩니다. 예를 들어, 다중 분기 프로젝트의 경우 푸시 알림에 대해 소스 제어 시스템이 구성되어 있지 않은 경우 짧은 간격을 설정합니다(대부분의 사용자가 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 token 부에 들어갈 내용은 Gitea에서 Webhook 설정 시 Request header에 담을 Webhook Token을 지정해 주는 부분이에요. 즉, Webhook Token과 일치시킬 Token을 설정하는 부분이에요.
HTTP Request로 JENKINS_URL/multibranch-webhook-trigger/invoke?token=[트리거 토큰]
위의 URI를 이용해서 Token이 일치하는 경우 다중 분기 검색이 bi trigger 된답니다.

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


이렇게 설정이 모두 마쳤으면 맨 밑에 Save 혹은 저장을 눌러 해당 설정창을 나가도록 합니다.

Scan Multibranch Pipeline Log

Log를 확인해 보면 위와 같이 Jenkinsfile을 찾을 수 없다고 나오는 것을 확인할 수 있어요.
왜냐하면? 안 만들어줬기 때문이에요!

 

728x90

 

        📦 Jenkins File 구성

이번에는 Jenkins File을 소스 코드 Project에 만들어 보도록 할게요.
Jenkins 자체 내에 해당 설정을 해 줄 수도 있지만, 주니는 Source Code 상에 넣는 방식을 선택하려고 해요.

최초 Project Root Directory 밑에 위와 같이 deploy Directory를 만들어 주었어요.

그리고 하위 Directory에 jenkins Directory를 만들어 주었어요.

그리고 그 밑에 위와 같이 Jenkins File을 만들어 줄게요.

 

jenkinsfile

 

pipeline {
    agent any
        stages {
            stage('stage 1') {
                steps {
                    echo "Hello, Juny!! 😀"
                }
            }
        }
}

Trigger Test를 위해 위와 같이 임시로 작성을 해 보았어요.

그런데, InteliJ에서 Groovy 형식의 Jenkins File이 인식 되지 않아 중괄호(Braces) 끝나는 부분도 가독성이 떨어지고,
뭔가 인식 되지 않은 느낌이에요.

이에 대한 해결 방법은 이 곳에 정성스럽게 준비해 두었어요.

[InteliJ] jenkinsfile Groovy 문법 활성화

 

여기까지 되었으면 Jenkins에 Jenkinsfile을 인식 시켜 주기 위해 Gitea로 Push를 해 주도록 해 볼게요.

Gitea에 정상적으로 jenkinsfile이 올라간 것을 볼 수 있어요.

Scan Multibranch Pipelien Log

Log를 다시 보면 이번에는 Jenkins file을 찾았다고 하는 것을 확인할 수 있어요.

 

        📦 Gitea Webhook 설정

이번에는 Gitea에서 Webhook 설정을 해보도록 할게요.

Gitea 대상 Repository -> 설정 -> 웹훅

최초 Gitea에 대상 Repository에 위와 같이 설정에서 웹훅으로 들어가 줄게요.

그런 뒤 webhook 추가를 눌러줍니다.

이 곳에서 Gitea를 선택해 줄게요.

최초 대상 URL에는 위에서 Jenkins를 통해 Job을 설정할 때, 

위에서 입력한 값을 {Jenkins Scan by webhook Trigger token Value} 이 부분을 지우고 넣어주면 되요.

참고로 URL 부분에 Jenkins IP 부분에는 80 Port가 아니라면 Jenkins IP 뒤에 :Port Number를
같이 입력해 주어야 해요.

예: http://192.168.0.100:8080


나머지는 기본값으로 두고, 주니는 Branch filter를 위와 같이 설정해 주었는데,
dev와 master Branch에 대한 Push Event만 Webhook이 동작하게 하기 위함이에요.

위와 같이 설정이 완료되면 Webhook 추가를 눌러 줍니다.

그런 뒤 밑 부분에 전달 시험을 눌러 위와 같이 Response Code가 200이 오는지 확인해 주어야 해요.

만약 200이 오지 않는다면 Gitea와 Jenkins 통신이 되지 않는 것일거에요.

vim /etc/gitea/app.ini

그럴 땐 Gitea가 설치 되어 있는 Server에서 위와 같이 app.ini File을 수정해 줄 필요가 있어요.

app.ini 87 ~ 89

위와 같이 ALLOWED_HOST_LIST 즉, 허용해줄 Host 목록을 통해 Jenkins의 정보를 넣어주거나,
주니처럼 *을 넣어 모두 통신이 되도록 해 주어야 하고, 89번째 줄에 DISABLE_WEBHOOKS를 false로 해주어 Webhook이 막히지 않도록 설정해 주어야 해요.

jenkinsfile

정상적으로 되는지 확인을 위해 jenkins File을 수정하고, 다시 Gitea의 Master Branch로 Push 해 볼게요.

master로 Push를 하자 바로 Jenkins Trigger가 걸렸고, 위와 같이 성공한 것을 확인할 수 있어요.

위와 같이 Jenkins File에 설정한 내용이 정상적으로 처리된 걸 확인할 수 있어요.

 

 

 

 

 

    🔽  Jenkins File

        📦 Jenkins이란?

주니는 위에서 Jenkins와 Gitea를 연결하고, Trigger가 제대로 걸리는지 확인까지 해 주었어요.

이제 본격적인 작업에 앞 써 Jenkins File이 무엇인지 알아보고 진행해 볼게요.

그 전에 Jenkins File을 작성하는 방법은 두 가지가 있는데, 선언형(Declarative)과 스크립트형(Scripted)가 존재해요.

1. Pipe Line Script 작성 방식 두가지
  1)Declarative
  2)Scripted(Groovy + DSL)

2. 차이점
  - 시작 시 유효성 검사 유무
    - 특정 Stage 실행 가능 여부
    - 제어문
    - Option
    - 각각의 Pipe Line을 진행하다가 어떤 작업이 실패했을 때,Declarative방식은 그 다음 단계를 진행하지 않고,         
Scripted방식은 그 다음 단계를 진행.

 

Declarative 방식

pipeline {
	agent any
    stage {
    	steps('build') {
        	//
        }
        
        steps('test') {
        	//
        }
        
        steps('deploy')	{
        	//
        }
}

 

1. agent : Jenkins Server를 기동할 때, Master Server와 Slave Server로 구성할 수 있는데, 어떤 Server에
                      Jenkins를 실행할지를 지정. any를 지정했을 때는 구성된 Server 중 어떤 Server도 관계 없으니
                      실행하겠다는 의미.

2. Stages : 구성하고자 하는 각각의 단계에 대한 내용을 삽입.

  1)build: build Stage 선언 및 하위에 build Stage에 필요한 작업 명령어 등 입력.
  2)test: test Stage 선언 및 하위 test Stage에 필요한 작업 명령어 등 입력.
  3)deploy: deploy Stage 선언 및 하위 deploy Stage에 필요한 작업 명령어 등 입력.

Jenkinsfile

🧐 참고 자료

[DevOps] Jenkins를 이용한 CI/CD Pipeline 구축 - Advenced Jenkins 사용 ① - Pipeline

 

젠킨스 마스터

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

 

 

다음 글: [CI/CD] Jenkins Trigger 정보 Discord로 보내기