컨테이너 레지스트리 데이터 전송량 줄이기

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

이미지 또는 태그가 컨테이너 레지스트리에서 다운로드되는 빈도에 따라 데이터 전송은 GitLab.com 제한을 초과할 수 있습니다. 이 페이지에서는 컨테이너 레지스트리로 전송하는 데이터 양을 줄이는 여러 권장 사항과 팁을 제공합니다.

데이터 전송 사용량 확인

전송 사용량은 GitLab UI 내에서 사용할 수 없습니다. GitLab-#350905 는 이 정보를 표출하기 위한 작업을 추적하는 Epic입니다. 그동안 GitLab 팀원은 전송 한도를 크게 초과한 고객에게 연락하여 사용 사례를 더 잘 이해하고 데이터 전송 사용량을 줄이는 방법을 제공할 수 있습니다.

이미지 크기 확인

이 도구들과 기술을 사용하여 이미지의 크기를 확인할 수 있습니다:

  • Skopeo: Skopeo inspect 명령을 사용하여 API 호출을 통해 레이어 수와 크기를 조사할 수 있습니다. 따라서 docker pull IMAGE를 실행하기 전에 이 데이터를 검사할 수 있습니다.

  • CI에서 Docker: Docker를 사용하여 이미지를 푸시하기 전에 GitLab CI를 사용하여 이미지 크기를 조사하고 기록할 수 있습니다. 예를 들어: 

    docker inspect "$CI_REGISTRY_IMAGE:$IMAGE_TAG" \
      | awk '/"Size": ([0-9]+)[,]?/{ printf "Final Image Size: %d\n",$2 }'

  • Dive 는 Docker 이미지, 레이어 내용을 탐색하고 해당 크기를 줄이는 방법을 찾을 수 있는 도구입니다.

이미지 크기 줄이기

더 작은 베이스 이미지 사용

Alpine Linux와 같이 더 작은 베이스 이미지를 사용하는 것을 고려해보세요. 알파인 이미지는 약 5MB로, Debian과 같은 인기 있는 베이스 이미지보다 몇 배나 작습니다. Go 애플리케이션과 같이 자체 포함된 정적 이진 파일로 애플리케이션이 제공되는 경우 도커 scratch 베이스 이미지를 사용할 수도 있습니다.

특정 베이스 이미지 운영 체제를 사용해야 하는 경우, 이미지 크기를 줄이는 데 도움이 되는 -slim 또는 -minimal 변형을 찾아보세요.

또한 베이스 이미지 상에 설치하는 운영 체제 패키지에 주의해야 합니다. 이러한 패키지는 수백 메가바이트에 달할 수 있습니다. 빌드 중 설치되는 패키지의 수를 최소한으로 유지해보세요.

다중 단계 빌드는 일시적인 빌드 의존성을 정리하는 데 강력한 도구가 될 수 있습니다.

또한 다음과 같은 도구를 사용하는 것도 고려해볼 수 있습니다:

  • DockerSlim 이미지 크기를 줄이는 일련의 명령을 제공합니다.
  • Distroless 이미지는 애플리케이션과 해당 런타임 의존성만 포함하고 있습니다. 패키지 관리자, 셸 또는 표준 리눅스 배포판에서 발견할 수 있는 다른 프로그램을 포함하지 않습니다.

레이어 최소화

Dockerfile의 각 명령은 해당 명령 중에 적용된 파일 시스템 변경 사항을 기록하는 새로운 레이어로 이어집니다. 일반적으로 더 많거나 더 큰 레이어는 더 큰 이미지로 이어집니다. Dockerfile에서 패키지를 설치하는 데 필요한 레이어 수를 최소화하도록 노력해보세요. 그렇지 않으면 빌드 프로세스의 각 단계가 이미지 크기를 늘리게 됩니다.

레이어 수와 크기를 줄이기 위한 여러 전략이 있습니다. 예를 들어 설치하려는 각 운영 체제 패키지마다 RUN 명령을 사용하는 대신, 한 번의 RUN 명령으로 모든 패키지를 설치하여 빌드 프로세스의 단계 수를 줄이고 이미지 크기를 줄일 수 있습니다.

다른 유용한 전략으로는 모든 일시적인 빌드 의존성을 제거하고, 패키지를 설치하기 전과 후에 운영 체제 패키지 관리자 캐시를 비활성화하거나 비워야 합니다.

이미지를 빌드할 때 관련 파일만 복사하도록 합니다. Docker의 .dockerignore를 사용하면 빌드 프로세스가 관련 없는 파일을 무시하도록 할 수 있습니다.

DockerSlim과 같은 타사 도구로 이미지를 최소화할 수 있습니다. 그러나 이러한 도구를 부적절하게 사용하면 응용 프로그램이 특정 조건에서 작동하는 데 필요한 의존성을 제거할 수 있습니다. 그러므로 이미지를 납작하게 만드는 대신 빌드 프로세스 중에 더 작은 이미지를 만드는 것이 좋습니다.

다중 단계 빌드 사용

다중 단계 빌드를 사용하면 Dockerfile의 각 FROM 문을 사용하여 여러 개의 빌드 단계를 사용할 수 있습니다. 각 FROM 명령은 다른 베이스를 사용하고, 각각은 새로운 빌드 단계를 시작합니다. 원하는 것만 최종 이미지에 남기고 다른 모든 것은 버릴 수 있습니다. 특히 빌드 의존성을 설치해야 하지만 최종 이미지에는 필요하지 않은 경우에 유용합니다.

이미지 풀 정책 사용

docker 또는 docker+machine 실행자를 사용할 때, Docker 이미지를 가져올 때 runner config.toml에서 pull_policy 매개변수를 설정할 수 있습니다. 크고 드물게 업데이트되는 이미지를 가져올 때 데이터 전송을 피하려면 원격 레지스트리에서 이미지를 가져올 때 if-not-present 풀 정책을 사용해보세요.

Docker 레이어 캐싱 사용

docker build를 실행할 때, Dockerfile의 각 명령은 레이어로 결과를 남깁니다. 이러한 레이어는 캐시로 유지되어 변경 사항이 없는 경우 재사용될 수 있습니다. --cache-from 인수를 사용하여 docker build 명령에 캐시 소스로 태그가 지정된 이미지를 사용할 수 있습니다. 여러 --cache-from 인수를 사용하여 여러 이미지를 캐시 소스로 지정할 수 있습니다. 이를 통해 빌드 속도를 높이고 데이터 전송량을 줄일 수 있습니다. 자세한 내용은 Docker 레이어 캐싱 설명서를 참조하세요.

자동화 주기 확인

특정 간격으로 정기적 작업을 수행하기 위해 컨테이너 이미지에 번들화된 자동화 스크립트를 만들곤 합니다. GitLab 레지스트리에서 컨테이너 이미지를 가져와 GitLab.com 외부 서비스로 전송하는 자동화 간격을 줄일 수 있습니다.

GitLab Premium 또는 Ultimate으로 이전하기

GitLab.com의 데이터 전송 한도는 티어 수준으로 설정됩니다. 더 높은 제한이 필요한 경우 GitLab Premium 또는 Ultimate으로 업그레이드를 고려해보세요.

추가 데이터 전송 구매

데이터 전송 한도를 관리하는 방법에 대해 자세히 알아보세요.

관련 이슈

  • 기본 Docker 이미지가 업데이트되었을 때 이미지를 다시 빌드하려 할 수 있습니다. 그러나 파이프라인 구독 한도가 너무 낮아 이 기능을 활용할 수 없습니다. 이를 해결하기 위해 매일 또는 하루에 여러 번 다시 빌드할 수 있습니다. GitLab-#225278에서는 이 워크플로우를 돕기 위해 한도를 높이는 것을 제안하고 있습니다.