Ansible handson

Ansible入門
Ansible Workshop in Okinawa
2016.11.11
Hideki Saito
Internet Initiative Japan inc.

本セッションの目的
午前の部では、午後に予定されているハンズオンに向け
て必要となる、以下の事柄について解説します。そして
実際にAnsibleのインストールを行います。
(1) Ansibleとは？
(2) AnsibleのインストールとCLIの基本操作
(3) Playbookの記述方法
本セッション終了時点で、午後の部のハンズオンに向け
た準備が整います。

自己紹介
• 氏名: 齊藤秀喜 (さいとうひでき)
• TwitterID: @saito_hideki
• 所属:
• 株式会社インターネットイニシアティブ
• 日本OpenStackユーザ会ボードメンバー
• 趣味: OpenStack, Ansible

News
~ Ansibleに関する最近の話題 ~

v2.2 release
2系の最新版である、2.2がリリースされています。
TechPreviewとしてPython3対応が入りました。
• 2.2.0リリース情報
• 11-01-2016 "The Battle of Evermore"
• https://goo.gl/IXprJu
• 2.3へのロードマップ
• https://goo.gl/9TojdJ

Galaxyオープンソース化
Ansible Galaxyがオープンソース化されました。
GalaxyはGithubやDockerhubのように、Playbookや
モジュールのリポジトリを公開して共有し、再利用す
るサービスです。
オープンソース化されたことにより、自身でGalaxy
サイトを構築することが可能となりました。
• ソースコード: https://github.com/ansible/galaxy
• 公式サイト https://galaxy.ansible.com/

Interop Challenge with Ansible
世に出ている様々なOpenStack環境で、共通のワークロード
を動作させて、相互運用性を検証する試み。
2016.10に開催されたOpenStack Summit Barcelonaでは、
キーノートセッションで実演されました。
ワークロードのデプロイにはAnsibleが利用されました。
• Wiki https://wiki.openstack.org/wiki/Interop_Challenge
• Video https://www.youtube.com/watch?v=CqNFcuJfZ_Y

本日のEtherpad
本日のハンズオンに利用するEtherpadはコチラです
• http://172.16.51.53:9001/p/ansible_workshop_2016
• https://etherpad.openstack.org/p/ool_ansible_workshop_2016

Ansibleとは
Infrastructure as Codeというコンセプトを実現する
ための自動化ツールで、以下の特徴を持っています。
(1) システム管理にエージェントを必要としない
(2) 構成管理データベースを持たない
(3) 多くの機能を提供する充実したモジュール群を提供
(4) 公式モジュールでは冪等性が担保される
(5) Playbookにワークフローの実現
(6) 数多い利用実績

Ansible関連情報
• 公式サイト
• https://www.ansible.com/
• 公式ドキュメント
• http://docs.ansible.com/ansible/index.html
• Ansible Galaxy
• https://galaxy.ansible.com/
• ソースコードリポジトリ
• https://github.com/ansible/ansible
• https://github.com/ansible/ansible-modules-core
• https://github.com/ansible/ansible-modules-extras

Ansibleの構成要素
Ansibleの主な構成要素は以下の通りです。
# 構成要素概要
1 Configuration Ansibleの振る舞いを決める設定ファイル
2 Inventory 管理対象ホストの一覧が記述されたファイル
3 Module タスクとしてAnsibleが実行するプログラム
4 Command タスクやPlaybookを実行するためのコマンド群
5 Playbook 複数のタスクから構成されるワークフロー定義ファイル

自動化の仕組み
(a) UNIXホストに対する操作
(b)Windowsホストに対する操作
(c)ネットワーク機器に対する操作

タスク実行の流れ
Ansibleがタスクを実行する流れは以下の通りです。

Playbook実行の流れ
システムに対して実施する一連の作業を、順序だて
てYAML形式でPlaybookに記述します。
AnsibleはPlaybookでオペレーションのコード化を
実現しています。

Installation
~ Ansibleをインストールする~

インストール方法
• インストールガイド
• http://docs.ansible.com/ansible/intro_installation.html
• 公式リポジトリ
• https://github.com/ansible/ansible.git
• PIPのパッケージを利用
$ pip install ansible
• OSのパッケージを利用
RPM:$ yum install ansible
APT:$ apt-get install ansible

Ubuntu14.04上のvirtualenv環境に、pipを利用して
Ansibleをインストールする。
1.パッケージ更新
$ sudo apt-get update
$ sudo apt-get upgrade -y
$ sudo apt-get install -y build-essential git
$ sudo apt-get install -y python-dev libffi-dev libssl-dev
2.virtualenvのインストールと環境の切り替え
$ sudo apt-get install -y python-virtualenv
$ virtualenv $HOME/ansible
$ source $HOME/ansible/bin/activate
(ansible)$
pipを利用したインストール

3.pipを利用したAnsibleのインストール
(ansible)$ pip install ansible
4.Ansibleのバージョンを確認
(ansible)$ ansible --version
ansible 2.2.0.0
config file =
configured module search path = Default w/o overrides
pipを利用したインストール

コマンドラインインターフェイス
Ansible v2.2.0.0をpipインストールすると利用でき
るようになるコマンド一覧
コマンド役割
ansible ターゲットホスト上でアドホックなタスクを実行する
ansible-console インタラクティブにタスクを実行できるコンソール
ansible-doc モジュールの一覧や利用方法を参照する
ansible-galaxy Ansible Galaxyサイトを利用する
ansible-playbook Playbookを実行する
ansible-pull 外部リポジトリからPlaybookをダウンロードして実行する
ansible-vault Playbookファイルを暗号化する

ansibleコマンドの実行
ansibleコマンドが動作するために必要な、Inventory
ファイルを作成する。
• inventoryファイル(例: ~/hosts)
[localhost]
127.0.0.1 ansible_connection=local
• pingモジュールでansibleの動作を確認する
(ansible)$ ansible localhost -i ~/hosts -m ping
127.0.0.1 | SUCCESS => {
"changed": false,
"ping": "pong"
}

ansibleのタスク実行によって、管理対象のシステム
に変更があったかどうかを確認するには、実行結果に
含まれる"changed"の値を確認する。
• ターゲットホストの状態が変更された(イエロー)
• changed: true
• ターゲットホストの状態に変化なし(グリーン)
• changed: false
実行結果による判断

ホストのリモート管理
• 設定ファイル(例:ファイルパス "~/.ansible.cfg")
[defaults]
host_key_checking = False
• inventoryファイル(例: ファイルパス"~/hosts")
localhost ansible_host=127.0.0.1 ansible_connection=local
[remote]
target-1 ansible_host=192.168.131.18

ホストのリモート管理
ホストへのssh接続時にパスフレーズの入力を求めら
れるのを抑止するために、ssh-agentを利用する。
(ansible)$ eval `ssh-agent`
(ansible)$ ssh-add
Enter passphrase for /home/ubuntu/.ssh/id_rsa: ********
Identity added: /home/foo/.ssh/id_rsa (/home/foo/.ssh/id_rsa)

Inventoryファイルに定義されているremoteグループに
対してpingモジュールを適用する。
(ansible)$ ansible remote -i hosts -m ping -u <user> -k
192.168.131.11 | SUCCESS => {
"changed": false,
"ping": "pong"
}
192.168.131.12 | SUCCESS => {
"changed": false,
"ping": "pong"
}
192.168.131.10 | SUCCESS => {
"changed": false,
"ping": "pong"
}
接続確認

Ansibleがタスクを実行するホストを特定するために
利用するファイル。書式はINI形式に近い。
• ホストとグループの定義
192.168.131.10
192.168.131.11
192.168.131.12
[groupA]
192.168.131.10
192.168.131.11
[groupB]
192.168.131.11
192.168.131.12
Inventoryファイル(1)

• ホスト変数
該当ホストでタスクを実行する際に定義される
192.168.131.10 foo="Hello, World!"
debugモジュールでfooが定義されたことを確認
(ansible)$ ansible 192.168.131.10 -i hosts
-m debug -a "msg={{ foo }}"
192.168.131.10 | SUCCESS => {
"msg": "Hello, World!"
}

• グループ変数
該当グループでタスクを実行する際に定義される
[groupA]
192.168.131.10
192.168.131.11
[groupA:vars]
bar="Hello, Ansible!"
debugモジュールでfooが定義されたことを確認
$ ansible groupA -i hosts -m debug -a "msg={{ bar }}" -o
192.168.131.10 | SUCCESS => { "msg": "Hello, Ansible!" }
192.168.131.11 | SUCCESS => { "msg": "Hello, Ansible!" }

• 複数のグループをまとめる(children)
[groupA]
192.168.131.10
192.168.131.11
[groupB]
192.168.131.11
192.168.131.12
[groupC:children]
groupA
groupB
[groupC:vars]
baz="Hello, Okinawa!"

• グループ内のホストをパターンで登録する
数値またはアルファベットでレンジを指定可能
[remotehost]
192.168.131.[10:12]
web-[a:g]

• 覚えておくと便利なシステム予約済み変数
[例]
web ansible_host=192.168.131.10 ansible_connection=ssh ansible_user=foo
➡ansible_host
接続先IPアドレスまたはホスト名
➡ansible_connection
接続方法: local or ssh or smart
➡ansible_user
ssh接続を行う際のユーザID
➡ansible_ssh_pass
ssh接続を行う際のパスワード

ansibleコマンドを利用すると、ターゲットホストに
対して、アドホックにタスク(モジュール)を実行する
ことができる。
• 引数を必要としないタスクを実行する
タスクとして実行するモジュールは-mオプション
で指定する
(ansible)$ ansible localhost -i hosts -m ping
ansible command(1)

ansible command(2)
• 引数を必要とするタスクを実行する
モジュールパラメータは -a オプションで指定する
(ansible)$ ansible localhost -i hosts -m debug
-a 'msg="Hello, World!"'
複数のパラメータを指定することも可能
(ansible)$ ansible localhost -i hosts -m copy
-a "src=/etc/hosts dest=/home/<userid>/etc_hosts"

• ターゲットホストで任意のコマンドを実行する
ansibleコマンドは -m でモジュールが指定されな
かった場合はcommandモジュールを実行する
(ansible)$ ansible localhost -i hosts -a "uname -a"
localhost | SUCCESS | rc=0 >>
Linux ansible 3.13.0-95-generic #142-Ubuntu SMP Fri Aug 12
17:00:09 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
ansible command(３)

• ターゲットホストの情報を収集する
ターゲットホストの情報をJSON形式で出力する
(ansible)$ ansible localhost -i hosts -m setup
localhost | SUCCESS => {
"ansible_facts": {
"ansible_all_ipv4_addresses": [
"192.168.131.6"
],
"ansible_all_ipv6_addresses": [
"fe80::f816:3eff:fe52:49e6"
],
"ansible_architecture": "x86_64",
...以下略...
ansible command(4)

• ターゲットホストで任意のコマンドを実行する
root権限でコマンドを実行する(passwordなし)
(ansible)$ ansible localhost -i hosts
-a "cat /etc/shadow" --become
root権限でコマンドを実行する(passwordあり)
(ansible)$ ansible localhost -i hosts
-a "cat /etc/shadow" --become --ask-become-pass
ansible command(5)

Modules
~ モジュールの使い方 ~

Ansibleのモジュール
ansibleコマンドやansible-playbookコマンドが実行
する"作業"を記述したプログラムです。
役割やオプションの確認方法は以下の通り。
(ansible)$ ansible-doc <モジュール名>
• 公式サイトのモジュールインデックス
http://docs.ansible.com/ansible/list_of_all_modules.html

Playbook
~ Playbookの基本構成 ~

ansible-playbookコマンドは、複数のタスクを実行順
に記述し、ワークフローとしてターゲットホストに適
用するコマンド。
(ansible)$ ansible-playbook -i hosts playbook.yml
Playbookファイルの最小構成は以下の２つ
(1)１つのInventoryファイル
(2)１つのPlaybookファイル
Playbookとは

• AnsibleのPlaybookはYAML形式で記述する。基本
的な構造は以下の通り
---
- hosts: Target Host or Group
vars:
Param_A: Value_A
Param_B: Value_B
tasks:
- Task_A
- Task_B
- Task_C
handlers:
- Handler_X
- Handler_Y
Writing Playbook(1)

• Playbookに記述する各セクションの役割
Writing Playbook(2)
セクション名概要
hosts
playbookを適用するターゲットホスト、またはグループを記述
する
vars playbook実行中に利用するパラメータと、その値を定義する
tasks
hostsセクションに記載したターゲット上で実行するモジュー
ルと、そのパラメータを実行順に定義する
handlers
tasksセクションで定義したモジュールを実行した結果、シス
テムに変更が発生した場合に実行するモジュールを定義する

Writing Playbook(3)
• ansible-playbook(例:sample00.yml)を記述する
---
- hosts: localhost
vars:
message: "Hello, World!"
tasks:
- name: copy /etc/hosts to /tmp/
copy:
src: "/etc/hosts"
dest: "/tmp/hosts"
notify:
- print message
handlers:
- name: print message
debug:
msg: "{{ message }}"

• playbookを実行する(1回目)
(ansible)$ ansible-playbook -i hosts sample00.yml
PLAY [localhost] ************************************************
TASK [setup] ****************************************************
ok: [localhost]
TASK [copy /etc/hosts to /tmp/] *********************************
changed: [localhost]
RUNNING HANDLER [print message] *********************************
ok: [localhost] => { "msg": "Hello, World!" }
PLAY RECAP ******************************************************
localhost : ok=3 changed=1 unreachable=0 failed=0
Writing Playbook(4)

• ２度目の実行では冪等性が担保される
(ansible)$ ansible-playbook -i hosts sample00.yml
PLAY [localhost] *************************************************
TASK [setup]
******************************************************************
ok: [localhost]
TASK [copy /etc/hosts to /tmp/]
******************************************************************
ok: [localhost]
PLAY RECAP
******************************************************************
localhost : ok=2 changed=0 unreachable=0 failed=0
Writing Playbook(5)

• Playbookを特定のユーザ権限でタスクを実行する
becomeとbecome_userで実行ユーザを指定する
tasks:
- name: show /etc/shadow by root
command: cat /etc/shadow
become: true
become_user: root
become_user

Playbook essentials
~ 制御構造やBest Practiceなど ~

Loops
• 特定のタスクを繰り返し実行する(★は以降で解説)
# 構文繰り返し処理要素
1 with_items ★ リストのメンバー
2 with_nested ★ [[i],[j]] で表現される i * j のリストのメンバー
3 with_dict ★ key:value 形式で表現された辞書型のメンバー
4 with_file ファイル名をリストのメンバーとして格納されたテキストファイルの内容
5 with_fileglob ファイルグロブにマッチしたファイル名
6 with_together 複数のリストの要素をインデックス番号毎に組みしたもの
7 with_subelements ★ 辞書型のデータ構造に含まれる共通のキーで構成されるサブセット
8 with_sequence ★ 連続した数値
9 with_random_choice リストのメンバー
10 until なし。Do-Untilループ
11 with_first_found ファイル名のリスト中で最初にマッチ(存在)したファイル名
12 with_lines コマンド実行結果の各行
13 with_indexed_items インデックスと値がセットになったリストのメンバー
14 with_ini iniファイルのセクション内で正規表現にマッチしたキーワードの値のリスト
15 with_flattened リストのメンバー。入れ子になったリストも一次元のリストに展開される

• varsセクション
vars:
members:
- "Hello, World!"
- "Hello, Ansible!"
- "Hello, Okinawa!"
Example: with_items
• tasksセクション
tasks:
- name: test for with_items
debug:
msg: "{{ item }}"
with_items: "{{ members }}"

vars:
group_a:
- "Hello"
group_b:
- "World"
- "Ansible"
- "Okinawa"
Example: with_nested
tasks:
- name: test for with_nested
debug:
msg: "{{ item.0 }}, {{ item.1 }}!"
with_nested:
- "{{ group_a }}"
- "{{ group_b }}"

tasks:
- name: test for with_dict
debug:
msg: "{{ item.key }}:{{ item.value.name }}"
with_dict: "{{ members }}"
vars:
members:
web:
name: instance-a
address: 192.168.131.10
app:
name: instance-b
address: 192.168.131.11
dbs:
name: instance-c
address: 192.168.131.12
Example: with_dict

tasks:
- name: test for with_subelements
debug:
msg: "{{ item.1 }}"
with_subelements:
- "{{ members }}"
- address
vars:
members:
web:
address:
- 192.168.131.10
app:
address:
- 192.168.131.11
dbs:
address:
- 192.168.131.12
Example: with_subelements

vars:
counter: 3
start: 10
end: 19
step: 2
Example: with_sequence
tasks:
- name: test for with_sequence (counter)
debug:
msg: "{{ item }}"
with_sequence: count="{{ counter }}"
- name: test for with_sequence (range)
debug:
msg: "{{ item }}"
with_sequence: start="{{ start }}" end="{{ end }}" stride="{{ step }}" format=prefix%02d

Conditionals - when
特定の条件が成立した場合のみタスクを実行する。
withループのitem要素も条件として設定可能。
• whenを利用してタスクの実行を制御する
tasks:
- name: install packages by yum
yum:
name: httpd
state: latest
when: ansible_os_family == "RedHat"

• タグ(tags)を設定して特定タスクのみを実行する
---
- hosts: all
tasks:
- name: Print World
debug:
msg: "Hello, World!"
tags:
- world
- name: Print Ansible
debug:
msg: "Hello, Ansible!"
tags:
- ansible
tags:
- everything
Conditionals - tags

• -tオプションでタグを指定してコマンドを実行する
(ansible)$ ansible-playbook -i hosts -t ansible sample01.yml
PLAY [all] **************************************************
TASK [setup] ************************************************
ok: [192.168.131.10]
ok: [192.168.131.12]
ok: [192.168.131.11]
TASK [Print Ansible] ****************************************
ok: [192.168.131.10] => { "msg": "Hello, Ansible!" }
PLAY RECAP **************************************************
192.168.131.10 : ok=2 changed=0 unreachable=0 failed=0
Conditionals - tags

Playbookの構成ガイドライン
Playbookのファイルやディレクトリは自由に配置する
ことができます。
しかし、再利用性を高めたりGalaxyでロールを公開し
たいような場合は、Best Practiceというガイドライン
に従った構成にすることが推奨されています(強制では
ありません)
• http://docs.ansible.com/ansible/playbooks_best_practices.html

my_app/ # Playbookディレクトリ
production # 本番用Inventoryファイル
stating # ステージング用Inventoryファイル
group_vars/ # グループに適用する変数定義ファイル配置用ディレクトリ
my_group1 # "my_group1"に適用する変数を定義したファイル
my_group2 # "my_group2"に適用する変数を定義したファイル
host_vars/ # ホスト毎にのみ適用する変数定義ファイル配置用ディレクトリ
my_host1 # "my_host1"にのみ適用する変数定義ファイル
my_host2 # "my_host2"にのみ適用する変数定義ファイル
site.yml # ansible-playbookコマンドで指定するマスターとなるPlaybookファイル
my_web_servers.yml # site.ymlでincludeされる。管理対象の役割ごとに適用するroleを指定するためのファイル
my_app_servers.yml # site.ymlでincludeされる。管理対象の役割ごとの適用するroleを指定するためのファイル
roles/ # 管理対象に適用するタスクのグループ(role)を配置するディレクトリ
my_role/ # 実際に適用する作業を記述したファイルや作業で使用するファイル群を配置するためのディレクトリ
tasks/ # 適用する作業(タスク)を記述したファイルを配置するディレクトリ
main.yml # 作業(タスク)を記述したファイル
handlers/ # タスクの実行によってシステムに変化がおきた場合に実行されるハンドラを配置するディレクトリ
main.yml # ハンドラを記述するファイル
templates/ # templateモジュールが利用するJinja2形式のテンプレートを配置するディレクトリ
my_template.j2 # Jinja2形式のテンプレートファイル
files/ # 管理対象ホストにそのまま転送されるファイルを配置するディレクトリ
my_file # 管理対象ホストにそのまま転送されるファイル
vars/ # role実行時に適用する変数定義ファイルを配置するディレクトリ
main.yml # role実行時に適用する変数定義ファイル
defaults/ # role実行時に適用するデフォルト変数定義ファイルを配置するディレクトリ
main.yml # role実行時に適用するデフォルト変数定義ファイル
meta/ # role間の依存関係を定義したファイルを配置するディレクトリ
main.yml # role間の依存関係定義ファイル
基本的なディレクトリ構成

ディレクトリ構造の作成
ansible-galaxyコマンドを利用して、Best Practiceでのrole推奨ディレ
クトリ構成が簡単に作成できます。
(ansible)$ ansible-galaxy init my_role
(ansible)$ tree my_role/
my_role/
├── defaults
│   └── main.yml
├── files
├── handlers
├── meta
├── README.md
├── tasks
├── templates
├── tests
│   ├── inventory
│   └── test.yml
└── vars
└── main.yml

Playbookを書く際の心得
(1) ちゃんとしたYAMLの書式で書こう
(2) できるだけBest Practiceに従った構造にしよう
(3) タスクの先頭にはname:セクションをちゃんと書こう
(4) タスク内で即値を書かずにvarsファイルに外出ししよう
(5) 名前重要。Playbookの変数の名前空間はフラットです
(6) debugモジュールをつかう場合はverbosityも設定しよう
(7) jinja2テンプレートはできるだけシンプルに書こう
(8) 巨大な１つのファイルに書かずに分割してincludeしよう
(9) Playbookをコードレビューできる仕組みを導入しよう

Inventoryを書く際の心得
(1) IPアドレスやFQDNよりも、わかりやすい名前をつけよう
(2) 環境毎に分けて誤爆を防ごう
(3) 適切なパーミッションを設定しよう
(4) --limitを多用するくらいなら、専用にグループを作ろう
(5) Dynamic Inventoryは単一の情報ソースから生成しよう

Ansible handson

More Related Content

What's hot (20)

Similar to Ansible handson (20)

More from Hideki Saito (20)

Ansible handson