お伝えしたいこと
2021年 Ansible Advent Calendar 8日目の記事です。
元のカレンダーはこちらにあります。
Ansibleを始めるにあたり、どのあたりから考えていけば良いかの道標を書きます。
全て私の主観ですので、ユーザーの一意見としてカジュアルに読んでいただければと思います。
ちなみに、私のAnsible経験値は以下ぐらいのレベルです。
- Ansible Documentationを一通り読んだことはある
- PlaybookとRoleを作成して、簡易な自動化をしたことはある
- 業務用途での本格利用の経験は無し
- Towerは少し触ったことがある程度
- moleculeやコンテナ、CIなどのテスト自動化・効率化の経験値はゼロ (これから勉強したいところ)
- 自動化の闇や技術的負債といった部分については、身をもって経験したことはありません
従って、主に初心者〜中級に差し掛かるあたりの知識がカバー範囲となります。
各セクションに参考資料を貼っておきました。
むしろこちらが本編...というぐらいに充実した先人の知恵が詰まっているので、参考資料もぜひチェックしてくださいね。
- お伝えしたいこと
- Ansible学習ロードマップ
- 自動化検討の下準備
- Ansibleの超概要の理解
- Ansibleを触ってみて基本機能を理解する
- 基礎を固めつつプロトタイプの実装
- 業務をイメージして、必要なことを考える
- (参考) Ansibleのテクニック面の話
- まとめ
Ansible学習ロードマップ
大体以下のような順序で進めていくと良いかなと思います。
- 自動化検討の下準備
- Ansibleの超概要の理解
- Ansibleを触ってみて基本機能を理解する
- 基礎を固めつつプロトタイプの実装
- 業務をイメージして、必要なことを考える
具体例を示しつつ、一つずつ追っていきます。
自動化検討の下準備
自動化は長い道のりです。
初期学習、簡易検証・プロトタイプ作成 (Proof of Concept)、設計、実装、試験、運用引き継ぎに短くとも1年強、普通に考えると2-3年はかかると思います。
未経験であれば簡易検証の実施期間は予想することは不可能ですし (どのぐらい難しいかわかりませんよね)、設計以降のフェーズが延びることもざらだと思います。
更に、運用引き継ぎ後もトラブル対応、機能追加、運用に合わせた仕様変更、OSやAnsible周りのバージョンアップも継続的に実施が必要となります。
こうした息の長い案件を進めていくためには、以下のあたりを言語化しておくことが大事だと思います。
メモ帳でも良いので、どこかに書いておくと後から見返せるので便利です。
最初は曖昧、または局所的な目的・ゴールで良いと思います。
| 初期検討項目 | 詳細 |
|---|---|
| 目的 | 自動化をしたい理由。 人的ミスを減らしたい、繰り返し発生する作業をスクリプト化したいなど |
| ゴール | いつまでに何を達成すれば一旦完了とするか？ ゴールを達成したら一旦案件としてはクローズして、次案件でまた別の目的・ゴールを設定すると管理しやすい |
| やることリスト | ゴール達成までにできなきゃいけないことを書き出す。 中項目 (マイルストーン) と詳細で階層を分けると良いかも。 計画が荒いうちは、期限の設定を後回しにしても良い |
5W1Hで言うと、When/Whoといった詳細情報よりも先に、Why/What/Howで先に骨子を決めるという考え方です。
業務であれば、誰を巻き込むか(体制/Who)、早期撤退のタイミングをどこでどうやって判断するか、費用対効果 (How much) をいつ検討するかなどなど考えることはあるかもしれません。
しかし、個人学習であれば上表ぐらいで十分かなと思います。
目的・ゴール・やることリストは流動的なものです。
最初はかなりいい加減なものでも良いので、書くことが大事だと思います。
調査を進めていくにつれて、Ansibleでできること、できないことが見えてきます。
理解が深まったタイミングで、改めて書き直せば良いと思います。
短いサイクルで見直し続ければ、どんどん良い計画になっていくと思います。
こういった理由から、「最初は曖昧、または局所的」でも良いと書きました。
学習・検証を進めていくと、どうしても目的を忘れるレベルで深く調査する機会が出てきます。
そんな時に目的・ゴールを見返せると、その調査が無限に続くものではなく、目的・ゴールを満たせれば十分だと気づくことができます。
自分にとって難しすぎる調査 (ソースコードにしか書いていないような仕様の調査など) をどこまで進めるか、ハードルを下げる材料にもなりますので、目的・ゴールは自分の精神衛生のためにも何かしら書いておき、継続的にメンテすることをおすすめします。
もちろん、やることリストも重要です。
「次何やるか」を常に考え続けることはストレスフルなものです。
一旦リストに書き出し、機械的にタスクをこなしていくほうが、思考の負荷が下がります。
機械的にこなせない場合は、無理のないようにタスクのレベルを落とすか、細かい粒度にするか、順序を変えるか、誰かを頼るといった工夫が必要になると思います。
具体例
今即興で目的とゴールを考えてみます。
やることリストについては、後続の#Ansibleの超概要の理解と#Ansibleを触ってみて基本機能を理解するを参考にしてください。
まず材料となる「やりたいこと (≒ゴール)」ですが、「NW機器の初期構築と、よくやる運用作業を自動化したい」とします。
ちょっと範囲が広いので、要素を分解してハードルを下げます。
- NW機器の初期構築
- よくやる運用作業の自動化
「よくやる運用作業」も局所化することで更にハードルを下げられます。
「ハードルを下げれば下げるほど効果も下がる」と思われるかもしれませんが、簡単なことを早期にクリアしてレベルを上げ、それから難しい課題に挑戦したほうが効率が良いです。
以下の2つのどちらかに絞ろうと思います。
- showコマンドを実行して結果を表示する
- 設定変更を自動化する
※ゆくゆくは、設定変更の自動化を積み上げて「業務フロー全体を自動化」したり、「showコマンドの結果次第で条件分岐」をして安全性を高めたりといったレベルの高いゴールを目指していくことになります。しかし、自動化が初めてであればこういったことは「ロードマップ」として退避しておいて、一旦はハードルの低いゴールを目指したほうが精神的に楽ですし効率が上がります
Ansibleにとってどちらのほうが簡単かはこの時点ではわからないかもしれません。
その場合は「どちらかやる」として、一旦先に進んじゃいましょう。
※どちらも簡単にできます
次に目的ですが、これがなかなか難しいと思います。
インターネット上で情報を集めつつ、一旦「自分が必要だと思った」自動化のメリットを抽出しましょう。
あまり多くを求めず、1つか2つ程度に絞るのが良いと思います。
自動化でありそうなメリットとしては、以下があると思います。
- 時間節約 (1コマンドで一連の処理が走るため)
- ミスの削減 (1コマンドの実行にミスが入り込む余地は少ない。もちろん自動化の仕組み自体にミスがないことが前提)
- 作業が楽になる (1000行のコマンドコピペよりも、自動化コマンドの1回実行の方が楽)
- 作業前のレビューが楽になる (スクリプト自体のレビューは開発時のみ。運用時はスクリプトに渡すパラメータのみのレビューになる。手順書のファイル全体レビューよりは楽)
時間節約によって結果として「工数削減」、工数削減によって「コスト削減」などもある「かも」しれません。
ただ、これらは上記要素の「結果」ですので、本当にそうなるかの予想は立てづらいです。
高度な目的は、影響を与える要素が多様になります。
例えば、自動化実装して運用引き継ぎした後は自動化サーバや自動化製品、スクリプトの「運用」があります。
こういったことも考慮して序盤から効果予測することは難しいので、最初は「単純な目的」からスタートするのがコツだと思います。
例えば検討フェーズが進み、設計がある程度見えてきたあたりで最終確定させるとか...。
全てフィーリングなので「これが正しい」というものではありませんが、参考になれば幸いです。
参考資料
ここまで、「目的やゴールは簡単で良い」、「継続的に修正していくことで精度が上がる」とお話してきました。
ですが、「とはいえ、業務まで見据えてもう少し精度高く検討したい」という方もいるかもしれません。
業務形態は人それぞれですので、実際の設計・構築・運用の業務フローや各担当者のスキルレベル、部署の理解などを踏まえて戦略を立てていく必要があります。
「部署の理解」が難しい場合は「1人でも良いから仲間を作る」ところから始まるかもしれませんし、「じゃあ自動化やります」で案件化できることもあるかもしれません。
こういったことを全て自分で考えることは難しいので、周囲の知見を持つ方にも相談してみることをおすすめしますが、以下に良い先人の知恵がありますのでURLを貼ります。
業務として自動化を検討する際にどんなことを考えるか、とても勉強になります。
本記事に書いてある内容よりも高度な内容ですが、楽しくわかりやすくまとめてあります。
興味のある方はぜひご覧ください。
Ansibleの超概要の理解
次に、Ansibleについて表面的なことを理解するとその後の展開がスムーズになると思います。
Ansibleは自動化を実現する手段の一つです。
Ansibleとは何か？ (何のための手段か？)
他にどんな手段があるか？
他の手段と比較して、Ansibleにどのような特徴があるか？
Ansibleの動作要件は？
Ansibleは何を自動化できるのか？
このあたりの質問に答えられるぐらいに理解してみるところから始めてみると良いかもしれません。
こういった情報は、日本語 (時には英語) のブログや動画から情報を集めると良いかもしれません。
最終的には英語の公式ドキュメントから最新かつ正確で、サポートを得られるような構成の情報を集めるのが良いですが、最初はわかりやすさを優先するのもアリだと思います。
英語が得意な方はYouTubeで"Ansible" や "Ansible Tutorial" などで検索したり、検索エンジンで"Ansible Getting Started" を探すのも良いでしょう。
日本語で知りたい方は、"Ansible 概要" など日本語を混ぜてググってみるとか。
慣れてきたら、"Ansible Documentation" から公式ドキュメントを探し、読み進めていきましょう。
具体例
ご参考までに、Ansibleの超概要を簡単に書いておきます。
| 質問 | 回答 |
|---|---|
| Ansibleとは何か？ | 自動化、可視化ツール。 べき等性を持たせる実装にすれば構成管理にも使える |
| 他にどんな手段があるか？ | ChefやPuppet、Saltとよく比較される。 クラウド分野だとTerraformなど。 そしてDevOpsツール全般は、PythonやRubyの自力開発や、Teratermマクロなどとも比較される印象です |
| 特徴は？ | プログラミング不要 (YAML+Jinja2)。 エラーハンドリングなどツール任せにできるのでプログラミングよりハードルが低い。 エージェント不要。 SSHやHTTPSで自動化命令を送る。 ソースコードはPythonで書かれている。 変数、条件分岐、ループなど色々できる。 凝った条件分岐には向かない。 Chef、Puppet、Saltと比較してメジャーな印象。 クラウドの自動化はTerraformを使う人も多い印象 |
| Ansibleの動作要件は？ | AnsibleをインストールするサーバはLinux限定。 Pythonバージョン一定以上。 最低限のCPU/RAM性能。 SSH/HTTPSが使えることなど |
| 自動化対象 | SSHかHTTPS (RestAPI) に対応する製品全て。 特にモジュールが充実している製品が自動化に向いている (参考)。 Linuxが得意だが、NW機器、Windows、クラウド、一部ミドルウェアにも対応 |
参考資料
下に行くにしたがって内容が分厚くなってきます。
いずれも非常にわかりやすく書かれているので、最初の読み物としておすすめです。
- Wikipedia - Ansible
- Red Hat - WHAT IS ANSIBLE?
- SIOS TECH.LAB - 【連載】Ansible入門 その1:Ansibleとは
- Ansible ネットワーク自動化チュートリアル
- Ansible トレイルマップ (まずはMt. YAMLから)
Ansibleを触ってみて基本機能を理解する
実際にハンズオンしつつ、わからないところは検索することで理解が一気に進みます。
大抵の製品は「VMにツールをインストールしてハンズオン」ですが、Ansibleの場合は他にも手段があります。
おすすめ順に書いていきます。
| ハンズオン方法 | 詳細 |
|---|---|
| Ansibleもくもく会 | 数ヶ月に一度、無料ハンズオンがあります。 Connpass上で登録することでイベント開催の通知を受け取れます。 Ansibleインストール済みの無料AWS環境、相談に載ってくれるメンター、教材と全て揃っています。 Ansibleの経験値ゼロでも、まずは参加することをおすすめします。 最初はServer編にご参加ください |
| Killercoda | ブラウザ上でAnsibleハンズオンができるコンテンツです。 メンターは不在ですが、説明不要なほど親切な解説があります。 もくもく会のタイミングが合わない時、予習・復習したい時などにおすすめです |
| 自力構築 | KVMやVirtualBoxでVMを立てて、Ansibleをインストールして検証します。 インストール方法を学べる点、時間制限なく学習できる点ではこちらもオススメです。 インストール方法はディストリビューションのパッケージマネージャーか、pipがあります。 ユーザー権限でインストールできる pip install --user ansible、またはvenvの中にインストールする方法をおすすめします |
ハンズオンの進め方案
ハンズオンを始める前に、既に自動化で実装してみたい処理は1、2あると思います。
そして予習を進めている方は、変数設計やRole分けの重要性を理解されているかもしれません。
ただ、最初はゴールに直結しないネタでも良いので可能な限りハードルを下げることをおすすめします。
例えば、以下のような流れです。
- debugモジュールで画面出力してみる
- 変数なし、単一Playbookで実装してみる (まずはLinuxから)
- 変数を使ってみる
- 条件分岐を入れてみる
- ループ処理を試してみる
- ansible.cfgをホームディレクトリに作っていじってみる
- フィルタを使ってみる
- import_tasks/include_tasks, import_vars, include_vars などを使い、Playbookファイルが肥大化しないよう整理してみる
- Role化してみる
- (このあたりでそろそろやりたかった自動化にチャレンジ)
その後も続きます。
- PlaybookとRoleを別リポジトリに分けてGitに保存してみる
- Gitで保存したPlaybookやRoleに簡単なREADME.mdをつけてみる
- Roleをrequirements.ymlでGitからインストールできるようにしてみる
- Moleculeでテスト自動化に挑戦
- CIに挑戦
- ...
参考資料
基本は、公式ドキュメントに従って手を動かしていくのが良いと思います。
...と言いたいところですが、「Ansible の使い方」という日本語で公式に負けないレベルのすごいドキュメントがあるので、そちらを先に読んでみると良いと思います。
『Ansible実践ガイド』や『Ansibleクックブック』といった書籍もAnsible界隈で人気があるので、本屋に行く機会があれば中身をチェックしてみるのも良いと思います。
初期の学習にあたり、公式情報と合わせて知っておくと便利な内容を#(参考) Ansibleのテクニック面の話に書きましたので、そちらも合わせてご覧ください。
基礎を固めつつプロトタイプの実装
#Ansibleを触ってみて基本機能を理解すると内容が被るので、ここは割愛します。
プロトタイプの実装が終わるまでは納期の予想が困難であるため、ゆるめにスケジュールを立てると良いかもしれません。
業務をイメージして、必要なことを考える
私も未経験なので、このあたりは全て想像ですがご参考までに...。
Ansibleを使っている状況をリアルに想像すると、色々な心配事が出てくると思います。
多分これがシステム設計や運用設計につながるんだろうなと思います。
ぱっと思いつくだけでこれだけあります。
- Playbookの実行は運用者にとって本当に「楽」なのか？
- Ansibleサーバは誰が管理するのか？
- Playbookは同僚がメンテしてくれるのか？できるのか？
- 新規参入者がAnsibleとPlaybookの構成を理解できるか？
- Playbookが乱立しないか？
- Ansibleを毎年バージョンアップするたびに全てのPlaybookを動作確認するのか？
- テストに追われて業務が回らなくなるのでは？
- AnsibleサーバのOSがEOLになったらどうするのか？
- バックアップはどう実装するか？
- Ansibleサーバのバックアップ
- Playbook/Roleのバックアップ
- Ansible実行で大事故が起こるリスクは？
- 運用フローにはまるのか？
- Ansibleサーバの監視はどうやるのか？
- Ansibleサーバに侵入された時のリスクは？どう回避する？どう被害を極小化する？
- Playbookが知らぬ間に書き換わっていたらどうなる？
- Ansibleサーバに誰でもログインできてよいのか？
- Playbook実行の監査ログは取るのか？
- Ansibleという製品が突然...なくなったら...
- レアケースでPlaybookが暴走したら？
- Playbookに想定外のパラメータが渡されたら？
- Ansibleサーバにログイン情報をテキストで保存するのってどうなのか？
- 知識のない人がPlaybookを書き換える心配はないか？
- 誰かメガンテする心配はないか？
- (例：
ansible -a 'shutdown -h now' all)
- (例：
- Ansible Playbookに何でもやらせすぎて後で困らないか？
- 用途と利用部署がわからず、闇鍋状態にならないか？
- 廃止できない、メンテナンスの調整がつかないサーバにならないか？
最初から考えると先に進めなくなるので、初期検討の間に課題を思いついた場合はどこかのメモ帳に書いて忘れることをおすすめします...w
(参考) Ansibleのテクニック面の話
Ansibleの公式ドキュメントは非常に良くできています。
これを読めば大体わかると言っても過言ではありません。
しかし、「これを知っていればハマらずに済んだ」ということもあるので、簡単に触れておきたいと思います。
予備知識がないと「何のことやら」となってしまいますが、その点はご了承ください。
インストール方法
インストール方法はいくつかあります。
- OSのパッケージマネージャーを使う
- pipでインストールする
- コンテナを使う
とりあえず検証で使うだけであれば、コンテナを使うかユーザー権限でインストールすることをおすすめします。
VM上でユーザー権限で使う方法は、2案あります。
- venv内で
pip install ansible - venvを作らず
pip install --user ansible
後述の#エディタ機能を活用するを意識するなら、venvを作らずpip install --user ansibleがおすすめです。
venv無しの方が、拡張機能との相性で問題が発生しにくいためです。
venv無しでpipを使うと環境が汚れないか...と心配の方は、以下の記事も併せてご覧ください。
Pythonパッケージを一括削除するだけなら、pip freeze --user | xargs pip uninstall -yでできます。
Ansibleの処理の順序
経験則なので100%正確とは言えませんが、ざっくり以下の流れで進んでいると思います。
従って、YAML観点の文法エラーがあるとその先に進みません。
エラーメッセージから、どの段階で躓いているか判断できるようになると切り分けが早くなります。
YAMLとJinja2
YAML観点とJinja2観点の文法にも詳しくなると必ず役に立ちます。
変数やフィルタ、条件分岐、ループなどを使わないうちは、Jinja2は登場しません。
なので、最初はこれらの機能を省いてYAMLに慣れることをおすすめします。
YAMLについては、以下の記事が参考になります。
yaml.orgにも仕様書はあるのですが、難解なので最初はあまりおすすめしません。
その後で、Jinja2の文法を覚えていきましょう。
Jinja2については、以下のドキュメントが参考になります。
このドキュメントに記載されている知識はAnsibleにも使えますが、一部YAMLの構文と競合することで実質的に使えない部分もあるのでご注意ください。
template Moduleで使う.j2ファイルであれば、大体使えます。
Jinja2 - Template Designer Documentation
Jinja2について更にTipsですが、Python文法の基本の型と四則演算、メソッドを覚えておくとオトクです。
配列の足し算など、以外と使えることがあります。
エディタ機能を活用する
viでPlaybookを書いて、ansible-playbookコマンドで実行。
それでも十分ではあります。
しかし、最近はVS CodeのAnsible拡張機能があるので、高機能なエディタ機能を使うと捗ると思います。
キーワードの色分け、エラーの自動検出、入力補完など色々できます。
概要資料を貼っておきますので、よろしければチェックください。
どちらのリンクも同じ資料です。
資料を書いたのは私なので、質問も受け付けられます。
『AnsibleユーザーのためのVS Code拡張機能の紹介』
メインマシンがWindowsで、AnsibleサーバがLinux VMのという構成でもRemote - SSHなどの拡張機能でVM上のPlaybookを直接編集できます。
VS Codeは...いいものですよ。
まとめ
Ansibleを始めるにあたって考えること、各工程の参考URLを示しました。
私の意見については、2割ぐらい信じつつ参考にしていただければと思います。
参考URLは本当にオススメなので、ぜひ目を通してください。
