쿠버네티스에서 젠킨스 에이전트 구성

쿠버네티스에서 젠킨스 에이전트 구성

젠킨스 노드 관리 

홈 화면에서 젠킨스 관리 > 노드 관리 메뉴로 이동한다.

• 신규 노드
  • 에이전트 노드를 추가한다. 고정된 여러 대의 서버에서 에이전트 노드를 추가해야 할 때 필요하다.
• Configure Cloud
  • 클라우드 환경 기반의 에이전트를 설정할 때 필요하다. 쿠버네티스 위에 설치된 젠킨스의 에이전트에 관한 설정도 이 메뉴에서 설정할 수 있다.
• Node Monitoring
  • 에이전트 노드의 안정성을 위한 각종 모니터링과 관련된 사항을 설정할 수 있다.
• 노드 목록
  • 현재 구성된 노드의 목록을 보여준다. 쿠버네티스상에 설치한 젠킨스는 작업이 진행될 때만 파드 형태의 에이전트가 생성되고 작업이 끝나면 파드가 사라지기 때문에 작업중이 아니라면 이 목록에는 젠킨스 컨트롤러 노드만 표시된다.

 

 

쿠버네티스에서 젠킨스 에이전트 구성

Configure Cloud 메뉴로 이동한다.  

• Kubernetes
  • 쿠버네티스 설정과 관련된 영역이다. Name 에 이름을 지정할 수 있다.
• Kubernetes Cloud details
  
  • 쿠버네티스 클라우드에 접속하기 위한 정보를 설정할 수 있다. 쿠버네티스 위에 설치한 젠킨스는 쿠버네티스 클러스터 내부에서 동작하기 때문에 기본값으로 둬도 무방하지만, 쿠버네티스 클러스터 외부에 젠킨스를 설치한 경우에는 이곳에서 쿠버네티스에 대한 정보를 수정해야한다.
• Pod Template
  • 쿠버네티스 위에 설치된 젠킨스는 작업 시 에이전트를 파드의 형태로 생성한다. 이곳에서 에이전트로 사용할 파드와 관련된 설정을 한다. 이때 Pod Template은 젠킨스 컨트롤러를 다시 시작하면 모든 설정이 초기화된다. 따라서 현재 환경에서 마스터노드를 다시 시작하면 모든 설정이 초기화된다. 이를 해결하기 위해 설정값(jenkins-config.yaml) 을 읽어 들이도록 구성할 수 있다. 

 

젠킨스 에이전트 템플릿의 상세내용

내용을 살펴보기 전에 잠깐 현재 작업에 대한 목적을 간단히 살펴보자. 젠킨스의 CI/CD 작업은 실제로 에이전트로 동작하는데, 쿠버네티스 환경에서는 에이전트가 파드로 운영되나 이 파드에는 도커 빌드를 위한 docker 명령과 쿠버네티스 환경에서는 에이전트가 파드로 운영되나 이 파드에는 도커빌드를 위한 docker 명령과 쿠버네티스 배포를 위한 kubectl 명령이 존재하지 않는다. 가장쉬운 해결 방법은 호스트 시스템에 있는 도커와 kubectl을 그대로 이용하는 것이다. 따라서 hostpath를 잡아 각 노드에 이미 설치돼 있는 도커와 kubectl 을 그대로 이용한다. 여기서 hostpath란 쿠버네티스 파드에서 워커노드에 있는 특정 경로를 마운트해서 파드 내에서 사용할 수 있는것을 말한다.

 

Pod Template은 말 그대로 파드의 구성요소를 그대로 메뉴상에 넣어둔것이다. 상당히 많은 내용이 있으나 실제로는 파드 생성에 필요한 정보들을 그대로 구현한 것입니다. 그러면 기본적인 Pod Template 정보를 살펴보자

• Name
  • Pod Template의 이름을 설정할 수 있다.
• Label
  • 에이전트 노드를 구분할 때 사용할 레이블을 설정할 수 있다. 여기서 설정하는 레이블은 pod metadata에 label을 설정하는 것과 동일한다.
• Usage
  • 노드의 사용 방법(Usage)을 설정할 수 있으며  젠킨스 컨트롤러와 마찬가지로 Use this  node as much as possible (이 노드를 가능한 많이 사용)인 기본 설정을 그대로 사용한다.

Pod Template에 파드에 대한 기본 정보를 입력했으니 파드에서 사용할 컨테이너 설정을 진행한다.

 

 

파드에서 사용할 컨테이너를 설정하는 메뉴이다.

 

• Name
  • 컨테이너를 구분하기 위한 이름이다.
• Docker image
  • 컨테이너에서 사용할 이미지를 지정한다. 이미지는 기본 설정대로 젠킨스에서 제공하는 inbound-agent:4.3-4를 사용한다.
• Command to run
  • 여기에 적혀진 명령은 컨테이너에서 실행하는 명령이 된다. 기존에 실행하는 명령위에 덮어쓰는 구조로 컨테이너의 의도와 다르게 강제 실행을 위한 명령이 있는 경우 사용될 수 있다. 하지만 젠킨스 에이전트로 동작하는 파드의 경우 컨테이너는 젠킨스에서 의도한 대로 동작해야 하기 때문에 빈칸으로 설정했다.
• Environment Variable
  • 컨테이너 환경변수를 설정하는 곳이다. 

 

다음으로 빌드 작업 중 호스트에 설치된 명령어를 파드 내부에서 사용하기 위한 Volumes를 설정하는 메뉴를 살펴보자. 

• Config Map Volume
  • 쿠버네티스에 존재하는 ConfigMap 오브젝트를 파드 내부에 연결해 이를 파드에서 사용할 수 있다.
• Empty Dir Volume
  • 파일 및 내용이 없는 디렉터리를 파드 내부에 생성한다. 젠킨스로 빌드할 때 컨테이너가 여러 개 생성될 수 있는데, 이런 경우 컨테이너 간에 공유할 수 있는 디렉터리로 사용할 볼륨으로 Empty Dir을 주로 사용한다.
• Host Path Volume 
  • 호스트, 즉 쿠버네티스 워커 노드에 파일 및 디렉터리를 파드에서 사용할 수 있도록 연결해준다. 이를통해 파드는 호스트에 위치한 명령이나 데이터를 사용할 수 있으며, 필요한 경우 파일을 저장해 파드가 사라진 경우에도 데이터를 보존할 수 있다. 실습에서는 이 볼륨을 사용해 파드 필요한 실행 파일을 호스츠에서 가지고 와서 사용한다.
• NFS Volume
  • NFS 서버에 위치한 원격의 디렉터리를 파드가 사용할 수 있도록 한다.
• Persistent Volume Claim
  • 쿠버네티스 클러스터에서 PVC로 설정한 볼륨을 파드에서 사용할 수 있도록 한다.
• Secret Volume
  • 쿠버네티스에 있는 Secret 오브젝트를 파드 내부에 연결해 파드에서 사용할 수 있도록 한다.

 

젠킨스를 이용한 배포작업은 내부에서 셸 스크립트 단위로 작업을 나누어 구성할 수 있다. 우리의 목적은 젠킨스를 이용해 컨테이너 이미지를 빌드하고 컨테이너를 쿠버네티스에  배포하는것이다. 이를 위해 젠킨스 내부에서 kubectl, docker와 같은 명령어를 사용해야한다. 하지만 배포되는 파드는 이와 같은 명령들이 포함돼 있지 않은 도커 이미지이기 때문에 호스트에 존재하는 명령을 파드에서 그대로 사용할 수 있는 Host Path Volume 을 사용해 구성하였다. 구조적으로는 Host path (쿠버네티스 워커 노드)에 있는 내용이 Mount path(젠킨스 에이전트 파드)로 설정되는 구조이다.

 

• (kubectl)Host Path Volume
  • kubectl 명령을 에이전트 파드 내부에서 사용할 수 있도록 /usr/bin/kubectl 경로를 호스트로부터 연결해준다. 이를 통해 빌드 작업 중 쿠버네티스와 관련된 작업을 할 수 있다.
• (docker)Host Path Volume
  • docker 명령을 에이전트 파드 내부에서 사용할 수 있도록 /usr/docker 경로를 호스트로부터 연결해준다. 이를 통해 빌드 작업 중 도커 이미지를 생성하고 저장소로 밀어 넣을 수 있다.
• (docker.sock)Host Path Volume
  • kubectl과 API 서버가 통신하는 것처럼 도커도 도커 데몬과 통신하기 위해서 API 서버 역할을 하는 docker.sock가 있다. 따라서 이미 호스트에 설치된 /var/run/docker.sock 소켓을 에이전트 파드에 사용하도록 설정해 준다.

 

 

• 서비스 어카운트
  • 쿠버네티스 클러스터 및 오브젝트 정보를 조회하기 위한 계정입니다. 젠킨스에 접속하기 위한 admin 계정과 같은 개념이다. 젠킨스의 에이전트 파드는 jenkins라는 서비스 어카운트를 사용한다.
• 사용자 ID
  • 에이전트 파드가 실행될 때 파드에 부여되는 숫자로, 리눅스 사용자에게 부여되는 숫다로 리눅스 사용자에게 부여되는 숫자 식별자이다. 여기에서는 에이전트가 파드가 루트 권한을 가진 사용자 ID를 사용하지 않게 하기 위해서 사용자 ID에 대한 값은 1000으로 설정한다.
• 그룹 ID
  • 에이전트 파드가 실행될 때 파드에 부여되는 숫자로 리눅스 사용자에게 부여되는 숫자로 된 식별자이다. 관용적으로 리눅스에서 사용되는 0부터 500까지의 ID는 리눅스 시스템이 사용하는 ID이다. 여기에서는 에이전트 파드가 시스템이 사용하는 ID를 쓰지 않고 독립적으로 컨테이너를 구동할 수 있게 하기위해 993으로 설정했다.

쿠버네티스 API 서버와의 통신은 단순히 서비스 어카운트 설정하고 이에 맞는 사용 ID 및 그룹 ID를 가진다고 해서 가능한것이 아니다. 서비스 어카운트에 쿠버네티스 API 서버와의 통신권한을 따로 적용해야한다.

 

 

 

 

 

 

 

 

출처:

"컨테이너 인프라 환경 구축을 위한 쿠버네티스/도커 - 조훈,심근우,문성주 지음/길벗출판사" 책을 기반으로 실습한 내용입니다.