[譯] 如何在六個月或更短的時間內成為 DevOps 工程師，第二部分：配置

• 原文地址：How To Become a DevOps Engineer In Six Months or Less, Part 2: Configure
• 原文作者：Igor Kantor
• 譯文出自：掘金翻譯計劃
• 本文永久連結：github.com/xitu/gold-m…
• 譯者：jianboy
• 校對者：lihanxiang

照片由 Reto Simonet 釋出在 Unsplash

注意：這是《如何如何在六個月或更短的時間內成為 DevOps 工程師》系列的第二部分，第一部分請點選這裡。

讓我們快速回顧一下上期內容。

在第一部分中，我認為 DevOps 工程師的工作是構建全自動的數字流水線，將程式碼從開發環境轉到生產環境。

現在，要有效地完成這項工作需要對基本原理有充分的瞭解，請看下圖所示：

以及基於這些基礎知識的工具和技能的良好理解（見下圖）。

提示：你的目標是先從左到右學習藍色字型部分知識，然後從左到右學習紫色字型部分知識。

好的，回到我們的主題。在本文中，我們將介紹上圖學習路線的第一個階段：配置。

配置階段會發生什麼？

由於我們建立的程式碼需要執行在機器上，因此配置階段實際上是在構建執行程式碼的基礎結構。

在過去，配置基礎設施是一項漫長的、勞動密集型、容易出錯的考驗。

現在，因為我們擁有令人敬畏的雲服務，所以只需點選一下或者多點幾下即可完成所有配置。

然而，實踐證明通過點選來完成這些任務是一個壞主意。

為什麼這麼說呢？

因為按鈕點選：

1. 容易出錯(人為犯錯），
2. 沒有版本化管理(點選不能儲存在 git 中），
3. 不可重複(更多機器=更多點選），
4. 並且不可測試(不知道我的點選是否真的有效或出錯）。

例如，想想在開發環境先配置所需的所有工作...然後是初始化環境...然後系統測試...然後進行分級...然後在美國部署生產環境...然後在歐盟部署生產環境...它很快就會變得非常乏味和煩人。

因此，需要一種新的方式。這種新的方式是架構即程式碼，這就是這個配置階段的全部內容。

作為最佳實踐，架構即程式碼要求無論需要哪些工作來配置計算資源，都必須通過程式碼完成。

注意：“計算資源”是指在產品中正確執行應用程式所需的一切：計算、儲存、網路、資料庫等。因此，名稱為“架構即程式碼”。

此外，這意味著，我們將通過架構即程式碼部署而不是通過點選方式：

1. 在 Terraform 中寫出所需的基礎設施狀態，
2. 將其儲存在我們的原始碼控制中，
3. 通過正式 Pull Request 流程徵求反饋意見，
4. 測試一下，
5. 執行提供所需的所有容器資源。

現在，顯而易見的問題是，“為何選擇 Terraform？為什麼不使用 Chef 或 Puppet 或 Ansible 或 CFEngine 或 Salt 或 CloudFormation 或其他的？”

好問題！

簡而言之，我認為你應該學習 Terraform 的原因如下：

1. 這很新潮，因此工作機會很多
2. 比其他人更容易學習
3. 這是跨平臺的

現在，你能選擇其中一個併成功嗎？絕對能！

---

注意：這個領域正在迅速發展，非常混亂。我想用幾分鐘的時間來談論一些最近的歷史和我看到它的發展。像 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、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。