ops worksに今後期待するところ
TRANSCRIPT
自己紹介• 白山 文彦(しろやま ふみひこ)
• Twitter: @_aodai_
• Facebook: fumihiko.shiroyama
• 株式会社マナボ エンジニア
• Android, Rails, DevOps, 全文検索…何でもやりますが、本職のインフラではないので拙い発表になったら何卒ご容赦くださいm(_ _)m
OpsWorksのイケてるところ• VPCとの相性抜群
• ELB, RDSとの連携最高
• Monitoring
• Lifecycle Events
• User Permissions/IAM Roles
• And more…
• OpsWorksはAWSの色んな素晴らしいサービスに「横串」を通すようなサービス。
• アプリケーションサーバは private subnet に置き…自動的にELBにぶら下げ…RDSにつなぎ…負荷が上がったらスケールさせ…みたいなよくあるシナリオをひとまとめに。
• ユーザ管理は素晴らしすぎる。鍵の配布やインスタンスへのアカウント作成の自動化、ユーザごとの権限の調節など、実際の現場で使える機能が盛りだくさん!
• カスタムJSONに関して
• Railsレイヤーに関して
• デプロイに関して
• オートスケールに関して
• Chefに関して
• OpsWorks Agentに関して
OpsWorksに今後期待するところ
Custom JSON• レイヤーごとのカスタムJSONが欲しい
• 実行されているlayerを判定してテンプレートや処理を変えるrecipeが必要でツライ
• カスタムJSONの履歴管理が欲しい
• ウェブ入力フォームしかないので容易に事故る
• 失うと取り返しがつかないので別の場所でgit管理してコピペしているのが無駄…
• S3に置いておけるとアツイ?
Rails Layer• 同一スタックに複数ELB+Railsレイヤが欲しい
• API, Web, Admin, etc…コードベースが同じで複数のエンドポイントを持つことがよくある
• スタックを分けるとカスタムJSONの管理が煩雑
• assets:precompile遅すぎる問題
• 基本的にまっさらな環境を再度作りなおすという思想
• カスタムAMIを使っても高速化には限界がある
Deployment• デプロイのキャンセルが出来ない
• 15分以上かかることがザラなのでミスに気付いた時にすみやかにデプロイをキャンセルしたい
• デプロイのRevertが出来ない
• undeployはそういった用途ではない
• デプロイの開始・終了フックしたい
• Chefのデプロイフック(before_migrate, before_symlink, before_restart, after_restart)だけでは不十分なケースが多々…
Auto Scaling• Load Based Scalingが若干実用性を欠く
• 自動で新規インスタンスは作られないので予め我々が待機させておく必要あり
• EBS-backedなインスタンスはAuto Scalingで起動時にCookbookに変更があってもrecipeが実行されない!
• Cookbookに更新があったら待機させているインスタンスを作り直す必要がある…
Chef-solo/zero• OpsWorksに対応しているOSがAmazonLinux, Ubuntuの状況でChefお得意の冪等性の恩恵をフルに受けるケースが少ない。オーバースペック感ある。
• もともと知ってる人ならいざ知らず、OpsWorksのために覚えるとしたら学習コスト高め
• ローカルでテストするのがむずかしい
• AmazonLinuxはオープンソースではないのでVagrant等でローカルで完結するテスト環境つくりづらい
• IAM Roleの必要なrecipeはそもそもローカルでテストできない
• User-Data/cloud-initでいいのでは
• 2013年ごろ爆発的に流行ったが、もう旬を過ぎた感がある
• Dockerfile使いたい!(キャシュが余りにも強力)
仲間を募集しています!• iOSエンジニア
• Androidエンジニア
• インフラエンジニア
• http://mana.bo/corp/recruit/
• ご興味ありましたらご飯行きましょう!