チーム内での Ansible 勉強会の資料を公開。
公式サイトは以下。
前提知識としては、以下。知っていたほうが理解が早い。
- unix コマンド
- YAML
公式から引用すると、Ansible は simple IT automation engine。
Ansible is a radically simple IT automation engine that automates cloud provisioning, configuration management, application deployment, intra-service orchestration, and many other IT needs.
—– How Ansible Works より
Ansible の概要
- Ansible は、サーバの構成管理ツールと言われている。
- サーバ構成管理とは? Ansible が主に対象としているのは以下。
- サーバのソフトウェアインストール/アップデート
- 設定ファイルの作成/修正/削除
- サービス停止/起動
- ファイル (アプリケーション) の配布
- 類似ツールに、Chef や Puppet がある。
- Infrastructure as Code の流れや世の中のクラウド化に伴い、評価されている
- Infrastructure as Code: インフラの状態をコード化できる
- ソフトウェア開発でのナレッジが活かせる
- バージョン管理: git, subversion, …
- コードレビュー: pull request, other tools, …
- テスト: test framework like serverspec, infrataster, …
- デプロイ、CI … : jenkins, …
- 設計ドキュメントと実装との差分がある程度埋まる
- ソフトウェア開発でのナレッジが活かせる
- サーバ構成管理とは? Ansible が主に対象としているのは以下。
- もともとはAnsible, Inc により開発されていたが、2015年10月に Redhat により買収された
以下は、Ansible の動作イメージ。(https://sysadmincasts.com/episodes/46-configuration-management-with-ansible-part-3-4 より引用)
Ansible の特徴・利点
- 冪等性
- 何回やっても同じ結果になること。
- モジュール側でチェック処理などを吸収してくれる。
- shell モジュールや rawモジュールなど、一部、冪等性が担保されないものもある。
- 単純 re-run が可能。
- Immutable Infrastructure との相性の良さ。
- 何回やっても同じ結果になること。
- Python の “バッテリー同梱 (Battery Included)” という考え方を引き継いでいる。
- 標準モジュール/機能の豊富さ。
- Push 型アーキテクチャ
- 管理対象ノード (Managed Node) に SSH さえできれば良い。
- エージェントレス。
- マルチプロセスで並列実行が可能。
- Ansible 実行サーバを Control Machine, 管理対象ノードを Managed Nodeと呼ぶ。
- シンプル
- 独自 DSL ではなく、YAML。
- データ志向の自動化言語である YAML
- 学習コストが低い。chef や puppet のように Ruby などの独自 DSL を覚える必要がない。
- ファイル・ディレクトリ構造の自由度の高さ。決まり事が少ない。
- Ansible 自体は Python で書かれているが、プラグインなどの開発が不要であれば、Python を使う必要なし。
- 独自 DSL ではなく、YAML。
Ansible の用途
- 複数サーバへの……
- バッチ処理
- システム全体の設定 (
/etc
以下の設定)- hosts へのエントリ
- ネットワーク設定
- ルーティングテーブルエントリの追加
- SOCKS プロキシ
- proxy.pac
- ファイル配布
- SSHキーの配布
- システム全体の設定 (
- ミドルウェアのインストール/アップデート
- yum
- apt
- homebrew
- gem
- アプリケーションデプロイ
- バッチ処理
公式サイトの Use case を直訳すると、以下。
- provisioning (Bootstrapping と呼ぶほうが正しいかも)
- ベアメタルサーバやVMに対する、PXEブート (遠隔電源操作), キックスタート (linux の自動インストール)
- VM (クラウドインスタンス) に対する、テンプレートからの作成
- configuration management
- コンフィグファイルの中央管理
- application deployment
- Ansible でアプリケーションを定義しデプロイすることで、開発環境から本番環境までのアプリケーション全体のライフサイクルを効果的に管理できる
- continuous delivery
- CI/CD のパイプラインはたくさんのチームから依頼を引き受けることになる。だれもが使えるシンプルなAnsible を使うことで適切にアプリケーションのデプロイ管理ができる
- security & compliance
- Ansible でセキュリティポリシを定義することで、サイト全体のセキュリティポリシのスキャンと修復が可能になる。
- orchestration
- 管理対象のコンフィグは多種多様に存在し、かつ、それぞれが相互に作用している。Ansible は、この複雑で混沌とした中に秩序をもたらす。
仕事ではあまり OS を扱うことは少なく、以下のようなレイヤの低いやつを raw モジュールを 駆使して構成変更したり情報取得したりしている。
- ESXi
- iLO
- BIOS
- その他 SSH 可能なノード
Ansible を動かしてみよう
Ansible のインストール
Installation – Ansible Documentation を参照
- Control Machine : Ansible 実行サーバ
- Python 2.6 or 2.7 が必要
- yum や rpm, apt などのパッケージ管理システムでインストール可能
- Managed Node : 管理対象ノード
- Control Machine から SSH できればOK
Ansible 実行してみる
ansile を単体実行するコマンド書式は以下。
1
|
|
オプション | 意味 |
---|---|
-f | 実行多重度。デフォルトは5 (ansible.cfg で規定) |
-m | モジュール名 |
-a | モジュール引数 |
以下はローカルで動くモジュールの一部を紹介。
モジュール | 機能 |
---|---|
ping | その名の通り ping |
shell | コマンドを引数に渡して shell 実行可能 |
file | ファイルのパーミション設定とか、ディレクトリ作成とか |
template | Control Machine のテンプレートファイル (テンプレートエンジンは jinja2 ) を Managed Node に配布 |
service | init system のサービスを制御 |
sysctrl | カーネルパラメータの操作 |
raw | ssh でナマの文字列をそのまま流し込む |
インターネットに接続していれば、以下も有用。
モジュール | 機能 |
---|---|
yum | yum によるソフトウェアパッケージ管理 |
get_url | HTTP でのダウンロード (curl, wget 的な) |
git | git リポジトリからの clone |
バージョンが 2 系からJunos とか Cisco, ESXi 用のモジュールもある。
<host-pattern>
でホストを指定する。
all とすると、/etc/ansible/hosts
で定義しているすべてのホストが対象となる。
以下は ping
モジュールを利用したコマンド。
localhost に ping する ansible コマンド。
-m
オプションのあとに ping
モジュールを指定する。
1 2 3 4 5 |
|
以下は、shell
モジュールを利用したコマンド。
-a
オプションのあとにモジュール引数を渡す。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
|
ただし、実際には ansible
コマンドを使うことはめったにない。
複数のノードに対してタスクを実行したり、複雑なタスクを実行する場合は、 Inventory ファイルや Playbook ファイルを利用する。
Ansible の主なファイルは以下。
- ansible.cfg
- ansible に関するデフォルト設定ファイル。
/etc/ansible/ansible.cfg
- ansible に関するデフォルト設定ファイル。
- Inventory
- ansible で管理対象ノードを定義するファイル
- Playbook
- タスク (実行手順) を定義するファイル
Inventory
Inventory ファイルは、ansible 用の hosts ファイル。 ホストやグルーピングの設定、変数などの定義が可能。 ホストや IP アドレスはレンジでの指定も可能。
- ホストとグループの定義
- ホスト変数とグループ変数
- グループのグループ
以下は、デフォルト設定 /etc/ansible/hosts
。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 |
|
Playbook
Playbook はタスクをまとめて、1つのファイルに記述したもの。 実行順序や依存関係、変数を利用した処理、ループ処理などが表現できる。
Playbookの基本的なフォーマットは以下。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
|
タスク
ansible ではホストに対する処理をタスクという単位で管理する。 通常、1つのタスクには1つのモジュールを指定する。
1 2 |
|
name は description なので省略可能だが、メンテナンス性や playbook 実行時にわかりやすいので絶対書いたほうが良い。
name は日本語でも記載可能。 (文字コードは注意)
ハンドラ
ハンドラは、特定のタスクの実行後に、予め指定した処理を実行するための仕組み。 以下のように記述する。
1 2 3 4 5 6 7 8 |
|
この場合、「be sure httpd is installed」というタスクが実行されると、続いて「notify」で指定された「restart httpd」というハンドラが実行される。
ループ
with_items
で列挙した項目に対してループ処理が可能。
リモートのコマンド結果 (標準出力)に対して、一行ずつ処理するタスクが以下。
1 2 3 4 5 6 7 |
|
こんな感じで直接リストを書いてもOK。
1 2 3 4 5 6 7 |
|
playbook のサンプル
まずはインベントリファイル sample_hosts
を作成する
“fujiko” グループに所属しているホストのリスト (計3台分) を記述している。
1 2 3 4 |
|
次にplaybook ファイル sample_playbook.yml
を作成する。
計 3 つのタスクを記述している。
register: <変数名1>
という書式でタスク実行結果を変数に保存する。 この変数を Registered Variable と呼ぶ。
debug: var=<変数名1>/stdout_lines
により、変数に保存したタスク実行結果 (の標準出力) を表示している。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
|
playbook の実行前に syntax check (構文の確認)をする。
1 2 3 |
|
次に playbook を dry-run。 実行する前に何が変更されるか、特に、実行時に消えてしまうリソースや入れ替わるリソースを知りたい場合に有効。
1 2 |
|
Playbook を実行する。--step
オプションを付けると、タスク単位にステップ実行もできる。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 |
|
playbook は role という単位で分割可能。再利用性が高くなり、1 つ 1 つの playbook の 見通しも良くなるなるので、相互に関係のないタスクは分離していくほうが望ましい。
大規模な環境用に、Best practices が示されているので、ご参考に。
システム情報を利用する: Facts
Playbook 実行結果に「GATHERING FACTS」と出力されている。 これは対象サーバから情報を収集する処理。たとえば、リモートサーバのIPアドレスや OS名などのシステム情報を、Playbook 中で変数として扱うことができる。
次のように setup
モジュールにより、どんな変数が利用可能かを確認することができる。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 |
|
たとえば、IPアドレスは {{ ansible_eth0["ipv4"]["address"] }}
のように、Playbook の中で変数として
扱うことができる。
その他、facter
や ohai
がリモートホストにインストールされていればそれらも利用可能。
facts よりも詳細な情報が取得できる。
この facts は、いまのところリモートホストが Linux でのみ動作する。 リモートホストが windows やネットワーク機器の場合は以下のように無効化できる。
1 2 |
|
また、システム情報を利用しない場合も無効化することで実行時間短縮が図れる。