Cookbooks 的規劃
對應 OpsWorks 的任務分支，分為以下幾個 cookbooks：
- common
- setup
- configure
- deploy
-
shutdown
- service-pack
不要有類似 OpsWorks 的 nginx 或 rails 這類獨樹一格的「專用」、「特用」cookbook，依以上基於動詞的 cookbook 來做事。
比如如果遇到要設定 nginx 某個獨特的項目，就是 setup::nginx_do_something 或 configure::nginx_do_something，而不要自己搞一個 nginx::do_something。
這樣做的好處就是管理起來簡單，一眼望過去知道這個 recipe「要做什麼事、對象是誰」，寫 recipe 時有明確分類可以遵循。
其中有幾點要注意：
- common cookbook 是用在「支援、配合任一其他類 cookbook」的地方，而不是「萬用類」。開發初期如果不曉得某任務應該歸在哪類，可「暫時」放在這裡，一旦確定放在某特定類比較適當後，則應立即 refactoring 改放到該特定類。
- service-pack cookbook 適合用在「單次任務」如元件安全更新、強制不使用 cache 重建 Docker images 的地方。
- 因為 Docker 的特性，基本上不需要 undeploy 類的任務，退版其實就是切回到某個舊版本的 Docker image 開 container 出來而已。所以不規劃 undeploy cookbook。
Docker 的部署設計
理想上，應該是把 docker image 從 registry pull 回來後立即 docker run 就能動起來。
實務上，我們有些地方還是需要仰賴 stack, layers, nodes 的設定資訊，所以還是免不了要使用 Chef 的 template 命令幫我們生成設定檔與 Dockerfile，最後再疊加上一層，生成新的 image 後予以部署。
部署時特別要注意，像是 Rails 應用會產生 logs、Unicorn 也會產生 logs，這些 logs 是營運績效、問題診斷的重要資訊 ，我會盡可能在 container 內把這些 logs 放在同一個目錄下，再用 volume 對應到 host 某一目錄底下保存。這樣可以直接從 host 取得 logs，不用進到 container 內，方便很多，也利於 logrotate, fluentd 之類的工具操作這些 logs。
目前想到的是這些，以後若有想到再寫…。