参加してきました。
Recruit Technologies Open Lab #03 テーマ:Infrastructure as Code : ATND
Infrastructure as Code by Naoya Ito さん
入門Chefを書いたnaoyaさんによるInfrastucture as Codeの歴史や概要の話。
- puppet, chef, AWS東京リージョンの開設などインフラ構築コード化が推進される要因が続いた
- pull requestでインフラの変更を出し、マージされたら本番に提供される、ということが行われている
- ソフトウェアの開発プラクティスがインフラにも適用された
- 構築手順をコード化するのではなく、インフラをモデリングする方向になっていくべきでは、と考えているがそういう方向にはなっていない
Chef vs Ansibleはどうでもよくて、システムの特性にあった方を使えば良いという考え方は参考にしようと思いました。
Infrastructure as Codeと企業文化 by @ryuzee さん
Infrastructure as Code を適用する前に組織構造の改革が必要、という話でした。 開発とインフラ部門がわかれている組織ではそもそもInfrastructure as Codeを適用しても非効率的で、製品単位で組織を作りそこにアプリケーションエンジニアもインフラエンジニアも居る組織である、というのが重要という話ですね。かつ、そこに認証やセキュリティ、UI標準化などを管理する組織があれば理想的ということです。
Infrastructure as Code のこれまでとこれから by mizzyさん
serverspecを創ったmizzyさんによるInfrastructure as Codeについての歴史とこれからどうなっていくか、という話。
オライリーの Infrastructure as Code がおすすめされていたので読んでみようと思います。
Infrastructure As Code: Managing Servers in the Cloud
- 作者: Kief Morris
- 出版社/メーカー: Oreilly & Associates Inc
- 発売日: 2016/06/27
- メディア: ペーパーバック
- この商品を含むブログを見る
インフラのツールやサービスとして分類が以下の4つにわかれている話が勉強になりました。
- Dynamic Infrastructure Platforms (IaaSやForemanなど)
- Infrastructure Definition Tools (TeraformやConsulなど)
- Server Configuration Tools (Puppet, Chefなど)
- Infrastructure Tools (モニタリング、サービスディスカバリ)
これからの話として、Containerが流行っていくとServer Configuration Toolsの重要性が減っていくという話はなるほどなぁと思いました。
運用・監視もコード化する。開発者が監視まで考える方法論 by Songmuさん
http://songmu.github.io/slides/recruit-technologies-open-lab-3/#0
MeckerelのディレクターであるSongmuさんによる監視の話。 オライリーのマイクロサービスアーキテクチャに書いてある、すべてのサービスでモニタリング/ログを共通化するべきという話が参考になりました。
- 作者: Sam Newman,佐藤直生,木下哲也
- 出版社/メーカー: オライリージャパン
- 発売日: 2016/02/26
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
プロビジョニングツールはMakeで決まりだろ by @katzchang
ネタっぽいタイトルですが、いい内容でした。 ChefやAnsibleで途中から要らなくなったツールに対してその行だけ消したりするとあるサーバにはそのツールが入っていて、別のサーバにはそのツールが入らないとなって冪等性の担保ができない問題の話など。
クラウドサーバ全盛期なので、「複雑なサーバをどう管理するかから、単純なサーバをどう組み合わせるか」という時代になっているという話がとても良かったです。