chefを使ったインフラ構築をやって思うこと

仕事でインフラ構築全般に関わり出したので、思ったことをメモ。

一昔前なら、ネイティブアプリ開発、WEBアプリ開発、データ分析、インフラ構築を一人で全部やるとか絶対無理だったんだけど、今はなんとかなってしまうところが開発の世界の進化の速度の凄さを示している。
10年後の開発環境とか想像もできない。

今回はchefについて語ろうと思う。

このchef。
もうこのツールなしで開発はもう無理と思ってしまうくらい便利だ。
WEBアプリの開発ではもう完全に必須ツール。今話題のdockerも触ってみたけど、周辺ツールが貧弱すぎるので、しばらくはchefが中心だと思う。

ただchefは、学習の敷居が高いことでも有名だ。僕はrailsを使った開発でrspecをかなり昔からいじっているからあまり抵抗はなかったけど、確かにわかりにくい箇所は多かったように思う。

chefの勉強の仕方は色々あるが、基本は他の技術の勉強の仕方と同じでよい。

つまりはコードをとにかく書いて動かし、サンプルコード(chefの場合はopscodeがgood)を読んで真似て自分の書いたコードの質をあげていくのだ。 どうしても理解できなかったら、わからない部分の基礎まで遡って内容を理解していく。

あと大事なのは、「最初はopscodeを使わない」ことも重要。
最初は手を動かして「どうやって設定しているのか。どのように動いているのか。」を理解することが重要。何の技術でもそうだけど、根っこは押さえておく必要がある。 何かが起きた時に、全く中身はわからないは危険だ。
技術的負債を返すために、テストコードを書いてリファクタリングをするべきという意見があるがインフラも同じだ。 売掛金は資産だが、資本ではない。ここでいうopscodeは売掛金と同じだ。売掛金は回収できないことがある。opscode場合は、大きな負債になることもある。

あとはserverspecを導入することも大事。

railsで開発している人はテストを書く習慣がある人が多いけど、他の言語(特にp○p)の開発者はテストを書かない傾向がある。(僕の周りだけ？)
でも、テストって動作を確認するだけじゃなくて、コードを書く能力や設計の能力も向上させてくれるものだから、面倒くさがらずに書かないといけない。 工数は増えるけど、おつりどころか利子がついて返ってくる。長期にわたると複利効果も期待できる。 上司が認めてくれないから書かない、書けないのではなく、こっそり少しでもいいから書くべきだ。結局はみんなのためになるし、あなたのためにもなる。
テストコードを書くのは習慣だ。朝顔を洗ったり、メイクをするのと同じだ。

今後は小さなプロジェクトならネイティブアプリ、WEBアプリ(API,　管理画面), インフラ構築を一人の開発者が全部やってしまうのが普通になると思う。 実際、今の時点でもなんとかなってしまっている。もう少しデータ解析の技術が発展すれば、分析も一人の開発者でできてしまうと思う。
僕も機械学習の学習を始めたけど、まだちょっと敷居高いなあという印象。

いずれにせよ、面白い時代です。今後、どんな開発手法が発展し、サービスがうまれてくるのか楽しみです。

この記事がお役にたちましたらシェアをお願いします

Tweet