リポジトリと標準化は、ネットワーク自動化統合の課題に対処するのに役立ちます
統合という言葉は、その実施に専念するプロジェクトに取り組んでいる人々の歯ぎしりや嘆きを呼び起こすという意味で、常に4文字の言葉でした。 実際、IT 意思決定者の 59% が「統合は組織にとっての『アキレス腱』である」と評価しています。(コネクテッド ビジネス統合 2018 レポート)
表面的には、統合は「applications間でデータをどのように共有するか」という単純な前提から始まります。 なぜなら、applicationは、たとえモノリスであっても、孤立したものではないからです。 他のapplicationと少なくとも 1 つのデータを共有しないapplicationにはまだ出会ったことがありません。
私たち（業界）は、統合の時代を何度か経験してきました。 ハブ アンド スポーク モデルからエンタープライズ (サービス) バス、メッセージ キューまで、統合は常にエンタープライズapplication戦略の不可欠な要素です。
私たちはもうこれをエンタープライズapplication統合 (EAI) とは呼びません。主な理由は、若者を怖がらせ、私たち年配者を激怒させると思うからです。しかし、私たちは今でも「統合」という言葉を使っています。 そして、application開発の世界以外でも、これをますます使用しています。 結局のところ、CI は継続的インテグレーションの略です。 私たちは、統合が世界の展開（生産）側にとっても重要であると考えています。 また、ネットワークの自動化に直面したときに統合ツールが不足していることに不満を感じているアプリ開発者と同様に、私たちも不満を感じています。
運用には統合が必要です。 これがなければ、プロセスを自動化することはできません (オーケストレーションとは)。プロセスは必然的に複数のシステム、サービス、デバイスにまたがり、それぞれに独自の運用ドメインとツールセットがあるためです。 統合がなければパイプラインを構築できず、パイプラインがなければ、頻繁なオンデマンドのデプロイメントの要件の増大によって運用が圧倒されてしまいます。
ここで、コードとしてのインフラストラクチャとリポジトリが役立ちます。 リポジトリは、構成ファイルから Python プログラム、スクリプト、テンプレートまで、あらゆる種類の成果物を保存できる場所以上のものです。 彼らは、（統合された）展開パイプラインに積極的に参加することができます。
リポジトリは単なる収納箱ではありません
リポジトリは、成果物を保存するだけの場所ではありません。 確かに、それが主な目的ですが、単なる収納ロッカー以上のものに進化しました。 今日では、GitLab や GitHub などのリポジトリは、自動化されたパイプラインの重要なコンポーネントになり得ます。 トリガーとイベントを使用すると、リポジトリは成果物を保存する場所としてだけでなく、より大きなツールチェーン内のツールとしても機能します。 コミットによりジョブが開始され、完了すると、パイプラインの次のステップをトリガーする Webhook が呼び出されます。
Webhook とは何ですか?
「リバース API」と呼ばれることもある Webhook を使用すると、リポジトリなどのapplicationが URL/API を介して別のapplicationにデータをリアルタイムで送信できます。たとえば、ロード バランサの新しい構成をコミットすると、リポジトリによって Webhook がトリガーされ、次に構成または構成の URI がアプリ (またはロード バランサに直接) に送信され、アプリによって新しい構成が読み込まれます。
基本的に、私たちは、エンタープライズ サービス バスを使用してデータを共有し、さまざまなapplicationsやサービスでアクションを開始して「プロセス」を完了していたのとほぼ同じ方法でリポジトリを使用しています。 ビジネスの世界では、そのプロセスは顧客の注文を完了することであり、顧客情報システム (CIS)、注文履行システム、請求、サプライ チェーンの要素が関係します。
運用の世界では、そのプロセスは、applicationまたはポリシーの展開の実行に関係するインフラストラクチャ、ネットワーク、およびセキュリティ サービスに及びます。
「スキル」を最大の課題として挙げた人にとってさらに興味深いのは、リポジトリをほぼコマンド ラインからのみ制御できることです。 はい、ほとんどの NetOps がすでに持っているのと同じスキルを使用します。 ちょっとした bash と PERL*、curl 経由の API で出来上がり!
しかし、これではデバイス層での統合に対するより深いニーズには対処できず、ベンダーソリューションの不足に対する不満として表れています。 最終的には、リポジトリに保存され、Webhook によってトリガーされる構成または構成の変更を、デバイスが理解できる形式に翻訳する必要があるためです。
ここで標準化とソリューションが重要になります。
標準化により運用統合の負担が軽減
自動化は、現在 F5 の多くの社員が注力している分野です。 私たちが考え出した解決策の 1 つが、 F5 Automation Toolchainです。 これは、F5 Application Services 3 Extension (AS3)、F5 Declarative Onboarding (DO)、F5 Telemetry Streaming、および F5 API Services Gateway で構成されます。 これらをリポジトリと組み合わせることで、組織は、application(およびビジネス) がアプリを高速かつ安全で、可用性を維持するために必要なapplicationサービスを展開するために必要なパイプラインを構築できるようになります。
しかし、ロリさん、それは自動化と統合が必要な他のすべてのデバイスやサービスには役立たないと思っているかもしれません。
真実。 これは、共通applicationサービス プラットフォームの標準化が役立つ方法の 1 つです。 プラットフォーム (BIG-IP) は幅広いapplicationサービスで同じであるため、自動化ツールチェーンを使用して、WAF、ロード バランサ、アクセス制御、DDoS 保護などを展開できます。 できるだけ少ないプラットフォームで標準化することで、ネットワーク、インフラストラクチャ、セキュリティなど、すべての運用における統合の負担が軽減され、価値が向上します。
これは、データセンターの範囲内およびマルチクラウドのシナリオでも当てはまります。 applicationサービスとクラウド環境全体で単一のプラットフォームを標準化すると、どこにでもアプリを展開するときに価値実現までの時間が短縮されます。
F5 Automation Toolchain (完全に無料で入手可能) は、いくつかの場所で見つけることができます。
リポジトリは単にデータを保存する場所ではないことを覚えておいてください。 これらは自動化ツールボックス内の貴重なツールであり、パイプラインのさまざまな部分すべてを自動化するために活用できます。 applicationサービス プラットフォームとともにリポジトリを標準化すると、統合という 4 文字の単語によって課せられる運用上の負担を大幅に軽減できます。
*「PERL」を Python または実際に使用可能なスクリプト言語として解釈します。 PERL はcurlと韻を踏む唯一のもので、 wgetと韻を踏む良いものは見つかりませんでした。