基調講演
さくらインターネット小笠原氏
Wantedly の文化を支えるインフラとビジネスの変化に強いインフラ
2014/8/9 Heroku→AWS
Docker in Production
方針
Code Wins Argumentsを可能
変化に強いインフラ = 変化を前提としたインフラ
→自動化+ツール
developerがtool/APIを通してデプロイができる環境となる
何をしたか
・capistrano
Rails製アプリケーション自動デプロイ
→Herokuと同等な振る舞いへカスタマイズ（cupコマンド）
http://qiita.com/Salinger/items/4ee4f3c5ebd5227196c0
・Docker / Chef / Packer
Packer
マシン・イメージの自動生成・管理
https://thinkit.co.jp/story/2015/04/13/5875
Chef
インフラ構築
→アプリケーションの構築が自動化
but chef/packerのメンテはインフラチームになる
→Dockerでの利用になった。
・二段階ビルド/blue-green deployment
二段階ビルド
→ビルドサーバで再ビルド・Dockerレジストリへ・本番Dockerへ・ヘルスチェック・デプロイ終了
・terraform
Pull Request→merge request accepted → deploy
の流れを自動化
・CoreOS
これまではubuntuを使用していた。
→Docker自体のversion upが大変
CoreOSはコンテナベース、すでにamiが用意されている
http://qiita.com/mopemope/items/fa9424b094aae3eac580
・sap / Deploy Server
デプロイ方法の見直し
・cell
AWS TAG
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/Using_Tags.html
AutoScalingGroup(ASG)
https://docs.aws.amazon.com/ja_jp/AutoScaling/latest/DeveloperGuide/GettingStartedTutorial.html
自動拡張・縮小
・Monolithic Architecture
コードの肥大化・ミドルウェア／ライブラリの依存関係
問題：作業量の増大
→クラスタリング
Applicationを動かせるインフラをすぐに作ってくれと言われた時に作れる
◯kubernotes
Google製のオープンソース：Dockerコンテナ管理
http://www.publickey1.jp/blog/14/dockerkubernetes_kubernetes20_paas_1.html
・Kong Architecture
https://getkong.org/