2022-09-20

【インベントリー概要】構築方法　３章：ホストへの接続

Ansible

５．動作用のイベントリーパラメーター

変数を設定して、Ansibleがリモートホストと対話する方法を制御します。

パラメータ	説明
ansible_connection	ホストへの接続の種類 ansiblleの接続プラグインの名前を使用できます。 SSH プロトコルタイプは、`smart`、`ssh`、または`paramiko`です。デフォルトは`smart`です。
ansible_host	接続するホストの名前(割り当てたいエイリアスと異なる場合)
ansible_port	デフォルトではない場合(sshの場合は22)は、接続ポート番号
ansible_user	ホストに接続する際に使用するユーザ名
ansibl_pasword	ホストへの認証に使用するパスワード (この変数をプレーンテキストで保存しないでください。常にVaultを使用してください。)

SSH接続の固有キーのパラメーター

パラメータ	説明
ansible_ssh_private_key_file	sshが使用する秘密鍵複数のキーを使用し、SSHエージェントを使用しない場合に便利
ansible_ssh_common_args	この設定は、常に`sftp`、`scp`および`ssh`のデフォルトのコマンドラインに追加されます。特定のホスト(またはグループ)に`proxyCommand`を設定するのに便利です。
ansible_sftp_extra_args	この設定は、常にドフォルトの`sftp`コマンドラインに追加されます。
ansible_scp_extra_args	この設定は、常にデフォルトの`scp`コマンドラインに追加されます
ansible_ssh_pipelining	SSHパイプラインを使用するかどうかを決めます。これにより、`ansible.cfg`の`pipelining`設定を上書きできます。
ansible_ssh_executable	この設定により、システムの`ssh`を使用するデフォルトの動作が上書きされます。これにより、`ansible.cfg`の`ssh_executable`設定を上書きできます。

権限の昇格　詳細はこちら

パラメータ	説明
ansible_become	`ansible_sudo`または`ansible_su`と同等です。これにより、権限のエスカレーションが強制できます。
ansible_become_method	権限昇格メソッドの設定を許可します。
ansible_become_user	`ansible_sudo_user`または`ansible_su_user`と同等で、権限の昇格でユーザーを設定できます。
ansible_become_password	`ansible_sudo`または`ansible_su`と同等で、権限昇格パスワードを設定できます。 (この変数をプレーンテキストで保存しないでください。常にVaultを使用してください。)
ansible_become_exe	`ansible_sudo`または`ansible_su`と同等で、選択した昇格メソッドの実行ファイルを設定できます。
ansible_become_flags	`ansible_sudo_flags`または`ansible_su_flags`と同等で、選択した昇格メソッドに渡すフラグを設定出来ます。これは、`sudo_flags`オプションの`absible.cfg`でグローバルに設定することも出来ます。

リモートホスト環境パラメーター

パラメータ	説明
ansible_shell_type	ターゲットシステムのシェルタイプ ansible_shell_executableを非Bourme(sh)しない限り、この設定は使用しないでくださいデフォルトコマンドは`sh`スタイルの構文を使用してフォーマットこれを`csh`または`fish`に設定すると、ターゲットシステムで実行差sれるコマンドがシェル構文に従います。
ansible_python_interpreter	ターゲットホストのPythonパスこれは、複数のPythonがあるシステム、またはBSDなどの /usr/bin/python にないシステム、または /usr/bin/python が2.XシリーズのPython以外のシステムに役に立ちます。 /usr/bin/env メカニズムを使用しません。リモートユーザーのパスを正しく設定する必要があり、また python 実行ファイルの名前がpythonであることを前提としています。 python2.6*のようになります。
ansible*interpreter	rubyやperlなどのあらゆるもので動作し、ansible_pyton_interpreter と同じように機能します。これは、ホストで実行するモジューつのシバンに代わるものです。

New in version2.1

パラメータ	説明
ansible_shell_executable	ansibleコントローラがターゲットマシンで使用するシェルを設定し、`ansible.cfg`の`executable`を上書きします。このデフォルトは /bin/sh です /bin/shを使用できない場合(つまり /bin/sh がターゲットマシンにインストールされず、sudoから実行できない場合)に限り変更してください。

Ansibile-INIホストファイルの例

some_host         ansible_port=2222     ansible_user=manager
aws_host          ansible_ssh_private_key_file=/home/example/.ssh/aws.pem
freebsd_host      ansible_python_interpreter=/usr/local/bin/python
ruby_module_host  ansible_ruby_interpreter=/usr/bin/ruby.1.9.3

５−１．SSH以外の接続タイプ

ホスト固有のパラメータansible_connection=<connector>を使用すると、接続タイプを変更できます。以下のパラメーターは、このコネクターより処理されます。

パラメータ	説明
local	このコネクターは、Playbookをコントロールマシン自体にデプロイするために使用できます。
docker	このコネクターは、ローカルのDockerクライアントを使用してPlaybokを直接Dokcerコンテナにデプロイします。
ansible_host	接続先のDockerコンテナの名前
ansibel_user	コンテナ内で動作するユーザ名ユーザーはコンテナ内に存在している必要があります。
ansible_become	`true`に設定すると、`become_user`はコンテナ内で動作するために使用されます
ansible_docker_extra_args	Dockerが認識する追加の引数を持つ文字列を指定できますが、これはコマンド固有ではありません。このパラメーターは、主に、使用するDockerデーモンを設定するために使用されます

以下は、作成されたコンテナに即時にデプロイする例を示しています。

- name: create jenkins container
  docker_container:
    docker_host: myserver.net:4243
    name: my_jenkins
    image: jenkins

- name: add container to inventory
  add_host:
    name: my_jenkins
    ansible_connection: docker
    ansible_docker_extra_args: "--tlsverify --tlscacert=/path/to/ca.pem --tlscert=/path/to/client-cert.pem --tlskey=/path/to/client-key.pem -H=tcp://myserver.net:4243"
    ansible_user: jenkins
  changed_when: false

- name: create directory for ssh keys
  delegate_to: my_jenkins
  file:
    path: "/var/jenkins_home/.ssh/jupiter"
    state: directory

利用可能なプラグインとサンプルの一覧は、プラグイン一覧を参照してください。

vault

Ansible Vault を試す - Qiita

Ansibleでパスワードなどの機密情報を暗号化して管理する | akamist blog

ansible-playbook -i hosts site.yml --ask-vault-pass

--ask-vault-passでプロンプトを表示させるか
--vault-password-file=VAULT_PASSWORD_FILEでパスワードの書かれたファイルを指定します。

--ask-vault-passを付けて、ansible-playbookコマンドを実行すると
Valut passwordとの入力が求められるので、暗号化した時のパスワードを入力すると復号化が可能

playbook1.yml

- hosts: group1
  remote_user: root

  tasks:
  - name: ls
    command: ls
    become: yes
    register: result_ls
  - name: result_ls
    debug:
      msg: "{{ result_ls.stdout }}"

項目	説明
hosts	実行対象のグループやホスト名を指定
tasks	実行するタスクを実行順に記述
name	実行するタスク名を指定（コメントみたいに何を記載しても大丈夫）
command	指定したOSコマンドを実行するモジュール
become	権限昇格をアクティブにするにはyesに設定
register	モジュールの結果を記載した変数名に格納するように指定
debug	msgで指定した文字列を出力するモジュール

コマンド実行

 ansible-playbook -i hosts playbook1.yml

実行先のホスト及びユーザ

hosts

hostsはコロンで区切られた１つ以上のグループまたはホストパターンのリストです。

- hosts: webserver

remote_user

remote_userは、ユーザアカウントの名前

remote_user: root

becomeの使用

権限昇格の理解: become — Ansible Documentation

playレベルまたはtaskレベルでbecomeを制御するディレクティブを設定できます。
接続変数をホストに設定すると、その変数を上書きできます。

これは多くの場合は、ホスト間で異なります。
これらの変数とディレクティブは独立しています。
become_userを設定するとbecomeに設定されません。

become 権限昇格をアクティブにするにはyesに設定
become_user 希望する権限を持つユーザに設定
ログインしたユーザではなく、becomeを行ったユーザ名になります。
ホストレベルで設定できるbecome:yesを意味しているわけではありません。
デフォルトはrootになります。
become_method playレベル、taskレベル
ansible.cfgに設定されたデフォルトのメソッドをオーバーライドして、
becomeプラグインを使用するよう設定しまします。
become_flags playレベル、taskレベルタスクまたはロールの特定フラグを使用できます。
シェルにno loginを設定する場合は、ユーザをnobodyに変更するのが一般的な方法。
Ansible2.2で追加

使用例

root以外のユーザとして接続する際にシステム・サービスを管理
become_user(root)がデフォルトで使用できます。

 - name: Ensure the httpd service is running
  service:
    name: httpd
    state: started
  become: yes

apacheユーザとしてコマンド実行するには、次を実行します。

 - name: Run a command as the apache user
  command: somecommand
  become: yes
  become_user: apache

シェルがnologingの場合にnobodyユーザとして操作を行う場合は、次を実行します。

 - name: Run a command as nobody
  command: somecommand
  become: yes
  become_method: su
  become_user: nobody
  become_flags: '-s /bin/sh'

sudoのパスワードを指定する必要がある場合 ansible-playbookに--ask-become-passまたは-Kを付けて実行します。

becomeを使用してPlaybookを実行し、
Playbookがハングしているように見える場合は、
おそらく権限昇格のプロンプトでスタックしており、Control-Cを使用して停止できます。

これにより、適切なパスワードを追加してPlaybookを再実行できます。

タスクリスト

各プレイには宅リストが含まれる。
タスクは、次のタスクに進む前に、ホスト「ターンに一致するすべてのマシンに対して、
一度に１つす順番に実行されます。

Ansible実行時の詳細ログを出力

Ansibleの実行時、以下のように-vvvを引数に追加
詳細な情報が表示されます。

Playbookの実行が失敗する場合、この引数を追加し実行を行い、原因特定を行う。

ansible-playbook -i hosts hoge.yml -vvv

指定された文字列をそのまま画面表示を行う「debug」

debugモジュールは引数msgに指定された文字列をそのまま画面に表示

tasks:
  - debug: msg="文字列を入力すると表示されます。"

変数の場合は以下の通り

vars:
  debug_msg: message
tasks:
  - debug: {{ debug_msg }}

参考サイト

Playbook実行後の戻り値【公式】Playbookの概要

2022-09-13

【インベントリー概要】構築方法　２章：変数の追加

Ansible

インベントリーへの変数追加

特定のホストまたはグループに関連する変数の値をイベントリーに保存できます。
メインのイベントリーファイルのホスト及びグループに変数を直接追加することが出来ます。
管理ノードをAnsibleイベントリーに追加するため、変数を別々のホスト変数およびグループ変数のファイルに保存することが推奨されます。

２．あるマシンへの変数の割り当て：ホスト変数

１台のホスト変数を簡単に割り当てると、後でPlaybookで使用できます。 INIの場合は、以下のようになります。

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

YAMLの場合は、以下のようになります。

atlanta:
  host1:
    http_port: 80
    maxRequestsPerChild: 808
  host2:
    http_port: 303
    maxRequestsPerChild: 909

非標準のSSHポートなどの一意な値は、ホスト変数として機能します。
コロンを使用してポート番号をホスト名の後に追加することで、ホスト変数としてAnsibleイベントリーに追加できます。

badwolf.example.com:5309

接続数もホスト変数として機能します。

[targets]

localhost              ansible_connection=local
other1.example.com     ansible_connection=ssh        ansible_user=myuser
other2.example.com     ansible_connection=ssh        ansible_user=myotheruser

Note SSH設定ファイル内に非標準のSSHポートの一覧を表示した場合、openssh接続はそのポートを見つけて使用しますが、paramiko接続は行われません

２−１．インベントリーエイリアス

エイリアスをインベントリーに定義することも出来ます。
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に接続します。
これは、静的IPがあるホスト、またはトンネル経由で接続しているホストでのみ機能します。

Note

key-value構文をしようしてINI形式で渡される値が解釈される方法は、宣言される場所に応じて異なります。

・ホストとインラインで宣言すると、INI値はPython リテラル構造(文字列、数値、リスト、辞書、プール値、なし)として解釈されます。　ホスト業は、行ごとに複数のkey=valueパラメータを受け入れます。　そのため、空白文字を区切り文字ではなく値の一部であることを示す方法が必要になります。

・:varsセクションで宣言すると、INI値は文字列として解釈されます。　例えば、var=FALSEは「FALSE」に等しい文字列を作成します。　ホスト行とは異なり、:varsセクションは行ごとにエントリーを１つしか受け入れないため、=に続くものはすべてエントリーの値である必要があります。

・INIイベントリーに設定された変数の値を特定のタイプ(文字列やプール値など)にする必要がある場合は、タスクで常にそのタイプをフィルターで指定します。　変数の使用時にINIインベントリーに設定されたタイプに依存しないでください

・変数の実際のタイプの混乱を避けるために、インベントリーソースにはYAML形式を使用することを検討してください。　 YAMLイベントリープラグインは、変数の値を一貫して正しく処理します。

通常は、システムポリシーを記述する変数を定義するのが最適な方法ではありません。
メインのイベントリーファイルで変数を設定するのは簡単な方法です。
「hosts_vars」ディレクトリーの個別ファイルに変数の値を保存するガイドラインはホスト変数とグループ変数の整理を参照してください。

３．多くのマシンへの変数の割り当て：グループ変数

グループのすべてのホストが変数値を共有している場合は、その変数をグループ全体に一度に適用できます。 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

グループ変数は、変数を複数のホストに当時に適用する場合に便利

ただし、Ansibleを実行する前に、イベントリー変数などの変数は常にホストレベルにフラットにします。
ホストが複数グループのメンバーである場合、Ansibleは、そのすべてのグループからヘンスの値を読み取ります。
異なるグループ内の同じ変数に異なる値を割り当てる場合、Ansibleは内部のマージ用ルールに基づいて、使用する値を選択します。

４．変数値の継承：グループのグループ用グループ変数

INIの:children接尾辞またはYAMLのchildren:エントリーを使用して、グループのグループ作成できます。
変数は、:varsまたはvars:を使用して、これらのグループのグループに適用できます。

INIの場合は、以下のようになります。

[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

YAMLの場合は、以下のようになります。

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:

一覧またはハッシュデータを保持する必要がある場合や
イベントリーファイルとは別にホスト及びグループ固有の変数を保持する必要がある場合
ホスト変数とグループ変数の整理を参照してください

子グループのメンバーであるホストは、自動的に親グループのメンバーになります。
子グループの変数は、親グループの変数よりも優先度が高くなります（オーバライド）
グループに複数の親と子を追加することは出来ますが、循環関係は設定できません。
ホストは複数のグループに属することもできますが、ホストのインスタンスは１つだけであり、複数のグループからのデータをマージします。

2022-09-12

【インベントリー概要】構築方法　１章：基本

Ansible

インベントリーの構築方法

Ansibleは、インベントリーと呼ばれるリスト、またはリストのグループを使用してインフラストラクチャーにある複数管理ノードまたは「ホスト」に対して同時に機能します。
インベントリーのデフォルトの場所は以下のファイルです。

/etc/ansible/hosts

以下のオプションを使用して、コマンドラインで別のイベントリーファイルを指定可能

-i <path>

動的イベントリーでの使用で説明されているように、複数のイベントリーファイルを同時に使用したり、動的またはクラウドのソースまたは異なる形式(YAML,iniなど)からづくすうのイベントリーを取得(プル)することも出来る。
Ansibleには、inventoryプラグインがあり、柔軟にカスタマイズ可能　バージョン2.4で導入

１．イベントリーの基本：形式、ホスト、およびグループ

イベントリーファイルは、所有するイベントリープラグインに応じて、以下の多くの形式のいずれかになります。最も一般的な形式はINIおよびYAML形式です

基本的な`INIである/etc/ansible/hosts`は以下のようになります。

mail.example.com

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

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

カッコ内の見出しはグループ内で、ホストを分類し、どの時点で、どのような目的で、どのホストを制御するのかを決定するのに使用されます。

基本的な`YAMLである/etc/ansible/hosts`は以下のようになります。

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:

１−１．デフォルトのグループ

デフォルトのグループはallおよび、ungroupedです。

グループ名	説明
allグループ	全てのホストが含まれます
ungroupedグループ	ユーザーによって明示的にグループへの紐付けがされていない全てのホストが所属するグループ

allグループの例

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:

この設定の場合以下のホスト名が含まれる

mail.example.com
foo.example.com
bar.example.com
one.example.com
two.example.com
three.example.com

ungroupedグループの例

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:

この設定の場合以下の children配下ではない、ホスト名が含まれる

mail.example.com

補足：childern

子グループを定義する時の宣言

管理対象のノードを共通な内容でグルーピングします。上記の設定の場合以下のような子グループに分かれます。

#	ホスト名	用途
1	mail.example.com	-
2	foo.example.com	webservers
3	bar.example.com	webservers
4	one.example.com	dbservers
5	two.example.com	dbservers
6	three.example.com	dbservers

１−２．複数グループ内のホスト

各ホストを複数のグループに配置

例：Atlantaのデータセンター内の実稼働Webサーバは [prod],[atlanta]および[webservers]と呼ばれるグループに含まれる場合があります。以下を追跡するグループ作成できます。

項目	説明
なにを	アプリケーション、スタック、またはマイクロサービス(データベースサーバ,Webサーバなど)
どこで	(ローカルDNS,ストレージなどと通信する)データセンターまたはリージョン(例：東、西)
いつ	実稼働リソースでのテストを回避する開発ステージ(例：実稼働、テスト)

「いつ、どこで、なにを」が含まれるようにします。

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:
    east:
      hosts:
        foo.example.com:
        one.example.com:
        two.example.com:
    west:
      hosts:
        bar.example.com:
        three.example.com:
    prod:
      hosts:
        foo.example.com:
        one.example.com:
        two.example.com:
    test:
      hosts:
        bar.example.com:
        three.example.com:

one.exampple.comが sbservers,east,prodグループに存在することを確認出来る。

このイベントりーのprod,testを簡略化するために、ネストされたグループを使用することも出来ます。

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:
    east:
      hosts:
        foo.example.com:
        one.example.com:
        two.example.com:
    west:
      hosts:
        bar.example.com:
        three.example.com:
    prod:
      children:
        east:
    test:
      children:
        west:

イベントリーを整理し、ホストをグループ化する方法は、イベントリーの設定例を参照してください。

１−３．ホスト範囲の追加

同様のパターンを持つホストが複数ある場合は、各ホスト名を個別に表示するのではなくホスト範囲として追加できます。

INIの場合は以下のようになります。

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

YAMLの場合は以下のようになります。

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

数値のパターンでは、必要に応じて、先頭にゼロを含めるか、または削除出来ます。

また、アルファベットの範囲を定義することも出来ます。

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

2022-09-08

【PlayBook概要】構築方法　４章：Playbookの実行

Ansible

Playbookの実行

並列処理レベル１０を使用してPlaybookを実行

ansible-playbook playbook.yml -f 10

Ansible-Pull

ansible-pullは、gitから設定手順のリポジトリをチェックアウトし、そのコンテンツに対してansible-playbookを実行する小さなスクリプトです。
チェックアウトの場所を負荷分散する場合、ansible-pullは基本的に無限にスケーリングします。
詳細は、ansible-pull --helpを実行してください
プッシュモードからのcrontabでansible-pullを設定する際に利用可能なclever playbookもあります。

Playbook文法チェック

ansible-lintを使用してPlaybookの詳細チェックを実行する前にPlaybookを実行可能

例：
verify-apache/yml playbookでansible-lintを実行すると以下の結果を得られます。

$ ansible-lint verify-apache.yml
[403] Package installs should not use latest
verify-apache.yml:8
Task/Handler: ensure apache is at the latest version

ansible-lintのデフォルトルールページでは、各エラーが説明されています。 [403]の場合に推奨される修正は、Playbookのsate: latestをstate: presentに変更する。

その他のPlaybook検証オプション

Playbookの検証に使用できるツールの詳細なリストは、Playbookを検証するためのツールを参照してください。

playbookの構文を確認するには、--syntax-checkフラグを指定してansible-playbookを使用します。 (これにより、パーサーを介してPlaybookファイルが実行され、インクルードダイルやろ０るなどに構文上の問題が無いことが確認されます。)
Playbookの実行の下部を見て、対象となったノードの概要やその実行方法を確認します。 (一般的な障害と、致命的な「到達不能」な通信の試行は、個別にカウントされます。)
成功したモジュールだけでなく、失敗したモジュールからの詳細な出力を表示する場合は、--verboseフラグを使用します。 (これは、Ansible0.5以降で利用できます。)
実行する前にPlaybbokの影響を受けるホストを確認するには、次のようにします

ansible-playbook playbook.yml --list-hosts

2022-09-07

【PlayBook概要】構築方法　３章：タスク

Ansible

各Playにはタスクリストが含まれている

タスクは、次のタスクに進む前に、ホストパターンに一致するマシンに対して、一度に１つずつ順番に実行されます。
Play内では、全てのホストが同じタスクディレクティブを取得することを理解することが重要。
Playの目的は、選択したホストをタスクにマップすることです。
上から下に実行されるPlaybookを実行すると、タスクが失敗したホストは、Playbook全体のローテーションから除外されます。
問題が発生した場合は、Playbookファイルを修正し、再実行します。

各タスクの目的

非常に具体的な引数を使用してモジュールを実行することです。
変数はモジュールの引数で使用できます。
モジュールは冪等(べきとう)である必要があります。
モジュールをシーケンスで複数回実行すると、１回だけ実行した場合と同じ結果になります。
冪等性(べきとうせい)を達成する１つの方法は、モジュールに目的の最終状態がすでに実現しているかどうかを確認し、その状態が実現している場合は、アクションを実行せずに終了することです。

important

Playbookが使用するすべてのモジュールの冪等(べきとう)である場合は、Playbook自体が冪等(べきとう)である可能性が高いため、Playbookを再実行しても安全です。

commandモジュールとshellモジュール

通常、同じコマンドを実行します。
chmodまたはsetseboolなどのコマンドの場合は、まったく問題ありません。
これらのモジュールを冪等(べきとう)にするために使用できるcreatesフラグが利用できます。

すべてのタスクにはnameが必要です。これは、Playbookの実行から出力に含まれます。

人間が読める形式の出力であるため、各タスクステップの適切な説明を提供すると便利です。ただし、名前が指定されてない場合は、actionに渡される文字列が出力されます。

推奨は

タスクは、レガシーのaction:module option形式を使用して宣言出来ますがより一般的なmodule:option形式を使用することが推奨されます。

この推奨される形式はドキュメント全体で使用されていますが 一部のPlaybookでは古い形式を使用している場合があります。

以下は基本的なタスクです。ほとんどのモジュールの場合と同様、サービスモジュールはkey=value引数をとります。

tasks:
  - name: make sure apache is running
    service:
      name: httpd
      state: started

commandモジュールとshellモジュールは

引数のリストを取り、key=value形式を使用しないユイツのモジュールです。これにより、それらは予想どおりに機能します。

name: enable selinux command: /sbin/setenforce 1

commandモジュールとshellモジュールは戻りコードを処理するためコマンドがあり、その正常な終了コードがゼロでない場合は以下を行うことが出来ます。

name: run this command and ignore the result shell: /usr/bin/somecommand || /bin/true

アクション行が長すぎて快適ではなくなった場合

スペースで改行し、継続している行にインシデントを追加できます。

name:Copy ansible inventory file to client copy: src=/etc/ansible/hosts dest=/etc/ansible/hosts
owner=root group=root mode=0644

変数はアクション行で使用できます。たとえば、varsセクションでvhostという名前の変数定義したとすると、次のようになります。

name: create a virtual host file for {{ vhost }} template:
src: somefile.j2 dest: /etc/httpd/conf.d/{{ vhost }}

同じような変数は、後で使用するテンプレートで使用できます。

非常に基本的なPlaybookでは、すべてのタスクがそのPlayに直接リストされますが通常は「再利用可能なPlaybookの作成」の説明に従って、タスクを破損せる方が分かりやすくなります。

アクション(短縮形表記)

Ansibleでは、以下のようなモジュールリストが推奨されます。

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

Ansibleの初期バージョンでは以下の形式が使用されていましたが、これは引き続き動作します。

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

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

モジュールは冪等(べきとう)である必要があり、リモートシステムに変更を加えた時にリレーできます。Playbookはこれを認識し、変化に対応すために使用できる基本的なイベントシステムを備えています。

これらの「通知」アクションは、Playのタスクの各ブロックの最後にトリガーされ、複数の異なるタスクから通知された場合でも１回だけトリガーされます。

たとえば、複数のリソースが設定ファイルを変更したためにApacheを再起動する必要があることを示している場合がありますが、不必要な再起動を回避するために、Apacheは１回だけバウンスされます。

<実例>
次に、ファイルの内容が変更された時に２つのサービスを再起動する。
ファイルが変更された場合のみ

name: template configuration file template:
src: template.j2 dest: /etc/foo.conf

#ハンドラーと呼ばれている
notify:
restart memcached
restart apache

タスクのnotifyセクションに挙げられているものは、ハンドラーと呼ばれています。

ハンドラーとは

タスクのリストであり、通常のタスクとの違いはない。
グローバルに一意の名前で参照され、通知機能によって通知されます。
ハンドラーは何も通知しないと、実行されません。
ハンドラーに通知するタスクの数に関係なく、特定のPlayでタスクがすべて完了すると、ハンドラーは１回だけ実行されます。

以下は、ハンドラーセクションの例

handlers:
    - name: restart memcached
      service:
        name: memcached
        state: restarted
    - name: restart apache
      service:
        name: apache
        state: restarted

Ansibleハンドラーが変数を使用することが望ましい場合があります。
たとえば、サービスの名前がディストリビューションによって若干異なる場合は、出力で各ターゲットマシンについて再起動したサービスの正確な名前を表示させる必要があります。
ハンドラーの名前を変数にしないようにします。

ハンドラー名はすぐにテンプレート化されるため、Ansibleには以下のように、ハンドラー名に使用できない値がない場合がある。

handlers: # this handler name may cause your play to fail! - name: restart “{{ web_service_name }}”

ハンドラー名で使用される変数が使用出来ない場合 Play全体が失敗します。この変数を中間のPlayに変更すると、ハンドラーは新たには作成されません。

代わりに、変数をハンドラーのtaskパラメータに設定します。以下のようなinclude_varsを使用して値を読み込むことが出来ます。

tasks:
  - name:Set host variables based on distribution
    include_vars: "{{ ansible_facts.distribution }}.yml"

handlers:
  name: restart web service service:
  name: “{{ web_service_name | default(‘httpd’) }}” state: restarted

Ansible2.2以降、ハンドラーは一般的なトピックを「リッスン」することもでき、タスクは次のようにそれらのトピックに通知できます。

handlers:
  name: restart memcached service:
  name: memcached state: restarted
  listen: “restart web services”
  name: restart apache service:
  name: apache state: restarted
  listen: “restart web services”

tasks:
  name: restart everything command: echo “this task will restart the web services” notify: “restart web services”

この使用により、複数のハンドラーをトリガーすることがはるかに簡単になります。

また、ハンドラーを名前から切り離し、Playbookとロールの間でハンドラーを共有しやくします。 (特にGalaxyなどの共有ソースからサードパーティのロールを使用する場合)

note

・通知ハンドラーは常に、notify-statementに記載される順番ではなく、
　定義される順序で実行されます。これは、listenを使用するハンドラーの場合
　でも当てはまります。
・ハンドラー名とlistenトピックは、グローバルな名前空間にあります。
・ハンドラー名は一時的なものですが、listenトピックは一時的ではありません。
・固有のハンドラー名を使用します。
　同じ名前のハンドラーを複数トリガーすると、最初のハンドラーが上書きされます。
　定義された最後のモノのみが実行されます。
・インクルード内で定義されたハンドラーに通知することは出来ません。
　Ansible2.1の時点ではこれは機能しますが、包含は静的だある必要がります。

ロールについては、次の点に注意してください。

・pre_taskセクション、taskセクション、およびpost_taskセクション内で通知される
　ハンドラーは、通知されたセクションの最後に自動的にフラッシュされます。

・rolesセクション内で通知されるハンドラーは、tasksセクションの最後ではなく、
　tasksハンドラーの前に自動的にフラッシュされます。

・ハンドラーはスコープのあるPlayであるため、
　ハンドラーは定義されているロールの外で使用できます。

すべてのハンドラーコマンドをすぐにフラッシュする必要のある場合は、
以下を実行できます。

tasks:
shell: some tasks go here
meta: flush_handlers
shell: some other tasks

上記の例では、metaステートメントに到達したときに、キューに入れられたハンドラーが処理されます。
これは少しニッチなケースですが、時々役に立ちます。

５．動作用のイベントリーパラメーター

SSH接続の固有キーのパラメーター

権限の昇格 詳細はこちら

５−１．SSH以外の接続タイプ

vault

実行先のホスト及びユーザ

hosts

remote_user

becomeの使用

使用例

タスクリスト

Ansible実行時の詳細ログを出力

指定された文字列をそのまま画面表示を行う「debug」

参考サイト

インベントリーへの変数追加

２．あるマシンへの変数の割り当て：ホスト変数

２−１．インベントリーエイリアス

Note

３．多くのマシンへの変数の割り当て：グループ変数

４．変数値の継承：グループのグループ用グループ変数

インベントリーの構築方法

１．イベントリーの基本：形式、ホスト、およびグループ

基本的なINIである/etc/ansible/hostsは以下のようになります。

基本的なYAMLである/etc/ansible/hostsは以下のようになります。

１−１．デフォルトのグループ

allグループの例

ungroupedグループの例

補足：childern

１−２．複数グループ内のホスト

１−３．ホスト範囲の追加

Playbookの実行

Ansible-Pull

Playbook文法チェック

その他のPlaybook検証オプション

各Playにはタスクリストが含まれている

各タスクの目的

important

commandモジュールとshellモジュール

推奨は

commandモジュールとshellモジュールは

アクション行が長すぎて快適ではなくなった場合

アクション(短縮形表記)

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

ハンドラーとは

note

権限の昇格　詳細はこちら

基本的な`INIである/etc/ansible/hosts`は以下のようになります。

基本的な`YAMLである/etc/ansible/hosts`は以下のようになります。