Jenkins란? 그리고 Docker를 이용한 설치 1#

https://www.jenkins.io/

최근 몇 년 동안 애자일 방법론은 전 세계적으로 성장했다. 이런 현상의 원인 중 하나는 전자상거래 영역에서 잦은 변경에 빠르게 대응 할 수 있는 소프트 웨어 배포 솔루션을 원하기 때문이다. 그 결과 지속적 통합(CI)과 지속적 배포(CD) 방법론은 사람(개발자사람임;적어도 아이와 할머니,할아버지는 아닐것이다.)들의 관심을 받게된다. 대다수 프로젝트가 정도의 차이는 있지만 이런 방법론의 효과를 보고 있다. 이슈의 조기 발견, 지저분한 코드가 상용 코드에 들어가는 것을 막고, 빠르게 배포하는 것을 통해 생산성을 향상시키고 있다.

 

필자는 강의를 트레비스 맛을 봣지만 젠킨스는 처음이기에 부족한 내용이나 틀린 내용도 있을 것이다. 처음 공부하면서 포스팅을 통해 정리한  내용이니 가볍게 보길 바란다. (피드백이나 틀린내용 있을 경우 댓글로 제보하길 부탁한다.) 또한 지속적 통합의 개념을 알기전에 사전 지식이 필요하다. 소프트웨어 개발에서 가장 중요한 방식인 폭포수 방법론과 애자일 방법론, 스크럼 프레임워크, 브렌칭 전략 그리고 소프트웨어 개발 주기 등 ( 나중에 따로 한번 다뤄볼 계획이다.) 여기서 다루지는 않을 것이다. 그래서 각자 한번 참고하고 이 글을 보기 바란다. 

본격적으로 시작하기 앞서 이번 포스팅의 목차를 나열 하겟다. 

 

• 지속적 통합의 개념
• 도커를 통한 젠킨스 설치

---

https://www.exoscale.com/syslog/what-is-continuous-integration/

1. 지속적 통합의 개념

Continuous Intergration은 개발자들이 빠른 주기로 작업한 내용을 통합 브랜치에 통합하고 빌드하는 개발 방식이다. 브랜치? 맞다 지금 생각하고 있는 브랜치가 그 브랜치다. 통합은 개인이 작업한 코드를 공용 작업 환경에 올리는 것을 의미한다. 이 과정은 개인 브랜치를 중앙 브랜치에 병합하는 과정으로 이뤄진다. (개인 브랜치를 원격 브랜치에 올린다고 표현하기도 한다.) 

지속적 통합은 통합 과정에서 발생하는 이슈를 가능한 빨리 바견하기 위해 필요하다. 이것은 지속적 통합 사이클에서 발생하는데 다음 상황이 있다.

코드가 잘못 반연되거나 개발자가 수동으로 빌드할 때 실수를 하면 빌드는 실패한다. 개발자가 개인 개발 환경을 통합 환경에 맞게 주기적을 리베이스하지 않으면 통합 이슈가 발생한다. 코드가 단위 테스트케이스나 통합 테스트케이스를 통과하지 못하면 테스트 이슈가 발생한다. 즉 이슈 발생시 개발자는 코드를 수정해 문제를 해결해야되는데 이때 CI를 이용한다. 

https://biarca.io/2019/02/biarca-helps-linux-foundation-develop-and-deploy-a-ci-cd-workflow-for-their-certification-platform/

애자일 개발 방법론은 빠른 배포를 기반으로 하는데, CI는 애자일에서 필요한 속도를 얻는데 도움을 준다. 어떻게? 

• 기능을 개발할 때 코드를 여러번 수정하게 되는데 이 과정에서 코드를 반영
• 버전 관리 시스템에서 변경 사항을 가져오고 (CI를 구성하는데 가장 기본이자 중요한 요소)
• 소스코드 빌드하고 
• 단위테스트하고 통합
• 통합된 코드를 빌드 
• 이를 패키징하여 배포
• 이 과정들을 빠르게 에러없이 진행한다. 

개발중인 프로젝트에서 커밋은 매우 빈번히 일어나기 때문에 커밋 횟수만큼 빌드르 실행하는 것이 아니라 작업이 큐잉 되어 개발자 서로가 커밋한 코드들이 실행될 차례를 기다리게 된다. 그래서 CI도구를 이용해 자동화 테스트 수행과 프로파일링 툴을 이용한 소스 변경에 따른 성능 변화 감시 마지막으로 결합 테스트 환경에 대한 배포작업까지 CI가 주는 이점이 크기 때문에 많이 사용한다. 이때 중간 중간에 알람을 추가하면 더욱 빨라진다. 팀원이 빌드, 통합, 배포 실패를 빨리 알아차릴수록 더 빨리 대응할 수 있다. 

 

CI도구는 파이프라인을 생성하는 방법을 제공한다. 각 파이프라인에는 고유한 목적인 있는데 CI를 관리하거나 소작업을 관리하거나 배포를 관장한다. 기술적으로 파이프라인은 연속된 작업의 흐름이다. 각 작업은 연속해서 수행되는 소작업의 모음이다. 즉 CI 도구 사용의 핵심은 스크립트 언어를 이용하여 다양한 소작업을 수행하는 것이다. 소작업은 폴더나 파일을 복사하는 등 간단한 것부터 파일 수정을 담하는 서버를 모니터링하는 것처럼 복잡한 펄 스크립트일 수도 있다. 하지만 젠킨스의 경우 플러그인을 사용하면 금방 이용가능하다. 즉 플러그인을 설치한 후 설정한 다음 원하는 작업을 실행시키면 된다.

 

CI 도구들 다양하다. Jenkins, Gitlab CI, Travis CI, Circle CI, Teamcity, Bamboo등 다양한데 사실 이중에 하나만 공부해도 된다. CI도구는 단순히  지휘자 역할을 하기 때문인데 버전관리, 빌드 도구, 바이너리 관리 도구, 테스트 및 프로덕션 환경, 소스코드 분석 도구 및 자동화 테스트 도구 등 기본적인 CI 도구들이 있다면 원리는 비슷하기에 자기가 원하거나 아니면 회사가 따로 요구하는 툴로 공부하면 되겟다. 

필자는 Jenkins을 하기로 마음먹었기에 젠킨스 간다!  

---

2. 도커를 통한 젠킨스 설치 

 

어디서 설치하던 상관없다. 본인이 톰켓 다룰줄 알면 톰켓에 올려 사용하면 된다. 필자의 경우 도커도 복습할겸 도커에서 설치하겟다. 나중에 추가적으로 쿠버네티스로 설치하는 방법 업데이트 할 예정이다. 

 

준비 사항이 있다. 

1) 운영체제에 상관없이 도커/쿠버네티스가 설치되어야 된다. 

hanibrown.tistory.com/6

Docker의 기초 1#

 

필자가 올린 인스톨 방법이 기재 되어있으니 참고하길 바란다. 

 

2) 깃허브 계정이 필요하다. (사설이든 공개든 상관없다.)

github.com/

GitHub: Where the world builds software

이 포스트를 보고있다면 개발자로서 기본적인 준비체제는 갖추고 있으니 회원가입하는 방법은 생략하겟다. 

 

3) 하드웨어 요구 사항이다. 권장 사양으로 4G이상의 램과 멀티코어(2개이상) CPU pc이면 된다. 

 

4) Docker 명령어로 Jenkins 설치 

docker run -d --name jenkins_dev -p 8080:8080 -p 50000:50000 jenkins/jenkins:lts

 

다운 받을게 많다 조금 기다려 보자 기다리다 보면 다음과 같이 나온다.

컨테이너에 잘 안착했고 실행 중이기도 하다. (참고로 -d 옵션은 백그라운드 실행이다.)

실행되는걸 확인하고 자기 ip주소값을 넣은 뒤 포트값 또한 넣으면 이 화면이 뜬다. 대충 딱 봐도 빨간색 경로에 비번있으니 확인하고 기입해라 라고 안보이는가? ㅎ 여기서 확인하는 방법 여러가지있는데 두가지만 소개 하겟다. 

 

docker exec -it jenkins_dev cat /var/jenkins_home/secrets/initialAdminPassword
 
docker log jenkins_dev

첫번째는 깔끔하다 즉 아래 사진처럼 나온다.

두번째 방법은 명령어가 깔끔하다. 대신 길게 나오므로 혼동은 하지말자 

젤밑에 별표시 안에 비번이 존재한다. 아무튼 취향껏 고르고 비번 알아내자 

복사해서 붙여넣기하면 

첫번째거 누르고 플로그인 설치 드간다. 아니면 오른쪽 버튼으로 필요한것만 인스톨할 수 있다. 학습용이니 첫번째(왠만한거 다 설치하는 버튼) 버튼을 누르겟다. 하지만 꽤나 오래 걸리기 때문에 조금 티타임을 가지기 바란다. 

일단 설치는 완료 되었으며 다음에 각각 설정을 포스팅 하겟다.