[譯] 如何在六個月或更短的時間內成為 DevOps 工程師，第二部分：配置
照片由Reto Simonet 釋出在Unsplash
注意：這是《如何如何在六個月或更短的時間內成為 DevOps 工程師》系列的第二部分，第一部分請點選 ofollow,noindex">這裡 。
讓我們快速回顧一下上期內容。
在第一部分中，我認為 DevOps 工程師的工作是構建全自動的數字流水線，將程式碼從開發環境轉到生產環境。
現在，要有效地完成這項工作需要對基本原理有充分的瞭解，請看下圖所示：
DevOps 基礎介紹圖
以及基於這些基礎知識的工具和技能的良好理解（見下圖）。
提示：你的目標是先從左到右學習藍色字型部分知識，然後從左到右學習紫色字型部分知識。
好的，回到我們的主題。在本文中，我們將介紹上圖學習路線的 第一個 階段：配置。
配置階段介紹圖
配置階段會發生什麼？
由於我們建立的程式碼需要執行在機器上，因此配置階段實際上是在構建執行程式碼的基礎結構。
在過去，配置基礎設施是一項漫長的、勞動密集型、容易出錯的考驗。
現在，因為我們擁有令人敬畏的雲服務，所以只需點選一下或者多點幾下即可完成所有配置。
然而，實踐證明通過點選來完成這些任務是一個壞主意。
為什麼這麼說呢？
因為按鈕點選：
- 容易出錯(人為犯錯），
- 沒有版本化管理(點選不能儲存在 git 中），
- 不可重複(更多機器=更多點選），
- 並且不可測試(不知道我的點選是否真的有效或出錯）。
例如，想想在開發環境先配置所需的所有工作...然後是初始化環境...然後系統測試...然後進行分級...然後在美國部署生產環境...然後在歐盟部署生產環境...它很快就會變得非常乏味和煩人。
因此，需要一種新的方式。這種新的方式是 架構即程式碼 ，這就是這個配置階段的全部內容。
作為最佳實踐，架構即程式碼要求無論需要哪些工作來配置計算資源，都必須通過程式碼完成。
注意：“計算資源”是指在產品中正確執行應用程式所需的一切：計算、儲存、網路、資料庫等。因此，名稱為“架構即程式碼”。
此外，這意味著，我們將通過架構即程式碼部署而不是通過點選方式：
- 在Terraform 中寫出所需的基礎設施狀態，
- 將其儲存在我們的原始碼控制中，
- 通過正式Pull Request 流程徵求反饋意見，
- 測試一下，
- 執行提供所需的所有容器資源。
現在，顯而易見的問題是，“為何選擇 Terraform？為什麼不使用 Chef 或 Puppet 或 Ansible 或 CFEngine 或 Salt 或 CloudFormation 或其他的？”
好問題！
簡而言之，我認為你應該學習 Terraform 的原因如下：
- 這很新潮，因此工作機會很多
- 比其他人更容易學習
- 這是跨平臺的
現在，你能選擇其中一個併成功嗎？絕對能！
注意：這個領域正在迅速發展，非常混亂。我想用幾分鐘的時間來談論一些最近的歷史和我看到它的發展。像 Terraform 和 CloudFormation 之類的東西被用來提供基礎設施，而像 Ansible 之類的東西被用來配置基礎設施。
一般，像 Terraform 和 CloudFormation 這樣的東西已被用來提供 基礎設施 ，而像 Ansible 這樣的東西則被用來配置 基礎設施 。
您可以將 Terraform 視為建立基礎的工具，Ansible 將房子置於最頂層，然後根據您的需要部署應用程式（例如 Ansible）。
如何理解這些工具介紹圖
換句話說，您使用 Terraform 建立 VM ，然後使用 Ansible 配置伺服器，以及可能用它部署您的應用程式。
通常將這些工具放在一起使用。
但是， Ansible 可以做的（如果不是全部），Terraform 也可以做。反過來也是如此。
不要讓那些困擾你。只要知道 Terraform 是基礎架構程式碼空間中最具好的工具之一，所以我強烈建議你從這裡開始。
事實上，Terraform + AWS 的專業知識是目前最炙手可熱的技能之一！
但是，如果你想推遲 Ansible 支援 Terraform，你仍然需要知道如何以程式設計方式批量配置伺服器，對吧？
不必要！
實際上，我預測像 Ansible 這樣的 配置管理 工具的重要性將會降低，而像 Terraform 或 CloudFormation 這樣的 基礎配置 工具的重要性將會提高。
為什麼這樣說呢？
因為所謂的“不可變部署”。
簡而言之，就是是指不改變已部署的基礎架構的做法。換句話說，您的部署單元是 VM 或 Docker 容器，而不是一段程式碼。
因此，您不會將程式碼部署到VM叢集中，而是部署一整個已經編譯了程式碼的 VM。
您不會更改 VM 的配置方式，而是部署更改了配置的新 VM。
您不會對生產環境機器打補丁，而是直接部署已經打補丁的新機器。
您不在開發環境和生產環境部署的 VM 叢集配置不同，它們都是相同的。
你應該明白了我的意思。
如果使用得當，這是一個非常強大的模式，我強烈推薦！
注意：不可變部署要求將配置與您的程式碼分開。請閱讀[12 Factor App]( 12factor.net/），其中詳細介紹了這個 (以及其他令人敬畏的想法！）。這是 DevOps 從業者必讀的內容。
程式碼與配置的分離非常重要 —— 您不希望每次修改資料庫密碼時都重新部署整個應用程式。相反，請確保應用程式可以從外部配置儲存（SSM/Consul/etc）中提取它。
此外，您可以很容易地看到，如果不可變部署的興起，像 Ansible 這樣的工具開始扮演的角色不那麼突出。
原因您只需要配置 一臺 伺服器並將其作為自動擴充套件的叢集一部分進行多次部署。
或者，如果您正在使用容器，您肯定希望幾乎按要求進行不可變部署。你 不 希望你的開發容器與你的 QA 容器不同，並且與生產環境不同。 或者，如果您正在使用容器，您肯定希望幾乎按要求進行不可變部署。你 不 希望你的開發容器與你的 QA 容器不同，並且與生產環境不同。
您希望 在所有環境中使用完全相同的容器 。這可以避免配置偏差，並在出現問題時簡化回滾。
除了容器之外，對於那些剛剛開始使用 Terraform 的人來說，使用 Terraform 配置 AWS 基礎設施是一個教科書 DevOps 模式，你確實需要掌握它。
但是等等...如果我需要檢視日誌來解決問題怎麼辦？好吧，您將不再登入計算機來檢視日誌，而是檢視所有日誌的集中式日誌記錄基礎結構。
事實上，一些聰明的傢伙已經寫了一篇關於如何在 AWS 中部署 ELK 叢集的詳細文章 —— 如果你想看看它在實踐中是如何完成的，請點選上面連結檢視。
此外，您可以完全禁用遠端訪問，這樣比大多數沒有禁用的人更安全！
總而言之，我們的全自動 “DevOps” 之旅始於配置執行程式碼所需的計算資源 —— 配置階段。而實現這一目標的最佳方法是通過不可變部署。
最後，如果您對從何處開始感到好奇，Terraform + AWS 組合是您開始旅程的絕佳場所！
這就是“配置”階段的全部內容。
第三部分的內容在[這裡]( github.com/xitu/gold-m… -less-part-3-version.md）！
如果發現譯文存在錯誤或其他需要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可獲得相應獎勵積分。文章開頭的 本文永久連結 即為本文在 GitHub 上的 MarkDown 連結。
掘金翻譯計劃 是一個翻譯優質網際網路技術文章的社群，文章來源為掘金 上的英文分享文章。內容覆蓋 Android 、 iOS 、 前端 、 後端 、 區塊鏈 、 產品 、 設計 、 人工智慧 等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃 、官方微博、 知乎專欄 。