アプリケーション配信デバイスとセキュリティ デバイスの展開と構成管理を自動化することは、ほぼ必須のプラクティスになっています。 2017 年の IDG FutureScapeレポートでは、自動化とマルチクラウド管理が、2021 年までにビジネスに影響を与える主要な取り組みの一部としてランク付けされました。 自動化により、アプリケーションに必要な重要なセキュリティ、最適化、可用性サービスの展開にスケール、信頼性、統合がもたらされ、それらの配信が、アプリケーション展開の主要モデルとして台頭しているオーケストレーションされたビルド、テスト、展開ワークフローの一部になります。
新しい仮想サーバーやプール メンバーの追加などの基本的なタスクを単純に自動化するだけでも、運用部門はアプリケーション所有者やその他の自動化システムにセルフサービス機能を提供できるようになり、次世代の自動化ツールの構築など、より生産性の高い作業に時間を割くことができます。
組織が IT サービスを提供するために複数のクラウド プラットフォームを導入し始めると、自動化の必要性がさらに重要になります。 プラットフォーム特性が異なる複数の場所にサービスを展開する場合、自動化により、運用オーバーヘッドの増加を抑え、新しいプラットフォームに不慣れなために発生するエラーを減らすことができます。
しかし、何をどのように自動化すればよいのでしょうか? さまざまな操作モデル、インターフェース、言語により、自動化ソフトウェアは単一のデバイス レイヤーで動作することも、より複雑なマルチシステム ツールとして動作することもできます。 Infrastructure-as-a-Service (IaaS) クラウド プラットフォームはすべて、仮想インフラストラクチャとサービスを展開するための独自のネイティブ ツールを提供します。 さらに、F5 はさまざまなインターフェースとオーケストレーション オプションを提供します。 こうした幅広いツールとオプションにより、組織に最適な方法で自動化する機会が得られますが、適切なツールを選択するのは困難な作業になる可能性があり、複雑さとツールの急増のリスクは現実的です。
このホワイト ペーパーでは、F5 BIG-IP アプライアンス (物理と仮想の両方) の導入、管理、構成を自動化する方法の概要と、ビジネスに適した方法を選択する方法に関するアドバイスを紹介します。
自動化はさまざまなアクティビティをカバーします。 スペクトルの一方の端には、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 デバイスは、文書化されたスキーマを介して BIG-IP 機能の大部分を公開する REST API を介して自動化されることが最も一般的です。 Ansible などの自動化ツール用の F5 提供モジュールは、REST API を広範に使用します。設定ごとの命令型インターフェイスの提供に加えて、REST API 呼び出しを使用して F5 iApp テンプレートを起動できます。このテンプレートでは、iApp サービスを構成する値が API 呼び出しで JSON ペイロードとして渡されます。 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 寄稿 |
https://github.com/F5Networks/f5-common-python |
行く |
ユーザーの投稿 |
https://github.com/f5devcentral/go-bigip |
パワーシェル |
F5 対応 |
https://devcentral.f5.com/wiki/icontrol.powershell.ashx |
構成管理およびインフラストラクチャ自動化ツール
道具 |
状態 |
例と出典 |
アンシブル |
F5 寄稿 |
https://github.com/F5Networks/f5-ansible |
テラフォーム |
F5 寄稿 |
https://github.com/f5devcentral/terraform-provider-bigip |
人形 |
F5 寄稿 |
https://github.com/f5devcentral/f5-puppet |
シェフ |
ユーザーの投稿 |
https://github.com/target/f5-bigip-cookbook |
ソルトスタック |
第三者 |
https://docs.saltstack.com/en/latest/ref/runners/all/salt.runners.f5.html |
インフラストラクチャ テンプレート システム
プラットフォーム |
状態 |
例と出典 |
アマゾン |
F5 対応2 |
https://github.com/F5Networks/f5-aws-cloudformation |
アズール |
F5 対応1 |
https://github.com/F5Networks/f5-azure-arm-templates |
グーグル |
F5 対応1 |
https://github.com/F5Networks/f5-google-gdm-templates |
オープンスタック |
F5 対応1 |
https://github.com/F5Networks/f5-openstack-hot |
スタートアップエージェントとクラウドスクリプト
クラウドライブラリ
https://github.com/F5Networks/f5-cloud-libs
プラットフォーム統合
コンテナ管理プラットフォーム
プラットフォーム |
状態 |
例と出典 |
クベネフィット |
F5 対応1 |
https://github.com/F5Networks/k8s-bigip-ctlr |
マラソン |
F5 対応1 |
https://github.com/F5Networks/marathon-bigip-ctlr |
クラウドファウンドリ |
F5 対応1 |
https://github.com/F5Networks/cf-bigip-ctlr |
プライベートクラウドプラットフォーム
プラットフォーム |
状態 |
例と出典 |
オープンスタック (LBaaS) |
F5 対応1 |
https://github.com/F5Networks/f5-openstack-lbaasv2-driver |
OpenStack(ヒート) |
F5 対応1 |
https://github.com/F5Networks/f5-openstack-hot |
VMWare (vRO) |
第三者 |
https://bluemedora.com/products/f5/big-ip-for-vrealize-operations/ |
上記のツールと統合は、アプリケーションの可用性、セキュリティ、スケーリング サービスを提供するために 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 プライベート クラウド ソリューション パッケージは、さまざまなプライベート クラウド環境で F5 アプリケーション サービスを提供するために必要なテクノロジとサービスを簡単に取得できる方法です。 パッケージには、ソフトウェア、ハードウェア、プロフェッショナル サービスがバンドルされており、多数のプライベート クラウド プラットフォームに対応したターンキーの検証済みソリューションが作成されます。 プライベート クラウド ソリューション パッケージを使用すると、他のプラットフォームに複製できるモデル展開が提供され、複数の環境にわたってより均一で一貫性のあるアプリケーション配信およびセキュリティ サービスのセットを作成できます。
IT 自動化のレベルの向上は避けられません。 主要なアプリケーション配信およびセキュリティ サービスを提供する戦略的なアプローチを採用することで、組織が展開するアプリケーションのセキュリティと可用性が確保されます。 自動化は、特に複数のプラットフォームやパブリック クラウドで作業する場合に、運用オーバーヘッドの削減にも役立ちます。
適切な自動化システムを選択するのは難しい場合があり、理想的には、利用可能なスキル セットとシステムのサポート可能性を考慮して、共同で総合的な取り組みとして行う必要があります。 どのようなソリューションを選択しても、BIG-IP プラットフォームと F5 の専門知識が、アプリケーションがどこに展開されていても、アプリケーションが依存するエンタープライズ グレードのサービスを提供するために役立つことを確信できます。