Puppetに関しての日本語ドキュメント少ない、少なすぎる。
特に、再利用性の観点で遵守すべきファイルツリー構造や、Puppetの見通しを良くする主要技術であるHieraの使い方の情報が絶対的に不足しているので発信しておきたい。
なお、このページはコンセプト的な話しかしていないので上記の内容を期待する方はすみません。
本シリーズの目的
- Infrastructure as Code 概念の理解
- Puppet環境の準備
- Puppetの基本の理解その1 Resource,Ordering,Class,Define,Node
- Puppetの基本の理解その2 Module,File,Templates,Variable
- Puppetベストプラクティスの理解その1 ディレクトリ構成とその役割
- Puppetベストプラクティスの理解その2 多種多様なサーバの構成管理
- [Puppetベストプラクティスの理解その3 Hieraで世界が変わる?] (http://qiita.com/takeuchikzm/items/e04e6cbe84a185eb1f26)
本シリーズが目的としていないこと
-
Puppetの詳細アーキテクチャ/内部挙動についての解説
-
オーケストレーション、ブートストラッピングに関してのテクニック紹介
- MCollective, PuppetDB、等のPuppet
-
ChefやAnsible等の競合技術との詳細な比較
What's "Infrastructure as Code" ?
お堅い言い方をすると、
"インフラストラクチャー構成管理における構築・運用をプログラマブルにする"
するというコンセプト。意地悪な言い方をするとバズワード。
AWSやGoogle等がRestAPI等で簡単にサーバを立ち上げる技術を整備した事で敷居が非常に下がった。
インフラ構成管理における構築・運用となる技術要素をブレークダウンすると以下の3つのレイヤに大別できる。
-
ブートストラッピング
- 物理ハードウェア環境やクラウド環境上に、OSが動作しているサーバもしくはVMを用意するための技術。
- 物理ハードウェアでも、kickstart(http, tftp, dhcp)やIPMI等のソフトウェア技術と、
各ハードウェアベンダが提供する遠隔管理ボード(iMM, iDRAC, iLo等)を利用することで実現は可能。
-
コンフィグレーション
- OSインストール後のミドルウェアのインストールやファイル設定を等を行うための技術。
- Puppet、Chef、Ansible(ansible-playbook)等がもっとも得意とする構成管理部分。
-
オーケストレーション
- 複数のサーバを跨いだサービスの連携等を調整させながら操作するための技術。(ex. Web三層のWeb、AP、DBのサービスを順に起動するなど。)
- Capstriano, Fabric, MCollective, pssh, Ansible(ansible)等が得意とする部分。
参考: インフラ系技術の流れ
Why Infrastructure as Code ?
「いつまであるかもわからない新しい技術覚えるより、手で設定したり操作したほうが確実だよね。」
→ それサーバ1000台あっても言えんの？
→ なお、数台のマシンでも、コードとしてインフラ構成を記述しておくとレビュや構成変更のバージョン管理がしやすかったり、別のシステムにも流用できたりとインフラの品質向上に直結する。
「SSHとかを使ってシェルスクリプトで構成管理したら良いじゃない。」
→ シェルスクリプトはあくまで処理を実行するためのもの。
→ 構成管理をするためのPuppet/Chef/Ansibleは設計意図がわかりやすく、再利用性が高い。
→ システムを使っていく中で継続的に発生する変更要求も吸収しやすい。
Why Puppet ?
Puppetは、Puppetのいまいちな部分をうまく補完している後発のChefやAnsibleに比べると、
若干煩雑なエコシステムと感じる時はある。
しかし、Puppetの記述言語であるmanifestはシステムのあるべき姿を記述するという思想に忠実な設計となっている。
そのため、ある程度の技術レベルを持っている多数のメンバにmanifestを配布して利用してもらうような形態には向いていると感じる。
なお、上記の所感はもちろん本気ではあるが、私がPuppetを使い続ける最も大きな理由はPuppetを長い事使っているため既存の資産が大量にあるからというのが大きい。
まとめ
書いてみたがぜんぜんPuppet個別の話になってなかった。