컨테이너 인프라 환경(4) 젠킨스 3. 젠킨스 구성

• 젠킨스 에이전트는 필요 시에 생성되고 작업을 마치면 삭제되는 임시적인 구조를 가진다.
• 따라서 젠킨스 에이전트 작업 내용들은 삭제 전에 젠킨스 컨트롤러에 저장돼야 하며, 이를 위해 젠킨스 에이전트 서비스가 항상 동작하고있다.
• 젠킨스 컨트롤러가 단독으로 설치할 경우에는 컨트롤러가 설치된 서버에서 젠킨스 자체 시스템관리, CI/CD 설정, 빌드 등의 작업을 모두 젠킨스 컨트롤러 단일 노드에서 수행한다.
• 하지만, 컨트롤러-에이전트 구조로 설치할 경우 컨트롤러는 젠킨스 자체의 관리 및 CI/CD와 관련된 설정만을 담당하고 실제 빌드 작업은 에이전트로 설정된 노드에서 이루어진다.

젠킨스 접속

• 웹브라우저에서 로드밸런서 타입의 외부 IP로 접속하여 로그인한다.
• 젠킨스에서는 작업을 수행할 수 있는 각 단위를 쿠버네티스와 동일하게 노드라고 하며, 노드에 레이블을 붙여 관리하거나 노드의 동작 방식을 설정할 수있다.

젠킨스 컨트롤러 설정

• 젠킨스 시스템 설정
• 젠킨스 관리 > 시스템 설정
• 시스템메시지
  • 젠킨스 메인 웹페이지에서 접속했을때 나타나는 메시지를 입력
• of executors
  • 동시에 빌드를 수행할 수 있는 실행기의 개수를 설정하는 옵션
  • 컨트롤러 노드에서 몇 개 까지의 빌드를 실행 할 수 있을지를 설정할 수 있다.
  • 에이전트 파드를 통해 빌드 작업 생성할 때는 0으로 설정
• Label
  • 노드를 구분할 수 있는 레이블을 지정
• Usage
  • 젠킨스의 빌드 작업에 대해 젠킨스 노드가 어떻게 처리할지 설정
  • Use this node as much as possilbe
    • 빌드 작업 수행시 별도의 조건없이 노드에 빌드를 할 수 있는 환경이라면 빌드를 진행 하도록 설정 하는것
  • Only build jobs with label expressions matching this node
    • 이노드와 일치하는 레이블 표현식을 가진 작업만 빌드
• Quiet period
  • 빌드 작업이 시작될 때까지 잠시 대기하는 시간을 설정
  • 초단위
  • 짧은 식나에 변경된 코드에 대해 중복으로 작업을 수행하지 않고 가장 마지막으로 변경된 코드를 빌드하기 위해 설정
• SCM checkout retry count
  • 소스 코드 저장소(SCM)로부터 파일을 가져오지 못한 경우 몇번 재시도를 할지 설정 하는 옵션
• Restrict project naming
  • 젠킨스를 통해 만들어지는 작업의 이름 규칙을 설정하는 옵션
  • 조건은 정규식 패터으로 작성해 적용가능
• Jenkins URL
  • 설치된 젠킨스 컨트롤러의 접속 주소
• Resource Root URL
  • 빌드 결과물과 같은 내용을 외부에 공개하기 위해 사용되는 주소

젠킨스 플러그인 관리

• 젠킨스는 실행되는 모든 기능을 플러그인으로 구현하도록 설계되 있다.
• 호환가능한(Compatible) 플러그인을 선택한후, 업데이트

젠킨스 에이전트

젠킨스 에이전트 설정

• 젠킨스 관리 > 노드 관리
• 신규노드 : 에이전트 노드를 추가
• Configure Clouds : 클라우드 환경 기반의 에이전트를 설정할 때 필요
• Node Monitoring : 에이전트 노드의 안정성을 위한 각종 모니터링과 관련된 사항을 설정 가능
• 노드 목록: 현재 구성된 노드의 목록을 보여준다.

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

• 헬름을 통해 젠키스를 설치할때 JCasC(Jenkins Configuration as Code) 기능을 사용해 현재 쿠버네티스 환경에 맞게 설정을 자동화 할수 있다.
• Configure Clouds
  • Kubernetes Cloud details
    • 쿠버네티스 클러스터에 접속하기 위한 정보를 설정 할 수 있다.
  • Pod Templates
    • 쿠버네티스 위에 설치된 젠킨스는 작업 시 에이전트를 파드의 형태로 생성한다.
    • 이곳에서 에이전트로 사용할 파드와 관련된 설정을 한다.
    • Pod Template은 젠킨스 컨트롤러를 다시 시작하면 모든 설정이 초기화 된다. → 마스터 노드 재시작시 모든 설정 초기화됨
    • 이를 해결하기 위해 헬름 설치시 미리 구성한 설정값을 읽어 들이도록 구성

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

• 호스트 시스템에 있는 도커와 kubectl을 그대로 이용
  • hostpath를 잡아 각 노드에 이미 설치돼 있는 도커와 kubectl을 그대로 이용
  • hostpath란 쿠버네티스 파드에서 워커 노드에 있는 특정 경로를 마운트해서 파드내에서 사용할 수 있는것
• PodTemplate은 파드의 구성요소와 같다.
• Labels
  • 에이전트 노드를 구분할 때 사용할 레이블을 설정할 수 있다.
  • pod metadata에 label을 설정하는것과 동일하다.
• Usages
  • 노드의 사용방법을 설정할 수 있ek.
• 파드에서 사용할 컨테이너 설정 메뉴
  • Docker iamge
    • 컨테이너에서 사용할 이미지를 지정
  • 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(젠킨스 에이전트 파드)로 설정 되게하자.
• 도커에게 도커 데몬과 통신하기 위해 API 서버 역할을 하는 docker.sock이 있다. 호스트에 설치된 소켓을 에이전트 파드에 사용하도록 추가로 설정해주자.
• 에이전트 파드에서 사용할 서비스 어카운트와 사용자 ID 및 그룹 ID를 설정하자.
• 서비스 어카운트
  • 쿠버네티스 클러스터 및 오브젝트의 정보를 조회하기 위한 계정
  • 젠킨스의 에이전트 파드는 jenkins라는 서비스 어카운트를 사용한다.
• 사용자 ID
  • 에이전트 파드가 실행될 때 파드에 부여되는 숫자로, 리눅스 사용자에게 부여되는 숫자 식별자이다.
  • 에이전트 파드가 루트권한을 가진 사용자 ID를 사용하지 않게 하기위해 사용자 ID에 대한 값은 1000으로 설정
• 그룹 ID
  • 리눅스 사용자에게 부여되는 숫자로된 식별자.
  • 0부터 500까지의 ID는 리눅스 시스템이 사용하는 ID이다.

jenkins 서비스 어카운트를 위한 권한 설정하기

• 젠킨스 에이전트 파드에서 쿠버네티스 API 서버로 통신하려면 서비스 어카운트에 권한을 줘야 한다.
• kubectl get serviceaccounts 명령어를 통해 서비스 어카운트 조회 가능
• jenkins 서비스 어카운트를 통해 젠킨스 에이전트 파드를 생성하거나 젠킨스 에이전트 파드 내부에서 쿠버네티스의 오브젝트에 제약 없이 접근하려면 cluster-admin 역할을 부여해야한다.
• 서비스 어카운트에 cluster-admin 역할을 부여하고 이를 권한이 필요한 서비스 어카운트에 바인딩해준다. 이를 역할기반 접근제어(RBAC)라고 한다.
• 쿠버네티스 역할 부여 구조는 할 수 있는 일과 할 수 있는 주체의 결합으로 이루어진다.
• Rules: Role, ClusterRole이 가지고 있는 자세한 행동 규칙
  • apiGroups,resources,verbs의 속성을 가진다.
  • apiGroups - 접근할 수 있는 API 집합
  • resources - API 그룹에 분류된 자원 중 접근 가능한 자원을 선별하기위해 사용
  • verbs 를 통해 해당 자원에 대해서 할 수 있는 행동을 규정
    • get, list, create, wathc 등
• Role, ClusterRole
  • 할 수 있는 일을 대표하는 오브젝트
  • Rules에 적용된 규칙에 따른 동작을 할 수 있으며 적용 범위에 따라 Role과 ClusterRole로 나뉜다.
  • Role은 해당 Role을 가진 주체가 특정 namespace에 대해서 접근할 수 있다.
  • ClusterRole은 해당 ClusterRole을 가진 주체가 쿠버네티스 클러스터 전체에 대해서 접근 할 수 있도록 한다.
• RoleBinding, ClusterRoleBinding
  • Role과 ClusterRole을 할 수있는 주체를 대표하는 속성인 Subjects와 연결시켜 주는 역할을한다.
  • Role과 ClusterRole은 공통적으로 roleRef(할 수 있는 역할 참조)와 subjects(수행 주체)라는 속성을 가지고 있으며 이 두가지가 결합하여 역할 기반 접근제어를 수행하게 된다.
  • RoleBinding은 Role과 결합하여 네임스페이스 범위의 접근 제어를 수행하고
  • ClusterRoleBinding은 ClusterRole과 결합해 클러스터 전체 범위의 접근 제어를 수행한다.
• Subjects
  • 역할 기반 접근제어에서 행위를 수행하는 주체를 의미
  • 특정 사용자 , 그룹, 서비스 어카운트르 속성으로 가질수 있다.
  • 사용자는 쿠버네티스에 접근을 수행하는 실제 이용자를 의미
  • 쿠버네티스 클러스터에 등록된 사용자의 목록은 kubeconfig users 섹션에 기록돼 있다.
  • 서비스 어카운트는 파드 내부의 프로세스에 적용되는 개념
  • 서비스 어카운트는 파드 내부의 프로세스에 적용되는 개념이다.
  • 파드는 네임 스페이스에 존재하는 default 서비스 어카운트를 사용하거나특정한 서비스 어카운트를 사용하도록 설정할 수 있으며 파드 내부의 프로세스는 설정된 서비스 어카운트로서 쿠버네티스상에 존재하는 자원에 접근을 시도할 수있다.

kubectl create clusterrolebinding jenkins-cluster-admin --clusterrole=cluster-admin --serviceaccount=default:jenkins

• clusterrolebinding을 jenkins-cluster-admin 이라는 이름으로 만든다.
  • cluster role에 cluster admin 이라는 미리정의된 클러스터 관리자 역할 부여
  • jenkins-cluster-admin이라는 클러스터 역할의 서비스 어카운트를 jenkins로 지정
  • 여러 가지 서비스 어카운트가 존재할 수 있으므로 jenkins가 속해 있는 네임스페이스 default도 함께 지정
• kubectl get clusterrolebindings jenkins-cluster-admin -o yaml clusterrole binding에 적요된 내용들을 확인