![Inventory（インベントリ）
192.168.33.101
foo
[webservers]
web01
web02
[dbservers]
db[01:03]
[xxxservice:children]
webservers
dbservers
[bastion]
bastion ansible_port=30022
[all:vars]
ansible_user=vagrant
グループ名
複数のホストをグルーピングした名称
グループ単位でPlaybookを実行可能
ホスト省略形式指定
（db01,db02,db03）
SSHのポート番号を指定するパラメータ
（デフォルトは22番を利用）
全ホストに対して指定するパラメータ
“all”グループは予約されており、インベントリ
の全ホストがターゲットとなる
ホスト
SSHで接続可能なホスト
IPアドレスや名前解決可能なホスト名
“:children”を指定して、グループを束ねたグ
ループを作成](https://image.slidesharecdn.com/ansible-170212144002/85/Ansible-29-320.jpg)
![ansible-playbook コマンド
$ ansible-playbook -i hosts site.yml
PLAY [192.168.33.101] *************************************************
TASK [setup] *******************************************************************
ok: [192.168.33.101]
TASK [install nginx] ***********************************************************
changed: [192.168.33.101]
TASK [nginx running and enabled] ***********************************************
changed: [192.168.33.101]
PLAY RECAP *********************************************************************
192.168.33.101 : ok=3 changed=2 unreachable=0 failed=0
インベントリ
Playbook 初回実行時](https://image.slidesharecdn.com/ansible-170212144002/85/Ansible-31-320.jpg)
![ansible-playbook コマンド
$ ansible-playbook -i hosts site.yml
PLAY [192.168.33.101] *************************************************
TASK [setup] *******************************************************************
ok: [192.168.33.101]
TASK [install nginx] ***********************************************************
ok: [192.168.33.101]
TASK [nginx running and enabled] ***********************************************
ok: [192.168.33.101]
PLAY RECAP *********************************************************************
192.168.33.101 : ok=3 changed=0 unreachable=0 failed=0
再実行時
変更点なし](https://image.slidesharecdn.com/ansible-170212144002/85/Ansible-32-320.jpg)
![ansibleコマンドを利用してAd-Hocにモジュールを実行可能
▷ yumモジュール（パッケージ管理）
playbookで実行したnginxインストールタスクの実行例
ansible コマンド（Ad-Hoc）
$ ansible -i hosts 192.168.33.101 -m yum -a "name=nginx state=present" -b
192.168.33.101 | SUCCESS => {
"changed": false,
"msg": "",
"rc": 0,
"results": [
"nginx-1.10.2-1.el6.x86_64 providing nginx is already installed"
]
}
ターゲットインベントリ モジュール モジュールのOptions become(sudo)](https://image.slidesharecdn.com/ansible-170212144002/85/Ansible-35-320.jpg)
![利用可能なモジュール一覧の確認
モジュールに関するドキュメントは`ansible-doc`コマンドで参照
Ansibleモジュール
$ ansible-doc -l
$ ansible-doc file
Sets attributes of files, symlinks, and directories, or removes
files/symlinks/directories. Many other modules support the same
options as the [file] module - including [copy], [template], and [assemble].
Options (= is mandatory):
- follow
This flag indicates that filesystem links, if they exist, should
be followed.
(Choices: yes, no)[Default: no]
- force
force the creation of the symlinks in two cases: the source file
does not exist (but will appear later); the destination exists
and is a file (so, we need to unlink the "path" file and create
モジュール名](https://image.slidesharecdn.com/ansible-170212144002/85/Ansible-37-320.jpg)
![▷ pingモジュール（リモートホストの疎通確認）
サーバ新設後の接続確認や障害発生時の疎通確認に利用可能。
Ansibleモジュール
$ ansible web -i hosts -m ping
web01 | SUCCESS => {
"changed": false,
"ping": "pong"
}
web02 | SUCCESS => {
"changed": false,
"ping": "pong"
}
※※インベントリ※※
[web]
web01
web02](https://image.slidesharecdn.com/ansible-170212144002/85/Ansible-38-320.jpg)
![▷ setupモジュール（リモートホストの情報取得）
playbookの実行時は、デフォルトで始めに setupモジュールが実行されてファクト変数を取得
ファクト変数はplaybook内で変数として利用可（ Distributionによる条件式等）
Ansibleモジュール
$ ansible 192.168.33.101 -i hosts -m setup --one-line
192.168.33.101 | SUCCESS => {"ansible_facts": {"ansible_all_ipv4_addresses": ["10.0.2.15",
"192.168.33.101"], "ansible_all_ipv6_addresses": ["fe80::a00:27ff:fe4f:b806",
"fe80::a00:27ff:fe03:c0a5"], "ansible_architecture": "x86_64", "ansible_bios_date": "12/01/2006",
"ansible_bios_version": "VirtualBox", "ansible_cmdline": {"KEYBOARDTYPE": "pc", "KEYTABLE":
"us", "LANG": "en_US.UTF-8", "SYSFONT": "latarcyrheb-sun16", "clocksource_failover":
"acpi_pm", "rd_NO_DM": true, "rd_NO_LUKS": true, "rd_NO_LVM": true, "rd_NO_MD": true, "ro":
true, "root": "UUID=1d798f26-8ace-413f-9530-2d1d1d4fdbb5"}, "ansible_date_time": {"date":
"2017-02-05", "day": "05", "epoch": "1486270715", "hour": "04", "iso8601":
"2017-02-05T04:58:35Z", "iso8601_basic": "20170205T045835431149",
"iso8601_basic_short": "20170205T045835", "iso8601_micro":
"2017-02-05T04:58:35.431233Z", "minute": "58", "month": "02", "second": "35", "time":
"04:58:35", "tz": "UTC", "tz_offset": "+0000", "weekday": "Sunday", "weekday_number": "0",
"weeknumber": "05", "year": "2017"}, "ansible_default_ipv4": {"address": "10.0.2.15", "alias":
"eth0", "broadcast": "10.0.2.255", "gateway": "10.0.2.2", …(snip)…](https://image.slidesharecdn.com/ansible-170212144002/85/Ansible-39-320.jpg)
![Role
Playbookを疎結合なコンポーネントの処理で分割したもの
tasks / defaults / files / templates / handlers / varsのディレクトリ構成
Roleを作成することで再利用可能となり、Playbookの可読性も高まる
site.yml # playbook
roles/nginx/ # roles/[Role名]ディレクトリ
├─ defaults/ # 変数のデフォルト値
｜ └ main.yml # Roleで利用する変数default
├─ files/ # copyモジュールのファイル
├─ handlers/ # 特定イベント発火タスク
｜ └ main.yml #
├─ meta/ # Roleのメタ情報（依存Role）
├─ tasks/ # Roleで実行されるタスク
｜ └ main.yml # 実行タスクファイル ※必須
├─ templates/ # templateモジュール
｜ └ xxx.xxx.j2 # Jinja2形式ファイル
└─ vars/ #
└ main.yml #
---
- hosts: web
roles:
- nginx nginxロール呼び出し
---
- name: install nginx
yum: name=nginx-{{ nginx_version }} state=present
- name: nginx running and enabled
service: name=nginx state=started enabled=yes
nginx_version: 1.10.2](https://image.slidesharecdn.com/ansible-170212144002/85/Ansible-41-320.jpg)
![Pull Request（レビュー）
## 概要
xxx
## レビュー観点
- xxx
## 環境適用手順
### ローカル環境
```
ansible-playbook -i inventories/local/hosts
playbooks/xxx.yml --diff --check
```
### 検証環境
```
ansible-playbook -i inventories/develop/hosts
playbooks/xxx.yml --diff --check
```
### 本番環境
```
ansible-playbook -i inventories/production/hosts
playbooks/xxx.yml --diff --check
```
## CIテスト実行設定
- テスト実行可否 [true/false]
test-enable: true
- テスト対象Playbook [csv形式]
test-playbooks: webservers.yml, dbservers.yml
## サービスへの影響
xxxx
## レビュー期日
xx/xx
.github/PULL_REQUEST_TEMPLATE.mdを作成することでPR作成簡略化](https://image.slidesharecdn.com/ansible-170212144002/85/Ansible-55-320.jpg)
![CI（継続的インテグレーション）
Ansibleで冪等性の考慮漏れは良く発生する。
CIで予め初期構築及び、冪等性をテストする。
(1) Apply [1st] - 初回構築の正常性確認
(2) Dry-Run - 初回構築後のdry-runで冪等性を検証 (changed=0)
(3) Apply [2nd] - 2回目以降の適用で冪等性を検証 (changed=0)
※(2)(3)を実施する理由は`check_mode: no`のtaskを考慮。
(1)
未構築 構築済
(2)(3)](https://image.slidesharecdn.com/ansible-170212144002/85/Ansible-57-320.jpg)
![callback_plugin
Playbook実行結果のok, changed,
unreachable, failure数の取得に
callback_pluginが利用可能。
playbookの実行開始や終了などの
イベントにフックして、処理を行うプ
ラグイン。
実行後にログやメール、チャットで
通知する用途など。
ここでplaybook_on_stats()の実行
結果を集計してjsonで出力させて、
CIでの結果判定に利用している。
## etc/callback_plugins/output_json.py
import os
import json
class CallbackModule(object):
def __init__(self):
self.hosts_name = None
self.results_dir = 'results'
## call on start playbook
def playbook_on_play_start(self, name):
self.hosts_name = self.play.hosts
## call at end playbook
def playbook_on_stats(self, stats):
hosts = sorted(stats.processed.keys())
result_hosts = []
for host in hosts:
s = stats.summarize(host)
dict = {
"host": host,
"result": {
"ok": s['ok'],
"changed": s['changed'],
"unreachable": s['unreachable'],
"failures": s['failures']
}
}
result_hosts.append(dict)
…..](https://image.slidesharecdn.com/ansible-170212144002/85/Ansible-59-320.jpg)
Ansibleで始めるインフラ構築自動化
- 2. Profile - 名前: 長原 佑紀 (Yuuki Nagahara) - 所属: 株式会社ビズリーチ - 部署: ビズリーチ事業 インフラ - 経歴: - 2007- SIer - 2015- ビズリーチ - 好き: - AWS - Android
- 3. 1. Infrastructure as Code 2. Ansible (概要) 3. Ansible (基礎編) 4. Ansibleデモ 5. Ansible (実践編) Agenda
- 4. Ansibleを使われたことがある方は？ 1. 使ったことない。これから学ぶ。 2. 多少触ったことがある。 3. 業務でがっつり利用している。 Question 回答 1. 5割 2. 3割 3. 2割
- 5. 1. Infrastructure as Code
- 6. manual Operator Infrastructure as Code とは Infrastructure
- 7. constraction manual Operator Infrastructure as Code とは source code Infrastructure
- 8. Infrastructure as Code とは ？
- 9. Infrastructure as Code とは インフラの構成管理を 宣言的なコードで記述し、 ソフトウェア開発の プラクティスを適用すること
- 11. - バージョン管理（Git） - Pull Request（レビュー） - TDI(TDD)（テスト駆動インフラストラクチャ） - CI（継続的インテグレーション） - CD（継続的デプロイ） Infrastructure as Codeのプラクティス
- 12. Infrastructure as Codeの領域 システムコンフィグレーション デプロイ、サーバ間連携 クラウド、VM、コンテナ、 OSインストール オーケストレーション (Orchestration) コンフィグレーション (Configuration) ブートストラッピング (Bootstrapping) Fabric, Capistrano, Serf, Consol Puppet, Chef, Ansible, Itamae AWS, OpenStack, Docker, KickStart, Cobbler, Terraform
- 13. Infrastructure as Codeの領域 OS / ミドルウェア設 定 デプロイ、サーバ間連携 仮想 マシン 作成 オーケストレーション コンフィグレーション ブートストラッピング OS インス トール Server#1 Server#2 Server#3
- 14. ▷ ブートストラッピング ○ プラットフォームそのもの。または、サーバとしてOSが利用可能な状態 を作るツール。 ○ 仮想マシンやコンテナ、クラウドにおいてAPIを利用してリソースの定 義を行う。 ▷ コンフィグレーション ○ サーバへミドルウェアのインストールや各種設定を行うツール。 ○ サーバ構成管理の自動化に当たる部分を担う領域。 ▷ オーケストレーション ○ リソースの集合体に連携したサービスを提供するツール。 ○ 構築済みの環境に対して振る舞いを行う。 Infrastructure as Codeの領域
- 15. ▷ ブートストラッピング ○ AWSのAPIを利用したEC2インスタンス管理 ○ Dockerを利用したコンテナ管理 ○ Vagrantでの仮想マシン立ち上げ ▷ コンフィグレーション ○ 各種ミドルウェアでのサーバの構築 ○ パッチ適用 ▷ オーケストレーション ○ アプリケーションの分散デプロイ（ローリングアップデート） ○ Hadoopクラスタの構築 ○ メトリクス/監視ツールへのノード追加 ユースケース
- 16. ▷ オペレーション品質の向上 人的ミス発生確率低減、再現性の向上 ▷ システム運用の標準化 変更履歴で属人化の防止 ▷ 再利用性の向上 部品化により再利用が容易 ▷ 作業工数削減 手動オペレーションのタイムロス削減 ▷ セキュリティの向上 直接多数のサーバを操作する機会を最小化 コード化によるメリット
- 17. 2. Ansible 概要
- 18. Python製の構成管理ツール。 2015年にRed Hat社が買収。 クラウド操作やデプロイ等も 利用可能で、ブートストラッピング やオーケストレーションのレイヤ の機能も一部提供する。 『Infrastructure as Code』を 実現するためのフレームワーク Ansible 概要 Configration Orchstration Bootstrapping “Ansible is Simple IT Automation.” ※名前の由来は、SF小説に登場する”超光速通信技術”
- 19. ▷ Simple - Yaml形式の設定ファイル - 可読性高、コーディング不要 - 低い学習コスト ▷ Powerful - "Batteries Included" (電池同梱) - パッケージ１つで導入可能 ▷ Agentless - 構築対象にエージェントは不要 - sshが接続可能であれば良い Ansibleの特徴
- 20. サーバの状態を一定に保つための特性 対象リソースに対して「何を実行するのか」ではなく、 「どういう状態があるべき姿なのか」を定義する。 ある操作を１回行っても複数回行っても結果が同じとなる性質。 冪等性（べきとうせい） ➔ × 冪等性がない ➔ ◯ 冪等性がある $ echo “parameter=1” >> /etc/configfile Ansibleで記述したコードは基本的に冪等性を担保する仕組み $ echo “parameter=1” >> /opt/app/config $ sudo yum install -y nginx-1.10.2 Package nginx-1.10.2-1.el6.x86_64 already installed and latest version Nothing to do
- 23. Ansibleは構成定義からAnsibleに組み込まれたモジュールを元に PythonCodeを生成し、リモートホストに転送して、ssh経由で実行 Ansibleの実行の内部処理 Python Code ③ ssh ① 自動生成 Python Code Ansibleホスト リモートホスト （構築対象サーバ） ④コード実行② sftpサーバ構成定義 ホスト情報 ⑤コード削除
- 24. 構成管理ツール比較 Puppet Chef Ansible 開発言語 Ruby Ruby Python 開発開始 2005年 2009年 2012年 書式 独自DSL Ruby DSL yaml 冪等制 ◯ ◯ ◯ 構成管理方法 Pull型 Pull型 Push型 エージェント 必要 必要 不要 ※1 ※1: AnsibleもリモートホストにPython 2.4以降のインストールが予め必要。
- 25. 構成管理ツール比較
- 26. 3. Ansible 基礎編
- 27. Ansibleインストール ansibleはyum、apt、pipで提供されているため環境に合わせてインストー ル。 ### Latest Release Via Yum (CentOS, RHEL) $ yum install -y epel-release $ sudo yum install ansible --enablerepo=epel ### Latest Releases Via Apt (Ubuntu) $ sudo apt-get install software-properties-common $ sudo apt-add-repository ppa:ansible/ansible $ sudo apt-get update $ sudo apt-get install ansible ### Latest Releases Via Pip (Linux, MacOS) $ sudo easy_install pip $ sudo pip install ansible
- 28. Ansibleの最小構成 Ansibleで環境構築を行う最低限の2ファイル 1. Inventory - リモートホストのホストやグループを管理するファイル - ファイル名に規定なし ex.) hosts, inventory 2. Playbook - リモートホストの状態 (構成) を定義するyamlファイル - Inventoryで管理されたグループやホスト単位で作成 - ファイルの拡張子は”.yml” 最小構成 ├── hosts # Inventory └── site.yml # Playbook
- 30. Playbook リモートホストの構成をタスク又はロールで定義 タスクはAnsibleのモジュールを利用して定義し、上から順番に実行 --- - hosts: 192.168.33.101 become: yes tasks: - name: install nginx yum: name=nginx state=present - name: nginx running and enabled service: name=nginx state=started enabled=yes リモートホスト（インベントリのホスト or グループ） sudoで実行 モジュール モジュールの引数 nginxのインストール nginxサービスの起動 / 自動起動有効化
- 31. ansible-playbook コマンド $ ansible-playbook -i hosts site.yml PLAY [192.168.33.101] ************************************************* TASK [setup] ******************************************************************* ok: [192.168.33.101] TASK [install nginx] *********************************************************** changed: [192.168.33.101] TASK [nginx running and enabled] *********************************************** changed: [192.168.33.101] PLAY RECAP ********************************************************************* 192.168.33.101 : ok=3 changed=2 unreachable=0 failed=0 インベントリ Playbook 初回実行時
- 32. ansible-playbook コマンド $ ansible-playbook -i hosts site.yml PLAY [192.168.33.101] ************************************************* TASK [setup] ******************************************************************* ok: [192.168.33.101] TASK [install nginx] *********************************************************** ok: [192.168.33.101] TASK [nginx running and enabled] *********************************************** ok: [192.168.33.101] PLAY RECAP ********************************************************************* 192.168.33.101 : ok=3 changed=0 unreachable=0 failed=0 再実行時 変更点なし
- 33. ansible-playbook コマンド $ ansible-playbook -i hosts site.yml … (snip) … PLAY RECAP ********************************************************************* 192.168.33.101 : ok=3 changed=2 unreachable=0 failed=0 結果 説明 ok 定義された状態となっている changed 定義された状態に変更が行われた unreachable リモートホストへの接続に失敗した failed タスクの実行に失敗（エラー） 実行結果にて、各リモートホストの実行結果の要約（RECAP）を出力
- 34. PlaybookのDry Run 手動でPlaybookを流す前には必ず事前に意図した変更となるか確認する ansible-playbook コマンド $ ansible-playbook -i hosts site.yml --check その他のオプション -D, --diffオプション ファイル等の変更差分内容を出力。 --syntax-check playbookのシンタックスを検査。 --list-tasks 実行されるタスクの一覧を表示。 --start-at-taskオプション（=”task名”） playbookを途中から実行する場合に有効。 --step playbookを(N)o/(y)es/(c)ontinue入力でステップ実行。 Tips Inventoryfileなしでplaybook実行 $ ansible-playbook -i "192.168.1.2," site.yml ※1台の場合は末尾にカンマが必要
- 35. ansibleコマンドを利用してAd-Hocにモジュールを実行可能 ▷ yumモジュール（パッケージ管理） playbookで実行したnginxインストールタスクの実行例 ansible コマンド（Ad-Hoc） $ ansible -i hosts 192.168.33.101 -m yum -a "name=nginx state=present" -b 192.168.33.101 | SUCCESS => { "changed": false, "msg": "", "rc": 0, "results": [ "nginx-1.10.2-1.el6.x86_64 providing nginx is already installed" ] } ターゲットインベントリ モジュール モジュールのOptions become(sudo)
- 36. タスクはモジュールを指定して構成を定義 モジュールは基本的に冪等性を担保した実装が行われている。 モジュールの分類 ▷ Core Modules https://github.com/ansible/ansible-modules-core 利用頻度の高いモジュール群 ▷ Extra Modules https://github.com/ansible/ansible-modules-extras 利用頻度の中以下のモジュール群、Core Modulesの登竜門 Ansible module index （core + extra） モジュール数：900超 Ansibleモジュール
- 37. 利用可能なモジュール一覧の確認 モジュールに関するドキュメントは`ansible-doc`コマンドで参照 Ansibleモジュール $ ansible-doc -l $ ansible-doc file Sets attributes of files, symlinks, and directories, or removes files/symlinks/directories. Many other modules support the same options as the [file] module - including [copy], [template], and [assemble]. Options (= is mandatory): - follow This flag indicates that filesystem links, if they exist, should be followed. (Choices: yes, no)[Default: no] - force force the creation of the symlinks in two cases: the source file does not exist (but will appear later); the destination exists and is a file (so, we need to unlink the "path" file and create モジュール名
- 38. ▷ pingモジュール（リモートホストの疎通確認） サーバ新設後の接続確認や障害発生時の疎通確認に利用可能。 Ansibleモジュール $ ansible web -i hosts -m ping web01 | SUCCESS => { "changed": false, "ping": "pong" } web02 | SUCCESS => { "changed": false, "ping": "pong" } ※※インベントリ※※ [web] web01 web02
- 39. ▷ setupモジュール（リモートホストの情報取得） playbookの実行時は、デフォルトで始めに setupモジュールが実行されてファクト変数を取得 ファクト変数はplaybook内で変数として利用可（ Distributionによる条件式等） Ansibleモジュール $ ansible 192.168.33.101 -i hosts -m setup --one-line 192.168.33.101 | SUCCESS => {"ansible_facts": {"ansible_all_ipv4_addresses": ["10.0.2.15", "192.168.33.101"], "ansible_all_ipv6_addresses": ["fe80::a00:27ff:fe4f:b806", "fe80::a00:27ff:fe03:c0a5"], "ansible_architecture": "x86_64", "ansible_bios_date": "12/01/2006", "ansible_bios_version": "VirtualBox", "ansible_cmdline": {"KEYBOARDTYPE": "pc", "KEYTABLE": "us", "LANG": "en_US.UTF-8", "SYSFONT": "latarcyrheb-sun16", "clocksource_failover": "acpi_pm", "rd_NO_DM": true, "rd_NO_LUKS": true, "rd_NO_LVM": true, "rd_NO_MD": true, "ro": true, "root": "UUID=1d798f26-8ace-413f-9530-2d1d1d4fdbb5"}, "ansible_date_time": {"date": "2017-02-05", "day": "05", "epoch": "1486270715", "hour": "04", "iso8601": "2017-02-05T04:58:35Z", "iso8601_basic": "20170205T045835431149", "iso8601_basic_short": "20170205T045835", "iso8601_micro": "2017-02-05T04:58:35.431233Z", "minute": "58", "month": "02", "second": "35", "time": "04:58:35", "tz": "UTC", "tz_offset": "+0000", "weekday": "Sunday", "weekday_number": "0", "weeknumber": "05", "year": "2017"}, "ansible_default_ipv4": {"address": "10.0.2.15", "alias": "eth0", "broadcast": "10.0.2.255", "gateway": "10.0.2.2", …(snip)…
- 40. Ansibleモジュール その他の代表的なモジュール ● file - ファイル/ディレクトリ作成や所有者/権限変更 ● copy - リモートホストにファイルを転送 ● template - テンプレートファイル（jinja2）を展開した ファイルをリモートホストへ転送 ● get_url - 指定URLからファイルをダウンロード ● lineinfile - リモートホストのファイルで正規表現にマッチ する行の書き換え ● shell - シェルの実行 ● yum / apt - パッケージ操作 ● service - サービス操作
- 41. Role Playbookを疎結合なコンポーネントの処理で分割したもの tasks / defaults / files / templates / handlers / varsのディレクトリ構成 Roleを作成することで再利用可能となり、Playbookの可読性も高まる site.yml # playbook roles/nginx/ # roles/[Role名]ディレクトリ ├─ defaults/ # 変数のデフォルト値 ｜ └ main.yml # Roleで利用する変数default ├─ files/ # copyモジュールのファイル ├─ handlers/ # 特定イベント発火タスク ｜ └ main.yml # ├─ meta/ # Roleのメタ情報（依存Role） ├─ tasks/ # Roleで実行されるタスク ｜ └ main.yml # 実行タスクファイル ※必須 ├─ templates/ # templateモジュール ｜ └ xxx.xxx.j2 # Jinja2形式ファイル └─ vars/ # └ main.yml # --- - hosts: web roles: - nginx nginxロール呼び出し --- - name: install nginx yum: name=nginx-{{ nginx_version }} state=present - name: nginx running and enabled service: name=nginx state=started enabled=yes nginx_version: 1.10.2
- 42. vars / templates varsはホスト/グループ/環境毎の設定値を定義、templates等にて変数代入 group_varsはグループ単位の設定値を変えることが可能 site.yml # playbook hosts #インベントリ group_vars ├─ web.yml # group: webのvars ├─ db.yml # group: dbのvars roles └─nginx/ # nginx rolesディレクトリ ├─ tasks/ ｜ └ main.yml # roleの実行タスク └─ templates/ └ index.html.j2 # index.htmlのテンプレート - hosts: web roles: - nginx - name: replace index.html template: src: index.html.j2 dest: /usr/share/nginx/html/index.html name: “webserver” group_vars name: {{ name }} name: “dbserver” $ ansible-playbook -i develop site.yml $ ssh web01 “cat /usr/share/nginx/html/index.html” group_vars name: webserver
- 43. vars / templates varsの値定義箇所は複数存在し、各優先度が複雑な為に注意が必要 ● role defaults ● inventory vars ● inventory group_vars ● inventory host_vars ● playbook group_vars ● playbook host_vars ● host facts ● play vars ● play vars_prompt ● play vars_files ● registered vars ● set_facts ● role and include vars ● block vars (only for tasks in block) ● task vars (only for the task) ● extra vars (always win precedence) low priority high
- 44. Ansible Vault $ cat group_vars/webserver.vault nginx_htpasswd: '9s36?;fyNp' $ ansible-vault encrypt group_vars/webserver.vault Encryption successful $ cat group_vars/webserver.vault $ANSIBLE_VAULT;1.1;AES256 61386434353264313436616339353933666163333931323262383 064343738643639373239643462 6665363764373265366464626666613535326531666363630a6 56332646462616231613438383233 ... snip ... ### view encrypt vars file $ ansible-vault view group_vars/webserver.vault nginx_htpasswd: '9s36?;fyNp' ### edit encrypt vars file $ ansible-vault edit group_vars/webserver.vault ### decrypt encrypted vars file $ ansible-vault decrypt group_vars/webserver.vault 機密情報のvarsを暗号化してリポジ トリ管理可能とするツール playbook実行時にはパスワードに より復号化して変数利用 パスワードファイル設置 ansible.cfgに以下の設定を追加 vault_password_file = ~/.vault_password $ echo “passwd” > ~/.vault_password
- 45. Ansible Galaxy AnsibleのRoleが公開されるサービス 世界中のユーザが作成したOSSのRoleの検索が可能 - サポートプラットフォーム - タグ - Github Watch/Start数 - ダウンロード数 利用方法 → rolesディレクトリ配下へDL 新規ロール作成時には、目的のRoleがないか検索 抽象度が高いRoleはメンテコストが掛かるため独自Roleの選択肢も検討 $ ansible-galaxy install user.repo
- 46. Best Practice production # inventory file for production servers staging # inventory file for staging environment group_vars/ group1 # here we assign variables to particular groups group2 # "" host_vars/ hostname1 # if systems need specific variables, put them here hostname2 # "" library/ # if any custom modules, put them here (optional) filter_plugins/ # if any custom filter plugins, put them here (optional) site.yml # master playbook webservers.yml # playbook for webserver tier dbservers.yml # playbook for dbserver tier roles/ common/ # this hierarchy represents a "role" tasks/ # main.yml # <-- tasks file can include smaller files if warranted handlers/ # main.yml # <-- handlers file templates/ # <-- files for use with the template resource ntp.conf.j2 # <------- templates end in .j2 files/ # bar.txt # <-- files for use with the copy resource vars/ # main.yml # <-- variables associated with this role defaults/ # main.yml # <-- default lower priority variables for this role meta/ # main.yml # <-- role dependencies library/ # roles can also include custom modules lookup_plugins/ # or other types of plugins, like lookup in this case webtier/ # same kind of structure as "common" was above, done for the webtier role monitoring/ # "" fooapp/ # "" 公式のAnsibleディレクトリ構成の ベストプラクティス マルチステージに対応 production / staging
- 48. Demo (3) オーケストレーション ローリングアップデートによるデプロイ (2) コンフィグレーション EC2のサーバ構築 x2台 common / ngnix (1) ブートストラッピング Ansibleを用いたAWSの環境構築 VPC / KeyPair / InternetGateway Subnet / RouteTable / SecurityGroup / EC2 x2台 / ELB Availability Zone 1a Availability Zone 1c web web EC2 EC2 Elastic Load Balancing
- 49. Demo (3) オーケストレーション ローリングアップデートによるデプロイ (2) コンフィグレーション EC2のサーバ構築 x2台 common / ngnix (1) ブートストラッピング Ansibleを用いたAWSの環境構築 VPC / KeyPair / InternetGateway Subnet / RouteTable / SecurityGroup / EC2 x2台 / ELB Availability Zone 1a Availability Zone 1c web web EC2 EC2 Elastic Load Balancing AWS via Ansible ● Rate exceededでAPI発行がこけることがある （terraformは自動でリトライ） ● リソースを削除する場合には state: absentのPlaybookが別途必要 （terraformはdestroyで一括削除） ● AWSサービスのモジュールサポートは事前に要チェック （デモ範囲は全てモジュールで実現）
- 50. 5. Ansible 実践編
- 51. - バージョン管理（Git） - Pull Request（レビュー） - TDI(TDD)（テスト駆動インフラストラクチャ） - CI（継続的インテグレーション） - CD（継続的デプロイ） (再) Infrastructure as Codeのプラクティス
- 52. - バージョン管理（Git） - Pull Request（レビュー） - TDI(TDD)（テスト駆動インフラストラクチャ） - CI（継続的インテグレーション） - CD（継続的デプロイ） (再) Infrastructure as Codeのプラクティス
- 53. バージョン管理 AnsibleのGitブランチ戦略 本番 / 検証環境をそれぞれmaster / developブランチで運用。 各環境とソースコードが適合する状態を維持し続ける。 master develop Feature Feature
- 54. Pull Request（レビュー） GithubのPull Requestでレビュー実施。 - 概要（変更内容） - レビュー観点 - 適用時ansible-playbookコマンド （その他必要作業漏れないか） - CIテスト実行設定 - 適用時のサービス影響
- 55. Pull Request（レビュー） ## 概要 xxx ## レビュー観点 - xxx ## 環境適用手順 ### ローカル環境 ``` ansible-playbook -i inventories/local/hosts playbooks/xxx.yml --diff --check ``` ### 検証環境 ``` ansible-playbook -i inventories/develop/hosts playbooks/xxx.yml --diff --check ``` ### 本番環境 ``` ansible-playbook -i inventories/production/hosts playbooks/xxx.yml --diff --check ``` ## CIテスト実行設定 - テスト実行可否 [true/false] test-enable: true - テスト対象Playbook [csv形式] test-playbooks: webservers.yml, dbservers.yml ## サービスへの影響 xxxx ## レビュー期日 xx/xx .github/PULL_REQUEST_TEMPLATE.mdを作成することでPR作成簡略化
- 57. CI（継続的インテグレーション） Ansibleで冪等性の考慮漏れは良く発生する。 CIで予め初期構築及び、冪等性をテストする。 (1) Apply [1st] - 初回構築の正常性確認 (2) Dry-Run - 初回構築後のdry-runで冪等性を検証 (changed=0) (3) Apply [2nd] - 2回目以降の適用で冪等性を検証 (changed=0) ※(2)(3)を実施する理由は`check_mode: no`のtaskを考慮。 (1) 未構築 構築済 (2)(3)
- 58. CI（継続的インテグレーション） (4) launch instances and exec playbook (run, dry-run, run) (1) pull request push (2) webhook Jenkins test script test script (3) exec playbooks x procs (6) post results (7) result (5) notify EC2 EC2
- 59. callback_plugin Playbook実行結果のok, changed, unreachable, failure数の取得に callback_pluginが利用可能。 playbookの実行開始や終了などの イベントにフックして、処理を行うプ ラグイン。 実行後にログやメール、チャットで 通知する用途など。 ここでplaybook_on_stats()の実行 結果を集計してjsonで出力させて、 CIでの結果判定に利用している。 ## etc/callback_plugins/output_json.py import os import json class CallbackModule(object): def __init__(self): self.hosts_name = None self.results_dir = 'results' ## call on start playbook def playbook_on_play_start(self, name): self.hosts_name = self.play.hosts ## call at end playbook def playbook_on_stats(self, stats): hosts = sorted(stats.processed.keys()) result_hosts = [] for host in hosts: s = stats.summarize(host) dict = { "host": host, "result": { "ok": s['ok'], "changed": s['changed'], "unreachable": s['unreachable'], "failures": s['failures'] } } result_hosts.append(dict) …..
- 62. 機能 ▷ ビジュアルダッシュボード ▷ ロールベースのアクセス制御 ▷ ジョブスケジューリング ▷ グラフィカルな在庫管理 ▷ リアルタイムでの ジョブステータス更新 https://www.redhat.com/ja/technologies/management/ansible Ansible Tower Ansibleの管理・操作用のWeb GUI インタフェース。 10ホストまでは無料、それ以上は有償。 ホストの状態はAnsible Towerでも管理可能。