テストするだけなのにどういう道のりだったのか。
沙耶です。

さて、そもそもChefとか何言ってんの？とか言われそう、というかすでに誰も読んでないだろここｗ


とりあえず僕のボケボケとした理解状況ですが。

サーバ、だけじゃないけど、システムのセットアップってみなさんめんどくさくないですか。
まあ、めんどくさくないひとはいいです回れ右してください。

あなたの目の前にPCが100台並んでて、20台が営業部で使うんでOfficeとVisio入れてください、18台は開発で使うんで開発環境をそれに加えて入れてください、25台は総務で使うので、Officeと大蔵大臣と入れてください。27台はバイトさんが使うのでOffice要りません、メーラーも要りません。10台は予備機ですので、それらのどれにでもなれるように共通アプリだけ入れてください。

ソフトウェアは以上です。PCにはActiveDirectoryの設定を入れて、ブラウザには以下のアドレスをブックマークして…etc.etc.

これを全部手作業でやっていくのはくそめんどくさい。
まあWindowsなら別にいいんですけどね。そのためのディレクトリサービスとリモートインストールの仕組みと、プロファイルの配布やmsiファイルのリモートインストールとかありますし。

さて、じゃあ同じことが実はサーバにもあるわけです。しかもさらにめんどくさいことに全部OSがばらばだったりします。それらを横断的に、まったく同じ挙動を示すように設定を入れていかねばならない、というのはよくある話です。

OSごと違ったりするので、アプリケーションの入れ方だの入れるディレクトリだの、設定ファイルの置き場所だの起動方法だのまで違うわけです。持ってるライブラリが異なればアプリケーションの同じバージョンが入りません、なんて普通の話です。
で、まあそういったものを指定されたものでくみ上げてく、ってのがインフラ屋さんのお仕事ってわけです。もちろんそれに付随して、というかこっちもメインなんだけど、ネットワークをどう組むかとか、それぞれのサーバのネットワークには何番のIP振ってどういう風に接続させるかとかそういうことも含めて全部、って話になるわけです。

まあ従来的にはそういうのはちまちま作って文書に残す。ってのが基本です。なんでドキュメントさえあれば同じ環境を再作成することはできるんですが、問題はハードウェアの同じものが調達できなかったりすると、ふるいOSを入れてもドライバがないだとかでドキュメントどおりにいかないことなんていくらでも発生するんですね。
そういうことを避けるために、大量の在庫でCloneつくりまくって、とかいう手法もありますし、仮想サーバ立ててそこに構築済みイメージをぶち込む、という素敵な手法もございます。

というか今後は基本イメージぶち込めばそれでいいはずなんですけど！けど！ｗ

さて、じゃあChefって何ぞやっていうと、この中間部分の差異を、ドキュメントではなくコード化してしまおう、というアプローチになります。
そして、僕はもともと管理台数も少ないので、Chefのようなものを大掛かりに使って体系的にやらんでも、Perlでがりごりコード書いておいて、それ実行すればどうにかなるように仕込んでました＞前職

ミニマムな感じではインフラasコードを手書きでやってたわけですが、いかんせん複数条件が発生するとコードにどんどん汎用性を持たせていかなくてはならず、コードのアップデートと改変に追われることになり、それは本来の仕事じゃないだろう、という本末転倒に陥ります。

ぼくはインフラ屋さんであってプログラマではない。というのが首をもたげてきますね。そこで、そのコードをフレームワークとして共通汎用部分を外部化し、設定値だけ埋め込んでいけばいい枠組み、というのがChefだのpuppetだのといった話です。いまだとAnsibleもか。

VagrantやDockerがこういった話にまぎれて現れるのは、それらとの組み合わせが非常に強力に働く側面を持っているからです。
VagrantとかDockerって何だよって話までやるとアホのように風呂敷が広がってくのでここでは割愛。

要するに、このChefってやつには「～～のサーバ向け設計手順書」をコード化して記録するための枠組みです。

そこには１．Apache入れて　２．設定ファイルを適切なとこにおいて　３．その中身をサーバごとで変わる部分を変数化して書き換えて

みたいな流れが記録されており、実際にじゃあ入れる手順は？っていうのがまた別に記録されています。もっとも、この手順部分って大半がだいたいみんなやりたいこと似通っているので、自分でも作れたりはしますが、だいたい誰が作っても同じようなものが出来上がります。

この実際の手順、をレシピ、といいます。

そして、サーバごとの、何をどうすればいいのか、の設計手順がクックブック、レシピの集合体。

要するに、和食のレシピもある、洋食のレシピもある、中華のレシピもある、レシピの塊の中から、「今日の晩御飯」を作るクックブックとして、「白米」「味噌汁」「チキンステーキ」「サラダ」というクックブックを作っておけば、今後そのクックブックを実行すれば同じご飯が提供できる。
というもの。ご飯のレシピと今日のメニューを決めておけば、後はChefさんに「そーれ実行しとけー」ってやったら実行してサーバを作ってくれる、というお話。

同じように、「ビフテキ」「パン」「サラダ」「コーンクリームスープ」「チーズケーキ」のクックブックを用意しておけば、そのご飯を作ってくれます。

大事なのは、このChefさん、実際に作成するときにそこがどんなキッチンであるか、を問いません。というかまああらかじめ作っておくんですけど。
つまり、～～環境だったらビフテキ作るときはこういう手順。～～の環境だったらこういう手順ですよって環境ごとに作り方書いとくわけ。

なにそれ面倒になってるだけジャン、って？
そうだよ。汎用化するってのは手間を増やすんだよ。でも、その後が変わる。

レシピを作れる人は一人いればいい。あとの人は何も考えないで、Chefに今日はビフテキが食いたいわーって言うだけ。その裏周りを整備するのがインフラ屋さんのお仕事。
だって、そうでしょ？　ビフテキを食べたい人がビフテキの作りかた（それもキッチン別で！）を知ってなきゃいけない、なんておかしいでしょう？
だって食べたいだけなんだもの。作りたいわけじゃない。

そういうとこが基本の根底にあります。

もっとも正直、仮想環境とそれなりに膨大なストレージがあるなら仮想ホストのイメージをパターン別に持つほうが楽じゃね？とか沙耶はおもったり思わなかったりします。メリットデメリットありますけどねｗ
さらにいえば、その仮想環境へのイメージの投入も「手順」なんだからコード化できる。

つまりはそういうことです。「やり方」を「言語化」して「記録」可能なのであれば、そのすべてはなんらかの形態での「コード」として共通言語下で統一的に管理コントロール可能ですよね。という考え。

このあたりのテクニックってのは結構古い話で別にいまさらどうこうって話でもないし、むかーしからやってる人はわりと自前作成のプロビジョニングのコードなんてひとつや二つ書いたことがあるんじゃないかなあ、と思います。
そのコードのアップデートと改変を生きがいにして商売にするかどうかっていうと別の話ですがねｗｗｗｗ　ぼくはめんどくさいからあんまやりたくないので楽をしたいんですけどねｗ

つまり、会社において新人教育、として「新人教育マニュアル」があって、そのやり方を言語化して去年の担当から今年の担当に「引き継げる」ならば、引き継ぐべき相手は誰であれ可能である。
そしてそのマニュアルを作る人は一人いればいいよね。

そして、部署ごとに異なる新人教育の要素部分を可変として、変数化して記述する。そうすることでこの枠組みはどんな部署であれ対応できるマニュアルとなる。

そういうものを使うと幸せになれるんじゃね？ってのが根底の考え方ですね。
それを拡張し、日常業務なんかも「言語化して」「引き継げるもの」ですから、これらもそういう形に落とし込んでいける。
そうすると、あとに残るのは独創性を求められる部分だけ。

つまり、この”マニュアルを作り出す”ことが仕事である。と定義されるわけです。

さてさて。次は操作を記録してレシピに書き起こすキーロガーとか生まれないかなｗ