基礎設施即代碼：自動化管理的聲明式與程式碼實踐

– 8 分鐘閱讀

隨著雲端運算與 DevOps 文化的普及，傳統手動配置已無法滿足企業對速度與一致性的要求。基礎設施即代碼（IaC）將系統架構的定義轉化為可維護的程式碼資產，不僅降低人為錯誤風險，更能無縫整合至 CI/CD 管道。此實踐賦予團隊更大的自主權，能夠建立自助式、可拋棄的開發環境，從而加速創新週期並優化企業的總體擁有成本，成為現代化 IT 管理的核心策略。

基礎設施即代碼 (IaC)：實現自動化、標準化與高效基礎設施管理

本章節深入探討基礎設施即代碼 (IaC) 的核心概念、實踐原則與關鍵優勢。闡述 IaC 如何透過將基礎設施的配置與部署轉化為可編寫的代碼，實現自動化、可重複、一致且版本化的基礎設施管理。內容將涵蓋 IaC 的發展背景、為企業帶來的顯著效益，並介紹不同類型的 IaC 語言與工具，包括指令碼 (Scripting) 和聲明式 (Declarative) 語言，為讀者建立現代化、高效能的基礎設施管理框架提供理論基礎與實務指引。

CI/CD 流程是 DevOps 文化不可或缺的一部分。CI 幫助團隊整合程式碼並驗證其一致性，定期獲得快速反饋。CD 則能自動將應用程式部署到一個或多個預備環境，從而能夠測試整個應用程式，直至部署到生產環境。最終，持續部署進一步自動化了從程式碼提交到生產環境部署的整個過程。

理解 IaC 實踐

基礎設施即代碼 (Infrastructure as Code, IaC) 是一種將構成基礎設施的資源配置寫入程式碼的實踐。這項實踐隨著 DevOps 文化的興起以及雲端基礎設施的現代化而逐漸普及。傳統上，營運團隊手動部署基礎設施，這不僅耗時，且因處理方式不一致而容易出錯。隨著雲端現代化及其可擴展性的發展，基礎設施的構建方式需要審視其配置和變更實踐。

IaC 是指將基礎設施組件的配置和部署步驟寫入程式碼的過程，這有助於以可重複且一致的方式自動化其部署。在深入探討 IaC 的具體應用之前，我們將先了解這項實踐所帶來的益處。

IaC 的優勢

IaC 為基礎設施管理帶來了多方面的顯著優勢：

  • 標準化配置，降低錯誤風險: 透過程式碼定義基礎設施，確保了配置的一致性，從而顯著降低了人為錯誤的可能性。
  • 版本控制與追蹤: 描述基礎設施的程式碼可以進行版本控制，並儲存在源碼管理器中，便於追蹤變更歷史、回滾到先前版本，並進行協同作業。
  • 整合至 CI/CD 管道: IaC 程式碼可以像應用程式程式碼一樣，納入 CI/CD 管道進行自動化測試和部署，實現基礎設施的自動化配置與更新。
  • 加速部署，提升效率: 基礎設施變更的部署過程更加快速和高效，減少了手動操作的時間和複雜性。
  • 優化管理、控制與成本: 實現對基礎設施的更好管理和控制，並有助於降低基礎設施的總體擁有成本 (TCO)。

IaC 還能為 DevOps 團隊帶來額外好處：團隊成員不再需要花費大量時間在手動配置上，而是可以專注於開發新功能。這也賦予了開發團隊升級其基礎設施並進行變更的能力，而無需額外請求營運資源。此外，IaC 還能創建自助式、臨時性的環境，為開發者和測試人員提供更大的靈活性，以便他們能夠獨立於其他環境，在隔離的狀態下測試新功能。

IaC 的語言與工具類型

用於編寫基礎設施配置的語言和工具類型多樣，主要可分為指令碼 (Scripting) 和聲明式 (Declarative) 兩種類型。

  • 指令碼類型 (Scripting Types): 這類工具包括 Bash、PowerShell 等指令碼語言，或是利用雲端供應商提供的不同客戶端（SDK）進行編寫。例如，可以使用 Azure CLI 或 Azure PowerShell 來編寫 Azure 基礎設施的配置指令碼。

    • Azure CLI 範例: 以下是使用 Azure CLI 創建資源群組的命令： az group create --location westeurope --resource-group MyAppResourcegroup

    • Azure PowerShell 範例: 以下是使用 Azure PowerShell 創建資源群組的命令： New-AzResourceGroup -Name MyAppResourcegroup -Location westeurope

    這類語言和工具的主要問題在於需要大量的程式碼行。這是因為需要管理被操作資源的不同狀態，並且必須編寫創建或更新所需基礎設施的所有步驟。然而，對於自動化執行重複性任務（如對資源列表進行選擇和查詢），或需要對基礎設施資源執行複雜處理（如刪除帶有特定標籤的虛擬機器）的指令碼，這類工具仍然非常有用。

  • 聲明式類型 (Declarative Types): 這類語言的特點是，您只需編寫所需系統或基礎設施的最終狀態，而無需詳細說明實現該狀態的步驟。Terraform 和 Vagrant（來自 HashiCorp）、Ansible，以及 Azure 的 ARM 模板和 Azure Bicep 都屬於此類。

    • Terraform: 一款流行的開源基礎設施即代碼工具，使用自定義的聲明式語言 HCL (HashiCorp Configuration Language) 來定義基礎設施。
    • Ansible: 一款開源自動化工具，雖然也可以用於配置管理，但其劇本 (Playbooks) 也可以用聲明式的方式來描述期望的系統狀態。
    • Azure ARM 模板 (Azure Resource Manager Templates): 使用 JSON 格式定義 Azure 資源的聲明式模板。
    • Azure Bicep: 一種領域特定語言 (DSL)，旨在簡化 ARM 模板的編寫，提供更簡潔的語法。

    聲明式語言的優勢在於，使用者只需專注於定義「期望的結果」，而工具本身會負責計算並執行實現該結果所需的步驟，大大簡化了基礎設施的配置和管理。

IaC 語言與工具：從聲明式到程式碼的演進

本節深入探討基礎設施即代碼 (IaC) 的不同語言與工具類型，包括指令碼、聲明式以及程式碼式。透過具體的 Terraform 和 Ansible 範例，展示聲明式語言如何簡化基礎設施的定義與管理。隨後，介紹程式碼式 IaC 工具（如 Pulumi 和 Terraform CDK）的興起，及其如何讓開發者利用熟悉的程式語言來編寫基礎設施代碼，促進開發與營運團隊的進一步融合，為現代化基礎設施管理提供更多元的選擇與可能性。

在上一節中，我們探討了 IaC 的基本概念與聲明式語言的優勢。本節將繼續深入，介紹 IaC 的程式碼式 (Programmatic Types) 工具，並透過具體範例來闡述不同類型工具的應用。

聲明式 IaC 工具範例

聲明式語言的關鍵在於，使用者只需定義「期望的系統狀態」，而工具則負責計算並執行實現該狀態所需的步驟。這大大簡化了基礎設施的配置和管理。

  • Terraform 範例 - 定義資源群組: 以下是使用 Terraform 定義 Azure 資源群組的程式碼範例。透過修改 tags 屬性，Terraform 會自動處理更新操作。

    resource "azurerm_resource_group" "myrg" {
  name     = "MyAppResourceGroup"
  location = "West Europe"
  tags = {
    environment = "Bookdemo"
  }
}

    此範例展示了如何以聲明式的方式定義一個名為 MyAppResourceGroup 的 Azure 資源群組，並設定了其位置和標籤。若要修改標籤，只需編輯此處的 tags 屬性，Terraform 便會自動執行必要的更新。

  • Ansible 範例 - 安裝與啟動 Nginx: 以下是使用 Ansible 安裝和啟動 Nginx 的範例。透過修改 state 屬性，可以輕鬆地將服務變更為停止或未安裝的狀態。

- hosts: all
  tasks:
    - name: install and check nginx latest version
      apt:
        name: nginx
        state: latest

    - name: start nginx
      service:
        name: nginx
        state: started
```
此 Ansible 劇本定義了在所有主機上安裝最新版本的 Nginx 並啟動該服務。若要停止 Nginx 或確保其未安裝，只需修改 `state` 屬性為 `stopped` 或 `absent`，並相應調整任務名稱。

```yaml

- hosts: all
  tasks:
    - name: stop nginx
      service:
        name: nginx
        state: stopped

    - name: check nginx is not installed
      apt:
        name: nginx
        state: absent
```
這個修改後的範例展示了如何聲明式地要求 Nginx 服務停止運行，以及確保 Nginx 套件未被安裝。

程式碼式 IaC 工具的興起

近年來，一個顯著的趨勢是 IaC 工具的演進，旨在讓開發者能夠利用他們熟悉的程式語言來編寫基礎設施代碼。這種轉變旨在促進開發者與營運團隊之間的進一步融合。

  • 程式碼式 IaC 的動機: 傳統的指令碼和聲明式 IaC 工具通常由營運團隊主導。為了讓開發者更深入地參與到基礎設施的定義和管理中，出現了基於開發者常用語言（如 TypeScript、Java、Python、C#）的 IaC 工具。

  • 代表性工具:

    • Pulumi: 這是一個開源的雲端開發平台，允許使用者使用 TypeScript、Python、Go、.NET 等多種程式語言來定義和部署雲端基礎設施。
    • Terraform CDK (Cloud Development Kit): 這是 Terraform 的一個擴展，允許開發者使用 TypeScript、Python、Java、C# 等程式語言來編寫基礎設施代碼，然後將其「合成」為 Terraform 的 HCL 配置。

  • Terraform CDK (TypeScript 範例): 以下是一個使用 Terraform CDK 編寫的 TypeScript 程式碼範例，用於定義一個 Azure 資源群組。

    import { Construct } from 'constructs';
import { App, TerraformStack, TerraformOutput } from 'cdktf';

import {
  ResourceGroup,
} from './.gen/providers/azurerm'; // 假設這是自動生成的提供者定義

class MyStack extends TerraformStack {
  constructor(scope: Construct, id: string) {
    super(scope, id);

    new ResourceGroup(this, 'my-resource-group', {
      name: "MyAppResourceGroup",
      location: "West Europe",
      tags: {
        environment: "Bookdemo",
        managedBy: "CDK"
      }
    });
  }
}

const app = new App();
new MyStack(app, 'my-azure-stack');
app.synth();

    這個範例展示了如何使用 TypeScript 來定義一個 Azure 資源群組。開發者可以使用熟悉的物件導向編程概念、類型檢查和 IDE 支持來編寫基礎設施代碼。最終，CDK 工具會將這些程式碼轉換為 Terraform 可識別的配置，然後由 Terraform 來執行部署。

程式碼式 IaC 工具的出現，不僅降低了開發者參與基礎設施管理的門檻，也使得基礎設施代碼能夠享受到與應用程式代碼相同的開發優勢，例如單元測試、代碼重用和更強大的抽象能力。這進一步推動了開發與營運團隊的融合，實現了更緊密的協作與更高的效率。

縱觀基礎設施即代碼（IaC）的演進，其發展不僅是工具的更迭，更反映了技術組織在思維框架上的深刻變革。從指令式的按部就班，到聲明式的目標導向，再演進至程式碼式的完全抽象，這條路徑揭示了管理哲學的轉變：從單純的任務自動化，提升至將基礎設施視為可測試、可重構的軟體產品。此一轉變的關鍵價值，在於打破開發與維運的傳統壁壘，將兩者的技能與思維模型融合。然而，這也帶來了新的挑戰——它要求團隊具備跨領域的抽象能力與更深度的工程素養。

展望未來，應用程式碼與基礎設施代碼的邊界將持續模糊，我們預見下一階段的突破點將是「平台工程」（Platform Engineering）的成熟，以及 AI 驅動的自我修復與優化基礎設施的出現。

玄貓認為，選擇何種 IaC 模式，已不僅是技術選型，更是對組織工程文化成熟度與未來協作模式的策略性定位。

玄貓 BlackCat

玄貓 BlackCat

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