컨테이너 이미지 태그 지정 및 버전 관리에 대한 권장 사항

  • 아티클

컨테이너 이미지를 컨테이너 레지스트리로 푸시한 후 배포할 때에는 이미지 태그 지정 및 버전 관리에 대한 전략이 필요합니다. 이 문서에서는 두 가지 방법과 각 방법이 컨테이너 수명 주기 동안 적합한 위치에 대해 설명합니다.

  • 안정적인 태그 - 예를 들어 mycontainerimage: 1.0과 같은 주 버전 또는 부 버전을 나타내기 위해 다시 사용하는 태그입니다.
  • 고유 태그 - mycontainerimage: abc123과 같이 레지스트리에 푸시하는 각 이미지에 대한 다른 태그입니다.

안정적인 태그

권장 사항: 안정적인 태그를 사용하여 컨테이너 빌드에 대한 기본 이미지를 유지합니다. 이러한 태그는 계속해서 업데이트를 수신하고 프로덕션 환경에서 불일치를 발생시킬 수 있으므로 안정적인 태그로 배포하지 마세요.

안정적인 태그는 개발자(또는 빌드 시스템)가 계속해서 특정 태그를 가져올 수 있습니다. 즉, 업데이트를 계속 받습니다. 안정성은 콘텐츠가 고정되어 있음을 의미하지 않습니다. 오히려 안정성은 이미지가 해당 버전의 의도에 맞게 안정적이어야 함을 의미합니다. "안정적인" 상태를 유지하기 위해 보안 패치 또는 프레임워크 업데이트를 적용하도록 처리될 수 있습니다.

예시

프레임워크 팀은 버전 1.0을 제공합니다. 이 팀은 사소한 업데이트를 포함하여 업데이트를 제공할 것임을 알고 있습니다. 지정된 주 버전과 부 버전에 안정적인 태그를 지원하기 위해 두 가지 안정적인 태그 집합을 제공합니다.

  • :1 – 주 버전에 대한 안정적인 태그입니다. 1은 “최신” 또는 “최근” 1.* 버전을 나타냅니다.
  • :1.0 - 버전 1.0에 대한 안정적인 태그로, 개발자가 1.0 업데이트에 바인딩할 수 있으며 릴리스되면 1.1로 롤포워드할 수 없습니다.

기본 이미지 업데이트를 사용할 수 있거나 프레임워크의 모든 서비스 릴리스 유형을 사용할 수 있는 경우, 안정적인 태그가 있는 이미지는 해당 버전의 최신 안정 릴리스를 나타내는 최신 다이제스트로 업데이트됩니다.

이 경우 주 태그와 보조 태그는 모두 계속해서 처리됩니다. 기본 이미지 시나리오에서 이미지 소유자는 처리된 이미지를 제공할 수 있습니다.

태그가 없는 매니페스트 삭제

안정적인 태그가 있는 이미지가 업데이트되면 이전에 태그가 지정된 이미지에 태그가 지정되지 않아 분리된 이미지가 됩니다. 이전 이미지의 매니페스트와 고유 레이어 데이터는 레지스트리에 남아 있습니다. 레지스트리 크기를 유지하기 위해 안정적인 이미지 업데이트로 인해 발생하는 태그가 지정되지 않은 매니페스트를 주기적으로 삭제할 수 있습니다. 예를 들어 지정된 기간보다 오래된 태그가 지정되지 않은 매니페스트를 자동으로 제거하거나, 태그가 지정되지 않은 매니페스트에 대한 보존 정책을 설정합니다.

고유 태그

권장 사항: 특히 여러 노드에서 확장할 수 있는 환경에서 배포에 고유 태그를 사용합니다. 일관된 버전의 구성 요소를 의도적으로 배포하려는 경우가 있습니다. 컨테이너가 다시 시작되거나 오케스트레이터가 더 많은 인스턴스를 스케일 아웃하는 경우, 호스트는 다른 노드와 일치하지 않는 새 버전을 실수로 가져오지 않습니다.

고유 태그 지정이란 레지스트리에 푸시된 모든 이미지에 고유한 태그가 있음을 의미합니다. 태그는 다시 사용되지 않습니다. 다음을 포함하여 고유 태그를 생성하기 위해 따를 수 있는 몇 가지 패턴이 있습니다.

  • 날짜-시간 스탬프 - 이미지가 작성된 시기를 명확하게 알 수 있으므로 이 방법이 매우 일반적입니다. 그러나 빌드 시스템에 다시 연결하려면 어떻게 해야 하나요? 동시에 완료된 빌드를 찾아야 하나요? 어떤 표준 시간대에 속해 있나요? 모든 빌드 시스템이 UTC로 보정되나요?

  • Git 커밋 – 이 방법은 기본 이미지 업데이트 지원을 시작할 때까지 작동합니다. 기본 이미지 업데이트가 수행되면 이전 빌드와 동일한 Git 커밋을 사용하여 빌드 시스템이 시작됩니다. 그러나 기본 이미지에는 새 콘텐츠가 있습니다. 일반적으로 Git 커밋은 반안정적인 태그를 제공합니다.

  • 매니페스트 다이제스트 - 컨테이너 레지스트리에 푸시된 각 컨테이너 이미지는 고유한 SHA-256 해시 또는 다이제스트로 식별되는 매니페스트와 연결됩니다. 다이제스트는 고유하지만 길고 읽기 어려우며 빌드 환경과 상관 관계가 없습니다.

  • 빌드 ID - 이 옵션은 증분 가능성이 있기 때문에 가장 좋을 수 있으며, 모든 아티팩트 및 로그를 찾기 위해 특정 빌드와 다시 연관시킬 수 있습니다. 그러나 매니페스트 다이제스트와 마찬가지로 사람이 읽기 어려울 수 있습니다.

    조직에 여러 빌드 시스템이 있는 경우 빌드 시스템 이름을 포함하는 태그는 이 <build-system>-<build-id> 옵션의 변형입니다. 예를 들어 API 팀의 Jenkins 빌드 시스템과 웹 팀의 Azure Pipelines 빌드 시스템의 빌드를 구분할 수 있습니다.

배포된 이미지 태그 잠금

모범 사례로, write-enabled 특성을 false로 설정하여 배포된 이미지 태그를 잠그는 것이 좋습니다. 이 방법은 레지스트리에서 이미지를 실수로 제거하여 배포가 중단되는 문제를 방지합니다. 릴리스 파이프라인에 잠금 단계를 포함할 수 있습니다.

배포된 이미지를 잠그면 레지스트리를 유지 관리하는 Azure Container Registry 기능을 사용하여 레지스트리에서 배포되지 않은 다른 이미지를 제거할 수 있습니다. 예를 들어 지정된 기간보다 오래된 태그가 지정되지 않은 매니페스트 또는 잠금 해제된 이미지를 자동으로 제거하거나, 태그가 지정되지 않은 매니페스트에 대한 보존 정책을 설정합니다.

다음 단계

이 문서의 개념에 대한 자세한 내용은 Docker 태그 지정: Docker 이미지 태그 지정 및 버전 관리에 대한 모범 사례 블로그 게시물을 참조하세요.

Azure Container Registry의 성능 및 비용 효율적인 사용을 최대화하려면 Azure Container Registry에 대한 모범 사례를 참조하세요.