GitLab CI/CD 캐싱

GitLab CI/CD에서 캐시를 사용하여 Job 실행을 빠르게 하는 방법.

캐시는 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일 후에 만료됩니다. 사용자 정의 만료 시간 을 정의할 수 있습니다. 최신 아티팩트 유지 가 활성화된 경우 최신 아티팩트는 만료되지 않습니다. dependencies 를 사용하여 어떤 Job이 아티팩트를 가져오는지 제어합니다. 좋은 캐싱 관행 # 캐시의 최대 가용성을 보장하려면 다음 중 하나 이상을 수행합니다: 러너에 태그를 지정 하고 캐시를 공유하는 Job에서 태그를 사용합니다. 특정 프로젝트에서만 사용 가능한 러너를 사용합니다 . 워크플로에 맞는 key 를 사용합니다. 예를 들어, 각 브랜치에 대해 다른 캐시를 구성할 수 있습니다. 러너가 캐시를 효율적으로 사용하려면 다음 중 하나를 수행해야 합니다: 모든 Job에 단일 러너를 사용합니다. 캐시가 S3 버킷에 저장되는 분산 캐싱 이 있는 여러 러너를 사용합니다. GitLab.com의 인스턴스 러너는 이 방식으로 동작합니다. 이러한 러너는 자동 확장 모드에 있을 수 있지만 반드시 그럴 필요는 없습니다. 캐시 객체를 관리하려면 일정 기간 후 캐시 객체를 삭제하는 수명 주기 규칙을 적용합니다. 수명 주기 규칙은 객체 스토리지 서버에서 사용할 수 있습니다. 동일한 아키텍처의 여러 러너를 사용하고 이 러너들이 캐시를 저장하기 위해 공통 네트워크 마운트 디렉토리를 공유합니