Jenkins CI 파이프라인 - 패키지 의존성 캐시 문제

[choshsh]

이슈

Jenkins 파이프라인으로 gradle이나 npm을 빌드할 때, 패키지 의존성을 매번 새로 설치하려니 빌드 속도가 너무 느리다.

• Jenkins CI에서 kubernetes plugin으로 pod를 동적으로 프로비저닝
• 1개의 Pod에 jdk, node, git 등의 컨테이너 존재

목표

캐시 데이터를 보존하고 재활용하여 빌드 속도를 개선한다.

트러블슈팅

시도 #1 - PVC로 캐시 디렉토리 마운트

삽질만 잔뜩 하고 실패...

Kubernetes plugin은 jnlp라는 기본 컨테이너가 존재하며 workspace를 공유한다.

Kubernetes 플러그인은 Kubernetes 포드에 Jenkins 에이전트를 할당합니다. 이러한 포드 내에는 항상 jnlpJenkins 에이전트를 실행하는 하나의 특수 컨테이너 가 있습니다. 다른 컨테이너는 선택한 임의의 프로세스를 실행할 수 있으며 에이전트 포드의 모든 컨테이너에서 명령을 동적으로 실행할 수 있습니다.

실패 이유는 다음과 같다.

1. jenkins 플러그인에서 PVC 마운트는 ReadWriteMany 모드만 허용
2. job의 workspace는 빌드 시 디렉토리가 초기화 됨

1번의 경우, ReadWriteMany 는 여러 노드에서 PVC를 마운트하고 사용할 수 있도록 하는 옵션인데 AWS EBS는 지원하지 않는다.

2번의 경우, workspace 내부 캐시 경로에 데이터를 마운트해봤자 빌드가 시작되면서 다 삭제되기 때문에 전혀 효과가 없다.

시도 #2 - 캐시 데이터를 workspace 외부에 저장하여 43% 속도 향상

70%의 성공 👍

캐시 데이터를 외부에 보관하고 빌드할 때 가져와서 쓰도록 구성해서 엄청난 속도 향상을 이뤘다.

GitHub Action 플러그인 Cache의 동작 방식에서 힌트를 얻고 비슷하게 구성했다.

• hostPath와 ReadWriteMany를 사용하여 jenkins agent pod에 마운트(❗workspace인 /home에 하면 안됨)
• 빌드 시 rsync로 가져와서 캐시 hit

Before : 8m 32s 소요. 특히 gradle 빌드 첫단계에서 4m 10s 소요ㅜㅜ

After: 3m 45s 소요. gradle 빌드 첫단계 40s로 통과

하지만 hostPath PV를 사용하는 것이 아쉬운 부분이다. 지금은 jenkins용 노드가 1개지만 늘어나면 어떡하지...

시도 #3 - Amazon EFS CSI 드라이버를 사용

EBS는 안되지만 EFS는 ReadWriteMany 모드를 지원한다고 한다. 나중에 시도해보자.