InfoGrab Docs

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

요약

컨테이너 레지스트리에서 이미지 또는 태그를 다운로드하는 빈도에 따라 데이터 전송이 상당히 많을 수 있습니다. GitLab UI에서는 전송 사용량을 사용할 수 없습니다. 이미지 크기를 확인하기 위한 도구 및 기법: Skopeo: Skopeo inspect 명령을 사용하여 API 호출을 통해 레이어 수와 크기를 검사합니다.

컨테이너 레지스트리에서 이미지 또는 태그를 다운로드하는 빈도에 따라 데이터 전송이 상당히 많을 수 있습니다. 이 페이지에서는 컨테이너 레지스트리로 전송하는 데이터 양을 줄이기 위한 몇 가지 권장 사항과 팁을 제공합니다.

데이터 전송 사용량 확인#

GitLab UI에서는 전송 사용량을 사용할 수 없습니다. GitLab-#350905는 이 정보를 노출하기 위한 작업을 추적하는 에픽입니다.

이미지 크기 확인#

이미지 크기를 확인하기 위한 도구 및 기법:

  • 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와 같은 더 작은 기본 이미지를 사용하는 것을 고려하세요. Alpine 이미지는 약 5 MB로 Debian과 같은 인기 있는 기본 이미지보다 몇 배 작습니다. Go 애플리케이션과 같이 애플리케이션이 독립 실행형 정적 바이너리로 배포되는 경우 Docker scratch 기본 이미지를 사용하는 것도 고려할 수 있습니다.

특정 기본 이미지 OS를 사용해야 하는 경우 이미지 크기를 줄이는 데 도움이 되는 -slim 또는 -minimal 변형을 찾아보세요.

또한 기본 이미지 위에 설치하는 운영 체제 패키지에 주의하세요. 이러한 패키지는 수백 MB에 달할 수 있습니다. 설치된 패키지 수를 최소한으로 유지하려고 노력하세요.

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

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

  • DockerSlim은 컨테이너 이미지 크기를 줄이는 명령 집합을 제공합니다.
  • Distroless 이미지에는 애플리케이션과 런타임 종속성만 포함됩니다. 표준 Linux 배포판에서 찾을 수 있는 패키지 관리자, 셸 또는 기타 프로그램이 포함되어 있지 않습니다.

레이어 최소화#

Dockerfile의 모든 명령은 해당 명령 중에 적용된 파일 시스템 변경 사항을 기록하는 새 레이어를 생성합니다. 일반적으로 레이어가 많거나 클수록 이미지가 커집니다. Dockerfile에서 패키지를 설치하기 위한 레이어 수를 최소화하려고 노력하세요. 그렇지 않으면 빌드 프로세스의 각 단계에서 이미지 크기가 증가할 수 있습니다.

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

또 다른 유용한 전략은 패키지를 설치하기 전후에 일시적인 빌드 종속성을 모두 제거하고 운영 체제 패키지 관리자 캐시를 비활성화하거나 비우는 것입니다.

이미지를 빌드할 때 관련 파일만 복사하는지 확인하세요. Docker의 경우 .dockerignore를 사용하면 빌드 프로세스가 관련 없는 파일을 무시하는 데 도움이 됩니다.

DockerSlim과 같은 다른 서드파티 도구를 사용하여 이미지를 최소화할 수 있습니다. 이러한 도구를 잘못 사용하면 애플리케이션이 특정 조건에서 작동하는 데 필요한 종속성이 제거될 수 있습니다. 따라서 이미지를 빌드 후 최소화하는 대신 빌드 프로세스 중에 더 작은 이미지를 위해 노력하는 것이 바람직합니다.

다단계 빌드 사용#

다단계 빌드를 사용하면 Dockerfile에서 여러 FROM 명령문을 사용합니다. 각 FROM 명령은 다른 기본을 사용할 수 있으며 각각은 새 빌드 단계를 시작합니다. 한 단계에서 다른 단계로 아티팩트를 선택적으로 복사하여 최종 이미지에 원하지 않는 모든 것을 남길 수 있습니다. 이는 빌드 종속성을 설치해야 하지만 최종 이미지에 있을 필요가 없을 때 특히 유용합니다.

이미지 가져오기 정책 사용#

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

Docker 레이어 캐싱 사용#

Docker 레이어 캐싱을 사용하면 빌드 속도를 높이고 전송되는 데이터 양을 줄일 수 있습니다. 자세한 내용은 Docker-in-Docker 빌드에서 Docker 레이어 캐시하기를 참조하세요.

자동화 빈도 확인#

특정 간격으로 정기적인 작업을 수행하기 위해 컨테이너 이미지에 번들된 자동화 스크립트를 만드는 경우가 많습니다. GitLab.com 외부의 서비스로 GitLab 레지스트리에서 컨테이너 이미지를 가져오는 자동화의 경우 그 간격의 빈도를 줄일 수 있습니다.

관련 이슈#

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

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

Tier: Free, Premium, Ultimate
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
원문 보기
요약

컨테이너 레지스트리에서 이미지 또는 태그를 다운로드하는 빈도에 따라 데이터 전송이 상당히 많을 수 있습니다. GitLab UI에서는 전송 사용량을 사용할 수 없습니다. 이미지 크기를 확인하기 위한 도구 및 기법: Skopeo: Skopeo inspect 명령을 사용하여 API 호출을 통해 레이어 수와 크기를 검사합니다.

컨테이너 레지스트리에서 이미지 또는 태그를 다운로드하는 빈도에 따라 데이터 전송이 상당히 많을 수 있습니다. 이 페이지에서는 컨테이너 레지스트리로 전송하는 데이터 양을 줄이기 위한 몇 가지 권장 사항과 팁을 제공합니다.

데이터 전송 사용량 확인#

GitLab UI에서는 전송 사용량을 사용할 수 없습니다. GitLab-#350905는 이 정보를 노출하기 위한 작업을 추적하는 에픽입니다.

이미지 크기 확인#

이미지 크기를 확인하기 위한 도구 및 기법:

  • 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와 같은 더 작은 기본 이미지를 사용하는 것을 고려하세요. Alpine 이미지는 약 5 MB로 Debian과 같은 인기 있는 기본 이미지보다 몇 배 작습니다. Go 애플리케이션과 같이 애플리케이션이 독립 실행형 정적 바이너리로 배포되는 경우 Docker scratch 기본 이미지를 사용하는 것도 고려할 수 있습니다.

특정 기본 이미지 OS를 사용해야 하는 경우 이미지 크기를 줄이는 데 도움이 되는 -slim 또는 -minimal 변형을 찾아보세요.

또한 기본 이미지 위에 설치하는 운영 체제 패키지에 주의하세요. 이러한 패키지는 수백 MB에 달할 수 있습니다. 설치된 패키지 수를 최소한으로 유지하려고 노력하세요.

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

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

  • DockerSlim은 컨테이너 이미지 크기를 줄이는 명령 집합을 제공합니다.
  • Distroless 이미지에는 애플리케이션과 런타임 종속성만 포함됩니다. 표준 Linux 배포판에서 찾을 수 있는 패키지 관리자, 셸 또는 기타 프로그램이 포함되어 있지 않습니다.

레이어 최소화#

Dockerfile의 모든 명령은 해당 명령 중에 적용된 파일 시스템 변경 사항을 기록하는 새 레이어를 생성합니다. 일반적으로 레이어가 많거나 클수록 이미지가 커집니다. Dockerfile에서 패키지를 설치하기 위한 레이어 수를 최소화하려고 노력하세요. 그렇지 않으면 빌드 프로세스의 각 단계에서 이미지 크기가 증가할 수 있습니다.

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

또 다른 유용한 전략은 패키지를 설치하기 전후에 일시적인 빌드 종속성을 모두 제거하고 운영 체제 패키지 관리자 캐시를 비활성화하거나 비우는 것입니다.

이미지를 빌드할 때 관련 파일만 복사하는지 확인하세요. Docker의 경우 .dockerignore를 사용하면 빌드 프로세스가 관련 없는 파일을 무시하는 데 도움이 됩니다.

DockerSlim과 같은 다른 서드파티 도구를 사용하여 이미지를 최소화할 수 있습니다. 이러한 도구를 잘못 사용하면 애플리케이션이 특정 조건에서 작동하는 데 필요한 종속성이 제거될 수 있습니다. 따라서 이미지를 빌드 후 최소화하는 대신 빌드 프로세스 중에 더 작은 이미지를 위해 노력하는 것이 바람직합니다.

다단계 빌드 사용#

다단계 빌드를 사용하면 Dockerfile에서 여러 FROM 명령문을 사용합니다. 각 FROM 명령은 다른 기본을 사용할 수 있으며 각각은 새 빌드 단계를 시작합니다. 한 단계에서 다른 단계로 아티팩트를 선택적으로 복사하여 최종 이미지에 원하지 않는 모든 것을 남길 수 있습니다. 이는 빌드 종속성을 설치해야 하지만 최종 이미지에 있을 필요가 없을 때 특히 유용합니다.

이미지 가져오기 정책 사용#

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

Docker 레이어 캐싱 사용#

Docker 레이어 캐싱을 사용하면 빌드 속도를 높이고 전송되는 데이터 양을 줄일 수 있습니다. 자세한 내용은 Docker-in-Docker 빌드에서 Docker 레이어 캐시하기를 참조하세요.

자동화 빈도 확인#

특정 간격으로 정기적인 작업을 수행하기 위해 컨테이너 이미지에 번들된 자동화 스크립트를 만드는 경우가 많습니다. GitLab.com 외부의 서비스로 GitLab 레지스트리에서 컨테이너 이미지를 가져오는 자동화의 경우 그 간격의 빈도를 줄일 수 있습니다.

관련 이슈#

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