1

現在、Jenkins ジョブを構成してサービスをリリースし、他のサービスをテスト、ステージング、および本番環境にデプロイしています。リリース ジョブの一部として、プライベート Docker リポジトリにプッシュされるサービス バイナリ (およびそのすべての依存関係) を含む Docker イメージを作成します (新しいタグは新しいバージョンで作成されます)。これまでのところ、この (または古い) バージョンを Jenkins からさまざまな環境にデプロイしたり、サービスの特定のバージョンをプルしてローカルで実行したりするのは簡単なので、これはうまく機能します。私の質問は、継続的デリバリーに移行した場合、このアプローチがうまく機能するかどうかです。ビルドが成功するたびに、新しい Docker タグを作成してプライベート リポジトリにプッシュし、イメージをテスト環境にデプロイするという考え方です。私の懸念は、これが 1 日に数回行われると、大量の Docker タグ/レイヤーをダウンロードする必要があることです。時間が経つにつれて、イメージを取得するのに時間がかかるのではないかと心配しています (そして、私が気付いていない他の問題があるかもしれません)。

したがって、質問をより明確に言い換えると、次のようになります。

  1. 多くの Docker タグを作成しても問題ないですか、それとも避けるべきものですか?
  2. ベース イメージ (OS など) を用意し、ソース管理システムのタグからサービス バイナリをビルドしてから、展開時にさまざまな環境に転送されるイメージをビルドする方がよいでしょうか?
  3. 他の提案？
4

2 に答える 2

2

Docker Registry v1 (python) は、タグのスケーリングがひどいです。これは、分散ファイルシステム ストレージ バックエンド (GCS や S3 など) を使用している場合に特に問題になります。コンテキストについては、 https://github.com/docker/docker-registry/issues/614を参照してください。

現在、新しいプロトコル (v2) と (golang) レジストリの方が優れているはずです。

要点:

  • v1プロトコル/レジストリ自体を除いて、あなたが説明するアプローチに問題はありません...
  • docker 1.6 (リリース候補が出ています) と v2 golang レジストリ (ここにあります: https://github.com/docker/distribution )に賭ける必要があります。
于 2015-04-06T06:27:19.637 に答える