今（昨？）天在公司跟同仁分享的經驗，簡單筆記一下：
- Elastic Beanstalk 自訂的彈性與便利性，都比不上 OpsWorks。
- 公司在 Web 的主要使用語言是 Ruby：
- OpsWorks = AWS + Chef
- Chef 是用 Ruby 來管理 infrastructure
- 所以相對來說，入門門檻相對較低
- 理想上，應該可以跟 Vagrant 用同一套 Chef Cookbook(s)，達成跨方案快速部署開發與營運環境
- OpsWorks 每個 Stack 內只允許有一個 Rails App layer
- 如果覺得在 custom layer 照抄 AWS 的 Rails App layer 套用的 recipes，就可以解決這個限制，你就會踩雷踩到想哭。
- 如果為了要使用內建的 Rails App layer 而拆分到不同 stacks，又顯得太蠢，且無法佔到「放在同一個 stack 時可共用很多管理資料」的便宜。
- 目前（我）已知最好的方法，就是架 Docker
- 利用 Docker 的隔間特性，以 KTV 包廂為例，理想上 (container) A 房間開趴，不會影響到 (container) B 房間，更不會影響到大廳 (host)。
- 所以我們甚至可以一台 EC2 instance 裡部署 A 應用，如果資源有餘裕，就可以堆 B 應用、C 應用、D 應用…而不互相打架，且不會被 OpsWorks 一堆未知的地雷炸到。
- 實務上我會這樣堆疊：debian:stable → rvm-ruby-base → rails-base → app-base → app。
- rvm-ruby-base 就是先在裡頭裝好 RVM 以及 Ruby。
- rails-base 是預先裝 Rails 會用到的 Debian packages 如 NodeJS (XD)
- app-base 預先 git clone 把 application 的 code 拉下來，先跑 bundle install，這樣預先裝好一堆落落長的 gems 後，往後疊 app 上去就不用把時間耗在重新安裝。
- app 則是做 git pull，把異動拉下來後認 branch/tag 部署。這個放在 deploy 類的 recipes 底下，上面那些則是擺在 setup 類底下。
- 好處：
- 我們基於 Rails 的產品很多，用 AWS 也用很大，所以每個產品理想上都可以用同一套 cookbook(s) 做部署基礎，只需在 deploy 這邊自訂個別需求就好。
- 就算不用 Rails，還是可以在 rvm-ruby-base 上疊其他的 Ruby 應用。
- 好，就算不用 Ruby，你還是可以在 debian:stable 上堆其他應用。
- 因為用了 OpsWorks & Chef，我們可以用 template 動態產生 Dockerfile 以及設定檔，可以當成「超彈性隨你玩加強版 ECS (EC2 Container Service)」來用。
- 先決條件：
- 規劃良好的 VPC subnets, security groups
- 看 AWS 官方的 cookbooks 怎麼寫，模仿，並瞭解 node 物件有哪些東西可以方便我們部署
- 考量日後發展，彈性劃分 Docker 堆疊
