DevOpsのためのNGINX Config：Serverionによるゼロダウンタイムデプロイメントの秘訣
ゼロダウンタイムの展開 サービスを中断することなくアプリケーションを更新することを意味します。これは、短時間の停止でも数百万ドルの損害が発生する可能性がある企業にとって必須の要件です。NGINXは、マスターワーカープロセスモデルと次のようなスマートシグナルによってこれを実現します。 USR2 （新しいプロセスを開始する）そして HUP （設定を再読み込みしてください）。鍵となるのは以下のとおりです。
- 仕組みNGINX は、接続を切断することなく、トラフィックを古いワーカーから更新されたワーカーにシフトします。
- 重要なステップ: 信号を使用する (
USR2,HUPなど）、設定nginx.conf適切に実行し、再ロードする前に変更を検証します。 - テクニック: NGINX をブルーグリーン デプロイメントや Docker などの方法と組み合わせて、シームレスな更新を実現します。
- 健康診断: NGINX のパッシブまたはアクティブ ヘルス チェックを使用して、正常なサーバーのみがトラフィックを処理するようにします。
適切な構成にすることで、更新中もサービスをスムーズに実行し、収益を保護し、顧客の信頼を維持することができます。
ゼロダウンタイムのデプロイメントのためのNGINXの基礎
ゼロダウンタイムデプロイメントの説明
NGINXは、サービスを中断することなくアップデートを処理するために、マスター・ワーカーモデルを採用しています。マスタープロセスは設定と制御を監視し、ワーカープロセスはクライアント接続を管理します。この構成により、アップデート中にトラフィックが古いワーカーから新しいワーカーへとシームレスに移行し、サービスの中断を防ぎます。
NGINX 接続管理
NGINX は、アップグレードや構成の変更中にプロセスを制御するために特定のシグナルに依存します。
- USR2: 新しいマスター プロセスとワーカー プロセスを開始します。
- ウインチ: 古いワーカープロセスを正常に停止します。
- HUP: 構成を再読み込みし、ワーカーを置き換えます。
- やめる: マスターとワーカーを正常にシャットダウンします。
再ロード時に、NGINXは古いマスタープロセスIDを /run/nginx.pid.oldbin、新しいマスタープロセスIDを /run/nginx.pid、古いワーカーがシャットダウンする前にアクティブなリクエストを完了できるようにします。
最新のアプリのデプロイメント: NGINX と JFrog を使用して…
継続的な運用のためのNGINXの設定
リロード中に接続をアクティブに保つには、次の設定で NGINX のマスター ワーカー アーキテクチャを活用します。
主要なNGINX設定手順
オンにする マルチ受け入れ ワーカーがイベントごとに複数の接続を処理できるようにします。設定例を以下に示します。 nginx.conf:
worker_processes auto; pid /run/nginx.pid; events { worker_connections 1024; multi_accept on; } http { アップストリームバックエンド { サーバー backend1.example.com:8080; サーバー backend2.example.com:8080; keepalive 32; } サーバー { listen 80; サーバー名 example.com; 場所 / { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header 接続 ""; proxy_set_header ホスト $host; proxy_set_header X-Real-IP $remote_addr; } } } ダウンタイムなしで構成を再読み込み
- 変更を適用するには、現在のワーカーをリロードします。
nginx -s リロード - 更新されたマスタープロセス ID を確認します。
cat /run/nginx.pid - トラフィックを停止せずにバイナリ アップグレードを実行します。
kill -USR2 $(cat /run/nginx.pid) kill -WINCH $(cat /run/nginx.pid.oldbin)
これらの手順により、古いワーカーと新しいワーカーの間でトラフィックがスムーズに移行し、中断のないサービスが保証されます。
sbb-itb-59e1987
NGINXを使用したデプロイメント方法
NGINX を使用すると、ブルーグリーン セットアップやコンテナベースのアプローチなどの手法を活用して、ゼロダウンタイムのデプロイメントを実現できます。
ブルーグリーンデプロイメントのセットアップ
NGINXを使用すると、一般的に「 青 そして 緑これらの環境は同一ですが、一度にアクティブになるのは1つだけです。仕組みは以下のとおりです。
- 更新されたバージョンを非アクティブな環境 (例: グリーン) にデプロイします。
- 新しいバージョンが適切に機能していることを確認するためにヘルスチェックを実行します。
- 確認後、更新してください NGINXの設定 更新された環境にトラフィックをルーティングします。
- 設定をリロードするには、
HUPアクティブな接続が切断されないように信号を送信します。
この方法により、サービスが中断されることなくスムーズな移行が保証されます。
DockerとNGINXの統合
DockerとNGINXを組み合わせることで、アプリケーション層とプロキシ層の両方で一貫した環境を維持できるため、デプロイメントが効率化されます。ゼロダウンタイムのアップデートを実現する方法は次のとおりです。
- 現在アクティブなコンテナと並行して新しいコンテナを起動します。
- ヘルスチェックを実行して、新しいコンテナの準備ができていることを確認します。
- 新しいコンテナを含めるように NGINX アップストリーム構成を変更します。
- 設定をリロードするには、
HUPシグナルを送信し、古いワーカーが終了前に処理を完了できるようにします。
このアプローチにより、アプリケーションの更新中にサービスが中断されないことが保証されます。
テストと検証
ヘルスチェックを構成する
NGINXのヘルスチェックは、正常に機能するサーバーのみがトラフィックを処理できるようにするのに役立ちます。これらのチェックは、アップストリームの設定とBlue-Greenルーティングと連携して機能します。NGINXは2種類のヘルスチェックを提供しています。 受け身 （NGINXオープンソースで利用可能）および アクティブ (NGINX Plus 限定)。
NGINX Open Source のパッシブ ヘルス チェックの場合、アップストリーム ブロックを次のように設定します。
アップストリームバックエンド { サーバー backend1.serverion.com:8080 max_fails=3 fail_timeout=30s; サーバー backend2.serverion.com:8080 max_fails=3 fail_timeout=30s; ゾーンバックエンド 64k; } NGINX Plusを使用している場合は、 ヘルスチェック 指令と マッチ ブロック：
location / { proxy_pass http://backend; health_check interval=5s fails=3 passing=2 required persistent; match health_check { status 200; header Content-Type = application/json; body ~ '"status":"UP"'; } } NGINX をリロードする前に、これらの構成を必ず検証してください。
構成の検証
再読み込みする前に、必ずNGINXの設定が正しいかテストしてください。以下のコマンドを使用してください。
nginx -t -c /path/to/your/nginx.conf ゼロダウンタイム導入の基本
ゼロダウンタイムのデプロイメントを実現するには、NGINXの綿密な設定と堅牢なインフラストラクチャ計画が不可欠です。これらの要素が連携して、中断なくアップデートが実行されるようにします。
成功するための重要な要素は次のとおりです。
- プロセス制御と構成の検証徹底したテスト プロトコルを遵守しながら、NGINX のアーキテクチャを最大限に活用します。
- インフラの安定性: 展開プロセス全体を通じて一貫したパフォーマンスを維持し、セキュリティを厳重に保ちます。
ヘルスチェックとロールバック手順の詳細については、 テストと検証 セクション。
Serverionのプラットフォームは、信頼性の高い安定性とセキュリティでこれらの取り組みをサポートします。 グローバルデータセンター アップデート中もパフォーマンスを安定させ、組み込みの DDoS 保護によりセキュリティが維持されます。
重要度の低いサービスでは、まずは機能トグルを使って小規模に始めましょう。定期的なテスト、綿密な監視、明確なロールバック計画を戦略の中心に据えながら、徐々にスケールアップを進めていきましょう。
