Ansible 2.5 Ansible Documentation 日本語訳

※ちまたにあふれた記事を参考に適当にAnsibleを使っていると、なんでこのファイル構成だとうまくうごくの？とか細かい部分でいろいろと疑問が生じたため、一度しっかりリファレンスの読み解きをしようと思い、ゆっくりと翻訳を進めています。
翻訳している間にも原文側の更新がけっこう発生しているみたいで、最新の原文とは内容が乖離している可能性があります。
翻訳自体にも誤りがあるかもしれません。
あくまで原文にどんなことが書いてあるのかを知るとっかかりとして、参考程度に見てください。

原文

なお、翻訳しているうちにわかってきたことは以下にまとめていってます。
Ansibleまとめ

インストールガイド

基本としてインストールされるもの

デフォルトのAnsibleはSSHプロトコルでマシン群を管理する。
一度Ansibleがインストールされると、データベースは追加されず、起動・動き続けるデーモンはない。
あなたは一台のマシン(ノートPCでもOK)のみにAnsibleをインストールすれば、中心点からリモートマシン全てを管理できる。
リモートマシンをAnsibleで管理する場合、リモートマシン上にソフトウェアをインストールしたりする必要はない。なのでAnsibleのバージョンアップ方法について質問はでないはずだ。

どのバージョンを選択するか？

ソースからとても簡単に動作し、リモートマシンへのソフトウェアインストールが必要ないため、多くの開発者は実際に開発バージョンを追跡する。
Ansibleのリリースサイクルは、通常約4ヶ月。短いリリースサイクルのため、マイナーバグは通常、安定したブランチで互換性を維持しつつ次のリリースで修正される。
メジャーバグは必要なときにメンテナンスリリースをするが、めったにない。

Ansibleの最新バージョンを動作させたい＆RedHat/CentOS/Fedora/Debian/Ubuntuを動作させているならば、OSパッケージマネージャー(rpm等)を使うことをおすすめする。

他のインストールオプションについては、Pythonのパッケージマネージャである"pip"経由でのインストールをおすすめするが、他のオプションも利用できる。

もし最新の機能を使うそしてテストするために開発リリースを追跡したいならば、我々はソースからの動作についての情報を共有する。
ソースから実行するためにプログラムをインストールする必要はない。

管理マシンの要件

現在、AnsibleはPython2(2.6 or 2.7)かPython3(3.5以上)がインストールされたマシン(Windowsはサポート対象外)で動作する。

これはRedHat,Debian,CentOS,OS X,BSD系OSその他を含む。

** 注記 **
デフォルトのMac OS Xは少数のファイルハンドル向けに設定されているため、
もし15以上のフォーク(プロセス)を使いたいならば、``sudo launchctl limit maxfiles unlimited`` コマンドでシステムリソース上限を引き上げる必要がある
このコマンドはToo many open files エラーを修正してくれる。

** 警告 **
一部のモジュールとプラグインには追加要件があります。
モジュールの場合、これらは 'ターゲット'マシンで満足する必要があり、
モジュール固有のドキュメントにリストされている必要があります。

管理対象ノードの要件

管理対象ノードでは、通常はSSHで通信するための方法が必要である。
デフォルトではAnsbleはSFTPを使う。もしSFTPが利用できないならば、
ansible.cfgでscpに切り替えることができる。なお、Python2.6以降も必要である。

**注記**
もしSELinuxがリモートのノードで有効ならば、Ansibleでいくつかのcopy,file,templateに関係する関数を使う前に、libselinux-pythonをインストールしたいと思うだろう。このパッケージがインストールされていないマシンにインストールするために、もちろんAnsibleのyum モジュールを使うことができる。

**注記**
デフォルトではAnsibleはRHEL6のような古いディストリビューションとの互換性を維持するためにAnsibleはPython2を使う。
しかし、Gentoo,Arch等のいくつかのLinuxディストリビューションでは、デフォルトではPython2.X系のインタプリタがインストールされていない場合がある。
これらのシステムでは、Python2.Xのインタプリタをインストールする必要があり、
”ansible_python_interpreter”変数がインストールした2.X系Pythonを指すように設定する必要がある。
Red Hat Enterprise Linux、CentOS、Fedora、Ubuntuなどのディストリビューション にはデフォルトで2.Xインタープリターがインストールされているが、
その他のディストリビューションには適用されない。ほぼ全てのUnixシステムも同様に適用されない。

もし適用外のリモートシステムにPython2.X系をインストールしつつ起動させたいならば、rawモジュールで遠隔操作でできる。
例えば、Ansibleとそのモジュールを実行するために必要となるPython2.Xおよびsimplejsonモジュールをインストールするだろう。

管理マシンのインストール

DNF or Yum 経由での最新版のインストール

Fedora

sudo dnf install ansible

Red Hat, CentOS

sudo yum install ansible

** 注記 **
我々はAnsibleコミュニティパッケージの配布方法を変更した。
RHEL / CentOS / Scientific Linuxバージョン7のユーザーにとって、AnsibleコミュニティRPMパッケージは、
EPELリポジトリからExtrasチャンネル(RedHatが最新版を提供するリポジトリのようなもの)に移行します
Extrasチャンネルはバージョン6の一部ではないためRHEL / CentOS / Scientific Linuxバージョン6向けの変更はない。

RHEL7のRPMはExtras channelから利用できる。
RHEL6のRPMはEPEL6のyumから利用できる。そして現在Fedoraをサポートしている。
AnbisleはRPM/YUMリポジトリもある。
Ansible バージョン2.4はPython2.6以上を含むより簡単にOSを管理できる。
あなたは、RPMを自身でビルドすることもできる。
チェックアウトまたはtar書庫から、あなたは配布してインストールできるRPMを構築するためのコマンド「make rpm」を使う。

Via Apt経由での最新版のインストール(Ubuntu)

(未翻訳)

GitHub上のAnsible

あなたがGitHubアカウントを持っているならばGitHubプロジェクトの動向を知りたいと思うこともあるだろう。
GitHubプロジェクトはバグや機能のアイディアを共有するための課題トラッカーを補完する場所でもある。

Ansibleの設定

設定ファイル

Ansibleのある設定は設定ファイル(ansible.cfg)経由で調整できる。
ストック設定はほとんどのユーザーにとって十分なはずだが、それらを変更したいと思うこともあるかもしれない。

最新の設定を取得

パッケージマネージャーからAnsibleをインストールする場合、最新のansible.cfg ファイルが/etc/ansibleに存在するはず。更新時に適切な.rpmnewファイルとして存在するはず。

もし"pip"かソースからインストールした場合、Ansibleのデフォルト設定を書き換えるためにあなたはこのファイル(最新のansible.cfgか？)を作成したいと思うだろう。

GitHubにあるサンプルansible.cfgへのリンク

さらなる詳細や利用できる全ての設定一覧はconfigulation_setingsを参照せよ。
Ansibleバージョン2.4から、あなたの利用可能なオプションを一覧表示して現在の値を調べることができる
ansible-config command line ユーティリティを使うことができる。

詳細については、config - 現在のAnsilbe設定値の参照を参照してください。

環境設定

また、環境変数を使用して設定を行うこともできます。
これらの環境変数が設定されていれば、設定ファイルからロードされた設定を上書きします。
使用可能な環境変数の完全なリストは、Ansible 構成設定から取得できます。

コマンドラインオプション

すべての設定オプションがコマンドラインに存在するわけではなく、
もっとも有用、もしくは共通であると思われる設定オプションだけです。
コマンドラインでの設定は、設定ファイルと環境で渡された設定を上書きします。
利用可能なオプションの完全なリストは以下のリンクにある。
ansible-playbook, ansible

Ansible移行ガイド

このセクションはあなたのplaybook、プラグイン、その他をあるバージョンのAnsibleから
次バージョンのAnsibleへ移行するのに役立つガイドを一覧表示したもの。
完全なリストではないことに注意せよ。これらのページで役立つ追加情報だと思ったら、
右上のEdit on GitHubをクリックして編集・もしくは問題を提起できる。

前バージョン間との変化点

Ansible 2.0 Porting Guide
Ansible 2.3 Porting Guide
Ansible 2.4 Porting Guide
Ansible 2.5 Porting Guide

ユーザーガイド

Ansible Quickstart

我々はAnsibleを紹介する短いビデオを録画しました。

クイックスタートビデオの長さは約13分で、Anabilitiesへの高水準の紹介 - その機能と使い方を紹介しています。また、Ansibleエコシステムの他の製品についてもお伝えします。

お楽しみにして、残りのドキュメントを参照して詳細を確認してください。

始める

序文

あなたはインストールガイドを読んでAnsibleをインストールしました。
いくつかの特別なコマンドを使ってみましょう。

私たちが最初に示しているのは、Ansibleの強力な構成/展開/オーケストレーションの機能ではありません。
これらの機能は別のセクションで説明されているplaybookで処理されます。

このセクションでは、最初にAnsibleを起動する方法について説明します。
これらの概念を理解したら、アドホックコマンドの紹介を読んでください。playbookの学習を始める準備ができています。

リモート接続情報

まずはSSH経由でAnsibleがリモートマシンと通信する方法を理解することが重要です。

デフォルトでAnsibleは可能ならばにリモート通信にネイティブなOpenSSHを使用しようとします。これによりControlPersist（パフォーマンス機能）、ケルベロス認証、そして踏み台設定などの~/.ssh/config内のオプションが有効になります。ただし、Enterprise Linux 6オペレーティングシステムを管理マシン（Red Hat Enterprise LinuxおよびCentOSなどの派生製品）として使用する場合、OpenSSHのバージョンはControlPersistをサポートするには古すぎるかもしれません。これらのOSでは、Ansibleは、 'paramiko'と呼ばれるOpenSSHの高品質なPython実装の使用を代替手段とする。
Kerberos認証によるSSHなどの機能を使用する場合は、使用しているプラットフォームで新しいバージョンのOpenSSHが利用できるようになるまで、Fedora、OS X、またはUbuntuを管理マシンとして使用することを検討してください。

SFTPをサポートしていないデバイスがあることがあります。
そのようなケースはレアですが、発生した場合は、「Ansibleを設定する」の項目にあったようにSCPモードに切り替えることができます。

リモートマシンと通信するとき、AnsibleはデフォルトでSSH鍵を使用していると仮定します。
SSHキーが推奨されていますが、必要に応じて--ask-passオプションを指定してパスワード認証を使用することもできます。

sudo機能を使っており、なおかつsudoがパスワードを必要とする場合は、--ask-become-pass（以前の--ask-sudo-passは廃止されています）を指定してください。

常識かもしれませんが、共有する価値がある：すべての管理システムは、ネットワーク的に管理対象マシンの近くで実行することで利益を得る。あなたがクラウド内でAnsibleを実行している場合は、そのクラウド内のマシンから実行することを検討してください。 ほとんどの場合、これはオープンインターネットよりも高速になります。

先進的な話題として、AnsibleはSSH経由で遠隔接続するだけではない。
トランスポートは接続可能であり、ローカルでの管理やchroot、lxc、jailコンテナの管理などのオプションがあります。

"ansible-pull"と呼ばれるモードでは、中央リポジトリから設定命令を引き出すためのスケジューリングされたgit checkouts経由でシステムの電話機をホームディレクトリに置くこともできます。

あなたの最初のコマンド

あなたがAnsibleをインストールしたので、いくつかの基本から始めましょう。

/etc/ansible/hostsを編集（または作成）して、そこに1つまたは複数のリモートシステムを書きなさい。

192.0.2.50
aserver.example.org
bserver.example.org

上記はインベントリファイルで、深い説明はこちら

なお、あなたの管理サーバの公開鍵は、インベントリファイルに記載したリモートシステムのauthorized_keysに書く必要があります

我々はあなたが認証にSSH鍵を使っていると仮定する。
SSH接続時のパスワード再入力を避けるためのSSHエージェント設定のためには以下のようにすればよい

$ ssh-agent bash
$ ssh-add ~/.ssh/id_rsa

(あなたの設定によってはpemファイルを指定するAnsibleの--private-keyオプションを使いたいかもしれません。)

Ansibleはノード群(管理対象のリモートホスト群)に対してpingしてみましょう

$ ansible all -m ping

SSHがそうするようにAnsibleは現在のあなたのユーザー名を使ってマシンにリモート接続しようとします。リモートユーザー名を上書きしたいならば-uパラメータを使いなさい。

sudoモードでアクセスしたい場合のフラグは以下の通り。

# ブルースとしてログイン
$ ansible all -m ping -u bruce
# ブルースとしてログイン, sudo(root)で実行
$ ansible all -m ping -u bruce --sudo
# ブルースとしてログイン, sudo(バットマン)で実行
$ ansible all -m ping -u bruce --sudo --sudo-user batman

# 最新バージョンのAnsibleでは `sudo`オプションは非推奨なので`become`オプションを使え
# ブルースとしてログイン, sudo(root)で実行
$ ansible all -m ping -u bruce -b
# ブルースとしてログイン, sudo(バットマン)で実行
$ ansible all -m ping -u bruce -b --become-user batman

(sudoの置き換えをしたい場合はAnsibleの設定ファイル内で実装を変更できる. sudoに渡されるオプション(-H など)も変更できる。)

次に、すべてのノードでライブコマンドを実行します。

$ ansible all -a "/bin/echo hello"

おめでとう！あなたはAnsibleであなたのノードに接触した。次はAd-Hocコマンド、異なるモジュールでできることの探求、Playbooks言語を使ったAnsible操作についての学習、の紹介を通して実際のケースについて読みましょう。 Ansibleはコマンドの実行だけでなく、強力な構成管理とデプロイ機能も備えています。探求すべきことはもうたくさんありますが、すでに十分に機能しているインフラがあります。

** Tips **
コマンドを実行するとき、サーバー名として``localhost`` や 
``127.0.0.1``を使うことでローカルのサーバーを指定できる。
例:
$ ansible localhost -m ping -e 'ansible_python_interpreter="/usr/bin/env python"'

インベントリファイルへ以下を追加することによって明確にローカルホストを指定できる。
localhost ansible_connection=local ansible_python_interpreter="/usr/bin/env python

ホストキーチェック

Ansibleは、デフォルトでホストキーチェックが有効になっている。

もしリモートホストマシンが再インストールされ、 known_hostsに異なるキーがある場合、修正するまでエラーメッセージが表示されます。ホストが最初に 'known_hosts'にない場合、これはキーの確認を促す結果となり、Ansibleを使用している場合はcronという対話形式のエクスペリエンスが得られます。あなたはこれを望まないかもしれません。

あなたがその意義を理解し、このふるまいを望まないならば、/etc/ansible/ansible.cfgや~/.ansible.cfgを編集することで無効にできる。

[defaults]
host_key_checking = False

代わりにこれはANSIBLE_HOST_KEY_CHECKING環境変数で設定することもできます。

$ export ANSIBLE_HOST_KEY_CHECKING=False

また、paramikoモードでのホスト鍵のチェックはかなり遅いので、この機能を使用するときには 'ssh'に切り替えることもお勧めします。

Ansibleは、taskまたはplayに「no_log：True」属性が設定されていない限り、リモートsyslogのリモートシステム上のモジュール引数に関する情報をログに記録します。これについては後で説明します。

コントロールマシンで基本ログを有効にするには、Ansible設定ドキュメントを参照し、「log_path」設定ファイルの設定を設定してください。エンタープライズユーザーはまた、Ansible Towerに興味があるかもしれません。タワーは非常に堅牢なデータベースロギング機能を備えており、ホスト、プロジェクト、および特定のインベントリに基づいて履歴をドリルダウンして表示することができます。グラフィカルにもREST APIでも探索できます。

コマンドラインツールで動かす

ほとんどのユーザーはansibleとansible-plaoybookをよく知っているが、これらだけがAnsibleが提供するユーティリティではない。以下は、完全なAnsibleユーティリティの一覧である。それぞれのページはユーティリティの説明とサポートされるパラメータの一覧を含む。

• ansible
• ansible-config
• ansible-console
• ansible-doc
• ansible-galaxy
• ansible-inventory
• ansible-playbook
• ansible-pull
• ansible-vault

ansible

ホストのセットに対して単一タスクの"Playbook"を定義して実行。

大要

ansible <host-pattern> [options]

説明

遠隔操作をするための超シンプルなツール/フレームワーク/APIである。
このコマンドであなたはホストのセットに対して単一のplaybookタスクを定義して実行できる。

共通オプション

(未翻訳)

環境

以下の環境変数を指定できる。
ANSIBLE_CONFIG ? デフォルトのAnsible設定ファイルを上書きする。
ansible.cfg 内のほとんどのオプションで利用できる。

ファイル

/etc/ansible/ansible.cfg ? 設定ファイル, 存在する場合に使用される。
~/.ansible.cfg ? ユーザー設定ファイル, 存在する場合にデフォルト設定を上書きする。

著者

元々AnsibleはMichael DeHaanによって書かれた。
完全な投稿者の一覧を見るにはAUTHORSファイルを参照。

コピーライト

Copyright c 2017 Red Hat, Inc | Ansible.

Ansible is released under the terms of the GPLv3 License.

関連情報

ansible(1), ansible-config(1), ansible-console(1), ansible-doc(1), ansible-galaxy(1), ansible-inventory(1), ansible-playbook(1), ansible-pull(1), ansible-vault(1),

ansible-config

Ansible設定を閲覧、編集、管理する。

大要

ansible-config [view|dump|list] [--help] [options] [ansible.cfg] 

説明

コマンドラインクラスを設定する。

共通オプション

動作

list

lib/constants.pyを読み込んで全ての共通設定を一覧表示し、環境そして設定ファイル設定名を表示する。

dump

指定されたansible.cfgをマージした現在の設定を表示する。
--only-changed デフォルトから変化した設定のみを表示する。

view

現在の設定ファイルを表示する。

環境

以下の環境変数を指定できる。
ANSIBLE_CONFIG ? デフォルトのAnsible設定ファイルを上書きする。
ansible.cfg 内のほとんどのオプションで利用できる。

ファイル

/etc/ansible/ansible.cfg ? 設定ファイル, 存在する場合に使用される。
~/.ansible.cfg ? ユーザー設定ファイル, 存在する場合にデフォルト設定を上書きする。

著者

元々AnsibleはMichael DeHaanによって書かれた。
完全な投稿者の一覧を見るにはAUTHORSファイルを参照。

コピーライト

Copyright c 2017 Red Hat, Inc | Ansible.

Ansible is released under the terms of the GPLv3 License.

関連情報

ansible(1), ansible-config(1), ansible-console(1), ansible-doc(1), ansible-galaxy(1), ansible-inventory(1), ansible-playbook(1), ansible-pull(1), ansible-vault(1),

ansible-console

Ansibleタスクを実行するための対話的コンソール

大要

ansible-console [<host-pattern>] [options]

説明

対話的コンソールで選択されたインベントリに対するアドホックタスクを実行できる（ドミニスのansible-shellに基づく）

共通オプション

(未翻訳)

環境

以下の環境変数を指定できる。
ANSIBLE_CONFIG ? デフォルトのAnsible設定ファイルを上書きする。
ansible.cfg 内のほとんどのオプションで利用できる。

ファイル

/etc/ansible/ansible.cfg ? 設定ファイル, 存在する場合に使用される。
~/.ansible.cfg ? ユーザー設定ファイル, 存在する場合にデフォルト設定を上書きする。

著者

元々AnsibleはMichael DeHaanによって書かれた。
完全な投稿者の一覧を見るにはAUTHORSファイルを参照。

コピーライト

Copyright c 2017 Red Hat, Inc | Ansible.

Ansible is released under the terms of the GPLv3 License.

関連情報

ansible(1), ansible-config(1), ansible-console(1), ansible-doc(1), ansible-galaxy(1), ansible-inventory(1), ansible-playbook(1), ansible-pull(1), ansible-vault(1),

ansible-doc

文書化ツールプラグイン

大要

ansible-doc [-l|-F|-s] [options] [-t <plugin type> ] [plugin]

説明

Ansibleライブラリにインストールされているモジュールに関する情報を表示します。これは、プラグインの簡潔なリストとその短い説明を表示し、DOCUMENTATION文字列のプリントアウトを提供し、短い「スニペット」を作成して、playbookに貼り付けることができます。

共通オプション

(未翻訳)

環境

以下の環境変数を指定できる。
ANSIBLE_CONFIG ? デフォルトのAnsible設定ファイルを上書きする。
ansible.cfg 内のほとんどのオプションで利用できる。

ファイル

/etc/ansible/ansible.cfg ? 設定ファイル, 存在する場合に使用される。
~/.ansible.cfg ? ユーザー設定ファイル, 存在する場合にデフォルト設定を上書きする。

著者

元々AnsibleはMichael DeHaanによって書かれた。
完全な投稿者の一覧を見るにはAUTHORSファイルを参照。

コピーライト

Copyright c 2017 Red Hat, Inc | Ansible.

Ansible is released under the terms of the GPLv3 License.

関連情報

ansible(1), ansible-config(1), ansible-console(1), ansible-doc(1), ansible-galaxy(1), ansible-inventory(1), ansible-playbook(1), ansible-pull(1), ansible-vault(1),

ansible-galaxy

大要

ansible-galaxy [delete|import|info|init|install|list|login|remove|search|setup] [--help] [options] ...

説明

共有リポジトリ内のAnsibleロールを管理する。そのデフォルトはAnsible Galaxy (https://galaxy.ansible.com.)である。

共通オプション

(未翻訳)

動作

(未翻訳)

環境

以下の環境変数を指定できる。
ANSIBLE_CONFIG ? デフォルトのAnsible設定ファイルを上書きする。
ansible.cfg 内のほとんどのオプションで利用できる。

ファイル

/etc/ansible/ansible.cfg ? 設定ファイル, 存在する場合に使用される。
~/.ansible.cfg ? ユーザー設定ファイル, 存在する場合にデフォルト設定を上書きする。

著者

元々AnsibleはMichael DeHaanによって書かれた。
完全な投稿者の一覧を見るにはAUTHORSファイルを参照。

コピーライト

Copyright c 2017 Red Hat, Inc | Ansible.

Ansible is released under the terms of the GPLv3 License.

関連情報

ansible(1), ansible-config(1), ansible-console(1), ansible-doc(1), ansible-galaxy(1), ansible-inventory(1), ansible-playbook(1), ansible-pull(1), ansible-vault(1),

ansible-inventory

大要

ansible-inventory [options] [host|group]

説明

Ansibleが見るような形で設定されたインベントリを表示またはダンプするために使われる。

共通オプション

環境

以下の環境変数を指定できる。
ANSIBLE_CONFIG ? デフォルトのAnsible設定ファイルを上書きする。
ansible.cfg 内のほとんどのオプションで利用できる。

ファイル

/etc/ansible/ansible.cfg ? 設定ファイル, 存在する場合に使用される。
~/.ansible.cfg ? ユーザー設定ファイル, 存在する場合にデフォルト設定を上書きする。

著者

元々AnsibleはMichael DeHaanによって書かれた。
完全な投稿者の一覧を見るにはAUTHORSファイルを参照。

コピーライト

Copyright c 2017 Red Hat, Inc | Ansible.

Ansible is released under the terms of the GPLv3 License.

関連情報

ansible(1), ansible-config(1), ansible-console(1), ansible-doc(1), ansible-galaxy(1), ansible-inventory(1), ansible-playbook(1), ansible-pull(1), ansible-vault(1),

ansible-playbook

ターゲットのホスト上で定義されたタスクを実行するAnsible playbook群を実行する。

大要

ansible-playbook [options] playbook.yml [playbook2 ...]

説明

Ansible playbook群を実行するための設定システム、複数ノードデプロイシステムであるツール。詳細についてはプロジェクトのホームページを参照（https://docs.ansible.com）。

共通オプション

環境

以下の環境変数を指定できる。
ANSIBLE_CONFIG ? デフォルトのAnsible設定ファイルを上書きする。
ansible.cfg 内のほとんどのオプションで利用できる。

ファイル

/etc/ansible/ansible.cfg ? 設定ファイル, 存在する場合に使用される。
~/.ansible.cfg ? ユーザー設定ファイル, 存在する場合にデフォルト設定を上書きする。

著者

元々AnsibleはMichael DeHaanによって書かれた。
完全な投稿者の一覧を見るにはAUTHORSファイルを参照。

コピーライト

Copyright c 2017 Red Hat, Inc | Ansible.

Ansible is released under the terms of the GPLv3 License.

関連情報

ansible(1), ansible-config(1), ansible-console(1), ansible-doc(1), ansible-galaxy(1), ansible-inventory(1), ansible-playbook(1), ansible-pull(1), ansible-vault(1),

ansible-pull

バージョン管理システムレポジトリからplaybook群を取り出し、ローカルホストでそれらを実行する

大要

ansible-pull -U <repository> [options] [<playbook.yml>]

説明

それぞれの管理対象ノード上のAnsibleのリモートコピーに使われる。
それぞれはクーロンを介して実行され、リポジトリ経由でplaybookソースを更新する。
これはデフォルトのpush型のAnsibleアーキテクチャがほぼ無限のスケーリングポテンシャルをもつプル型のアーキテクチャに反転する。

playbookのセットアップはcronの頻度、ロギングの場所、パラメータをansible-pullへ変更するためのチューニングされうる。これは極端なスケールアウトと定期的な修復の両方に役立つ。フェッチモジュールを使用して、ansible-pullからログを取得することはansible-pullからリモートログを収集・分析する優れた方法です。

共通オプション

環境

以下の環境変数を指定できる。
ANSIBLE_CONFIG ? デフォルトのAnsible設定ファイルを上書きする。
ansible.cfg 内のほとんどのオプションで利用できる。

ファイル

/etc/ansible/ansible.cfg ? 設定ファイル, 存在する場合に使用される。
~/.ansible.cfg ? ユーザー設定ファイル, 存在する場合にデフォルト設定を上書きする。

著者

元々AnsibleはMichael DeHaanによって書かれた。
完全な投稿者の一覧を見るにはAUTHORSファイルを参照。

コピーライト

Copyright c 2017 Red Hat, Inc | Ansible.

Ansible is released under the terms of the GPLv3 License.

関連情報

ansible(1), ansible-config(1), ansible-console(1), ansible-doc(1), ansible-galaxy(1), ansible-inventory(1), ansible-playbook(1), ansible-pull(1), ansible-vault(1),

ansible-vault

Ansibleデータファイルのための暗号化/復号化ユーティリティ

大要

ansible-vault [create|decrypt|edit|encrypt|encrypt_string|rekey|view] [options] [vaultfile.yml]

説明

Ansibleが使用する構造化データファイルを暗号化できる。
これは"group_vars"または"host_vars"のインベントリ変数,"include_vars" または "vars_viles"によってロードされる変数、または-e @file.yml　や -e @file.json を伴うansible-playbookコマンドラインで渡される変数ファイルを含むことができる。ロール変数とデフォルト変数もまた含まれる。

Ansibleのtask群、handler群、他のオブジェクトはデータであるため、これらはvaultで暗号化できる。もし使用している変数を公開したくないならば、個々のタスクファイルを完全に暗号化したままにすることもできる。

vaultで使用されるパスワードは同時に使用する全てのファイルで同じでなければならない。

共通オプション

(未翻訳)

動作

(未翻訳)

環境

以下の環境変数を指定できる。
ANSIBLE_CONFIG ? デフォルトのAnsible設定ファイルを上書きする。
ansible.cfg 内のほとんどのオプションで利用できる。

ファイル

/etc/ansible/ansible.cfg ? 設定ファイル, 存在する場合に使用される。
~/.ansible.cfg ? ユーザー設定ファイル, 存在する場合にデフォルト設定を上書きする。

著者

元々AnsibleはMichael DeHaanによって書かれた。
完全な投稿者の一覧を見るにはAUTHORSファイルを参照。

コピーライト

Copyright c 2017 Red Hat, Inc | Ansible.

Ansible is released under the terms of the GPLv3 License.

関連情報

ansible(1), ansible-config(1), ansible-console(1), ansible-doc(1), ansible-galaxy(1), ansible-inventory(1), ansible-playbook(1), ansible-pull(1), ansible-vault(1),

Ad-Hocコマンドのためのまえがき

以下の例はad hocタスクを実行するために/usr/bin/ansibleを使うための方法を示す。

ad-hocコマンドとは何か？

ad-hocコマンドは、何かをすばやく実行するために入力するが、あとで保存したくないものである。

これは、Ansibleがplaybook言語を学ぶ前にできることの基礎を理解するのに適している。
ad-hocコマンドは完全なplaybookを書く必要がないものを迅速に実行するために使える。

一般的に言うと、Ansibleの真のパワーはplaybookに存在する。
アドホックタスク群とplaybook群の違いは何か？

例えば、クリスマス休暇にあなたのラボの電源を切りたいならば、あなたはplaybookを書くことなくAnsibleで迅速な1行実行ができる。

構成管理とデプロイのために、しかし、あなたは"/usr/bin/ansible-playbook"を使いこなしたいと思うだろう。あなたがここで学ぶコンセプトはplaybook言語に直接移植できる。

(それらについてより多くの情報はplaybookを使って動かすを参照)

もしあなたはすでにインベントリを使って動かすを見ているならば、少し先にそれを見てから行くだろう。

(以下未翻訳)

インベントリを使って動かす

Ansibleはあなたのインフラ内の複数のシステムに対して同時に動作します。
これは、デフォルトで/etc/ansible/hostsの場所に保存されるAnsibleのインベントリに一覧化されているシステムの一部を選択することによって行われます。コマンドラインで-i <path>オプションを使用すると、別のインベントリファイルを指定できます。

このインベントリは設定可能なだけでなく、複数のインベントリファイルを同時に使用し、ダイナミックまたはクラウドソースまたは異なるフォーマット（YAML、iniなど）からインベントリを取得することもできます（「ダイナミックインベントリの処理」を参照）。バージョン2.4で導入されたAnsibleは、これを柔軟かつカスタマイズ可能にするためのインベントリプラグインを持っています。

ホスト群とグループ群

インベントリファイルはあなたが持つインベントリプラグインに依存する多くのフォーマットの一つになりうる。/etc/ansible/hostsのフォーマットの例はINIライクで次のようになる。

mail.example.com

[webservers]
foo.example.com
bar.example.com

[dbservers]
one.example.com
two.example.com
three.example.com

角括弧内の見出しはグループ名で、システムの分類やあなたがいつ、なんの目的でコントロールするシステムであるかを決定する。

YAMLバージョンは次のようになる。

all:
  hosts:
    mail.example.com:
  children:
    webservers:
      hosts:
        foo.example.com:
        bar.example.com:
    dbservers:
      hosts:
        one.example.com:
        two.example.com:
        three.example.com:

システムを複数のグループに配置してもOKである。
例えば、サーバーはwebサーバーとDBサーバーの両方になる可能性がある。
そうした場合、変数群は所属する全てのグループのものが適用されることに注意しなさい。
変数の優先順位は後のチャプターで詳しく説明する。

非標準のSSHポートで動作するホストがある場合は、コロンでホスト名の後にポート番号を配置できる。SSH設定ファイルで一覧化されるポート群はparamiko接続では使われないが、OpenSSH接続で使われる。

物事を明示化するために、デフォルトポートで実行されていない場合に設定することをおすすめする。

badwolf.example.com:5309

静的IP群だけを持っており、ホストファイルにいくつかのエイリアスを設定したいまたはトンネル経由での接続をしているとする。あなたは変数を経由してホストを記述できる。

INI形式

jumper ansible_port=5555 ansible_host=192.0.2.50

YAML形式

...
  hosts:
    jumper:
      ansible_port: 5555
      ansible_host: 192.0.2.50

上記の例では、ホストエイリアス"jumper"(本当のホスト名ではないかも)に対してAnsibleを試みると、ポート5555の192.0.2.50に連絡する。いくつかの特別な変数を定義するためのインベントリファイルの機能を利用することに注意しろ。一般的にいえばシステムポリシーを記述する変数を定義するためのこれは最善の方法ではない。あとから提案を示す。

** 注記 **
key = value構文を使用してINI形式で渡される値は、Pythonリテラル構造（文字列、数値、タプル、リスト、辞書、ブール値、なし）として解釈されるのではなく、文字列として解釈されます。たとえば、var = FALSEは、 'FALSE'に等しい文字列を作成します。定義時に設定された型に頼らないで、変数を消費するときに必要なときに必ずフィルターを使用して型を指定するようにしてください。

似通ったパターンで多くのホストを追加する場合は、それぞれのホスト名を一覧化することなく次のようにできる。

[webservers]
www[01:50].example.com

数値のパターンの場合、必要に応じて先行ゼロを含めたり削除したりできる。範囲は包括的である。アルファベットの範囲も適宜できる。

[databases]
db-[a:f].example.com

ホスト毎に接続タイプとユーザーを割り当てることもできる。

[targets]

localhost              ansible_connection=local
other1.example.com     ansible_connection=ssh     ansible_user=mpdehaan
other2.example.com     ansible_connection=ssh        ansible_user=mdehaan

上述した通り、これらをインベントリファイルに設定することはちょっとしたことであり、後ほどhost_varsディレクトリで個々のファイルにそれらを格納する方法について説明する。

ホスト変数

上述した通り、ホスト群に対する変数群を割り当てることは以下のplaybookで簡単にできる。

[atlanta]
host1 http_port=80 maxRequestsPerChild=808
host2 http_port=303 maxRequestsPerChild=909

グループ変数

変数は一度にグループ全体に適用することもできる。

INI形式

[atlanta]
host1
host2

[atlanta:vars]
ntp_server=ntp.atlanta.example.com
proxy=proxy.atlanta.example.com

YAML形式

atlanta:
  hosts:
    host1:
    host2:
  vars:
    ntp_server: ntp.atlanta.example.com
    proxy: proxy.atlanta.example.com

これは一度に複数のホストに変数を適用するための便利な方法であるだけなことに注意しろ。
グループ毎のホスト群をターゲットにできるが、変数群は常にplayが実行される前にホストレベルにフラット化される。

グループ群のグループ群とグループ変数

INIの:children接尾後またはYAMLのchildren:接頭語を使ってグループ群のグループ群を作ることもできる。あなたは:varsまたはvars:を使って変数を適用できる。

[atlanta]
host1
host2

[raleigh]
host2
host3

[southeast:children]
atlanta
raleigh

[southeast:vars]
some_server=foo.southeast.example.com
halon_system_timeout=30
self_destruct_countdown=60
escape_pods=2

[usa:children]
southeast
northeast
southwest
northwest

all:
  children:
    usa:
      children:
        southeast:
          children:
            atlanta:
              hosts:
                host1:
                host2:
            raleigh:
              hosts:
                host2:
                host3:
          vars:
            some_server: foo.southeast.example.com
            halon_system_timeout: 30
            self_destruct_countdown: 60
            escape_pods: 2
        northeast:
        northwest:
        southwest:

リスト(配列)やハッシュデータ(連想配列)を格納する必要がある場合や、ホストとグループ固有の変数をインベントリファイルとは別に保存する場合は、次のセクションを参照してください。子グループには、いくつかの注意すべきプロパティがあります。

• 子グループに所属するホストは、自動的に親グループにも所属します。
• 子グループの変数は、親グループの変数を上書きするでしょう。
• グループには複数の親と子が含まれますが、循環関係はありません。
• ホストは複数のグループに所属することもできますが、ホストのインスタンスは1つしかなく、複数のグループのデータをマージします。

デフォルトグループ群

all と ungroupedという2つのデフォルトグループがある。
allは全てのホストを意味するグループ。
ungroupedはグループに所属しない全てのホストを意味するグループ。

全てのhostは常に少なくとも2つのグループに所属する。
all ungroupedは常に存在するが、それらは暗黙的であり、group_namesのようなグループリストには表示されない。

ホストとグループ固有のデータの分割

Ansibleの好ましいプラクティスは、メインのインベントリファイルに変数を保存しないことである。

インベントリファイルに直接変数を格納することに加え、ホストとグループ変数はインベントリファイルに関係する個々のファイルへ格納できる。

これらの変数ファイルはYAML形式である。有効な拡張子は".yml", ".yaml", ".json", または拡張子なしである。YAMLを初めて使用する場合はYAML構文を参照せよ。

想定するインベントリファイルのパスは以下の通り。

/etc/ansible/hosts

ホスト名が"foosball"、グループ名が"raleigh"と"webservers"である場合、次の場所のYAMLファイル内の変数がホストに対して適用される。

# '.yml', '.yaml', or '.json'の拡張子をつけてもよい
/etc/ansible/group_vars/raleigh 
/etc/ansible/group_vars/webservers
/etc/ansible/host_vars/foosball

例えば、DC毎にグループ化されたホスト群があり、それぞれのDCで異なるサーバーを使っていると仮定する。raleighグループに対応するグループファイル"/etc/ansible/group_vars"内のデータは次のようになる。

---
ntp_server: acme.example.org
database_server: storage.example.org

これはオプション機能であるため、これらのファイルが存在しなくてもよい。

高度なユースケースとして、あなたはあなたのグループ群やホスト群の名前のディレクトリを作成することができ、Ansibleはそれらのディレクトリ内のファイルを辞書順に読み込む。"raleigh"グループの例：

/etc/ansible/group_vars/raleigh/db_settings
/etc/ansible/group_vars/raleigh/cluster_settings

'raleigh'グループに属するすべてのホストは、これらのファイルで定義された変数を使用できます。これは、1つのファイルが肥大化したとき、またはグループの変数の一部でAnabilities Vaultを使用するときに、変数を整理しておくのに非常に便利です。

** ヒント **
``group_vars/``および``host_vars/``ディレクトリは、playbookディレクトリまたはインベントリディレクトリに存在できます。両方のパスが存在する場合、playbookディレクトリの変数は、インベントリディレクトリに設定された変数を上書きします。

** ヒント **
インベントリファイルと変数をgit(やその他VCS)リポジトリに保存することはインベントリとホスト変数の変更を追跡する優れた方法である。

どのように変数がマージされるか

デフォルトでは、playが実行される前に変数が特定のホストへマージされ、フラット化される。
これにより、Ansibleはホストとタスクに重点を置いたままになります。
そのため、グループ群はインベントリとホストの突き合わせを除いて苦労することはありません。デフォルトでは、Ansibleはグループやホストに対して定義された変数を上書きします（これを変更するにはhash_mergeの設定を参照してください）。
変数の優先順位は以下の通り（最も低いものから最も高いものへ）

• all グループ
• 親グループ
• 子グループ
• ホスト

同じ親/子のレベルのグループのマージはアルファベット順に行われる。ロードされた最新のグループは以前のグループを上書きする。たとえば、a_groupはb_groupとマージされ、同じ名前の変数についてはb_groupのものが採用される。

バージョン2.4の新機能

Ansibleバージョン2.4から、ユーザーはグループ変数ansible_group_priorityを使用して、同じレベルのグループ（親/子オーダが解決された後）のマージ順序を変更できます。番号が大きいほど後でマージされ、優先度が高くなります。この変数は、設定されていない場合、デフォルトで1になります。例えば：

a_group:
    testvar: a
    ansible_group_priority: 10
b_group
    testvar: b

この例では、もし両グループが同じ優先度であるならば、結果はtestvar == bとなるが、a_groupの方がより高い優先度を付与されているため、結果はtestvar == aとなる。

ふるまいに関するインベントリパラメータの一覧

(未翻訳)

SSHでない接続タイプ

(未翻訳)

ダイナミックインベントリを使って動かす

(未翻訳)

Playbookを使って動かす

Playbookは、Ansibleの構成、デプロイ、およびオーケストレーション言語です。
Playbookにはリモートシステム群に対して強制したいポリシーや、または一般的なITプロセスの一連のステップを記述できます。

もしAnsibleモジュールがあなたの工場におけるツールと例えるならば、playbookはあなたの取り扱い説明書であり、あなたのホスト群のインベントリは原材料です。

基本的なレベルでは、playbookはリモートマシンの構成やデプロイを管理できます。より高度なレベルでは、ローリング更新を含む複数層のロールアウトをシーケンスでき、他のホストにアクションを委任し、途中で監視サーバーやロードバランサとやりとりすることができます。

ここにはたくさんの情報がありますが、一度にすべてを学ぶ必要はありません。小規模から始めて、必要に応じてさらに多くの機能を拾うことができます。

playbookは人間が読めるように設計されており、基本的なテキスト言語で開発されています。playbookとその中に含まれるファイルを整理する方法はいくつかありますが、その中でいくつかの提案を行い、Ansibleを最大限に活用していきます。

あなたは、playbookのドキュメントを読む間に、playbook例を見てください。これらはさまざまなコンセプトの多くを一緒にする方法と同様にベストプラクティスを説明する。

playbookの出だし

playbookについて

playbookは、アドホックタスク実行モードとはまったく異なる使い方をしており、特別に強力です。

簡単に言えば、playbookは、既存のものとは違って、本当にシンプルな構成管理とマルチマシンデプロイシステムの基盤であり、複雑なアプリケーションをデプロイするのに非常に適しています。

Playbookは設定を宣言することができますが、手動で順序づけられるプロセスのステップを調整することもできます。異なるステップは特定の順番のマシンセット間を行き来する必要があります。タスクを同期または非同期で起動できます。

あなたはアドホックなタスクのために主な/usr/bin/ansibleプログラムを実行するかもしれませんが、playbookはソース管理で保持され、設定をプッシュアウトしたり、リモートシステムの設定が仕様どおりであることを保証します。

また、いくつかのフルセットのplaybookが、これらのテクニックの多くをアシスタントサンプルリポジトリに示しています。私たちは別のタブでこれらを調べることをお勧めします。

あなたがplaybookを学んだ後にも多くのジャンプポイントがありますので、このセクションで作業が終わったらドキュメントインデックスに戻ってください。

playbook言語例

(未翻訳)

基本

(未翻訳)

アクションの表現

バージョン0.8の新機能

Ansibleは次のような一覧化するモジュールを好む。

template:
    src: templates/foo.j2
    dest: /etc/foo.conf

古いバージョンでは、次の形式が採用されていた。

action: template src=templates/foo.j2 dest=/etc/foo.conf

ハンドラ：変化時の実行操作

(未翻訳)

playbookの実行

playbookの構文を学んだが、どのようにplaybookを実行すればよいか？
それは単純である。並列性レベル10でplaybookを実行してみよう。

ansible-playbook playbook.yml -f 10

Ansible-Pull

Ansibleのアーキテクチャを反転させたいならば、ノードが中央へチェックインできるように、ノードに設定を転送する代わりに、あなたはできる。

ansible-pullはgitから設定指示のリポジトリをチェックアウトし、その内容に対してansible-playbookを実行する小さなスクリプトです。

あなたがチェックアウト場所の負荷を分散すると仮定すると、ansible-pullは本質的に無限に広がります。

詳細はansible-pull --helpを実行してください。

プッシュモードからのcrontab経由でansible-pullを構成するための巧妙なplaybookもあります。

ヒントとコツ

playbookのシンタックスをチェックするには、--syntax-checkフラグと一緒にansible-playbookを使え。
これにより、パーサーを介してplaybookファイルが実行され、インクルードされるファイルやロールなどに構文上の問題がないことが保証されます。

playbookの実行の最後に、ターゲットとされたノードとそれらの実行結果の概要が表示されます。一般的な失敗や致命的な"unreachable"通信の試行は、カウントで分けられます。

成功したモジュールと失敗したモジュールの詳細な出力を見たい場合は、--verboseフラグを使用してください。これはAnsible 0.5以降で利用可能です。

playbookの実行対象ホストを確認するには、次のコマンドを実行。

ansible-playbook playbook.yml --list-hosts

再利用可能なplaybookの作成

playbookを1つの非常に大きなファイルに書き込むことは可能ですが（この方法でplaybookを学習することもできます）、最終的にはファイルを再利用して物事を整理することになります。 Ansibleでは、これを行うための3つの方法があります：インクルード、インポート、ロール。

IncludesとImports（Ansibleバージョン2.4で追加）により、大規模なplaybookを複数の親playbookにまたは同じplaybook内で複数回使用できる小さなファイルに分割することができます。

ロールを使用すると、タスクだけでなく、変数、ハンドラ、さらにはモジュールやその他のプラグインを含めることができます。インクルードやインポートとは異なり、ロールはAnsible Galaxyを介してアップロードして共有することもできます。

インクルード と インポート

インクルード vs インポート

再利用可能なPlaybookの作成で説明したように、include文とimport文は非常によく似ていますが、Ansible実行エンジンは全く異なる方法で扱います。

• すべてのimport*文は、playbookが解析されるときに前処理されます。
• すべてのinclude*文は、playbookの実行中に遭遇したときに処理されます。

それぞれのトレードオフについては、再利用可能なplaybookの作成を参照してください。

2.4でふるまいが変更されたことに注意しなさい。以前のAnsibleバージョンではincludeのみが利用でき、文脈に依存して違ったふるまいをしていた。

Playbookのインポート

マスターplaybook内部にplaybook群を含めることが可能である。例えば：

---
- import_playbook: webservers.yml
- import_playbook: databases.yml

リストされた各playbook内のplay群、task群はここに直接定義されたようにリストされた順に実行される。

バージョン2.4以前では、includeだけが利用でき、playbookとtask両方に対して使用できた。

taskファイルのインクルードとインポート

含まれるtaskリストの使用はシステムが果たす役割を定義することができます。taskインクルードファイルは、単純なタスク群のリスト(以下)を含む：

# common_tasks.yml
---
- name: placeholder foo
  command: /bin/foo
- name: placeholder bar
  command: /bin/bar

import_tasks または include_tasks を使用して、このファイルをメインのタスクリストに含める（以下）ことができます。

tasks:
- import_tasks: common_tasks.yml
# or
- include_tasks: common_tasks.yml

import、include時に変数を渡すこともできます。

tasks:
- import_tasks: wordpress.yml
  vars:
    wp_user: timmy
- import_tasks: wordpress.yml
  vars:
    wp_user: alice
- import_tasks: wordpress.yml
  vars:
    wp_user: bob

変数は、辞書やリストなどの構造化変数もサポートする別の構文を使用してインクルードファイルに渡すこともできます。

tasks:
- include_tasks: wordpress.yml
  vars:
    wp_user: timmy
    ssh_keys:
    - "{{ lookup('file', 'keys/one.pub') }}"
    - "{{ lookup('file', 'keys/two.pub') }}"

いずれの構文を使用しても、渡された変数はインクルードされたファイルで使用できます。これらの変数は、インクルードされたファイル内のタスクでのみ使用できます。変数の継承と優先順位の詳細については、[変数の優先順位：変数はどこに置くべきですか？](Variable Precedence: Where Should I Put A Variable? )を参照してください。

taskのinclude文は任意の深さで使用できます。

** 注記 **
静的と動的を混在させることはできますが、これはあなたのplaybookには診断が困難なバグにつながる可能性があるため、これはお勧めしません

インクルードとインポートは、handlers:セクションでも使用できます。たとえば、Apacheを再起動する方法を定義する場合は、すべてのplaybookで一度だけ実行する必要があります。次のようなhandlers.ymlを作成することができます：

- name: restart apache
  service: name=apache state=restarted

メインplaybookファイル内で

handlers:
- include_tasks: more_handlers.yml
# or
- import_tasks: more_handlers.yml

** 注記 **
[再利用可能なplaybookを作成する](http://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse.html)に記載されているハンドラの制限/トレードオフを参照してください。

ロールのインクルードとインポート

ロールの追加とインポートの詳細については、ロールを参照してください。

ロール

バージョン1.2の新機能

roleは、特定のvars_files、tasks、およびhandlersを既知のファイル構造に基づいて自動的にロードする方法です。ロールでコンテンツをグループ化すると、他のユーザーと簡単にロールを共有することもできます。

ロールのディレクトリ構造

例のプロジェクト構造

site.yml
webservers.yml
fooservers.yml
roles/
   common/
     tasks/
     handlers/
     files/
     templates/
     vars/
     defaults/
     meta/
   webservers/
     tasks/
     defaults/
     meta/

ロールはファイルが特定の名前のディレクトリ内にあることを期待する。
ロールはこれらのディレクトリの少なくとも1つが含まれていなければならないが使用されていないディレクトリは除外することができる。
使用時には、各ディレクトリに、関連する内容を含むmain.ymlファイルが含まれている必要があります。

• tasks - roleによって実行されるメインのtaskリストの置き場
• handlers - このroleの中または外で利用される可能性があるhandlerの置き場
• defaults - このroleのデフォルト変数(詳細情報は変数を参照)
• vars - このroleのその他の変数(詳細情報は変数を参照)
• files - このroleを経由してデプロイされるファイルの置き場
• templates - このroleを経由してデプロイされるテンプレートの置き場
• meta - このroleのためのメタデータを定義する。詳細は以下を参照。

その他のYAMLファイルが特定のディレクトリに含まれることがある。
例えば、tasks/main.ymlファイルからインクルードされるプラットフォーム固有のtaskをもつことが一般的に行われる。

# roles/example/tasks/main.yml
- name: added in 2.4, previously you used 'include'
  import_tasks: redhat.yml
  when: ansible_os_platform|lower == 'redhat'
- import_tasks: debian.yml
  when: ansible_os_platform|lower == 'debian'

# roles/example/tasks/redhat.yml
- yum:
    name: "httpd"
    state: present

# roles/example/tasks/debian.yml
- apt:
    name: "apache2"
    state: present

roleはモジュールや他のプラグイン型をインクルードするかもしれない。
詳細はモジュールとプラグインをロールに埋め込むを参照。

動的 vs 静的

Aniableには、動的コンテンツと静的コンテンツを再利用可能にするための2つの操作モードがあります。

Ansible 2.0で、"動的インクルード"の概念が導入されました。
この方法で全てのインクルードを動的にすることにはいくつかの制限があるため、強制的にインクルードを静的にする機能がAnsible2.1で導入されました。
タスクのインクルードは、静的な構文と動的な構文両方を含むようにオーバーロードされ、デフォルトのインクルードのふるまいがそのタスクに設定されたオプションに基づいて変更される可能性があるため、Ansible2.4ではinclude対importの概念を導入している。

もしあなたがいくつかのimport*タスク(import_playbook, import_tasks,等)を使うならば静的になるだろう。
もしあなたがinclude*タスク(include_tasks, include_role, 等)を使うならば動的になるだろう。

ただのincludeタスク(taskのみがかかれたファイルのインクルードとPlaybookレベルのファイルのインクルード両方で使われる)はまだ利用できるが、廃止予定である。

動的と静的の違い

2つの操作モードはとても単純だ：

• AnsibleはPlaybook解析時に全ての「静的」なインポートを前処理する。
• 「動的」なインクルードは実行中にそのタスクに遭遇した際に処理される。

tagsや条件文(when:)のようなAnsibleタスクのオプションがある場合：

• 「静的」なインポートの場合、親タスクのオプションはインポートする全ての子タスクへコピーされる。

• 「動的」なインクルードの場合、タスクのオプションは評価されるときに動的なタスクにのみ適用され、子タスクへはコピーされない。

  ** 注記 **
  ロールはやや特別なケースである。Ansible2.3より前のバージョンでは、ロールは常にplay領域で付与される特別なオプションroles:を使って静的にインクルードされ、常に他のplayタスクに先駆けて最初に実行されていた(pre_tasksが使われていないならば)。ロールはまだこの方法で使用できるが、Ansible2.3でロールが他のタスクに埋め込んで実行されるinclude_roleオプションが導入された。

インクルードとインポートの間のトレードオフと落とし穴

include*とimport*の使用はユーザーがそれぞれの使用を選択する際に考慮すべきいくつかの利点といくつかのトレードオフがあります。

include*文を使用する主な利点はループである。インクルードと一緒にループが使われるとき、インクルードされるタスクやロールはループ内のそれぞれの項目にで対して一度実行される。

include*の使用はimport*と比較するといくつかの制限がある。

• 「動的」なインクルード内にのみ存在するタグは--list-tags出力にあらわれてこない。
• 「動的」なインクルード内にのみ存在するタスクは--list-taks出力にあらわれてこない。
• 「動的」なインクルードから来るハンドラ名をトリガにnotifyを使用することができない。
• 「動的」なインクルード内のタスクで実行を始めるための--start-at-taskを使用することができない。

import*の使用も「動的な」インクルードと比較するといくつかの制限がある。

• 上記のように、インポートと一緒にループを使うことがまったくできない。

• ターゲットファイルまたはロール名に変数を使用する時、インベントリのソース(host変数、group変数など)の変数は使用できない。

  ** 注記 **
  動的なタスクにnotifyを使用することについて、「動的」なインクルード自体をトリガとすることはまだ可能であり、インクルードしている全てのタスクが実行されることになる。

変数

自動化はものごとを簡単に繰り返せるようにするために存在するが、おそらく、あなたのシステムの全てが瓜二つというわけではない。

また、監視しているリモートシステムのふるまいや状態のいくつかが、それらのシステムを構成する方法に影響を与えるという動作を必要とするかもしれない(例えば、システムのIPアドレスを調査し、別のシステムの構成値として使用するなど)。

ほとんど同じだがそれらの変数に基づいて若干異なる構成ファイルのためのいくつかのテンプレートをあなたは持っているかもしれない。

Ansibleの変数はシステム間の際を我々が扱う方法である。

変数を理解するために、あなたは条件とループを掘り下げたくなるだろう。

group_byモジュールとwhen条件はシステム間の差異を管理するために、変数と一緒にも使われる。

多くの変数の使用例を確認するためには、ansible-examples GitHubリポジトリを参照することを強くおすすめする。

ベストプラクティスのアドバイスについては、章"ベストプラクティス"内の変数とVaultを参照しろ。

有効な変数名とは

変数を使い始める前に、何が有効な変数名なのかを知ることが重要である。

利用できる名前は文字、数字、そしてアンダースコアである。
変数は常に文字からはじまらなければならない。

foo_portは有効な変数である。foo5も。
foo-port, foo port, foo.port そして 12 は有効な変数名ではない。

YAMLはキーと値の辞書(=マップ,連想配列)もサポートする。例えば：

foo:
  field1: one
  field2: two

カッコ記法またはドット記法を使って辞書の特定のフィールドを参照することができます。

foo['field1']
foo.field1

これらは両方とも同じ値("one")を参照する。
しかし、もしドット記法の使用を選択するならば、pythonで使われる辞書の属性名やメソッド名と衝突するようなキーでは問題が発生するかもしれない。
もし先頭または末尾に２つのアンダースコア(これらはpythonにおいて特別な意味を持つ)がつくキーや既知のパブリック属性のキーを使うならば、ドット記法の代わりにカッコ記法をつかうべき。

add, append, as_integer_ratio, bit_length, capitalize, center, clear, 
conjugate, copy, count, decode, denominator, difference, 
difference_update, discard, encode, endswith, expandtabs, extend, find, 
format, fromhex, fromkeys, get, has_key, hex, imag, index, insert, 
intersection, intersection_update, isalnum, isalpha, isdecimal, isdigit, 
isdisjoint, is_integer, islower, isnumeric, isspace, issubset, 
issuperset, istitle, isupper, items, iteritems, iterkeys, itervalues, 
join, keys, ljust, lower, lstrip, numerator, partition, pop, popitem, 
real, remove, replace, reverse, rfind, rindex, rjust, rpartition, rsplit, 
rstrip, setdefault, sort, split, splitlines, startswith, strip, swapcase, 
symmetric_difference, symmetric_difference_update, title, translate, 
union, update, upper, values, viewitems, viewkeys, viewvalues, zfill.

インベントリ内で定義された変数

我々はすでに、別の章で変数について多くを扱っているが、これまでのところめちゃくちゃ
新しいものではなく、すこし再学習している形だ。

多くの場合、あなたはマシンがどのグループ内にあるかに基づいて変数を設定したいと思うだろう。
例えば、ボストンにあるマシンはNTPサーバーとして"boston.ntp.example.com"を使いたいとする。

インベントリで変数を定義する複数の方法についてはインベントリを使って動かすのドキュメントを参照しろ。

Playbook内で定義された変数

playbook内で、以下のようにインラインで直接変数を定義することが可能である。

- hosts: webservers
  vars:
    http_port: 80

playbookを読んでいるときに出てくることになるため、これは親切であるかもしれない。

インクルードされたファイルとロールから定義された変数

結局我々は別の場所ですでに変数について話していたことがわかる。

ロールで述べたように、変数はインクルードファイル経由でplaybookでインクルードされることもある。そのファイルは"Ansible Role"の一部かもしれないしそうではないかもしれない。ロールの使用は組織的なシステムを提供するため好ましい。

変数の使用：Jinja2について

変数を定義する方法については十分わかったと思うが、それらをどのように使えばいいのか？

AnsibleではJinja2テンプレートシステムを使用するplaybook内で変数を参照できる。
Jinjaでは多くの複雑なことができるが、最初に本当に学ぶべきは基本のみである。

例えば、単純なテンプレートでは、あなたは以下のようにできる。

My amp goes to {{ max_amp_value }}

上記は変数置換の最も基本の形である。

これはplaybook内でも有効であり、時には以下のようなことをしたいこともあるだろう。

template: src=foo.cfg.j2 dest={{ remote_install_path }}/foo.cfg 

上記の例では、ファイルの設置場所を決定する変数を使用した。

テンプレート内で、あなたはホストのスコープ内にある全ての変数へ自動的にアクセスできる。
実際にはそれ以上である - あなたは他のホストに対する変数も読み込むことができる。
ちょっとだけその方法をお見せしよう。

**注記**
Ansibleではjinja2でループと条件分岐をテンプレート内でつかうことができるが、playbookではそれらを使うことができない。
Ansible Playbookは純粋な機械的に解釈できるYAMLである。
これは非常に重要な機能であり、ファイルのコードを生成したり、他のエコシステムツールにAnsibleファイルを読みこませることができる。
誰もがこれを必要とするわけではないが、可能性がある機能である。

Jinja2フィルター

**注記**
これらはあまり利用されない機能である。
あなたのユースケースにフィットするならば、使ってください。
これはオプション的な知識になります。

(未翻訳)

ちょっとまってYAML Gotcha

YAML構文では、辞書で{{ foo }}ではじまる値が使えないので、値の箇所全体を引用(""で囲む)必要がある。これはYAML構文ドキュメントで説明されている。

これは動かない:

• hosts: app_servers
  vars:
  app_path: {{ base_path }}/22

このようにすればOK：

- hosts: app_servers
  vars:
       app_path: "{{ base_path }}/22"

システムから発見される情報：Facts

変数が出てくる場所は他にもあるが、これら発見される変数の一種であり、ユーザーが設定するものではない。

Factsはあなたのリモートシステムとの対話で得られた情報である。

これは例えばリモートホストのIPアドレスや、OSが何であるかといったものである。

利用可能な情報を確認するには次のコマンドを試せ：

ansible hostname -m setup

以下はUbuntu12.04システムでAnsible1.4を実行したときに得られた大量の変数データの例である。

{
    "ansible_all_ipv4_addresses": [
        "REDACTED IP ADDRESS"
    ],
    "ansible_all_ipv6_addresses": [
        "REDACTED IPV6 ADDRESS"
    ],
    "ansible_architecture": "x86_64",
    "ansible_bios_date": "09/20/2012",
    "ansible_bios_version": "6.00",
    "ansible_cmdline": {
        "BOOT_IMAGE": "/boot/vmlinuz-3.5.0-23-generic",
        "quiet": true,
        "ro": true,
        "root": "UUID=4195bff4-e157-4e41-8701-e93f0aec9e22",
        "splash": true
    },
    "ansible_date_time": {
        "date": "2013-10-02",
        "day": "02",
        "epoch": "1380756810",
        "hour": "19",
        "iso8601": "2013-10-02T23:33:30Z",
        "iso8601_micro": "2013-10-02T23:33:30.036070Z",
        "minute": "33",
        "month": "10",
        "second": "30",
        "time": "19:33:30",
        "tz": "EDT",
        "year": "2013"
    },
    "ansible_default_ipv4": {
        "address": "REDACTED",
        "alias": "eth0",
        "gateway": "REDACTED",
        "interface": "eth0",
        "macaddress": "REDACTED",
        "mtu": 1500,
        "netmask": "255.255.255.0",
        "network": "REDACTED",
        "type": "ether"
    },
    "ansible_default_ipv6": {},
    "ansible_devices": {
        "fd0": {
            "holders": [],
            "host": "",
            "model": null,
            "partitions": {},
            "removable": "1",
            "rotational": "1",
            "scheduler_mode": "deadline",
            "sectors": "0",
            "sectorsize": "512",
            "size": "0.00 Bytes",
            "support_discard": "0",
            "vendor": null
        },
        "sda": {
            "holders": [],
            "host": "SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 01)",
            "model": "VMware Virtual S",
            "partitions": {
                "sda1": {
                    "sectors": "39843840",
                    "sectorsize": 512,
                    "size": "19.00 GB",
                    "start": "2048"
                },
                "sda2": {
                    "sectors": "2",
                    "sectorsize": 512,
                    "size": "1.00 KB",
                    "start": "39847934"
                },
                "sda5": {
                    "sectors": "2093056",
                    "sectorsize": 512,
                    "size": "1022.00 MB",
                    "start": "39847936"
                }
            },
            "removable": "0",
            "rotational": "1",
            "scheduler_mode": "deadline",
            "sectors": "41943040",
            "sectorsize": "512",
            "size": "20.00 GB",
            "support_discard": "0",
            "vendor": "VMware,"
        },
        "sr0": {
            "holders": [],
            "host": "IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01)",
            "model": "VMware IDE CDR10",
            "partitions": {},
            "removable": "1",
            "rotational": "1",
            "scheduler_mode": "deadline",
            "sectors": "2097151",
            "sectorsize": "512",
            "size": "1024.00 MB",
            "support_discard": "0",
            "vendor": "NECVMWar"
        }
    },
    "ansible_distribution": "Ubuntu",
    "ansible_distribution_release": "precise",
    "ansible_distribution_version": "12.04",
    "ansible_domain": "",
    "ansible_env": {
        "COLORTERM": "gnome-terminal",
        "DISPLAY": ":0",
        "HOME": "/home/mdehaan",
        "LANG": "C",
        "LESSCLOSE": "/usr/bin/lesspipe %s %s",
        "LESSOPEN": "| /usr/bin/lesspipe %s",
        "LOGNAME": "root",
        "LS_COLORS": "rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36:",
        "MAIL": "/var/mail/root",
        "OLDPWD": "/root/ansible/docsite",
        "PATH": "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
        "PWD": "/root/ansible",
        "SHELL": "/bin/bash",
        "SHLVL": "1",
        "SUDO_COMMAND": "/bin/bash",
        "SUDO_GID": "1000",
        "SUDO_UID": "1000",
        "SUDO_USER": "mdehaan",
        "TERM": "xterm",
        "USER": "root",
        "USERNAME": "root",
        "XAUTHORITY": "/home/mdehaan/.Xauthority",
        "_": "/usr/local/bin/ansible"
    },
    "ansible_eth0": {
        "active": true,
        "device": "eth0",
        "ipv4": {
            "address": "REDACTED",
            "netmask": "255.255.255.0",
            "network": "REDACTED"
        },
        "ipv6": [
            {
                "address": "REDACTED",
                "prefix": "64",
                "scope": "link"
            }
        ],
        "macaddress": "REDACTED",
        "module": "e1000",
        "mtu": 1500,
        "type": "ether"
    },
    "ansible_form_factor": "Other",
    "ansible_fqdn": "ubuntu2.example.com",
    "ansible_hostname": "ubuntu2",
    "ansible_interfaces": [
        "lo",
        "eth0"
    ],
    "ansible_kernel": "3.5.0-23-generic",
    "ansible_lo": {
        "active": true,
        "device": "lo",
        "ipv4": {
            "address": "127.0.0.1",
            "netmask": "255.0.0.0",
            "network": "127.0.0.0"
        },
        "ipv6": [
            {
                "address": "::1",
                "prefix": "128",
                "scope": "host"
            }
        ],
        "mtu": 16436,
        "type": "loopback"
    },
    "ansible_lsb": {
        "codename": "precise",
        "description": "Ubuntu 12.04.2 LTS",
        "id": "Ubuntu",
        "major_release": "12",
        "release": "12.04"
    },
    "ansible_machine": "x86_64",
    "ansible_memfree_mb": 74,
    "ansible_memtotal_mb": 991,
    "ansible_mounts": [
        {
            "device": "/dev/sda1",
            "fstype": "ext4",
            "mount": "/",
            "options": "rw,errors=remount-ro",
            "size_available": 15032406016,
            "size_total": 20079898624
        }
    ],
    "ansible_nodename": "ubuntu2.example.com",
    "ansible_os_family": "Debian",
    "ansible_pkg_mgr": "apt",
    "ansible_processor": [
        "Intel(R) Core(TM) i7 CPU         860  @ 2.80GHz"
    ],
    "ansible_processor_cores": 1,
    "ansible_processor_count": 1,
    "ansible_processor_threads_per_core": 1,
    "ansible_processor_vcpus": 1,
    "ansible_product_name": "VMware Virtual Platform",
    "ansible_product_serial": "REDACTED",
    "ansible_product_uuid": "REDACTED",
    "ansible_product_version": "None",
    "ansible_python_version": "2.7.3",
    "ansible_selinux": false,
    "ansible_ssh_host_key_dsa_public": "REDACTED KEY VALUE",
    "ansible_ssh_host_key_ecdsa_public": "REDACTED KEY VALUE",
    "ansible_ssh_host_key_rsa_public": "REDACTED KEY VALUE",
    "ansible_swapfree_mb": 665,
    "ansible_swaptotal_mb": 1021,
    "ansible_system": "Linux",
    "ansible_system_vendor": "VMware, Inc.",
    "ansible_user_id": "root",
    "ansible_userspace_architecture": "x86_64",
    "ansible_userspace_bits": "64",
    "ansible_virtualization_role": "guest",
    "ansible_virtualization_type": "VMware"
}

上記において、1番目のハードディスクドライブの型番はテンプレートまたはplaybookで以下のように参照される。

{{ ansible_devices.sda.model }}

同様に、システムが報告するホスト名は次の通りです。

{{ ansible_nodename }}

最初のピリオドの前までの文字列のホスト名は以下のようになる。

{{ ansible_hostname }}

Factsは条件分岐(条件分岐参照)やテンプレートで頻繁に量される。

特定の条件に一致するような動的なホストグループを作成するためにFactsを利用できる。
詳細はモジュールを使って動かすのgroup_byを参照しろ。
同様に、条件分岐の章で説明した「一般化された条件分岐文」も参照しろ。

Factsを無効にする

あなたがあなたのホストについてのFactデータを知る必要がなく、あなたのシステムに関する全てを一元的にしっているならば、fact収集をオフにするこができる。
Fact収集のオフは主に非常に多くのシステムを伴うpushモードでAnsibleの実行時間を短縮するときや、あなたがAnsibleを実験環境で使用しているときに有利である。

- hosts: whatever
  gather_facts: no

ローカルFacts(Facts.d)

バージョン1.3の新機能

Playbookの章で説明したように、AnsibleのFactsはplaybook変数で使うリモートホストについてデータを取得する方法である。

通常、これらはAnsibleの設定モジュールによって自動的に検出される。
ユーザーはAPIガイドに記載されているようにカスタムFactモジュールを書くこともできる。
しかし、もしあなたがFactモジュールの記載なしでAnsible変数で使用するためのシステムを供給したいまたはユーザー供給データがほしい場合にはどうしたらよいか？

例えば、ユーザーがシステム管理についていくつかの局面をコントロールしたい場合はどうしたらよいか？

もしリモートで管理されるシステムが/etc/ansible/facts.dディレクトリおよびこのディレクトリ内に.factでおわるJSONまたはINI、JSONを返す実行可能ファイルを持つならば、AnsibleでローカルFactを提供できる。fact_pathディレクティブを使用して別のディレクトリを指定できる。

例えば、/etc/ansible/facts.d/preferences.factと仮定する。

[general]
asdf=1
bar=2

これは、メンバーとしてasdfとbarを持つgeneralという名前の連想配列変数を生成する。これを検証するには以下を実行する。

ansible <hostname> -m setup -a "filter=ansible_local"

すると、あなたは以下のFactが追加されていることが確認できるだろう。

"ansible_local": {
        "preferences": {
            "general": {
                "asdf" : "1",
                "bar"  : "2"
            }
        }
 }

このデータ以下のようにアクセスできる。

{{ ansible_local.preferences.general.asdf }}

ローカルの名前空間はユーザーが入力したFactがplaybook内の他の場所で定義されたシステムFactや変数が上書きされるのを防ぐ。

**注記**
key=valueのペアのキー部はansible_local変数の内部で小文字に変換される。上記の例でいえば、
iniファイルが``XYZ=3``を``[general]``セクションに含むならば
あなたは``{{ ansible_local.preferences.general.xyz }}``としてアクセスすべきであり、
``{{ ansible_local.preferences.general.XYZ }}``ではアクセスできない。
これはAnsibleが[optionxform](https://docs.python.org/2/library/configparser.html#ConfigParser.RawConfigParser.optionxform)メソッドを通して全てのオプション名を渡すPythonの[ConfigParser](https://docs.python.org/2/library/configparser.html)を使うためであり、このメソッドのデフォルトの実装がオプション名を小文字化するからです。

もしあなたがカスタムFactをコピーして実行しているplaybookを持っているならば、セットアップモジュールを再実行するための明示的な呼び出しを行うことで、その特定のplay中にそのFactを使用することができる。それ以外の場合は、Fact情報を収集する次のplayで利用可能になる。以下はその例です：

- hosts: webservers
  tasks:
    - name: create directory for ansible custom facts
      file: state=directory recurse=yes path=/etc/ansible/facts.d
    - name: install custom impi fact
      copy: src=ipmi.fact dest=/etc/ansible/facts.d
    - name: re-read facts after adding custom fact
      setup: filter=ansible_local

このパターンでは、Factモジュールも書くことができ、これをオプションとして考えることができる。

(以下未翻訳)

テンプレート(Jinja2)

変数セクションですでに述べたように、Ansibleは動的な式と変数へのアクセスを可能にするJinja2テンプレートを使っている。Ansibleはフィルターとテスト変数の数を拡張するだけでなく新しいプラグインタイプ：lookupsの追加も拡張する。

タスクが送信されてターゲットマシン上で実行される前にAnsible管理マシン側ですべてのテンプレーティングが実行されることに注意してください。これはターゲット上の要件を最小化する(jinja2は管理マシン上でのみ必要)ためで、タスクに必要な最小限の情報を渡すことができるため、ターゲットマシンは管理マシンがアクセスする全てのデータのコピーを必要としない。

フィルタ

AnsibleのフィルタはJinja2の機能であり、テンプレート式内部のデータを変換するために使われる。
Jinja2は多くのフィルタが付属している。公式Jinja2ドキュメント内の
(組み込みフィルタ)[http://jinja.pocoo.org/docs/templates/#builtin-filters]を参照しろ。

テンプレーティングはAnsible管理マシン上で実行され、タスクのターゲットホスト上ではないため、フィルタは管理マシン上でそれらがローカルデータを操作する際にフィルタも実行されることを考慮しろ。

加えて、Jinja2によって提供されるものとしてAnsibleはそれ自身を所有しており、ユーザーは独自のカスタムフィルタを追加できる。

データフォーマットフィルタ

次のフィルタはテンプレート内に書かれたデータの構造を取得し、異なるフォーマットで書き出す。これらはデバッグに便利なことがある：

{{ some_variable | to_json }}
{{ some_variable | to_yaml }}

人間が読める出力のためには以下のようにする：

{{ some_variable | to_nice_json }}
{{ some_variable | to_nice_yaml }}

両方のインデントを変更することも可能である(バージョン2.2の新機能)。

{{ some_variable | to_nice_json(indent=2) }}
{{ some_variable | to_nice_yaml(indent=8) }}

あるいは、すでにフォーマットされたデータを読むこともあるかもしれない。:

{{ some_variable | from_json }}
{{ some_variable | from_yaml }}

例えば

tasks:
  - shell: cat /some/path/to/file.json
    register: result

  - set_fact:
      myvar: "{{ result.stdout | from_json }}"

変数定義の強制

変数が定義されていない場合、Ansibleとansible.cfgでのデフォルトの振る舞いは「処理に失敗」になってしまうが、これをオフにすることができる。

この機能をオフにして明示的にチェックすることができる。

{{ variable | mandatory }}

変数は通常通りそのまま展開され、変数が定義されていない場合テンプレート評価時にエラーを吐くようになる。

定義されていない変数のデフォルト設定

Jinja2は変数が定義されていない場合の失敗」により適した'default'フィルタを提供する。

{{ some_variable | default(5) }}

上記の例では、変数'some_variable'が定義されていないならば、エラーが発生するのではなく、その値が「5」と扱われる。

変数が空の文字列に評価される場合は、フィルタの2番目のパラメータをtrueに設定する必要があります。：

{{ lookup('env', 'MY_USER') | default('admin', true) }}

(以下未翻訳)

条件分岐

多くの場合、playの結果は変数値、Fact(対象のリモートシステムから得られる情報)、または前のタスクの結果に依存する。
場合によっては、変数値は他の変数値に依存することもある。
対象ホストが他の基準にマッチするかに基づいて、ホストを管理するための追加グループを作成できる。
このトピックでは、playbookで条件分岐の使い方について説明する。

**注記**
Ansibleの実行フローを管理する多くのオプションがある。
より多くの条件分岐の例はここにある。:
http://jinja.pocoo.org/docs/dev/templates/#comparisons.

When文

特定のホストにおける特定の手順をスキップしたい場合があるだろう。
これは、OSが特定のバージョンであればとクチのパッケージをインストールしないというものであったり、ファイルシステムがいっぱいになったらクリーンアップの手順を実行するというものである。

これは、二重中カッコなしの生のJinja2式を含むwhen節を使ったAnsibleで簡単に実行できる(変数を参照)。

実際にはとても単純である:

tasks:
  - name: "shut down Debian flavored systems"
    command: /sbin/shutdown -t now
    when: ansible_os_family == "Debian"
    # Factとansible_os_familyのような変数は
    # 条件分岐内では二重中括弧なしで直接使われる

カッコを使用して条件分岐をグループ化することもできる。:

tasks:
  - name: "shut down CentOS 6 and Debian 7 systems"
    command: /sbin/shutdown -t now
    when: (ansible_distribution == "CentOS" and ansible_distribution_major_version == "6") or
          (ansible_distribution == "Debian" and ansible_distribution_major_version == "7")

全てが真でなければならないという複数の条件分岐(=論理積'and')はリスト的にも書ける。

tasks:

• name: "shut down CentOS 6 systems"
  command: /sbin/shutdown -t now
  when:
  • ansible_distribution == "CentOS"
  • ansible_distribution_major_version == "6"

Jinja2の"filters"のいくつかもwhen文で使われ、そのいくつかは固有でありAnsibleによって提供される。
1文のエラーを無視し、成功or失敗に基づいて条件付きで何かを実行することを決定したいとする:

tasks:
  - command: /bin/false
    register: result
    ignore_errors: True

  - command: /bin/something
    when: result is failed

  # 古いバージョンのAnsibleでは"successs"を使っており、今はsucceededがイマドキだが両方使える。
  - command: /bin/something_else
    when: result is succeeded

  - command: /bin/still/something_else
    when: result is skipped

--

**注記**
success と succeeded 両方とも動作する。(fail/failed なども)

リマインダとして、特定のシステムどのFactsを利用できるかを参照するには以下を実行する:

ansible hostname.example.com -m setup

ヒント：文字列の変数が返ってきて、それに対して数学的な演算の比較をしたいと思うことがあるだろう。以下のようにすればよい：

tasks:
  - shell: echo "only on Red Hat 6, derivatives, and later"
    when: ansible_os_family == "RedHat" and ansible_lsb.major_release|int >= 6

**注記**
上記の例で、ansible_lsb.major_release Factを返してくれるためには管理対象ホストに対してlsb_release パッケージがインストールされている必要がある

playbookまたはインベントリで定義された変数も使うことができる。
例えば、以下のような変数のBoolean値に基づいてタスクを実行するかもしれない：

vars:
  epic: true

この時の条件式は以下のような形:

tasks:
    - shell: echo "This certainly is epic!"
      when: epic

もしくは

tasks:
    - shell: echo "This certainly isn't epic!"
      when: not epic

もし必要な変数が設定されていなかったら、あなたはJinja2の定義済みテストを使用して、「スキップ」させるまたは「失敗」させることができる。例えば：

tasks:
    - shell: echo "I've got '{{ foo }}' and am not afraid to use it!"
      when: foo is defined

    - fail: msg="Bailing out. this play requires 'bar'"
      when: bar is undefined

これは、変数ファイル(下記参照)の条件付きインポートと組み合わせると特に便利である。例にあるように、条件分岐内で変数を使用するために"{{ }}"を使う必要はない。

ループ処理と条件分岐

ループ処理(ループ処理参照)にwhenを組み合わせると、when文がそれぞれの項目毎に対して個別に処理されることに注意せよ。これは仕様です：

tasks:
    - command: echo {{ item }}
      loop: [ 0, 2, 4, 6, 8, 10 ]
      when: item > 5

もし定義されているループ変数に依存するタスク全体をスキップしたいならば、空のイテレータを指定する"|default"フィルタを使え。

- command: echo {{ item }}
  loop: "{{ mylist|default([]) }}"
  when: item > 5

ループ内で辞書を使うならば以下の通り：

- command: echo {{ item.key }}
  loop: "{{ query('dict', mydict|default({})) }}"
  when: item.value > 5

カスタムFactでロード

必要に応じて独自Factを指定することも簡単である。
モジュールの開発で説明している。
それらを実行するためには、タスクリストの先頭で独自カスタムFact収集モジュールを呼び出すだけで、将来のタスクへのアクセスが可能になる。：

tasks:
    - name: gather site specific fact data
      action: site_facts
    - command: /usr/bin/thingy
      when: my_custom_fact_just_retrieved_from_the_remote_system == '1234'

ロール、インポート、インクルードにwhenを適用する

同じ条件分岐文を全て共有する複数のタスクがある場合、以下のようにタスクインクルード文へ条件付けができる。
全てのタスクが評価されるが、条件分岐が全てのタスクに対して適用されることにもなります。

- import_tasks: tasks/sometasks.yml
  when: "'reticulating splines' in output"

**注記**
バージョン2.0より前のバージョンでは、タスクインクルードのみ動作して
playbookのインクルードは動作しなかったが、バージョン2.0で両方とも可能になった。

また、ロールに対して条件分岐を適用するならば以下の通り：

- hosts: webservers
  roles:
     - { role: debian_stock_config, when: ansible_os_family == 'Debian' }

条件にマッチしないシステムに対しては、この方法ではAnsibleデフォルトで、大量の"skipped"が出力されることに注意せよ。
同様のことを実現するためのより効率的な方法についてはモジュールを使って動かすの"group_by"モジュールを参照せよ。

importの代わりに"include_*"taskを使うと,条件分岐はタスクのインクルード処理自体にのみ適用され、インクルードされるファイル内のその他のタスクには適用されない。この区別が重要となるのは以下のような状況：

# 変数が定義されていない場合、変数を定義するためにファイルをインクルードする

# main.yml
- include_tasks: other_tasks.yml
  when: x is not defined

# other_tasks.yml
- set_fact:
    x: foo
- debug:
    var: x

上記の例で、代わりにimport_tasksが使われていれば、両方のインクルード対象タスクがスキップされていた。include_tasksを仕様すると、条件分岐が適用されないため、タスクは期待通りに動作する。

条件付きインポート

**注記**
これはあまり仕様されない高度なトピックです

(以下未翻訳)

変数に基づくファイルとテンプレートの選択

**注記**
これはあまり使用されない高度なトピックです。
おそらくこのセクションをスキップすることができます。

レジスタ変数

playbookでは特定のコマンドの結果を変数に格納して後からそれにアクセスしたいときがある。
この方法でコマンドモジュールを使用すると、いろいろと特定のfactを記述する必要がなくなり、例えば特定のプログラムの存在チェックをすることができる。

'register'キーワードは結果を保存する変数を決定する。
その結果を保存した変数はテンプレート、アクション行や"when"文で使うことができる。
次のようになる：

- name: test play
  hosts: all

  tasks:
      - shell: cat /etc/motd
        register: motd_contents

      - shell: echo "motd contains the word hi"
        when: motd_contents.stdout.find('hi') != -1

前に示した通り、レジスタ変数の文字列は'stdout'値でアクセス可能になる。
レジスタ変数はリストに変換されるまたはすでにリストである場合、タスクのループ処理で以下に示すように使われる。

"stdout_lines"は既にオブジェクト上で利用可能ですが、必要に応じて "home_dirs.stdout.split（）"を呼び出すこともできますし、他のフィールドで分割することもできます：

- name: registered variable usage as a loop list
  hosts: all
  tasks:

    - name: retrieve the list of home directories
      command: ls /home
      register: home_dirs

    - name: add home dirs to the backup spooler
      file:
        path: /mnt/bkspool/{{ item }}
        src: /home/{{ item }}
        state: link
      loop: "{{ home_dirs.stdout_lines }}"
      # same as loop: "{{ home_dirs.stdout.split() }}"

前に示したように、登録変数の文字列の内容は 'stdout'値でアクセスできます。登録された変数の文字列の中身が空であるかどうかをチェックすることができます：

- name: check registered variable for emptiness
  hosts: all

  tasks:

      - name: list contents of directory
        command: ls mydir
        register: contents

      - name: check contents for emptiness
        debug:
          msg: "Directory is empty"
        when: contents.stdout == ""

よく使われるFacts

以下のFactはよく条件分岐で使われる。

ansible_distribution

以下のような値になる：

Alpine
Altlinux
Amazon
Archlinux
ClearLinux
Coreos
Debian
Gentoo
Mandriva
NA
OpenWrt
OracleLinux
RedHat
Slackware
SMGL
SUSE
VMwareESX

ansible_distribution_major_version

これはOSのメジャーバージョンになる。
例えばUbuntu 16.04.の値は16になる。

ansible_os_family

以下のような値になる：

AIX
Alpine
Altlinux
Archlinux
Darwin
Debian
FreeBSD
Gentoo
HP-UX
Mandrake
RedHat
SGML
Slackware
Solaris
Suse

ループ処理

大量のユーザー作成、大量のパッケージのインストール、特定の結果に達するまでポーリングのように一つのタスク内で多くのことをやりたいと思うかもしれません。

この章では、playbook内でループ処理を使う方法について説明します。

標準のループ処理

タイピング数を節約するために、繰り返されるタスクは以下のように短く書くことができます：

- name: add several users
  user:
    name: "{{ item }}"
    state: present
    groups: "wheel"
  loop:
     - testuser1
     - testuser2

もし変数ファイル内や"vars"セクションで定義されたYAML形式のリストがあるならば、次のようにもできる：

loop: "{{ somelist }}"

上記は次のものと同等である。

- name: add user testuser1
  user:
    name: "testuser1"
    state: present
    groups: "wheel"
- name: add user testuser2
  user:
    name: "testuser2"
    state: present
    groups: "wheel"

**注記**
Ansible2.5以前では主に``with_<lookup>``キーワードがループ処理を作るために使われ、
"loop"キーワードは基本的に``with_list``に似ている。

yumやaptモジュールのようないくつかのプラグインはそれらのオプションに直接的にリストを取り込むことができ、これはタスクをまたがってループするよりも最適である。
詳細はそれぞれのアクションのドキュメントを参照しなさい。以下は例です：

- name: optimal yum
  yum:
    name: "{{list_of_packages}}"
    state: present

- name: 最善のyumではなく、より遅いだけなく、 相互依存性の問題を引き起こすかもしれない
  yum:
    name: "{{item}}"
    state: present
  loop: "{{list_of_packages}}"

反復処理項目の型は単純な文字列のリストでなければならないわけではない。
ハッシュリストがあるならば、次のようにサブキーを参照できる。

- name: add several users
  user:
    name: "{{ item.name }}"
    state: present
   groups: "{{ item.groups }}"
loop:
  - { name: 'testuser1', groups: 'wheel' }
  - { name: 'testuser2', groups: 'root' }

条件分岐とループを組み合わせるとき、when:文はそれぞれの項目に対して個別に処理されることにも注意せよ。例についてはWhen文を参照せよ。

複雑なループ処理

単純なリスト以上のものを必要とすることもあるだろう。
Jinja2式を複雑なリストを作成するために使うことができる。
例えば、'nested'ルックアップを使ってリストを組み合わせることができる。

- name: give users access to multiple databases
  mysql_user:
    name: "{{ item[0] }}"
    priv: "{{ item[1] }}.*:ALL"
    append_privs: yes
    password: "foo"
  loop: "{{ query('nested', [ 'alice', 'bob' ], [ 'clientdb', 'employeedb', 'providerdb' ]) }}"

**注記**
``with_``ループは実際には``with_``と``lookup()``の組み合わせであり、``item``は検索である。``loop``を使って上記と同じようなことができる。

lookup vs query with loop

Ansible 2.5では、新しいjinja2関数が名前付きクエリに導入されました。これは、新しいloopキーワードを使用するときにlookupにいくつかの利点があります。

これはlookupのドキュメントで詳細に説明されていますが、queryではlookupプラグインのより簡単なインターフェイスと予測可能な出力が提供されloopとの互換性が向上します。

状況によっては、lookup関数がloopに必要なリストを返さないことがあります。

次の呼び出しは同等です。リストの戻り値型を保証するためにlookupでwantlist = Trueを使用します。

loop: "{{ query('nested', ['alice', 'bob'], ['clientdb', 'employeedb', 'providerdb']) }}"

loop: "{{ lookup('nested', ['alice', 'bob'], ['clientdb', 'employeedb', 'providerdb'], wantlist=True) }}"

Do-Until ループ処理

バージョン1.4の新機能

ある条件が満たされるまで、タスクを再試行したいことがあります。ここに例があります：

- shell: /usr/bin/foo
  register: result
  until: result.stdout.find("all systems go") != -1
  retries: 5
  delay: 10

上記の例では、shellモジュールの結果、標準出力に "all systems go"と出力されるか、またはタスクが10秒毎に5回再試行されるまで、shellモジュールを再帰的に実行します。 retries"のデフォルト値は3、"delay"のデフォルト値は5です。

タスクは、最後に実行したときの結果を返します。
それぞれの試行結果は、-vvオプションをつけると表示できます。
登録された変数には、タスクの再試行回数を持つ新しいキー"atempts"もあります。

**注記**
``until``パラメータが定義されていないならば、``retries``パラメータは強制的に1になる。

ループでレジスタを使う

(未翻訳)

インベントリをまたがってループする

(未翻訳)

ループ管理

(未翻訳)

Ansible2.0でのループ処理とインクルード

(未翻訳)

ブロック

高度なplaybookの機能

戦略

ベストプラクティス

特権撤去の理解

(未翻訳)

Ansible Vault

(未翻訳)

パターンを使って動かす

(未翻訳)

プラグインを使って動かす

(未翻訳)

Ansible コミュニティガイド

コミュニティガイドへようこそ。

Ansibleコミュニティの貢献メンバーになることについて、すべてのことを教えることが目的である。

以下のトピックのいずれかを選んで開始しろ。

Ansible開発プロセス

ロードマップ

Pull Requests

Ansibullbot

バグ修正とリクエスト機能

助ける方法

パワーユーザーになる

オンラインで質問を尋ねて答える

モジュール管理者ガイドライン

リリース管理者

リリースプロセス

コミュニケーション

他のツールとプログラム

開発者ガイド

Ansible開発者ガイドへようこそ。

このガイドの目的は、モジュールとプラグインの開発からプルリクエストを介したAnsible Core Engineの開発に至るまで、
コードを使ってAnsibleと対話して整形するために利用できるすべてのパスを文書化することです。

開始するには、次のいずれかのトピックを選択します。

Ansible アーキテクチャ

モジュール開発

Ansibleモジュールアーキテクチャ

補足：モジュールユーティリティ

プラグイン開発

…

VagrantとAnsibleを使う

紹介

Vagrantは仮想マシン環境を管理するツールであり、さまざまな仮想化やクラウドプラットフォームの上で再現可能な作業環境を構成し、使用することができます。
また、これらの仮想マシンの準備ツールとしてのAnsibleとの統合も行われており、この2つのツールはうまく連携しています。

このガイドでは、Vagrant 1.7+とAnsibleを一緒に使用する方法について説明します。

あなたがVagrantに慣れていない場合は、マニュアルを参照してください

このガイドは、既にAnsibleをインストールして使用していることを前提としています。
Gitのチェックアウトから実行しても問題ありません。詳しくは、「インストール・ガイド」の説明に従ってください。

Vagrantのセットアップ

Vagrantをインストールした後の最初のステップは、Vagrantfileを作成してニーズに合わせてカスタマイズすることです。
Vagrantのドキュメントで詳細に説明されていますが、ここでは単一のマシンを管理するためのAnsibleプロビジョナを使用するためのセクションを含む簡単な例を示します。

# This guide is optimized for Vagrant 1.7 and above.
# Although versions 1.6.x should behave very similarly, it is recommended
# to upgrade instead of disabling the requirement below.
Vagrant.require_version ">= 1.7.0"
		
Vagrant.configure(2) do |config|
		
 config.vm.box = "ubuntu/trusty64"
		
# Disable the new default behavior introduced in Vagrant 1.7, to
# ensure that all Vagrant machines will use the same SSH key pair.
# See https://github.com/mitchellh/vagrant/issues/5005
 config.ssh.insert_key = false
		
 config.vm.provision "ansible" do |ansible|
  ansible.verbose = "v"
  ansible.playbook = "playbook.yml"
 end
end

Vagrantfileと同じディレクトリにある「playbook.yml」というAniable playbookを参照する「config.vm.provision」セクションに注目してください。
仮想マシンが起動してSSHアクセスの準備が整ったら、Vagrantはプロビジョニングを実行します。

Vagrantfileで設定できる多くのAnsibleオプションがあります。詳細については、Ansible Provisionerのドキュメントを参照してください。

$ vagrant up

上記コマンドでVMが起動し、最初のVM起動時にプロビジョニングplaybookが実行される。

既存のVMでPlaybookを再実行するためには次のコマンドを実行する。

$ vagrant provision

これにより、既存のVMに対してplaybookが再実行されます。

ansible.verboseオプションを有効にすると、この例で示すように、Vagrantの裏で実行されている完全なansible-playbookコマンドを表示するように指示します。

この情報は、統合の問題をデバッグするのに非常に有用であり、次のセクションで説明するように、シェルから「Ansible」を手動で実行するためにも使用できます。

Ansibleの手動実行

場合によっては、マシンに対して手動でAnsibleを実行することもできます。これは、vagrant provisionをキックするよりも速く、かなり簡単です。

我々のVagrantfileの例では、Vagrantは「.vagrant/provisioners/ansible/inventory/vagrant_ansible_inventory」にインベントリファイルを自動的に作成します。
このインベントリは、Vagrantが自動的に作成するSSHトンネルに従って設定されます。
単一のマシン環境用の典型的な自動作成インベントリファイルは、次のようになります。
# Generated by Vagrant

default ansible_ssh_host=127.0.0.1 ansible_ssh_port=2222

もしあなたが手動でAnsibleを実行したいのであれば、少なくともあなたのユーザ名、SSH秘密鍵、インベントリに対して、ansible,ansible-playbookコマンドに正しい引数を渡す必要がある。

Vagrantのグローバル保護されていないキー（Vagrantファイルではconfig.ssh.insert_keyをfalseに設定する必要があります）を使用する例を次に示します。
$ ansible-playbook --private-key=~/.vagrant.d/insecure_private_key -u vagrant -i .vagrant/provisioners/ansible/inventory/vagrant_ansible_inventory playbook.yml

Vagrant 1.7+が新しいVMごとに自動的に設定するランダムな秘密鍵を使用する2番目の例を示します
（それぞれの鍵は.vagrant / machines / [プロバイダ名] / private_keyなどのパスに格納されます）。
$ ansible-playbook --private-key=.vagrant/machines/default/virtualbox/private_key -u vagrant -i .vagrant/provisioners/ansible/inventory/vagrant_ansible_inventory playbook.yml

ネットワーク自動化のためのAnsible

まえがき

安全なネットワークモジュールは、シンプルでパワフルなエージェントレスオートメーションの利点をネットワーク管理者やチームにまで拡張します。
可能なネットワークモジュールは、ネットワークスタックの構成、既存のネットワーク状態のテストと検証、およびネットワーク構成のドリフトの発見と修正を行うことができます。

あなたがAnsibleを初めて習得した場合、またはネットワーク管理のためにAnusesを初めて使用する場合は、Getting Started Guideから始めてください。

特定のネットワークモジュールの使用に関するドキュメントについては、すべてのネットワークモジュールのリストを参照してください。
一部のネットワークモジュールは、Ansibleコミュニティによって管理されています。ここには、Anecess Networkチームによって管理されているネットワークモジュールのリストがあります。

開始する

ユーザーガイド

モジュールインデックス

全モジュール

• get_url

Playbook キーワード

playbook共通で利用できるキーワードである。

** 注記 **		
ディレクティブのエイリアスはここには反映されず、変更可能なエイリアスもありません。		
たとえば、タスク内のアクションは、任意のAnsibleモジュールの名前で置き換えることができます。		
		
現時点でそのキーワードはversion_added情報を持っていない		
		
キーワードの中には、オブジェクト自体ではなく、オブジェクト内部のオブジェクトのデフォルトを設定するものがあります		

用語集

以下は、Ansibleのドキュメントの他の場所で使用されている用語定義のリスト（および再説明）です。

完全なドキュメントと文脈で用語を見るためには、ドキュメントのホームページを参照してください。
しかし、これはAnsibleのコンポーネントに関する知識を確認し、それらがどのように適合するかを理解するのには良いリソースです。
それは、あなたが見直しのために読んだり、メーリングリストに用語が現れたりしたときに読んでみたいことかもしれません。

Action

アクションは、実行するモジュールとそのモジュールに渡す引数を指定するタスクの一部です。
各タスクは1つのアクションしか持つことはできませんが、他のパラメータを持つこともできます。

Ad Hoc

(以下未翻訳)