NGINX コントローラーによるより安全な構成管理

過去 1 年間にお客様と話をする中で、 NGINX Controllerなどのオーケストレーション製品を評価する動機となるいくつかの共通のテーマに気づきました。

• 複雑さ- さまざまなソースからの個別の構成オブジェクトの大規模なセットを管理、維持、検証、および適用することは簡単ではありません。
• 脆弱性– スケールアップは、多くの場合、イベントへの対応として、急速に行われることがあります。 時には戦略的なこともありますが、あらゆる運用部門でよくあることですが、計画外かつ有機的なものです。
• 安全性- エラーを回避し、本番環境に展開する前に問題を検出することは、アジャイル手法の基礎です。 また、複雑さと脆弱性を軽減するのにも役立ちます。

これらは、顧客がアプリケーションを初めて導入するときに一般的に直面する懸念事項ではありません。 むしろ、時間の経過とともにアプリケーションが成功し、スケールアップが必要になるにつれて、問題が発生します。 スケーリング、より正確には計画外のスケーリングが、上記に挙げた懸念の共通の根本原因であることがわかりました。

幸いなことに、NGINX コントローラー構成オブジェクト モデルは、次の 3 つの懸念事項すべてに対処します。

• 特定のNGINX Plusインスタンス セットに影響を与える可能性のあるすべての構成コンポーネントを 1 か所に集めることで、展開の複雑さを軽減します。
• チームが構成を本番環境に配置する前に検証およびテストできるようにすることで脆弱性が軽減され、フェイルファストが容易になり、本番環境のユーザー トラフィックが途切れることなく流れるようになります。
• 柔軟性が高いため安全性が向上します。 構成オブジェクト モデルは、モデルに合わせてプロセスを調整する必要はなく、ビジネス ワークフローと責任の分担に合わせて設計されているため、必要に応じてさまざまなビジネス ユニットに構成要素に対する適切な所有権を付与できます。

コントローラ構成オブジェクト

コントローラー モデルがどのように機能するかをよりよく理解するために、いくつかの重要な構成オブジェクトについてもう少し詳しく見てみましょう。

環境

ほとんどの組織では、ソフトウェアはリリース前に開発、ユーザー承認、試作、生産、その他の品質チェックの段階など、複数の段階を経ます。 これらのステージは、Environment と呼ばれる NGINX コントローラー オブジェクトに対応します。

環境は、コントローラー内の構成要素の分離ゾーンです。 これは通常、ロールベースのアクセス制御 (RBAC) が定義されるレベルです。 環境は、ターゲット サーバー、データ センター、および環境間で一般的に異なるその他のインフラストラクチャ オブジェクトなどの変更を最小限に抑えながら、さまざまなステージを通じて同一の構成成果物を保持できます。

ゲートウェイ

ゲートウェイは、環境内の構成オブジェクトであり、アプリケーションを顧客に配信する方法を定義するための最上位レベルとしてよく使用されます。ホスト名、プロトコル、TLS/SSL の動作などの設定ですが、このような設定は下位レベルでも行うことができます。 実際には、エッジ ネットワーク アプライアンスまたは DMZ を管理するネットワーク運用 (NetOps) チームが、ゲートウェイ オブジェクトを所有することが最も一般的です。 ゲートウェイでは、「配置」の概念も採用されています。これは、構成を受け取って実際の作業を行う NGINX Plus インスタンスとコントローラーをリンクする方法です。

アプリ

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

コンポーネント

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

まとめ

構成オブジェクト間の関係を視覚的に表したものを次に示します。

コントローラーとやり取りするグループは 2 つだけであることに注意してください。この場合は、 ReferralとTransfers という2 つの開発チームです。 実際には、アプリケーションの配信とセキュリティに関わる人の数は、ネットワークとセキュリティ (プラットフォーム オペレーション)、DevOps、アプリ開発など、はるかに多いことが分かっています。 最も知識のあるチームは、ポリシーを設定し、ベストプラクティスに沿ったセルフサービス ワークフローを構築し、組織の東部と西部のデータセンターの場所にまたがる「開発」環境内でアプリ、コンポーネント、ゲートウェイを操作するチームにガードレールを提供できます。

これを少し違った視点、つまり基幹業務 (LOB) の観点から見てみましょう。 LOB 所有者は、最新のアプリの適用に関する決定を下すことが増えています。

次の図は、さまざまな LOB チームと、すべての証明書の更新を管理する Shawn を含む、はるかに大規模なユーザー プールを含む、より現実的なシナリオを示しています。

現在、結果のデータ フローに影響を与える個別のアクターとパイプラインが増えています。

個々のパイプラインがソース管理 (GitHub など) からコントローラーへのさまざまなオブジェクトの変更を通過すると、構成オブジェクトはコントローラー側で検証され、変更が NGINX Plus インスタンスにプッシュされる前に関連オブジェクトと結合されます。

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

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

上記の例では、紹介コンポーネントが転送コンポーネントがすでに実装しているのと同じ正規表現パターンを使用しようとすると、パスの競合がすぐに検出され、紹介チームがこの構成を本番環境に展開しようとするずっと前に通知を受けることができるため、誤った構成に関連する多くの問題を回避できます。

証明書に関しては、Shawn はコントローラの RBAC 機能を介して証明書の変更を即座に実装できるようになります。 ゲートウェイとコンポーネントのメンテナーは正しい証明書を参照するだけでよく、Shawn はそれらを独自のライフサイクルで自信を持って管理できます。 Shawn が Controller で証明書を更新すると、証明書の有効期限切れに伴うパニックが発生することなく、証明書が適切なインスタンスにプッシュされます。

NGINX コントローラーはすべての設定オブジェクトと、1 つ以上の NGINX Plus インスタンスへの配置の関連付けを取得しました。これで、最後の手順である設定の適用を実行できます。

実践における安全性

最終的に、Controller を使用した構成管理の目標は、正しい場所にある正しい NGINX Plus インスタンスに正しい構成を適用することです。つまり、アプリ、コンポーネント、ゲートウェイ、および関連するすべての証明書とインスタンスが正しく構成されていることを確認することで、より安全でスケーラブルなデプロイメントが実現します。

この最終検証は、Controller によってより簡単かつ安全に実行される構成管理プロセスの最後の部分です。 プロキシとしてデプロイされた NGINX Plus の Web ワークロード グループでのセッション永続性など、関連するオブジェクトの変更があった NGINX Plus インスタンスに適用されると、構成全体が検証され、インスタンスが目的の構成と互換性があることが確認されます。 その条件が満たされると、構成が適用されます。 最後の安全策として、構成の適用中に何かが失敗した場合、コントローラーは以前の構成に戻ります。

コントローラーは、構成が合格することを保証するだけでなく、新しい構成が適用されたときにセッション ドレインなどの高度な NGINX 機能も活用できるため、変更を通じてサイトの可用性とパフォーマンスが維持されることが保証されます。

運用チームにとって、上記で概説した概念とワークフロー設計は、NGINX コントローラーが構成管理に関して提供する安全性に貢献します。 これらの安全対策は、ビジネスのニーズをサポートしながら、ワークフローと最新のアプリで作業するさまざまなチームを調整するのに役に立ちます。

NGINX Controller を試すには、今すぐ30 日間の無料トライアルを開始するか、お問い合わせの上、使用事例についてご相談ください。