AnsibleによるInfrastructure as code入門

Transcript

• 1. Ansibleによる Infrastructure as Code入門 2014/12/17 kawasaki.rb #19 @kk_Ataka
• 2. 自己紹介 4 Twitter: @kk_Ataka 4 GitHub: gosyujin
• 3. アジェンダ 1. 構成管理ツールの長所/短所 2. Ansibleの長所/短所 3. Ansible入門
• 4. 話さないこと 4 本格的なAnsibleの使い方 4 yamlとは、yaml構文
• 5. 対象者 1. 構成管理ツール何それな人 2. サーバの構成管理を手作業で行っている人 3. Ansibleを使いたいなーと思っている人
• 6. 構成管理ツールの長所/短所
• 7. サーバの構成管理とは 1. サーバを調達し、必要なMW, SWなどをインストールする こと 2. 設定ファイルを適切に編集すること 4 これらの作業を適切に維持、管理してくれるツールの事 を「構成管理ツール」という ※ 「サーバが正しく稼動していること」の監視、確認は今回対 象外
• 8. サーバの構成管理の辛さ 4 サーバが複数台構成になっている場合、 4 サーバ間で 一部を除き 同一設定を維持しなければなら ない 4 設定変更が発生した場合、全てのサーバにそれを適用し なければならない
• 9. サーバの構成管理の辛さ 4 設定ファイルってきちんと管理なされていない印象… 4 日付管理 xxx.conf xxx.conf.20141001 xxx.conf. 20141101 が多い… 4 手順(長い)があっても、それ手作業でやるの…？ 4 ダブルチェック？トリプルチェック？
• 10. そこで構成管理ツール
• 11. 構成管理ツールの嬉しさ 4 サーバ構築手順をコード化できる 4 Infrastructure as Code 4 何度実行しても同じ結果になる 4 複数のサーバに一発で環境構築できる 4 コードなのでコードレビューもできる 代表的なツール(独断)としてChef, Puppet, Ansibleなどが挙 げられる、今回はAnsibleを使ってみようという話
• 12. Ansible 4 あんしぶる 4 由来はハイニッシュ・ユニバースシリーズ1 に登場する超 光速通信技術 4 Python製 4 基本理念は シンプル 1 アーシュラ・K・ル・グウィン著
• 13. Ansibleの長所/短所
• 14. Ansibleの長所(構成管理ツールとして) 4 べき等性(Idempotency)がある 4 前述した、何度実行しても同じ結果になること 例 「 `hoge.conf` の最後に "proxy=http://hoge..." を追加する」という処理をシェルでフツーに作ると、 そのシェルを実行するたびに "proxy=..." が追加されてしまう… (回避するための処理を書くのはけっこうめんどくさい) べき等性があれば、何度やっても同じ結果に。便利！
• 15. Ansibleの長所(構成管理ツールとして) 4 過去の資産を活用できる 4 シェルスクリプトでInfrastructure as codeっぽいこ とをしていたなら、それを再利用できる 4 Ansibleからシェルスクリプトをサーバへ送り、実行 できる機能がある 4 資産をそのまま流用するとべき等性はない2 2 うまくやればできる sh hoge.sh creates=/tmp/exist.txt でexist.txtがあればスキップ
• 16. Ansibleの長所(競合ツールと比べて) 4 python コマンドが実行できるサーバにSSH接続できればす ぐ使える 4 サーバ側に余計なツールをインストールする必要がない 4 Chefなどでは基本的にサーバにもエージェントをイン ストールする必要がある 4 必要がファイルが少ない 4 とりあえず2ファイルあればいい(後述)
• 17. Ansibleの長所(競合ツールと比べて) 4 処理は yamlファイル で書く 4 Python製だがPythonを書く必要はない 競合ツールと比べてきわめてシンプル
• 18. Ansibleの短所(構成管理ツールとして) 4 学習コスト…Ansible自体, Playbookの書き方… 4 Ansibleの変更に追従していく必要あり 4 これはちょっと大変かも(ハマった) 何台のサーバに何回(どのくらいの周期で)使うか、それを手作 業でやって生きていけるか…天 にかけてみる
• 19. Ansibleの短所(他の競合ツールと比べて) 競合ツールと比べてきわめてシンプル…とはいうものの 4 大規模システムの構成管理は苦手 4 複雑な処理も苦手 両方ともできないことはないけど、こんなときは素直にChef などを導入したほうが良さ気 逆に小さな環境にChefを導入しようとしたらかなりToo muchかも...
• 20. Ansible入門
• 21. 登場人物 1. ホスト 4 Ansible を実行するマシン 4 Python 2.6 - (Python 3 未対応) 2. サーバ 4 Ansible で環境を整えるマシン 4 Python 2.4 -
• 22. 実行するために必要なファイル 4 inventoryファイル 4 playbookファイル
• 23. inventoryファイル 4 ini形式で実行対象のサーバを記述する、変数も使える [web] web01.example.com web02.example.com [web:vars] ansible_ssh_port=20022 [db] db01.example.com
• 24. playbookファイル こんなファイル。 - hosts: all sudo: yes remote_user: vagrant vars: username: newuser tasks: - name: ユーザを追加するよ user: name={{ username }} group=vagrant shell=/bin/bash
• 25. playbookファイル 解説 大きく分けて3つのセクションに分けられる 4 TARGETセクション 4 VARSセクション 4 TASKセクション 4 モジュール
• 26. playbookファイル 1 TARGETセクション どこにだれがインストールするか - hosts: all # すべてのホストに sudo: yes # sudo使う remote_user: vagrant # vagrantユーザでログイン
• 27. playbookファイル 2 VARSセクション 変数を指定する。TASKセクションで使用する vars: username: newuser
• 28. playbookファイル 3 TASKセクション どんなことをするのかモジュールを使って記述する tasks: - name: ユーザを追加するよ # taskの名前、必須ではない user: name={{ username }} group=vagrant shell=/bin/bash # モジュール VARSで宣言した変数も使える
• 29. playbookファイル 3 TASKセクション 4 userモジュールを使って以下のユーザを追加している 4 ユーザ名は newuser (VARSの変数から) 4 グループは vagrant でログインシェルは bash
• 30. デモ