AWX(Ansible Tower)とZabbixを連携させて自動化ジョブの標準化を図ってみる
ここでは、Ansible TowerのOSS版であるAWXとZabbixを連携させて自動ジョブの標準化ができないか考えてみました。
1. 背景
Zabbixではトリガーが発生したら指定したジョブ(スクリプトなど)を実行して対処をすることができます。
自由度が高くスクリプトなどで書けば簡単に動いて便利です。
ただ、以下のような課題がありました。
- スクリプトやコーディングは利用者のスキル依存になるため言語が統一できず属人化になりがち(bashやPerlやPythonや...)
- コードの品質にも課題あり
- コードの管理方法がバラバラ(Git使う人もいればCIFSにファイルをそのまま入れてる人もいる)
- それぞれの言語で必要なモジュールが出てきてZabbixに都度インストールする必要があり、最終的に構成管理がしきれなくなる(スクリプトもZabbix/Proxy毎にどんどん入れるともはやワケワカメ)
- etc...
そこで、AWXとZabbixを連携すれば自動ジョブは標準化できないか検証してみました。
2. 使うもの
- AWX(ansible)
- Zabbix
- 自作Goツール awx-exec-job
3. 考えたこと
3-1. ZabbixとAWXを連携させるツール
3-1. ZabbixとAWXを連携させるツール
ここでは awx-exec-job というツールをGoで作ったので使用してみます。
これは、AWXのジョブテンプレート名を指定して実行するだけのツールです。
何故、Goで作ったかというとワンバイナリ化ができZabbixサーバ側には追加でモジュールをインストールしなくてもよいという点です。
例えば、運用でGoのツールを更新する場合はビルドしたバイナリを置き換えるだけで済みます。
3-2. コードの標準化
次に、それぞれの言語で作っていた処理の標準化については、Ansibleが使えるかなと思いAWXを使ってみます。
AnsibleのPlaybook(YAML)でコードを標準化しておくことでバラバラで作っていたコードを標準化できないかと考えています。
また、AnsibleはPythonで自作モジュールも作成できるため Python
と Playbook(YAML)
を覚える形かなと思っています。
3-3. 実行結果や証跡について
Zabbixでスクリプト実行の自動化はできますが、Zabbix側でわかるのはスクリプトの実行結果の戻り値が問題ないか位で失敗した時に どこでコケたか?
などがわかりません。
AWXを使う事で例え処理が失敗しても いつ実行してどこのタスクで失敗して結果はこうだった
というところまで記録に残ります。
4. 検証
ここでは、簡単なイメージがつくようにVMwareのVM再起動をしてみようと思います。
以下は検証のイメージ図です。
4-1. 検証内容
- Zabbix側でzabbix_senderを使って意図的にトリガーを発生させる
- トリガーにはAWXのジョブ(VMが再起動する)をキックするアクションを紐づけておく
- Zabbixのマクロに
AWX
AWXユーザー名
AWXパスワード
を設定しておく -
awx-exec-job
の引数には設定したマクロとextra_vars
を指定する
- Zabbixのマクロに
- トリガーが発生してアクションが実行されたことを確認する
- AWX側でも実行された確認する
- VM(ここでは
devel2
というホストを指定する)が問題なく再起動したことを確認する
4-2. 検証環境
項目 | バージョン |
---|---|
RHEL | 7.5 |
Zabbix | 3.4 |
AWX | この時点での最新版 |
awx-exec-job | 0.2 |
vCenter | 6.5 |
4-3. awx-exec-jobのインストール
(1) ここの手順を元にビルドしてZabbixサーバへコピーします。
[root@localhost ~]$ scp awx-exec-job root@zabbix34:
(2) ここでは、ツールを externalscripts
ディレクトリへ移動します。インストール場所は環境に合わせて変更します。
[root@zabbix34 ~]# mv awx-exec-job /usr/lib/zabbix/externalscripts/
(3) 動作確認用でヘルプが表示されれば問題ありません。
[root@zabbix34 extralscript]# ./awx-exec-job -h
NAME:
awx-exec-job - Tool to execute AWX job
USAGE:
awx-exec-job [global options] command [command options] [arguments...]
VERSION:
0.2
AUTHOR:
sky_joker
COMMANDS:
help, h Shows a list of commands or help for one command
GLOBAL OPTIONS:
--host value IP or HostName for AWX (default: "127.0.0.1")
--username value, -u value Login UserName (default: "admin")
--password value, -p value Login Password
--template value, -t value Specify the template name to execute
--ssl Specified only when using SSL
--extra value, -e value Specify extra vars
--help, -h show help
--version, -v print the version
4-4. Zabbixの設定
4-4-1. ホスト設定
4-4-1-1. ホスト
4-4-1-2. マクロ
マクロには以下を設定しています。
項目 | 説明 |
---|---|
{$AWX} | AWXのIPまたはホスト名 |
{$AWX_USER} | AWXへログインするユーザー名 |
{$AWX_PASSWORD} | AWXへログインするパスワード |
4-4-1-3. アプリケーション・アイテム
4-4-1-4. トリガー
4-4-2. アクション設定
4-4-2-1. アクション
4-4-2-2. 実行内容
コマンド
には以下を指定しています。
/usr/lib/zabbix/externalscripts/awx-exec-job --host {$AWX} -u {$AWX_USER} -p {$AWX_PASSWORD} -t vm_reboot -e '{"extra_vars": {"vm":"{HOST.HOST}"}}'
vm
のキーに対して動的にZabbixで設定したホスト名が入るようにしています。
4-5. AWXの設定
vm
はextra_varsから受けれるようにしています。
ここでは、vCenterの認証関係はPlaybookに記述していますが変数化して外部から受けれるよう設計するのもいいと思います。
4-5-1. Playbook
---
- name: VMware Job
hosts: localhost
gather_facts: no
tasks:
- name: "{{ vm }} reboot"
vmware_guest:
hostname: 192.168.0.253
username: [email protected]
password: secret
validate_certs: no
name: "{{ vm }}"
state: rebootguest
4-5-2. テンプレート
extra_vars
が渡せるようにテンプレートの 起動プロンプト
を有効にしておく必要があります。
4-6. 検証実行
4-6-1. トリガー実行
(1) Zabbix Senderを使って意図的にトリガーを発生します。
[root@zabbix34 externalscripts]# zabbix_sender -z 127.0.0.1 -s devel2 -k reboot_flag -o 1
info from server: "processed: 1; failed: 0; total: 1; seconds spent: 0.000070"
sent: 1; skipped: 0; total: 1
(2) Zabbixでトリガーに紐づけられたコマンドアクションが実行されていることを確認します。
(3) AWXのジョブで問題なく実行された確認します。
(4) vCenter側でVMが再起動されたことを確認します。
問題なく実行されていることが確認できました :-)
5. まとめ
- Zabbix側はAWXのテンプレートを実行するツール(Go)を入れておく事でツールの保守や構成管理の負荷が減りそう
- ジョブの処理はAnsibleのPlaybookで記述しておくことで自動化処理(スケールアウトや復旧など)のソースが標準化できそう
- 足りないモジュールはPythonで標準化することでAWXを利用する運用者は
Playbook(YAML)
と Python
を覚えればよさそう(Zabbix運用者は Go
のスキルも必要になる)
- AWXでは実行結果が記録されるので、失敗時の確認が容易にできそう
- 監査・証跡ログも残せるのでエンタープライズでも使えそう
- (ここでは出てないが)Playbookや自作モジュールはGitLabなどで管理してAWXと連携すれば管理の効率化ができそう
6. 最後に
Playbook(YAML)
と Python
を覚えればよさそう(Zabbix運用者は Go
のスキルも必要になる)awx-exec-job
はAWXのみサポートしていますが時間があればAnsible Towerもサポートできるように改修...したいな...
2018/07/14追加
HTTP BASIC認証の有効化
が オン
になっていればAnsible Towerでも動作することを確認しまいsた。
Author And Source
この問題について(AWX(Ansible Tower)とZabbixを連携させて自動化ジョブの標準化を図ってみる), 我々は、より多くの情報をここで見つけました https://qiita.com/sky_jokerxx/items/cb07773cf33e854e4af3著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .