MSP だってプロビジョンしたい！ Ansible 勉強会 #1 (LT 資料 )

自己紹介 Name: Kei Iwasaki (@laugh_k) MSP( 監視運用代行 ) な インフラ屋をしています。

お話させていただく内容 お客さん環境の監視・運用代行を行っている インフラ屋が Ansible を少しずつ使い始めて 嬉しいなというところを紹介。

Ansible の嬉しいところ ● クライアント側に特別なツールの導入の必要がない ● sshconfig が使える ● playbook が yaml 形式のため、設定ファイルを書く 延長線上の感覚で記載ができる。 ● playbook が作業の記録として残る。再現もできる。

クライアント側に 特別なツールの導入の必要がない

クライアント側に特別なツールの導入の必要がない Ansible 以外にもプロビジョン系のツールは多数存在します。 とはいえ、お客さんの環境の管理をする際は、 そもそも下手にクライアントをインストールできない手前、 基本的にクライアント側は SSH アクセスができれば OK というのは 非常にありがたいです。

クライアント側に特別なツールの導入の必要がない もちろん CentOS5 系では python-simplejson が必要 selinux が動いている場合は libselinux-python が必要 だったりと、 必ずしも SSH だけで OK かといえばそうでもないケースは あったりするので注意は必要です。

sshconfig が使える

つまり

踏み台を超えれる！

sshconfig が使える => 踏み台を超えられる 各お客さんのインフラ環境には 踏み台を超えないことにはそもそもアクセスができません。 オフィス DC 踏み台 Web Web DB DB

sshconfig が使える => 踏み台を超えられる 残念ながら Ansible に直接踏み台サーバ指定のオプションなどは 実装されていません。 しかしながら、環境変数 'ANSIBLE_SSH_ARGS' に SSH コマンドのオプションを渡すことができます。 ( ansible.cfg に ssh_args = … で指定しても OK )

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

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

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"

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

playbook が 設定ファイルを書く延長線上の感覚で 記載ができる

playbook が 設定ファイルを書く延長線上の感覚で 記載ができる yaml 形式でサーバの設定や構成を記載していけるため これまでサーバ管理をやってきた方でも 設定ファイルを書いていくのに近い感覚で記載ができます。 もちろん、 ansible 特有の書き方の部分もありますが、 そもそもで公式ドキュメントが非常に充実しているので 簡単な構成管理であればそれほど苦労せずかけます。

playbook が作業の記録として残る。 再現もできる。

playbook が作業の記録として残る。 再現もできる。 一度 playbook に落としこんで構築してしまえば LVS DC ansible-playbook

playbook が作業の記録として残る。 再現もできる。 品質を保ちつつ、再現ができる！ LVS LVS DC ansible-playbook

playbook が作業の記録として残る。 再現もできる。 HW 故障などで、急遽構築が必要になった場合なども ... ( ※ 実際に体験した話です ) LVS LVS DC2 ＿人人人人人人＿ ＞　突然の死　＜ ￣ Y^Y^Y^Y^Y ￣

playbook が作業の記録として残る。 再現もできる。 機器の調達ができれば、突貫の手作業よりも安全に構築できます。 ( ※ 実際に体験した話です ) LVS LVS だったもの DC2 新 LVS ansible-playbook

playbook が作業の記録として残る。 再現もできる。 本当に完璧にプロビジョニングをするにはやはり playbook をバージョン管理、 メンテナンス等をし続ける必要が出てくるかと思います。 それでも、まずは運用上頻繁に行う作業はもちろん、 忘れた頃にやってきそうな作業なども playbook 化しておくだけでも 作業負荷が減らせたりする部分は多いと思います。

最後に 本当にすこしで、まだ手探り段階ではあるけれども 運用屋が Ansible うれしいな っていう点を 紹介させてもらいました。 むしろ「俺のほうがうまい使い方知ってる！」 みたいな話があったらぜひ聞いてみたいなと思っています。 完全な構成管理を行っていくのは 今すぐにというわけには行かない部分も大きいですが、 定常的な作業や、すでに手順書化されている部分を自動化する という視点などでアプローチしていくと 少しでも幸せになれるのではないでしょうか。

ご清聴ありがとうございました。