2015-05-18
_ Puppetの活用レベルの高い低いの議論から、インフラ自動化の成熟度モデルを妄想した
半年くらい前、Puppetの活用ノウハウをまとめたドキュメントの中身を議論する機会がありました。 以前からの書き方から、コミュニティでの動向を取り入れて、Hiera(過去記事: Puppet3.0の新機能Hiera auto-lookupの使い方)や、Role-Profileモデル(参考: http://www.craigdunn.org/2012/05/239/)の説明を入れたいね、 と話していると、「あなたの部署ならHieraが使いこなせるだろうが、他の部署やグループ会社だと使いこなせないから、説明に入れないほうが良いのでは」ということを言われて、そんな保守的に考えなくても良いのでは、Hieraは柔軟性も保守性もあがるので使って損はないのに、と思ったことがありました。
ただ、確かにRole-Profileは使いどころが難しくて使ったことがないのも事実です。 Puppet活用度の高い低いって一体何が違うのだろう、使う側のレベルにあった使い方はなにか、 を考えてみるきっかけになりました。
自分を振り返ってみると、こんな流れで発展してきています。
- Hadoop等で大量のサーバの同じ構築をする時にピンポイントでKicstart,Puppetで自動化(効率化)
- 一度に大量でなくても、開発環境をA面、B面、C面、D面……と複数回適用できると案外台数が多い(使いまわし)
- 事前にKickstart,Puppetマニフェストを作っておいて何度も何度もインストール検証をして確かめておき、サーバ調達ができたら安心して構築(品質向上、作業のコード化でモビリティ出す)
- オープンソースではない商用ミドルも含めて、Puppetを使って当たり前の状態
確かに、だんだんと進化していますねぇ。 きっかけは台数が多いことへの対処でしたが、 時間の効率化より、全サーバ・全環境で同じ変更ができることによる品質確保、コード化することでの持ち運び可能になることなどが効果として強くなってきています。
Puppet活用の成熟度モデルの妄想
そこで思いついたのは、CMMIの成熟度モデルでした。 最初は、単純に「5段のレベル分け」というところだけまねて、Puppetの使い方の進化を書いてみました。
当初の案:
- ０．「手順書なく作業している」
~~~~~~~~~~~~~~~~~~~~~~ 手順化の壁 - １．「手順書で作業している」
~~~~~~~~~~~~~~~~~~~~~~ Puppet導入の壁 - ２．「Puppetを小規模で利用している」
Node定義、Module定義の組み合わせ
~~~~~~~~~~~~~~~~~~~~~~ Hiera導入の壁 - ３．「Puppetを大規模、維持管理で利用している」
Hieraでパラメタを管理、全台共通のパラメタと個別ノードのパラメタが区別して管理する
~~~~~~~~~~~~~~~~~~~~~~ Module再利用の壁 - ４．「Puppet Moduleを流通、再利用している」
Moduleのリポジトリ管理、PuppetマニフェストのUnit testを実施
~~~~~~~~~~~~~~~~~~~~~~ 構成情報DB導入の壁 - ５．「Puppetを直観に合う最適な粒度で管理している」
Role-Profileモデルで構成、ソフトウェアスタック図と1対1対応する
(サーバ種別=Role、ソフト=Profile)
これに対する意見:。
- Puppetに異存せず、ChefやAnsibleなど他のツールにも適用できるように、ツールに依存した記述はしないほうが良い
- CMMIは汎用性が高いので、CMMIのレベルの定義に合う形で記述したほうが良い(これはいわれたのではなく、改めて見たときの自分の意見)
いずれももっともな気がするので、考えて行きたいです。
[ツッコミを入れる]