brief.ing.gg

BRIEFING

오래된 컨테이너 이미지는 어떻게 자동 정리할까

오래된 컨테이너 이미지는 어떻게 자동 정리할까

Scope

핵심 질문

컨테이너 레지스트리와 호스트에 쌓이는 오래된 이미지를 배포 안전성을 해치지 않고 어떻게 자동 정리하는가?

Research

핵심 근거

  • 현재 배포 중인 image digest와 rollback에 필요한 최근 버전을 먼저 보호해야 한다.
  • tag age만으로 삭제하면 mutable tag와 오래된 rollback release를 잘못 제거할 수 있다.
  • registry retention과 host image prune은 서로 다른 계층이므로 별도 정책이 필요하다.

참고 자료

  • Docker image prune docs: https://docs.docker.com/reference/cli/docker/image/prune/

Draft

이미지 정리는 단순히 오래된 순서로 지우면 안 된다. 현재 실행 중인 digest와 rollback 후보를 먼저 보호해야 한다.

레지스트리 정책

배포에 사용된 최근 N개 release, production tag가 가리키는 digest, 수동 pin한 이미지를 보존한다. 나머지는 생성일이나 마지막 pull 시각을 기준으로 retention 정책을 적용한다.

Mutable Tag 문제

latest 같은 tag는 다른 digest를 가리킬 수 있다. 따라서 tag 문자열보다 digest를 기준으로 어떤 이미지가 실제 배포에 사용되는지 추적하는 편이 안전하다.

호스트 정리

레지스트리에서 이미지를 지워도 각 Docker host의 local cache는 남는다. 반대로 host에서 prune해도 registry image는 삭제되지 않는다. 두 정책을 분리해야 한다. 특히 docker image prune -a는 컨테이너에서 참조하지 않는 이미지를 제거하므로, registry에서 보존한 이전 release라도 host의 rollback cache에서는 사라질 수 있다. 자동 정리 전에 삭제 후보와 보호할 digest를 확인하고, 필요한 로컬 이미지를 제외하는 절차 또는 접근 가능한 registry에서 해당 digest를 다시 받을 수 있는지 검증해야 한다.

Rollback

배포 실패 시 직전 이미지로 돌아갈 수 있어야 한다. 현지에 보존된 digest를 쓰거나, registry에 유지한 digest를 실제로 다시 가져와 복구되는지 미리 시험한다. tag만 남아 있다는 이유로 host 정리 후에도 즉시 rollback이 가능하다고 가정하지 않는다.

핵심

안전한 자동정리는 '삭제 조건'보다 '절대 삭제하면 안 되는 집합'을 먼저 정의하고 나머지에 retention을 적용하는 방식이다.