Jenkins로 git push → Kubernetes 자동 배포 연동

2023년 4월 6일·6 min read

Jenkins(오픈소스 CI/CD 자동화 서버)를 처음 익히며 흐름과 연동 절차를 정리했다. git push 한 번이 테스트·빌드·배포까지 이어지는 그림을 잡는 게 첫 목표였다.

전체 흐름

git push 한 번에 Jenkins가 소스를 받아오고, 빌드와 Docker 이미지 푸시를 거쳐 Kubernetes로 배포까지 이어진다. 5단계가 한 줄로 이어진다.

각 단계 사이를 묶어주는 게 Webhook(저장소 이벤트를 외부 서버로 알려주는 HTTP 콜백)과 Jenkins의 Job 설정이다. 이 두 가지가 CI/CD의 실제 연결고리다.

Jenkins를 처음 띄울 때 거치는 순서.

Jenkins가 소스를 가져올 수 있게 저장소와 연결한다. 사용자명·비밀번호 방식은 보안상 취약하므로 SSH 키 방식으로 진행했다.

여기까지 하면 Jenkins가 저장소를 클론할 수 있다. 하지만 push 이벤트를 자동으로 감지하려면 Webhook을 따로 연결해야 한다.

push 이벤트마다 Jenkins가 빌드를 시작하게 만드는 단계다.

GitHub 설정에서 access token을 발급받아 복사해둔다. 이 토큰은 한 번만 노출되므로 바로 옮겨놓는다.

대상 저장소의 Settings → Webhooks → Add webhook으로 들어가 아래 값을 채운다.

Payload URL은 끝 슬래시까지 포함해야 한다. 슬래시가 빠지면 Jenkins의 GitHub 플러그인이 요청을 받지 못한다.

Jenkins 관리 → 시스템 설정 → GitHub → Add github server로 들어가 Credentials를 추가한다.

Kind를 Secret text로 고를 때 Secret 필드와 ID 필드를 헷갈리지 않는 게 포인트다. 토큰 값은 Secret에, ID는 Jenkins 내부에서 이 자격증명을 부를 때 쓰는 라벨이다.

생성한 credentials를 고른 뒤 Test connection을 눌러 정상 응답이 오는지 확인한다.

마지막으로 파이프라인이 Webhook 신호를 받아 빌드를 시작하도록 트리거를 켠다.

파이프라인 메인 화면 → 구성 → Build Triggers → GitHub hook trigger for GITScm polling 체크.

이 옵션이 켜져 있어야 GitHub에서 들어온 push 이벤트가 실제 빌드로 이어진다.

Jenkins 위에서 Kubernetes를 함께 쓰면 단순한 배포 자동화 이상으로 묶을 수 있는 지점들이 있다.

쿠버네티스 환경에서만 동작하는 소스코드를 kube-apiserver 같은 컴포넌트와 상호작용시키며, Unit Test를 쿠버네티스 pod 위에서 직접 돌릴 수 있다.
Jenkins에서 Volume Mount, ConfigMap, Secret 같은 쿠버네티스 기능을 그대로 끌어와 빌드·배포 과정에 쓸 수 있다.
Jenkins 플러그인 중 쿠버네티스 관련 기능이 많고, 쿠버네티스 자동 배포에 최적화되어 있다.