前回「ちょっと自動化でも図ってみようかしらん」などと、軽い気持ちでpuppetやchefを調べ始めたのだが、どうも自分には合わなそうだ、ということがわかってきた。そもそも、最初に対象ホストにログインしてインストールが必要、という仕様が自己矛盾していて気に食わない。記述の例を見ても、抽象化レベルが高く、汎用性が高そうな反面、あまりクドいことはできなさそうにみえる。わけで、自分なりにサーバ設定の自動化機構を作り始めたところ、それなりに楽しくなってきてしまい、結果、かなり納得の行くものができてしまった。その名も「kugutsu」。直感的に設定が記述できて、我ながら大いに気に入っている。実際、Fedora23のインストール後、ワンショットでpackstack実行直前までのお膳立てするスクリプトを書いたが、非常に便利だ。OSのインストール完了後、対象ホストにログインする必要すらなく、外部ホストから設定を完結してしまえるのがいい。ひととおり動くようになったところで、大トラップ。先日に導入を回避したhiera-3がupdateリポジトリに入ってきてしまっているではないか。updateリポジトリを外したところ、packstackが頓挫するようになってしまった。おいおい、packstackさん、モグラ叩き大会やってんじゃねーんだぞ。結局、updateリポジトリを無効化して、hieraを導入後、updateリポジトリを再度有効化する、というワケのわからない手順が必要になった。なんだ、この針の穴を通すようなインストール手順は。普通の人がこんな状況に遭遇したら、アッサリとあきらめざるを得ないじゃねーか、マジかよ......と思ったら、今度はpackstack側に修正が加わり、新しいhieraでも動くようになったようだ......って、もういいや、そのままで。開発物件一式を置いておく。んが、上記のような状況なんで、いつまでもこの導入手順が有効とは限らない、ってことだな。)......こんな実行結果を得られるというシロモノだ。+0900].しかし、今回の開発の主な動機は「packstack実行直前までのお膳立てをラクしたい」だったのだが、これってむしろ、openstackのインスタンス起動後の初期設定にこそ、真価を発揮するんじゃないだろうか。インスタンスの起動そのものを自動化してしまうことにも使うべきかもしれない。一回、最初からインストールしてみるかな......って、いつしかインストール自体が目的になってしまってるような......。1.8.7-p357。