はじめに
前回の記事で、eda-server をデプロイしてログインできるところまで確認しました。
今回は、Webhook をイベントソースとしてAutomation Controller のジョブテンプレートを実行する仕組みを試します。
以降、念のため AAP のプロダクトとして EDA Controller と区別するために eda-server と表記します。
環境は前回と同じく以下のとおりです。
- 環境
■ 環境面の準備
環境変数
前回の記事同様、eda-server を docker-compose で up でする際に、Automation Controller の接続情報を環境変数で定義します。
export EDA_CONTROLLER_URL=https://10.0.1.140 export EDA_CONTROLLER_SSL_VERIFY=no
環境変数名の頭が EDA_CONTROLLER_ なので少しややこしいですが、EDA Controller 自体のことを指しているのではなく「EDA の設定として、Automation Controller (またはAWX) の URLの指定をする」という意味合いのようです。
NAT
今回は TCP/5000 で Webhook を受け付けることにします。コンテナではなく、コンテナホスト（今回でいうと mac）自体が Webhook を受けられるようにしたかったので、NAT を追加します。具体的には、tools/docker/docker-compose-stage.yaml の podman というサービスの以下の箇所に 5000:5000 を追加します。
# ...(略)... services: podman: user: "1000" image: quay.io/containers/podman:${EDA_PODMAN_VERSION:-v4.5} privileged: true command: podman system service --time=0 tcp://0.0.0.0:8888 ports: - 8888:8888 - 5000:5000 # 追加 #...(略)...
（本当はどのサービスに設定すればよいか試行錯誤しました）
docker-compose で up
前回の記事同様、docker-compose で up します。
cd tools/docker docker-compose -p eda -f docker-compose-stage.yaml up
リポジトリの準備
あとで Project から Rulebook を参照するために、あらかじめ Rulebook を配置したリポジトリの作成が必要です。（現状は、ローカルディレクトリには対応していません）
リポジトリ側で、以下の Rulebooks を rulebooks/hello_jt.yml として作成します。
--- - name: Hello Events hosts: all sources: - ansible.eda.webhook: host: 0.0.0.0 port: 5000 rules: - name: Say Hello condition: event.payload.message == "sakana" action: run_job_template: name: Demo Job Template # 実行したいジョブテンプレート名 organization: Default
TCP/5000 で Webhook を待ち受けて、飛んできたペイロード内の「message が sakana だったら、Automation Controller のジョブテンプレート Demo Job Template を実行する」という Rulebook です。action には run_job_template を利用しています。
どこの Automation Controller を相手にするかというと、あらかじめ指定した環境変数 EDA_CONTROLLER_URL のアドレスです。Automation Controller への認証情報はあとで定義します。
ポイントはディレクトリ構成です。リポジトリ内の extensions/eda/rulebooks ディレクトリ > rulebooks ディレクトリの順に Rulebook を探すため、いずれかのディレクトリ配下に Rulebook を配置する必要があります。リポジトリトップやその他のディレクトリに Rulebook を置いても、プロジェクトとしてファイルを見つけてくれません。
■ リソース類類の作成
大まかには以下のような流れです。
- Project の作成
- Rulebook を格納したリポジトリの参照
- Decision Environment 作成
- Rulebook を実行するコンテナイメージ
- Automation Controller でいう Execution Environment
- Automation Controller のトークンの設定
- 連携のため
- Rulebook Activation の作成
- Rulebook の実行可能状態にする
Project の作成
ここからは画面の操作です。http://localhost:8080 に admin でログインします。
まずは、Rulebook を格納したリポジトリを参照するための Project を作成します。Automation Controller でいうと Playbook があるリポジトリと同じような位置づけです。
画面左メニューの Projects をクリックして一覧画面を開き、Create project をクリックします。
Project 作成画面が開くので、必要事項を入力します。
| 項目 | 意味 | 今回の設定値 | 備考 |
|---|---|---|---|
Name |
Project の名前 | my_project01 |
|
SCM URL |
Rulebook がある SCM の URL | https://github.com/akira6592/rulebook-sample.git |
現状 SCM Type が Git のみなのため、実質的に git clone したい URL（本記事を書いた後リポジトリの内容は変更する可能性があります。試したときのコミットはこの時点） |
入力したら、画面下部の Create project をクリックします。
Status が Completed になることを確認します。失敗したら URL が間違ってないか、認証が必要かなどを確認します。
Credential について（作成しない）
Credential は、プロジェクトを git clone するときや、後述の Decision Environment のイメージを pull するときに認証情報が必要な場合に作成するものです。
今回はプロジェクトも Decision Environment も認証不要のものを利用するため、Credential は作成しません。
Decision Environment （決定環境） の作成
Rulebook を実行するための環境のコンテナイメージを指定して定義します。Automation Controller でいう Playbook の実行環境の Execution Environment (EE) にあたるものと解釈しています。
まず画面左メニューの Decision Environments をクリックして一覧画面を開き、Create decision environment をクリックします。
Decision Environment 作成画面が開くので、必要事項を入力します。
| 項目 | 意味 | 今回の設定値 | 備考 |
|---|---|---|---|
Name |
Decision Environment の名前 | my_env01 |
|
Image |
Decision Environment として利用したいイメージ | quay.io/ansible/ansible-rulebook |
後述の補足参照 |
現状、SSL Verify 有無的な設定は見当たりませんでした。
入力したら、画面下部の Create decision environment をクリックします。
補足: 利用するイメージ quay.io/ansible/ansible-rulebook について
Decision Environment としてどのイメージを利用すればよいか少々悩みました。Rulebook を実行するための環境なので ansible-rulebook が入ってる必要がありそうです。これをヒントに考えて、気軽に使うには quay.io/ansible/ansible-rulebook が良いだろうと思って、このイメージを指定することにしました。
quay.io/ansible/ansible-rulebook には、ansible-rulebook のほか、ansible.eda コレクションも入っていました。
% docker run -it quay.io/ansible/ansible-rulebook /bin/bash (app-root) (app-root) pip list Package Version ------------------- -------- aiohttp 3.8.4 aiokafka 0.8.1 aiosignal 1.3.1 ansible 8.0.0 ansible-core 2.15.0 ansible-rulebook 1.0.0 ansible-runner 2.3.3 ...(略)... (app-root) (app-root) ansible-galaxy collection list # /opt/app-root/lib/python3.9/site-packages/ansible_collections Collection Version ----------------------------- ------- amazon.aws 6.0.1 ansible.netcommon 5.1.1 ansible.posix 1.5.4 ansible.utils 2.10.3 ansible.windows 1.14.0 ...(略)... # /opt/app-root/src/.ansible/collections/ansible_collections Collection Version ----------------------------- ------- ansible.eda 1.3.8
ansible.eda 以外のコレクションのイベントソースを利用したいときなどは、別途イメージを用意することになると思います。
なお、eda-server のテストコードにも、Decision Environment として上記のイメージをしているような箇所がありました。
Automation Controller へのトークンの設定
事前に環境変数 EDA_CONTROLLER_URL によって、Automation Controller の URL は指定していますが、認証情報は指定していません。eda-server と Automation Controller を連携するには認証情報も必要なので設定します。
トークンの作成、取得
あらかじめ Automation Controller 側でトークンを作成、取得しておきます。
今回は awxkit の awx login コマンド でトークンを作成、取得しました。
% awx login \
--conf.host https://10.0.1.140 \
--conf.username (Automation Controllerのユーザー) \
--conf.password (Automation Controllerパスワード) -k
{
"token": "ここにトークンが表示されるのでコピーしておく"
}
これで、Automation Controller の admin ユーザーのトークン一覧画面には、以下のように Personal access token が表示されます。
他、curl で済ませる方法もあります。
参考情報: 18. Token-Based Authentication — Automation Controller Administration Guide v4.2.0
実運用上は、権限を絞るなどの工夫が必要そうです。
トークンの設定
続いて、先程取得したトークンを eda-server 側に設定します。
画面左メニューの User をクリックします。一覧にデフォルトのユーザー admin が表示されるので admin をクリックします。
Controller Tokens をクリックすると、トークン一覧画面が表示されるので、Create controller token をクリックします。
トークン設定画面が表示されるので必要事項を入力します。
| 項目 | 意味 | 今回の設定値 | 備考 |
|---|---|---|---|
Name |
トークンの設定名 | my_token01 |
|
Token |
Automation Controller にアクセスするためのトークン | (あらかじめ取得したトークン) |
入力したら、画面下部の Create controller token をクリックします。
この段階ではトークンが正しいかどうか確認する方法は無さそうです。
Rulebook Activation の作成
もろもろ作成できたので、最後に Rulebook Activation を作成します。 Rulebook Activation は Rulebook を動作可能状態にしたオブジェクトのようなもののようです。
画面左メニューの Rulebook Activations をクリックして一覧画面を開き、Create rulebook activation をクリックします。
Rulebook Acrivation 作成画面が開くので、必要事項を入力します。
| 項目 | 意味 | 今回の設定値 | 備考 |
|---|---|---|---|
Name |
Rulebook Activation の名前 | my_activation01 |
|
Project |
Rulebook があるプロジェクト | my_project01 |
事前に作成したもの |
Rulebook |
プロジェクト内の Rulebook のファイル名 | hello_jt.yml |
今回は rulebooks ディレクトリ配下 |
Decision environment |
Rulebook を実行する環境 | my_env01 |
事前に作成したもの |
入力したら、画面下部の Create rulebook activation をクリックします。
作成後の詳細画面で、Activation status が Running で、Number of Activations が 1 （作成直後は 0 なので待つ）になったことを確認します。
Rule Audit 画面にははまだ何も表示されていない状態です。
ここまでで一通り、仕組みができあがりました。
■ Webhook 経由でジョブテンプレートの実行を試す
いよいよ、 Webhook 経由でジョブテンプレートの実行を試します。
Webhook を受け付けているのは実際はコンテナ側ですが、あらかじめ「環境面の準備」で 5000:5000 の NAT を追加しているので、コンテナホスト（今回は mac）で localhost:5000 あてに実行します。
% curl -H 'Content-Type: application/json' -d "{\"message\": \"sakana\"}" localhost:5000
去年 run_playbook の action で試したときは、/endpoint が必要だった記憶がありますが、今回はなしでも動きました。
以下、動画です。（一部本記事と細かい名称などが異なります雰囲気が伝わればと）
curl 叩いて EDA Controller 経由で Automation Controller のジョブテンプレート実行できた。rulebook 側は action に run_job_template を指定。荒削りだけど雰囲気は少し掴めた。 pic.twitter.com/Va2NFE2p4J
— よこち (@akira6592) 2023年6月22日
Rule Audit には結果が表示されます。
Rule name 列の Say Hello (Rulebook の rules の name で指定したもの）をクリックすると以下のような画面が表示されます。
Actions 画面で run_job_template をクリックしたら、実行したジョブテンプレートのジョブが表示されるのが気が利いています。
もちろん、Rulebook 内の条件にマッチしないリクエストの場合は、ジョブテンプレートは実行されません。
おわりに
eda-server 経由で Automation Controller のジョブテンプレートを実行するための設定とおためしをしてみました。
ひととおり試すことで、操作感が少し掴めました。Automation Controller と概念が似ている部分もあり、そこまで苦労することはなかったです。
今回は Automation Controller との連携まで含めましたが、単独として試す場合は、Rulebook の action を run_job_template ではなく debug を利用するのが手軽です。
まだまだ、触りたてなので分からないことや、設定の詰めなどはあるかと思います。AAP 2.4 リリースによって EDA Controller のドキュメントも整備されていくと思うので、ドキュメントも読んでいきたいと思います。
