Puppet導入前に知っていればよかったなと思うことです。
導入検討されている方に役立つかわかりませんが、ノウハウというよりは考え方をまとめました。
構成管理ツール ≠ 自動構築ツール
一言でPuppetを紹介する場合、Puppetはサーバの自動構築ツールです。
なのですが、自動構築ツールなイメージでPuppetを使うと、まわりくどさを感じることもあります。
構築時に１回だけ実行するだけであれば、単純にシェル書いた方が楽な場合あります。
もっと正確な紹介だと、Puppetはサーバの構成管理ツールです。
なのですが、構成管理って一言で説明しにくい。しばらくPuppetを使ってみてですが、
構成管理ツール = テスト + 修繕
な、イメージかなと。もう少し具体的には、
- サーバのあるべき状態の定義を書いておく
- 定義にあっているかテストされる
- 定義とあっていなければ修繕する
です。なのでPuppetの作業負担感としては、構築自動化、単体テスト自動化を合わせたぐらいだと思った方がよいです。もちろん別途テストは必要ですが、手順書ベースの構築後のテストに比べてテスト項目は減らせるかなと。
何も設定してないサーバに対して適用するとあるべき状態に修繕されるので、結果的に自動的に構築されると見ることもできます。
なんで構成管理ツール使うの？
その答えは、なんでGit使うの？に似ているかなと思います。
ちょっと面倒だけど、なれるとトータルでは品質は良くなるからと。
使っていない人に、メリットを説明する難しいのも似ています。
状態を定義するのは面倒だけど、状態チェックを含むから設定漏れが減ります。あと、同じ設定を横並び的に反映するのは得意です。デバック環境、ステージング環境、プロダクション環境、同じにすべき設定が同じであれば、意図しないインフラ差異での不具合を減らせます。
あと、
サーバのあるべき状態をコード化できる
→ GitやSubversionで成果物管理できる（あとで変更内容を追える）
反映結果にべき等性がある（1回行っても複数回行っても結果が同じ）
→ インフラCI的なこともできる
なので、単純に構築自動化というメリットだけでなく、品質管理やテスト自動化がやりやすくなります。
どういう場合に向いているの？
次の場合に向いているかと。
- システム構成が１サーバ１機能
- インフラリリースのルールが明確
です。逆に、１サーバが多機能だったり、インフラリリースが不定期（頻度が高かったり、後からきた要件を先行反映しないといけない）だったりする場合は、できなくはないですがそれなりに苦労します。
また、一度構築したサーバは基本触らない的な運用であれば、Puppetは冗長かもしれません。その場合は、シェルとかFabricとかAnsibleとか、もっと自動構築に特化したものも検討しましょう。
各サーバにエージェントをインストールするの？
Puppetだと管理対象のサーバに、エージェント役のpuppetのインストールが必要です。内製システムであれば各サーバにエージェント入れるのは比較的容易ですが、SI案件だとそこが一番ハードル高いかと思います。
現状だと各サーバにエージェントのインストール不要な構成管理ツールもあるので、構成管理の手始めとしてはそっちを使うのもありです。AnsibleとかItamaeとかです。
個人的に同規模のシステムで各ツールを使っていないので、Puppetとは違う苦労もある可能性もあります。他ツールの経験浅いのでどういう場合かは比較できないですが、案件によってAnsibleが向いていたり、Puppetが向いていたりする場合があるのかなと思います。
残念なことに、現状エージェントを入れないとできないようなメリットはあまり感じないです。もしかしたら大規模システムであれば、エージェントが入っている方が負荷が分散されてよいかもしれないですが。。。あとは、定義の書きやすさですが、これは個人の好みによります。
Agent/MasterとPuppet Applyどっちがいいの？
Puppetにはスタンドアローンで反映するApplyと、Master側でコンパイルした定義をAgentに反映する２タイプあります。
数台であればスタンドアローンのPuppet Applyの方が、導入準備が少ないので良いかと思います。
台数が多い場合（明確に何台くらいかは難しいです）は、Agent/Masterの方が推奨されています。
意訳ですが、参考までに。
- Master/Agent構成だと、Agent側には関係する部分だけ渡されるので、各サーバの負荷は少ないです。Applyだと各ノードで全定義を読むので負荷高いです。
- Master/Agent構成だと、Puppet実行時のレポート情報がMaster側に集まります。
- Master/Agent構成だと、Master上の定義だけ更新すればよいので楽です。
- Master/Agent構成だと、Agent側でコンパイルされないので、Agent側でpuppet用に必要なリソースは少なくすみます。
- Master/Agent構成であれば、Puppet masterには速いプロセッサ、多めのRAM、速いディスクをつけましょう。
- Master/Agent構成の場合、Master/Agentの通信があるためネットワーク帯域に余裕がない場合は見直してください。
- Master/Agent構成の場合、HTTPSを使ったセキュアな通信と、SSLでの認証を行っています。
マスター側で必要なリソースは、下記参照
- 少なくとも2プロセッサ、1GB RAM。
- 1000ノードの場合、2-4プロセッサ、少なくとも4GB RAM.
ただ、反映頻度やpuppetマニフェストの規模に依存するので、あくまでも目安なので、気持ち多めに積んだ方がよいです。
なお、台数が多い場合でもApplyの方が良い場合もありそうです。いろいろ情報見ていると、マニフェストをGitで管理して、各ノードにはマニフェストをclone(pull)してapplyする運用もあるようです。たぶんですが各サーバごとに設定をこまめに変更する運用の場合はGit+applyが良いかもしれません。
- 一部のサーバだけ古い（安定した）設定（リビジョン）で残しておくとか
- 一部のサーバ用の特別設定はブランチ切って特別に反映するとか