F5 アプリケーション サービスの自動化: 実践ガイド

アプリケーション配信デバイスとセキュリティ デバイスの展開と構成管理を自動化することは、ほぼ必須のプラクティスになっています。 2017 年の IDG FutureScapeレポートでは、自動化とマルチクラウド管理が、2021 年までにビジネスに影響を与える主要な取り組みの一部としてランク付けされています。1 自動化により、アプリケーションに必要な重要なセキュリティ、最適化、可用性サービスの展開に拡張性、信頼性、統合性がもたらされ、それらの配信が、アプリケーション展開の主要モデルとして台頭しているオーケストレーションされたビルド、テスト、展開ワークフローの一部になります。

新しい仮想サーバーやプール メンバーの追加などの基本的なタスクを単純に自動化するだけでも、運用部門はアプリケーション所有者やその他の自動化システムにセルフサービス機能を提供できるようになり、次世代の自動化ツールの構築など、より生産性の高い作業に時間を割くことができます。

組織が IT サービスを提供するために複数のクラウド プラットフォームを導入し始めると、自動化の必要性がさらに重要になります。 プラットフォーム特性が異なる複数の場所にサービスを展開する場合、自動化により、運用オーバーヘッドの増加の影響を軽減し、新しいプラットフォームに不慣れなために発生するエラーを減らすことができます。

しかし、何をどのように自動化すればよいのでしょうか? さまざまな操作モデル、インターフェース、言語により、自動化ソフトウェアは単一のデバイス レイヤーで動作することも、より複雑なマルチシステム ツールとして動作することもできます。 Infrastructure-as-a-Service (IaaS) クラウド プラットフォームは、仮想インフラストラクチャとサービスを展開するための独自のネイティブ ツールを提供します。 さらに、F5 はさまざまなインターフェースとオーケストレーション オプションを提供します。 幅広いツールとオプションにより、組織に最適な方法で自動化する機会が得られますが、適切なツールを選択するのは困難な作業になる可能性があり、複雑さとツールの急増のリスクは現実的です。

このホワイト ペーパーでは、F5 BIG-IP アプライアンス (物理と仮想の両方) の導入、管理、構成を自動化する方法の概要と、ビジネスに適した方法を選択する方法に関するアドバイスを紹介します。

アプリケーション サービスの提供ライフサイクルには、重要な自動化ポイントがいくつかあります。 インフラストラクチャ モデルとアプリケーションの展開方法に応じて、すべてを開発する必要がある場合もあれば、一部のみを開発する必要がある場合もあります。

大容量のマルチテナント物理または仮想 BIG-IP にサービスを展開する場合、サポートされる数百または数千のアプリケーションのアプリケーション サービス構成の展開、監視、更新と比較すると、ブートストラップとオンボーディングのアクティビティは優先度が高くありません。

すべてのアプリケーションが複数の環境に専用の BIG-IP インスタンス（テストや QA 用にオンデマンドで作成される一時的なインスタンスを含む）を持つ展開モデルを検討している場合、ブートストラップとオンボーディングのプロセスを自動化することは、アプリケーション サービス自体を展開することと同じくらい重要なパスの一部となります。 

環境や自動化が必要なプロセスの数に関係なく、考慮する必要がある重要なトピックがいくつかあります。

自動化はさまざまなアクティビティをカバーします。 スペクトルの一方の端には、Bash、TMSH、Python、またはその他の言語で記述された単純なスクリプトの開発があり、これをローカルで実行して、手動構成アクティビティを高速化できます。 スペクトルのもう一方の端には、ソース コード管理、ワークフロー オーケストレーター、および (潜在的に) 複数の自動化ツールを組み合わせて、インフラストラクチャの構成がリポジトリ内に含まれるテキスト ファイルによって定義され、変更されるシステムを作成する完全な「コードとしてのインフラストラクチャ」システムがあります。 これら 2 つの極端な例の間には、BIG-IP プラットフォームの展開と構成の管理に役立つさまざまなオプションが存在します。

現在の BIG-IP の展開のほとんどは変更可能であると考えられます。つまり、時間の経過とともに構成が変化することが予想されます。 これは、BIG-IP プラットフォームが主に複数のアプリケーションにサービスを提供するマルチテナント デバイスとして導入されるためです。 新しいアプリケーションが導入されたり、既存のアプリケーションが拡張されたり、追加のサービスが必要になったりすると、BIG-IP の構成がそれに応じて更新されます。 この展開方法により、インフラストラクチャ チームは、共通プラットフォームからアプリケーションにサービスを提供する集中型インフラストラクチャのセットを管理できます。

ただし、BIG-IP プラットフォームが個別のアプリケーション スタックの一部として導入され、特定の BIG-IP のサービスが特定のアプリケーションまたはサービスに関連付けられる場合もあります。 この状況では、BIG-IP 構成を不変として扱うことができます。つまり、構成は起動時にインストールされるか、ソフトウェア イメージの一部としてインストールされ、BIG-IP インスタンスのライフサイクル中に変更されません。 構成の変更は、ソフトウェア イメージまたは起動エージェント スクリプトの内容を変更し、再展開することによって実行されます。 このモデルは「Nuke and Pave」と呼ばれることがよくあります。 全体的にはあまり一般的ではありませんが、アプリごとのインスタンスをサポートする新しい BIG-IP ライセンス モデル、強化されたライセンス ツール、 F5 クラウド ライブラリ(クラウドでの BIG-IP のオンボードを支援するために設計された Node.js スクリプトとライブラリのセット) などのツールが利用できるようになったことで、コードとインフラストラクチャの両方が緊密に結合されて分離されたスタックをアプリケーションに必要とする組織にとって、この展開モデルは実行可能なオプションになっています。

自動化インターフェースが消費者に公開される方法については、2 つの概念モデルがあります。 最も一般的な「第 1 波」の自動化スキーマは、命令型モデルになる傾向があります。 命令型自動化モデルでは、自動化の消費者は通常、達成したい目標と、それを達成するための明示的な手順 (通常は API 呼び出しによる) の両方を知る必要があります。 これにより、高度なサービスの構成の詳細を理解する負担、およびサービスを自動化ツールと統合するための追加の複雑さと労力が消費者にかかることになります。 これは、サンドイッチを作る人がサンドイッチを作るのに必要な操作（および操作の順序）を知っているだろうと期待してサンドイッチを頼むのではなく、サンドイッチを作るのに必要なすべての操作を指定してサンドイッチを頼むのと似ています。

対照的に、宣言型インターフェースでは、消費者 (人間または機械) が必要なものを要求することでサービスを作成できます。 自動化ターゲットには、必要な結果に基づいて構成を作成するための事前構成されたワークフローまたはサービス テンプレートがあるため、必要なすべての手順に関する詳細な知識は必要ありません。 宣言型インターフェースでは初期設定が少し複雑になりますが、適切なサービス テンプレートが構築されると、その複雑さは操作の単純さによって相殺されます。 そのため、一般的には、自動化システムを構築するための好ましいメカニズムとなります。

検討する必要があるもう 1 つの決定は、自動化 API 呼び出しをサードパーティ ツールから変更が必要なデバイスに直接行うか、追加の管理ツールを介して行うかということです。 管理ツールは操作を抽象化して簡素化することができ、管理対象エンティティへの直接接続とは対照的に、追加の制御レイヤーとログ記録レイヤーを提供する場合があります。 ただし、迅速に変更を加える能力が重要な状況では、管理レイヤーの可用性が高くなるようにする必要があります。

BIG-IP デバイスは、REST API を介して自動化されるのが最も一般的です。REST API は、文書化されたスキーマを介して BIG-IP 機能の大部分を公開します。 Ansible などの自動化ツール用の F5 提供モジュールは、REST API を広範に活用します。iControl LX機能の追加により、単一の API 呼び出しから複数のステップの操作を実行できるユーザー定義の API エンドポイントを作成することもできます。

BIG-IP 構成を自動化するもう 1 つの一般的な方法は、起動時に実行され、外部情報を取得して BIG-IP プラットフォームを構成できる起動エージェントを使用することです。 スタートアップ エージェントは、デバイスを「オンボード」するための初期構成を実行するためによく使用され、GitHub などのサードパーティ サイトや独自のリポジトリから追加のスクリプトや構成ファイルを取得できます。 スタートアップ エージェントは、特にアプリケーションごとに固定された構成を選択した場合に、BIG-IP プラットフォームを完全に構成するためにも使用できます。

最も一般的な起動構成はcloud-initです。これはすべての BIG-IP VE イメージ (Microsoft Azure を除く) で有効になっていますが、AWS および OpenStack デプロイメントでの使用に最も適しています。 F5 は、cloud-init に加えて、起動時に BIG-IP を構成するのに役立つ一連のクラウド スタートアップ ライブラリも提供しています。

起動後にプラットフォームを構成するために起動エージェントを使用する場合は、障害の管理に細心の注意を払ってください。 これは、外部ソースが使用される場合、特にスケーリング イベントの一部としてインスタンスが起動される可能性がある場合に特に重要です。 外部リソースが利用できない場合、システムはどのように動作しますか? 需要に応えるために追加の「ゾンビ」デバイスが作成されるのでしょうか?

場合によっては、自動化システムはユーザーとして動作し、CLI コマンドを実行できます。 この方法は、API 呼び出しが完了していない可能性があるいくつかの問題を解決できる場合もありますが、一般的にはサポートの難しさやソリューションの脆弱性により、最後の手段となる方法となります。

テンプレートとプレイブックを使用すると、自動化されたデプロイメントを作成し、ある程度標準化されたインフラストラクチャを構築できます。 適切なレベルの標準化により、インフラストラクチャの堅牢性とサポート性が向上します。 適切に作成されたテンプレートは宣言型インターフェースを提供します。これにより、要求元のエンティティ (ユーザーまたはマシン) は、実装の詳細ではなく、必要なプロパティのみを知る必要があります。 テンプレートを使用して厳密にデプロイし、テンプレートを修正するだけで修復すると、通常、問題を一度だけ修正するだけで済むため、より高品質なサービスを実現できます。 サービスは新しいテンプレートから再デプロイされ、テンプレートの更新によって同じ問題が再び発生するのを防ぎます。

プラットフォーム統合ツールは、BIG-IP サービスの構成をプライベート クラウドやコンテナ管理システムなどのプラットフォームに結び付けます。 メカニズムはプラットフォームや実装によって異なりますが、一般的には次の 3 つのモデルに分類されます。

• F5 サービスを既存のプラットフォーム構造に置き換える
  このモデルでは、F5 をOpenShift Container Platform ルーターとして使用したり、F5 をOpenStack Load Balancing as a Service (LBaaS)システムと共に使用したりするなど、既存のプラットフォーム構造を使用して F5 サービスが挿入されます。 これらのメカニズムを使用する場合、プラットフォームネイティブ インターフェイスを使用してサービスが構成され、提供されたドライバーやその他のソフトウェアによってプラットフォーム構成ディレクティブが F5 構成にシームレスに変換されるため、運用手順をほとんど変更する必要はありません。 ただし、プラットフォームネイティブ インターフェイスを通じて利用できる機能のみを簡単に展開できることに注意してください。
• プラットフォームイベントへの登録
  もう 1 つの一般的な統合方法は、ソフトウェア モジュール ( Kubernetes や Mesos の Container Connectorなど) がプラットフォーム内のイベントをサブスクライブし、イベントに基づいて構成を変更することです。 サービスが必要なアプリケーションにタグまたはラベルを付け、必要なタグが付いたイベントを監視するようにコネクタ ソフトウェアを構成することで、展開するイベントとサービスを選択できます。
• プラットフォーム管理ツールとの統合
  多くのプライベート クラウド プラットフォームには、自動化用に設計された管理システムがあります。 たとえば、VMware には、BIG-IP 構成用のサードパーティ プラグインがある vRealize Orchestrator (vRO) など、いくつかの管理および統合ツールがあります。 その他の例としては、 OpenStack HEATテンプレート システム用のプラグインがあります。

完全な自動化ソリューションではありませんが、サービス検出は、BIG-IP 構成を環境の変化と統合するシンプルで強力な方法です。 サービス検出は、API を介してクラウド システムを定期的にポーリングしてリソースのリストを取得し、それに応じて BIG-IP 構成を変更することで機能します。 これは、バックエンドのコンピューティング リソースをスケーリングするには、ロード バランサーが新しいリソースを認識する必要があるため、リソースが自動スケール グループに構成されている環境で特に役立ちます。 サービス検出コンポーネントは、 AWSおよびAzure向けの F5 クラウド自動スケール ソリューションに付属しています。

それで、F5 が推奨する自動化スキームはあるのでしょうか? はい、そしていいえ。考慮すべき変数が多すぎるため、完全に規範的なアドバイスは役に立ちません。 ただし、当社では、お客様に必要と思われる主要な構成要素を調整された製品ファミリーにまとめました。  

F5 Automation Toolchain 製品ファミリは、F5 BIG-IP プラットフォームを CI/CD ツールチェーンなどの一般的な自動化パターンに統合できるようにする基本的な自動化およびオーケストレーションのビルディング ブロックで構成されています。  

F5自動化ツールチェーンには、次の主要コンポーネントが含まれています。

• アプリケーション サービス 3 拡張 (AS3) – 宣言型 L4-L7 BIG-IP アプリケーション サービス
• 宣言型オンボーディング拡張 (DO) – 宣言型 L1-L3 BIG-IP オンボーディング
• テレメトリ ストリーミング拡張 (TS) – 分析システムへの BIG-IP テレメトリ ストリーミングの自動化
• API サービス ゲートウェイ (ASG) – カスタム iControl LX 拡張機能のコンテナ ランタイム

Automation Toolchain ファミリは、プラットフォームの展開 (クラウド テンプレート経由) からオンボーディング、サービス構成、高度なテレメトリとログ記録によるアプリケーション パフォーマンスの保証まで、アプリケーション サービスの配信ライフサイクルを管理するように設計されています。

サポートされるツール ファミリの拡大は、F5 アプリケーション サービスの自動化の将来の方向性を表していますが、これは他の統合が存在しない、またはサポートされていないことを意味するものではありません。このドキュメントの「その他の自動化ツール」セクションを参照してください。

F5 Applications Services 3 Extension (AS3) は、宣言型 REST API を介して BIG-IP プラットフォーム上のレイヤー 4 ～ 7 アプリケーション サービスの展開を自動化するシンプルで一貫した方法を提供します。AS3 は、JSON ドキュメントとして表される明確に定義されたオブジェクト モデルを使用します。  宣言型インターフェイスにより、F5 アプリケーション サービスの展開の管理が簡単かつ信頼性が高まります。

図: AS3アーキテクチャ

AS3 拡張機能は宣言を取り込んで分析し、適切な iControl API 呼び出しを行って、ターゲット BIG-IP 上で目的の最終状態を作成します。 拡張機能は、BIG-IP インスタンス上または AS3 コンテナ経由で実行できます。AS3 コンテナは、AS3 拡張機能を実行し、BIG-IP への外部 API 呼び出しを行う別のコンテナ/VM です。 

AS3 呼び出しは、 BIG -IP プラットフォームのライセンス、管理、視覚化、アクセス制御を提供し、強力な分析機能と組み合わされたオンデマンドの BIG-IP のアプリケーションごとのインスタンスを提供するF5 Cloud Editionを強化する BIG-IQ 経由でも行うことができます。

Declarative Onboarding 拡張機能は、 F5 BIG-IP プラットフォームを初期起動直後からアプリケーションのセキュリティとトラフィック管理を展開できる状態にするためのシンプルなインターフェイスを提供します。  これには、ライセンスやプロビジョニングなどのシステム設定、VLAN やセルフ IP などのネットワーク設定、複数の BIG-IP システムを使用している場合はクラスタリング設定が含まれます。

オンボーディング プロセスが完了すると、選択した自動化 (または手動) プロセスを使用してアプリケーション サービスを展開できます。

宣言型オンボーディングは、AS3 スキーマと一致する JSON スキーマを使用し、同様のアーキテクチャを備えています。  宣言型オンボーディングは、オンボーディング フェーズの最初のステップで新しく起動した BIG-IP にインストールされる TMOS に依存しない RPM として提供されます。

BIG-IP は、アプリケーション、セキュリティ、ネットワーク テレメトリの強力なジェネレーターです。  Telemetry Streaming 拡張機能は、次のようなサードパーティのコンシューマーへの統計情報とイベントのストリーミングを構成するための宣言型インターフェイスを提供します。

• スプランク
• Azure ログ分析
• AWS クラウドウォッチ
• AWS の
• 黒鉛

Automation Toolchain ファミリーの他のメンバーと同様に、構成は、シンプルで一貫性のある JSON スキーマを使用した宣言型インターフェースを通じて管理されます。

API サービス ゲートウェイは、カスタム iControl LX 拡張機能を TMOS に依存しないプラットフォームで実行できるようにする Docker コンテナ イメージです。  これにより、個々の BIG-IP プラットフォームから管理操作を抽象化することで、F5 の導入を拡張および管理できるようになります。

クラウド テンプレートは、パブリック クラウドとプライベート クラウドのデプロイメント自動化機能を使用して、BIG-IP 仮想アプライアンスをプロビジョニングおよび起動します。

F5 は現在、次のクラウドのテンプレートをサポートしています。

• AWS –クラウド フォーメーション テンプレート
• Azure – Azure リソース マネージャー テンプレート
• Google – Google デプロイメント マネージャー テンプレート
• VMware - vCenter テンプレート
• OpenStack – Heat オーケストレーション テンプレート

F5 は、より幅広い展開シナリオをカバーするためにクラウド テンプレートを積極的に開発しています。関連するgithubリポジトリから問題またはプル リクエストを送信してください。

アプリケーション サービスは、機能するアプリケーションを作成するテクノロジ スタック内の 1 つのレイヤーにすぎません。 アプリケーションをコードコミットから運用展開および監視に移行するために必要なすべてのコンポーネントを統合、構築、展開するには、多数の従属ステップが必要であり、それらを正しい順序で実行する必要があります。 このタスクを自動化するのは、調整されたタスクとツールのワークフロー パイプラインを作成するオーケストレーション ツールの役割です。  

ほとんどのパイプラインは、アプリケーション、テスト、インフラストラクチャ構成のコードを含むソース コード リポジトリから始まります。

AS3、クラウド テンプレート、宣言型オンボーディングなどのツールを使用すると、デプロイメント パイプラインの一部としてアプリケーション サービスを構築および構成するために必要なすべての構成情報を保存できます。

マルチテナントの長期 BIG-IP ハードウェアまたはソフトウェア プラットフォームを使用するアーキテクチャでは、アプリケーションのコード リポジトリの一部として管理される AS3 構成のみが必要になります。 対照的に、デプロイメント プロセスの一環としてオンデマンドで専用インスタンスを起動するシナリオでは、テンプレートと宣言型オンボーディング宣言の管理をアプリケーション リポジトリの一部にする必要があります。

考えられるすべての自動化ツールやオーケストレーション ツールを網羅することはできませんが、以下に F5 のお客様が使用する最も一般的なツール、ユース ケース、機能のリストを示します。

言語統合

構成管理およびインフラストラクチャ自動化ツール

インフラストラクチャ テンプレート システム

スタートアップエージェントとクラウドスクリプト

クラウド初期化

https://devcentral.f5.com/articles/f5-in-aws-part-5-cloud-init-single-nic-and-scale-out-of-big-ip-in-v12-21476

クラウドライブラリ

https://github.com/F5Networks/f5-cloud-libs

プラットフォーム統合

コンテナ管理プラットフォーム

プライベートクラウドプラットフォーム

上記のツールと統合は、アプリケーションの可用性、セキュリティ、スケーリング サービスを提供するために BIG-IP プラットフォームを自動的に導入および構成する方法を表しています。 これらのサービスは不可欠ですが、フルスタック アプリケーションの展開の一部にすぎません。 サーバー、データ、コンパイルされたアプリケーション コード、インフラストラクチャを含む完全なアプリケーション スタックを調整およびテストされた方法で作成するには、単純な自動化ツール以上のものが必要です。

関連するワークフローと多数の自動化システムとの統合を備えた、より高度なオーケストレーション ツールが必要になります。 これらのツールは、継続的インテグレーション/継続的デリバリー (CI/CD) の作業方法で最も一般的に使用されており、すべての実用的な実装では自動化が必要です。 数多くのオーケストレーション ツールが存在しますが、おそらく Jenkins が最も一般的であり、Jenkins、F5、Ansible を使用して F5 のインフラストラクチャ アズ コード機能を CI/CD ワークフローに組み込む方法を示すサンプル ワークフローが用意されています。 ただし、一般的には、オーケストレーション ツールは構成自動化ツールの 1 つを介して動作し、実際に変更を加えてサービスを展開します。

BIG-IP プラットフォームが機能するにはライセンスが必要であるため、自動化のクリティカル パスにライセンスを含めると役立ちます。 BIG-IP 仮想デバイスを迅速にスケールアップまたはスケールダウンしたり、テストや開発の目的で作成したりする必要がある非常に動的な環境では、ライセンス モデルを慎重に検討する必要があります。

パブリック クラウドでは、BIG-IP のユーティリティ課金バージョン (クラウド マーケットプレイスから入手可能) を使用する方法があります。 ユーティリティ課金インスタンスは自己ライセンスとなり、コストは従量課金制または時間契約ベースでクラウド プロバイダーを通じて請求されます。

もう 1 つのオプションは、サブスクリプション (または永続的) を通じて購入した再利用可能なライセンスのプールをF5 BIG-IQ License Managerと一緒に使用することです。これにより、プールからライセンスを割り当てたり取り消したりできるようになります。

スタートアップ エージェントと API 呼び出しを通じてライセンス手順を自動化できますが、その際には F5 ライセンス サーバーへのアウトバウンド インターネット アクセスが必要になります (クラウド プラットフォームのユーティリティ ライセンスの場合でも)。

組織によっては、適切な自動化およびオーケストレーション ツールを選択するのは非常に簡単な場合もあれば、難しい作業になる場合もあります。 他のコンポーネントにすでにツールや方法論を採用していて、BIG-IP をシステムに統合するだけでよい場合は簡単です。 特定のツールに統合しなくても、iControl LX 機能および cloud-init と組み合わせた豊富な iControl REST API により、BIG-IP を既存の自動化ツールに統合することが比較的簡単になります (特に、1 回の API 呼び出しで複雑な構成も作成できる iApp テンプレートと組み合わせると)。

ただし、ゼロから始める場合は、状況がより複雑になる可能性があります。 他のソリューションを選択する場合と同様に、まず要件を理解することが重要です。 この文書では要件リストを作成することはできませんが、評価に役立つ一連の質問と推奨事項を以下に示します。

自動化モデル: 宣言型モデルを使用すると、オーケストレーション コンシューマーが対話するのがはるかに簡単になります。 消費者は、そこに到達するためのすべての手続きステップではなく、自分が何を望んでいるかを知るだけでよいのです。 F5 Automation Toolchain ファミリは、今後のグリーンフィールド サイトの「モデル」展開を表します。

潜在的なプラットフォームと環境: コンテナとさまざまなクラウド プラットフォームがアプリケーション インフラストラクチャの重要な部分となることは避けられません。それに応じて計画を立ててください。

スキル: 基盤となるテクノロジーのいくつかに関するスキルをすでにお持ちですか? これらのスキルはあなたの部門外に存在する場合もありますが、ビジネス全体に存在する場合もあることに留意してください。 もしそうなら、組織がすでに採用している言語を使用するツールを選択するのが合理的かもしれません。

サポート性: サポートできるシステムのみを構築してください。 当たり前のように思えるかもしれませんが、成功の鍵は、組織内で実現できる複雑さのレベルを選択することです。そうすることで、余分な運用オーバーヘッドを発生させることなく、自動化のメリットを最大化できます。

IT システムの自動化の増加は避けられません。 主要なアプリケーション配信およびセキュリティ サービスに対して戦略的なアプローチを採用することで、組織が展開するアプリケーションの安全性と可用性が確保されます。 自動化は、特に複数のプラットフォームやパブリック クラウドで作業する場合に、運用オーバーヘッドの削減にも役立ちます。

適切な自動化システムを選択するのは難しい場合があります。理想的には、利用可能なスキル セットと、構築するシステムをサポートする能力を考慮して、共同で総合的な取り組みとして行う必要があります。 どのようなソリューションを選択しても、BIG-IP プラットフォームと F5 の専門知識が、アプリケーションがどこに展開されていても、アプリケーションが依存するエンタープライズ グレードのサービスを提供するために役立つことを確信できます。

F5 サポートに関する注意事項。 F5 はいくつかのテンプレートとツールをサポートしていますが、すべてをサポートしているわけではありません。 ソフトウェアが Github で入手可能な場合、サポートされているコードは F5 リポジトリの「サポートされている」フォルダーにのみあります。 その他のソフトウェアについては、関連する readme ファイルにサポート ポリシーが定義されています。