ChefとかPuppetとか・・・

ここまで開発環境を構築してきたんだけど、ここで少し疑問があったりする。

プログラミング言語の開発環境を作って、Vagrantも使えるようにしたし、あとは実際に運用するサーバとVagrantを同等にしてそれに合わせた言語環境にして開発だー、って思ってたんだけどちょっと躓いた。

本当は今流行りのChefとかPuppetとか使って本番サーバとVagrantの仕様を同じにしようと考えてた訳なんだけれども、今回初めて使うにあたっていろいろと調べてたんだが、ChefもPuppetも設定先サーバにクライアント（っぽいもの？）を入れなきゃいけないらしい。 現役から5年も離れてて、本来の現場からは疎遠になっている訳だけれども、それってどうなの？ってやっぱり思ってしまう。

SIの現場的な事をちょっと書くと、まずサーバ構築する時に基本設計・詳細設計とか作って、それに合わせて手順とか作って構築して、テストしてエビデンス取って納品、って流れなんだけれども、現代のSIではその流れの中にChefとかPuppetとかって組み込まれてるんだろか。

今のWeb開発とかは小規模な物が大半だし、開発者自身がサーバの設定から全て行う流れなのでDevOps的にいかにインフラ周りの作業を簡略化して開発に専念するかっていうのは判るし、実際自分が開発しててもそういう部分に手間かけるのは時間の無駄な気がする。だからこそSIではインフラ周りを専門でやる部隊がいて、そこがインストールとか設定とかの泥臭い部分をやっていたんだけれども・・・・。うーん、なんだろ。この違和感は・・・。

ChefとかPuppetの事を調べるまでは、Capistrano（使ったことないけど）とかを拡張した感じになってんだろなぁって思ってた。要するに古くはexpectからある流れで、リモートでやる作業をスクリプト化してローカルから自動でやらせるっていうような感じ。

そう、多分インフラやってた人間からするとパッケージインストールして設定ファイル変更するごとき作業の為にリモートに何か入れなきゃならないのが気持ち悪いんだと思う。

手作業でやるなら何も入れる必要が無いのに、それを自動でやるためにリモート側に何か入れるのが凄い気持ち悪い。と言うのも、SI的には設定しているサーバはお客様の物で、いくら自分たちがやる作業を簡略化させる為とは言え、そこに（お客様が求めている）本来の機能に必要のないものを入れて納品するって事にすごい違和感を感じてしまう。

まぁ小規模Web開発みたいに自己責任で運用する物であればこういうツールを使ってやった方が間違いも少ないしいいとは思うんだけど、いかんせんインフラ屋さん的思考だと拒否反応が出てしまう。

便利だと思うのに使うのに拒否感が出るのはどうしたもんだろなぁ・・・。