[Jenkins] 젠킨스 아키텍처와 에이전트 구성 유형

목차

---

젠킨스를 운영하다 보면 예상보다 빠르게 과부하 상황이 발생해 빌드에 오랜 시간이 걸리는 일이 종종 발생합니다.

그래서 커밋을 자주 하는 팀은 젠킨스 인스턴스를 죽이는 일이 종종 발생한다고 하는데요,

이런 이유로 빌드 작업을 Jenkins Master 인스턴스와 Jenkins Agent 인스턴스가 나누어서 수행합니다.

 

이를 그림으로 표현하면 이렇습니다.

사진 출처: https://medium.com/@rejani2906/day-28-jenkins-agents-2d17a883d29f

 

1.  Master-Agent 구조

Jenkins Master

• 커밋이 발생한 후 빌드 시작 명령을 받습니다.
• 만약 빌드 실패 시 슬랙 등에 알림을 보냅니다.
• 클라이언트와 통신하며 HTTP 요청을 처리합니다.
• 에이전트의 우선순위 조정 등 빌드 환경을 관리합니다.

Jenkins Agent

• 실제로 빌드, 테스트, 배포 작업을 수행합니다.

---

2. 통신 프로토콜

Master 노드와 Agent 노드가 통신하려면 양방향 연결이 이뤄져야 하며, 다음 두 가지 방식을 이용할 수 있습니다.

 

2-1. SSH

• 젠킨스에는 SSH 클라이언트가 내장돼 있으므로 에이전트에서 SSH 데몬 서버를 구성하면 됩니다.
• 표준 유닉스 메커니즘을 사용하기 때문에 가장 편리하고 안정적입니다.

2-2. 자바 웹 스타트

• 각 에이전트 머신에서 자바 애플리케이션이 실행되고, 마스터 자바 애플리케이션과 젠킨스 에이전트 애플리케이션 간 TCP 연결이 이뤄집니다.
• 에이전트가 방화벽 네트워크 안에 있어 마스터와 SSH 통신이 불가능할 경우 주로 사용됩니다.

---

3. 에이전트 구성 유형

에이전트는 다음과 같이 다섯 가지로 구성할 수 있습니다.

• 영구 에이전트(Permanent Agent)
• 영구 도커 호스트 에이전트 (Permanent Docker Host Agent)
• 젠킨스 스웜 에이전트 (Jenkins Swarm Agent)
• 동적 프로비저닝 도커 에이전트 (Dynamic Provisioning Dokcer Agent)
• 동적 프로비저닝 쿠버네티스 에이전트 (Dynamic Provisioning Kubernetes Agent)

이제 각 방법의 상세 내용을 알아보겠습니다.

3-1. 영구 에이전트 (Permanent Agent)

영구 에이전트는 항상 사용 가능한 상태로 유지되는 젠킨스 에이전트입니다.

따라서 안정적인 환경을 제공하지만, 리소스 사용량이 고정됩니다.

 

영구 에이전트 생성하기

젠킨스에 접속해 Manage Jenkins -> Nodes에 들어가 New Node를 클릭합니다.

다음과 같이 Permanent Agent Type을 선택해 생성합니다.

 

• Number of executors: 에이전트에서 실행할 수 있는 동시 빌드의 수
• Remote root directory: 에이전트가 빌드 작업을 할 때 사용하는 에이전트 머신 내의 전용 디렉터리
• Lables: 입력된 태그와 일치하는 특정 빌드를 찾습니다. 예를 들어 Java 8 기반의 프로젝트만 찾아서 빌드할 수 있습니다.
• usage: Labels와 일치하는 경우에만 에이전트를 실행할지, 아니면 모든 경우에 실행할지 정합니다.
• Launch method: 에이전트의 시작 방법을 선택합니다.
• Availability: 에이전트가 항상 동작해야 하는지, 또는 특정 조건에 따라 마스터를 오프라인으로 전환할지 정합니다.

 

3-2. 영구 도커 호스트 에이전트 (Permanent Docker Host Agent)

• 영구 에이전트의 단점은 프로젝트 유형별로 다중 에이전트 유형(레이블)을 유지해야 한다는 것입니다.
• 따라서 다음 그림처럼 프로젝트 유형이 3개라면 각 레이블로 구분된 3개의 에이전트를 수동으로 추가하고 관리해야 합니다. 
• 영구 도커 호스트 에이전트는 도커 컨테이너 내에서 실행되는 에이전트이므로, 일일이 레이블을 지정해야 하는 번거로움을 해결할 수 있습니다.
• 각 에이전트는완전히 동일하며, 에이전트 레이블을 지정하는 대신 파이프라인 스크립트에서 사용할 도커 이미지를 정의하면 됩니다.

 

영구 도커 호스트 에이전트 생성하기

영구 에이전트 방식과 똑같이 생성하지만, 차이점은 각 에이전트로 사용할 시스템에 도커를 설치하는 것입니다.

에이전트를 구성하고, 각 파이프라인 스크립트에서 도커 이미지를 정의해야 합니다.

 

파이프라인 구성 예시:

pipeline {
    agent 
    	docker{
        	image 'openjdk:8-jdk-alpine'
        }
    ...
}

 

 

 

3-3. 젠킨스 스웜 에이전트 (Jenkins Swarm Agent)

에이전트 기기가 많고, 확장 작업이 빈번한 경우 유용합니다.

젠킨스 스웜 에이전트를 사용하면 마스터에서 에이전트를 구성할 필요 없이 동적으로 에이전트를 추가할 수 있습니다.

 

젠킨스 스웜 에이전트 생성하기

Jenkins 관리 -> plugins에서 Swarm plugin을 설치합니다.

 

다음으로 에이전트 역할을 할 모든 기기에서 젠킨스 스웜 에이전트 애플리케이션을 실행합니다.

이 작업에는 swarm-client.jar 애플리케이션을 사용합니다.

 

에이전트 노드에서 다음 명령을 사용해 마스터 노드와 연결할 수 있습니다.

java -jar /<스웜파일경로>/swarm-client.jar -url ${젠킨스_URL} -username ${사용자명}

 

3-4. 동적 프로비저닝 도커 에이전트 (Dynamic Provisioning Docker Agent)

• 빌드가 시작될 때마다 동적으로 새로운 에이전트를 생성하도록 젠킨스를 설정합니다.
• 에이전트 수가 빌드 수에 따라 자동으로 조정되므로 가장 유연한 방식입니다.

 

동적 프로비저닝 도커 에이전트 생성하기

3-3과 같은 방식으로 이번엔 Docker 플러그인을 설치한 후, New cloud에서 Docker Type을 선택합니다. 

Docker Cloud details와 Dcoker Agent templates은 아래 사진처럼 구성합니다.

 

• Docker Host URI는 docker0의 ip이며, 이곳에서 에이전트가 실행됩니다.
• tcp 3275 포트는 데몬에 원격 액세스할 때 사용하는 포트입니다.
• docker0에 관한 내용은 이전 포스팅을 참고해주세요.

 

동적 프로비저닝 도커 에이전트를 그림으로 표현하면 아래와 같습니다.

 

1. 젠킨스 작업이 시작되면 마스터는 에이전트 도커 호스트의 jenkins/agent 이미지에서 신규 컨테이너를 실행합니다.
2. jekins/agent 컨테이너는 젠킨스 에이전트를 시작하고, 이를 젠킨스 마스터의 노드 풀에 추가합니다.
3. 젠킨스는 jenkins/agent 컨테이너 내의 파이프라인을 실행합니다.
4. 빌드가 끝나면 마스터 에이전트는 컨테이너를 중단시킨 후 컨테이너를 삭제합니다.

 

이 방법은 도커를 사용한다는 점에서 영구 도커 에이전트 방법과 유사합니다.

하지만 에이전트 추가, 삭제 과정이 자동화되며 확장성이 뛰어납니다.

 

3-5. 동적 프로비저닝 쿠버네티스 에이전트 (Dynamic Provisioning Kubernetes Agent)

이번엔 3-3과 같은 방식으로 Kubernetes 플러그인을 설치하고, 새 클라우드를 생성합니다.

쿠버네티스 에이전트를 생성하려면 쿠버네티스 credential이 필요한데, 저는 쿠버네티스를 사용하지 않았으므로 에이전트 구성은 스킵하겠습니다.

 

동적 프로비저닝 쿠버네티스 에이전트를 그림으로 구성하면 아래와 같습니다.

 

이 방법은 동적 프로비저닝 도커 에이전트와 유사하지만, 단일 도커 호스트가 아닌 다수의 기기로 구성된 쿠버네티스 클러스터와 작업을 하는 점에서 차이점이 있습니다.

---

4. 실습 결과 확인

동적 프로비저닝 도커 에이전트에서 정상적으로 파이프라인 빌드가 수행되는 것을 확인했습니다.

 

 

 

 

---

참고 자료

도커의 2375 포트와 connection refused

서적: Continuous Delivery with Docker and Jenkins