チャレンジ
現代のソフトウェア開発における継続的インテグレーションと継続的デリバリー (CI/CD) の実践により、新しいソフトウェアや新機能をより早く市場に投入できるようになります。 高度に仮想化され、自動化可能なクラウドおよびコンテナ プラットフォームの進化と並行して、配信方法のこの革新により、一般的な企業におけるapplicationsの数と機能が急速に増加しました。
ただし、applicationsがどのように、どこに展開されるかに関係なく、トラフィック管理、コンテンツ ルーティング、ボット防御、API セキュリティなどのapplicationサービスからのサポートが必要です。 適切に機能する CI/CD パイプラインのほとんどは、最小限の人的介入でapplicationコードの統合と展開を処理します。 しかし、多くの組織では依然として、時間のかかるチケット駆動型のプロセスを通じて、applicationサービスとポリシー（多くの場合、ネットワークとセキュリティ ポリシーの手動構成）を管理しています。
これにより、コードを迅速にリリースするために、企業のセキュリティ ポリシー、ネットワーク操作、およびその他の制御をバイパスするという決定につながる可能性があります。 リリース サイクルを遅らせることなく、重要なapplicationsに必要なサービスを確実に提供するにはどうすればよいでしょうか。
関連コンテンツ
解決
唯一の実行可能な解決策は、アプリ サービスの構成と展開を、ソフトウェア スタックの残りの部分の展開に使用されているのと同じツールチェーンに挿入することです。 コードと成果物を統合して、applicationsをビルド、テスト、デプロイするワークフローにapplicationサービスを挿入すると、2 つの重要な利点が得られます。
- applicationコードは、実稼働バージョンのapplicationサービスを使用してテストされます。 セキュリティ ポリシーと新しいソフトウェア機能の間に相互運用性の問題がある場合は、テスト プロセス中にその問題が検出され、ソフトウェア ビルドが中止される可能性があります。
- 実稼働環境にデプロイされたapplicationsは、必要なときに必要なセキュリティとapplication配信サービスを受けられます。 手動で追加される追加コンポーネントではなく。
BIG-IP のコードとしてのインフラストラクチャと宣言型オンボーディング
仕組み
一般的なデプロイメント ワークフローには、多数のサービスが含まれます。
ソース コードマネージャー (SCM) >
ソース コードマネージャー (SCM)
ここには、applicationの構築とデプロイに必要なapplicationコード、インフラストラクチャ コード、その他のテキストベースの成果物が保存されます。 SCM は一般に「真実のソース」です。理想的な世界では、SCM が実行されるapplicationまたはインフラストラクチャへの変更は、ソースを変更してワークフローを実行することによってのみ実行できるためです。
オーケストレーター >
オーケストレーター
オーケストレーション ツールは、ソフトウェアのビルド、テスト、統合パイプラインに加えて、テスト インフラストラクチャと構成を作成するジョブを作成します。 applicationサービスはオーケストレーターによって作成される必要があり、applicationサービス プラットフォームに直接統合される場合もあれば、二次的な自動化ツールを介して統合される場合もあります。
自動化ツール >
自動化ツール
サーバー インスタンス、ネットワーク コンポーネント、applicationサービスなどのインフラストラクチャ コンポーネントをオーケストレーターによって作成または変更する必要がある場合、何らかの自動化ツールがよく使用されます。 これは、Ansible などのローカルにインストールされ管理されるサービスである場合もあれば、Amazon Web Services CloudFormation などのクラウド サービスである場合もあります。
要素マネージャー >
要素マネージャー
これらは、実際にサービスを提供するインフラストラクチャへの自動化インターフェースを表します。 すべてのアーキテクチャに存在するわけではありませんが、要素マネージャーはライセンス、テレメトリ、レポート、プラットフォーム ソフトウェアのバージョンを管理できるほか、サービス作成のための認証と承認の追加レイヤーとしても機能します。
サービスプラットフォーム >
サービスプラットフォーム
一般的に、サービス プラットフォームは、コンテナーやapplicationプロキシなどのサービスを提供するコンポーネントで構成されます。 これは、applicationまたはインフラストラクチャ コード、コンピューティング インスタンス上で実行中のサービス、負荷分散プロセス、またはアプリケーション層のファイアウォール構成の「最終宛先」です。
コンポーネント
applicationサービスの展開を CI/CD ワークフローに統合するために、組織はいくつかの F5 コンポーネントを活用できます。
BIG-IPプラットフォーム >
BIG-IP は、業界をリードするapplication配信およびセキュリティ サービス プラットフォームです。 数メガビットから 1 テラビット/秒を超えるスループットまでの拡張性、膨大な機能範囲、および幅広いコンピューティング環境 (通信事業者の POP 向けの堅牢なハードウェアからパブリック クラウドの仮想バージョンまで) での可用性を備えた BIG-IP プラットフォームは、applicationsが必要とするサービスを、必要なすべての場所で提供できます。
F5 自動化ツールチェーン >
F5 Automation Toolchain 製品ファミリは、F5 BIG-IP プラットフォームを CI/CD ツールチェーンなどの一般的な自動化パターンに統合できるようにする基本的な自動化およびオーケストレーションのビルディング ブロックで構成されています。
F5 自動化ツールチェーンには、次の主要コンポーネントが含まれています。
- 宣言型オンボーディング拡張機能 (DO) - ネットワーク、DNS、高可用性などの BIG-IP プラットフォーム設定を構成します。
- Application Services 3 Extension（AS3）：ロード バランシング、コンテンツ ルーティング、ボット検出などのアプリケーション サービスを構成します。
- テレメトリ ストリーミング拡張機能 (TS) - Kafka、Splunk、Graphite などの分析システムへの自動applicationトラフィック テレメトリ ストリーミングを構成します。
これらのツールは、F5 BIG-IPapplicationサービス プラットフォームを構成するための宣言型インターフェイスを提供します。これにより、applicationsに必要なセキュリティ、最適化、スケーリング サービスが提供され、自動化ツールやオーケストレーション ツールと統合できます。
ネットワーク インフラストラクチャをコードとして >
コードとしてのネットワーク インフラストラクチャ
技術系ブロガーの Nathan Pearce 氏によると、Infrastructure as Code の実装のほとんどは、「サーバー」インフラストラクチャを中心に展開されています。 このビデオでは、Nathan が Infrastructure as Code プラクティスを F5 の BIG-IP App Services アプライアンスの管理に導入する方法について説明します。
結論
継続的インテグレーション、継続的デリバリー、継続的デプロイメントの実践により、より安全で高速かつ効率的なソフトウェア開発が実現します。 この約束を実現するために重要なのは、application配信とセキュリティ サービスを開発および展開ワークフローに統合することです。
F5 は、業界をリードするapplication保護および最適化サービスをワークフローに組み込むためのプラットフォーム、統合、トレーニングを提供し、ソフトウェアを安全、高速、かつ可用性を確保するために必要なサービスとともに構築、テスト、展開できるようにします。
リソース
F5 Automation Toolchainに関するすべての詳細を入手してください。
BIG-IP プラットフォームのプログラマビリティ機能の使用について詳しく学びます。
F5applicationサービスの自動化に関する実用的なガイドをお読みください。