在剛開始接觸組態管理工具（Configure Management Tool，或常見譯為配置管理工具）的時候，應該都會經歷過一段日子，就是擔心自己寫的自動化腳本會不會有問題，特別是當腳本要使用在 Production 環境時，總是會再三的確認，深怕自己一個不小心，不但沒省事，反而把 Production 環境搞壞了。
本文簡單地談談在 Ansible 中有哪些小技巧可以幫助你降低這些憂慮，放膽執行您的 playbook。
（本文同步發表於 Medium）
 （Photo by John Schnobrich on Unsplash）
在實際執行 playbook 之前的三個基本 Options 先從 ansible-playbook 指令內建的 Options 開始說起，有三個 Options 是最基本的檢查，分別是：
--syntax-check --list-tasks --list-hosts –syntax-check 首先是 --syntax-check，它可以用來幫你檢查 playbook 有沒有格式或語法錯誤，不過其實我們不用手動執行它，因為當你執行 ansible-playbook 時，就已預設會先進行語法檢查了。 所以在 --help 中也是這麼說明的。
--syntax-check perform a syntax check on the playbook, but do not execute it （謎之音：那你還浪費篇幅介紹它。）
對於現代的開發者而言，「語法檢查」通常會跟工程師使用的編輯器、IDE 綁在一起，讓語法檢查能夠自動完成，以 ATOM 為例就有 pacakage - linter-ansible-syntax 可以幫助我們在撰寫 playbook 時即能完成語法檢查。
–list-tasks 第二個 Option 是 --list-tasks，它可以幫你列出在即將要執行的 playbook 中有哪一些 tasks 會被執行。建議在執行重要的 playbook 之前可以先跑一次 --list-tasks，複閱是否會執行的皆是你所預期的 tasks。...
今年（2017）的 COSCUP 採用與過往不同的徵稿方式，而 DevOps Taiwan 社群也共襄盛舉貢獻了三場分享。
縱然我們知道談到 DevOps 時，不該只談論其中的技術層面，更應該要包含文化層面的議題，不過在這種技術力爆表的場子，就請原諒我們還是會以技術為主要的分享內容。
（不過這麼說有失偏頗，因為 COSCUP 2017 還是有像是「如何將女友培養成開源貢獻者」這種軟性的主題，因此只要有心，還是能夠分享非技術主題的。）
DevOps Taiwan 這次由三位講者，分別負責一場分享，首先我們邀請了部落格「小城故事不多-科技部」的蔡宗城（smalltown）為我們分享「Infrastructure As Code」。
第二位講者則是大家從小看到大的部落格「凍仁的筆記」其主人凍仁翔，為我們分享「DevOps 人一定要知道的 Ansible & GitLab CI 持續交付技巧」。
最後，則由小弟我延續凍仁翔的題目，帶來一場簡易的 Workshop 「Ansible & GitLab CI/CD workshop 101」。
Ansible & GitLab CI/CD workshop 101 這場 Workshop 在構思時，預定的難度是 101 的程度，但實際動手設計內容時發現要講多淺才算是 101？要多複雜才算是 201、301 或更高的難度？有一些難以拿捏，總之就請各位保持著一種開開心心的心情來跟著下面的內容操作練習即可，到底是 101、201、或甚至根本只是幼幼班就先拋在腦後吧（逃）。
回到正題，這場 Workshop 希望能幫助大家藉由實際操作，能夠體驗看看 CI / CD、Automation，以及當我們在談到開發流程的規劃，關於 workflow 或 pipeline 的規劃時可能要注意些什麼？
要注意的是，這個 workshop 的案例只是一個簡單的示範，不同的公司、組織或團隊在規劃 pipeline 時會有各自的考量，因此在實際體驗之後，當你回到自己的團隊時，務必要根據你自身的情況進行規劃，如此才能建構出最適合你團隊的 CI / CD pipeline。
所需工具 本次我們會使用的工具如下：
Ansible - 我們會利用 Ansible 撰寫一些簡易的自動化腳本。 Docker Community Edition - 用來運行你自己 CI Runner 與模擬 Web Server。 續上，一台可以跑得動 2-3 個 Container 的主機（可以是你自己的筆電、雲端的 VPS，或其他。），預計會消耗 5 GB 以內的硬碟空間，因為在 Workshop 使用的是個人自建又大又肥的 Container。 GitLab....

籌備多時的 DevOps Taiwan Meetup #3 順利在 2016/11/23 夜間舉辦。感謝極客窩 (Geek Cave) 贊助場地，感謝四位講者黃俊宏、蔡宗城、Mose、Wayne Lin 為本次活動的付出，感謝志工群的幫忙。最後也感謝社群朋友對本次活動的熱情參與！
就以此文簡短紀錄一下本次活動的林林總總。
（封面背景圖片來源 https://unsplash.com/search/fight?photo=1iHpSdiZyFA）
籌備 其實原本 Meetup #2 的活動主題就是「配置管理工具大亂鬥」(CM Tools 大亂鬥) ，但因為 Meetup #2 一直遲遲未能順利籌辦，而當時正逢 DevOps Summit 2016 剛結束，葉秉哲 (葉大) 也有意再分享一次 TOC 的講題，於是在天時地利人和的情況下，就先以「思維引導、持續改善，引發團隊改變新契機」為題舉辦了 Meetup #2。
那到底什麼原因讓「CM Tools 大亂鬥」難以籌辦呢？
主要有兩個原因：
講者邀請 想要一次湊齊四種工具、四位講者實在是一件辛苦的事情，尤其是 Puppet 與 SaltStack 這兩個工具的講者。如果你去 Google 搜尋 Ansible 或 Chef，大概都能找到幾位己經浮出水面的講者。但是 Puppet 與 SaltStack 能找到的則相當有限。 如果不能用 Google 搜尋來找講者，就只好透過人脈來間接尋找了，於是在志工群動員了各自的人脈暗地詢問之後，最終我們才湊齊了四位講者。
而且講者還不是找到即可，還要與對方確認意願、約定日期時間，其中 SaltStack 的講者一度流標，因為時間上無法配合，最後是又再透過 Chef 的講者蔡宗城的人脈才順利邀約到 Wayne 來擔任講者。
規劃活動內容 CM Tools 大亂鬥，到底要怎麼鬥？這也讓志工們苦惱許久。 最後志工們討論出了一個很棒的想法，即是分為上下半場的活動。...
注意！因為 open source 的工具改版的速度非常快速，而本文提到的 ansible-container 更是一個非常新的專案，恐怕不用幾天的時間，本文就會變成過期文章，因此閱讀之前建議先確認一下 ansible-container 目前的最新狀態，避免因為本文而讓你產生誤解。 （謎之音：所以你寫了一篇超短命的文章。）
本文確實已經過期，超短命的！ ansible-container 已經更新好幾回合了，現在按官方文件操作就可以正常試用了喔！
（再次更新，ansible-container 已經 DEPRECATED 了，原本使用它來 build container 的人，請改用 ansible-bender；如果是使用它來 deploy container 至 K8s，則請改用 Ansible Operators。）
Ansible 官方這次更新的 2.1.0.0 版本，其中一個特點就是與 Container 有更好的互動，像官方部落格就特別寫了一篇文《SIX WAYS ANSIBLE MAKES DOCKER-COMPOSE BETTER》來介紹一部分重點。
不僅如此，Ansible 官方其實從五月就悶不吭聲的在 Github 上新建了一個新的工具 ansible-container，目標讓 Ansible 在操控與管理 Container 上能更靈活。
以下就依據目前官方 GitHub 上已釋出的資訊，搶先試用一下 ansible-container。但文章很長，因為記錄了幾個雷，如果你只想要爽爽順順的試用，那可以跳到最後一個段落，我有將最後除雷完後的環境，做一個簡單的記錄。
跳至除雷結果 如果你很有耐心一起除雷，那就繼續往下看吧！
安裝 ansible-container 必須要手動安裝，所以第一步當然是將官方 repo 先 clone 一份回來。
接著是安裝 docker-compose，因為根據官方文件 ansible-container 需要依賴 docker-compose library，因此使用它的前提就是你也必須安裝好 docker-compose。 （但其實不止如此，repo 中還有一個 requirements.txt 請務必閱讀，並將其中所列的 python lib 全都預備齊全為佳，不然可能會踩到雷。）...
有時候我們會需要編寫一些比較小型的 Playbook，例如每次遇到重大漏洞時，用來修補漏洞的 Playbook。這樣的 Playbook 通常 tasks 不多，有時甚至只要 1 ~ 2 個 tasks 即可搞定。但假設你同時管理了 Ubuntu 及 CentOS，兩者分別是用 apt 與 yum 來管理套件，這導致可能需要為不同的 OS 各寫一個 Playbook。
有沒有辦法可以只編寫一個 Playbook，同時將 apt 與 yum 的 task 都寫進去，但能動態的判斷每次執行 Playbook 時該啟用哪一個 task 呢？
答案當然是可以，這需要用到 Playbook 中的 when 來達成。
基本上 when 就像是一般編寫程式會用到的 if 判斷式一樣，你可以告知 Ansible 在哪些狀況之下才要執行某個 task，藉此我們就能將多種不同情況的 tasks 寫在同一個 playbook.yml 之中，讓 Ansible 來依據狀況執行後續的動作。
回到前面提到的案例：
「編寫一個 Playbook 裡面包含了 Ubuntu 的 apt 及 CentOS 的 yum，當要執行 Playbook 時可以彈性的讓它自動執行正確的 tasks。」
目前比較常看到有幾種寫法：
利用 Variables 自行控制 透過 register 自動註冊新的 Variables 透過 gather facts 取得遠端主機資訊 以下一一說明這幾種寫法。...
Ansible 的 playbook 只需要 hosts 與 tasks 這兩個最基本的參數即可運作。一個最基本的 playbook 的結構會長成下面的模樣。
---
- hosts: myVM
tasks:
- apt: name=curl state=latest update_cache=yes tasks 設定了這個 playbook 要執行的動作，上面的範例很簡單，它只有一個動作就是透過 apt-get 安裝 curl。
而 hosts 則會與 Inventory file 搭配，Ansible 在執行 playbook 時，會從 Inventory file 中找到吻合 “myVM” 的主機，對它執行 tasks 中的動作。
一般來說當主機越來越多時，就必須用到一些進階 Inventory file 技巧來達到複雜的彈性運用，像是下面的舉例：
設定多個不同的 Inventory file 在執行 playbook 時，直接指定不同的 Inventory file。 例如：公司的主機群放在 Inventory file A，私人的主機群放在 Inventory file B。
設定多個不同的 Groups 在一個 Inventory file 之內，利用 Groups 區分主機群。...