Puppet Dojo #2やります これに行ってきました。事前に gihyo の mizzy さんの連載を半分くらい読んでいったのですんなり聞けました。セキュリティ向上という視点はなかったなあ。今日の午後からも実践編に参加してきます。メモは以下に。
オープンソースでシステム管理の自動化を実現！ Puppetを使うこれだけの理由
Puppet?
Ruby でかかれたオープンソースの自動化ツール
何を自動化するか
- サーバの設定
- ソフトウェア開発以外の様々な作業
導入のメリットは何か
自動化するメリット
- 放置で ok なので楽
- 手作業によるミスを防げる
- セキュリティ向上にも一役買う (はてなの事例)
- 再現性がうまれる
- 決まった手順にしたがって自動で作業が進むので誰がやっても同じ結果、同じ環境になる
- 同じ環境になっていることが保証できる (人力でやった場合本当にまったく同じ手順だったかどうかを証明できない)
抽象化によるメリット
- OS ごとの違い、ディストリビューションによる違い、もろもろを吸収できる
- adduser/useradd
- 抽象化の度合いが高い = 再利用できる
- 全サーバに共通の設定/ウェブサーバに共通の設定/メールサーバに共通の設定
バージョン管理システムと連動するメリット
- 履歴が残る、参照できる
- 誰がいつ何を変更したかを容易に参照できる、監視できる、ロールバックもできる
cfengine との比較
抽象化の度合いが高い
- cfeingine は面倒見れるパッケージ管理システムが少なかったり、結局複雑な設定ファイルに加えて自前の sh を書くはめになりがち
- 設定ごとの依存関係を表現できない/貧弱なので、「正しい手順」を維持するコストが高い
- メールサーバは DNS サーバがないと動かない
継承できる/強力
- puppet の site.pp などに書いた内容は再利用性が高い
- DRY だということ
拡張性
- file とか exec とかいろいろあるけど他にも自分でやりたいことを定義できる、柔軟さがある
依存の解決、処理
- httpd.conf を変更したら apache も再起動して欲しい
- もちろん、自動で
- そういうことがあらゆるサービス、ファイル、パッケージ間で定義できる
LDAP サポート
これはまあ、そういうものらしい
Puppet の動き
- 基本は pull 型
- puppetmasterd という中央のデーモンがいて、 puppetd というクライアントが各ノードにいる
- クライアントが定期的にサーバに変更を問い合わせて引っ張ってきて適応する
- push というのもできて、 LDAP サポートがあると push のときノードをグルーピングできる強みがある
- push はサーバがクライアントに向けて更新を投げつける
site.pp について
- webserver.pp など、細かく分けていくと管理が容易になる
puppet:// スキーム
- puppet 自身がファイルをやりとりできる
- NFS サーバから各種設定ファイルの実体をコピーしてくる、などもできる
notify/subscribe
- notify
- 自分に変更があれば対象の resource に対してその旨通知しアクションを起こさせる
- subscribe
- 自分以外の resource を監視し、変更があれば依存している自分自身に対してアクションを起こす
- type によって notify 受け取り時の動作が決まる
- service なら restart
セキュリティという視点から
- 仮に侵入されたら?
- OS 再インストールが基本
- でも、以前の状態に戻せるかどうか? (以前と同じじゃまた侵入されるだろって話はおいといて)
- 再インストール後の品質が均一で抜けがないようにできる
- 新規インストールでも。以後常に同一品質の環境構築ができる保証が得られる
監視、監査、ログ
- 誰がいつ何を変更したかを追うのが容易 (バージョン管理システムの配下にあるから)
- diff, log
- ML, IRC, RSS
- 現実と剥離した手順書は不要になる
- puppet はまさに手順書にそって自動で動くものだから
結論
- この手の作業は自動化しないとダメ。ミスが減り、品質が均一になり、セキュリティも向上する。
- シェルスクリプトは管理者ならばかけなければならない
- が、できるだけかかないようにしたほうがよい
- 壊れた車輪の再発明
- 作業者のスキルに依存した属人的な仕事
- ポータビリティ
