前言

隨著現(xiàn)代化應(yīng)用的普及和企業(yè)上云的深入，項目中會涉及越來越多的云資源使用。企業(yè)上云過程中，往往會有平臺（Platform）團隊和基礎(chǔ)設(shè)施（Infra）團隊：平臺團隊關(guān)注業(yè)務(wù)，根據(jù)業(yè)務(wù)場景進行抽象，對研發(fā)人員屏蔽基礎(chǔ)設(shè)施；基礎(chǔ)設(shè)施團隊關(guān)注安全及成本，為平臺團隊規(guī)劃了不同的子賬號、權(quán)限策略以及網(wǎng)絡(luò)配置。 這種分層管理的必然結(jié)果導(dǎo)致應(yīng)用和基礎(chǔ)設(shè)施的生命周期會完全不同，因此基礎(chǔ)設(shè)施管理員、平臺管理員、研發(fā)人員關(guān)注的云資源視角也不盡相同。比如：

• 基礎(chǔ)設(shè)施管理員管理整家企業(yè)的云賬號，規(guī)劃企業(yè)的網(wǎng)絡(luò)配置，并為各個平臺團隊設(shè)置不同子賬號以及訪問策略；
• 平臺管理員持有子賬號，根據(jù)容災(zāi)及高可用場景劃分地域、安全、流量策略；根據(jù)業(yè)務(wù)場景規(guī)劃日志、存儲、數(shù)據(jù)庫的規(guī)格、備份配置、Quota 等；根據(jù)研發(fā)流程要求規(guī)劃 CI/CD 流水線；
• 研發(fā)人員在使用平臺過程中，僅需關(guān)注代碼、數(shù)據(jù)、配置等程序相關(guān)內(nèi)容：
• 當需要訪問數(shù)據(jù)庫時，向平臺索要數(shù)據(jù)連接串；
• 當需進行日志采集時，將采集路徑提交給平臺，由平臺操作日志服務(wù)完成日志采集配置掛載；
• 當需要使用持久化存儲時，將本地掛載路徑提交給平臺，由平臺操作存儲服務(wù)完成文件目錄掛載；
• 發(fā)布代碼，自動觸發(fā) CI/CD 流水線的執(zhí)行；

因此，隨著職責邊界的不同，平臺團隊面臨著更大的挑戰(zhàn)，既要面向研發(fā)人員消化業(yè)務(wù)，又要面向基礎(chǔ)設(shè)施團隊解釋云產(chǎn)品的使用，無疑增加了很多溝通成本，降低了業(yè)務(wù)的迭代效率。

如果能建立一種自動化的管道，讓不同團隊自助化地完成各自的邊界，勢必會極大地提升生產(chǎn)力。這需要幾個很重要的概念來連接 Dev 和 Ops：

• 服務(wù)：對代碼、程序的描述，只描述跟程序相關(guān)的信息，比如函數(shù)配置、日志采集路徑
• 對于函數(shù)型應(yīng)用，服務(wù)一般描述一個函數(shù)
• 對于容器化應(yīng)用， 服務(wù)一般描述一個 Workload
• 環(huán)境：服務(wù)運行在不同的環(huán)境上，環(huán)境是服務(wù)運行的載體，描述了基礎(chǔ)設(shè)施（如網(wǎng)絡(luò)、集群、存儲）的配置，以及應(yīng)用運行時的運維配置（如彈性伸縮、資源規(guī)格）
• 流水線：對 CI/CD 的描述，完成代碼到服務(wù)的構(gòu)建，并將服務(wù)部署到所有的環(huán)境上
• 應(yīng)用：一組服務(wù)、環(huán)境、流水線所有資源的集合

要實現(xiàn)高效的自助化操作，合理化的方案是將上述概念進行模板化，并使用如下的工作流來完成：

• 平臺管理員將網(wǎng)絡(luò)、日志服務(wù)、存儲、數(shù)據(jù)庫等基礎(chǔ)設(shè)施資源根據(jù)測試/生產(chǎn)隔離的要求，封裝成環(huán)境模板；將阿里云函數(shù)計算（FC）的函數(shù)、Serverless 應(yīng)用引擎（SAE ）應(yīng)用這些研發(fā)關(guān)注的業(yè)務(wù)資源封裝成服務(wù)模板；將 CI/CD 的基礎(chǔ)流程封裝成流水線模板；
• 基礎(chǔ)設(shè)施管理員審核模板，通過后為平臺管理員分配對應(yīng)的子賬號；
• 平臺管理員持有子賬號選擇環(huán)境模板創(chuàng)建不同的測試、預(yù)發(fā)、生產(chǎn)環(huán)境，然后授予研發(fā)子賬號訪問權(quán)限，或者授予研發(fā)寫權(quán)限來自助創(chuàng)建環(huán)境；
• 研發(fā)人員選擇服務(wù)模板以及關(guān)聯(lián)的環(huán)境來創(chuàng)建服務(wù)，實現(xiàn)將應(yīng)用程序自動部署到指定的環(huán)境上；
• 研發(fā)人員選擇流水線模板，通過主動觸發(fā)或者代碼提交自動觸發(fā) CI/CD 的執(zhí)行。

通過這種分邊界的模板化處理方式，可以讓企業(yè)不同的團隊自助完成基礎(chǔ)設(shè)施的搭建，提高生產(chǎn)效率的同時，又保證了權(quán)限隔離，讓基礎(chǔ)設(shè)施受到保護。

Serverless Devs 支持多環(huán)境所面臨的挑戰(zhàn)

Serverless Devs [1]是一款面向 Serverless 應(yīng)用全生命周期的管理工具，其模型規(guī)范中存在應(yīng)用和服務(wù)的概念，但目前缺少對環(huán)境的內(nèi)在支持，代碼 基礎(chǔ)設(shè)施共同維護在一個 s.yaml 下。這種模式在多環(huán)境時的限制主要有3點：

1. 要為不同的環(huán)境維護不同的 s.yaml，維護成本比較高。更新環(huán)境時需要重新發(fā)起部署，對接 CI/CD 服務(wù)時就要重新發(fā)起一次完整的發(fā)布上線操作。（但通常情況下環(huán)境的變化，例如升降配、更新權(quán)限，對程序來說是安全的，不需要發(fā)起一次上線）；
2. 難以實現(xiàn)基礎(chǔ)設(shè)施團隊、平臺團隊、研發(fā)團隊分層協(xié)作的場景。比如阿里云函數(shù)計算的服務(wù)描述提供了日志、網(wǎng)絡(luò)、NAS、服務(wù)角色等平臺管理員視角的配置。收到客戶反饋，這些配置是干嘛的研發(fā)基本都不清楚，無疑減低了研發(fā)效率并增加了安全風險，經(jīng)常出現(xiàn)研發(fā)改錯配置導(dǎo)致線上服務(wù)有損的情況；
3. Serverless Devs 的資源操作主要由組件來實現(xiàn)，但對于一些資源的變更可能會引起實例重建或者不能提供服務(wù)（比如更改數(shù)據(jù)庫引擎、更換了FC的服務(wù)角色、更換VPC）的風險，組件開發(fā)者未必會清楚也可能會忽略，即使清楚也需要 Case By Case 的通過很多判斷代碼來解決，這無疑增加了組件開發(fā)的復(fù)雜度和使用成本；

如果采用本文前言章節(jié)中描述的分層的模板化方案，以上問題就可以順利解決：

1. 平臺團隊通過封裝環(huán)境模板，僅需對研發(fā)人員暴露安全的參數(shù)（比如實例規(guī)格），研發(fā)人員使用模板創(chuàng)建環(huán)境，填寫必要的參數(shù)即可完成基礎(chǔ)設(shè)施的搭建；通過更新環(huán)境即可自助化地完成基礎(chǔ)設(shè)施的升級，并且不需要重新發(fā)起代碼發(fā)布操作；
2. 平臺團隊在環(huán)境模板中聲明更加嚴格的訪問策略，拒絕某些有風險的資源操作，可以更好地控制爆炸半徑；

那么，接下來的問題就是：如何在 Serverless Devs 中定義環(huán)境模板？

當 Serverless Devs 遇見 Terraform

環(huán)境模板面向的是基礎(chǔ)設(shè)施，也就是云資源。Serverless Devs 離不開對云資源的操作，傳統(tǒng)的做法是在組件中直接使用云產(chǎn)品 SDK，但支持新資源時需要開發(fā)相應(yīng)的組件代碼，因此面臨著資源擴張帶來的開發(fā)效率降低以及代碼越來越難以維護的問題，更好的方式是通過基礎(chǔ)設(shè)施即代碼（IaC）來完成云資源的創(chuàng)建。

Serverless Devs 在之前的實踐中采用 Pulumi ，通過一個單獨組件完成對 Pulumi Stack 的封裝，但實踐下來發(fā)現(xiàn)，用 GPLs 來定義 IaC 還是需要模型層面良好的抽象，因此將 Pulumi 推廣到組件開發(fā)者，在生態(tài)成熟度以及靈活性上都不是太好。

目前 IaC 生態(tài)最強大的工具是 Terraform，已成為事實標準。Terraform HCL 本身是一種 DSL，任何生態(tài)都能很好地兼容，特別是 Provider 極其豐富。 阿里云的云產(chǎn)品如果對接 POP，能夠自動生成 Terraform 的 Provider，其可靠性和接入便捷程度已經(jīng)相當之高。

如果將環(huán)境模板的定義通過 Terraform IaC 來完成，并且在 Serverless Devs 的體系內(nèi)能夠良好地銜接，這樣可以極大拓寬用戶領(lǐng)域，用戶可以通過編寫 Terraform 文件來定義自己的基礎(chǔ)設(shè)施，用 Serverless Devs 完成所有工作流的串聯(lián)。

操作案例

遵循 Serverless Devs 的組件開發(fā)規(guī)范，將多環(huán)境的操作封裝成 env 命令，通過利用 s env 命令，可以實現(xiàn)如下的工作流：

1. 通過基礎(chǔ)設(shè)施即代碼（IaC）的能力定義可復(fù)用的環(huán)境模板
2. 基于模板構(gòu)建不同的測試、預(yù)發(fā)、生產(chǎn)等互相隔離的環(huán)境，并自動完成基礎(chǔ)設(shè)施的搭建
3. 將函數(shù)的同一份代碼部署到不同的環(huán)境上

下面我們通過一個實際案例演示整個操作流程。

假設(shè)業(yè)務(wù)場景需要：

• 在函數(shù)中讀寫OSS文件
• 日志文件寫入NAS，前端做實時展現(xiàn)
• 函數(shù)日志寫入SLS，做系統(tǒng)分析

作為平臺管理員，需要為研發(fā)：

• 創(chuàng)建 OSS Bucket，Bucket 名字研發(fā)可以自己指定，但是ACL策略必須是私有
• 創(chuàng)建 NAS 掛載點，涉及的VPC、VSwitch、NAS文件系統(tǒng)、訪問組、掛載點完全由管理員指定
• 創(chuàng)建SLS Project 、Logstore，名字研發(fā)可以自己指定，但是自動分裂、最大分裂數(shù)完全由管理員指定

01 平臺管理員：開發(fā)環(huán)境模板

環(huán)境模板采用 IaC 來定義資源，目前只支持 Terraform 類型的模板。環(huán)境模板的代碼目錄要包含兩類文件：

• IaC文件：即 Terraform 的 .tf 文件，IaC 文件的核心要素為：
• variable：定義模板的參數(shù)，用戶使用該模板創(chuàng)建環(huán)境時輸入?yún)?shù)的值
• resource：定義模板的資源，環(huán)境部署時完成資源的創(chuàng)建
• output：定義模板的輸出，環(huán)境部署成功后透出相應(yīng)輸出，可以被其他服務(wù)所訪問

• policy.json：RAM 的權(quán)限策略數(shù)組，支持自定義策略和系統(tǒng)策略，聲明了使用該模板創(chuàng)建資源所需要的權(quán)限，授信對象是 函數(shù)計算。部署環(huán)境時，函數(shù)計算會通過角色扮演的方式訪問模板中定義的資源。

編寫 IaC，定義環(huán)境模板的 variable、resource、output。

完整代碼示例：https://github.com/devsapp/fc/blob/main/examples/multi-envs/infra/main.tf

為上述資源定義權(quán)限策略，保持權(quán)限最小原則，僅放開必要的寫權(quán)限。由于 Terraform 在創(chuàng)建資源時會依賴很多資源的讀權(quán)限，因此推薦再增加 AliyunECSReadOnlyAccess、AliyunVPCReadOnlyAccess、AliyunNASReadOnlyAccess 這些常用的讀權(quán)限。

完整代碼示例：https://github.com/devsapp/fc/blob/main/examples/multi-envs/infra/policy.json

02 平臺管理員：發(fā)布環(huán)境模板

通過 s env apply-template 發(fā)布環(huán)境模板

s env apply-template –name testing –description 'it is a demo' –code ./infra

參數(shù)含義如下：

操作成功后，會返回當前模板的 varibale、outputs、狀態(tài)、 policy、文本內(nèi)容、版本 等信息。

03 研發(fā)：使用環(huán)境模板創(chuàng)建環(huán)境

環(huán)境需要操作對應(yīng)云資源的權(quán)限，授予函數(shù)計算以角色扮演的方式訪問的云資源，因此需要：

1. 創(chuàng)建普通的服務(wù)角色，授信服務(wù)選擇函數(shù)計算
2. 為該角色授予環(huán)境所需要的權(quán)限

通過 s env init 命令進入交互式操作，輸入環(huán)境名、地域、角色、環(huán)境模板以及模板參數(shù)，完成環(huán)境的部署：

執(zhí)行成功后，會在本地 .s 目錄下創(chuàng)建 env/fc-env-testing.yaml 描述文件，可以查看并編輯該文件。

04 研發(fā)：部署函數(shù)到指定環(huán)境

開發(fā)人員編寫s.yaml，并將基礎(chǔ)設(shè)施配置關(guān)聯(lián)到指定環(huán)境?？梢酝ㄟ^如下方式：

• 通過environment.outputs來關(guān)聯(lián)環(huán)境模板中定義的輸出
• FC 的服務(wù)往往和一個環(huán)境相映射，通常在創(chuàng)建服務(wù)時服務(wù)名要帶上環(huán)境的后綴，可以通過environment.name讓服務(wù)和環(huán)境自動關(guān)聯(lián)
• 指定環(huán)境時，無需在 props 中指定 region，組件會自動保證將服務(wù)部署到環(huán)境所在的 region

通過s deploy –env將函數(shù)部署到指定的環(huán)境中。

s deploy –env fc-env-testing

執(zhí)行指令后，組件會先判斷環(huán)境是否已經(jīng)部署，如果環(huán)境狀態(tài)為 ready ，則會將服務(wù)部署到該環(huán)境上； 否則會先部署環(huán)境，再部署服務(wù)。

總結(jié)

本文通過分析企業(yè)全面上云時，遇到的應(yīng)用和基礎(chǔ)設(shè)施管理的挑戰(zhàn)，提出采用分層的模板化方式來組織不同團隊的工作流，通過環(huán)境、服務(wù)、流水線來定義一個現(xiàn)代化的應(yīng)用，通過環(huán)境模板、服務(wù)模板、流水線模板來屏蔽基礎(chǔ)設(shè)施的復(fù)雜性并提升操作安全性，核心是需要一個管道來串聯(lián)整個工作流，讓 DevOps 的各個階段可以自助化并安全的完成。作者希望 Serverless Devs 可以充當這個管道，其應(yīng)用、組件、插件的思路為開發(fā)者提供了良好的構(gòu)建現(xiàn)代化應(yīng)用的基礎(chǔ)，并且 Serverless Devs 已經(jīng)具備了服務(wù)及服務(wù)模板的抽象，需要擴展的是環(huán)境、流水線的能力。

本文關(guān)注點是如何利用 Serverless Devs 管理多環(huán)境，分析了關(guān)鍵的挑戰(zhàn)是要解耦代碼和基礎(chǔ)設(shè)施，利用 IaC 來完成基礎(chǔ)設(shè)施的定義，而 IaC 生態(tài)下最適合引入的是 Terraform，因此選擇用 Terraform HCL 來定義環(huán)境模板，環(huán)境的資源編排通過后端的 Terraform 服務(wù)來完成。這樣就可以通過 Serverless Devs 來完成 "發(fā)布環(huán)境模板" -> "部署環(huán)境" -> "部署應(yīng)用到指定環(huán)境" 的完整工作流。

當然，要實現(xiàn)上述終態(tài)的愿景還有很長的路要走，未來規(guī)劃主要的 Roadmap 是：

• 持續(xù)打磨體驗，輸出更多開箱即用的模板
• 解決應(yīng)用運行時訪問環(huán)境的問題，比如在函數(shù)代碼中通過某種方式安全、高效地訪問環(huán)境的資源
• 輸出流水線模板、流水線的能力

本篇介紹了 Serverless Devs 多環(huán)境功能的使用，在下一篇中我會就一些常見問題，進行詳細解讀。

文中鏈接：

Serverless Devs：https://www.serverless-devs.com/

Pulumi：https://www.pulumi.com/

Terraform：https://www.terraform.io/

RAM:https://www.aliyun.com/product/ram?spm

阿里云函數(shù)計算（FC）：https://www.aliyun.com/product/fc?

原文鏈接：http://click.aliyun.com/m/1000347184/

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。