[GitLab] 깃랩 CI/CD 캐시

깃랩은 배포 시의 캐시를 지원한다.

여기서의 캐시는 파일 시스템에 저장이 되고

프로젝트별로 관리가 되어

캐싱할 부분은 매번 빌드하지 않고

다시 사용하여 배포 시간을 단축시킬 수 있다.

 

필자는 깃랩 캐시를 사용해서 배포 시간을 줄였다.

 

캐시를 활용해서 4분 22초대였던 배포 시간을 줄일 수 있었다.

 

그럼 깃랩 캐시가 무엇인지 자세히 확인해보자.

 

https://docs.gitlab.com/ee/ci/caching/

Caching in GitLab CI/CD | GitLab

 

 

https://gitlab-docs.infograb.net/ee/ci/caching/

GitLab 공식 기술 문서 한글판 by 인포그랩 | 인포그랩 | GitLab 기반 DevSecOps 구축,컨설팅,교육,CICD Pipe

 

 

빌드 시간이 4분이 넘었을 때

 

gradle bootJar 명령 이후 거의 4분에 가까이 아무 동작이 없었다.

 

그래서 --info 명령을 통해 어떤 작업이 일어나는지 확인했는데

 

Resource missing. [HTTP GET: https://maven.pkg.jetbrains.space/public/p/compose/dev/com/android/application/com.android.application.gradle.plugin/8.6.1/com.android.application.gradle.plugin-8.6.1.pom]

 

이런 식의 메세지가 엄청 뜨고 있었다.

 

여기서 문제점은 필자가 빌드하는 서버는 스프링서버이고 안드로이드 프로젝트가 아니다.

 

그런데 필요없는 패키지를 다운받고 있는 것이다.

 

이것은 gradle 설정을 바꿔야 하는 것이니 다음 포스트에서 다루려 한다.

 

위에 상황도 그렇고 이런 패키지들을 매번 받고있는 것도 문제였다.

 

이것을 해결할 수 있는 것이 깃랩 CICD 캐시이다.

 

 

캐시는 보다싶이 인터넷에서 다운로드한 패키지와 같은 종속 항목에 사용된다고 한다.

 

아티팩트는 단계간에 빌드 결과를 공유한다.

 

필자는 프론트 배포 시에 빌드 결과인 정적 파일들을 전달하는데 사용했었다.

 

front_upload:
  stage: upload
  variables:
    AWS_PROFILE: profile
  dependencies:
    - front_build
  tags:
    - tag
  script:
    - cd path/to/artifact
    - aws cp . s3://bucket-name/key
   path/to/artifact
  cache:
    key: build-cache-front
    paths:
      - $GRADLE_USER_HOME
  artifacts:
    paths:
      - path/to/artifact
  rules:
    - if: $CI_COMMIT_BRANCH =~ /^release-frontend.*$/
      when: always

 

 

공식 문서에서 설명하는 캐시와 아티팩트의 차이 나열

 

캐시

• cache 키워드를 사용하여 작업당 캐시를 정의합니다. 그렇지 않으면 비활성화됩니다.
• 이후 파이프라인에서 캐시를 사용할 수 있습니다.
• 동일한 파이프라인의 이후 작업은 종속 항목이 동일한 경우 캐시를 사용할 수 있습니다.
• 다른 프로젝트는 캐시를 공유할 수 없습니다.
• 기본적으로 보호 및 비보호 브랜치는 캐시를 공유하지 않습니다. 그러나 이 동작을 변경할 수 있습니다.

 

아티팩트

• 작업당 아티팩트를 정의합니다.
• 동일 파이프라인의 후속 작업은 아티팩트를 사용할 수 있습니다.
• 다른 프로젝트는 아티팩트를 공유할 수 없습니다.
• 기본적으로 아티팩트는 30일 후에 만료됩니다. 사용자 정의 만료 시간을 정의할 수 있습니다.
• 최신 아티팩트는 최신 성공적인 작업의 아티팩트를 유지할 경우에만 만료되지 않습니다.
• 종속 항목을 사용하여 어떤 작업이 아티팩트를 가져올지 제어합니다.

 

좋은 캐싱 관행

 

읽고 요약한 좋은 캐싱 관행은 다음과 같다.

 

1. Runner에 태그를 지정하고 해당 태그를 공유하는 작업에서 사용하라.

 

여기서 러너에 태그를 지정하는 것은 전에 러너등록할 때 설명과 태그를 지정하는데 그것을 말하는 것이다.

 

2. 특정 프로젝트에서만 사용 가능한 러너를 사용하라.

 

specific runner 를 말하는 것이다.

 

3. 워크플로에 맞는 key를 사용하라. 예를 들어 각 브랜치에 대해 다른 캐시를 구성할 수 있다.

 

브랜치별, 프로젝트별 캐시 키를 구성할 수 있다.

 

대체 캐시 키 사용

 

대체 키란 키가 miss 되었을 때 확인할 다음 캐싱 공간이다.

 

test-job:
  stage: build
  cache:
    - key: cache-$CI_COMMIT_REF_SLUG
      fallback_keys:
        - cache-$CI_DEFAULT_BRANCH
        - cache-default
      paths:
        - vendor/ruby
  script:
    - bundle config set --local path 'vendor/ruby'
    - bundle install
    - echo Run tests...

 

위는 공식 문서에 있는 코드인데 fallback_keys 로 대체 키를 사용하고 있다.

 

이 대체 키도 variables 에 설정해서 전역으로 대체 키를 쓸 수도 있다.

 

variables:
  CACHE_FALLBACK_KEY: fallback-key

 

이렇게 설정하게 되면 캐시 찾는 순서는

 

1. stage 에 설정한 key 로 캐시를 찾는다.

2. stage 에 설정한 대체 키를 찾는다.

3. 전역 대체 키를 찾는다.

 

로 동작한다.

 

그리고 이 키는 [] 라는 빈 배열을 줘서 비활성화시킬 수도 있다.

 

캐시 키 이름을 브랜치 명으로 지정하면 각 브랜치에서 공유하게 되고

 

고정된 값을 쓰게 되면 프로젝트에서 공유하게 된다!

 

캐시 저장 위치

러너의 실행기 유형에 따라 달라지는데

 

shell은 

/home/gitlab-runner/cache/<user>/<project>/<cache-key>/cache.zip

 

docker 는

 

/var/lib/docker/volumes/<volume-id>/_data/<user>/<project>/<cache-key>/cache.zip

 

정리

 

깃랩에는 아티팩트와 캐시가 있고 

아티팩트는 stage 간에 빌드 결과를 공유할 수 있는 파일 시스템이고

캐시는 외부 라이브러리 등을 미리 다운받아두는 파일 시스템이다.

 

캐시를 쓸 때는 특정 프로젝트에만 사용가능한 러너에 맞는 캐시와

적절한 key 를 써서 (각 브랜치 별 할 수 있는 등) 쓰는 것이 좋고

또 대체 키를 사용하는 것이 좋다!