docker-compose.yml
必要なすべてのコンテナをリストしたファイルを使用して、開発環境で docker-compose を使用しています。
また、集中型の Git リポジトリ、Jenkins サーバー、ステージングと本番の両方を保存する別のサーバーもあります。
したがって、問題は、展開プロセスをどのようにより適切に整理するかということです。
これで、git push
git サーバー側で Jenkins ビルド ジョブがトリガーされます。ブランチ名 (ステージングまたは本番) に応じて、異なるジョブがトリガーされます。
ビルド ジョブは、環境全体を起動してテストを実行するために docker-compose を使用します。では、新しいコンテナーをステージング/本番環境にプッシュするにはどうすればよいでしょうか?
1 つの方法は、それらをプライベートまたはパブリックの Docker レジストリにプッシュすることですが、運用環境でコンテナーを更新するベスト プラクティスは何でしょうか? Jenkins サーバーは、ssh を実行して、生のkill
、rm
、コマンドを実行するだけpull
でよいのでしょうかrun
? 例が見当たりません。
答え1
Kubernetes、Docker Swarm、または Rancher は、ローリング アップデートと呼ばれるものを実装する最適な方法でしょう。
基本的に、ローリング アップデートはコンテナーのコレクション (サービスと呼ばれます) を取得し、それらを 1 つずつ更新します。つまり、3 つのコンテナーでアプリを実行しているとします。ローリング アップデートでは、最初のコンテナーを停止して更新し、サービスが完全に更新されるまでこれを繰り返します。つまり、これらの製品のロード バランサーはインテリジェントであり、コンテナーの更新にリダイレクトしないため、アプリのダウンタイムは実質的にゼロになります。
このリンクでは、サービスを実行して更新する Swarm の基本的な実装が提供されます。
最も簡単なセットアップと実装としては、私の経験では、Rancher がこれらすべての概念を理解するための良い出発点です。基本的には、Kubernetes などのさまざまな Docker テクノロジーの上にあるインターフェイスです。