컨테이너 이미지를 컨테이너 레지스트리에 푸시한 후 이를 배포하려면, 이미지 태그 지정과 버전 관리를 위한 전략이 필요합니다. 이 문서에서는 컨테이너 수명 주기 전반에서 각각이 어떻게 활용되는지에 초점을 맞추어 두 가지 접근 방식을 설명합니다.
- 안정적인 태그는 예를 들어 mycontainerimage:1.0과 같이 주요 버전이나 부 버전을 나타내기 위해 반복해서 재사용하는 태그를 의미합니다.
- 고유 태그는 mycontainerimage: abc123과 같이 레지스트리에 푸시하는 각 이미지마다 서로 다른 태그를 부여하는 방식을 의미합니다.
안정적인 태그
권장 사항: 컨테이너 빌드를 위한 기본 이미지를 유지 관리하기 위해 안정 태그를 사용하는 것을 권장합니다. 이러한 태그는 계속해서 업데이트를 수신하고 프로덕션 환경에서 불일치를 발생시킬 수 있으므로 안정적인 태그로 배포하지 마세요.
안정적인 태그는 개발자나 빌드 시스템이 지속적으로 업데이트되는 특정 태그를 계속해서 가져올 수 있음을 의미합니다. 안정이라는 표현이 해당 태그의 내용이 고정되어 있음을 의미하는 것은 아닙니다. 오히려 안정성은 이미지가 해당 버전의 의도에 맞게 안정적이어야 함을 의미합니다. “안정” 상태를 유지하기 위해 보안 패치나 프레임워크 업데이트가 적용될 수 있습니다.
예제
프레임워크 팀은 버전 1.0을 제공합니다. 이 팀은 사소한 업데이트를 포함하여 업데이트를 제공할 것임을 알고 있습니다. 지정된 주 버전과 부 버전에 안정적인 태그를 지원하기 위해 두 가지 안정적인 태그 집합을 제공합니다.
-
:1– 주 버전을 나타내는 안정 태그입니다.1은 “최신” 또는 “최근” 1.* 버전을 나타냅니다. -
:1.0- 1.0 버전에 대한 안정 태그로, 개발자가 1.0의 업데이트에만 연결되도록 하고 1.1이 출시되었을 때 해당 버전으로 자동 전환되지 않도록 합니다.
기본 이미지 업데이트를 사용할 수 있거나 프레임워크의 모든 서비스 릴리스 유형을 사용할 수 있는 경우, 안정적인 태그가 있는 이미지는 해당 버전의 최신 안정 릴리스를 나타내는 최신 다이제스트로 업데이트됩니다.
이 경우 주 버전 태그와 부 버전 태그 모두에 대해 지속적으로 유지 관리와 업데이트가 이루어집니다. 기본 이미지 시나리오의 관점에서 보면, 이는 이미지 소유자가 유지 관리가 반영된 이미지를 제공할 수 있도록 합니다.
태그가 지정되지 않은 매니페스트를 삭제합니다.
안정 태그가 지정된 이미지가 업데이트되면, 이전에 해당 태그가 지정되어 있던 이미지는 태그가 제거되어 고아 이미지로 남게 됩니다. 이전 이미지의 매니페스트와 해당 이미지에만 고유하게 포함된 레이어 데이터는 레지스트리에 그대로 남아 있습니다. 레지스트리의 저장 공간 사용량을 적정 수준으로 유지하려면 안정 이미지가 업데이트되면서 생성된 태그가 없는 매니페스트를 주기적으로 삭제할 수 있습니다. 예를 들어 지정한 기간보다 오래된 태그 없는 매니페스트를 자동 정리하도록 설정하거나, 태그 없는 매니페스트에 대해 보존 정책을 설정할 수 있습니다.
고유 태그
권장 사항: 특히 여러 노드로 확장될 수 있는 환경에서는 배포에 고유 태그를 사용하는 것이 좋습니다. 구성 요소의 일관된 버전을 의도적으로 배포하는 방식을 사용하는 것이 바람직합니다. 컨테이너가 다시 시작되거나 오케스트레이터가 더 많은 인스턴스를 스케일 아웃하는 경우, 호스트는 다른 노드와 일치하지 않는 새 버전을 실수로 가져오지 않습니다.
구성 요소의 일관된 버전을 의도적으로 배포하는 방식을 사용하는 것이 바람직합니다. 태그는 다시 사용되지 않습니다. 고유 태그를 생성하기 위해 따를 수 있는 여러 가지 방식이 있으며, 그 예는 다음과 같습니다.
날짜-시간 스탬프 방식은 이미지가 언제 빌드되었는지를 명확하게 확인할 수 있기 때문에 비교적 일반적으로 사용됩니다. 그러나 이를 빌드 시스템과 어떻게 연계하여 추적할 수 있을까요? 동시에 완료된 빌드를 찾아야 할까요? 어떤 표준 시간대에 속해 있나요? 모든 빌드 시스템이 UTC 기준으로 맞춰져 있나요?
Git commit 방식은 기본 이미지 업데이트를 지원하기 시작할 때까지 유용하게 사용할 수 있습니다. 기본 이미지 업데이트가 수행되면 이전 빌드와 동일한 Git 커밋을 사용하여 빌드 시스템이 시작됩니다. 하지만 기본 이미지에 새로운 내용이 추가된 경우에는 문제가 발생할 수 있습니다. 일반적으로 Git 커밋은 반 안정 태그를 제공합니다.
매니페스트 다이제스트 - 컨테이너 레지스트리에 푸시된 각 컨테이너 이미지는 매니페스트와 연결되며, 이 매니페스트는 고유한 SHA-256 해시 값 또는 다이제스트로 식별됩니다. 고유하긴 하지만, 다이제스트는 길고 읽기 어렵으며 빌드 환경과는 연관성이 없습니다.
빌드 ID - 이 옵션이 가장 적합할 수 있으며, 점진적으로 증가할 가능성이 높고, 특정 빌드와 연계하여 모든 아티팩트와 로그를 확인할 수 있도록 해줍니다. 하지만 매니페스트 다이제스트와 마찬가지로 사람이 읽기에는 어려울 수 있습니다.
조직에 여러 빌드 시스템이 있는 경우, 태그 앞에 빌드 시스템 이름을 붙이는 방식은 이 옵션의 변형으로 사용할 수 있습니다.
<build-system>-<build-id>. 예를 들어, API 팀의 Jenkins 빌드 시스템과 웹 팀의 Azure Pipelines 빌드 시스템에서 생성된 빌드를 구분할 수 있습니다.
배포된 이미지 태그를 잠급니다.
모범 사례로, 배포된 이미지 태그의 잠금을 설정하고 해당 write-enabled속성을 false로 지정하는 것을 권장합니다. 이 방법은 레지스트리에서 이미지를 실수로 제거하여 배포가 중단되는 문제를 방지합니다. 배포 파이프라인에 이미지 태그 잠금 단계를 포함시킬 수 있습니다.
배포된 이미지를 잠그면 레지스트리를 유지 관리하는 Azure Container Registry 기능을 사용하여 레지스트리에서 배포되지 않은 다른 이미지를 제거할 수 있습니다. 예를 들어 지정한 기간보다 오래된 태그 없는 매니페스트나 잠금 해제된 이미지를 자동 정리하도록 하거나, 태그 없는 매니페스트에 대해 보존 정책을 설정할 수 있습니다.
관련 콘텐츠
Azure 컨테이너 레지스트리의 성능을 최대화하고 비용 효율적으로 사용하기 위해 Azure Container Registry 모범 사례를 참고하십시오.