Ansible 的最佳實踐

什麼是最佳實踐 (Best Practice)？

然而，我並不認為所謂的 best practice 是用來限制開發人員都不可以有任何彈性的緊箍咒。根據背景的不同，每個開發團隊本來就有可能有屬於自己的一套風格。Best practice 只是某種程度上提供了一個建議，來讓不同的開發團隊都可以在最快的時間內建立出最有效且有一定品質的產品。就算是單人工作者，也可以透過 best practice 的概念來迅速掌握網路上不同專案的邏輯及開發目的。

Ansible 的最佳實踐

在 Ansible 官方提供的 中，從專案架構、inventory file 的撰寫到 task 之間是否需要斷行都有描述。我會建議讀者可以花時間稍微瀏覽一下，這對未來 Ansible 設計的掌握會很有幫助。接下來，我會用我在自己的 GitHub 上的一個小專案來介紹怎麼使用 Ansible 的最佳實踐來設計自己的 Ansible 專案。

專案架構

一般來說，大部分的 Ansible 專案都蠻常使用 best practice 的 來做為專案結構的參考。（其中 Ansbile 也提供了另一種風格 - alternative directory layout，與 directory layout 主要差異在於 inventory file 的結構。如果在不同環境下的共用環境變數較少的話，使用這種結構會相對好管理。）

對比於我自己在 GitHub 上的專案的結構：

• 在這裡我存放了所有跟這個專案有關的 roles。由於每個 role 的結構類似，所以我以其中的 這個 role 來做簡單介紹：

  • defaults/

    在這個資料夾下，通常被用來定義優先度較低的變數。除了 defaults/，習慣上我還會另外將只跟這個 role 有關的變數放在 vars/ 的資料夾下來做使用目的上的區分。關於 Ansbile 變數的優先權，可以參考官方在這裡的。

  • files/

    這個資料夾內通常存放著這個 role 在部署過程中會需要使用或執行的檔案。

  • tasks/

    整個 role 中最核心的部分。這裡面定義了這個 role 的部署邏輯以及運行任務。在這個資料夾下可以不只有一個檔案，然後在 main.yml 裡定義何時呼叫其他檔案。

  • meta/

    meta/ 資料夾內定義了這個 role 的依賴 (dependencies) 關係。以這個 docker-jenkins 為例，docker 這個 role 就是其依賴。在運行時，會在運行完 內定義的所有 dependencies 後才接著執行 role 本身的任務。我們可以充分利用這個特色來重複組合及利用已經定義好的 role 以減少重造輪子的情況發生。

  • handlers/

    我們會將所有 事件存放在這個目錄下。雖然這個專案並沒有使用到任何 handler，但 handler 是 Ansible 中非常好用的一個功能。我們可以根據 Ansible 運行時 tasks 狀態的改變來通知 (notify) handlers。最重要的特色是，無論有多少個 task notify 同一個 handler，該 handler 都只會運行一次。非常常見 handler 的實踐之一就是在檔案被修改後重啟 services。