前言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

當(dāng) Serverless Devs 遇見(jiàn) Terraform

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

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

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

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

操作案例

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

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

下面我們通過(guò)一個(gè)實(shí)際案例演示整個(gè)操作流程。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

參數(shù)含義如下：

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

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

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

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

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

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

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

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

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

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

s deploy –env fc-env-testing

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

總結(jié)

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

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

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

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

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

文中鏈接：

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ù)計(jì)算（FC）：https://www.aliyun.com/product/fc?

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

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