_ Recruit Technologies Open Lab #03 テーマ：Infrastructure as Code に行ってきた。 #rtechlab

• Recruit Technologies Open Lab #03 テーマ：Infrastructure as Code: ATND

1ヶ月ぶりくらいに外の勉強会に参加した。 最近、またAnsibleでゴニョゴニョとレガシーなアプリケーションを牧畜するために、再現性のある環境構築をしている。 参加するまでは、「Infrastructure as Codeって、インフラをコードで書くってことっしょ？」というくらいの浅い知識でした。 ですが、単なるコード化だけではなく、その周辺への影響を知ることができた。

"Infrastructure as Code" から数年、結果どうなったか", @naoya_ito

伊藤さんと言えば、入門Chef Solo - Infrastructure as Code でChefとInfrastructure as Codeの普及を推した人として有名だ。自分もこれを読んで、Chefの勉強をして、色々環境構築をした。

伊藤さんの話で非常に面白かったのが、コード化の意義についてだった。 アプリケーションエンジニアがなぜコード化するのかと言えば、それは対象としているサービスのプロセスをモデリング化するためだ。それと同じことが、IaCでも必要なんじゃないかっていう話だった。

自分もAnsibleで書いていて、「結局これによって構築される環境の全体像みたいなものは何なのだろう」と疑問に思うことが多々ある。ドメイン駆動とかは参考になるのだろうけど、インフラって極力アプリケーションが意識しない方が嬉しくて、ブラックボックスになりそうなので、モデリングする対象がずれて来るんじゃないかなぁ、とか悶々と考えていた。これは悩ましい問題なんだろう。

"Infrastructure as Code と企業文化", @ryuzee

コンウェイの法則を元に、様々な組織の構造の中で誰がインフラのコードを書くか、そしてそれによってどのようなことが起きるのかという考察でした。 ポイントは、コミュニケーションのオーバーヘッドと責任範囲または分界点がどこなのかというところだと思いました。

やはり、1つのプロダクトに対して従事する多能工なチームが良さそう。しかしながら、チーム内で属人的な形に陥るおそれがあるので、

• スキルマップでスキルの冗長構成を保ちつつ、
• それぞれのチーム間での知識共有を行う といった対策が必要とのこと。

しかし、技術については現場での努力でなんとかなるところもありますが、IaCのように新しいものの導入は、変化に対する抵抗が生じるので、人間系の問題への泥臭い対応が生じる、とのことでした。

"Infrastructure as Code のこれまでとこれから ", @gosukenator

正直言って、あまり自分は理解に追いつけなかった。最新の動向とかこれから先のことを知るには良いのかも。

"プロビジョニングツールはMakeで決まりだろ", @katzchang

タイトルから、どんなネタをぶっこんでくるのだろうと思ってたのですが、まじめにmakeはデフォルトで安全に落ちるようにできてるし、DSLはなくshellで書けるので良さそう。