젠킨스로 CI/CD 적용하기(CI 적용편) - 1
CI/CD 는 지속적 통합 / 지속적 배포 라고 하는데 여기저기서 주워들은 지식으로 "빌드나 배포 같은걸 자동화 하는 것이구나!"정도로만 생각하고 있었습니다.
실제로 공부해볼 생각은 안하고 있었는데 어려워 보인다는 이유로 미뤄왔습니다.
하지만 막상 공부를 해보고 실습을 해보니 생각보다 쉬웠고 재밌다! 라고 앞서 말씀드리고 싶습니다 :)
CI/CD 왜 해야하는가?
CI(Continuous Integration) : 지속적 통합
CD(Continuous Deployment) : 지속적 배포
CI는 애자일 방법론에 최적화되어 있습니다.
애자일에서 스프린트 기간을 짧게 가져가는데 일을 분배하고 스프린트 기간이 끝나면 회고하는 주기가 짧습니다.
즉 애자일 방법론은 피드백의 주기가 짧다는 의미입니다.
CI 또한 테스트/빌드를 빠르게 가져가고 그 결과에 대한 피드백을 빠르게 받기 위함입니다. 자동화 테스트는 코드 변경사항에 대해 빠른 피드백과 빌드 성공을 보장해줍니다.
CD로 배포를 자동화하면 배포하는 시간을 줄여주고 이를 즉각적으로 Dev 서버나 Production 서버에 배포하여 확인해볼 수 있습니다.
정리하자면 CI/CD는 짧은 주기로 테스트와 빌드에 대한 피드백을 받고 배포를 자동화하여 배포 또한 빠르게 피드백을 받아볼 수 있습니다.
애자일 개발과 CI/CD | CI/CD 완벽 가이드 | JetBrains TeamCity
www.jetbrains.com
CI/CD 툴로 Jenkins를 사용한 이유
많은 CI/CD 툴이 있지만 젠킨스를 선택한 이유는 가장 많이 들어봤다는 것이 첫번째이고 러닝커브가 좀 있어야한다는 점이 좋았습니다.
러닝 커브가 있어야 한다는 의미는 젠킨스를 익히고나면 다른 CI/CD툴로 쉽게 갈아탈 수 있을거라 생각해서 입니다.
Jenkins 설치하기
우선 젠킨스를 설치해야합니다.
젠킨스 사이트에 가서 직접 다운로드 받아도 괜찮고 Docker에서 젠킨스 이미지를 받아도 괜찮습니다.
이 글에서는 Docker 이미지를 다운받는 방법을 기준으로 하겠습니다.
우선 젠킨스 이미지를 pull 받습니다.
docker pull jenkins/jenkins:lts
위에서 lts 버전을 받았는데 Long Term Support 라 하여 장기 지원해주는 버전이라고 생각하시면 됩니다.
주의할 점은 lts 버전에는 기본적으로 java8 버전이 설치되어있습니다.
만약 java11 이나 다른 버전이 필요하신분은 내부에 다시 설치를 하시거나 아래의 이미지를 pull 받으시면 됩니다.
docker pull jenkins/jenkins:java11
다음으로 젠킨스 이미지를 컨테이너에 실행하면 됩니다.
docker run -d -p 8080:8080 -v /jenkins:/var/jenkins_hom --name [컨테이너 이름] -u root jenkins/jenkins:lts
도커 명령어를 간단하게 설명하자면
- -d detached mode 백그라운드 모드
- -p 호스트와 컨테이너의 포트를 연결 (호스트port:컨테이너port)
- -v 호스트와 컨테이너의 디렉토리를 연결
- --name 컨테이너 이름 설정
- -u 실행할 사용자 지정
젠킨스가 성공적으로 실행됐다면 local ip의 8080 포트로 접속하시면 됩니다.(어떤 호스트 ip에 연결했냐에 따라 다릅니다. 위의 예제에서는 8080 포트로 연결했습니다)
아래와 같은 화면이 뜨면 기다려주시면 됩니다.
로딩이 완료되면 아래와 같이 인증을 요구하는 화면이 나옵니다.
화면에 나와있는 path(/var/jenkins_home/secrets/initialAdminPassword)를 가보면 젠킨스를 언락하기 위한 비밀번호가 들어있습니다. 이것을 확인하는 두가지 방법이 있습니다. (Docker 기준)
1. docker logs [컨테이너 ID 또는 컨테이너 이름] -> 젠킨스를 실행하면 CLI 창에 비밀번호를 띄워줍니다. 이를 확인하기 위해 도커의 log를 보는 명령어 입니다.
2. docker exec -it bash 로 컨테이너 내부로 가서 화면의 /var/jenkins_home/secrets/initialAdminPassword 를 확인하는것입니다.
비밀번호 입력이 완료됐다면 오른쪽 아래의 continue 버튼을 누릅니다.
continue를 누르면 아래와 같은 화면을 보게됩니다.
왼쪽은 유용한 플러그인을 자동으로 설치하는것이고
오른쪽은 설치할 플러그인을 직접 선택하는 것입니다.
여기서는 왼쪽을 이용해서 설치하도록 하겠습니다. 정말 유용한 플러그인을 많이 설치해줍니다 :)
왼쪽 박스를 클릭하면 아래의 화면이 나옵니다. 기다려주면 설치가 완료됩니다.
설치가 완료되면 젠킨스 계정 설정화면이 나옵니다. 앞으로 Jenkins에 로그인할 때 사용할 계정이되니 적절하게 작성해주시면 됩니다.
이후 한가지 과정이 더 있지만 스크린샷을 깜빡했습니다 ㅠㅠ
Jenkins URI에 대해서 물어보는데 Jenkins 에 접속하는 주소를 적어주시면 됩니다.
(예시: http://localhost:8080)
완료하면 아래와 같은 화면이 나옵니다.
여기까지 젠킨스 설치는 끝났습니다.
Jenkins로 CI/CD 설정하기
새로운 Item 을 클릭합니다.
젠킨스에서 Job은 하나의 Item이라고 생각하시면 됩니다. 즉 젠킨스가 행하는 하나의 일이라고 생각하시면 됩니다.
새로운 Item을 누르면 아래와 같은 화면이 나옵니다.
item의 이름과 item의 타입을 선택합니다.
item의 타입은 일단 지금은 Freestyle project 를 선택합니다. (뒤에서 Pipeline에 대해서 설명하겠습니다.)
아래는 만들어진 item의 모습입니다.
이제 CI/CD를 위해서 몇가지 설정이 필요합니다.
우선 설정을 위해 메뉴에서 구성을 선택해서 들어갑니다.
설정창의 제일 상단부터 차근차근 설명하겠습니다.
먼저 제일 위의 설명은 현재 Item이 어떤것을 위한 Item인지 설명하는 공간입니다. 물론 Optional 이라서 입력하지 않아도 됩니다.
저희는 Github Project를 사용할것이므로 Github project에 체크하고 저장소 Url을 입력합니다.
다음은 git에서 소스코드를 가져오기 위한 설정입니다.
먼저 Git 에 체크를 해주시면 위와 같은 입력 폼이 나옵니다.
Repository URL은 CI/CD하는 대상 저장소의 URL을 입력해주시면 됩니다.
Credentials는 Jenkins가 저장소에 접근하기 위한 인증수단을 의미합니다.
Github ID와 비밀번호로 하는 방법도 있지만 이것은 Github에 대한 모든 권한은 열어주므로 가능하면 ssh 인증방식이나 Github 액세스 토큰을 사용하는것을 추천드립니다.
여기서는 Github 액세스 토큰으로 진행을 해보겠습니다.
Branch Specifier는 어떤 브랜치의 소스코드를 빌드할지를 입력하는 곳입니다. 여기서는 master라고 되어있지만 다른 브랜치를 입력하면 해당 브랜치의 소스코드로 Item이 빌드를 진행합니다.
이곳에서 바로 credentials를 생성해도 되지만 Github 에 액세스하는 것은 새로운 item만 만들어도 다시 사용해야하므로 Credentials를 설정하겠습니다.
Jenkins 관리로 들어가시면 아래와 같은 화면이 나옵니다.
여기서 Manage Credentials 가 있는데 여기서 다양한 인증서를 관리할 수 있습니다.
젠킨스는 이런 인증서에 대한 민감 정보를 암호화해서 관리해줍니다 :)
따라서 외부에서 이것을 탈취하더라도 쉽게 정보를 알아보기 힘들도록 합니다.
Manage Credentials을 선택하면 아래와 같은 화면이 나옵니다.
Jenkins 를 선택해주시면 아래와 같은 화면이 나옵니다.
Global credentials 를 선택해줍니다.
이제 Add Credentials 를 선택해서 인증서를 추가해줍니다.
인증서 추가에 앞서 Github에 가서 인증을 위한 Github Access Token을 만들도록 하겠습니다.
먼저 Github의 내프로필을 클릭하면 나오는 Settings로 갑니다.
Developer settings를 클릭하면 아래와 같은 화면이 나옵니다.
메뉴에서 Personal access tokens 를 선택하고 generate new token을 선택해서 새로운 토큰을 만들어 줍니다.
Note 에는 이 토큰을 식별할 수 있는 이름정도를 적어줍니다.
Select scopes 는 이 액세스 토큰이 어느정도의 권한을 가질지를 설정합니다.
여기서는 저장소에 대한 권한과 저장소에 대한 hook 을 관리할 수 있도록 합니다.
이제 액세스 토큰을 생성하면 아래와 같은 토큰이 만들어집니다.
주의할점은 Github 토큰은 만들어진 화면에서만 볼 수 있고 이후에는 다시 토큰을 보여주지 않기때문에 따로 복사하여 자신만 볼 수 있는곳에 저장해둬야 합니다.
토큰을 가지고 이제 Jenkins Credential을 등록합니다.
Kind는 인증 방식을 의미합니다. 여러가지가 있지만 지금은 Username과 Token으로 인증을 할것이므로 Username with password를 선택합니다.
Username은 Gibhub ID를 적어줍니다.
Password는 아까 받았던 Github Access Token을 입력합니다.
ID는 현재 인증서의 이름입니다. 사용자가 알아보기 쉬운 이름으로 직접 입력하시면 됩니다.
여기까지입력하고 등록을 하시면 Credential이 생깁니다.
이제 다시 Item의 설정으로 돌아가서 Credentials를 보시면 인증서가 하나 생겼습니다.
등록된 인증서를 선택해줍니다.
이제 다음으로 넘어가겠습니다.
빌드 유발은 GitHub hook trigger for GITScm polling 을 체크합니다.
이 설정은 Jenkins가 Github의 push hook 을 수신하면 위에서 정의한 Github 리포지토리와 일치하는지 확인합니다. 일치하면 소스코드를 가져와서 빌드를 진행합니다.
이를 위해서는 Github에서 Webhook을 걸어줘야 합니다. 다시 Github 저장소로 가서 설정을 진행합니다.
Webhooks 로 가면 아래와 같은 화면이 나옵니다.
Payload URL 매우 중요합니다.
[자신의 젠킨스 URL]/github-webhook/ 로 등록해주셔야 합니다. URL 마지막 '/' 도 생략하지 마시고 입력해주셔야 합니다!
그렇지 않으면 오류가 발생합니다.
Content type 은 json으로 받도록 하시고
Which events would you like to trigger this webhook? 은 어떤 이벤트에 트리거를 설정하느냐 인데
여기서는 push event만 필요하므로 Just the push event에 체크해줍니다.
여기까지 했다면 Github 저장소의 Webhook 설정은 끝났습니다.
이제 Github 저장소의 대상 브랜치에 push(merge)가 된다면 Webhook 트리거가 발동해서 젠킨스에게 요청을 보내게 됩니다.
이제 다시 젠킨스 설정으로 돌아와서 빌드를 실행하기 위한 설정을 하겠습니다.
Build 단계에서 Add build step을 클릭하면 다양한 빌드 방법들이 있는데 여기서는 Execute shell을 활용하겠습니다.
간단하게 말하자면 shell script로 빌드를 진행한다고 생각하시면 됩니다.
이렇게 shell script를 적절하게 작성해주시면 됩니다.
여기까지 CI, 즉 지속적 통합은 완성됐습니다.
이제 설정에서 지정한 브랜치에 push가 되면 젠킨스에서 자동으로 빌드를 시작합니다.
CD에 대한 설정은 다음 포스팅에서 계속 하겠습니다.