[CI/CD] いくつかの一般的なノンストップ公開方法

なぜダウンタイムなしで公開できるのでしょうか?

この記事で言及されているノンストップ リリースとは、外部サービスを停止せずにアプリケーションの更新を完了することを指します。ホット デプロイメントとの違いは、ホット デプロイメントは アプリケーション レベルに焦点を当てており、アプリケーションを再起動しないという前提に基づいているのに対し、ノンストップ リリースは サービスに焦点を当てていることです。 レベル。ムーアの法則が徐々に限界に近づき、マルチコア時代が到来するにつれ、分散アプリケーションが事実上の主流になりました。次の記事では、まず分散アプリケーション環境に適した一般的なノンストップ パブリッシング方法を示し、次にスタンドアロン アプリケーションに適した一般的なノンストップ パブリッシング方法であるマスター/ワーカーを紹介します。

クラスター モード

クラスター環境で実行される分散アプリケーションの場合、通常、アプリケーションの上に負荷分散 (LB) の層があります。リリース プロセス中に、ノードを更新する前に任意のノード (またはノードのグループ) に対応するロードをクローズし、更新後にロードをオープンすると、サービス全体のノンストップ リリースを実現できます。これに基づいて、サービスの安定性を確保するために、スタンバイ マシンのサポートを追加できます。つまり、特定のノードを更新するときに、最初にスタンバイ マシンをマウントし、更新後にスタンバイ マシンを削除してから、スタンバイをアップグレードします。以下の図に示すように、すべてのノードを順番に更新した後のマシン:

完全な設計については、私が書いた別の記事を参照してください。

上記のリリース プロセスは、実際には単純な CD です。 (継続的展開) システム。リファレンス実装として、Jenkins 2.0 Pipeline 機能を使用してリリース プロセス全体を定義し、Nginx Dynamic Upstream プラグインを使用して Nginx を操作し、スクリプトと連携してアプリケーションの開始、停止、検出を完了できます。

マスター/ワーカー モード

スタンドアロン アプリケーションの場合、LB がないため、ノンストップ パブリッシュ機能は通常、アプリケーション コンテナーによって実装されます。最も一般的なのはマスター/ワーカーです。モード。コンテナ内にはマスター プロセスと複数のワーカー プロセスが存在し、マスター プロセスはプログラムのロードとリクエストの分散のみを担当し、フォークされたワーカー プロセスは特定の作業を完了します。コンテナーがアプリケーションを更新するシグナルを受信すると、マスター プロセスは更新されたプログラムを再ロードし、新しいリクエストを処理するために新しいワーカー プロセスをフォークし、現在のリクエストを処理した後、古いワーカー プロセスは自動的に破棄されます。 Ruby の Unicorn と PHP の FPM は両方ともこのメカニズムを使用します。

拡張読書

マスター/ワーカー モデルとは異なり、erlang はノンストップ パブリッシングを実現するために別のユニークな方法を採用しています。

Erlang VM は、モジュールごとにコードのコピーを最大 2 つ保存します。モジュールが初めてロードされるとき、コードは現在のバージョン「current」と古いバージョン「old」です。 「現在の」バージョン。新しいコードがロードされると、コードの「現在の」バージョンは「古い」バージョンになり、新しいコードは「現在の」バージョンになります。 Erlang は 2 つのバージョンの共存方法を使用して、いつでも常に 1 つのバージョンを使用できるようにし、外部サービスが停止しないようにします。

gt;
- erlang ホットアップデート実装メカニズムの分析より引用

概要

LB であってもマスター/ワーカーであっても、基本的な考え方は、公開プロセス中、サービス リクエストは常にシステム内の特定のノードまたはプロセスによって特定のメカニズムを通じて処理され、それによってサービスの可用性が保証されるというものです。