The Inside Playbook
Ansible Automation Platform、GitLab CE、Webhook を使用して IIS Web サイトをデプロイする
2020年3月17日、寄稿者： Colin McNaughton (コリン・マクノートン)
Red Hat Ansible Automation Platform 内の Ansible Tower REST API は、環境に存在するプロセスやツールに自動化を統合するのに役立つ主要なメカニズムです。Ansible Tower 3.6 は、エンタープライズ向けオンプレミスバージョンを含む、GitHub および GitLab の Webhook と直接統合しています。つまり、ソース管理で変更が加えられると自動化による処理がトリガーされ、インフラストラクチャ構成への変更の適用、新しいサービスのデプロイ、既存のアプリケーションの再構成などが実行されます。このブログ記事では、シンプルなシナリオをとおして、新たに統合された Webhook 機能を適用します。
環境
私の環境は、Ansible Tower (Red Hat Ansible Automation Platform のコンポーネント)、プロジェクトが既に作成されている GitLab CE、同じ git リポジトリがクローンされた IDE を実行しているコードサーバーで構成されています。Ansible Tower には、ホスト (認定済みクラウドで実行されている Windows 2019 Server インスタンス) を 1 つだけ持つ単一のインベントリが存在します。この例では、この Windows サーバー上に IIS をデプロイし、このサイトから提供する HTML ファイルにいくつかの変更を加えます。
IIS をデプロイするための私の Playbook は非常にシンプルです。
---
- name: Configure IIS
hosts: windows
tasks:
- name: Install IIS
win_feature:
name: Web-Server
state: present
- name: Start IIS service
win_service:
name: W3Svc
state: started
- name: Create website index.html
win_copy:
src: files/web.html
dest: C:\Inetpub\wwwroot\index.html
ここでは、「Web-Server」機能を追加し、IIS を起動して、サイトの HTML ファイルを IIS が提供する Web コンテンツのデフォルトの場所にコピーしています。
私の HTML ファイルは次のような基本的なものです。
<html>
<title></title>
<body>
</body>
</html>
目的とセットアップ
私の目的は、この 1 つの IIS サイトに変更を加えるマージ要求ごとに、基本的な HTML ファイルを使用してサイトを再デプロイすることです。
GitLab のアクセストークン
Webhook がトリガーされるときに、GitLab で作成されたマージ要求を Ansible Tower ジョブのステータスで更新したいと思います。
これを実現するには、まず GitLab アカウントのパーソナル・アクセス・トークンを作成して、Ansible Tower が GitLab API にアクセスできるようにする必要があります。これはとても簡単です。ユーザー設定に移動して、左側のナビゲーションパネルから「Access Tokens」を選択するだけです。
アクセストークンはわかりやすいよう「Ansible Tower」という名前を付け、有効期限を月末に設定し、このアクセストークンのスコープを API のみにします。「Create personal access token」をクリックすると、トークン自体が表示され、このページの下部に新しいエントリーが表示されます。
次に、このトークンを使用して、「GitLab Personal Access Token」タイプの Ansible Tower に新しい認証情報を作成します。
保存すると、Ansible Tower は私の GitLab アカウントに API アクセスできるようになります。
Ansible Tower ジョブテンプレート
Ansible Tower がマージ要求を更新できるようになったので、シンプルな IIS Playbook を実行するように構成されているジョブテンプレートへの Webhook アクセスを構成する必要があります。Ansible Tower 3.6 リリース以降、各ジョブテンプレートには ENABLE WEBHOOK というチェックボックスがあります。
ENABLE WEBHOOK オプションを選択すると、いくつかの新しいフィールドが表示されます。私は、WEBHOOK SERVICE として GitLab を選択し、GitLab パーソナル・アクセス・トークンを使用して作成した資格情報を提供します。WEBHOOK URL にはこのジョブテンプレートへのパスが事前に入力されており、変更を保存すると WEBHOOK KEY が生成されます。これを使用して GitLab のプロジェクトフックを構成します。また、私のプロジェクトでは SCM ブランチをオーバーライドすることができます。つまり、プロジェクトは、Master ではなく「change-web-text」ブランチから更新をプルします。
GitLab プロジェクトフックの統合
次のステップでは GitLab に戻ります。今度は、Webhook を実行したいプロジェクトの統合ページに移動します。
統合ページで、URL (Ansible Tower のジョブテンプレートの WEBHOOK URL) とシークレットトークン (Ansible Tower のジョブテンプレートの WEBHOOK KEY) を指定します。また、トリガーに「マージ要求イベント」を指定します。これにより、マージ要求が開かれると指定した URL が起動されます。
使ってみる：ウェブサイトのテキストを更新する
新しい認証情報タイプとしてパーソナル・アクセス・トークンを使用してプロジェクトへのアクセスを Ansible Tower に付与し、ジョブテンプレートを構成して Webhook を有効にし、プロジェクトのマージ要求イベントに応答するように GitLab のプロジェクトフックを構成しました。これで、HTML ファイルのテストコミットを行う準備ができました。
ここでは、HTML ドキュメントの `<title>` タグと `<body>` タグにテキストを追加して、ファイルを保存します。
「change-web-text」ブランチで変更をコミットしたら、コードをプッシュして GitLab に戻り、マージ要求を開いて変更をマスターにマージします。
このマージ要求を開くと、Webhook がトリガーされ、Web ページの変更が IIS サイトにデプロイされます。パーソナル・アクセス・トークンを使用して Ansible Tower を構成したので、Ansible Tower は、マージ要求での Webhook トリガーの結果として実行されたジョブへのリンクをポストします。
すべてが正しく構成されていれば、構成済みの Webhook を伴うジョブテンプレートに対応する新しいジョブが実行されていることが確認できます。キックオフされたジョブも表示され、GitLab プロジェクトから最新の変更を取り込むプロジェクトを更新します。
Webhook 実行用に構成したジョブテンプレートである「iis website create」のジョブを選択すると、Webhook によってジョブが起動 (LAUNCHED BY) されたことが示されます。EXTRA VARIABLES には、プロジェクト固有の構成に関する多くのファクトが表示されます。さらに重要なのは、ジョブが想定どおりに実行されていることがジョブ出力に示されていることです。
完了すると、IIS サーバーの IP をプルアップして、私のすばらしい HTML ページへの変更を確認できます。
まとめと次のステップ
Ansible Tower 3.6 に導入された Webhook は、ソース管理のイベントに応答して自動化を起動するための非常にパワフルな方法です。ここで使用した基本的な Web サイトはとても手短でシンプルな例にすぎませんが、すべてのサービス構成が Ansible Playbook で定義されているコードとしてのインフラストラクチャにこの機能を適用すると、いかに強力な機能であるかがよくわかります。さらに進めたい場合は、自動化がコードとしてインフラストラクチャに拡張されると、適切なゲートが配置されていることを確認できます。これは、Ansible Tower 3.6：Ansible Tower のワークフローに承認ステップを追加する方法でも紹介されている、ワークフローの承認ノードについて詳しく知る絶好のチャンスです。
