ゼロ ダウンタイム デプロイ: Blue-Green テクニックを使用して Docker 化されたアプリをアップグレードする

1 か月前に書いた記事で、Python Web アプリケーションを運用環境 (または開発前/ステージング前) に継続的にデプロイする方法について説明しました。

私は最近、マイクロサービスを (Python と FastAPI を使用して) 構築し、2 つの声を照合して、両方が一致するかどうかを予測スコアにする任務を負っていました。利害関係者は、音声ロック解除機能を要求していました。

私たちはエンジニアリング会議を開き、私は立ち上がってタスクを引き受けました (または、私のリードが私のために立ち上がった、笑)。

これまで ML モデルを使った作業 (トレーニングなど) がなかったので、これは興味深い作業でした。コードを設計してビルドし、AWS EC2 インスタンスに出荷するのに 1 週間かかりました。私は CI/CD の大ファンなので、最も使いやすい GitHub Actions を使用しました。

一週間後… 変更依頼が来て、研究していた新しい【展開】手法を試してみたくなりました。再デプロイ時にダウンタイムが発生しないように、AWS EC2 インスタンスで適切に実行されている Docker 化されたマイクロサービス アプリケーションが必要でした。

そして、私は袖に完璧なトリックを持っていました.

そのトリックは青緑テクニックです。

Blue/Green デプロイに関する AWS ホワイトペーパーによると、これは2 つの別個の同一の環境を作成するデプロイ戦略です。

1 つの環境 (青) は現在のアプリケーション バージョンを実行しており、もう 1 つの環境 (緑) は新しいアプリケーション バージョンを実行しています。 Blue/Green デプロイメント戦略を使用すると、デプロイメントが失敗した場合のロールバック プロセスが簡素化されるため、アプリケーションの可用性が向上し、デプロイメントのリスクが軽減されます。

グリーン環境でのテストが完了すると、ライブ アプリケーション トラフィックがグリーン環境に転送され、ブルー環境は廃止されます。

簡単に言えば、ブルー/グリーン デプロイ手法は、2 つの同一の運用環境を実行することで、ダウンタイムとリスクを軽減する方法です。

このような展開手法を初めて耳にする場合でも、恐れる必要はまったくありません。Blue-Green 展開を実現するのに役立つ詳細な手順を提供します。

手順に進みましょう。

1. 更新されたコードで新しい Docker イメージを構築することから始め、新しいバージョン番号でタグ付けします。

   
   

 $ docker build -t myexample:v2 .

これにより、現在のディレクトリのDockerfileを使用して、タグmyexample:v2を持つ新しい Docker イメージが作成されます。

myexample:v2新しくビルドされた Docker イメージの名前です。私の場合、それは ML プロジェクトの名前でした。例: docker build -t companyx-servicename-backend:v2

2. 新しいイメージから新しい Docker コンテナーを開始しますが、まだ外部に公開しないでください。

   
   

 $ docker run -d --name myexample-v2 myexample:v2

これにより、 myexample:v2イメージからmyexample-v2という名前の新しい Docker コンテナーが開始されます。

3. 新しいコンテナが起動して初期化されるのを待ち、正しく機能していることを確認します。

   
   

 $ docker logs myexample-v2

docker logs コマンドを使用して、新しいコンテナーのログをチェックし、コンテナーが適切に開始および初期化されていることを確認します。

4. NGINX などのリバース プロキシを使用して、トラフィックを古いコンテナーと新しいコンテナーの両方にルーティングします。リクエストをリッスンするようにリバース プロキシを構成し、それらを古いコンテナと新しいコンテナの両方に転送します。これにより、トラフィックを新しいコンテナに徐々に移行できます。

2 つのコンテナーをルーティングする NGINX 構成の例を次に示します。

 upstream myexample { server myexample-v1:8000; server myexample-v2:8000 backup; } server { listen 80; server_name myexample.com; location / { proxy_pass http://myexample; } }

この構成では、 myexample-v1とmyexample-v2の 2 つのサーバーを持つ myexample というアップストリーム グループをセットアップします。 backupキーワードは、2 番目のサーバーをバックアップとしてマークするために使用されます。 proxy_passディレクティブは、要求をmyexampleアップストリーム グループに転送するために使用されます。

アプリケーションの名前とポートを反映するように、リバース プロキシ構成を更新してください。

5. リバース プロキシの構成を調整して、トラフィックを古いコンテナーから新しいコンテナーに徐々に移行します。

   
   

トラフィックを新しいコンテナーに移行するには、リバース プロキシ構成を調整して、新しいコンテナーにより多くの重みを与えます。これは、サーバー ディレクティブから backup キーワードを削除することで実行できます。

 upstream myexample { server myexample-v1:8000; server myexample-v2:8000; } server { listen 80; server_name myexample.com; location / { proxy_pass http://myexample; } }

これにより、NGINX はより多くのリクエストをmyexample-v2コンテナーに送信します。アプリケーションを監視し、すべてのトラフィックが新しいコンテナーに流れるようになるまで、必要に応じて構成を調整します。

6. すべてのトラフィックが新しいコンテナーに流れたら、古いコンテナーを安全に停止して削除できます。

   
   

 $ docker stop myexample-v1 $ docker rm myexample-v1

これにより、古いコンテナーが停止して削除され、サーバー上のリソースが解放されます。

結論

私はこの手法に不慣れで、明らかに、それについてあまり知りません。しかし、私はそのトレードオフや、よりうまく機能する他のテクニックについて学び続けるつもりです.私と共有したいトリックが 1 つか 2 つありませんか?

感謝します。させてください（コメント欄に）。

ああ、ああ。私の退屈なニュースレターを購読することを忘れないでください.第 1 四半期以降、多くのことを学んだので、すぐに共有します。チャオ。