DevOps 工程師成長日記系列二：配置

原文地址：medium.com/@devfire/ho…
原文做者：Igor Kantor
翻譯君：CODING 戴維奧普斯

前情提要

在第一篇文章中，我對 DevOps 工程師的工做定義是搭建一個數字化的全自動流水線來高效地將代碼從編寫環節部署到生產環境中：《DevOps 工程師成長日記系列一：必備知識與技能組合》。

可是高效地完成這項工做首先須要有必定的基礎，以下圖：

同時還要對各種工具和使用這些工具所需的技能有所瞭解，才能作到事半功倍。

舒適提示：咱們的目標是快速地學習下圖中藍色部分的內容，按從左到右的順序，而後開始學習紫色的部分，一樣是從左到右。整個流程分爲六個模塊，順利的話每月完成一個模塊的學習，恰好六個月學完。

在這篇文章中咱們會 cover 整個流水線中的第一部分：配置（Configure）。

綜述

因此在配置階段究竟是要咱們作什麼呢？

簡而言之，就是咱們寫的代碼須要跑在服務器上，在配置階段咱們所要作的就是在服務器上搭建適合咱們的代碼運行的基礎環境。

在過去配置基礎環境的過程是一個及其冗長、處處是坑、重複性高的痛苦經歷。

如今因爲咱們擁有了雲服務器這種高級服務，全部的基礎環境設置均可以經過點擊完成，固然有時候可能須要不少次點擊。

可是，咱們發現經過點擊來實現配置環境也不是一個好主意，由於一樣的問題仍然存在：

1. 仍是處處是坑（human error 沒法避免）
2. 無法控制版本（點擊沒辦法存儲在 git 裏）
3. 重複性高（更多的機器 = 更屢次的點擊）
4. 同時還無法測試（徹底黑箱，不知道點擊後會不會把全部東西弄亂）

想象一下，當你須要給你的 dev 環境、QA 環境、Staging 環境和各個地區不一樣的生產環境作配置時所需的工做量，並且這項工做很快就會變得很是煩人和冗長。

因此咱們就須要一種新的方式來完成這個工做，而這個新的解決方案就是 「基礎設施即代碼（Infrastructure as Code）「 這也是本文關於 DevOps 中配置環節的重點。

基礎設施即代碼（Infrastructure as Code）的最佳實踐即全部歸爲計算資源編排工具類的工做都必須使用代碼來完成。這裏的計算資源指的是爲了讓代碼跑起來所須要的一切，好比：服務器、存儲、網絡、數據庫等等。

此外，這意味着咱們部署基礎設施的方式從各類點擊變爲：

1. 在 Terraform 中編寫所需的基礎架構狀態
2. 將其存儲在咱們的源代碼版本控制中
3. 經過正式的 Pull Request 流程徵求反饋
4. 測試一下配置
5. 經過執行代碼來配置所需的資源

爲何選用 Terraform 而不是其餘的呢？

你如今可能會問爲何要選用 Terraform 而不是 Chef 或者 Puppet 或者 Ansible 或者 CFEngine 或者 Salt 或者其餘什麼呢？

好問題，並且這個問題已經在各個社區翻來覆去討論過無數遍了，簡而言之，我認爲你應該學習 Terraform 有如下緣由：

1. Terraform 如今很火，這表明着會有不少相關的工做機會
2. 相對於其餘的來講，它比較容易學習
3. 它有跨平臺支持

固然這毫不表明着你選擇了其餘的工具就無法玩轉了，相信每一個工程師都有着本身對於工具的理解和選擇。

SIDE NOTE：這個領域正在經歷迅速發展而且可能會讓人困惑，因此我想花幾分鐘時間談談最近的一些歷史，以及我看到事情在往哪裏發展。

傳統意義上來講，Terraform 和 CloudFormation 這類工具是用來編排基礎設施的，而其餘像 Ansible 這類的工具是用來作配置的。

你能夠想像成 Terraform 是一個打地基的工具，而後 Ansible 在地基上蓋房子，在幫助你的代碼部署到相應的環境。

換句話說，經過 Terraform 來建立虛擬機，而後使用 Ansible 來配置和部署應用，過去都是這麼搭配操做的。

然而，工具發展到如今，其實 Ansible 能幹的事 Terraform 基本上也能作了，反之亦然。不過也別讓這些事兒煩你，只須要知道如今 Terraform 已是這個領域最重量級的選手，因此強烈推薦從 Terraform 開始學習。

事實上，Terraform + AWS 已經成爲最火的技術需求之一了。

不可變基礎設施（Immutable Infrastructure）

實際上，我預測 Ansible 這類配置管理工具的重要性會下降，而 Terraform 或 CloudFormation 等基礎設施編排工具的重要性將會提升。

爲何呢？正是由於不可變基礎設施（Immutable Infrastructure）概念的出現。

不可變部署是指永不改變已部署的基礎架構的作法。換句話說，你的部署單元是 VM 或 Docker 容器，而不是一段代碼。所以，你不會將代碼部署到一組靜態虛擬機，而是部署整個已經編譯了代碼的 VM。

不可變基礎設施中所謂的不可變，即安裝一次，不作修改，用過即扔。有點像一次性產品，或者能夠稱爲即拋型。

再也不須要給生產環境中的機器打補丁，直接部署一個新的已經打好補丁的機器就行了。

也沒有必要區別生產環境和編譯環境中 VM，全部的機器在不可變基礎設施概念下都是同樣的。

實際上，您能夠安全地禁用對全部生產環境機器的全部 SSH 訪問，由於已經沒有任何事情可作 - 沒有要更改的設置，沒有要查看的日誌。

若是能正確的使用，這是一個很是強大的模式，因此我強烈推薦！

注意：不可變部署要求將配置與您的代碼分開。請閱讀 12 Factor App 宣言（ 12factor.net/ ），其中詳細介紹了這一點（以及其餘很棒的想法！）。這是 DevOps 從業者必讀的內容。

代碼與配置的分離很是重要 - 你也不但願每次輪換數據庫密碼時還得從新部署整個應用程序堆棧。因此，請確保應用程序能從外部配置存儲（SSM / Consul / etc）中提取這些配置。

此外，您能夠很容易地看到，隨着不可變部署的興起，像 Ansible 這樣的工具扮演的角色就變得不那麼突出了。緣由是，如今只須要配置一臺服務器並將其做爲擴展組的一部分進行屢次部署就能夠實現大規模的自動化配置了。

或者，若是您正在使用容器，那麼你應該從心裏渴望使用不可變部署的。你確定不但願開發容器與 QA 容器和生產容器不一樣。而且但願在全部環境中使用徹底相同的容器。這能夠避免配置誤差，並在出現問題時簡化回滾。

除了容器以外，對於那些剛剛開始學習的人來講，使用 Terraform 配置 AWS 基礎設施是一個教科書級的 DevOps 實踐模式，也是成長爲 DevOps 工程師的必經之路。

可是若是我須要查看日誌來解決問題怎麼辦？好吧，您將再也不登陸虛擬機來查看日誌，而是查看集中式日誌管理的基礎設施來解決問題。這一樣使得你能夠徹底禁用遠程訪問，讓環境變得更加安全。

看到我自信的微笑了麼

總而言之，咱們的全自動 「DevOps」 之旅始於配置運行咱們的代碼所需的計算資源。實現這一目標的最佳方法是經過不可變部署。

最後，若是你還好奇從什麼地方開始的話，就去試試 Terraform+AWS 的組合吧，這將是一個很好的起點。

譯後記

對於國內的開發者來講，能夠選擇 Terraform + 騰訊雲的組合嘗試，具體能夠參考 cloud.tencent.com/developer/a… 這篇文章中提到的方式。

咱們相信，在企業數字化轉型落地過程當中，DevOps 是企業軟件開發模式革新的重要支柱。 CODING 做爲國內領先的 DevOps 解決方案提供商，支持從需求到部署的研發全流程管理，涵蓋了項目管理、代碼管理、持續集成、製品庫管理、測試管理、部署管理、缺陷管理、知識管理，幫助企業輕鬆將創意轉化爲創收。CODING 也會持續關注並分享軟件研發領域最新理念與技術，與 DevOps 工程師一塊兒成長。