MSPだってプロビジョンしたい！

Ansible 勉強会 #1 ( http://ansible-users.connpass.com/event/5968/ )
でLTさせてもらった際のスライドです。

Transcript

1. MSP だってプロビジョンしたい！ Ansible 勉強会 #1 (LT 資料 )
2. 自己紹介 Name: Kei Iwasaki (@laugh_k) MSP( 監視運用代行 ) な インフラ屋をしています。
3. お話させていただく内容 お客さん環境の監視・運用代行を行っている インフラ屋が Ansible を少しずつ使い始めて 嬉しいなというところを紹介。
4. Ansible の嬉しいところ • クライアント側に特別なツールの導入の必要がない • sshconfig が使える • playbook が yaml 形式のため、設定ファイルを書く 延長線上の感覚で記載ができる。 • playbook が作業の記録として残る。再現もできる。
5. クライアント側に 特別なツールの導入の必要がない
6. クライアント側に特別なツールの導入の必要がない Ansible 以外にもプロビジョン系のツールは多数存在します。 とはいえ、お客さんの環境の管理をする際は、 そもそも下手にクライアントをインストールできない手前、 基本的にクライアント側は SSH アクセスができれば OK というのは 非常にありがたいです。
7. クライアント側に特別なツールの導入の必要がない もちろん CentOS5 系では python-simplejson が必要 selinux が動いている場合は libselinux-python が必要 だったりと、 必ずしも SSH だけで OK かといえばそうでもないケースは あったりするので注意は必要です。
8. sshconfig が使える
9. つまり
10. 踏み台を超えれる！
11. sshconfig が使える => 踏み台を超えられる 各お客さんのインフラ環境には 踏み台を超えないことにはそもそもアクセスができません。 オフィス DC 踏み台 Web Web DB DB
12. sshconfig が使える => 踏み台を超えられる 残念ながら Ansible に直接踏み台サーバ指定のオプションなどは 実装されていません。 しかしながら、環境変数 'ANSIBLE_SSH_ARGS' に SSH コマンドのオプションを渡すことができます。 ( ansible.cfg に ssh_args = … で指定しても OK )
13. sshconfig が使える => 踏み台を超えられる つまり、 こんな感じで sshconfig.project なんてファイルを用意して ... Host gateway HostName 192.0.2.10 User loginuser IdentityFile ~/.ssh/hoge.pem Host 172.16.2.* User loginuser IdentityFile ~/.ssh/hoge.pem ProxyCommand ssh -F sshconfig.project gateway nc -w 120 %h %p
14. sshconfig が使える => 踏み台を超えられる こんな感じで host.project なんてファイルを用意して ... [web] web01 ansible_ssh_host=172.16.2.11 web02 ansible_ssh_host=172.16.2.12 [db] db01 ansible_ssh_host=172.16.2.21
15. sshconfig が使える => 踏み台を超えられる こんな感じで base-play.yml なんてファイルを用意して ... --- - hosts : all user : loginuser sudo : True task : - name : install develop tools yum : name="{{ item }}" state=present with_lines : - "@Development Tools" - "@Compatibility libraries"
16. sshconfig が使える => 踏み台を超えられる 以下のようにすれば sshconfig.project に従って踏み台越えができる！ % export ANSIBLE_SSH_ARGS=' -F sshconfig.project ' % ansible-playbook base-play.yml -i host.project オフィス DC 踏み台 Web Web DB DB ansble-playbook
17. playbook が 設定ファイルを書く延長線上の感覚で 記載ができる
18. playbook が 設定ファイルを書く延長線上の感覚で 記載ができる yaml 形式でサーバの設定や構成を記載していけるため これまでサーバ管理をやってきた方でも 設定ファイルを書いていくのに近い感覚で記載ができます。 もちろん、 ansible 特有の書き方の部分もありますが、 そもそもで公式ドキュメントが非常に充実しているので 簡単な構成管理であればそれほど苦労せずかけます。
19. playbook が作業の記録として残る。 再現もできる。
20. playbook が作業の記録として残る。 再現もできる。 一度 playbook に落としこんで構築してしまえば LVS DC ansible-playbook
21. playbook が作業の記録として残る。 再現もできる。 品質を保ちつつ、再現ができる！ LVS LVS DC ansible-playbook
22. playbook が作業の記録として残る。 再現もできる。 HW 故障などで、急遽構築が必要になった場合なども ... ( ※ 実際に体験した話です ) LVS LVS DC2 ＿人人人人人人＿ ＞　突然の死　＜ ￣ Y^Y^Y^Y^Y ￣
23. playbook が作業の記録として残る。 再現もできる。 機器の調達ができれば、突貫の手作業よりも安全に構築できます。 ( ※ 実際に体験した話です ) LVS LVS だったもの DC2 新 LVS ansible-playbook
24. playbook が作業の記録として残る。 再現もできる。 本当に完璧にプロビジョニングをするにはやはり playbook をバージョン管理、 メンテナンス等をし続ける必要が出てくるかと思います。 それでも、まずは運用上頻繁に行う作業はもちろん、 忘れた頃にやってきそうな作業なども playbook 化しておくだけでも 作業負荷が減らせたりする部分は多いと思います。
25. 最後に 本当にすこしで、まだ手探り段階ではあるけれども 運用屋が Ansible うれしいな っていう点を 紹介させてもらいました。 むしろ「俺のほうがうまい使い方知ってる！」 みたいな話があったらぜひ聞いてみたいなと思っています。 完全な構成管理を行っていくのは 今すぐにというわけには行かない部分も大きいですが、 定常的な作業や、すでに手順書化されている部分を自動化する という視点などでアプローチしていくと 少しでも幸せになれるのではないでしょうか。
26. ご清聴ありがとうございました。