[譯] 如何在六個月或更短的時間內成爲 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 工程師的工做是構建全自動的數字流水線，將代碼從開發環境轉到生產環境。

如今，要有效地完成這項工做須要對基本原理有充分的瞭解，請看下圖所示：

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、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。