CloudFormation與Terraform和CDK比較

– 10 分鐘閱讀

CloudFormation 作為 AWS 原生 IaC 工具，與 Terraform 的多雲支援能力形成對比。Terraform 仰賴各雲供應商的更新速度，而 CloudFormation 則能快速整合 AWS 最新服務。宣告式語法方面，CloudFormation 使用 JSON 或 YAML，而 Terraform 使用 HCL。CDK 則允許使用程式語言定義基礎設施，更易於測試和程式碼複用。傳統的宣告式 IaC 工具在測試上需要額外佈署環境，成本高且耗時。CDK 則可利用程式語言特性進行單元和整合測試，提升效率。

傳統的宣告式 IaC 工具（如 CloudFormation 和 Terraform）在定義基礎設施時，需要使用範本語言，例如 JSON 或 YAML。這些範本語言雖然易於閱讀和理解，但在處理複雜的基礎設施時，可能會變得冗長且難以維護。此外，測試這些範本也比較困難，通常需要實際佈署基礎設施才能驗證其正確性。CDK 的出現解決了這些問題。CDK 允許開發者使用熟悉的程式設計語言（如 TypeScript、Python 和 Java）來定義基礎設施，並利用程式語言的特性來簡化程式碼、提高可重用性和可測試性。CDK 還提供了一組高層次的抽象，使得開發者可以更輕鬆地管理和佈署複雜的基礎設施。

下一步：比較CloudFormation和Terraform

在繼續探索雲端自動化的旅程之前，我們需要比較兩個主要的競爭者——CloudFormation和Terraform——並瞭解它們之間的差異。學習這些將有助於您為特定的案例做出正確的選擇，無論是現在還是未來。

瞭解Terraform和CloudFormation之間的差異

首先，我們並不是要評估CloudFormation和Terraform哪個是市場上最好的IaC工具。我們的目標是找到適合特定用途和案例的工具。我們將比較以下功能：

  • 提供者支援
  • 宣告語法
  • 開發和佈署方法論

提供者支援

CloudFormation作為AWS的發明，原本只支援AWS作為服務提供者。Terraform則被開發為雲端無關的工具，能夠與各種雲端和服務提供者進行通訊，從而成為統治所有雲端的一體化工具。

  graph LR
    A[Terraform] --> B[AWS]
    A --> C[Azure]
    A --> D[GCP]
    E[CloudFormation] --> B

圖表翻譯：

此圖示展示了Terraform和CloudFormation對不同雲端服務提供者的支援情況。Terraform能夠支援多個雲端提供者，包括AWS、Azure和GCP，而CloudFormation則主要支援AWS。

內容深度解析

Terraform的成功在於其作為通用IaC工具的定位，使其能夠與多個雲端提供者進行互動。透過提供者（Provider）機制，Terraform能夠支援多種雲端服務。然而，這也意味著Terraform需要依賴這些提供者的開發速度，雲端提供者的工具將會第一時間支援最新的服務和API變更。

宣告語法

CloudFormation範本使用JSON或YAML編寫，取決於開發者的偏好。CloudFormation的宣告是一個鍵值區塊，其中鍵是資源的邏輯名稱，值是其屬性和屬性值。

MyResourceLogicalName:
  Type: AWS::Service::ResourceType
  Properties:
    PropertyA: some value
    PropertyB: some value
    # 諸如此類別

內容解密：

這段CloudFormation範本程式碼展示瞭如何宣告一個資源。MyResourceLogicalName是資源的邏輯名稱，Type指定了資源的型別，Properties則包含了資源的屬性。

Terraform則使用其自有的DSL（Domain-Specific Language）稱為HCL（HashiCorp Configuration Language）。HCL是一種類別似JSON的語言，並帶有一些語法糖。

resource "aws_vpc" "vpc" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_subnet" "subnet" {
  vpc_id     = aws_vpc.vpc.id
  cidr_block = "10.0.1.0/24"
}

內容解密：

這段Terraform程式碼展示瞭如何建立一個VPC和一個子網路。第一個資源區塊宣告了一個AWS VPC，CIDR區塊為10.0.0.0/16。第二個資源區塊宣告了一個子網路，指定了所屬VPC的ID和CIDR區塊。

深入理解雲端開發套件（Cloud Development Kit）的價值

在前面的章節中，我們探討了使用宣告式語言（如AWS CloudFormation和Terraform）來定義基礎設施即程式碼（IaC）。現在，讓我們來看看它們的潛在後繼者——雲端開發套件（CDK），以及它為IT行業帶來的變革和價值。

基礎設施測試的挑戰

測試一個電腦程式通常涉及構建它並執行一些預先編寫的測試場景。對於軟體來說，預期的行為是已知的，因此只需要驗證是否獲得了正確的結果。在第4章「持續整合和佈署」中，我們使用CloudFormation佈署了基礎設施並在其上執行特定的基礎設施測試。對於宣告式工具來說，這是目前為止唯一的測試方法。

# Terraform範例：建立VPC
resource "aws_vpc" "example" {
  cidr_block = "10.0.0.0/16"
}

#### 內容解密：
此段程式碼使用Terraform建立一個AWS VPC資源。其中`aws_vpc`是資源型別，`example`是邏輯名稱。`cidr_block`引數指定了VPC的IP範圍。這種宣告式語法使得基礎設施的定義更加直觀。

然而，為了測試宣告式工具，我們需要為測試建立獨立的基礎設施。這是一個耗時且在某些情況下非常昂貴的過程。有時，甚至是不可能的。主要原因是資源宣告的方式並不意味著服務提供者能夠處理這些資訊。例如，CloudFormation無法判斷我們是否為EC2例項提供了正確的AMI ID。同樣，Kubernetes也無法驗證Docker映像是否存在，當我們編寫Pod宣告時。

測試基礎設施的困難

  1. 資源宣告的不確定性：宣告式工具無法驗證資源宣告的正確性。
  2. 測試環境的建立：為測試建立獨立的基礎設施不僅耗時，而且昂貴。
  3. 測試結果的不確定性：測試結果取決於多種因素，包括資源組態和服務供應商的能力。

CDK如何改善基礎設施測試

雲端開發套件（CDK）透過允許開發者使用程式設計語言（如TypeScript、Python、Java等）定義基礎設施，從而帶來了多項改進。這種方法使得基礎設施的定義更加靈活，並且能夠利用現有的程式設計工具和實踐，包括單元測試和整合測試。

// CDK範例：使用TypeScript建立S3儲存桶
import * as cdk from 'aws-cdk-lib';
import * as s3 from 'aws-cdk-lib/aws-s3';

export class MyStack extends cdk.Stack {
  constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // 建立S3儲存桶
    new s3.Bucket(this, 'MyBucket', {
      versioned: true
    });
  }
}

#### 內容解密：
這段程式碼使用AWS CDK和TypeScript建立一個S3儲存桶。CDK允許開發者使用熟悉的程式設計語言定義雲端資源，從而提高開發效率和程式碼的可重用性。`s3.Bucket`類別被用來建立一個啟用版本控制的S3儲存桶。

CDK的優勢

  1. 程式設計語言的靈活性：開發者可以使用熟悉的程式設計語言定義基礎設施。
  2. 測試能力的增強：CDK支援單元測試和整合測試，使得基礎設施測試更加全面。
  3. 開發效率的提高：CDK透過提供高層次的抽象，簡化了基礎設施的定義和管理。

隨著雲端技術的不斷發展，IaC工具也在不斷演進。瞭解最新的工具和技術，如CDK，將幫助IT專業人員更好地應對未來的挑戰。無論是選擇傳統的宣告式工具還是最新的程式設計式工具，關鍵在於選擇最適合您組織需求的解決方案。

  graph LR;
    A[宣告式IaC工具] -->|演進| B[CDK];
    B --> C[增強測試能力];
    B --> D[提高開發效率];
    C --> E[單元測試];
    C --> F[整合測試];
    D --> G[程式設計語言靈活性];
    D --> H[高層次抽象];

圖表翻譯： 此圖表展示了從傳統的宣告式基礎設施即程式碼（IaC）工具到雲端開發套件（CDK）的演進過程。CDK透過提供程式設計語言的靈活性和高層次的抽象，不僅提高了開發效率，還增強了基礎設施的測試能力，包括單元測試和整合測試。

邁向未來：雲端基礎設施的新篇章

隨著科技的快速發展，雲端基礎設施的管理和佈署方式也在不斷演進。在本章中，我們將探討未來的發展趨勢，並深入瞭解 AWS Cloud Development Kit（CDK）如何革新基礎設施的建立和管理方式。

從過去到未來：基礎設施的演變

基礎設施即程式碼（Infrastructure as Code, IaC）已經成為現代雲端運算的重要組成部分。過去，我們使用宣告式範本來定義基礎設施的組態。然而，這種方法存在一定的侷限性，尤其是在大型專案和複雜的基礎設施中。

測試的重要性

在大型專案和基礎設施中，整合測試至關重要。我們不僅需要關注小規模的網路和機器組態，更需要考慮成百上千的運算、儲存、傳輸和分析資源。這些資源通常由不同的團隊開發和提供，因此，確保它們之間的協同工作變得至關重要。

CDK：以程式設計方式定義基礎設施

AWS CDK 提供了一種創新的方式來建立基礎設施。與傳統的宣告式範本不同，CDK 允許我們使用物件導向程式設計（OOP）正規化來撰寫基礎設施組態。每個資源都被定義為一個類別，這些類別之間存在著相互的關聯。例如，VPC 是一個類別，子網路是與 VPC 相關的另一個類別，而 RDS 資料函式庫子網路群組則與子網路相關聯。

import aws_cdk.aws_ec2 as ec2

# 建立 VPC
vpc = ec2.VPC(self, "MyVPC")

# 建立子網路
subnet = ec2.Subnet(self, "MySubnet", vpc_id=vpc.vpc_id)

# 建立 RDS 資料函式庫子網路群組
rds_subnet_group = ec2.SubnetGroup(self, "MyRDSSubnetGroup", subnet_ids=[subnet.subnet_id])

程式碼解讀：

  1. VPC 建立：我們使用 ec2.VPC 類別來建立一個新的 VPC。
  2. 子網路建立：透過 ec2.Subnet 類別，我們可以在 VPC 中建立子網路，並指定其所屬的 VPC ID。
  3. RDS 資料函式庫子網路群組建立：使用 ec2.SubnetGroup 類別，我們可以建立一個 RDS 資料函式庫子網路群組，並將之前建立的子網路納入其中。

這種程式設計方式使得我們能夠運用軟體工程的最佳實踐來進行複雜的測試，而無需花費大量成本在建立數十或數百個資源上進行測試。

結合應用程式與基礎設施

CDK 不僅僅是一個生成 CloudFormation 範本的框架，它還提供了許多抽象層，使得我們能夠將應用程式與基礎設施緊密結合。

新增構件（Artifacts）

在使用純粹的 CloudFormation 時，我們無法直接將應用程式構件新增到範本中。然而，CDK 提供了資產（Assets）的概念，允許我們將應用程式構件（如 Docker 映像檔）封裝並納入基礎設施中。

import aws_cdk.aws_ecs as ecs
from aws_cdk.aws_ecr_assets import DockerImageAsset

# 宣告資產物件，指定應用程式路徑
asset = DockerImageAsset(self, "MyImage", directory="/path/to/foo")

# 建立任務定義
td = ecs.FargateTaskDefinition(self, "MyTaskDefinition", memory_limit_mib=512, cpu=256)

# 新增容器至任務定義，使用資產中的映像檔
td.add_container("MyContainer", image=ecs.ContainerImage.from_ecr_repository(asset.repository, asset.image_uri))

程式碼解讀：

  1. 資產宣告：我們使用 DockerImageAsset 類別來宣告一個資產物件，指定應用程式的路徑。
  2. 任務定義建立：透過 ecs.FargateTaskDefinition 類別，我們建立了一個 Fargate 任務定義，並指定了記憶體限制和 CPU 資源。
  3. 容器新增：我們將容器新增至任務定義中，並使用資產中的 Docker 映像檔。

這種抽象使得我們能夠將應用程式與基礎設施作為一個整體進行管理，大大簡化了佈署流程。

參考資料

透過深入瞭解 CDK 和其相關技術，我們可以更好地把握未來的發展趨勢，並在雲端運算領域取得更大的成就。

AWS CloudFormation 深度解析與實務應用

第一章：CloudFormation 基礎與堆積疊操作

CloudFormation 是 AWS 提供的一種基礎設施即程式碼（Infrastructure as Code, IaC）服務，允許使用者透過範本定義和佈署 AWS 資源。本章將探討 CloudFormation 的核心概念和堆積疊操作。

1.1 建立堆積疊的流程

當呼叫 CreateStack 時，CloudFormation 會呼叫服務 API 來建立堆積疊資源。這個過程涉及以下步驟：

  1. 驗證範本：CloudFormation 會檢查範本的有效性，確保其符合 CloudFormation 的規範。
  2. 建立資源：根據範本中的定義，CloudFormation 會建立相應的 AWS 資源。
  3. 組態資源：CloudFormation 會根據範本中的組態，對資源進行初始化設定。
import boto3

cloudformation = boto3.client('cloudformation')

response = cloudformation.create_stack(
    StackName='my-stack',
    TemplateBody='file://path/to/template.yaml'
)

print(response)

#### 內容解密：

上述程式碼使用 boto3 函式庫建立了一個名為 my-stack 的 CloudFormation 堆積疊。TemplateBody 引數指定了範本檔案的路徑。CloudFormation 會根據範本定義建立相應的資源。

1.2 CloudFormation 服務角色

CloudFormation 服務角色是一種 IAM 角色，用於在執行堆積疊操作之前由 CloudFormation 承擔。該角色的策略將用於執行堆積疊操作。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "cloudformation:*",
            "Resource": "*"
        }
    ]
}

#### 內容解密：

上述 JSON 程式碼定義了一個 IAM 策略，允許 CloudFormation 執行所有操作。這個策略可以附加到 CloudFormation 服務角色上，以授權其執行堆積疊操作。

第二章：CloudFormation 進階功能

2.1 條件屬性

條件屬性允許使用者根據特定條件建立或更新資源。

Resources:
  MyResource:
    Type: 'AWS::EC2::Instance'
    Condition: MyCondition

#### 內容解密：

上述 YAML 程式碼定義了一個名為 MyResource 的 EC2 例項，並將其建立條件設定為 MyCondition。當 MyCondition 為真時，CloudFormation 會建立該資源。

2.2 內建函式

CloudFormation 提供了多種內建函式，用於處理範本中的值。

Resources:
  MyResource:
    Type: 'AWS::EC2::Instance'
    Properties:
      UserData: !Base64 { 'Fn::Sub': 'echo ${AWS::Region}' }

#### 內容解密：

上述 YAML 程式碼使用 !Base64 和 Fn::Sub 函式建立了一個 UserData 指令碼，該指令碼會輸出當前區域的名稱。

隨著雲端運算的快速發展，Infrastructure as Code (IaC) 變得越來越重要。未來，我們可以期待 CloudFormation 持續進化，提供更多強大的功能和更簡化的操作體驗。同時，使用者也需要不斷學習和適應新的技術，以充分利用 CloudFormation 的優勢。

字數統計：6,012 字

玄貓

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。