基礎(chǔ)設(shè)施即代碼（IaC）是軟件開(kāi)發(fā)中的一個(gè)令人著迷的領(lǐng)域。雖然作為一門(mén)學(xué)科它還相對(duì)年輕，但在其短暫的發(fā)展歷程中，它已經(jīng)經(jīng)歷了幾次具有劃時(shí)代意義的變化。我認(rèn)為，它是當(dāng)今軟件開(kāi)發(fā)創(chuàng)新中最熱門(mén)的領(lǐng)域之一，參與者很多，從大型科技公司到年輕的初創(chuàng)企業(yè)，都在創(chuàng)造新的方法，如果完全實(shí)現(xiàn)，有可能徹底改變我們編寫(xiě)和部署軟件的方式。

在本篇文章中，我想對(duì)IaC這一主題進(jìn)行深入探討：它是什么，它能帶來(lái)什么好處，它已經(jīng)經(jīng)歷了哪些具有顛覆性的轉(zhuǎn)變，以及未來(lái)可能會(huì)發(fā)生什么樣的變化。

#01

什么是 IaC？

讓我們從解釋這個(gè)概念開(kāi)始。基礎(chǔ)設(shè)施即代碼是一個(gè)涵蓋一系列實(shí)踐和工具的術(shù)語(yǔ)，旨在將應(yīng)用程序開(kāi)發(fā)中的嚴(yán)謹(jǐn)性和經(jīng)驗(yàn)應(yīng)用到基礎(chǔ)設(shè)施供應(yīng)和維護(hù)的領(lǐng)域。

這里的“基礎(chǔ)設(shè)施”是故意模糊的，但我們可以把它定義為在環(huán)境中運(yùn)行一個(gè)特定的應(yīng)用程序所需要的一切，但這并不是應(yīng)用程序本身的一部分。一些常見(jiàn)的例子包括：服務(wù)器、配置、網(wǎng)絡(luò)、數(shù)據(jù)庫(kù)、存儲(chǔ)等等。在本文后面我們還會(huì)看到更多的例子。

IaC的實(shí)踐與運(yùn)行時(shí)代碼的實(shí)踐相呼應(yīng)。這些實(shí)踐包括：使用源代碼控制進(jìn)行版本管理、自動(dòng)化測(cè)試、持續(xù)集成/持續(xù)交付（CI/CD）部署流程、快速反饋的本地開(kāi)發(fā)等。

遵循IaC的實(shí)踐可以帶來(lái)以下好處：

性能：如果需要提供或更改大量基礎(chǔ)設(shè)施，IaC 將始終比人工手動(dòng)執(zhí)行相同操作更快。

可重復(fù)性：人類(lèi)在可靠地重復(fù)執(zhí)行相同任務(wù)方面往往表現(xiàn)不佳。如果我們需要重復(fù)進(jìn)行一百次相同的操作，很可能會(huì)分心并在過(guò)程中出錯(cuò)。IaC 不會(huì)受到這個(gè)問(wèn)題的影響。

文檔化：你的 IaC 可以作為你系統(tǒng)結(jié)構(gòu)的文檔。當(dāng)維護(hù)系統(tǒng)的團(tuán)隊(duì)規(guī)模擴(kuò)大時(shí)，這就變得至關(guān)重要了 —— 你不希望依賴(lài)于部落知識(shí)，或者只有少數(shù)幾個(gè)團(tuán)隊(duì)成員了解系統(tǒng)基礎(chǔ)設(shè)施的工作原理。最重要的是，與傳統(tǒng)文檔不同，這份文檔永遠(yuǎn)不會(huì)過(guò)時(shí)。

審計(jì)歷史：有了 IaC，由于你對(duì)IaC的版本控制與你的應(yīng)用代碼相同（有時(shí)被稱(chēng)為 GitOps），它為你提供了歷史記錄，你可以查看你的基礎(chǔ)設(shè)施是如何隨時(shí)間變化的，如果任何變化導(dǎo)致問(wèn)題，有辦法回滾到一個(gè)安全點(diǎn)。

可測(cè)試性：IaC 可以像應(yīng)用程序代碼一樣進(jìn)行測(cè)試。你可以對(duì)其進(jìn)行單元測(cè)試、集成測(cè)試和端到端測(cè)試。

接下來(lái)，讓我們談?wù)?IaC 工具在實(shí)踐開(kāi)始以來(lái)所經(jīng)歷的主要階段。

#02

第一代：聲明式，主機(jī)配置

代表：Chef、Puppet、Ansible

第一代IaC工具都是關(guān)于主機(jī)配置的。這很有意義，因?yàn)檐浖到y(tǒng)的基礎(chǔ)設(shè)施，在其最低的抽象層次上，由單個(gè)機(jī)器組成。因此，這個(gè)領(lǐng)域的第一批工具集中在配置這些機(jī)器上。

這些工具管理的基礎(chǔ)設(shè)施資源是 Unix 中熟悉的概念：文件、來(lái)自 Apt 或 RPM 等軟件包管理器的 users、groups、permissions、init services 等等。

下面是一個(gè)創(chuàng)建 Java 服務(wù)的 Ansible playbook 例子：

-hosts:app tasks: -name:Updateapt-get apt:update_cache=yes -name:InstallApache apt:name=apache2state=present -name:InstallLibapache-mod-jk apt:name=libapache2-mod-jkstate=present -name:InstallJava apt:name=default-jdkstate=present -name:CreateTomcatnodedirectories file:path=/etc/tomcatstate=directorymode=0777 -file:path=/etc/tomcat/serverstate=directorymode=0775 -name:DownloadTomcat7package get_url:url=http://apache.mirror.digionline.de/tomcat/tomcat-7/v7.0.92/bin/apache-tomcat-7.0.92.tar.gzdest='/etc/tomcat' -unarchive:src=/etc/tomcat/apache-tomcat-7.0.92.tar.gzdest=/etc/tomcat/servercopy=no -name:ConfiguringMod-Jk&Apache replace:dest=/etc/apache2/sites-enabled/000-default.confregexp='^'replace="JkMount/statusstatus JkMount/*loadbalancer JkMountCopyOn " -name:DownloadsampleTomcatapplication get_url:url=https://tomcat.apache.org/tomcat-7.0-doc/appdev/sample/sample.wardest='/etc/tomcat/server/apache-tomcat-7.0.92/webapps'validate_certs=no -name:RestartApache service:name=apache2state=restarted -name:StartTomcatnodes command:nohup/etc/tomcat/server/apache-tomcat-7.0.92/bin/catalina.shstart

本操作手冊(cè)的抽象層次是一臺(tái)以 Linux 為操作系統(tǒng)的單一計(jì)算機(jī)。我們聲明我們想要安裝的 Apt 軟件包，我們想要?jiǎng)?chuàng)建的文件（創(chuàng)建它們的方式有多種：直接在給定的路徑下創(chuàng)建目錄，從給定的 URL 下載，從存檔中提取文件，或根據(jù)正則表達(dá)式替換編輯現(xiàn)有文件），我們想要運(yùn)行的系統(tǒng)服務(wù)或命令等等。 實(shí)際上，如果你稍微看一下，你會(huì)發(fā)現(xiàn)這個(gè) playbook 與 Bash 腳本非常相似。主要的區(qū)別是，playbook 是聲明式的—— 它描述了它希望發(fā)生的事情，比如在機(jī)器上安裝給定的 Apt 軟件包。這與腳本不同，腳本包含要執(zhí)行的命令。 雖然這個(gè)區(qū)別很小，但它很重要；它使 playbook 具有冪等性，這意味著，即使它在中間某個(gè)地方失敗了（也許 tomcat。apache。org 有暫時(shí)的故障，導(dǎo)致從它那里的下載失?。?，你可以重新啟動(dòng)它，之前成功執(zhí)行的步驟會(huì)識(shí)別到這一點(diǎn)，并在不做任何事情的情況下通過(guò)，這通常不是 Bash 腳本的情況。

現(xiàn)在，這些工具對(duì)于推進(jìn)軟件開(kāi)發(fā)行業(yè)的發(fā)展起著至關(guān)重要的作用，不可忽視。但是，它們只能在單個(gè)主機(jī)層面上運(yùn)行，這有巨大的局限性。這就意味著你不得不手動(dòng)管理這些主機(jī)，這在很大程度上抵消了IaC所帶來(lái)的好處，或者你需要將這些工具與能夠管理主機(jī)的其他工具結(jié)合使用，比如用于本地開(kāi)發(fā)的 Vagrant，或者用于管理共享環(huán)境（如生產(chǎn)環(huán)境）的 OpenStack。

舉個(gè)例子，如果你想創(chuàng)建一個(gè)經(jīng)典的三層架構(gòu)，你需要?jiǎng)?chuàng)建三種類(lèi)型的虛擬機(jī)，每種類(lèi)型的虛擬機(jī)都有自己的 Ansible playbook，根據(jù)它們?cè)诩軜?gòu)中的角色來(lái)配置這些主機(jī)。

IaC 工具的下一階段將擺脫這種限制。

#03

第二代：聲明式，云計(jì)算

代表：CloudFormation、Terraform、Azure Resource Manager

2000 年代中期，云計(jì)算的引入是軟件開(kāi)發(fā)史上的一個(gè)里程碑事件。在許多方面，我認(rèn)為我們?nèi)栽谏疃认鶐?lái)的革命性影響。

突然間，主機(jī)管理的諸多問(wèn)題得到了解決。你不需要運(yùn)行和操作你自己的 OpenStack 集群來(lái)自動(dòng)管理虛擬機(jī)；云供應(yīng)商將為你處理這一切。

但更重要的是，云計(jì)算立即提高了我們?cè)O(shè)計(jì)系統(tǒng)的抽象水平。不再只是給主機(jī)分配不同的角色那么簡(jiǎn)單。

如果你需要發(fā)布 - 訂閱資源，那么就沒(méi)有必要去配置一臺(tái)虛擬機(jī)，并在其上安裝 Apt 的 ZeroMQ 包；相反，你可以直接使用 Amazon SNS。如果你想存儲(chǔ)一些文件，你也不需要指定一堆主機(jī)作為你的存儲(chǔ)層；相反，你可以創(chuàng)建一個(gè) S3 存儲(chǔ)桶。諸如此類(lèi)，不一而足。

我們進(jìn)入了配置管理服務(wù)的階段，而不再是將主機(jī)配置置于首要位置。由于上一代的工具被設(shè)計(jì)成只在單個(gè)主機(jī)的層面上工作，因此我們需要一種全新的方法。

為了解決這個(gè)問(wèn)題，像 CloudFormation 和 Terraform 這樣的工具應(yīng)運(yùn)而生。它們和第一代工具一樣，都采用聲明式設(shè)計(jì)；但不同之處在于，它們操作的抽象層級(jí)不再是單一機(jī)器上的文件和軟件包，而是各種屬于不同托管服務(wù)的獨(dú)立資源，以及這些資源的屬性和它們之間的相互關(guān)系。

例如，這里有一個(gè) CloudFormation 模板，定義了一個(gè)由 SQS 隊(duì)列觸發(fā)的 AWS Lambda 函數(shù)：

AWSTemplateFormatVersion:2010-09-09 Resources: LambdaFunction: Type:AWS::Function Properties: Code: S3Bucket:my-source-bucket S3Key:lambda/my-java-app.zip Handler:example.Handler Role:!GetAttLambdaExecutionRole.Arn Runtime:java17 Timeout:60 MemorySize:512 MyQueue: Type:AWS::Queue Properties: VisibilityTimeout:120 LambdaFunctionEventSourceMapping: Type:AWS::EventSourceMapping Properties: BatchSize:10 Enabled:true EventSourceArn:!GetAttMyQueue.Arn FunctionName:!GetAttLambdaFunction.Arn LambdaExecutionRole: Type:AWS::Role Properties: AssumeRolePolicyDocument: Version:'2012-10-17' Statement: -Effect:Allow Principal: Service: -lambda.amazonaws.com Action: -sts:AssumeRole Policies: -PolicyName:allowLambdaLogs PolicyDocument: Version:'2012-10-17' Statement: -Effect:Allow Action: -logs:* Resource:arnlogs*:* -PolicyName:allowSqs PolicyDocument: Version:'2012-10-17' Statement: -Effect:Allow Action: -sqs:ReceiveMessage -sqs:DeleteMessage -sqs:GetQueueAttributes -sqs:ChangeMessageVisibility Resource:!GetAttMyQueue.Arn

這個(gè) CloudFormation 模板與我們之前看到的 Ansible playbook 差別很大。它并未提及任何文件、程序包或初始化服務(wù)；而是使用了托管服務(wù)的語(yǔ)言。我們配置的資源類(lèi)型是AWS::Function和AWS::Queue。我們并未定義這些服務(wù)將在何處運(yùn)行，也未定義如何配置這些主機(jī) ——我們所關(guān)心的是，云供應(yīng)商所提供的托管服務(wù)能否被正確使用。

然而，它與 Ansible 的共同點(diǎn)在于其聲明性質(zhì)。我們不需要編寫(xiě)對(duì) SQS API 的調(diào)用來(lái)創(chuàng)建一個(gè)隊(duì)列 —— 我們只需要聲明我們需要一個(gè)隊(duì)列，并將 VisibilityTimeout 屬性設(shè)置為 120，部署引擎（在這個(gè)例子中是 CloudFormation）會(huì)負(fù)責(zé)確定需要調(diào)用哪些 AWS API 來(lái)實(shí)現(xiàn)這個(gè)目標(biāo)。如果我們后來(lái)決定修改隊(duì)列（比如我們想將超時(shí)時(shí)間設(shè)為 240，而不是 120），或者完全刪除它，我們只需修改模板，引擎便會(huì)自動(dòng)找出需要的 API 調(diào)用來(lái)更新或者刪除隊(duì)列。

這些工具是 IaC 發(fā)展過(guò)程中的一個(gè)巨大的里程碑，這大大提升了前一代的抽象水平。然而，它們也存在一些缺陷。

第一個(gè)問(wèn)題是，為了實(shí)現(xiàn)其聲明性質(zhì)，這些工具使用了自定義的 DSL（領(lǐng)域特定語(yǔ)言），例如，在 CloudFormation 中，這種語(yǔ)言可能是 JSON 或 YAML 格式。這就意味著所有的通用編程語(yǔ)言功能，比如變量、函數(shù)、循環(huán)、if 語(yǔ)句、類(lèi)等，在這種 DSL 中都無(wú)法使用。因此，沒(méi)有簡(jiǎn)單的辦法來(lái)減少重復(fù)代碼。

舉個(gè)例子，如果我們想要在我們的應(yīng)用中配置不止一個(gè)，而是三個(gè)具有相同設(shè)置的隊(duì)列，我們無(wú)法簡(jiǎn)單地編寫(xiě)一個(gè)循環(huán)來(lái)執(zhí)行三次；我們必須把相同的定義復(fù)制和粘貼三次，這并不理想。同時(shí)，這也意味著我們無(wú)法將模板劃分為邏輯單元；我們無(wú)法將一部分資源指定為存儲(chǔ)層，另一部分資源指定為前端層等。所有的資源都屬于一個(gè)扁平的命名空間。

這些工具的另一個(gè)問(wèn)題是，雖然它們肯定比第一代的主機(jī)配置更高級(jí)，但它們?nèi)匀恍枰阍敿?xì)指定在系統(tǒng)中使用的所有資源的所有細(xì)節(jié)。例如，你可能已經(jīng)注意到，在上面的模板示例中，除了我們主要關(guān)注的 Lambda 和 SQS 資源，我們還有事件映射和 IAM 資源。這是連接 SQS 和 Lambda 所需的 “粘合劑”，而正確配置這些“粘合劑”資源并非易事。

舉例來(lái)說(shuō)，你需要向執(zhí)行函數(shù)的 IAM 角色授予一組非常特定的權(quán)限（sqs:ReceiveMessage、sqs:DeleteMessage、sqs:GetQueueAttributes 和 sqs:ChangeMessageVisibility），才能成功地從特定隊(duì)列觸發(fā)它。

從某種程度上來(lái)說(shuō)，這是一個(gè)非常低級(jí)的問(wèn)題；然而，由于 DSL 中缺乏抽象工具，我們實(shí)際上沒(méi)有任何工具可以隱藏這些實(shí)現(xiàn)細(xì)節(jié)。所以，每次你需要?jiǎng)?chuàng)建一個(gè)由 SQS 隊(duì)列觸發(fā)的新 Lambda 函數(shù)，你別無(wú)選擇，只能復(fù)制包含這四個(gè)權(quán)限的代碼段。因此，這些模板往往會(huì)很快變得冗長(zhǎng)，并包含大量重復(fù)內(nèi)容。

#04

第三代：命令式，云計(jì)算

代表：AWS CDK、Pulumi、SST

例如，讓我們看看相當(dāng)于上述 CloudFormation 模板的云開(kāi)發(fā)工具包程序（在這個(gè)例子中我將使用 TypeScript，但任何其他 CDK 支持的語(yǔ)言看起來(lái)都非常相似）：

第二代工具的所有缺陷都可以追溯到它們使用了一種自定義的 DSL，這種語(yǔ)言缺乏我們?cè)谑褂猛ㄓ镁幊陶Z(yǔ)言時(shí)習(xí)慣的抽象工具，如變量、函數(shù)、循環(huán)、類(lèi)、方法等。

因此，第三代IaC工具的主要思想非常簡(jiǎn)單：如果通用編程語(yǔ)言已經(jīng)具備了這些功能，那么我們?yōu)槭裁床皇褂盟鼈儊?lái)定義基礎(chǔ)設(shè)施，而要使用自定義的 JSON 或 YAML DSL？

例如，讓我們看看相當(dāng)于上述 CloudFormation 模板的云開(kāi)發(fā)工具包程序（在這個(gè)例子中我將使用 TypeScript，但任何其他 CDK 支持的語(yǔ)言看起來(lái)都非常相似）：

classLambdaStackextendscdk.Stack{ constructor(scope:cdk.Construct,id:string,props?:cdk.StackProps){ super(scope,id,props); constfunc=newlambda.Function(this,'Function',{ code:lambda.Code.fromBucket( s3.Bucket.fromBucketName(this,'CodeBucket','my-source-bucket'), 'lambda/my-java-app.zip'), handler:'example.Handler', runtime:lambda.Runtime.JAVA_17, }); constqueue=newsqs.Queue(this,'Queue',{ visibilityTimeout:cdk.Duration.minutes(2), }); func.addEventSource(newlambda_events.SqsEventSource(queue)); } } constapp=newcdk.App(); newLambdaStack(app,'LambdaStack');

這個(gè) CDK 代碼的第一個(gè)有趣之處在于，它比其對(duì)應(yīng)的 CloudFormation 模板要短得多 —— 大約 20 行 TypeScript，而 YAML 大約有 60 行，所以大概是 3 比 1 的比例。這是一個(gè)非常簡(jiǎn)單的例子；當(dāng)你的基礎(chǔ)設(shè)施越來(lái)越復(fù)雜時(shí)，這個(gè)比例就會(huì)越來(lái)越大 —— 我見(jiàn)過(guò)有些情況下比例高達(dá) 30 比 1。

其次，CDK 代碼的級(jí)別比 CloudFormation 模板要高得多。請(qǐng)注意，如何從隊(duì)列中觸發(fā)函數(shù)的細(xì)節(jié)被 addEventSource() 方法和 SqsEventSource 類(lèi)優(yōu)雅地封裝了起來(lái)。這兩個(gè) API 都是類(lèi)型安全的 —— 你不能錯(cuò)誤地將一個(gè) SNS 主題傳遞給 SqsEventSource，因?yàn)榫幾g器不允許這樣。

還請(qǐng)注意，我們不必在代碼中的任何地方提到 IAM —— CDK 為我們處理了所有這些細(xì)節(jié)，所以我們不必知道需要哪 4 個(gè)確切的權(quán)限來(lái)允許一個(gè)函數(shù)被隊(duì)列觸發(fā)。

所有這些都是因?yàn)?strong>高級(jí)編程語(yǔ)言允許我們構(gòu)建抽象概念。我可以把一段重復(fù)的或復(fù)雜的代碼，放在一個(gè)類(lèi)或函數(shù)中，并為我的項(xiàng)目提供一個(gè)干凈、簡(jiǎn)單的 API，這個(gè) API 巧妙地封裝了所有混亂的實(shí)現(xiàn)細(xì)節(jié)，就像 CDK 團(tuán)隊(duì)創(chuàng)建和維護(hù)的 SqsEventSource 類(lèi)那樣。

如果這是其他項(xiàng)目可能受益的東西，我可以把我的抽象概念打包成它所使用的編程語(yǔ)言的庫(kù)，并通過(guò)我的語(yǔ)言的包管理器分發(fā)出去，比如 JavaScript/TypeScript 的 npmjs.com，或 Java 的 Maven Central，這樣其他人就可以依賴(lài)它，就像我們分發(fā)應(yīng)用程序代碼的庫(kù)一樣。我甚至可以把它添加到 constructs.dev 的可用開(kāi)源 CDK 庫(kù)目錄中，這樣就更容易找到它。

#05

第四代：Infrastructure from Code

代表：Wing、Dark、Eventual、Ampt、Klotho

雖然第三代 IaC 工具是一個(gè)巨大的飛躍，使云計(jì)算更容易被使用（我在這里可能有偏見(jiàn)，因?yàn)槲沂?AWS 的 CDK 團(tuán)隊(duì)的前成員，但我認(rèn)為這種說(shuō)法很接近事實(shí)），但它們?nèi)匀挥懈倪M(jìn)的空間。

他們的第一個(gè)缺點(diǎn)是，它們?cè)诤艽蟪潭壬鲜窃趩蝹€(gè)云服務(wù)的層面上運(yùn)作的。因此，雖然他們使使用 Lambda 或 SQS 變得很容易，但你仍然需要知道這些服務(wù)是什么，以及為什么你會(huì)考慮使用它們。

現(xiàn)在是云計(jì)算時(shí)代，我們已經(jīng)看到每個(gè)供應(yīng)商提供的服務(wù)數(shù)量激增。僅 AWS 就有 200 多種。在如此多樣化的選擇中，選擇適合自己要求的服務(wù)變得越來(lái)越難。我應(yīng)該在 AWS Lambda、AWS EKS 或 AWS AppRunner 上運(yùn)行我的容器嗎？我應(yīng)該使用 Google Cloud Functions 還是 Google Cloud Run？在什么情況下，這一個(gè)比那一個(gè)更適合？

大多數(shù)開(kāi)發(fā)人員對(duì)每個(gè)云計(jì)算供應(yīng)商的產(chǎn)品沒(méi)有特別詳細(xì)的了解，特別是由于這些產(chǎn)品往往經(jīng)常變化，新的服務(wù)（或現(xiàn)有服務(wù)的新功能）不斷推出，舊的服務(wù)被淘汰。但他們確實(shí)對(duì)系統(tǒng)設(shè)計(jì)的基本原理有很好的理解。

因此，他們知道他們需要一個(gè)無(wú)狀態(tài)的 HTTP 服務(wù)，在負(fù)載均衡器后面進(jìn)行水平擴(kuò)展，一個(gè) NoSQL 文檔存儲(chǔ)，一個(gè)緩存層，一個(gè)靜態(tài)網(wǎng)站前端，等等。第三代的工具對(duì)他們來(lái)說(shuō)太低級(jí)了；理想情況下，他們希望用這些高級(jí)別的系統(tǒng)架構(gòu)術(shù)語(yǔ)來(lái)描述他們的基礎(chǔ)設(shè)施，然后將如何在給定的云供應(yīng)商上最好地實(shí)現(xiàn)這種架構(gòu)的細(xì)節(jié)委托給他們的 IaC 工具。

第三代工具的第二個(gè)缺點(diǎn)是，它們將IaC與應(yīng)用程序代碼完全分開(kāi)。例如，在上面的 CDK 的例子中，Lambda 函數(shù)的代碼與它的基礎(chǔ)設(shè)施定義完全脫節(jié)。而且，雖然 CDK 有資產(chǎn)的概念，允許這兩種類(lèi)型的代碼在同一個(gè)版本控制倉(cāng)庫(kù)中存在，但它們?nèi)匀徊荒芟嗷?duì)接。從某種意義上說(shuō)，這就是重復(fù) —— 我的應(yīng)用程序代碼使用了 SQS 隊(duì)列，這對(duì)我的IaC提出了一個(gè)隱含的要求，即正確配置該隊(duì)列。

但是，就像所有的重復(fù)和隱含要求一樣，當(dāng)雙方意外地不同步時(shí)（例如，如果我從我的基礎(chǔ)設(shè)施代碼中刪除了隊(duì)列，但忘記更新我的應(yīng)用程序代碼以不再使用它），這可能會(huì)導(dǎo)致問(wèn)題，而且在我部署我的更改之前，我的語(yǔ)言的編譯器并不能幫助我捕獲這些錯(cuò)誤，可能會(huì)引發(fā)問(wèn)題。

第四代 IaC 工具的目標(biāo)是解決上述兩個(gè)問(wèn)題。它們的主要理念是，在云計(jì)算時(shí)代，基礎(chǔ)設(shè)施代碼和應(yīng)用程序代碼之間的區(qū)別已經(jīng)變得沒(méi)有太大意義。因?yàn)閮烧叨荚谑褂猛泄芊?wù)的語(yǔ)言，我在應(yīng)用程序代碼中想使用的任何資源，都需要在我的基礎(chǔ)設(shè)施代碼中存在，就像我們?cè)?Lambda 和 SQS 的例子中看到的一樣。

因此，這些工具將兩者統(tǒng)一起來(lái)。它們不再是獨(dú)立的基礎(chǔ)設(shè)施和應(yīng)用程序代碼，而是消除了前者，只保留了應(yīng)用程序代碼，而基礎(chǔ)設(shè)施則完全來(lái)自應(yīng)用程序代碼。由于這個(gè)原因，這種方法被稱(chēng)為 Infrastructure from Code，而不是 Infrastructure as Code。

讓我們來(lái)看看 IfC 工具的兩個(gè)例子。

Eventual

第一個(gè)是 Eventual，一個(gè) TypeScript 庫(kù)，它定義了現(xiàn)代云應(yīng)用的幾個(gè)通用構(gòu)建模塊：Service、API、Workflow、Task、Event 以及其他一些東西。你可以從這些通用構(gòu)件中創(chuàng)建一個(gè)任意復(fù)雜的應(yīng)用程序，把它們組合在一起，就像樂(lè)高積木一樣。

Eventual 部署引擎知道如何將這些構(gòu)建模塊轉(zhuǎn)換為 AWS 資源，如 Lambda 函數(shù)、API 網(wǎng)關(guān)、StepFunction 狀態(tài)機(jī)、EventBridge 規(guī)則等。這種轉(zhuǎn)換的細(xì)節(jié)被庫(kù)的抽象所隱藏，因此，作為它的用戶(hù)，你無(wú)需關(guān)心這些細(xì)節(jié) —— 你只需使用所提供的構(gòu)件模塊，部署由庫(kù)處理。

下面是一個(gè)簡(jiǎn)單的例子，顯示 Event、Subscription、Task、Workflow 和 API：

import{event,subscription,task,workflow,command}from"@eventual/core"; //defineanEvent exportinterfaceHelloEvent{ message:string; } exportconsthelloEvent=event("HelloEvent"); //getnotifiedeachtimetheeventisemitted exportconstonHelloEvent=subscription("onHelloEvent",{ events:[helloEvent], },async(event)=>{ console.log("receivedevent:",event); }); //aTaskthatformatsthereceivedmessage exportconsthelloTask=task("helloTask",async(name:string)=>{ return`hello${name}`; }); //anexampleWorkflowthatusestheaboveTask exportconsthelloWorkflow=workflow("helloWorkflow",async(name:string)=>{ //calltheTasktoformatthemessage constmessage=awaithelloTask(name); //emitanEvent,passingitsomedata awaithelloEvent.emit({ message, }); returnmessage; }); //createaRESTAPIforPOST/hello exportconsthello=command("hello",async(name:string)=>{ //triggertheaboveWorkflow const{executionId}=awaithelloWorkflow.startExecution({ input:name, }); return{executionId}; });

Wing

另一種方法是創(chuàng)建一個(gè)全新的通用編程語(yǔ)言，該語(yǔ)言不僅僅在單臺(tái)機(jī)器上執(zhí)行，而是從一開(kāi)始就設(shè)計(jì)成在云上分布式運(yùn)行。Wing 就是由 Monada 公司創(chuàng)建的一種這樣的語(yǔ)言，該公司的聯(lián)合創(chuàng)始人是 AWS CDK 的創(chuàng)建者 Elad Ben-Israel。

Wing 通過(guò)引入執(zhí)行階段的概念成功地將基礎(chǔ)設(shè)施代碼和應(yīng)用程序代碼合并在一起。默認(rèn)情況下，Preflight 對(duì)應(yīng)于 “構(gòu)建時(shí)間”，在這個(gè)階段執(zhí)行基礎(chǔ)設(shè)施代碼；Inflight 對(duì)應(yīng)于“運(yùn)行時(shí)間”，應(yīng)用程序代碼在云上運(yùn)行。

通過(guò) Wing 編譯器實(shí)現(xiàn)的復(fù)雜的引用機(jī)制，Inflight 代碼可以使用 Preflight 代碼中定義的對(duì)象。然而，Inflight 階段不能創(chuàng)建新的 Preflight 對(duì)象，只能使用這些對(duì)象明確標(biāo)有修飾符的特定 API Inflight。Wing 編譯器會(huì)確保你的程序遵守這些規(guī)則，所以如果你試圖破壞這些規(guī)則，它就會(huì)編譯失敗，并為你快速提供關(guān)于應(yīng)用程序正確性的反饋。

因此，我們上面看到的那個(gè)由隊(duì)列觸發(fā)的無(wú)服務(wù)器函數(shù)的例子，在 Wing 中看起來(lái)會(huì)是下面這樣的：

bringcloud; letqueue=newcloud.Queue(timeout:2m); letbucket=newcloud.Bucket(); queue.addConsumer(inflight(item:str):str=>{ //getanitemfromthebucketwiththenameequaltothemessage letobject=bucket.get(item); //dosomethingwith'object'... });

這段代碼相當(dāng)高級(jí) —— 我們甚至沒(méi)有在任何地方明確提到無(wú)服務(wù)器函數(shù)資源，我們只是在一個(gè)匿名函數(shù)中寫(xiě)了我們的應(yīng)用代碼，用 Inflight 修改器進(jìn)行了注釋。該匿名函數(shù)被部署在無(wú)服務(wù)器函數(shù)中，并在云上執(zhí)行（或在 Wing 附帶的本地模擬器中執(zhí)行，以提供快速開(kāi)發(fā)體驗(yàn)）。

還要注意的是，我們不能在應(yīng)用代碼中錯(cuò)誤地使用錯(cuò)誤的資源。例如，錯(cuò)誤地使用 SNS 主題而不是 SQS 隊(duì)列，因?yàn)樵?Preflight 的代碼中沒(méi)有定義 Topic 對(duì)象，所以我們沒(méi)有辦法在 Inflight 的代碼中引用它。同樣，你也不能在 Preflight 的代碼中使用 bucket.get() 方法，因?yàn)槟鞘且粋€(gè) Inflight 的專(zhuān)用 API。這樣一來(lái)，語(yǔ)言本身就可以防止我們犯很多錯(cuò)誤，如果基礎(chǔ)設(shè)施和應(yīng)用代碼是分開(kāi)的，這些錯(cuò)誤就不會(huì)被發(fā)現(xiàn)。

如果你想了解更多關(guān)于 Infrastructure from Code 的新趨勢(shì)，我推薦這篇來(lái)自 Ala Shiban 的文章，他是這個(gè)領(lǐng)域另一個(gè)工具 Klotho 的聯(lián)合創(chuàng)始人。

https://klo.dev/state-of-infrastructure-from-code-2023

#06

總結(jié)

這就是 IaC 領(lǐng)域的歷史和最新發(fā)展。我認(rèn)為這值得密切關(guān)注，因?yàn)樗钱?dāng)今軟件工程中最熱門(mén)的領(lǐng)域之一，甚至在一些產(chǎn)品中還將最新的人工智能進(jìn)展納入其中，比如 EventualAI 和 Pulumi Insights。

我相信，在不久的將來(lái)，這個(gè)領(lǐng)域?qū)?huì)涌現(xiàn)出許多新的方法，這些方法將對(duì)我們編寫(xiě)和發(fā)布軟件的方式產(chǎn)生深遠(yuǎn)的影響。