[Github Action] ARC 를 이용한 Gradle Build Cache

 

 

Action Controller Runner (이하 ARC) 는 파드 단위 Self Hosted Runner 입니다. 

 

즉, 쿠버네티스 환경에서 파드를 Self Hosted Runner 로 지정할 수 있게 해주는 오픈소스죠.

 

ARC 에 대한 정보는 여기를 확인해주세요.

 

근데 ARC 를 사용하는 경우 하나 고려해야 할 사항이 있습니다.

바로 ARC 에 의해 만들어지는 파드는 Github Action 의 Job 이 종료될 경우 제거되고 다시 생성됩니다.

 

Job 단위마다 Runner 를 삭제하고 생성

 

 

따라서 HostPath 나 EFS 를 사용하지 않으면 Job 을 실행할 때 생성했던 Java SDK, Node, Build File 등 또한 같이 삭제됩니다.

그 말은 즉슨, caching 을 할 수 없으며, 매번 필드할 때 마다 새롭게 패키지를 설치하기 때문에 Job 을 수행하는데 보다 더 많은 시간이 소요 된다는 것이죠.

 

따라서 이번 글에서는 ARC 를 이용할 때 파드에 EFS 를 마운트하여 caching 이 가능하도록 해보겠습니다.

build file 을 EFS 에 저장하여 caching

 

 

사전조건

• Build 할 Kotlin Project
• Action Runner Controller Helm Chart
• EFS CSI Driver

 

ARC 설치는 여기를 참고해주세요.

 

Runner 의 종류로는 RunnerDeploy, RunnerSet 이 있고, 여기서는 RunnerDeploy 를 통해 배포해보겠습니다.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv
spec:
  capacity:
    storage: 10Ei
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  storageClassName: ""
  persistentVolumeReclaimPolicy: Retain
  csi:
    driver: efs.csi.aws.com
    volumeHandle: <EFS ID>::<Access Point ID>
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc
  namespace: actions-runner-system
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: ""
  resources:
    requests:
      storage: 1Ei

 

PV 와 PVC 를 위와 같이 배포해줍니다. 

이후 배포한 PV 를 RunnerDeploy 에 마운트 해줍니다. 자세한 사항은 여기를 참고해주세요.

apiVersion: actions.summerwind.dev/v1alpha1
kind: RunnerDeployment
metadata:
  name: runner
  namespace: actions-runner-system
spec:
  replicas: 2
  template:
    spec:
      serviceAccountName: ""
      organization: <organization name>
      ephemeral: true 
      dockerEnabled: true
      dockerRegistryMirror: <docker registry url>
      workDir: /runner/_work
      labels:
        - runner
        - al2_x86_64
      resources:
        requests:
          cpu: "500m"
          memory: "1000Mi"
      nodeSelector:
        purpose: self-hosted-runner
      tolerations:
        - key: "self-hosted-runner"
          value: "true"
          operator: "Equal"
          effect: "NoExecute"
      volumeMounts:
        - mountPath: /build-cache
          name: runner-pv # 위에서 생성한 pv 이름
      volumes:
        - name: runner-pv
          persistentVolumeClaim:
            claimName: pvc # 위에서 생성한 pvc 이름

• ephemeral: true 
  • Job 이 끝나면 기존 Runner 는 삭제하고 새로운 Runner 를 생성합니다 (true 가 권장됨)
• dockerEnabled: true
  • Job 을 수행할 때 Docker Engine 을 통해 수행 됩니다
• dockerRegistryMirror
  • Image 를 가져올 Registry URL 을 작성합니다
• workDir
  • Job 이 수행되는 Directory 입니다 (default 가 /runner/_work)

 

EFS 의  /build-cache 디렉터리에 caching 을 진행할 겁니다.

 

이후 kotlin Project 를 gradle 를 통해 build 해봅시다.

아래와 같은 명령어로 gradle build 시 caching 될 디렉터리를 명시할 수 있습니다. 

./gradlew build \
    --no-daemon \
    --build-cache \
    --project-cache-dir=/build-cache/.gradle \
    --gradle-user-home=/build-cache/.gradle

 

gradle 은 기본적으로 해당 프로젝트 위치에 caching 디렉터리를 생성하고 선택하기 때문에 --gradle-user-home 을 통해 gradle 이 바라볼 곳은 지정합니다.

 

Github Action 으로 옮기면 아래와 같이 쓸 수 있죠.

runs:
  using: "composite"
  steps:
    - uses: actions/setup-java@v3
      with:
        distribution: 'zulu' # See 'Supported distributions' for available options
        java-version: '11'

    - run: ./gradlew build --no-daemon --build-cache --project-cache-dir=/build-cache/gradle --gradle-user-home=/build-cache/gradle
      shell: bash

 

모든 준비는 끝났습니다. 

 

Action 을 실행하여 얼마나 속도 차이가 나는 지 확인해보죠!

 

테스트한 파드의 스펙은 아래와 같습니다.

• cpu : 400Mi
• memory : 1Gi

 

caching 전

caching 전 - 4분9초 소요

 

caching 후

caching 후 - 1분1초 소요

 

확연히 Build 속도가 빨라진 것을 확인할 수 있습니다.

더 나아가 Docker Build 또한 caching 해 속도를 높일 수 있습니다. 그건 각자에게 맡기도록 하죠!

 

그럼 오늘은 여기까지!