Introduction to Tower & AWX Hideki Saito Software Maintenance Engineer@Red Hat K.K. 08/16/2018

自己紹介 • 氏名: 齊藤 秀喜 (さいとう ひでき) • TwitterID: @saito_hideki • 所属: Ansible Support Team / Red Hat K.K. • 仕事: Software Maintenance Engineer�for Ansible • 趣味: Ansible / Ansible Tower / AWX !2

本日のテーマ Ansibleを利用した自動化を統合管理するプラットフォーム「Tower」と「AWX」 について、その中核となるアーキテクチャ部分についてご紹介します。 本日お話すること: 1. 5分でわかるTower & AWX 2. Tower & AWX の概要 3. Tower & AWX の仕組み ‣ ジョブの実行 ‣ インベントリの更新 ‣ プロジェクトの更新 4. デモ !3

5分でわかる Tower / AWX 4

5分でわかるTower & AWX Red Hat Ansible Tower に興味をお持ちいただきありがとうございます。 Ansible Tower は、Ansible を装備した環境に、制御、ナレッジ、委譲機能 を追加して、チームが複雑かつ複数層のデプロイメントを管理できるように 支援する商用オファリングです。 ~ Ansible Tower ユーザーガイドより抜粋 ~ !5

5分でわかるTower & AWX ‣WebUI�/ RESTful APIで操作するAnsibleを利用した統合自動 化プラットフォーム ‣ユーザ管理・ログ管理・Playbookを利用したジョブ/ワークフロー の実行機能を提供 ‣要はAnsible Playbookを利用したジョブ管理システム ‣Ansible Towerはサポート付きのエンタープライズ版 ‣AWXはAnsible TowerのアップストリームにあたるOSS版 !6

5分でわかるTower & AWX Ansible Tower / AWX Ansible Playbook Web Browser CLI External System Launch tower-cli-library etcetera... Target SSH/WinRM/API !7 WebUI RESTful API

デモ ~Tower & AWX によるジョブ実行~ 8

デモ: WebUIからのジョブ実行 !9

Ansible Tower / AWX�の概要 10

1. WebUI / RESTful API / Callback URL を利用した外部からの制御 2. ユーザ管理機能(Active DirectoryやGoogle OAuth2等のIAMとも連携) 3. 認証情報の一元管理 4. クラウド/IaaS基盤と連携可能なDynamic Inventoryをプリセットで提供 5. Github/Gitlab などのSCMからPlaybookを取得して利用 6. 複数のジョブ(Playbook)をワークフローとして実行 7. ジョブやワークフローを指定の日時でスケジュール実行 8. ジョブの実行結果をIRCやSlackなどに送信 9. SplunkやLogstashなどの外部ロギングシステムと連携 10. コントローラのマルチノード構成 Tower & AWX の機能10選 !11

TowerとAWXの位置付け Red Hatが、エンタープライズユーザ向けに提供している自動化プラットフォーム 「Ansible Tower」 のアップストリーム版という位置付けで、Apache v2ライセンス に基づいて、これをOSS化したものが「AWX」です。 分類 アップストリーム エンタープライズ （レッドハットが提供&サポート） 自動化プラットフォーム （GUI/REST API/ 権限管理/ 実行履歴管理など） AWX Project Ansible Tower 動作エンジン （コマンド等のコア部分、
 モジュール、プラグインなど） Ansible Project Ansible Engine !12

Towerのリリース状況(v3.1) 現在サポートされているのは、v3.1.x および v3.2.x�で、それ以前のバージョンは サポートが終了しています。 v3.1系の最新版は2018-05-11にリリースされたv3.1.7です。 ’2017-02-28 v3.1.0 v3.1.1 ’2017-03-07 v3.1.2 ’2017-03-31 v3.1.3 ’2017-05-03 v3.1.4 ’2017-07-10 ’2017-09-17 v3.1.5 v3.1.6 v3.1.7 ’2017-05-07 ’2017-05-11 !13

Towerのリリース状況(v3.2) v3.2系の最新版は、2018-05-11にリリースされたv3.2.5です。 v3.3のリリースは秋頃に予定されています。 v3.2.0 v3.2.1 v3.2.2 v3.2.3 v3.2.4 v3.2.5 ’2017-10-19 ’2017-12-12 ’2018-02-20 ’2018-05-07 ’2018-05-11 ’2017-10-02 !14

AWXのリリース状況 2018-07-16にv1.0.0がリリースされました。 最新版(2018-07-22時点)は、2018-04-28にリリースされたv1.0.6です。 ’2017-08-16 v1.0.0 v1.0.1 v1.0.2 v1.0.3 v1.0.4 v1.0.5 v1.0.6 ’2017-10-11 ’2017-12-14 ’2018-02-02 ’2018-02-21 ’2018-03-27 ’2018-04-28 !15

AWXのインストール RHEL7系のOSの場合: # yum install docker python-docker-py # systemctl enable docker # systemctl start docker # git clone https://github.com/ansible/awx.git # cd awx/installer # ansible-playbook -i inventory install.yml AWXリポジトリをクローンしてから、Playbookを利用してインストール(*) *) 事前にAnsibleのインストールが必要です !16

AWXのサービスコンポーネント AWXは、コンテナ化された5つのサービスから構成されています。 Infrastructure Host OS Docker Engine Bins/Libs Bins/Libs Bins/Libs Bins/Libs Bins/Libs awx-web awx-task awx-memcached awx-rabbit postgresql !17

関連ドキュメント TowerおよびAWXに関する情報は、以下のサイトから入手することができます。 ユーザガイドや管理者ガイドなどのドキュメント類は、AWX向けとしては存在しません。 Enterprise版であるAnsible Towerのものを参照してください。 ★Source Code�(AWX) ➡ https://github.com/ansible/awx ★Install Guide (Tower/AWX) ➡ https://docs.ansible.com/ansible-tower/latest/html/quickinstall/prepare.html (Tower) ➡ https://github.com/ansible/awx/blob/devel/INSTALL.md (AWX) ★User Guide (Tower) • https://docs.ansible.com/ansible-tower/latest/html/userguide/index.html ★Administration Guide (Tower) ➡ https://docs.ansible.com/ansible-tower/latest/html/administration/index.html ★API Guide (Tower) ➡ https://docs.ansible.com/ansible-tower/latest/html/towerapi/index.html !18

機能要素 機能要素 概要 Organization 全ての機能要素を収容するグループ Project Playbookを収容するディレクトリ Credential 操作対象となるホストの認証情報(SSHユーザ・パスワード等) Inventory 操作対象となるホスト及びホストをグループ化したリスト Job Template Project(Playbook)/Credential/Inventoryから構成されるジョブ Workflow 複数のJob Templateから作られたワークフロー Job Job Template / Workflowの実行単位 User Towerの各機能要素を操作する権限を付与されたユーザ Team 複数のTeamを所属させたチーム。User同様に権限を付与可能 !19

各機能要素の関係(1) !20

各機能要素の関係(2) Projects Job templates Notifications Organizations Inventories Users Teams Groups Hosts Inventory Sources Workflow Job templates Inventory Scripts Inventory Smart Inventory Schedules Instance Groups Credential Types Credentials !21

基本的な操作の流れ (15)Finished (14)Launch "Job template" (13)Setting up RBAC (1)Create "Organization" (4)Associate "User" with "Team" (7)Create "Host" in "Inventory" (10)Create "Project" (3)Create "Team" (6)Create "Inventory" (9)Associate "Host" with "Group" (12)Setting up "Job template" (2)Create "User" (5)Create "Credential" (8)Create "Group" in "Inventory" (11)Create "Job template" !22

(1)Create Organization Organizationを作成する。 AWXの管理情報は Organization単位で管理される !23

(2)Create User Userを作成する。 !24

User Type ユーザタイプ 概要 Normal User (標準ユーザ) 一般ユーザとして、AWXのさまざまなオブジェクト(Project / Credential / Inventory / Job template など)に設定された権限にしたがって操作を実行する。 System Auditor
 (システム監査者) AWXシステムの監査を目的として、全てのオブジェクトに対する読み込み権限をデフ ォルト状態で持っている。 System Administrator (システム管理者) AWXシステム管理者として、全てのオブジェクトの管理者権限を持っている。 AWXにログインして操作するためのユーザには、ユーザタイプの中から1つを選択 して割り当てることができます。 !25

(3)Create Team Teamを作成する。 !26

(4)Associate User with Team UserをTeamに所属させて、適切な役割を設定する。 !27

(5)Create Credential Credentialを作成する。 !28

Credential Type 現時点(v1.0.6)でプリセットされている認証情報タイプは以下の通りです。 認証情報 用途 Amazon Web Services AWSとの連携に必要な認証情報(ACCESS_KEY/SECRET_KEY/STS_TOKEN) Ansible Tower Ansibleのモジュールから利用できるTower/AWXの認証情報 Google Compute Engine GCEとの連携に必要な認証情報(サービス用アカウントのEmailアドレス等) Insights Insightsと連携するための認証情報(USERNAME/PASSWORD) Machine (必須) SSH/WinRMでターゲットホストに接続するために利用する認証情報 Microsoft Azure Resource Manager Azure Resource Managerとの連携に必要な認証情報(SUBSCRIPTION_ID等) Network Ansibleから操作可能なネットワーク機器への接続に利用する認証情報 OpenStack OpenStackの認証情報(OS_USERNAME/OS_PASSWORD/OS_AUTH_URL等) Red Hat Cloud Forms CloudFormsの認証情報(URL/USERNAME/PASSWORD) Red Hat Satellite 6 Satellite 6.3以降との連携するための認証情報(URL/USERNAME/PASSWORD) Red Hat Virtualization RHEV(Ovirt)と連携するための認証情報(URL/USERNAME/PASSWORD) Souce Control Github/Gitlab等のSCMと連携するための認証情報(USERNAME/PASSWORD等) Vault Ansible Vaultを利用するために必要な認証情報(PASSWORD) VMware vCenter vCenterとの連携に必要な認証情報(HOST/USERNAME/PASSWORD) Custom Credential 利用者が独自にCustom Credential Typeとして定義した認証情報 !29

(6)Create�Inventory Inventoryを作成する。 !30

(7)Create Host in Inventory Inventory内にホストを作成する。 !31

(8)Create Group in Inventory Inventory内にグループを作成する。 !32

(9)Associate Host with Group Inventory内に作成したグループにホストを登録する。 !33

Host and Group AnsibleのInventoryファイルと同様に、AWXのInventoryにはHostとGroupを 定義します。varsパラメータも定義可能です。 Inventory {vars} host-A {vars} host-B {vars} group-A {vars} group-B {vars} host-C {vars} !34

(10)Create Project Projectを作成する。 Playbookが配置されているGithub/Gitlabなどの 外部SCMのリポジトリを指定する !35

(11)Create Job template Job templateを作成する。 Projectに指定したリポジトリ内の Playbookを指定する !36

(12)Setting up Job template Project / Credential / Inventory / Job Template に対する権限を設定する。 !37

(13) Setting up RBAC Project-A Credential-A Inventory-A Job template-A role:use role:use role:use role:execute Project/Credential/Inventory/Job template などのAWXの各オブジェクトに 対する操作権限(role)は、ユーザ毎に割り当てられますが、これを複数のユーザ を所属させたチームに対して行うことで一括設定が可能です。 Team-A foo bar baz !38

Role Type 以下のオブジェクトに対して、ロールベースの権限付与が可能です。 オブジェクト 権限 Project • Admin => 使用権限 / 編集権限 / SCMのリポジトリの同期権限 • Use => 使用権限 • Update => SCMリポジトリの同期権限 • Credential • Admin => 使用権限 / 編集権限 • Use => 使用権限 Inventory • Admin => 使用権限 / Dynamic Inventoryの同期権限 / Ad Hocコマンド実行権 限 • Use => 使用権限 • Update => Dynamic Inventoryの同期権限 • Ad Hoc => Ad Hocコマンド実行権限 Job template • Admin => 実行権限 / 編集権限 • Execute => 実行権限 !39

Role Type 以下のオブジェクトに対して、ロールベースの権限付与が可能です。 オブジェクト 権限 Organization • Admin => 使用権限 / 編集権限 / SCMのリポジトリの同期権限 • Use => 使用権限 • Update => SCMリポジトリの同期権限 • Credential • Admin => 使用権限 / 編集権限 • Use => 使用権限 Inventory • Admin => 使用権限 / Dynamic Inventoryの同期権限 / Ad Hocコマンド実行権 限 • Use => 使用権限 • Update => Dynamic Inventoryの同期権限 • Ad Hoc => Ad Hocコマンド実行権限 Job template • Admin => 実行権限 / 編集権限 • Execute => 実行権限 !40

(14)Launch Job template Job Templateを実行する。 !41

(15)Finished Jobの実行結果を確認する。 ansible-playbookコマンドの実行結果は Live Eventとしてリアルタイム出力 ansible-playbookコマンドの実行結果を テキストファイルとしてダウンロード可能 !42

RESTful API / CLIを利用する Web Dashboardによる操作だけでなく、M2MインターフェイスとなるAPIを提供 しています。 このAPIを利用したコマンドラインインターフェイス(tower-cli)も、オープンソース プロジェクトとして提供されています。 • RESTful API - https:///api/v2/ でAPIにアクセス可能 - 利用方法はAPIガイドを参照してください - https://docs.ansible.com/ansible-tower/latest/html/towerapi/index.html • tower-cli - AWXが提供するAPIを利用したAWXのコマンドラインインターフェイス - ソースコード - https://github.com/ansible/tower-cli/ - ドキュメント - https://docs.ansible.com/ansible-tower/latest/html/towerapi/tower_cli.html !43

Tower / AWXの仕組み 44

Tower/AWXのサービス は、以下のようなOSSプロダクトを利用して実装されています。 Tower v3.1/v3.2の場合は、Towerサーバ上でsystemd/supervisordを利用 して直接起動します。 OSS 役割 Docker AWXの各サービスをコンテナとして起動する (AWXのみ) Django WebUI / RESTful APIを提供するためのフレームワーク Nginx WebUI / RESTful APIを提供するためのフロントエンドサービス PostgreSQL 設定情報や、インベントリ、ジョブの実行結果を格納するデータベース RabbitMQ ジョブスケジューラが利用するメッセージキューを管理する Celery RabbitMQと連携するAMQPワーカー Memcached Live EventやLogging Aggregator用の一時データストア Supervisord Celery / uwsgiなどのサービスをデーモンとして起動する Ansible Tower/AWXが実行するジョブのエンジン部分を担う !45

AWXコンテナ Infrastructure Host OS Docker Engine Bins/Libs Bins/Libs Bins/Libs Bins/Libs Bins/Libs awx-web awx-task awx-memcached awx-rabbit postgresql クラスタ構成の場合は のコンポーネントが新たに起動してスケールアウトを実現 AWXは、前述のOSSをいくつかのサービスの役割毎にまとめて、5つのコンテナを Dockerを利用して起動します。 !46

Towerの構成図 スケールアウト可能 Databaseサーバ Towerサーバ !47

AWXの構成図 awx-web awx-memcached awx-rabbit awx-task postgresql スケールアウト可能 (*)現時点ではスケールダウン には手間がかかります !48

AWXコンテナの役割(1) awxのサービスを提供する各コンポーネントの役割は以下の通りです。 •awx-webコンテナ - 利用者へのフロントエンドサービス(Web Dashboard / RESTful API)を提供 - Supervisordを利用してNginxとuwsgiを利用したフロントエンドサービスを起動 •awx-memcachedコンテナ - AWXの他のコンポーネント向けにMemcachedサービスを提供 - ジョブの結果をLive EventでWebクライアントに提供したり、外部ロギングシステムに実行結果を 転送するために一時利用される !49

AWXコンテナの役割(2) •awx-rabbitコンテナ - フロントエンドから送られたAMQPメッセージをハンドリングするAMQPサービスを提供 - ジョブの起動やイベントの処理、バックグラウンドプロセス、WebSocketの処理に利用 - K8SやOpenShiftでawxサービスのpodを増やすと自動でRabbitMQクラスタに追加される •awx-taskコンテナ - AWXの中枢として、awx-rabbitからメッセージを取得して、プロジェクトの管理やジョブの実行を 担うサービス群をSupervisordを利用して起動 - 自動化のエンジンとなるAnsible(ansible-playbookコマンド)は、このコンテナで実行される - Ansibleの実行環境は、Pythonのvirtualenv上に配置(venv/ansible, venv/awx) されている - Github / Gitlab などのSCMからチェックアウトしたPlaybookが配置される •postgresqコンテナ - AWXの設定情報を保存する構成管理データベース - ジョブテンプレートの設定、インベントリ情報や全てのジョブの実行情報(Playbookの出力など)、 Tower/AWXが保持するほぼ全ての情報が保存されている !50

Tower / AWXの仕組み ~ ジョブの実行 ~ 51

Ansible Tower / AWS Job実行の流れ:概要 Credential SCM
 Update Inventory
 Update Job template Project Inventory Job Jobとしてansible-playbookコマンドを実行する この実行環境が、TowerとAWXでは違います (1) (2) (2) (2) (3) (3) (4) (5) (1)WebUI/API経由でJob templateを起動 (2)Project / Inventory を更新。Credentialを取得 (3)SCMからリポジトリ取得。Inventory情報を更新 (4)Job templateからJobを生成 (5)実行環境を生成してansible-playbookを起動 !52

ジョブの実行環境 Ansible Tower/AWXのジョブ実行環境は、Pythonのvirtualenvを利用して 実現されています。 このvirtualenvは�"--system-site-packages"�で作成されています。 System wide ジョブ実行環境 (/var/lib/awx/venv/ansible/) Tower/AWX自身の実行環境
 (/var/lib/awx/venv/awx/) Ansibleや、その他のPythonモジュール群 Ansibleモジュールが必要とする Pythonモジュール群 Tower/AWXが動作するために 必要とするPythonモジュール群 !53

Ansible TowerとAWXの違いは、コントローラの実行環境の違いによる、ジョブの実 行環境にあります。 Towerは、bubblewrapを利用してジョブ毎に隔離環境を作り、その中にジョブ実行 環境を閉じ込めるので、より安全にジョブの実行が可能です(Job isolation機能)。 一方で、コンテナ環境で動作することを想定しているAWXでは、現状、この実行環境 の隔離機能が無効化されています。 Ansible Tower namespace namespace namespace TowerとAWXの違い(1) AWX !54

TowerとAWXの違い(2) Ansible Tower/AWXでは、マルチリージョンでのクラスタ構成をサポートして いませんが、リージョン毎にジョブの実行のみを行う「Isolatedノード」を構成す ることができます。この機能は、現状AWXではサポートされていません。 Sapporo Osaka Fukuoka Tokyo Tower Isolated Node Isolated Node Isolated Node SSH !55

Instance Group マルチノードクラスタでは、複数のインスタンスから構成された、インスタンス グループにジョブの実行を割り当てることができます。実行前に、実際にジョブ を実行するために必要なキャパシティが計算され、そのキャパシティを許容でき るインスタンスでジョブを実行します(インスタンス数は最大20)。 !56 IG: tower (default) IG: west IG: east instanceA instanceB instanceC Job (1) Job (2) Job (3) Job (4) Job (5) instanceA instanceB instanceC

Provisioning Callback ジョブテンプレートのProvisioning Callback機能を有効化することで、外部か らジョブを起動することができます。 !57 Tower / AWX Inventory hostA (1) (2) (3) (4) Job Job template CallbackURL (1) hostAからCallbackURLにリクエスト送信 (2) インベントリ内にhostAが存在することを確認 (3) Jobを起動(LIMITとしてhostAを指定) (4) hostAに対してJobのPlaybookを適用

Output from Job ansible-playbookコマンドでは、Playbookの実行結果は標準出力に出力され ます。Tower/AWXでは、この標準出力の情報が1つのファイルとしてファイル システムに、各イベントの情報がデータベースとmemcachedに出力されます。 !58 ジョブの実行結果 /var/lib/awx/job_status/ Filesystem Database memcached Job

Job template and Credentials Tower/AWXがジョブテンプレートから利用するAnsibleのPlaybookは、さま ざまなモジュールから構成されています。 認証を必要とするクラウドを操作するようなモジュール群は、その下請けにヘル パーモジュールを持っていおり、認証プロセスに必要な情報を取得しています。 Tower/AWXでは、この仕組みを利用して、ジョブ実行に必要となる認証情報 を引き渡しています。(全てのモジュールに対応しているわけではありません) !59 モジュール (例: modules/clouds/openstack/os_auth.py) ヘルパーモジュール (例: module_utils/openstack.py) 認証情報をPlaybook実行環境の 環境変数やファイルにセット (例: OS_CLIENT_CONFIGとclouds.yml)

ジョブの並列実行 Tower/AWXでは、ジョブテンプレートを並列実行することも可能ですが、以下 のような制約があります。 1. プロジェクト/インベントリの更新は、それを利用している全てのジョブの実行 をブロックします 2. ヒストリの削除などを行う管理ジョブ(System Job)の実行中は、他の通常 ジョブの実行をブロックします 3. キャパシティに余裕がある場合は、インスタンスにジョブが割り当てられます が、上記のブロック状態である場合は、実行待ちステータスとなります。 4. Ad-hocジョブは、インベントリのグループ/ホストに対して実行されるため、 インベントリの更新中は実行がブロックされます !60

Tower / AWXの仕組み ~ インベントリの同期 ~ 61

Dynamic Inventory(1) Tower/AWXには、Ansibleで言うところの静的なインベントリは存在せず、ジョブの 実行時に、ダイナミックインベントリスクリプトを実行し、インベントリ情報を動的に取得 します。取得した情報は、構成管理データベースに保存されます。 Ansible Tower/AWX Tower / AWX CMDB(PostgreSQL) SCM repository External system AWS/GCE/Azureなどのクラウドや、OpenStack/RHEV/VMware vCenterなどの IaaS基盤、Red Hat SatelliteやInsightsなどの管理システムなどの外部の管理基盤 からインベントリ情報を取得することができます。 !62 DB

ec2.ini Dynamic Inventory(1) ~ Amazon EC2 ~ Ansible Tower/AWX AWS 環境変数 (1) (3) (4) (1) 認証タイプ:Amazon EC2の認証情報を環境変数に設定 - AWS_ACCESS_KEY_ID - AWS_SECRET_ACCESS_KEY - AWS_SECURITY_TOKEN - EC2_INI_PATH (2) インベントリソースの"SOURCE_VARIABLES"に設定された パラメータを元に"ec2.ini"を生成する (3) ダイナミックインベントリ"ec2.py"を利用してAPIリクエスト (4) ホストリストを取得し、Towerのデータベースにインポート インベントリ 認証情報 !63 (2)

vmware_inventory.ini Dynamic Inventory(2) ~ VMware vCenter ~ Ansible Tower/AWX AWS 環境変数 (1) (3) (4) (1) 認証タイプ:Amazon EC2の認証情報を環境変数に設定 - VMWARE_USER - VMWARE_PASSWORD - VMWARE_HOST - VMWARE_VALIDATE_CERTS - VMWARE_INI_PATH (2) インベントリソースの"SOURCE_VARIABLES"に設定された パラメータを元に"vmware_inventory.ini"を生成する (3) ダイナミックインベントリ"vmware_inventory.py"を利用し てAPIリクエスト (4) ホストリストを取得し、Towerのデータベースにインポート インベントリ 認証情報 !64 (2)

vmware_inventory.ini Dynamic Inventory(2) ~ OpenStack ~ Ansible Tower/AWX AWS 環境変数 (1) (3) (4) (1) 認証タイプ:OpenStackとして設定した認証情報から生成す る"clouds.yml"ファイルのパスを環境変数に設定する - OS_CLIENT_CONFIG_FILE (2) インベントリソースの"SOURCE_VARIABLES"に設定された パラメータと認証情報を元に"clouds.yml"を生成する (3) ダイナミックインベントリスクリプト("openstack.py")を利用 してAPIリクエスト (4) ホストリストを取得し、Towerのデータベースにインポート インベントリ 認証情報 !65 (2)

Tower / AWXの仕組み ~ プロジェクトの同期 ~ 66

SCM update(2) Tower/AWXがジョブとして実行するPlaybook群は、外部のSCMのリポジトリに配置 されることを想定して設計されています。 Ansible Tower/AWX Towerでは、Towerサーバ上の$PROJECTS_ROOT(/var/lib/awx/projects/)に、 AWXでは、awx-tasksコンテナの＄PROJECTS_ROOTチェックアウトされます。 !67 PROJECT /var/lib/awx/projects/ External SCM git subversion mercurial Red Hat Insights

SCM update(2) Ansible Tower/AWX SCM (1) (2) (3) (1) Privateリポジトリの場合は、指定された認証情報 を取得する (2) プロジェクトに設定したパラメータをvarsに設定し、 プリセットされたPlaybook(project_update.yml) を実行する (3) SCMからソースコードをチェックアウトする。チェック アウトしたコードに、requirements.ymlが存在した 場合は、ansible-galaxyコマンドを実行してroleを 取得する。 認証情報 !68 Playbook /var/lib/awx/projects/%PROJECT% (3)

まとめ 69

·ͱΊ Ansibleは、シンプルで強力な自動化ツールです。しかし、シンプルであるために、あ えて実装していない、さまざまな機能があります。 Ansible Tower/AWXは、Ansibleを自動化のエンジン部分として利用することで、 自動化の根幹となるPlaybookなどの仕組みをシンプルなまま維持しつつ、モダンな Web UIやRESTful APIを提供することで、人だけではなく外部システムからの利用を 想定した機能を補完しています。 みなさんも、Ansible Tower/AWXを利用して、Ansibleで蓄積した自動化のノウハウ を利用して、さらなる自動化向けた一歩を踏み出してみませんか？ !70

ありがとうございました :) 71