![](https://img-blog.csdnimg.cn/20210701093851144.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)

作者 ｜ 林俊（萬念）
來源 ｜[爾達 Erda 公眾號](https://mp.weixin.qq.com/s/kAvxNJi3fKWu6Cd0ePTTaA)

## 從一個小故事開始
你是一個高階開發工程師。

某天，你自信地寫好了`自動煮咖啡`功能的程式碼，並在本地除錯透過。程式碼合併入主幹分支後，你準備把服務釋出到測試環境，進入提測流程。

你熟練地開啟專案協同，新建了一個釋出工單給運維同學，詳細備註了需要釋出的程式碼分支，並特別強調這次需要專門新增一個環境變數開關 `AUTO_MAKE_COFFIE_ENABLED=true`。

過了一段時間，工單處理完成，測試同學開始測試。

突然，噩耗傳來：你的專案協同裡出現了幾個 Bug。

你很疑惑，為什麼本地完美執行的程式碼，在測試環境被提了這麼多 Bug ？

你開始懷疑程式碼中某個地方的邏輯有問題。可仔細排查後卻仍然定位不到問題。

最後，你終於發現，是運維同學複製環境變數時少複製了一個字母：
`AUTO_MAKE_COFFIE_ENABLE=true`，`ENABLED` 少了一個 `D`。

上面這種情況是不是很熟悉？雖然不是你的鍋，卻拖慢了你成為十倍程式設計師的進度。

那麼，該怎麼避免呢？

你一定在想：要是沒有手工複製操作就好了。那就要有個地方來儲存你的配置，但是你沒有許可權、也不想登入到運維操作平臺自己貼上配置。

你靈光一現：要是和運維同學約定好一個配置檔案，把部署配置也提交進程式碼裡，運維同學從檔案裡讀取應用環境配置，問題就迎刃而解了。

## IaC 是什麼
在上面的故事裡，這個特殊約定好的配置檔案就是這個應用基礎設施的一部分（IaC 中的 I）。

我們該怎麼理解基礎設施呢？一個稍微複雜點的應用，只有程式碼是無法執行起來的，因為它還有很多環境依賴需要被準確描述，比如需要執行環境有 make、git 等指定的命令列工具，依賴了哪些中介軟體等。

因此，產品團隊在實施持續交付的過程中，必須考慮將基礎設施的維護納入進來，作為支援產品執行的一部分。
同時，技術的快速進步和演化，也使得基礎設施的配置不得不頻繁變化。在這種快速變化的過程中，要求基礎設施既要靈活，也要安全、可靠。

參考 Wikipedia 上的定義，IaC 裡的 Infrastructure 廣義上是指 IaaS 層的基礎設施，包括物理伺服器、虛擬機器以及相關的資源定義等。As Code 是指這些配置都應該被放到 VCS 上管理起來。

As Code 的好處是，你可以享受版本管理天然的福利，很方便地做一些回滾操作等。

> 當你把 Code 維護在 Git 裡，就成了 GitOps。感興趣的同學可以搜尋 GitOps 相關文章進行學習。

那麼，As Code 裡的 Code 應該長什麼樣？這個格式由具體的自動化平臺來定。至於 Code 的型別，指令式和宣告式都可以。例如，常見的 Ansible 一般來說是指令式的，而 Terraform 是宣告式的。當然，宣告式定義更為推薦，因為這是一種面向終態的定義，對開發者遮蔽了具體實現細節，更加友好。

## 雲原生時代，以應用為中心的 IaC 有什麼不同？
時間快進到雲原生時代。

在服務上雲的大趨勢下，基礎設施的概念已經不再侷限於 IaaS 層。雲原生時代，開發者的焦點逐漸聚集到了應用上。即：以應用為中心。

持續整合、持續部署和 DevOps 這些概念的廣泛推行和接受，要求產品團隊對部署和運維要有更高的自主性。

首先，在 DevOps 概念深入人心的今天，一個開發工程師如果僅僅是把程式碼寫好，是遠遠不夠的，那只是做好了 Dev。真正的軟體交付的生命週期，是從 Ops 開始的，運維同學早已不再負責應用的部署和運維，這都是開發者的事情。

Docker 的出現使得映象交付成為大多數應用軟體事實上的交付標準。所以，應用裡需要有一個檔案來定義怎麼樣把你的程式碼製作成映象，這個檔案通常是 Dockerfile。

與此同時，PaaS 平臺的普及，使得開發者甚至不需要關心 Dockerfile。因為 PaaS 平臺可以透過你的應用目錄結構和特徵檔案，自動探測和選擇合適的構建方式，這個程式碼編譯和映象構建的過程被稱為 BuildPack。當然，在編譯之前，你可能還需要做一些程式碼質量檢查、合規性檢查等，這些流程化的配置，需要有一個流程描述檔案來宣告。在不同的 PaaS 平臺上，會有不同的宣告方式。

## Erda DOP 裡怎麼樣把 IaC 做得更好
Erda 是一個以應用為中心的企業級一站式數字化 PaaS 平臺。

DOP，即 DevOps Platform，是一個以應用為中心的一站式的 DevOps 平臺。

一個 Erda 應用支援程式碼質量掃描、程式碼安全掃描、單元測試執行等，映象製作好之後，還有映象安全掃描、持續部署、介面自動化測試等。透過這些流程對應用的全生命週期進行管理。

在這個平臺上，你可以使用 pipeline.yaml 來定義應用的 CI/CD 全流程。很顯然，這個 pipeline.yaml 就是這個應用基礎設施的一部分。

同時，你需要用一個宣告式的 erda.yaml 來描述你的應用微服務架構，包括微服務之間的依賴關係、對中介軟體的依賴等等。

在平臺設計之初，我們就對應用做了抽象，使得它可以被部署到任意平臺，包括 K8s、DC/OS 等，對開發者遮蔽了具體實現細節。

因此，當應用部署在 Erda PaaS 平臺上時，這兩個檔案是必不可少的。
> 值得一提的是，在平臺最早期的時候，我們只有一個 erda.yaml 檔案，裡面把微服務架構和構建過程寫在一起。在實踐過程中，我們逐漸意識到這樣的方式擴充套件性不夠，很難進行流程定製。並且命令式和宣告式的兩種形態耦合在同一個檔案中，使用者的心智切換成本也更高。

除此之外，我們還支援在 .erda 目錄下定義 API 描述檔案來對 API 全生命週期進行管理。

當這些 Infrastructure 都被作為 Code 提交之後，Erda 平臺就可以根據這些配置，進行持續整合和持續交付，最終自動把應用完整地部署起來。

以 Erda 自身舉例，Erda 本身的持續整合、自動版本釋出等，都是在 Erda 平臺上自舉的。
erda.yaml 部分截圖如下：
![](https://img-blog.csdnimg.cn/20210701093914893.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)

用於 CI 的 pipeline.yaml 部分截圖如下：
![](https://img-blog.csdnimg.cn/20210701093926307.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzU5MzU4NjQ4,size_16,color_FFFFFF,t_70#pic_center)

當你的應用是一個標品時，有了 IaC，給客戶交付這個應用就變得非常簡單。你要做的，只是把程式碼倉庫完整地推送到新的應用程式碼倉庫裡，然後執行流水線。執行完畢後，一個完整的應用就被交付到了新的客戶環境裡。之後，開發者在這個新應用進行定製化開發，在應用的基礎設施變更時，把變更提交到程式碼裡進行版本控制管理。

## 總結
> You build it, you run it.

所以我們說，基礎設施即程式碼（IaC）是雲原生時代開發者體驗的核心。

有了 IaC，作為開發者的你，終於可以更好地掌握應用的全生命週期了。

# 歡迎參與開源
Erda 作為開源的一站式雲原生 PaaS 平臺，具備 DevOps、微服務觀測治理、多雲管理以及快資料治理等平臺級能力。**點選下方連結即可參與開源**，和眾多開發者一起探討、交流，共建開源社群。**歡迎大家關注、貢獻程式碼和 Star！**
****

- **Erda Github 地址：**[_https://github.com/erda-project/erda_](https://github.com/erda-project/erda)
- **Erda Cloud 官網：**[_https://www.erda.cloud/_](https://www.erda.cloud/)

雲原生時代，為什麼基礎設施即程式碼（IaC）是開發者體驗的核心？

相關文章