최근에 도커와 쿠버네티스를 공부하기 위해 도서관에서 빌린 책중의 하나가 제목에서 언급한 도커/쿠버네티스를 활용한 컨테이너 개발 실전 입문(지금부터는 빌린책..이라고 호칭하겠다..제목이 너무 길어..ㅠㅠㅠ..)이다. 도커를 아주 모르는 상황도 아니고 내 개발환경에서 나름 잘 사용중이나 내 스스로 체계적인 지식을 갖고 있는게 아니어서 이 참에 책을 통해 한번 가다듬고 쿠버네티스는 정말 공부하고 싶어서 그런 계기로 빌리게 된 책이다. 근데 이 빌린책에 나는 개인적으로 경험해보지 못한 흥미로운 구성을 실습하는게 있었는데 jenkins 분산 빌드 환경을 도커로 구성하는 것이었다. jenkins를 실제 프로젝트에서 적용해보지 못했던 나로서는(희한하게 내가 참여했던 플젝들은 svn은 늘 써도 jenkins는 사용하질 않았다. 내가 관리 주체도 아니어서 내가 쓰자고 말할 입장도 아니었기 때문에 그냥 넘어갔지만..) 분산빌드환경..이란게 왜 필요한지를 몰라서 검색과 지인 찬스를 통해 알게 되었다.
jenkins 분산 빌드 환경은 간단히 설명하자면 jenkins 서버 1대만을 이용하는 상황에서 만약 여러 프로젝트가 동시다발적으로 빌드하게 될 경우 jenkins 서버에 부담을 주게 되고 이는 각 프로젝트별로 빌드 시간이 길어지는 결과를 낳기때문에 분산빌드 환경이 필요하다는 것이다(이거는 내가 검색해서 알게된 내용..) 또 원격으로 배포를 할때 배포되는 서버에 agent를 두고 배포하면 remote shell을 사용할 필요가 없기땜에 보안사항으로 지적을 받지 않는다고 한다(이거는 지인찬스로 알게 된 내용) 암튼 실무적으로 나름 합리적인 이유가 있어서 이런 분산빌드 환경을 구축한다는 것이다. jenkins 분산 빌드 환경은 jenkins master 서버와 이 서버에 연결된 1개 이상의 agent로 구성이 된다. jenkins master 서버는 단지 ui를 통한 관리 업무만을 진행하고 빌드 및 배포는 agent 쪽에서 하게 된다. 이 글에서는 jenkins 분산 빌드 환경에 대한 구체적인 언급은 하지 않는다. 다만 여기에 이 내용을 기록하는 것은 개인 기록 차원에서 남겨두기 위해 써둔 것이다. jenkins 분산 빌드 환경에 대해서는 검색하면 양질의 자료들이 나오기땜에 그런 자료를 보는것이 좋다. 그러나 방금 언급한 구조는 알아두어야 한다. 왜냐면 docker에서 이러한 구조로 사용할 것이기 때문이다(master와 1개 이상의 agent..)
이 빌린책은 2019년 3월에 나온 번역서이다. 원서에 대한 정보는 찾질 못했는데 추측으로는 2018년에 나왔을 것으로 생각된다. 그러다보니 현재 docker에 있는 jenkins 운영과는 약간 차이점이 있다. 그래서 책에서 사용한 docker 이미지가 아닌 현재 docker jenkins 운영에 맞춰서 이미지 사용을 바꾸었고 개인적인 경험도 더 추가해서 구성했다. 이 글에서 사용하는 환경은 Windows 10, Vagrant, Vagrant CentOS 7 box를 사용한 환경이다. docker는 Vagrant CentOS 7 box에 설치했으며 docker ce 19.03.8 버전, docker-compose 1.25.5 버전을 사용했다.
아까도 말했다시피 jenkins 분산 빌드 환경은 1개의 master와 1개 이상의 agent로 구성된다고 했다. 그래서 master를 먼저 구성해야 한다. docker-compose를 이용해서 master와 agent 1개를 구성했는데 이에 대한 docker-compose.yml 파일은 다음과 같다
version: "3"
services:
master:
container_name: master
image: jenkins/jenkins:2.222.3-alpine
ports:
- 8080:8080
volumes:
- /home/vagrant/docker_study/jenkins_home:/var/jenkins_home
networks:
dockernet:
ipv4_address: 10.10.20.101
# slave01:
# container_name: slave01
# image: jenkins/ssh-agent:2.1.0-alpine
# environment:
# - JENKINS_SLAVE_SSH_PUBKEY=master의 id_rsa.pub 파일 내용
# networks:
# dockernet:
# ipv4_address: 10.10.20.102
networks:
dockernet:
external: true
이 docker-compose.yml 파일을 보면 service로 master와 slave01이 있는데 master는 위에서 언급했던 분산 빌드 환경의 master 역할을 할 것이고, slave01이 agent 역할을 할 것이다. 만약 agent를 더 두고 싶으면 slave01과 같은 형태의 구성을 더 두면 된다. 현재 slave01 에 대한 항목은 모두 주석처리를 해놨는데 왜냐면 master만 먼저 실행시켜서 작업을 한 뒤 작업 내용을 slave 항목에 넣어서 반영해야 하기 땜에 구성 형태만 남겨두고 주석처리해서 실제로는 slave01 컨테이너가 만들어지지 않도록 했다. 이 부분은 최종적으로는 주석을 풀 것이다. 현재의 스텝에서는 이 부분을 주석처리해두고 진행한다고 생각하고 넘어가주길 바란다.
지금부터 설명할 내용은 빌린책의 docker-compose.yml 파일 구성과 이 글에서 사용한 docker-compose.yml 파일 구성의 차이점, 그리고 왜 이렇게 했는지에 대한 설명을 하도록 하겠다. 그러자면 먼저 docker hub에서 jenkins가 어떻게 관리되고 있는지를 볼 필요가 있다. jenkins 또한 유명한 프로그램이다 보니 official image가 있다. 다만 이 official image를 사용할 수 없는 아이러니한 문제가 있다. 왜냐면 이 official image 란게 최근 2년동안 반영된게 없기 때문이다(잉?..) 그래서 jenkins official image는 최신 버전이 아니다. jenkins 공식 homepage 에 가서 download(https://www.jenkins.io/download/) 에 가보면 LTS 버전과 Weekly 버전을 받을 수 있는데 2020년 5월 4일 기준으로 LTS 버전은 2.222.3이고 Weekly 버전은 2.234 버전임을 알 수 있다. 그러나 docker hub의 jenkins official image는 2.60.3 버전이다. docker hub에서 jenkins를 검색해보면 일반 사용자가 아닌 jenkins community 차원에서 배포되는 이미지가 3종류인것을 확인할 수 있다.
- jenkins(엄밀하게는 library/jenkins인 official image)
- jenkins/jenkins
- jenkinsci/jenkins
jenkins community 차원에서 관리되며 배포되는 이미지는 jenkins/jenkins 이미지이다. 실제로 위에서 잠깐 언급했던 download 메뉴에 가보면 docker 항목이 있는데 클릭해보면 jenkins/jenkins 이미지로 연결되고 있다. jenkins/jenkins 이미지는 LTS 버전일 경우 태그에 lts를 붙이고 있으며 Weekly 버전은 별도 태그를 붙이지 않고 있다. 빌린책에서 사용되는 jenkins 이미지는 jenkinsci/jenkins:2.142-slim 이미지를 사용하고 있는데 jenkinsci/jenkins 이미지는 deprecated 되어서 더는 관리되지 않고 있다. 그래서 jenkins/jenkins 이미지를 사용했다. 그리고 나는 위의 docker-compose.yml 파일에서도 보다시피 alpine linux를 사용하는 이미지를 사용했다. docker pull 명령을 이용해서 이미지를 받아보면 이미지 크기의 차이가 상당한 편이다. jenkins/jenkins 에서도 slim 이미지를 제공하는데 예를 들어 jenkins/jenkins:2.222.3-slim 이미지를 사용할경우 이미지를 pull 받은 후의 이미지의 크기가 470MB 이지만 jenkins/jenkins:2.222.3-alpine 을 사용하면 pull 받은 후의 이미지의 크기가 228MB 여서 절반 수준의 크기인것을 알 수 있다. 이 부분은 agent에서도 그러하기 때문에 주석처리를 해놨지만 agent에서도 alpine linux를 사용하는 이미지를 사용했다.
빌린책에서는 slave01 컨테이너에 사용된 이미지로 jenkinsci/ssh-slave 이미지를 사용하고 있다. 그러나 나는 jenkins/ssh-agent 이미지를 사용하고 있는데 jenkinsci를 사용하지 않는 이유에 대해서는 위에서 jenkinsci가 deprecated 되었다고 얘기했기땜에 더는 추가 설명은 생략하기로 한다. 그러면 ssh-slave와 ssh-agent가 차이가 있느냐..하면 그렇지가 않다. ssh-slave나 ssh-agent나 양쪽 모두 동일한 github repository(https://www.github.com/jenkinsci/docker-ssh-agent)를 사용하고 있기 때문에 동일한 이미지라 봐도 무방하다. 그러나 jenkins/slave 이미지가 deprecated 되고 jenkins/agent를 사용하게끔 하고 있기 때문에 ssh-slave도 deprecated 될 가능성이 있을듯 하여 ssh-agent를 사용했다. jenkins/ssh-agent는 github(https://github.com/jenkinsci/docker-ssh-agent) 에서 release 항목을 클릭해보면 가장 최근 버전이 2.1.0으로 되어 있는데 2.1.0 버전을 사용했을 것으로 추측되는 jenkins/ssh-agent:2.1.0-alpine 과 jenkins/ssh-agent:alpine 의 DIGEST 값이 달라서 이 둘이 서로 버전이 다를것으로 생각되는 측면도 있지만 이에 대한 확신이 없어서 일단 버전이 명시된 것으로 사용했다.
내가 사용한 이미지에 대한 설명은 이 정도로 마치고 volume에 대한 설명을 하도록 하겠다. linux 환경이나 또는 docker for windows 환경에서 이 글을 보고 실습해볼 사람에게는 해당사항이 없지만 나 같이 windows 에서 vagrant로 docker 환경을 만든 사람에게는 주의할 점이 있다. vagrant도 가상환경이기 때문에 windows(host) 폴더(이하 A 폴더)와 vagrant로 만든 가상머신(remote) 디렉토리(이하 B 디렉토리)와의 공유 설정이 가능하다. 그래서 이러한 공유 설정과 docker volume 설정을 통해 다음과 같은 공유가 가능해진다.
Windows 10 A 폴더 = Vagrant CensOS B 디렉토리 = docker container C 디렉토리
개념적으로 이렇게 썼지만 디테일하게 기록하면 A 폴더/docker/jenkins_home = B 디렉토리/jenkins_home = docker container의 /var/jenkins_home 이런 구조가 가능해진다. 그러나 이 실습에서는 이렇게 공유되는 디렉토리를 windows 까지 확장시키면 안된다. 이따가 설명할 작업이지만 미리 조금 언급해주면 master에서 ssh key를 생성하는 작업을 진행해야 하는데 이때 관련된 file permission이 너무 많이 열려있어서 문제가 있다는 에러 메시지가 나온다. 왜 그러냐면 windows와 vagrant가 폴더와 디렉토리를 공유하는 과정에서 공유되는 파일의 권한을 모두 777로 설정해버리기 때문에 key 파일도 777 permission을 가지게 되어서 이러한 에러가 발생되는 것이다. 그래서 docker-compose.yml에서 volume을 통한 디렉토리 공유 설정을 할때 windows 디렉토리와 공유가 되지 않는 vagrant 가상머신 디렉토리를 docker container의 디렉토리와 공유 설정해야 한다. 위의 설정에서 사용된 /home/vagrant/docker_study/jenkins_home 디렉토리는 vagrant 가상머신에 있는 디렉토리이지만 이 디렉토리는 vagrant가 운영되는 windows host와는 공유되고 있지 않다.
또 한가지 덧붙일 작업이 volume과 관련되어서 필요하다. 이 상태로 그냥 docker-compose를 이용해서 jenkins를 실행하면 다음과 같은 오류가 발생하게 된다
이것은 현재 vagrant 가상머신 디렉토리인 /home/vagrant/docker_study 디렉토리에서 다음과 같은 명령어를 실행시켜주면 된다(여기를 보고 이 부분을 해결했다)
sudo chown 1000 jenkins_home
빌린책에서는 networks 설정을 하지 않았지만 나는 networks 설정을 했다. 개인적으로 docker container를 이용한 개발과정에서 container를 ip를 통한 접근을 하는것이 나에게는 편리함을 주기 때문에 그렇다. 포트포워딩 방식으로 개발할수 있지만 여러개의 컨테이너를 동일한 port로 띄워야 할 경우 나는 vagrant를 중간에 사용하고 있기 때문에 이러한 설정이 쉽지가 않아서 차라리 ip를 부여하고 각 컨테이너가 동일한 port를 사용하게끔 개발하는 편이다. 그래서 이 부분도 이 글을 쓸 무렵에는 지울까..하다가 내 자신의 개인기록 차원에서는 남겨야 할 것 같아서 남겨두었다. 그러나 이 글을 읽으시는 분들은 빌린책과 같이 설정해도 충분히 가능하다(그래도 이걸 따라해보고 싶다면 docker에 대한 형식없는 정리 글의 30번, 31번, 35번 항목의 내용을 읽어보길 바란다)
빌린책에서는 master service에 links 항목을 설정하는데 나는 이를 설정하지 않았다. 원래 links는 docker-compose.yml 에서 실행되는 service 들간의 연결을 정의할때 사용하는 항목인데 docker-compose 문법 3 버전부터는 docker-compose.yml을 실행하면 해당 yml에 대한 bridge network가 생성이 되면서 그 bridge network가 제공하는 ip를 각 service container가 받게 된다. 그리고 service 이름(여기서는 master, slave01) 만으로 network 연결이 가능해진다(예를 들자면 master container에서 ping slave01이 가능하다는 얘기..) 그래서 links 항목을 뺐다.
위에서 언급한 docker-compose.yml 파일에 대한 설명은 이 정도로 일단 마치고 이제 본격적으로 이를 실행시켜보자. 위에 작성한 docker-compose.yml 파일과 같이 slave01 서비스에 대한 설정을 일단 주석처리 하면 결국 master만 실행될 것이다. docker-compose.yml 파일이 있는 디렉토리에서 다음과 같이 docker-compose를 실행하자.
docker-compose up
일반적으로 서버를 띄우는 것이기 때문에 -d 옵션을 붙여서 백그라운드에서 실행되게끔 해야 하는 것이 맞지만 여기서는 일부러 포그라운드로 실행하도록 했다. 이유는 아래의 그림때문에 그랬다. 아래의 그림은 처음 jenkins가 실행이 될때 올라오는 log 내용중 마지막 부분에 해당되는 내용이다.
빨간색 박스 쳐져 있는 부분을 보면 무슨 암호화된 문자열 비스무리 한 것이 있고 이 문자열은 /var/jenkins_home/secrets/initialAdminPassword 에서도 찾을수 있다고 나온다. 이 문자열을 별도로 메모장 같은데다가 일단 복사해두자. 현재 docker-compose 구성대로면 master service만 올라와 있는 상태이다. 이제 브라우저를 열고 http://localhost:8080 으로 접근을 시도하면 다음과 같은 화면을 볼 수 있다
패스워드를 입력하라는 화면인데 이 패스워드가 바로 위에서 메모장 같은데에 복사해두라는 문자열이다. 위의 화면에서도 /var/jenkins_home/secrets/initialAdminPassword 파일에서 볼수 있다고 언급되어 있다. 참고로 현재 실행중인 master service 에 접근해서 이를 확인할려면 docker exec 명령을 이용해서 master container 안에 들어가면 확인할 수 있다. 현재의 터미널 화면에서는 jenkins container가 포그라운드에서 실행중이기 때문에 이 작업을 하기위해 별도의 터미널 화면을 띄운뒤 작업을 진행하도록 하자. alpine linux 는 ash를 기본 shell로 사용하기 때문에 아래의 그림과 같이 실행하면 확인할 수 있다.
이렇게 패스워드를 입력하면 Customize Jenkins 화면이 나오는데 일단은 Install suggested plugins 항목을 클릭해서 plugin을 설치해주고 마지막으로 관리자 인증 정보를 제공하면 jenkins 접근 URL을 보여준뒤 jenkins 메인 화면을 보여준다
jenkins master service를 이렇게 실행한 뒤에 해줘야 할 일이 있다. jenkins master service에서 SSH key를 생성해야 하는데 이 SSH key가 이따가 추가하게 될 slave01에 환경변수로 등록해줘야 하기 때문이다. 이렇게 하면 slave01 입장에서는 jenkins master service의 SSH key를 알고 있기 때문에 jenkins master service가 slave01을 접근하는것을 허용하게 해주는 것이다. jenkins master container에 접속해서 비밀번호를 알아냈던 방법에서와 같이 jenkins master container에 접속하자. 그런 후에 다음과 같은 명령어를 입력한다.
ssh-keygen -t rsa -C ""
그러면 몇가지 질문을 거치게 될텐데 질문이 나올때 마다 그냥 엔터키만 입력한다(원래는 보안차원에서 passphrase 질문시에 특정 문자열을 입력해서 보안을 강화시켜야 하지만 여기서는 공부차원이라 엄격하게 하지는 않았다. 그러나 운영계에서는 passphrase 입력을 해주는게 좋다) 전체적인 작업 과정은 아래 그림과 같이 이루어지게 된다.
위의 그림을 보면 마지막에 cat /var/jenkins_home/.ssh/id_rsa.pub 파일을 실행한 것이 있다. 이를 실행하면 ssh-rsa 로 시작하는 문자열이 있는데 이것을 메모장 같은데에 복사해두자(편의상 이 문자열을 master 암호키 라 하겠다) 이 master 암호키를 slave01 컨테이너의 환경변수에 등록한다. 위에서 주석으로 설정했던 slave01 service의 주석 설정을 풀고 master 암호키를 JENKINS_SLAVE_SSH_PUBKEY 환경변수에 등록한다. 그러면 최종적으로 docker-compose.yml 파일은 다음과 같이 된다.
version: "3"
services:
master:
container_name: master
image: jenkins/jenkins:2.222.3-alpine
ports:
- 8080:8080
volumes:
- /home/vagrant/docker_study/jenkins_home:/var/jenkins_home
networks:
dockernet:
ipv4_address: 10.10.20.101
slave01:
container_name: slave01
image: jenkins/ssh-agent:2.1.0-alpine
environment:
- JENKINS_SLAVE_SSH_PUBKEY=ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDAUo6yLcA/YylawjV+spI99tiRcd1bU0TPMwewOYLPpdpHj1XwTGU6lH5P/Mt4pXE4LV8O31KTCOGkbGooBLgG+0ZvDuT3irIN27ygwVOa06ZSHfVeTePVB1X4RgUnoxoiBoNcP6SbiBBWoLSPn/Y2YeNl7YZ1L6rrb6rIL0od0Yt3oxr7SdCvnfL8KYu68uJxDMCxRyMfrNt+KSysWfkQZBXHxcI7f/zpad3WSmlQWo61fvpTExs5Ihb4O5Rzp2YTYyeDUea63Uu+deen3bqAbm7kFwKd5uzbjmvvraZaWSTN0n3FQOORwfG7j7Wq2PfjdY7KETGIQG8mOuFI9FAb
networks:
dockernet:
ipv4_address: 10.10.20.102
networks:
dockernet:
external: true
slave01 service의 environment 항목에 JENKINS_SLAVE_SSH_PUBKEY를 master 암호키를 넣어줌으써 slave01 컨테이너에 JENKINS_SLAVE_SSH_PUBKEY 환경변수에 master 암호키 값이 들어가있게 된다. 현재 포그라운드로 실행중인 master jenkins container를 ctrl + c 키를 눌러 중지시킨후 다시 docker-compose를 이용해서 실행하면 아래와 같은 화면이 나온다.(중지시킨뒤 master container를 삭제하면 안된다. 삭제하면 다시 위의 작업을 반복해야 한다)
다시 docker-compose를 이용해서 실행을 하게 되면 포그라운드에서 중지되었던 master container를 다시 기동시키는 것과 동시에 아까는 생성하지 않았던 slave01 container를 생성하고 있다. 이 과정에서 보면 우리가 환경변수로 등록한 master 암호키를 이용하여 무언가 생성작업을 하는 것을 볼 수 있다.
지금 얘기하는 과정은 빌린책에는 언급이 안되어 있는 내용이다. 빌린책에서는 지금부터 설명하는 과정을 안하고 slave01 을 master container에서 신규 노드로 등록하는 과정에서 Host Key Verification Strategy 부분을 Non Verifying Verification Strategy 로 설정하게 되는데 이렇게 설정하는 것은 불안정한 설정이란 언급이 있다(여기를 보면 hopetds 의 답변 내용에 언급되어 있다) 그래서 나중에 Host Key Verification Strategy 항목을 Non verifying Verification Strategy 가 아닌 Known hosts file verification strategy 로 설정하기 위해 추가적으로 작업해야 할 내용이 있다. master container에 known_hosts 파일을 생성하면서 여기에 slave01 서비스를 등록하는 작업을 하는 것이다. 이를 위해 master container에서 다음과 같이 입력한다
ssh-copy-id jenkins@slave01
이 명령어를 실행하게 되면 master container가 slave01 container를 접속하는 과정을 거치면서 /var/jenkins_home/.ssh 디렉토리에 known_hosts 파일을 생성하게 된다. 아래의 그림은 이러한 과정과 known_hosts 파일 안에 있는 내용을 보여주고 있다
중간에 물어보는 질문에는 yes라고 입력해주면 되며, known_hosts 파일 내용을 보면 slave01 컨테이너와 관련하여 무언가 내용이 추가된것을 볼 수 있다. 아까 위에서 설명했을때 links 항목에 대해 설명하면서 service 이름만으로도 network 연결이 가능하다고 언급했었다. 지금 보면 ssh-copy-id 명령을 사용하면서 slave01 service 접속시 slave01 service의 ip 주소인 10.10.20.102를 사용하지않고 serivce 이름은 slave01 을 그대로 사용했다. 마치 hostname 같이 등록되어 동작하는 것을 알 수 있다.
이제 slave01 service를 master의 node로 등록하는 작업을 진행해보도록 하자. 브라우저로 http://localhost:8080 으로 접접근해서 로그인을 거치면 위에서 언급했던바와 같은 jenkins 메인화면을 보게 되는데 화면 왼쪽 메뉴를 보면 jenkins 관리 라는 메뉴가 있다. 여기를 들어가 보면 Jenkins 관리 화면이 나오게 되는데 여기서 노드 관리를 클릭해보자. 노드 관리를 클릭하면 아래와 같은 화면을 볼 수 있다.
화면을 보면 이 관리 화면을 띄우는 master service 이것만 보이는데 이제 여기서 slave01 service를 등록하게 된다. 위의 그림에서도 보이지만 화면 왼쪽을 보면 신규 노드 란 메뉴가 있는데 이를 클릭하면 아래와 같이 신규 노드 이름을 입력하는 화면이 보인다. 여기서 신규 노드 이름을 알기 쉽게 slave01 이라고 입력하고 Permanent Agent 항목을 체크한뒤 OK 버튼을 클릭한다.
OK 버튼을 클릭하면 아래와 같은 화면을 볼 수 있다
이 화면에서 Remote root directory는 /home/jenkins 로 설정하고 Launch method 항목을 Launch agents via SSH 로 설정한다. Launch agents via SSH로 설정하면 화면이 아래와 같이 바뀐다
여기서 Host 항목은 slave01로 입력한다(여기에 ip 주소를 입력하지 않고 container 이름을 입력해도 가능한 것은 위에서 설명했기 때문에 생략한다) 그리고 Host Key Verification Strategy 항목에는 화면과 같이 Known hosts file Verification Strategy 로 설정한다. 원래 빌린책에서는 Non verifying Verification Strategy 를 설정하고 있지만 위에서 ssh-copy-id 명령어를 실행하는 과정을 설명하면서 얘기했듯이 이러한 설정이 불안정한 설정이어서 Known hosts file Verification Strategy 로 설정한다(이 설정을 하기 위해 ssh-copy-id 명령을 실행한 것이다) Credentials 항목은 우리가 jenkins master service를 만드는 과정에서 Credentials 을 따로 등록한 것이 없기 때문에 위의 화면과 같이 Add 를 클릭하여 Jenkins를 선택하면 아래와 같은 화면을 볼 수 있다.
Kind 항목을 SSH Username with private key를 선택하면 화면의 UI가 위의 화면과 같이 바뀌는데 여기서 username을 jenkins 로 넣고 Private Key 항목에서 Enter directly 를 체크한뒤 Add 버튼을 클릭하면 위의 화면과 같이 바뀐다. 여기서 입력해야 하는 Key는 master container에 있는 /var/jenkins_home/.ssh/id_rsa 파일에 있는 내용을 넣어준다. 아래의 화면은 id_rsa 파일의 내용을 보는 화면이다.
위와 같이 id_rsa 키를 입력하고 Add 버튼을 클릭하면 Credentials 항목에 none으로 되어 있는 선택항목에 jenkins 가 추가된다. 여기서 jenkins를 선택해준다(지금까지 Credentials 관련 작업은 Jenkins 메인 화면의 왼쪽 메뉴에 있는 Credentials 메뉴에 들어가서 별도로 진행할 수도 있다) 그리고 Launch method 항목의 고급 버튼을 클릭하면 아래와 같은 화면이 나온다. 여기서 JavaPath 항목에 /usr/bin/java 를 입력한다.
지금까지의 과정대로 입력하고 Save 버튼을 클릭하면 노드 화면에 다음과 같이 slave01 이 등록되어 있는 화면이 나타난다. 만약 이렇게 나오지 않았다면 제대로 등록된 것이 아니기 때문에 삭제하고 다시 재등록해준다. 삭제하는 방법은 slave01에 마우스를 대보면 slave01 옆에 검은색 역삼각형이 생기는데 이것을 클릭하면 Delete Agent 항목이 생긴다. 이 항목을 클릭하면 Agent가 삭제된다.
이렇게 Jenkins의 분산 빌드 환경을 구성해보았다. 현재는 slave01 1개만 등록했지만 더 추가할려면 slave01 설정하듯이 했던 방법을 반복적으로 해주면 된다.
'프로그래밍 > Docker' 카테고리의 다른 글
| Apache Kafka 실습환경을 Docker에 구성해보기(feat. 아파치 카프카 입문) (1) | 2020.07.29 |
|---|---|
| Vagrant 기반의 Minikube 실습 (0) | 2020.02.14 |
| Vagrant 기반의 Minikube 설치 (0) | 2020.02.13 |
| Hyper-V에 CoreOS 설치하기(2) (0) | 2017.11.12 |
| Hyper-V에 CoreOS 설치하기(1) (0) | 2017.11.12 |