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

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

#01

什么是 IaC？

讓我們從解釋這個(gè)概念開始。基礎(chǔ)設(shè)施即代碼是一個(gè)涵蓋一系列實(shí)踐和工具的術(shù)語，旨在將應(yīng)用程序開發(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)用程序本身的一部分。一些常見的例子包括：服務(wù)器、配置、網(wǎng)絡(luò)、數(shù)據(jù)庫、存儲(chǔ)等等。在本文后面我們還會(huì)看到更多的例子。

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

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

性能：如果需要提供或更改大量基礎(chǔ)設(shè)施，IaC 將始終比人工手動(dòng)執(zhí)行相同操作更快。
可重復(fù)性：人類在可靠地重復(fù)執(zhí)行相同任務(wù)方面往往表現(xiàn)不佳。如果我們需要重復(fù)進(jìn)行一百次相同的操作，很可能會(huì)分心并在過程中出錯(cuò)。IaC 不會(huì)受到這個(gè)問題的影響。
文檔化：你的 IaC 可以作為你系統(tǒng)結(jié)構(gòu)的文檔。當(dāng)維護(hù)系統(tǒng)的團(tuán)隊(duì)規(guī)模擴(kuò)大時(shí)，這就變得至關(guān)重要了 —— 你不希望依賴于部落知識(shí)，或者只有少數(shù)幾個(gè)團(tuán)隊(duì)成員了解系統(tǒng)基礎(chǔ)設(shè)施的工作原理。最重要的是，與傳統(tǒng)文檔不同，這份文檔永遠(yuǎn)不會(huì)過時(shí)。
審計(jì)歷史：有了 IaC，由于你對(duì) IaC 的版本控制與你的應(yīng)用代碼相同（有時(shí)被稱為 GitOps），它為你提供了歷史記錄，你可以查看你的基礎(chǔ)設(shè)施是如何隨時(shí)間變化的，如果任何變化導(dǎo)致問題，有辦法回滾到一個(gè)安全點(diǎn)。
可測(cè)試性：IaC 可以像應(yīng)用程序代碼一樣進(jìn)行測(cè)試。你可以對(duì)其進(jìn)行單元測(cè)試、集成測(cè)試和端到端測(cè)試。

接下來，讓我們談?wù)?IaC 工具在實(shí)踐開始以來所經(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 中熟悉的概念：文件、來自 Apt 或 RPM 等軟件包管理器的 users、groups、permissions、init services 等等。

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

- hosts: app
tasks:
- name: Update apt-get
apt: update_cache=yes

- name: Install Apache
apt: name=apache2 state=present

- name: Install Libapache-mod-jk
apt: name=libapache2-mod-jk state=present

- name: Install Java
apt: name=default-jdk state=present

- name: Create Tomcat node directories
file: path=/etc/tomcat state=directory mode=0777
- file: path=/etc/tomcat/server state=directory mode=0775

- name: Download Tomcat 7 package
get_url: url=http://apache.mirror.digionline.de/tomcat/tomcat-7/v7.0.92/bin/apache-tomcat-7.0.92.tar.gz dest='/etc/tomcat'
- unarchive: src=/etc/tomcat/apache-tomcat-7.0.92.tar.gz dest=/etc/tomcat/server copy=no

- name: Configuring Mod-Jk & Apache
replace: dest=/etc/apache2/sites-enabled/000-default.conf regexp='^</VirtualHost>' replace="JkMount /status status \n JkMount /* loadbalancer \n JkMountCopy On \n </VirtualHost>"

- name: Download sample Tomcat application
get_url: url=https://tomcat.apache.org/tomcat-7.0-doc/appdev/sample/sample.war dest='/etc/tomcat/server/apache-tomcat-7.0.92/webapps' validate_certs=no

- name: Restart Apache
service: name=apache2 state=restarted

- name: Start Tomcat nodes
command: nohup /etc/tomcat/server/apache-tomcat-7.0.92/bin/catalina.sh start

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

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

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

#03

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

代表：CloudFormation、Terraform、Azure Resource Manager

2000 年代中期，云計(jì)算的引入是軟件開發(fā)史上的一個(gè)里程碑事件。在許多方面，我認(rèn)為我們?nèi)栽谏疃认鶐淼母锩杂绊憽?/p>

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

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

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

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

為了解決這個(gè)問題，像 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::Lambda::Function
Properties:
Code:
S3Bucket: my-source-bucket
S3Key: lambda/my-java-app.zip
Handler: example.Handler
Role: !GetAtt LambdaExecutionRole.Arn
Runtime: java17
Timeout: 60
MemorySize: 512
MyQueue:
Type: AWS::SQS::Queue
Properties:
VisibilityTimeout: 120
LambdaFunctionEventSourceMapping:
Type: AWS::Lambda::EventSourceMapping
Properties:
BatchSize: 10
Enabled: true
EventSourceArn: !GetAtt MyQueue.Arn
FunctionName: !GetAtt LambdaFunction.Arn
LambdaExecutionRole:
Type: AWS::IAM::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: arn:aws:logs:*:*:*
- PolicyName: allowSqs
PolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Action:
- sqs:ReceiveMessage
- sqs:DeleteMessage
- sqs:GetQueueAttributes
- sqs:ChangeMessageVisibility
Resource: !GetAtt MyQueue.Arn

這個(gè) CloudFormation 模板與我們之前看到的 Ansible playbook 差別很大。它并未提及任何文件、程序包或初始化服務(wù)；而是使用了托管服務(wù)的語言。我們配置的資源類型是AWS::Lambda::Function和AWS::SQS::Queue。我們并未定義這些服務(wù)將在何處運(yùn)行，也未定義如何配置這些主機(jī) —— 我們所關(guān)心的是，云供應(yīng)商所提供的托管服務(wù)能否被正確使用。
然而，它與 Ansible 的共同點(diǎn)在于其聲明性質(zhì)。我們不需要編寫對(duì) SQS API 的調(diào)用來創(chuàng)建一個(gè)隊(duì)列 —— 我們只需要聲明我們需要一個(gè)隊(duì)列，并將 VisibilityTimeout 屬性設(shè)置為 120，部署引擎（在這個(gè)例子中是 CloudFormation）會(huì)負(fù)責(zé)確定需要調(diào)用哪些 AWS API 來實(shí)現(xiàn)這個(gè)目標(biāo)。如果我們后來決定修改隊(duì)列（比如我們想將超時(shí)時(shí)間設(shè)為 240，而不是 120），或者完全刪除它，我們只需修改模板，引擎便會(huì)自動(dòng)找出需要的 API 調(diào)用來更新或者刪除隊(duì)列。

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

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

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

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

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

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

#04

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

代表：AWS CDK、Pulumi、SST

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

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

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

例如，讓我們看看相當(dāng)于上述 CloudFormation 模板的云開發(fā)工具包程序（在這個(gè)例子中我將使用 TypeScript，但任何其他 CDK 支持的語言看起來都非常相似）：
class LambdaStack extends cdk.Stack {
constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);

const func = new lambda.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,
});

const queue = new sqs.Queue(this, 'Queue', {
visibilityTimeout: cdk.Duration.minutes(2),
});

func.addEventSource(new lambda_events.SqsEventSource(queue));
}
}

const app = new cdk.App();
new LambdaStack(app, 'LambdaStack');

這個(gè) CDK 代碼的第一個(gè)有趣之處在于，它比其對(duì)應(yīng)的 CloudFormation 模板要短得多 —— 大約 20 行 TypeScript，而 YAML 大約有 60 行，所以大概是 3 比 1 的比例。這是一個(gè)非常簡(jiǎn)單的例子；當(dāng)你的基礎(chǔ)設(shè)施越來越復(fù)雜時(shí)，這個(gè)比例就會(huì)越來越大 —— 我見過有些情況下比例高達(dá) 30 比 1。
其次，CDK 代碼的級(jí)別比 CloudFormation 模板要高得多。請(qǐng)注意，如何從隊(duì)列中觸發(fā)函數(shù)的細(xì)節(jié)被 addEventSource() 方法和 SqsEventSource 類優(yōu)雅地封裝了起來。這兩個(gè) API 都是類型安全的 —— 你不能錯(cuò)誤地將一個(gè) SNS 主題傳遞給 SqsEventSource，因?yàn)榫幾g器不允許這樣。

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

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

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

#05

第四代：Infrastructure from Code

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

雖然第三代 IaC 工具是一個(gè)巨大的飛躍，使云計(jì)算更容易被使用（我在這里可能有偏見，因?yàn)槲沂?AWS 的 CDK 團(tuán)隊(duì)的前成員，但我認(rèn)為這種說法很接近事實(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ù)變得越來越難。我應(yīng)該在 AWS Lambda、AWS EKS 或 AWS AppRunner 上運(yùn)行我的容器嗎？我應(yīng)該使用 Google Cloud Functions 還是 Google Cloud Run？在什么情況下，這一個(gè)比那一個(gè)更適合？

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

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

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

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

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

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

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

Eventual

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

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

下面是一個(gè)簡(jiǎn)單的例子，顯示 Event、Subscription、Task、Workflow 和 API：
import { event, subscription, task, workflow, command } from "@eventual/core";

// define an Event
export interface HelloEvent {
message: string;
}
export const helloEvent = event<HelloEvent>("HelloEvent");

// get notified each time the event is emitted
export const onHelloEvent = subscription("onHelloEvent", {
events: [helloEvent],
}, async (event) => {
console.log("received event:", event);
});

// a Task that formats the received message
export const helloTask = task("helloTask", async (name: string) => {
return `hello ${name}`;
});

// an example Workflow that uses the above Task
export const helloWorkflow = workflow("helloWorkflow", async (name: string) => {
// call the Task to format the message
const message = await helloTask(name);

// emit an Event, passing it some data
await helloEvent.emit({
message,
});

return message;
});

// create a REST API for POST /hello <name>
export const hello = command("hello", async (name: string) => {
// trigger the above Workflow
const { executionId } = await helloWorkflow.startExecution({
input: name,
});

return { executionId };
});

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

Wing 通過引入執(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)行。

通過 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ù)器函數(shù)的例子，在 Wing 中看起來會(huì)是下面這樣的：
bring cloud;

let queue = new cloud.Queue(timeout: 2m);
let bucket = new cloud.Bucket();

queue.addConsumer(inflight (item: str): str => {
// get an item from the bucket with the name equal to the message
let object = bucket.get(item);
// do something with 'object'...
});

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

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

如果你想了解更多關(guān)于 Infrastructure from Code 的新趨勢(shì)，我推薦這篇來自 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)今軟件工程中最熱門的領(lǐng)域之一，甚至在一些產(chǎn)品中還將最新的人工智能進(jìn)展納入其中，比如 EventualAI 和 Pulumi Insights。

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