コンテナー イメージのタグ付けとバージョン管理に関する推奨事項

コンテナー イメージをコンテナー レジストリにプッシュして、その後、デプロイする場合、イメージのタグ付けやバージョン管理には戦略が必要です。 この記事では 2 つのアプローチを取り上げ、コンテナー ライフサイクルにおいてそれぞれが適合するシナリオについて説明します。

• 安定したタグ - たとえば、メジャー バージョンまたはマイナー バージョンを示すために再利用するタグ (例: mycontainerimage:1.0)。
• 一意のタグ - レジストリにプッシュするイメージごとに異なるタグ (mycontainerimage:abc123 など)。

安定したタグ

推奨事項: コンテナー ビルドの基本イメージを維持するには、安定したタグを使用します。 安定したタグは更新プログラムを継続的に受け取り、運用環境での不整合を生じる可能性があるため、これらのタグを使用したデプロイは避けます。

"安定したタグ" は、開発者またはビルド システムが継続的に特定のタグをプルし、そのタグは引き続き更新プログラムを受け取ることを意味します。 "安定した" という語は、内容が固定されているという意味ではありません。 そうではなく、"安定した" は、イメージがそのバージョンの目的を表すように安定している必要があることを意味します。 "安定" を維持するために、そのイメージには、セキュリティ更新プログラムまたはフレームワーク更新プログラムを適用するサービスが提供されている可能性があります。

例

フレームワーク チームはバージョン 1.0 をリリースします。 マイナー更新を含む更新プログラムをリリースすることがわかっています。 特定のメジャーおよびマイナー バージョンで安定したタグをサポートするためには、2 組の安定したタグを使用します。

• :1 - メジャー バージョン用の安定したタグ。 1 は "最新の" または "最後の" 1.* バージョンを表します。
• :1.0 - バージョン 1.0 用の安定したタグを使用すると、開発者は 1.0 の更新にバインドすることができます。1.1 がリリースされても 1.1 にロールフォワードされることはありません。

基本イメージの更新プログラムやフレームワークの任意の種類のサービス リリースが提供されると、安定したタグを持つイメージはそのバージョンの最新の安定したリリースを表す最新ダイジェストに更新されます。

この場合、メジャーおよびマイナー タグはいずれも引き続きサービスの提供を受けます。 基本イメージのシナリオから、これによってイメージ所有者は処理済みのイメージを提供できます。

タグの付いていないマニフェストを削除する

安定したタグが付いているイメージが更新されると、以前タグが付けられたイメージのタグが解除され、孤立したイメージになります。 以前のイメージのマニフェストと一意のレイヤー データは、レジストリに残ります。 レジストリ サイズを維持するには、安定したイメージの更新によって生成された、タグの付いていないマニフェストを定期的に削除します。 たとえば、指定した期間より古い、タグの付いていないマニフェストを自動消去したり、タグの付いていないマニフェストの保持ポリシーを設定したりします。

一意のタグ

推奨事項: 複数のノードでスケーリングできる環境では特に、デプロイに一意のタグを使用します。 コンポーネントのバージョンに一貫性が維持されるように、慎重にデプロイを行いたいと思うことでしょう。 コンテナーが再起動したり、オーケストレーターがより多くのインスタンスにスケールアウトしたりした場合でも、ホストは他のノードと整合しない新しいバージョンを誤ってプルすることがありません。

一意のタグ付けは、単に、レジストリにプッシュされたすべてのイメージが一意のタグを持つということを意味します。 タグは再利用されません。 次のように、一意のタグを生成するために従ういくつかのパターンがあります。

• 日付時刻スタンプ - これはいつイメージがビルドされたかが明確にわかるため、非常に一般的な方法です。 しかし、ビルド システムに関連付ける手立てがありません。 同時に完了したビルドを見分ける方法もありません。 タイム ゾーンの問題もありまあす。 すべてのビルド システムを調整して UTC に合わせる必要があります。

• Git コミット - このアプローチは、基本イメージの更新のサポートを開始するまでは機能します。 基本イメージの更新が始まると、ビルド システムは前回のビルドと同じ Git コミットを開始します。 ただし、基本イメージには新しいコンテンツが含まれています。 一般に、Git コミットでは、"準" 安定したタグが提供されます。

• マニフェスト ダイジェスト - コンテナー レジストリにプッシュされた各コンテナー イメージはマニフェストに関連付けられ、一意の SHA-256 ハッシュ、つまりダイジェストによって識別されます。 一意ではあっても、ダイジェストは長くて読み取りにくく、ビルド環境には関連付けられていません。

• ビルド ID - 増分され、特定のビルドに関連付けてすべての成果物とログを検索することができるため、このオプションが最適である可能性があります。 ただし、マニフェスト ダイジェストと同様に、人が読むのは困難です。

  組織に複数のビルド システムがある場合は、このオプションのバリエーションとして、<build-system>-<build-id> のように、ビルド システムの名前をタグの前に付けます。 たとえば、API チームの Jenkins ビルド システムのビルドと Web チームの Azure Pipelines ビルド システムのビルドを区別できます。

デプロイ済みイメージ タグをロックする

ベスト プラクティスとして、デプロイ済みイメージ タグの write-enabled 属性を false に設定して、そのタグをロックすることをお勧めします。 このプラクティスによりイメージが誤ってレジストリから削除されないようにして、デプロイが中断される可能性を防ぐことができます。 ロック手順はリリース パイプラインに含めることができます。

デプロイ済みイメージをロックしても、デプロイされていない他のイメージについては、レジストリを維持するために、Azure Container Registry 機能を使用して引き続きレジストリから削除できます。 たとえば、指定した期間より古い、タグの付いていないマニフェストやロック解除されたイメージを自動消去したり、タグの付いていないマニフェストの保持ポリシーを設定したりします。

次のステップ

この記事に記載されている概念の詳細については、ブログ記事「Docker のタグ付け: Docker イメージのタグ付けとバージョン管理のベスト プラクティス」を参照してください。

Azure Container Registry のパフォーマンスを最大化し、コスト効率良く使用するには、「Azure Container Registry のベスト プラクティス」を参照してください。