為 Serverless Devs 插上 Terraform 的翅膀，解耦程式碼和基礎設施，實現企業級多環境部署（下）

語言: CN / TW / HK
時間 2022-06-23 02:15:27

在上篇《為 Serverless Devs 插上 Terraform 的翅膀，實現企業級多環境部署（上）》中，主要介紹了 Serverless Devs 多環境功能的使用，使用者讀完可能會些疑問，本文會就一些常見問題進行回答。

Serverless Devs 和 Terraform 的關係

可能有些使用者會問，既然你們已經支援了 Terraform，那 Serverless Devs 還有什麼作用，是不是直接用 Terraform 就可以了？

Serverless Devs 和 Terraform 的定位還是明顯不同的。Serverless Devs 面向應用管理及 DevOps，Terraform 面向雲資源，是兩個不同的領域，但並不表示不能在某些層面有交集或者不能整合，整合和被整合能力本來就是開源工具是否標準化的一個衡量標準。

Terraform 解決的是雲資源的 Provisioning，這個領域是有非常清晰的方法論的。而 Serverless Devs 更應該強調如何使用好雲資源，兩者的關係可以用幾個場景說明：

  • Serverless Devs 更多關注如何把程式碼或者安裝依賴分片上傳到 NAS 上，更少關注 VPC/交換機/安全組/NAS 掛載點如何創建出來；

  • Serverless Devs 更多關注如何把檔案上傳到 OSS，並且自動觸發函式完成報表的生成，更少關注 OSS Bucket 如何建立；

  • Serverless Devs 更多關注如何構建程式碼/映象、製作 Layer、部署程式碼、釋出版本、灰度放量來構造完整的 CI/CD 體驗，更少關注 FC 的網路、日誌倉庫、ACR 例項如何創建出來；

  • Serverless Devs 更多關注如何遠端除錯程式碼，如何登陸到線上例項，如何通過日誌以及監控快速發現業務的異常； 

可以看到 Serverless Devs 更加重點關注的是應用執行態以及運維態的操作，這也是 Serverless 架構的工具最重要的使命，但 Serverless Devs 負責的是 Serverless 應用全生命週期管理，必然少不了資源的管理，我們在實踐過程中發現，無論是用雲產品 SDK 還是 Pulumi 這類 GPLs 都需要投入很大精力在資源生命週期的對接上，這對於元件開發者對接更多雲產品來說是非常低效的。而 Terraform 在這方面是最專業的，無論是標準化程度、受認可程度以及資源的豐富度都能很好滿足終端使用者及開發者的需求，因此才觸發 Serverless Devs 和 Terraform 結合這一想法。

Serverless Devs 沒有和 Terraform 耦合，相反的是讓 Terraform 的 HCL 語言自然的在 Serverless Devs 的元件規範裡玩轉起來，可以認為是 Serverless Devs 支援多語言的一種能力。對開發者的價值是可以比較低程式碼的完成基礎設施的搭建，把精力投入到和 Serverless 應用生命週期管理相關的開發上，不然就得開發大量的資源 CRUD 程式碼，這個是非常低效的。

多環境功能和直接用 Terraform 有什麼不同

既然多環境部署也走的是 Terraform，那和我直接用 Terraform 部署資源有什麼區別？

  • Terraform 是個人版的工具，需要本地管理ak/sk、本地安裝 Provider；而多環境是個多租的服務，不需要使用者自己來維護這些；

  • 多環境功能重要的是"管理"的能力，比如模板有版本管理能力，當模板釋出了新版本並且 IaC 的變更是不相容的，此時使用者如果更新環境會導致未知問題，這種情況下系統會自動識別並且保證存量環境的變更還使用舊版本，不受不相容變更帶來的影響；

  • Terraform 是純面向資源的編排工具，和應用的關聯很弱；而環境和服務、流水線可以天然地形成連線關係，比如通過環境可以感知到資源被哪些服務所使用、服務可以通過環境的授權來獲取訪問資源的許可權、可以在流水線中將服務一次性部署到所有環境上，而這些是 Terraform 做不了的；

  • Terraform 只是多環境實現 IaC 的一個技術選型，未來還計劃對接 ROS、Pulumi 等 IaC 專案。

多環境和環境變數的關係

在 CI/CD 中使用環境變數，環境變數中配置 VPC、NAS 啥的，s.yaml 中引用環境變數似乎就可以了，為什麼還要造一個環境概念？

環境和環境變數從名字就能區分出定位的差異，環境變數就是一組靜態配置，雖然可以將一些資源配置寫到環境變數內並在 CI/CD 流水線中引用，但這種方式不具備資源納管的能力。

而環境是個實體資源，具備基礎設施的生命週期管理能力，通過環境可以完成基礎設施的增刪改查，並可以通過訪問控制的方式授予使用者的操作許可權，更新環境時還可以對接一些安全檢查的能力。

通過環境可以讓基礎設施受到保護，比如當多個服務共享環境時，如果發起環境刪除，系統會自動發現環境被其他服務所依賴，此時刪除會被拒絕。

只能企業使用者使用嗎？個人開發者怎麼用？

我是個人開發者，不懂 Terraform，文章中各種模板定義看的有點暈，那我還適合用這個功能麼？

個人開發者一樣適用，但不應該讓這部分使用者承擔寫模板的工作，而是由平臺提供各種業務場景化的模板，開發者開箱即用，這也是我們後續的主要工作。

對個人使用者來說，上阿里雲最複雜的某過於 RAM、VPC、ECS、SLB、NAS 這些複雜的概念，學習曲線太長。在 Serverless 架構下這個問題尤為明顯，Serverless 宣稱低門檻、低成本、低運維，但是上手 Serverless 需要了解一大堆概念，配置一大堆東西，很多使用者在這過程中就被"勸退"了，而環境模板和環境可以極大地簡化雲產品的上手成本，同時又能很安全地操作。舉個例子，使用者選擇一個模板部署環境，就可以一鍵拉起所有云資源，這樣才算是真正的 Serverless。

實現原理

  • 遵循 Serverless Devs 元件開發規範，通過實現一個元件來完成和後端服務的對接

  • 後端服務採用 Serverless + K8s 的架構，通過訊息觸發函式，來完成模板的渲染以及部署任務的執行

  • 採用 KubeVela [ 1] 來完成 K8s 資源的管理以及 Terraform 任務的執行

1.png

多環境為什麼是元件級的能力而不是 CLI 的能力

Serverless Devs 分為 CLI [ 2] 和元件 [ 3] ：

  • CLI 提供最通用的能力，不依賴任何元件，比如：s init、s config、s verify、--template、--debug

  • 元件提供特定的功能，比如 s deploy、s build、s invoke 這些是 fc 元件的能力 

從 env 命令的通用性以及要解決的問題上看，做到 CLI 內也是合適的。但從實現上看，因為需要一個服務端的控制平面來完成使用者資源的部署，出於安全性考慮必須要特定的雲服務來完成，所以才通過一個元件來完成。

參考連結：

[1] KubeVela ：

http://kubevela.io/

[2] CLI：

http://docs.serverless-devs.com/serverless-devs/command/readme

[3] 阿里雲函式計算元件：

http://docs.serverless-devs.com/fc/readme

往期回顧

為 Serverless Devs 插上 Terraform 的翅膀，實現企業級多環境部署（上）

極速上手 Serverless

為了讓開發者快速定位 Serverless 開發問題，找到對應解決辦法，阿里云云原生 Serverless 團隊推出 2022 《Serverless 開發速查手冊》 ，目前已開放下載，我們希望給 Serverless 開發者提供一本能夠速查、速懂的工具書，實實在在幫助開發者快速解決 Serverless 開發遇到的實際問題，讓大家能夠踏踏實實享受 Serverless 帶來的技術紅利！點選閱讀原文，即刻下載手冊！

2.jpeg

「」
「」