概要
Webhook は、2 つのアプリケーション・プログラミング・インタフェース (API) 間の軽量なイベント駆動型の通信を可能にする HTTP ベースのコールバック機能であり、Webhook はさまざまな Web アプリケーションで他のアプリケーションから少量のデータを受信するのに使用され、また GitOps 環境での自動化ワークフローのトリガーにも使用されます。
アプリケーション開発での Webhook
API とは
API は、アプリケーション・ソフトウェアを構築および統合するための一連のツール、定義、およびプロトコルです。API 間の通信は情報プロバイダーと情報ユーザーの間の契約とみなされることもあり、コンシューマー (呼び出し) から要求されるコンテンツとプロデューサー (応答) によって要求されるコンテンツを確立します。この関係はサーバー・アプリケーションを呼び出すクライアント・アプリケーションとも考えられます。このロールは、所定の状況でデータを要求するアプリケーションに応じて逆転します。
Web API は通常 HTTP を使用して他のアプリケーションからデータを要求し、応答メッセージの構造を定義します。この構造は一般に XML または JSON ファイルの形式です。XML と JSON の両方とも他のアプリケーションが操作しやすい方法でデータを提示するため、好まれるフォーマットです。
クライアント API がサーバー API にデータを要求するとき、呼び出しによって特定のイベントが発生したかを確認します。つまり、サーバーのデータがクライアントにとって役立つ方法で変更されていないかを確認します。このプロセス (ポーリングと呼ばれる) では、サーバーの API が該当するデータを送信するまで、クライアントは定期的に HTTP 要求を送信します。このデータはペイロードと呼ばれることもあります。
クライアント・アプリケーションはサーバー・アプリケーションの状態を把握していないので、最新情報を取得しようとサーバーの API にポーリングし、特定のイベントが発生するまで何度も呼び出しを続けます。しかしサーバーは、情報がある場合にのみ要求されたデータを送信します。クライアント・アプリケーションは最新情報を要求し続け、該当するイベントが発生するまで待機します。
Webhook の違い
Webhook を準備するため、クライアントはサーバー API に一意の URL を付与し、認識したいイベントを指定します。Webhook がセットアップされると、クライアントはサーバーにポーリングする必要がなくなります。指定されたイベントが発生すると、サーバーは該当するペイロードをクライアントの Webhook URL に自動的に送信します。
Webhook はリバース API やプッシュ API と呼ばれることもよくあります。通信の責任をサーバーではなくクライアントに任せるからです。クライアントが HTTP 要求を送信する、つまりサーバーが応答するまでデータを求めるのではなく、 データが利用できるようになったときにサーバーはクライアントに HTTP POST 要求を 1 回送信します。その呼び名とは異なり、Webhook は API ではなく、連携して機能します。Webhook を使用するには、アプリケーションには API が必要です。
Webhook という名前は、HTTP ベースの通信を意味する Web と、関係する可能性がある呼び出しやその他のイベントをアプリケーションにインターセプトさせるプログラミング機能のフッキングを示す hooking を組み合わせただけです。Webhook はサーバー・アプリケーションで発生したイベントをフックし、サーバーにペイロードをクライアントに Web 経由で送信するよう指示します。Jeff Lindsay 氏は 2007 年のブログ投稿「Web hooks to revolutionize the web」において、このコンセプトを世間に広めようとしました。
IT チームは Webhook で通信するアプリケーションを保護するためのさまざまな手法を使用しています。ほとんどの Webhook 対応アプリケーションは、ペイロードの要求ヘッダーにシークレットキーを追加しているので、クライアントはサーバーのアイデンティティを確認できます。Webhook は多くの場合、相互トランスポート層セキュリティ (mTLS) 認証で保護され、クライアントとサーバーの両方を検証してからペイロードを送信します。クライアント・アプリケーションが SSL 暗号化を Webhook URL に使用することも多く、転送されたデータの機密性を維持します。
Webhook の特徴：
- ポーリングの必要性がない：クライアント・アプリケーションのリソースを節約できます。
- 迅速にセットアップできる：アプリケーションが Webhook をサポートしている場合、サーバー・アプリケーションのユーザー・インタフェースから容易にセットアップできます。ここでクライアントがアプリケーションの Webhook URL を入力し、関心のあるイベントなど、基本的なパラメーターを設定します。
- データ転送を自動化する：指定されたイベントがサーバー・アプリケーションで発生すると、ペイロードは即座に送信されます。この交換はイベントによって開始されるので、データがサーバーからクライアントに転送されると、リアルタイムのデータ転送と同様に、迅速に発生します。
- 特定の軽量ペイロードに適している：Webhook では送信するデータ量をサーバーが決定し、ペイロードの解釈と生産的な方法での使用はクライアントに任されています。クライアントはデータ転送の正確なタイミングやサイズを制御しないので、Webhook は２つのエンドポイント間の少量の情報を、多くの場合は通知の形式で処理します。
インフラストラクチャ開発での Webhook
Webhook が使用される主な目的は、2 つのアプリケーション間の通信を単純化することですが、Infrastructure-as-code (IaC) ワークフローを自動化し GitOps プラクティスを実現するためにも使用できます。
IaC (Infrastructure as Code) とは
IaC (Infrastructure as Code) は、手動のプロセスではなく、コードを使用してインフラストラクチャの管理とプロビジョニングを行うことを言います。IaC においてバージョン管理は重要な要素であり、設定ファイルは他のソフトウェアのソースコードファイルと同じようにソース管理を行う必要があります。インフラストラクチャをコードとしてデプロイするということは、インフラストラクチャをモジュラー・コンポーネントに分割し、自動化を使ってさまざまに組み合わせることもできるということです。
IaC を使用するインフラストラクチャ・プロビジョニングの自動化により、開発者は、アプリケーションを開発またはデプロイするたびに、サーバー、オペレーティングシステム、ストレージ、およびその他のインフラストラクチャ・コンポーネントのプロビジョニングと管理を手動で行う必要がなくなります。インフラストラクチャを体系化すると、プロビジョニングに使用するテンプレートを得られます。これは手動で実行することもできますが、これらのプロセスは Red Hat® Ansible Automation® Platform などのエンタープライズレベルの望ましい状態を達成するエンジンで自動化できます。
GitOps とは
GitOps は、IaC の進化形とみなされることも多いのですが、オープンソースのバージョン管理システムである Git を使用して、インフラストラクチャとアプリケーションの構成を管理するための戦略的アプローチです。GitOps プラクティスに従い、開発者は宣言的インフラストラクチャおよびアプリケーションの信頼できる唯一の情報源として Git を使用し、インフラストラクチャのプロビジョニングとデプロイメントの自動管理に Git プルリクエストを使用します。Git リポジトリにはシステムの全体の状態が含まれているため、変更の記録を確認して監査することができます。
Webhook が役立つ場面
Webhook は Git 中心のデプロイメント・パイプラインの実装と管理に必要なステップを削減し、IaC ワークフロー全体を自動的に起動するために使用できます。GitOps 環境では、Webhook は 2 つのアプリケーション間と同様に機能し、特定のイベントによってトリガーされると、1 つの API がもう片方の API にペイロードを送信します。違いは、Webhook をトリガーするイベントのタイプと、ペイロードの受信側の動作にあります。
このコンテキストでは、git リポジトリはサーバー・アプリケーションの役割をし、インフラストラクチャの状態を管理する望ましい状態を達成するエンジンはクライアント・アプリケーションの役割を担当します。リポジトリで変更が行われたら常に通信をトリガーするように Webhook を設定することができます。たとえば、コードの一部が更新されて git リポジトリにプッシュされると、このイベントによって Webhook がトリガーされます。リポジトリはペイロードを望ましい状態を達成するエンジンの Webhook アドレスに自動的に送信し、コードの変更を通知します。
このように Webhookを使用すると、望ましい状態を達成するエンジンでインフラストラクチャのあらゆる変更を監視させることができ、リポジトリを積極的に監視する必要はありません。望ましい状態を達成するエンジンが自動化もサポートしている場合、Webhook を使用して IaC ワークフローをトリガーできます。たとえば、Red Hat Ansible Automation Platform などのエンタープライズレベルの望ましい状態を達成するエンジンにより、システム管理者は Webhook を使用して最新の変更を管理対象ホストに自動的にデプロイできます。
Red Hat のサポート内容
Red Hat® Ansible® Automation Platform には自動化 Webhook が組み込まれており、IaC および GitOps プラクティスをサポートします。Webhook によって、GitHub や GitLab などのサービスを介して、git リポジトリと Ansible Automation Platform とのネイティブ統合が実現します。リポジトリリンクが設定されると、Ansible Automation Platform は Git システムから Git コミットをキャッチし、それらのイベントを使用して自動化ジョブをトリガーし、プロジェクトを更新してインベントリーを管理し、デプロイメントを実行します。
自動化 Webhook により、イベントがソース管理システムで発生したときに自動化ワークフローを自動的に有効化できます。これにより、リポジトリを監視したり、変更の発生時に自動化ジョブを起動したりするための Jenkins などの CI/CD ツールを追加する必要がなくなり、GitOps のワークフローが単純化され、運用が効率化されます。Red Hat Ansible Automation Platform は、さまざまな開発ツールやデプロイメントツールと連携できるため、使用するツールやプロセスに応じて GitOps のワークフローをカスタマイズすることができます。
