OpsWorks + Docker 管理架構

今(昨?)天在公司跟同仁分享的經驗,簡單筆記一下:

  • 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 堆疊

已發佈

分類:

作者:

標籤: