Dockerタグのバージョン管理のベストプラクティスは何ですか？

私は最近、gitコミット時にdockerイメージを構築するためにCIサーバーを接続しました。

ビルドされるコンテナは約8種類あり、それぞれに独自の言語/フレームワークがあります。一部はnodeであり、package.jsonを持っています。その他は、セマンティックバージョン情報を含まないpythonサービスです。

私の質問は、タグを作成する方法ではなく、タグの値を作成することです。

各タグが特定の画像の一意のセマンティックバージョン番号を持っていることを確認するにはどうすればよいですか？ビルドバージョンの追跡/増分の権限を持つのは誰ですか？

私は、あなたの投稿を、公式のforums.docker.comからdmazeが回答した、Coupling Docker レジストリーとソース管理に誘導します。ハッシュとブランチ名またはタグをコミットするだけで十分です。

Dockerfileで、LABELを使用してビルドのソースを記録します。これにはおそらく、分散ソース管理（git、Mercurial）からのコミットハッシュ、ブランチ名（該当する場合）、リリースタグ（存在する場合）、および場合によっては最後のコミットのタイムスタンプなどの詳細が含まれます。docker historyとdocker inspectはこれらを表示できるはずです。

Dockerがイメージをプッシュするとき、コミットハッシュとブランチ名を「バージョン」の部分として使用して、イメージを少なくとも2回プッシュします（quay.io/mycorp/imagename:123abc7、quay.io/mycorp/imagename:dmaze-test ）。リリースタグがすぐに利用できる場合、CIシステムはこれらのタグを含むイメージもプッシュする必要があります。

現在、ブランチ名/コミットハッシュの組み合わせを使用しています。私たちにとってはそれで十分のようです。タイムスタンプは便利ですが、IMOはコミットハッシュが提供しないものを提供しないため、混乱を追加します。

030に同意します。

ビルドバージョンの追跡/増分の権限を持つユーザー

100％は、他のチーム間の適切なコミュニケーションにより、そのようなものを維持するためのCIの責任です。

各タグが特定の画像の一意のセマンティックバージョン番号を持っていることを確認するにはどうすればよいですか？

たとえば、タイムスタンプ、git commitハッシュ、セマンティックバージョンの組み合わせなど、複数の要素で構成されるタグを作成できます。後者は手動で設定する必要がありますが、最初の2つは自動化できます。このようなタグは次のようになります。

20171015141729-58617f500f7efe236c7ba6a1dfdf37a478b4c878-0.1.4

このタグには、ビルドの日付、コミット、セマンティックバージョンが含まれます。Dockerイメージが本番環境で実行され、バグが見つかった場合、製品のバージョン、内部にあるコード、イメージがいつビルドされたか、およびどのような状況であるかがわかります。

ビルドバージョンの追跡/増分の権限を持つのは誰ですか？

私の意見では、これはCIの責任である必要があります。これによりプロセスを自動化でき、タグの作成を自動化できるため、このようなツールはジョブに適したツールです。

JenkinsのようなCI / CDのDevOpsツールの1つを使用していると思いますが、次のアプローチをお勧めします。

ジェンキンスのようなものを使用する場合

• Jenkins環境変数「BUILD_ID」を使用できるようにジョブを構成できます。これにより、トリガーされたときにジョブのビルドIDが取得され、画像にタグが付けられます。このようにして、Dockerイメージをバージョン管理できます。以下の例を確認してください。

例：- sudo docker build -t <image_name>:<BUILD_ID>

したがって、SCMのタグのようなメカニズムがある場合は、ジョブベースのビルドまたはJENKINS HOME_FOLDERのビルドIDのconfig.xmlで、それぞれのビルドIDのタグを確認できます。