這是該系列的第二篇，點選 此處閱讀第一篇。
在第一篇中，我認為DevOps工程的工作是構建全自動的數字流水線，將程式碼從開發人員的手裡上線到生產。
現在，要有效地完成這項工作需要對基本原理有充分的瞭解，如下所示：

以及基於這些基礎知識的工具和技能的良好理解（見下圖）。
一個快速提醒：你應該從左到右先學習藍色的部分，然後再從左到右學習紫色的那部分。
那麼，回到我們的主題。在本文中，我們將介紹數字管道流程的第一階段：配置。

在配置階段發生了什麼呢？
由於我們的程式碼需要機器來執行，因此配置階段實際上打造了執行程式碼的基礎設施。
在過去，配置基礎設施是一項漫長的，勞動密集型，容易出錯的考驗。
現在，因為我們擁有令人敬畏的雲服務，所以只需點選一下（或多下）按鈕即可完成所有配置。
然而，結果發現通過點選按鈕來完成這些任務是一個壞主意。
為什麼？
因為按鈕點選操作：

• 容易出錯（人類犯錯誤）

• 沒有版本化（這些操作不能儲存在Git中）

• 不可重複（當更多機器時你需要更多次點選）

• 而且不可測試（我不清楚這些點選操作是否真的有效或是產生其他未知風險）

例如，想想配置你的開發環境所需的所有工作，然後是整合環境，然後QA，然後是灰度，接著是在美國的生產環境，歐洲的生產環境。重複性工作是非常乏味，非常煩人的。
因此，我們需要一種新的方式。那便是“基礎設施即程式碼”，這就是這個配置階段所要講的。
作為最佳實踐，基礎設施即程式碼要求無論需要哪些工作來配置計算資源，都必須通過程式碼完成。
注意：“計算資源”是指在產品中正確執行應用程式所需的一切資源，例如計算，儲存，網路，資料庫等。故名為“基礎設施即程式碼”。
此外，這意味著我們不會用點選操作來作為我們的基礎設施部署方式，而是：

• 在Terraform中寫下所需的基礎架構狀態

• 並將它儲存在我們的原始碼控制系統中

• 通過正式的Pull Request流程來徵求反饋

• 再執行測試

• 執行以提供生成我們所需的所有資源

那麼問題來了，“為什麼需要Terraform？為什麼不使用Chef、Puppet、Ansible、CFEngine、Salt、CloudFormation或其他工具來實現呢？”
問得好！關於這一問題，人們已經展開了大量的討論。
簡而言之，我認為Terraform的優勢有：

• 它非常流行，因此工作機會很多

• 它比其他工具更容易學習

• 它是跨平臺的

雖然當前你仍能選擇其他工具中的某個！
【注意】這個領域正在迅速發展並且很容易令人困惑。我覺得需要花幾分鐘時間來談談這些工具發展的近況。
傳統上，像Terraform和CloudFormation這樣的東西已被用於配置基礎設施，而像Ansible這樣的東西則用於來配置它。
你可以將Terraform視為建立基礎的工具，Ansible在其之上完成其他工作，根據你的需求來部署應用程式。

換句話說，你能使用Terraform來建立VM，然後使用Ansible配置伺服器或是部署你的應用程式。
傳統上這些工具會這樣結合起來一起使用。
但是，Ansible可以做很多（如果不是全部）Terraform可以做的事情。反之亦然。
不要因為工具的選擇而困擾到你。你只需知道Terraform是基礎設施即程式碼領域中最具統治力的工具之一，所以我強烈建議你從它開始。
事實上，Terraform+AWS的專業知識是目前最炙手可熱的技能之一！
但是，如果你想逐步用Terraform來取代Ansible，你仍然需要知道如何以程式設計的方式來配置大量伺服器，對吧？
完全不必要如此！
事實上，我預測配置管理工具，如Ansible的重要性將會降低，而基礎設施配置工具，如Terraform或CloudFormation的重要性將會顯著上升。
為什麼呢？
因為所謂的“不可變部署”。
簡而言之，不可變部署是指從不改變已部署的基礎設施的做法。換句話說，你的部署單元是VM或Docker容器，而不是一段程式碼。
因此，你不會去將程式碼部署到一組靜態VM中，而是部署已經包含了已編譯程式碼的整個VM。
你不會選擇更改VM的配置方式，而是部署具有所需配置的新的VM。
你不必去修復生產的機器，你可以直接部署一個新的例項，直接就修復好了！
你將不必在開發與生產環境部署不同的VM集，因為它們都是一樣的。
你應該明白我的意思吧。
如果使用得當，這個模式是非常強大的，我強烈推薦使用！
注意：不可變部署要求將配置與程式碼分開。請閱讀12法則[1]（或是參考其他更棒的思路），其中詳細介紹了這一點。這是DevOps從業者必讀的內容。
程式碼與配置的分離非常重要，你也不希望每次替換資料庫密碼時都要重新部署整個應用程式。相反，請確保應用程式從外部配置儲存（SSM/Consul或是其他）中獲取這個配置。
此外，你可以很容易地看到，隨著不可變部署的興起，像Ansible這樣的工具扮演的角色將越來越小。
原因就是你只需配置一臺伺服器並將其作為自動擴充套件組的一部分去進行多次部署就可以了。
或者，如果你正在使用容器，你肯定希望所有都按定義來進行不可變部署。你不希望開發環境的容器與QA或是生產環境上的不同。
你希望在所有環境中使用完全相同的容器。這可以避免配置偏差，並在出現問題時簡化回滾。
除了容器之外，對於那些剛剛開始使用Terraform的人來說，使用Terraform配置AWS基礎設施是一個教科書式的DevOps模式，你需要真正掌握它。
等等，如果我需要檢視日誌來解決問題呢？好吧，你將無需登入伺服器去檢視日誌，而是通過統一日誌中心來檢視日誌。
事實上，一些人早就寫過關於如何在AWS中部署ELK的詳細文章[2]，如果你想看看它在實踐中是如何完成的，那可以先去搜索閱讀一下。
此外，你可以完全禁用遠端訪問，做到比其他人所能做到的更安全！

總而言之，我們的全自動“DevOps”之旅始於配置執行程式碼所需的計算資源，這就是配置階段，而實現這一目標的最佳方法是通過不可變部署。
最後，如果你好奇從何處開始，Terraform+AWS組合將是一個不錯的選擇！
這就是“配置”階段的全部內容。
相關連結：

1. https://12factor.net/

2. https://medium.com/@devfire/deploying-the-elk-stack-on-amazon-ecs-dd97d671df06

原文連結：https://medium.com/@devfire/how-to-become-a-devops-engineer-in-six-months-or-less-part-2-configure-a2dfc11f6f7d

Kubernetes線下實戰培訓

Kubernetes應用實戰培訓將於2018年12月21日在北京開課，3天時間帶你係統學習Kubernetes 。本次培訓包括：容器特性、映象、網路；Docker特性、架構、元件、概念、Runtime；Docker安全；Docker實踐；Kubernetes架構、核心元件、基本功能；Kubernetes設計理念、架構設計、基本功能、常用物件、設計原則；Kubernetes的實踐、執行時、網路、外掛已經落地經驗；微服務架構、DevOps等，點選下方圖片檢視詳情。