Puppet Advent Calendar 2015の19日目です。Tipsネタ切れのため、最後の手段アイディアまとめです。というより課題列挙かも？
**Puppetを使っていて定義と実際の設定が乖離したとき、**一方通行なコーディングだとつらいので、何かいい方法ないかなという話です。そんなこと考えなくても、こうすればいいよってあれば共有してほしいかなと。切実に。
ちょっと長いですが、Infrastructure as Readable Databaseはいかがですか？
Infrastructure as Readable Database?
個人的に思っている構成管理ツールのあるべき形の一つ、造語です。Infrastructure as Codeの派生で、サーバの定義を集めて管理、簡単に検索・抽出・編集ができて（データベースな感じで）、かつ、定義自体は人が読める状態（リーダブル）にするという理想です。
従来のInfrastructure as Codeだと、定義をコーディングして、サーバに反映する一方通行の流れだったのを、双方向的なルートを用意してデータベース的にしたいなというものです。例えば、既存サーバから定義化した設定を取得したり、既存定義から欲しい部分のみを選択して、編集して、更新するみたいなデータベースを操作するように定義があつかえたらなと。
Infrastructure as Readable Databaseにしたい背景
構成管理ツールのよくある問題の１つが、定義と実機で乖離がでたときにどうするかです。定義が常に正であれば苦労しないのですが、たまに実機が先行することがあったりします。そんなとき変更時に関係ない部分のコードはあまり見たくないので、設定に関わる部分だけ抽出してそこだけ変えて更新するデータベース的な操作がよいかなと。
次に、既存環境を構成管理するためにPuppet使いたいんだけどという時に、まずはコーディングから始めましょうは辛いのです。できればスナップショットを取るようなイメージで、まずは（簡易のコードでもよいので）既存環境から機械的に定義化して、そこから構成管理を進めるとかでもいいんじゃないかと。まずはデータベースに設定のバックアップをとってからみたいなイメージです。
モダンできれいな設計のシステムであれば、おそらくコーディングするという方針の方があっている気がしますが、従来設計でかつサーバ主導な運用をしていると、サーバの設定に合わせて定義を更新する作業が多々あります。正直、楽しくない作業なので、どうにかしたいのです。
方向性
定義はコードではなく、テキスト状のデータベースとして割り切って、平易な定義で書ける部分はある程度機械化する方向がよいかなと。平易な定義に落とし込むことによって、ツールで選択や加工もしやすくなるので。ただ、ツールを扱うためのツールなので、ちょっと微妙ですが...、サーバの設計（設定）が変わるたびにコーディングするのが辛いのです。Puppetに欲しい機能をいくつか足せば、それっぽいことが実現できそうなので、Puppet + 自作ツールで試してみます。
なぜPuppet?
いくつかある構成管理ツールの中で、スクリプトからの定義編集のしやすさ（Chefではなく）と、サーバの設定を機械的に定義化する場合エージェントレスじゃない（Ansibleでもない）のが向いていそうなのでPuppetです。あと、Hieraの説明が、
A simple pluggable Hierarchical Database.
だったり、puppet resorcesなどの機能があったりするのも理由です。Puppetの既存機能で、なんとなく部品となる機能はあって、それらをうまく繋げば、Infrastructure as Readable Databaseができそうかなと。
ツール作成（途中経過）
まだ途中なので、前の投稿を参考程度に。双方向で編集しやすくするには、いろいろ考えないと。。。
メリット・デメリット
アイディアの良し悪しを判断するには、最低限ちょっとしたサーバ構成でデモできるくらいの方がいいんですが、まだそこまでツールができていないので文章で。
メリット
1.既存環境を構成管理する場合の導入が楽かも。
普通であれば、最初にマニフェストのディレクトリ構成とか、Puppetの文法とか、コーディング規約とか色々考えないといけないけど、ツールが肩代わりしてくれるので最初はらくかも。
2.他システム構築時の流用がしやすいかも。
マニフェストから必要な部分を選択する機能があれば、必要な部分をとりだして流用するのがやりやすいかも。定義を作り込んで汎用的にして資産にするというよりは、必要な定義を細切れでとり出して、別システムのマニフェストを再構成するとか。積み木みたいなイメージ。
デメリット
1.こったマニフェストと相性が悪い
定義が平易でないと静的解析が難しいので、どうしてもこった定義が使えなくなる。例えば、Facterの値で反映するクラスやロールを変えるとかは対応できそうにない。便利なやり方でもあるので、この辺はもったいないかも。
2.マニフェストの変更前後のdiffが多くなる
定義を平易にしているので同じ内容の変更が複数箇所に出るはず。なので、変更差分のdiffが読みにくくなりそう。特にサーバ台数が多いと顕著。例えば、あるパラメータを数十台分変更したら、数十カ所変更差分がでるかなと。
3.exec（Puppet内でのコマンド実行）が難しい
そもそもどういうコマンドを実行されたかが、既存のサーバから取れない。やるとするなら人がマニフェストを書くしかない。あとexecの順序制御も。
見方を変えてみる
個人的にPuppetの得意なことは、
- 壊れた環境をなおす
- 同じ設定を複数台に反映する
で、サーバをマニフェストに従属させるような構成管理的な部分だと思っています。構成管理って以外と便利で、よくわからないけどなぜか動かなくなったとか、設定を色々変えたらなぜか動くようになったけどどの設定が影響したのはわからないってのが減らせます。なので、スナップショットをとるように手軽にマニフェストがつくれたり編集できた方が、より構成管理の使い道がひろがるかなと。理想では、１台から始める構成管理ってなるくらい手軽になればなと思って、ちょっと考えてみました。
あとがき
Advent Calendar、ネタ切れで自分は最後になりそうなので、まだ早いかもですが一言。
Puppet Advent Calendar 2015、刺激になる投稿もあっていろいろ勉強になりました。来年もPuppetの話題が尽きませんように。。。
残り6日。明日は@denkasさんです。