[CI/CD] Jenkins/gitea 연동 테스트

CI/CD 환경에서 가장 중심이 되는 Jenkins와 git연동 결과를 공유하려 합니다.

-  구성은 git,gitea 서버/ Jenkins 서버를 기준으로 테스트

-  PC에서 git으로 git서버에 소스반영

-  Jenkins 버젼 : 2.204 Ubuntu 설치 ( 먼저 jdk 설치 1.8 openjdk 추천)

-  서버사양 git: aws t2.medium, Jenkins: aws t2.small

 

 

Git관련 이론정보

-원격 저장소(Remote Repository) :

  파일이 원격 저장소 전용 서버에서 관리되며 여러 사람이 함께 공유하기 위한 저장소입니다.

-로컬 저장소(Local Repository) :

  내 PC에 파일이 저장되는 개인 전용 저장소입니다.

-각 커밋에는 영문/숫자로 이루어진 40자리 고유 이름이 붙습니다. 저장소에선 이 40자리 이름을 보고 각 커밋을

 구분하고 선택합니다.

-Git에서는 폴더 -> '작업 트리'(Work Tree)

      * 작업트리 -> 인덱스 -> 저장소

-Git의 '커밋' 작업은 '작업 트리'에 있는 변경 내용을 저장소에 바로 기록하는 것이 아니라 그 사이 공간인 '인덱스'에

 파일 상태를 기록(stage - 스테이징 한다고 표현하기도 합니다)하게 되어 있습니다.

 따라서 저장소에 변경 사항을 기록하기 위해서는, 기록하고자 하는 모든 변경 사항들이 '인덱스'에 존재해야 합니다.

 예를 들어, 10개의 파일을 수정했지만 그 중에 7개만 저장소에 공개하고 싶을 때를 생각해 보세요.

 변경한 10개의 파일 중 7개를 선택하는 작업이 바로 '인덱스에 등록' 또는 '스테이징(stage)'이라 표현하는 작업 입니다.

 이렇게 인덱스란 공간(가상이지만요!)이 중간에 있는 덕분에 작업 트리 안에 있는 커밋이 필요 없는 파일들을 커밋에

 포함하지 않을 수 있고, 파일에서 내가 원하는 일부 변경 사항만 인덱스에 등록해 커밋할 수 있습니다.

 

푸시(Push) : 웹 상의 원격 저장소로 변경된 파일을 업로드

클론(Clone) : 원격 저장소의 내용을 통째로 다운로드

풀(Pull) : 원격 저장소에서 로컬 저장소로 업데이트 (다운로드)

브랜치(Branch) : 여러 사람이 동일한 소스코드를 기반으로 서로 다른 작업을 할 때에는 각각 서로 다른 버전의 코드가 만들어 질 수 밖에 없습니다.

이럴 때, 여러 개발자들이 동시에 다양한 작업을 할 수 있게 만들어 주는 기능이 바로 '브랜치(Branch)' 입니다.

각자 독립적인 작업 영역(저장소) 안에서 마음대로 소스코드를 변경할 수 있지요.

이렇게 분리된 작업 영역에서 변경된 내용은 나중에 원래의 버전과 비교해서 하나의 새로운 버전으로 만들어 낼 수 있습니다.

병합(Merge) : 이렇게 만들어진 브랜치는 다른 브랜치와 병합(Merge)함으로써, 작업한 내용을 다시 새로운 하나의 브랜치로 모을 수 있습니다

여러 명이서 동시에 작업을 할 때에 다른 사람의 작업에 영향을 주거나 받지 않도록, 먼저 메인 브랜치에서 자신의 작업 전용 브랜치를 만듭니다.

그리고 각자 작업을 진행한 후, 작업이 끝난 사람은 메인 브랜치에 자신의 브랜치의 변경 사항을 적용합니다.

이렇게 함으로써 다른 사람의 작업에 영향을 받지 않고 독립적으로 특정 작업을 수행하고 그 결과를 하나로 모아 나가게 됩니다.

이러한 방식으로 작업할 경우 '작업 단위', 즉 브랜치로 그 작업의 기록을 중간 중간에 남기게 되므로 문제가 발생했을 경우 원인이 되는 작업을 찾아내거나 그에 따른 대책을 세우기 쉬워집니다.

master 브랜치 : 저장소를 처음 만들면, Git은 바로 'master'라는 이름의 브랜치를 만들어 둡니다. 이 새로운 저장소에 새로운 파일을 추가 한다거나 추가한 파일의 내용을 변경하여 그 내용을 저장(커밋, Commit)하는 것은 모두 'master' 라는 이름의 브랜치를 통해 처리할 수 있는 일이 됩니다.

'master'가 아닌 또 다른 새로운 브랜치를 만들어서 '이제부터 이 브랜치를 사용할거야!'라고 선언(체크아웃, checkout)하지 않는 이상, 이 때의 모든 작업은 'master' 브랜치에서 이루어 집니다.

 

Jenkins 설치 

Jetty 사용 설치  (DB를 사용하지 않음)

1. 설치

  $ sudo wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add -

  $ sudo sh -c 'echo deb http://pkg.jenkins-ci.org/debian binary/ > /etc/apt/sources.list.d/jenkins.list'

  $ sudo apt update

  $ sudo apt install jenkins

2. 포트 변경

  $ sudo vi /etc/default/jenkins

  HTTP_PORT=8110

3. 서비스 시작/종료

  $ sudo service jenkins stop

  $ sudo service jenkins start

4. 웹실행

  $ sudo cat /var/lib/jenkins/secrets/initialAdminPassword

  http://IP:8110/

  install suggested plugin(잘모르면 두가지중 이걸로 하는거다)

5. 참고사항

젠킨스는 데이타 베이스를 사용하지 않고 모든 설정 파일 및 빌드 데이타를 파일로 관리한다.

이런 데이타가 저장되는 곳이 젠킨스 홈 디렉터리이며 기본적으로 젠킨스를 구동한 계정의 .jenkins 디렉터리로

설정된다.

사용자의 홈 디렉터리에 저장되면 사용자가 실수로 삭제할 수 있으며 운영자가 관리하기 힘드므로 별도의 경로로 분리해서 사용하는 것을 권장한다.

 

Jenkins 환경설정

Global Tool Configuration 선택

Jenkins 서버에 설치된 jdk home 경로를 입력한다.

- 틀리면 바로 빨간색글씨로 에러가 확인되니 환경구성 실수를 줄일수 있다. 

- 실행파일까지가 아닌 경로만 입력한다.

Git에서 테스트 자바소스를 가져와서 자동컴파일,실행(헬로우 월드이지만..떱) 하기위한 실행경로를 입력한다.

- 기본적으로 ubuntu 18 버전에는 기설치 되어있다. 

- git 실행경로가 git서버 실행경로인지 먼지 한참 고민했는데 결론은 jenkins 서버에 git이 설치되어 있어야 하고

  해당 실행파일로 remote에 있는 git서버 리파지토리에서 정보를 가져오는 것이다. 

 

jenkins 신규빌드 구성

신규빌드 이름을 정하고 처음 테스트 이므로 Freestyle project를 선택한다. 

- jenkins가 2.0 버전부터 Pipeline를 지원하는데 해당 기능이 가장 각광받고 있는기능으로 추후 공부해야할 숙제이다.

git 리파지토리에서 소스를 가져와서 테스트를 하여야 하기에 해당 url과 읽어올수있는 사용자계정을 입력합니다.

- git URL은 총 3가지가 가능한데 http, https, ssh(RSA 키교환 방식으로 보안에 좋음)

- 테스트 이므로 http로 세팅 

빌드유발은 git서버에 소스가 변경되면 자동으로 빌드하기 위해 설정했다.

 

Exeute shell인 경우는 리눅스에서 사용할때 사용하고 아래것은 윈도우에서 사용할때 하는것으로 혼동하면안된다.

- 여기서 삽질을 많이 했어요..떱..

 

jenkins 빌드실행 

구성을 마치면 item정보가 보이고 name을 클릭하면 상세정보를 확인할수 있다.

 

Build History 보면 실패했다 성공했다를 색깔로 표시한다. 빨간색 실패, 파란색 성공

실패의 내용을 보고자 하면 Console Output으로 확인가능하다

해당 내용을 보면 아주 자세히 나와있는 것을 확인할수 있다. git에 소스변경을 감지하여 소스를 받아서 실행했는데

오류가 난것이 보인다.

- 오류 이유는 : jenkins 구성시 window용으로 스크립트를 실행하게 하였더니 cmd 기준으로 실행 하였는데 오류가 발생한것이다.

 

리눅스 shell 스크립트로 구성을 변경하고 실행하였더니 성공이다!!!

- 성공정보도 아주 자세히 나와있다.

 

결론

테스트를 해보면 jenkins의 강점이 한눈에 보인다. 소스 커밋만 git에 해놓으면 알아서 변경을 감지해서 자동 빌드를 해주는 오픈소스인것이다. CI/CD 환경에서 가장 중요한 부분이라고 생각한다. 

개발자에게 개발에 집중하게 해주는 이런 솔루션을 잘 커스텀마이징 하여 프로젝트에 꼭 적용해야 할것으로 보인다.

 

긴글 읽어주셔서 감사합니다!!!