GitLab CI/CD 캐싱

Job과 파이프라인 간에 의존성을 다운로드하기 위해 GitLab CI/CD에서 캐싱을 사용하는 방법을 설명합니다.

캐시는 Job이 다운로드하고 저장하는 하나 이상의 파일입니다. 동일한 캐시를 사용하는 후속 Job은 파일을 다시 다운로드할 필요가 없으므로 더 빠르게 실행됩니다. .gitlab-ci.yml 파일에서 캐시를 정의하는 방법은 cache 참조 를 참조합니다. 고급 캐시 키 전략을 위해 다음을 사용할 수 있습니다: cache:key:files : 특정 파일의 내용에 연결된 키를 생성합니다. cache:key:files_commits : 특정 파일의 최신 커밋에 연결된 키를 생성합니다. 더 많은 사용 사례와 예시는 CI/CD 캐싱 예시 를 참조합니다. 캐시와 아티팩트의 차이점 # 인터넷에서 다운로드하는 패키지와 같은 의존성에는 캐시를 사용합니다. 캐시는 GitLab Runner가 설치된 위치에 저장되며 분산 캐시가 활성화된 경우 S3에 업로드됩니다. Stage 간에 중간 빌드 결과를 전달하는 데는 아티팩트를 사용합니다. 아티팩트는 Job에 의해 생성되고 GitLab에 저장되며 다운로드할 수 있습니다. 아티팩트와 캐시 모두 프로젝트 디렉터리를 기준으로 경로를 정의하며, 그 외부의 파일에는 링크할 수 없습니다. 캐시 # cache 키워드를 사용하여 Job별로 캐시를 정의합니다. 정의하지 않으면 비활성화됩니다. 후속 파이프라인은 캐시를 사용할 수 있습니다. 의존성이 동일하면 같은 파이프라인의 후속 Job도 캐시를 사용할 수 있습니다. 서로 다른 프로젝트는 캐시를 공유할 수 없습니다. 기본적으로 보호된 브랜치와 보호되지 않은 브랜치는 캐시를 공유하지 않습니다 . 하지만 이 동작을 변경 할 수 있습니다. 아티팩트 # Job별로 아티팩트를 정의합니다. 같은 파이프라인의 이후 Stage에 있는 후속 Job은 아티팩트를 사용할 수 있습니다. 아티팩트는 기본적으로 30일 후 만료됩니다. 사용자 지정 만료 시간 을 정의할 수 있습니다. 최신 아티팩트 유지 가 활성화된 경우 최신 아티팩트는 만료되지 않습니다. 어떤 Job이 아티팩트를 가져올지 제어하려면 dependencies 를 사용합니다. 좋은 캐싱 관행 # 캐시의 가용성을 최대한 보장하려면 다음 중 하나 이상을 수행합니다: 러너에 태그를 지정 하고 캐시를 공유하는 Job에 그 태그를 사용합니다. 특정 프로젝트에서만 사용할 수 있는 러너를 사용합니다 . 워크플로에 맞는 key 를 사용합니다. 예를 들어 브랜치마다 다른 캐시를 구성할 수 있습니다. 러너가 캐시를 효율적으로 사용하려면 다음 중 하나를 수행해야 합니다: 모든 Job에 러너 하나만 사용합니다. 캐시가 S3 버킷에 저장되는 분산 캐싱 을 지원하는 여러 러너를 사용합니다. GitLab.com의 인스턴스 러너는 이 방식으로 동작합니다. 이러한 러너는 자동 확장 모드일 수 있지만 반드시 그래야 하는 것은 아닙니다. 캐시 객체를 관리하려면 일정 기간이 지난 후 캐시 객체를 삭제하는 수명 주기 규칙을 적용합니다. 수명 주기 규칙은 오브젝트 스토리지 서버에서 사용할 수 있습니다. 동일한 아키텍처의 여러 러너를 사용하고, 이 러너들이 캐시를 저장할 공통 네트워크 마운