我個人已經用了 ansible 一段時間了，像是 kaif 就是用 ansible 部署的。不過公司本身的系統已經四~五年了，長久以來都是用 scripts 管理。直到最近才花了一兩個禮拜重整，全部用 ansible 重做，去掉那些 adhoc scripts。

這過程實在是冗長，要將 ansible 每個指令都設計成 idempotent 實在是有夠久 (不斷試誤，重新 play 都要很久)。不過做完了之後就會覺得值得了，因為整個部署的歷程、做法都完整的寫在 playbook 裡。只要查 playbook，就知道哪台主機怎麼部署的，做了哪些設定，部署到哪裡。只要學 ansible 這麼一套，就可以了解整個部署的架構。不再像以前要到處找 shell script，而且中間還混了一堆 python/ruby/perl scripts (還包含它們的 dependencies 安裝，版本控制... 實在很頭痛這。)

我想 ansible 是很適合中小企業多的台灣公司吧，說真的單一服務會部署到 > 50 台以上生意真的做很大，沒幾家辦得到的。不過 ansible 就算是只部署到一台主機，也是值得投資的技術。對 ansible 來說，部署一台和五十台的技術門檻都一樣，都很低，不像其他 puppet/chef 都太複雜，太難學，只適用於大公司。我很建議管理零星主機的開發者 (比方說 3~20 台)，開始導入 ansible，把過去的 script 都漸漸汱換掉。

如果是新專案，大概就是一開始就準備好 vagrant 的 playbook 給開發時用，等到專案要上線了，拿那本 playbook 改個幾行就可以上線了。你的開發團隊的環境統一，好管理，一鍵搞定他的電腦的開發環境。而你的 production 環境又跟 local 的 vagrant 很像，等於每個開發者都很自然的熟悉正式機的運作，這投資報酬率很好呀。

要說 ansible 的缺點就是他的 playbook 只是 yaml 格式，沒辦法寫簡單的 loop ( with_items 不夠用的)。遇到這問題，在實務上你會開始用其他怪招來處理這個缺點，但這就讓原本很簡單的 playbook，藏著一些別人看不懂的設定 (他得知道你繞著彎寫這麼多額外的 task，其實只是為了做一個 loop 而已… )

另外，ansible galaxy 裡面放在前人努力的成果，要裝 redis？隨便找一下就有現成的可用。不過它也個問題就是有時候你不知道該挑哪個 role 來用，因為水準撐疵不齊，它的網頁寫的不是很好，不夠你判斷哪個 role 水準比較高，有持續在維護的。你還是得去它的 github 看一下原始碼才比較有譜。

最後，來抱怨一下血淚… ansible 的 ec2 module 有個這麼樣的設定：

- ec2:
    key_name: mykey
    group: webserver
    instance_tags:
        foo: bar
    exact_count: 5
    count_tag: foo

這個 task 的是建立 ec2 裡的 instance。條件是 tag name 為 foo 的主機，保證一定開 5 台 (exact_count:5)。媽呀，這個指令有夠恐怖，我練習個幾次後，就在 production 下，結果 tag 下錯了，我線上的 server 就被胡亂的 terminate ，只剩下 5 台，其他都被殺了，整個快哭了… devop 的血淚史又翻過了另一頁…

exact_count 這功能立意很好，但除了一些 stateless 的 web server ，有什麼服務可以 random terminate 的？資料庫鐵定不行的啊，master 主機怎麼能亂殺？但就算是 slave ，它啟動也要有很長的準備時間 (要先 copy 資料)，哪有說設個 slave exact_count: 3，就讓 ansible 隨便挑3台留下，胡亂殺掉任意的其他台 slave？而像 redis 這種 cache server，也會有 warm up 的期間，哪有說殺就殺，說開就開？真的能適用 exact_count 這種部署方式的，只有那些幾乎沒 state 的 nginx, ha_proxy 服務吧…