標記和版本設定容器映像的建議

將容器映像推送至容器登錄後再加以部署時，您需要映像標記和版本設定的策略。本文討論兩種方法，以及這兩個方法在容器生命週期中的適用時機：

穩定標記

建議：使用穩定標記來維護容器組建的基礎映像。避免在部署時使用穩定標記，因為這些標記會繼續接收更新，可能會造成實際執行環境中發生不一致的情況。

穩定標記表示開發人員或建置系統可以繼續提取特定標記，持續取得更新。穩定並不表示內容是凍結的。相對地，穩定代表的是映像對於該版本來說應該是穩定的。為了保持「穩定」，映像可能已套用了安全性修補檔或架構更新。

架構小組發行了 1.0 版。他們知道他們將會寄送更新，包括次要更新。為了支援指定主要和次要版本的穩定標記，他們會有兩組穩定標記。

當基礎映像更新或任何類型的架構維護版本可供使用時，具有穩定標記的映像會更新為代表該版本最新穩定版本的最新摘要。

在此情況下，主要和次要標記都會持續受到維護。在基礎映像案例中，這可讓映像擁有者提供經過維護的映像。

如果更新具有穩定標記的映像，則先前標記的影像會取消標記，產生孤立的映像。上一個映像的資訊清單和唯一圖層資料會保留在登錄中。若要維護登錄大小，您可以定期刪除穩定映像更新所產生的未標記資訊清單。例如，自動清除超過指定持續時間的未標記資訊清單，或為未標記的資訊清單設定保留原則。

建議：針對部署使用唯一標記，特別是在可在多個節點上擴展的環境中。建議您謹慎部署版本一致的元件。如果您的容器重新啟動或協調器擴增了更多的執行個體，您的主機便不會意外提取較新的版本，而造成與其他節點的不一致。

唯一標記僅表示推送至登錄的每個映像都有唯一的標記。不會重複使用標記。您可以遵循數種模式來產生唯一標記，包括：

日期時間戳記 - 這種方法相當常見，因為您可以清楚分辨映像的建置時間。但是，如何將其與組建系統相互關聯？您是否必須找到同時完成的組建？您所在的時區為何？您的所有組建系統是否都校正為 UTC？
Git 認可 – 在您開始支援基礎映像更新之前都可以使用此方法。如果發生了基礎映像更新，您的組建系統會使用與上一個組建相同的 Git 認可來啟動。然而，基礎映像卻有了新的內容。一般而言，Git 認可可提供「半」穩定標記。
資訊清單摘要 - 推送至容器登錄的每個容器映像都會與資訊清單相關聯，由唯一的 SHA-256 雜湊或摘要來識別。雖然摘要是唯一的，但冗長又難以閱讀，而且與您的組建環境沒有相互關聯。
組建識別碼 - 此選項可能是最理想的，因為其可能是累加的，而且可讓您相互關聯回特定的組建，以尋找所有組建成品和記錄。不過，就像資訊清單摘要一樣，人員可能難以閱讀。

如果您的組織有數個組建系統，在標記前面加上組建系統名稱是此選項的一種變化：<build-system>-<build-id>。例如，您可以將 API 小組的 Jenkins 建置系統與 Web 小組的 Azure Pipelines 建置系統的組建區分開來。

我們所建議您的最佳做法是鎖定任何已部署的映像標記，將其 write-enabled 屬性設為 false。此做法可防止您不小心從登錄中移除映像，並可能中斷您的部署。您可以在發行管線中包含鎖定步驟。

鎖定已部署的映像仍可讓您使用 Azure Container Registry 功能，從登錄中移除其他未部署的映像，以維護您的登錄。例如，自動清除超過指定持續時間的未標記資訊清單或解除鎖定的映像，或為未標記的資訊清單設定保留原則。

如需關於本文中概念的詳細探討，請參閱部落格文章 Docker 標記：標記和設定 Docker 映像版本的最佳做法 (英文)。

若需要將 Azure 容器登錄的效能和符合成本效益的使用最大化的協助，請參閱 Azure Container Registry 的最佳做法 (部分機器翻譯)。