2016-03-26 7 views
2

は、私は次のシナリオを持っている:docker pushとdocker pullで並行性を管理するにはどうすればいいですか?

  • プライベートレジストリからdocker pull画像の最後のバージョンを実行しているdaemon_pulling。
    • など。 docker pull localhost:5000/myimage:v1#1、SHAまたはイメージID:1234
  • daemon_pushingが画像の最後のバージョンのdocker push実行します。
    • など。 docker commit container_stable localhost:5000/myimage:v1 && docker push localhost:5000/myimage:v1#舎や画像ID:6789

コードは、コンテナに基づいてイメージを展開するために正常に動作します!

dameon_pushing(SHAまたは画像ID:6789)のときに問題がある:ときドッカープルプッシュ(6789)が終了していないので、同時に実行しdaemon_pulling(1234 SHAまたは画像ID)を実行しています(1234)が使用され、ローカルの変更(6789!= 1234)を検出し、イメージ(1234)を再度ダウンロードしようとしましたが、最後の安定したイメージが押しています(6789)...

進行中のプルには影響を与えずにプッシュし、逆も同様である。

この並行性を管理するより良い方法はありますか?

ピボットとして別のDockerイメージ名を使用してレジストリサーバー上で直接名前を変更しようとしましたが、リモートで名前を変更する方法が見つかりませんでした。

+0

このセットアップ/ワークフローで解決しようとしている問題は何ですか? – jonatan

+0

@jonatan私たちは、ブランチ・ステイブルとプル・リクエストのブランチの変化を検出するCIを持っています。プル・リクエストのビルドでは 'docker pull stable'が使用され、安定ブランチでは' docker push'が使用されます。 – moylop260

答えて

1

CIビルドをセットアップして既存のイメージをプルし、そこからコンテナを実行してアップデートをインストールし、変更を同じイメージ名にコミットしてからレジストリに戻しているようです。コンテナを実行し、同じイメージにコミットすることによってイメージを継続的に更新することは、変更を隠してビルドを複製することを不必要に困難にするので、良い方法ではありません。

より良い方法は、すべてのビルドステップを定義するDockerfileからイメージを構築することです。例については、Dockerの公式Continuous Integration use caseのリファレンスアーキテクチャを参照してください。ビルド時間を短縮したい場合は、自分でbase imageを開始することができます。

+0

私のCIは、安定したブランチ 'production/8.0'が更新され、新しい' docker build'が実行されると、 'git clone production/8.0'のgitリポジトリと一緒にDockerfileを使用します。しかし、プルリクエストでは、最後のバージョン 'docker pull'を使用してください(PRは' docker push'を実行しません)が、問題はCIが 'docker push'を実行し、PRに' docker pull'が来るときです。私はリンクを見直します。ありがとうございました! – moylop260

関連する問題