Ansible AWXを導入してみた

Ansible AWXを導入してみた
Ansible Night in Nagoya 2019.02
#ansiblejp
アビームシステムズ株式会社
後藤卓
山口大地

アジェンダ
1. 自己紹介
2. Ansible AWXとは？
3. AWX導入システム
4. AWXを導入した目的
5. AWX導入方法
6. AWX導入で苦労したこと
7. AWXを使った今後
8. 最後に

自己紹介
1. アビームシステムズについて
2. 発表者について

© 2019 ABeam Systems Ltd.3
アビームシステムズについて（会社概要）

アビームシステムズについて（当社のDNA）

発表者について
• 後藤卓（Goto Suguru）
• クラウド系インフラ担当
➢ AWSで稼働するシステムの設計、構築、保守、運用
➢ Ansibleやスクリプトによる自動化を進めてます（主には保守、運用面）
• Ansible歴 2年
➢ 最近は “手順書を書く量＜＜＜ Playbookを書く量” → Ansibleおじさん化
• 山口大地（Yamaguchi Daichi）
• サーバ系インフラ担当
➢ 物理（サーバ、ストレージ、電源、バックアップ）、仮想（VMWare）、AWS関連
➢ 最近はDockerに傾倒。Kubernetesやりたい
• 本発表では主にインフラ基盤側を担当
• Ansible歴 0年

Ansible AWXとは？
1. 概要
2. アーキテクチャ
3. AWXの階層構造
4. こんなことが出来る ≒ Ansibleでは出来ないこと

Ansible AWXとは？（概要）
• Ansible AWX
• AWX provides a web-based user interface, REST API, and task engine built on
top of Ansible. It is the upstream project for Tower, a commercial derivative of
AWX.
• AWXはAnsible上に構築されたWebベースのユーザーインターフェース、REST API、および
タスクエンジンを提供します。これは、AWXの商用派生物であるTowerの上流プロジェクトです。
（日本語機械翻訳）
引用元： https://github.com/ansible/awx

• Ansible Tower
• Red Hat® Ansible® Tower helps you scale IT automation, manage complex
deployments and speed productivity. Centralize and control your IT infrastructure
with a visual dashboard, role-based access control, job scheduling, integrated
notifications and graphical inventory management. And Ansible Tower's REST API
and CLI make it easy to embed Ansible Tower into existing tools and processes.
• RedHat®Ansible®Towerは、ITの自動化を拡大し、複雑な展開を管理し、生産性を向上させる
のに役立ちます。ビジュアルダッシュボード、ロールベースのアクセス制御、ジョブスケジューリング、
統合通知、グラフィカル在庫管理を使用して、ITインフラストラクチャを一元管理します。
また、Ansible TowerのREST APIとCLIにより、Ansible Towerを既存のツールやプロセスに簡単に
組み込むことができます。
（日本語機械翻訳）
引用元： https://www.ansible.com/products/tower

• つまり、Tower と AWX は、どう違う？
※Red Hat Enterprise Linux と Fedora の関係性（アップストリーム版）といえば分かりやすいかも
※だいぶざっくりした解釈です
本日の発表は AWXで出来ること ≒ Towerで出来ることと置き換えできると思います。
ただし ”完全にイコールではない” ので、導入時は ”要検証” でお願いします。
Ansible Tower = 商用
Ansible AWX = OSS (Apache v2)

Ansible AWXとは？（アーキテクチャ）
• Ansible AWXのアーキテクチャ (Dockerの場合)
※AWXはコンテナ前提、Towerはコンテナ以外も選択可能です。
Infrastructure
Host OS
Docker Engine
memcachedawx_task awx_web awx_rabbitq postgres

• こんな感じに動いています
• docker psコマンドの実行結果

• 稼働しているコンテナの詳細
コンテナ名役割
awx_task
• AWXの中核
• rabbitmqからのキューを受けて実行（ansible-playbook等）
• Ansibleの実行環境はPythonのvirtualenv上に配置される
• SCMからチェックアウト、もしくは手動で配置したPlaybookは、本コンテナ上に配置される
awx_web • フロントエンドを提供（Web UI / RESTful API）
awx_rabbitmq • フロントエンドからのメッセージをハンドリング（ジョブ起動など）
postgres
• Ansible AWXの設定情報が保存される領域
• データ保持の観点ではここを守る必要がある
memached
• AWX以外のコンポーネント向けにmemcachedサービスを提供
• ジョブの実行結果を転送する際など、一時領域として利用される

Ansible AWXとは？（AWXの階層構造）
• Ansible AWX（Tower）の階層構造
引用元： https://docs.ansible.com/ansible-tower/latest/html/userguide/organizations.html

• Organizations（組織）
• ジョブを実行するための構成要素（※）を
まとめて管理する単位
※プロジェクト、インベントリ、認証情報など

• Inventories（インベントリ）
• AWX（Tower）からジョブを実行する先とな
るホストの情報、変数（ホスト変数）を管理
• ホストへの認証情報はCredentialsで管理
• クラウドサービス（AWSやAzure等）との
連携も可能（動的インベントリ）

• Teams（チーム）
• Organizationよりも小さい組織管理単位
• 開発、保守、運用チーム等で分けて作成
• Credentials（認証情報）
• AWXで管理するホスト、他サービス（AWS等
）へ接続するための認証情報を管理
• Users（ユーザー）
• LDAP, AD連携可能！

• Projects（プロジェクト）
• Playbookを管理する単位
• Playbookは手動配置か、SCM（Git等）
との連携
• Job Templates（ジョブテンプレート）
• ジョブを実行するために必要な情報を定義
（Playbook, インベントリ、認証情報 etc）

• Jobs（ジョブ）
• ジョブテンプレートを元に生成された
実行情報、実行結果

Ansible AWXとは？（こんなことが出来る ≒ Ansibleでは出来ないこと）
• AWXで出来ること
• AWXではITインフラを統合管理するための機能が実装されている
• ダッシュボードによる可視化
• アクセス制御
• ジョブスケジューリング
各機能の概要は次ページ以降で説明

Ansible AWXとは？（こんなことができる≒Ansibleではできないこと）
• ダッシュボードによる可視化
➢対象ホストやインベントリー、最近使用したジョブなどが表示
➢Playbook（ジョブ）の実行結果
➢ 実行されたテンプレートのグラフ化
➢ ホスト、ジョブテンプレート毎でも実行結果も確認可能
➢モダンなUI！日本語UI！

ダッシュボードによる可視化
※v2.1.2 の画面です
【一例】ダッシュボード（トップページ）

• アクセス制御
➢ロールベースアクセス制御（RBAC）
➢ロール単位で設定し、特定ユーザしか触れないサーバなどに対してジョブ実行権限有
無を付与する、等
詳細は後ほど説明します！

• ジョブスケジューリング
➢定期的に実行したいジョブなどをスケジューリング
➢ジョブの集中管理

ジョブスケジューリング
利用ケース
• 定期的に実行したいジョブ
• 夜間休日に実行したいジョブ
※画像はデフォルトで作成されるAWXメンテ
ナンスジョブです

AWX導入システム
1. AWXを導入したシステムの概要

システム概要
• サーバ構築自動化システム
• 構築、テストの自動化
• 申請書の電子化
構築した目的
• サーバ構築作業を標準化、品質の均一化
• 自動化により、以下を実現
• サーバ構築作業のリードタイムの削減
• サーバ構築作業の固定費削減
将来的な構想
• CI/CD基盤として活用
• Infrastructure as Code
• 自動化対象の拡大
（VMware, Network…）

システム概要
構築した目的
将来的な構想
構築するサーバ（EC2）
Windows Server
RHEL

システム概要
構築した目的
将来的な構想
Role数：26
Task数：95
→ まだまだ開発中！

AWXを導入した目的
1. 何故AnsibleではなくAnsible AWXを選択したか？

AWXを導入した目的
• 何故Ansible AWXを選択したか？
⇒ Ansibleではできないことを実現するため
保守・運用の現場の負荷を軽減したい
• 一時的なエラーでジョブが失敗した場合など、GUIから再実行
するだけでリカバリ対応をしたい
• 自動化した作業のサービス化（誰でも利用できるように…）
アクセス制御を実施したい（将来的に）
• 実行先のサーバによっては、アクセス権限を譲渡してもらえない
• AWXのリソース（認証情報）に対してロールベースの
アクセス制御が可能
GUIがあることによる心理的安全性の確保
• CUIはちょっと・・・という人を納得させ、自動化を推進するため
• モダンなUIを使いたい！
Playbookの実行履歴をチェック/記録したい
• 内部統制として実行履歴の保存が必要
（自動化する場合は特に）
• サーバーにログインすることなく、ログ（実行履歴）を確認可能

AWX導入方法
• 前提条件の確認（GitHubより一部抜粋）
• AWX導入前提となる以下M/Wをサーバ上にインストール
• Ansible Requires Version 2.4+
• Docker
• docker-py Python module
• GNU Make
• Git Requires Version 1.8.4+
• Node 8.x LTS version
• NPM 6.x LTS
• システム要件のチェック
• At leasts 4GB of memory
• At least 2 cpu cores
• At least 20GB of space
• Running Docker, Openshift, or Kubernetes
• If you choose to use an external PostgreSQL database, please note that the minimum version is 9.4.
引用元： https://github.com/ansible/awx/blob/devel/INSTALL.md
結構、スペックが必要
重要！
AWXはコンテナ環境必須のため、
最低限のコンテナ知識が必要になります

AWX導入方法
• Docker環境で導入する
（※弊社が実施した手順です。Openshift、Kubernetes環境は別途Install Guideをご確認ください。）
1. GitHubのAWXをgit clone
2. 「installer/inventory」ファイルのカスタマイズ（弊社で採用している変更の代表例）
• docker-composeを利用（docker_compose_dir）
• proxy設定を入力（http_proxy, https_proxy, no_proxy）
• PostgreSQLのデータ保存先を変更（postgres_data_dir）
3. 以下コマンドを実行！
• $ cd installer
• $ ansible-playbook -i inventory install.yml
4. PlaybookがうまくいけばOK！
• （実際にはプロキシ環境下の場合にプロキシが突破できない等、さまざまな理由でPlaybook実行がこけます・・・）
簡単だよ！

AWXの便利なところ
1. ジョブテンプレート
2. ジョブの詳細ビュー
3. アクセス制御

AWXの便利なところ（ジョブテンプレート）
• 「起動プロンプト」を有効化すれば、実行時に
各設定項目を動的に変更できる
• REST API経由、JenkinsのPlugin経由で
実行する場合などに便利
• 制限（limit）で、実行するホストを制御している

• 追加変数（extra-vars）も動的に変更すること
ができる
• 導入したシステムでは、構築するサーバに変数を
与えて制御する仕組みに利用

ジョブの実行完了後、通知を送信することも可能
通知先：メール、Slack、Webhook、IRC etc...

• Ansible時代の苦労
ansible-playbookコマンドを実行するための
ラップシェルを用意していた
（増え続けるラップシェル・・・）
（直感的に理解できない・・・）
作業者に ansible-playbook コマンドを実行さ
せる（してもらう）ことは、中々難しい・・・。
→ コマンドを実行することに自体に抵抗がある
→ 実行するホスト、Playbookを間違えるリスクがある

複数のジョブテンプレートを組み合わせた “ワークフローテンプレート” もあります
ワークフローは、GUIでクリックしていくだけで作成可能！
ジョブテンプレート
（先行ジョブが成功時に実行）
（先行ジョブが失敗時に実行）

AWXの便利なところ（ジョブの詳細ビュー）
ジョブ：ジョブテンプレートを元に生成された実行情報
• ジョブの実行結果がGUIで！リアルタイムで確認可能！
（CUIはちょっと・・・という人にも優しい）
• 各タスクの結果（ok, changedなど）をクリック
すると、デバッグモードで出力されるような
実行結果が確認可能
• デバッグモードで実行しなくても、簡易的な
デバッグが可能！開発がすごく楽！
• Ansible時代の苦労
実行ログ（標準出力）を残したい、という要望があり
ansible-playbookコマンドを実行するためのラップシェル
を作成し、Ansibleの標準出力をログファイルにリダイレク
トで出力していた
（ok, changedの色分けが消えてしまう・・・）

AWXの便利なところ（ジョブの詳細ビュー）
ジョブ：ジョブテンプレートを元に生成された実行情報
• ジョブの実行結果がGUIで！リアルタイムで確認可能！
（CUIはちょっと・・・という人にも優しい）
• 各タスクの結果（ok, changedなど）をクリック
すると、デバッグモードで出力されるような
実行結果が確認可能
• デバッグモードで実行しなくても、簡易的な
デバッグが可能！開発がすごく楽！
• Ansible時代では・・・
実行ログ（標準出力）を残したい、という要望があり
ansible-playbookコマンドを実行するためのラップシ
ェルを作成し、Ansibleの標準出力をログファイルにリダ
イレクトで出力していた
（ok, changedの色分けが消えてしまう・・・）
モジュールが返す戻り値を確認可能！

AWXの便利なところ（アクセス制御）
• Ansibleでは・・・
• 主な機能は「インベントリファイルで指定された対象ホストへ、Playbookで定義した操作を実行する」こと
• アクセス制御等はなく、複数ユーザーでの使用は考慮あまりない・・・
➢ OSの実行ユーザで分ける等、工夫が必要
• Ansible AWXでは・・・
• ロールベースで権限を分けることが可能！
➢ 例えば管理者権限ロール、閲覧者用ロール、特定ジョブだけ実行できるロール、等
• Organaization（組織）、Team（チーム）、User（ユーザ）の３段階構造で設定可能！
• 組織内にAnsibleを展開していくためには、必須の機能

• アクセス制御の構造
以下の３構造で構成
• Organizations
• Teams
• Users

• アクセス制御の具体例
組織A
組織B
別組織のジョブテンプレートを
実行できない状態に設定
（もちろん、参照も不可）
※パーミッションを設定すれば、他組織のジョブテンプレートでもアクセス、利用が可能

• アクセス制御の具体例
組織A
組織B
別組織のジョブテンプレートを
実行できない状態に設定
「認証情報」の場合・・・
【別組織から ID/Password を覗き見されない！】
【登録したPasswordは管理者も閲覧不可！】
ちなみに、認証情報（Credentials）をAWXに登録しても、
ID/Passwordなどは暗号化されてDBに保管される。
※パーミッションを設定すれば、他組織のジョブテンプレートでもアクセス、利用が可能

指定した組織だけが参照、設定可能
暗号化されているため、パスワード参照不可
• 「認証情報」での設定例
組織内で細かいアクセス制御をする場合は
「パーミッション」を使用する
【参考】「認証情報タイプ」の種類
• AWS
• Azure
• GCP
• VMWare vCenter
• ホストOS
• NW機器 etc…

【参考】
「認証情報タイプ」の種類
• AWS
• Azure
• GCP
• VMWare vCenter
• ホストOS
• NW機器
他にも諸々・・・
指定した組織だけが参照、設定可能
暗号化されているため、パスワード参照不可
• 「認証情報」での設定例
更に細かい制御をする場合は
「パーミッション」を使用する• Ansible AWX導入の決め手となったのが「アクセス制御機能」
➢ 組織内にAnsibleを展開していくためにも、
機密性の高い情報の権限分離は必須
• Ansible時代の話
➢ Ansible Vaultを使用した暗号化ではダメだったのか？
Ansibleサーバー上に認証情報を定義したファイルを
配置すること自体が問題で、特定のチームでしか
Ansibleの利用が進まなかった・・・

AWX導入で苦労したこと
1. 導入
2. 運用
3. AWX
4. Docker

AWX導入で苦労したこと（導入）
• 導入時に苦労したこと
• プロキシ環境下だと、プロキシが突破できない・・・
• AWXだけではなく、Docker側のプロキシ設定も必要
• 原因がAWXなのか、Dockerなのか・・・知識が足りなかったときは、切り分けが大変でした
• Ansible AWXインストール用Playbookを実行して、失敗・・・
• 現状、以下の環境でうまくいっています。各リポジトリのバージョン差異による非互換（相性）の問題と推測
• yum：docker-ce
• pip：docker-py

AWX導入で苦労したこと（運用）
• 運用面で苦労したこと（苦労していくであろうこと）
• Playbookの管理やメンテナンスのCIを、どう回していくか？
• （まだ結論出てません・・・）
• コンテナが死んだとき（Container is Dead!）の対応をどうするか？
• （まだ結論出てません・・・）
• 将来的にはKubernetesを代表とするコンテナオーケストレータを利用し、自動復旧させたい
• 現行は手動で再立ち上げ（またはコンテナ停止時に自動実行するスクリプトを作成、等）

AWX導入で苦労したこと（AWX）
• AWX用のドキュメントは存在しない！
• Tower用のドキュメントを参照して ”大半はなんとかなっている” 状況・・・
➢ しかし、Tower と AWX は少なからず差異があるため、想定していないバグ、仕様の違いによる
苦労が発生することもあり得る・・・？
• AWXはサポートがない！（OSSなので、当然ですが・・・）
• バグに直面した場合、商用サポートやパッチの提供が無いため、解決不可
➢ バージョンアップで対応されるまで、解決できない・・・
• 致命的ではないが、2つのバグに遭遇しました（v2.1.2では解消されていました！）
• 本番環境で利用するには覚悟が必要
➢ 弊社環境はユーザ利用が少ないため、“なんとかなる範囲”と捉えている（現時点では）

AWX導入で苦労したこと（AWX）
• 一部のAnsibleモジュールが動作しない！
• ジョブテンプレート実行！ ⇒ Python 「Module not Found・・・」
➢ awx_taskコンテナ上のvirtualenv(ansible)に、モジュールを動かすための前提パッケージを追加
➢ しかし、コンテナを作成するたび（バージョンアップ対応等）にインストールしないといけない問題に派生
➢ コンテナ作成後に、自作のセットアップスクリプトを実行して解決
➢ 他に素晴らしい解決方法があれば、ぜひ教えてください・・・(初めから入っていると、なおうれしい)
• botoを利用したAWS系のモジュール（boto3利用モジュールでは発生せず）が動作しない・・・
➢ shellモジュールでAWS CLIを実行する設計に変更して解決（べ、冪等性・・・）
• AWSとのインベントリ同期ができない！
• 原因不明のエラーが発生、未だに未解決・・・
➢ （これもboto関係・・・？NW環境の問題・・・？）

AWX導入で苦労したこと（Docker）
• 5つのコンテナの管理、どうしよう・・・？
• 5つのうち、１つのコンテナが予期せぬ停止した場合、コンテナ起動の順序関係はあるのか・・・？
➢ 全コンテナを再立ち上げすることにした（潔く・・・？）
➢ AWXのように複数コンテナが稼働する場合は、docker-compose化した方が管理面で楽です
➢ 更に言うと、OpenShift や Kubernetes といったコンテナオーケストレータを利用するべき
• コンテナの監視、どうしよう・・・？
• ZabbixのDockerプラグインで収集することにした
➢ CPU、メモリ、N/W IO、Disk I/Oを取得
• ログはfluentdで集約
➢ fluentdもコンテナで起動
➢ Dockerコンテナはデフォルトでfluentd driver搭載
➢ 現状は集約しているだけのため、集約したログを “どう見ていくべきか” を考えないといけない

AWX導入で苦労したこと（Docker）
• AWXのバージョンアップ、どうしよう・・・？
• Ansible AWXは開発が盛んなため、更新頻度が高い（およそ２週に１回ぐらい）
➢ 2019/1/23に3.0.0リリース
• DockerコンテナなのでDocker Hub上に公開されているイメージのバージョンを指定可能
➢ v2⇒v3のメジャーバージョンアップだったが、awx_webとawx_taskのコンテナイメージタグを変更しただけで、
バージョンアップ完了＆簡易テスト問題なし！
➢ 詳細テストは別途検討中
• Postgresのバックアップ、どうしよう・・・？
• docker execコマンドを利用してdumpを実行することにした
• バージョンアップでテーブル構造が変更されているような挙動も確認
➢ 元のバージョンに戻したいときはdumpファイルからリストアが必要
➢ データ保持は必須

AWXを使った今後
1. 展望/野望

AWXを使った今後（展望/野望）
1. Ansibleの啓蒙
• AWXのUIを利用し “コードに拒否感を覚える運用者” にもAnsibleのいい点を伝えていく
• 組織として “Uncomfortable” な作業を無くす（もしくは自動化する）
2. 特権環境の自動化、コード化（自動化範囲の拡大）
• アクセス制御機能を活用し、NW機器のenable、ドメインアドミニストレーター等の
特権領域にもAnsibleを活用していく
3. 名古屋圏内ユーザコミュニティの活発化
• ゆくゆくは名古屋圏内のエンジニアだけでAnsible Nightの活動ができるようにしていく

AWXを使った今後（展望/野望）
• 今後の展望/野望
1. Ansibleの啓蒙
• AWXのUIを利用し、コードに拒否感を覚える運用者にもAnsibleのいい点を伝えていく
• 組織として、“Uncomfortable” な作業を無くす（もしくは自動化する）
2. 特権環境の自動化、コード化
• アクセス制御機能を利用し、NW機器のenable、ドメインアドミニストレータ等の特権領域にもAnsibleを活
用していく
3. 名古屋圏内ユーザコミュニティの活発化
• ゆくゆくは名古屋圏内のエンジニアだけでAnsible Nightの活動ができるようにしていく
AnsibleやAWXを活用し、
東京に負けず、
名古屋でよいエンジニアライフを
すごしましょう！

最後に
• アビームシステムズでは一緒に働ける方を募集しています！
• 詳細は以下をご参照ください。インフラエンジニア、ソフトウェアエンジニア問わず、募集中です！
• http://www.abeam-s.com/career/

アビーム、ABeam及びそのロゴは、アビームコンサルティング株式会社の日本その他の国における登録商標です。
本文に記載されている会社名及び製品名は各社の商号、商標又は登録商標です。

Ansible AWXを導入してみた

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Ansible AWXを導入してみた

Similaire à Ansible AWXを導入してみた (20)

Dernier

Dernier (9)

Ansible AWXを導入してみた