Infrastructure as Code [2016/07/07 Thu.]を聴いてきた話
Recruit Technologies Open Lab #03 テーマ：Infrastructure as Codeに参加して来ました。
自分にとってのDevOpsやInfrastructure as Codeは3年前くらいから始まっていて、
特に「はじめるDevOps」、
「JTF2013」への参加が印象に強いので、
Naoyaさん、ryuzeeさん、mizzyさんといったスピーカー陣・時期・内容からいっても
まさに振り返りのつもりで参加しました。
主催のmizzyさんも振り返りと言ってらした気がする。
資料
Naoya Itoさん 「Infrastructure as Code」
ryuzeeさん 「Infrastructure as Codeと企業文化」
mizzyさん 「Infrastructure as Code のこれまでとこれから」
songmuさん 「運用・監視もコード化する。開発者が監視まで考える方法論」
katchangさん 「プロビジョニングツールはMakeで決まりだろ」
感想とか
NaoyaさんによるInfrastructure as Codeの歴史から。
初めは自動化から始まって徐々にコードのバージョン管理・ビルド再現性・テストと
アプリケーションと同じ流れで来てると。
それもサーバプロビジョニングだけでなくクラウドインフラ全体に対して。
Naoyaさん的にはこのままモデリングも・・・と思ったがイマイチ来てないとか。
自分もここ1年で書いたAnsibleが組織的には負債になってしまっているので
よい方法があったら知りたいが、ryuzeeさんの組織論にもヒントがありそうだった。
Dockerが来たことで違うStepに来てるのかなという気もする。
プロビジョニング層の複雑さを違う形で解決できそう。
この辺はkatchangさんの話にもつながる。
ryuzeeさんの組織論。
DevOps云々の前に組織文化大事ですよ。
バージョン管理やテストもしてないのでDevOpsどころじゃないよと。
大きく組織構造3パターン
- 開発部門とインフラ部門が独立、サービスに紐づかない
- 部門はそのままだがサービス毎にチームを組む
- サービスでワンチーム
基本的には1->2->3となるにつれ変化に強くなる半面、
サービス毎に品質のバラつき等の問題もおこりうる。
チャレンジする場合は小さく初めて必ず成功させようとのこと。
自分もインフラ担当1人なのに無理して1のパターンぽくなってボトルネックになってしまったので、
どういう感じに動くと3のパターンになれるのかというのは気になるところ。
組織文化・・・
mizzyさん
手法や分類を非常に丁寧に説明されていたので資料参照。
今後でいうとコンテナの影響によりプロビジョニング部分のツールの重要性は相対的に低下して
サーバ管理というよりはプロセス管理になっていくと。
マイクロサービス化によりテストやモニタリングが重要に。
自立制御のような仕組みが重要になっていくのでは。動的平衡
Serverspec以降の(テスト界隈の？)進展がないと仰ってて実際その辺は気になりました。
元々はリファクタのために作成されたはずですが、
インフラのモデリングが進まないのも一旦なのか、
それとToolもまだ少ない(Terraform一択)ですよね、という話をされてて割と同感。
さわのぼりさんのpodcast聴かなくちゃ。
songmuさん
監視やログは標準化した方が良いby「マイクロサービスアーキテクチャ」
やっていくしかない
監視は継続的なテスト（先にやるか後にやるか）
欲しいapi生やしてモニタリングできる
アプリケーションエンジニアはコード書くの得意なので見たい項目を取ろう
見たい人が書いて改善してくの良いよなぁと思ってるけどどうやって推進すればいいのか難しい。
組織論の3のパターンだとこういうの進みそう。
Toolの説明してるように見えてチームの精神みたいなのも垣間見れる発表でした。
katchangさん
makeでプロビジョニングする。エラーも即中断して便利。
一般のプロビジョニングツールは宣言型アプローチ
実は冪等ではない（記述を削除しても反映されない）
ネタっぽい流れでありながらも考察は的確で
Dockerfileで実は一周回ってきた感あるし同感、みたいな話だった。
シンプルなのがいいよねっていう話なのかも。
そういえば誰かもイージーよりシンプルという話をしてた気がする・・・
まとめ
おっさん的振り返りとして参加したが学びも非常にあって良かった。
