NGINX Controllerで構成管理をより安全に

Brian Ehlertプロダクト管理担当ディレクター

この1年間、お客さまと対話する中で、NGINX Controllerなどのオーケストレーション製品を検討するきっかけとなる、いくつかの共通した課題が見えてきました。

• 複雑さ – さまざまなソースから取得した個々の構成オブジェクトを大量に管理、保守、検証、適用するのは容易ではありません。
• 脆弱性 – イベントへの対応として、急速なスケールアップが必要になることがよくあります。戦略的に行われる場合もありますが、運用部門ではよくあるように、計画外に自然発生的な形で進むこともあります。
• 安全性 – エラーを回避し、本番環境へのデプロイ前に問題を検出することは、アジャイル手法の基本原則です。また、複雑性と脆弱性の軽減にも役立ちます。

これらは通常、アプリケーションの初回デプロイ時に直面する問題ではありません。むしろ、時間の経過とともにアプリケーションが成功し、スケールアップが必要になったときに表面化します。F5では、スケーリング、より正確には「計画外のスケーリング」が、上記の問題に共通する根本原因であると考えています。

幸い、NGINX Controllerの構成オブジェクトモデルは、これら3つの懸念事項すべてに対応します。

• 特定の導入の複雑さを軽減します。これは、特定のNGINX Plusインスタンス群に影響する可能性があるすべての構成コンポーネントを1か所に集約することで実現します。
• 本番環境に導入する前にチームが構成を検証およびテストできるため、脆弱性が軽減され、早期に問題を検出しやすくなるとともに、本番環境のユーザートラフィックを継続的に処理できます。
• 高い柔軟性により、安全性が向上します。プロセスをモデルに合わせて変更する必要はありません。構成オブジェクトモデルは、ビジネスワークフローと責任分担に適合するよう設計されており、必要に応じて各事業部門に構成要素の適切な所有権を付与できます。

Controllerの構成オブジェクト

Controllerモデルの仕組みをより深く理解するために、主要な構成オブジェクトを詳しく見ていきましょう。

環境

ほとんどの組織では、ソフトウェアはリリース前に、開発、ユーザー受け入れ、プリプロダクション、プロダクション、その他の品質チェックなど、複数の段階を経ます。これらの段階は、NGINX ControllerでEnvironmentと呼ばれるオブジェクトに対応します。

Environmentは、Controller内の構成要素を分離するための領域です。通常、ロールベースのアクセス制御（RBAC）はこのレベルで定義されます。Environmentを使用すると、対象サーバー、データセンターなど、Environment間で異なることの多いインフラストラクチャオブジェクトに最小限の変更を加えるだけで、同一の構成アーティファクトを各ステージに引き継ぐことができます。

ゲートウェイ

GatewayはEnvironment内の構成オブジェクトです。多くの場合、アプリケーションをお客さまに配信する方法（ホスト名、プロトコル、TLS/SSLの動作などの設定）を定義する最上位レベルとして使用されますが、これらの設定は下位レベルでも行えます。実際には、エッジネットワークアプライアンスやDMZを管理するネットワーク運用（NetOps）チームがGatewayオブジェクトを所有するのが一般的です。また、Gatewayでは「Placement」という概念も使用します。これは、構成を受信して実際の処理を行うNGINX PlusインスタンスとControllerを関連付ける仕組みです。

アプリ

その下のレベルにあるのがApp構成オブジェクトです。ここで、アプリケーションのモデル化とトラフィックシェーピング動作のグループ化を開始します。組織のニーズに応じて、必要な数のAppを使用できます。唯一の要件は、Environment内で各Appが一意であることです。

コンポーネント

App内では、ComponentsによってAppに必要なトラフィックシェーピングの動作を記述します。最も単純なケースでは、特定のパス名に対するすべてのトラフィックが同じサーバーグループに送信されます。また、Componentsでは、ヘッダー操作、URL書き換え、バックエンドの負荷分散動作、Cookie処理などの設定を含む、より高度なシェーピングも制御します。ホスト名とTLS/SSLの動作もこのレベルで定義できます。

全体の連携

構成オブジェクト間の関係を図で示します。

Controllerとやり取りするグループは2つだけです。この例では、2つの開発チーム、ReferralとTransfersです。実際には、アプリケーションデリバリとセキュリティに関わる人数はさらに多く、ネットワークおよびセキュリティ（Platform Ops）、DevOps、アプリケーション開発など、幅広い分野に及ぶと考えられます。最も豊富な知識を持つチームは、ベストプラクティスに沿ったポリシーを設定し、セルフサービスワークフローを構築できます。これにより、組織の東西のデータセンター拠点にまたがる「Dev」環境内でApps、Components、Gatewaysを扱うチームにガードレールを提供できます。

これを少し異なる角度から、事業部門（LOB）の視点で見てみましょう。モダンアプリに関する意思決定を事業部門の責任者が担うケースが増えています。

次の図は、さまざまなLOBチームに加え、すべての証明書更新を管理する担当者であるShawnを含む、より大規模なユーザー層を想定した、実態に即したシナリオを示しています。

現在では、より多くの個別の関係者やパイプラインが、結果として生じるデータフローに影響を及ぼしています。

個々のパイプラインが、ソース管理（GitHubなど）からControllerに至るまでのさまざまなオブジェクト変更を処理する過程で、構成オブジェクトはController側で検証され、関連するオブジェクトと結合された後、変更がNGINX Plusインスタンスにプッシュされます。

Controllerは、最新の変更が以前の設定や、他のアプリケーションおよびLOBの所有者による設定と互換性があることを確認することで、構成管理の安全性向上に役立ちます。

実際には、単一のNGINX Plusインスタンスに適用するすべての構成が実現可能である必要があります。ただし、設定同士が競合、重複、衝突してはなりません。また、競合を事前に検出し、各コンポーネントの構成を提供する担当者に通知することが重要です。

上記の例では、Referralコンポーネントが、Transfersコンポーネントですでに実装されているものと同じ正規表現パターンを使用しようとすると、パスの競合が直ちに検出されます。そのため、Referralチームには、この構成を本番環境にデプロイするよりもかなり前に通知でき、構成ミスに伴うさまざまな問題を回避できます。

証明書については、ControllerのRBAC機能により、Shawnは証明書の変更を直ちに適用できます。GatewayとComponentsの保守担当者は、適切な証明書を参照するだけで済み、Shawnは各証明書のライフサイクルを確実に管理できます。ShawnがControllerで証明書を更新すると、該当するインスタンスにその更新が反映されるため、証明書の有効期限切れに慌てる必要がありません。

NGINX Controllerにすべての構成オブジェクトが揃い、1つ以上のNGINX PlusインスタンスとのPlacementの関連付けが完了したため、最後のステップである構成の適用を実行できます。

実践における安全性

最終的に、Controllerによる構成管理の目標は、適切な場所にある適切なNGINX Plusインスタンスに正しい構成を適用することです。Apps、Components、Gateways、および関連するすべての証明書とインスタンスを正しく構成することで、より安全で拡張性の高いデプロイが可能になります。

この最終検証は、Controllerによって簡素化され、安全性が向上した構成管理プロセスの最後のステップです。プロキシとして導入されたNGINX PlusのWebワークロードグループにおけるセッション永続化など、関連オブジェクトに変更があったNGINX Plusインスタンスに構成全体を適用する際、そのインスタンスが目的の構成に対応しているかどうかを検証します。この条件を満たしている場合、構成が適用されます。さらに安全性を確保するため、構成の適用中に何らかの問題が発生した場合は、Controllerが以前の構成に戻します。

構成が要件を満たしていることを確認するだけでなく、Controllerは、新しい構成の適用時にセッションドレイニングなどのNGINXの高度な機能も活用できるため、変更中もサイトの可用性とパフォーマンスが維持されます。

運用チームにとって、前述の概念とワークフロー設計は、NGINX Controllerが構成管理にもたらす安全性の向上に寄与します。こうした保護策は、ビジネスニーズへの対応を支援するとともに、ワークフローとモダンアプリに携わるさまざまなチームの連携を促進します。

NGINX Controllerをお試しいただくには、今すぐ30日間の無料トライアルを開始するか、ユースケースについてお問い合わせください。

著者について

Brian Ehlertプロダクト管理担当ディレクター

Brian Ehlertのその他のブログ記事