Terraform 透過基礎設施即程式碼的理念,讓開發者能以程式碼定義和管理基礎設施資源,簡化了跨多個雲端平台的佈署流程。其宣告式語法讓使用者專注於描述目標狀態,Terraform 自動處理資源的建立、更新和刪除,確保基礎設施的一致性和可重複性。文章中提到的多雲端佈署案例,展現了 Terraform 如何以單一工具管理 AWS、GCP 等不同雲端環境,有效避免供應商鎖定。此外,Terraform 也能精細化地協調應用程式基礎設施,自動處理資源間的依賴關係,並支援藍綠佈署和金絲雀發布等進階佈署策略。結合 ServiceNow 等自助服務平台,更能將基礎設施管理流程自動化,提升團隊效率。

使用 Terraform 進行基礎設施管理

利用 Terraform 與其他工具整合進行自動化

從圖示中可以看到,Terraform 是一個允許我們將基礎設施定義為程式碼、進行基礎設施自動化並提供不同基礎設施生態系統元件之間互動的工具。Terraform 擁有豐富的功能,能夠與不同平台如 Microsoft Azure、Google Cloud 或 VMware 等整合。

SaltStack 是一個組態管理工具,提供作業系統和應用程式層級的自動化。SaltStack 的工作方式是主-從對,從節點是佈署在個別伺服器上的代理,它們透過指定的 TCP/IP 傳輸埠與主節點通訊。主節點可以根據在主節點上定義的狀態向從節點發出一系列指令和操作。

ServiceNow 的自助服務目錄

ServiceNow 允許管理員提供自助服務目錄。這些目錄根據每個需要自動化的任務來定義。一旦目錄定義並且使用者需求對應(通常需要呼叫 Terraform 模組所需的輸入),使用者只需登入到 ServiceNow 工單工具,然後就可以在其後端基礎設施環境中自動執行定義好的任務。ServiceNow 提供與 Terraform 的直接整合;它在後台與 Terraform 核心、企業或雲端版本互動,並作為協調器來完成任務。完成任務後,它會向使用者傳送確認。

例如,假設使用者需要擴充套件現有磁碟。透過 Terraform 和 SaltStack 的整合,這項工作可以自動完成。使用者可以在服務目錄中提交請求,然後 ServiceNow(或工單工具)將控制權交給 Terraform,從後端增加磁碟大小。當平台上的所需磁碟大小增加後,Terraform 可以將控制權交給 SaltStack,在作業系統層級擴充套件磁碟。最終,當任務完成時,SaltStack 可以通知 ServiceNow 並完成整個工作流程。因此,一個完整的工作流程可以被協調。

Terraform 的應用場景

多雲端佈署

組織越來越多地轉向公有雲。組織轉向雲端的一個常見趨勢是利用多個公有雲提供者的優勢。這在組織希望避免供應商鎖定情況、利用適合其應用程式的功能以及分割其足跡以獲得成本優勢時尤其明顯。跨多個雲端提供者佈署基礎設施也增加了容錯能力,使得從雲端提供者停機中更優雅地還原。

然而,這種趨勢也帶來了挑戰。因為每個雲端提供者都有自己的介面、工具和工作流程。為了完全適應雲端服務,利用自動化尤其重要。因此,Terraform 的存在允許使用相同的工作流程來管理多個雲端提供者並處理其跨雲端依賴性。

Terraform 使用共同語言(HCL)簡化了大規模多雲端基礎設施的管理和協調。

Terraform 登入檔支援數千個公開可用的提供者。它支援所有主要公有雲平台,並且這個清單還在不斷擴充套件。

應用程式基礎設施協調、擴充套件和監控

當我們談論應用程式時,是應用程式的分層將它們與其他基礎設施佈署區分開來。應用程式的安裝和佈署需要按順序安排。例如,當我們佈署應用程式時,第一步是佈署資料函式庫層,然後是網頁伺服器,然後是快取伺服器等。

Terraform 可以自動處理這些依賴關係。例如,它可以在佈建依賴於資料函式庫層的網頁伺服器之前先佈建資料函式庫層。此外,Terraform 可以有效地釋放、擴充套件和監控多層應用程式的基礎設施。多層應用程式讓你能夠獨立地擴充套件應用程式元件並提供關注點分離。

Terraform 支援使用 Datadog 提供者自動監控應用程式基礎設施。當你想要將 Nginx 應用程式佈署到 Kubernetes 叢集時,透過 Terraform 的幫助,你還可以在叢集資源上協調 Datadog Agent 的安裝。這個 Datadog Agent 報告叢集健康狀況到 Datadog 儀錶板。

Terraform 的功能也可以用於藍綠佈署和金絲雀發布策略。對於藍綠佈署策略中的特性切換來說,「藍」環境對應於現有產品環境,「綠」環境則是預備好待上線的新版本環境。「金絲雀」發布則是逐步地將新版本推播到小部分生產環境中進行測試和監控,「藍」環境同時運作以保障生產安全性與穩定性。

Terraform 讓你能夠定義一份組態檔案並包含一系列可能的佈署策略,同時進行金絲雀測試並在逐步推進「綠」環境版本上線過程中進行更多確認測試。

自助服務模型

如前文所述,大型組織通常有一支中央營運團隊負責處理重複性的基礎設施服務請求。透過 Terraform 的幫助,他們可以建立一種自助模型讓客戶獨立管理自己的基礎設施。Terraform 支援建立模組以便在不同佈署中複製相同的標準規範、標準流程及標準作業模式(SOPs),從而讓各團隊能夠按照組織標準有效地佈署服務。

之前提到的一種整合方式就是與 ServiceNow 的整合——也就是說經由票證系統來管理及協調各項工作流程及請求。

裝載例項解說

provider "aws" {
  region = "us-west-2"
}

resource "aws_instance" "example" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"

  tags = {
    Name = "HelloWorld"
  }
}

內容解密:

玄貓首先組態 AWS 提供者並指定地區(region)為 us-west-2(奧瑞岡州)。然後使用 aws_instance 資源建立 EC2 執行例項並指定了 AMI ID 和執行例項型別為 t2.micro。最後增加了一些標籤以便識別該例項。

resource "aws_security_group" "allow_tls" {
  name        = "allow_tls"
  description = "Allow TLS inbound traffic"

  ingress {
    description      = "TLS from VPC"
    from_port        = 443
    to_port          = 443
    protocol         = "tcp"
    cidr_blocks      = [var.vpc_cidr_block]
    ipv6_cidr_blocks = [var.vpc_ipv6_cidr_block]
  }

  egress {
    from_port        = 0
    to_port          = 0
    protocol         = "-1"
    cidr_blocks      = ["0.0.0.0/0"]
    ipv6_cidr_blocks = ["::/0"]
  }

  tags = {
    Name = "allow_tls"
  }
}

內容解密:

玄貓接著建立了一個安全群組(Security Group),該安全群組允許 TLS 流量進入(Ingress)並允許所有出站流量(Egress)。使用變數 var.vpc_cidr_blockvar.vpc_ipv6_cidr_block 指定 VPC CIDR 塊和 IPv6 CIDR 塊以限制進站流量來源。

variable "vpc_cidr_block" {
  description = "The CIDR block for the VPC."
  type        = string
}

variable "vpc_ipv6_cidr_block" {
  description = "The IPv6 CIDR block for the VPC."
  type        = string
}

內容解密:

玄貓接著定義了兩個變數:vpc_cidr_blockvpc_ipv6_cidr_block ,分別描述 VPC 的 IPv4 和 IPv6 CIDR 塊型別為字串(string)。

建立多雲端網路架構

以下是利用 Terraform 建立跨多公有雲之間互通網路架構之簡化範例:

provider "aws" {
  region = "us-west-2"
}

provider "google" {
    project     = var.gcp_project
    region      = var.gcp_region
}

resource "aws_vpc" "main" {
   cidr_block       = "10.0.0.0/16"
   enable_dns_hostnames = true
   enable_dns_support   = true
}

resource "google_compute_network" "main" {
   name                    = var.network_name
   auto_create_subnetworks = false
}

resource "google_compute_subnetwork" "main" {
   name          = var.subnetwork_name
   network       = google_compute_network.main.id
   ip_cidr_range       = var.subnetwork_ip_range
   region               ="${var.gcp_region}"
}

內容解密:

玄貓首先組態了 AWS 和 GCP 提供者並分別指定地區與專案資訊;接著透過 aws_vpc 資源建立 AWS VPC 網路並在 google_compute_network 資源中建立 GCP 網路及子網路資源;子網路資源之範圍則由變數 var.subnetwork_ip_range 指定;最後透過 region 屬性來指定所屬區域位置.

自助服務平台之實踐範例

以下範例顯示如何利用 ServiceNow 與 Terraform 整合來實作自我服務功能:

provider "servicenow" {

    # Configuration options here

}

data "servicenow_table" "instances" {

        table           ="incident"
        query           ="number=INC12345"

}

resource "servicenow_record" "instance_12345_update":

         table           ="incident"
         fields          =
         {

               state       ="3"
               short_description="Instance updated by terraform"

         }

內容解密:

玄貓首先組態了 ServiceNow 提供者;接著透過 data 資源取得指定號碼之工單記錄;最後透過 resource 資源更新該記錄之狀態及簡短描述。

以上就是利用 Terraform 與其他工具整合進行自動化以及一些常見應用場景的詳細解說。 希望這些內容對您理解如何利用 Terraform 與其他技術進行基礎設施管理有所幫助!

Terraform 自動化與組態管理工具整合

自動化工具的自助式介面

對於希望實施自動化並將重複性任務外包給 Terraform 的組織來說,Terraform 提供了一個強大的自助式介面。這使得支援團隊能夠更高效地運作,並將精力集中在更有價值的工作上。自動化工具可以顯著提升組織的營運效率,降低人為錯誤的風險。

政策遵從與管理

政策是 Terraform Cloud 在 Terraform 執行過程中所應用的指導方針。這些政策可以確保 Terraform 計劃符合安全準則和最佳實踐。Terraform 可以協助強制執行有關團隊能夠提供和使用的資源的規範。傳統的票據審核流程可能會成為開發過程中的障礙,而 Sentinel 這樣的政策即程式碼框架可以替代這些流程,在 Terraform 進行基礎設施修改之前自動強制執行合規性和治理要求。無論是 Terraform Enterprise 還是 Terraform Cloud 版本,都支援 Sentinel 政策。

Sentinel 和 Open Policy Agent (OPA) 是兩種可用於建立根據邏輯的細粒度政策的政策即程式碼框架。根據設定,政策可能是建議通知或嚴格限制,阻止 Terraform 提供基礎設施。

軟體定義網路(SDN)

軟體定義網路(SDN)與 Terraform 的結合可以自主地組態網路以滿足應用程式的需求。這樣可以從票據驅動的方法轉向自動化方法,加快佈署速度。

這些使用案例展示了 Terraform 技術的豐富功能,當智慧利用時,可以為基礎設施管理帶來顯著好處。

組態管理工具與 Terraform 的整合

組態管理工具簡介

組態管理工具幫助系統管理員維護系統的一致性。它們確保新機器、軟體套件和更新按預期狀態進行安裝和組態。這有助於維護各種 IT 系統和站點的一致性。常見的組態管理工具包括 SaltStack、Chef、Puppet 和 Ansible。

大多陣列態管理工具都支援像 Linux 和 Windows 這樣流行的作業系統,並且可以透過中央伺服器遠端控制系統。以 SaltStack 為例,不同的 minion(小嘍囉)會安裝在各自的系統上,並由主伺服器集中控制。IT 管理員可以在 SaltStack 主伺服器上組態預期狀態,然後在 minion 上強制執行該組態。

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title Terraform 基礎設施即程式碼:多雲端自動化與組態管理整合

package "Kubernetes Cluster" {
    package "Control Plane" {
        component [API Server] as api
        component [Controller Manager] as cm
        component [Scheduler] as sched
        database [etcd] as etcd
    }

    package "Worker Nodes" {
        component [Kubelet] as kubelet
        component [Kube-proxy] as proxy
        package "Pods" {
            component [Container 1] as c1
            component [Container 2] as c2
        }
    }
}

api --> etcd : 儲存狀態
api --> cm : 控制迴圈
api --> sched : 調度決策
api --> kubelet : 指令下達
kubelet --> c1
kubelet --> c2
proxy --> c1 : 網路代理
proxy --> c2

note right of api
  核心 API 入口
  所有操作經由此處
end note

@enduml

在此圖示中,Slave 是安裝在不同系統(如 Linux、Windows 等)上的代理程式(minion)。這些 Slave 會將自己註冊到中央伺服器(稱為 Master),負責在各自 Slave 上組態和執行相同的預期狀態。現代 Master 組態支援 REST API,這使得透過 RESTful API 進行組態和管理變得更加容易,從而使程式設計化管理 Master-Slave 整合成為可能。

SaltStack 與 Terraform 的整合

SaltStack 與 Terraform 的整合對 IT 管理員來說是一個額外的價值,因為它們可以從頭到尾自動化基礎設施操作。Terraform 控制平台基礎設施層面的自動化,而 SaltStack 控制系統層面的自動化,形成了典型基礎設施自動化使用案例所需的完整組合。它們的整合在進行端對端自動化方面提供了真正的價值增加。

Terraform 提供了多種整合選項供此類別組態工具使用。我們可以利用 Terraform 在每次建立新虛擬機器時安裝這些組態代理程式。此外,為了完成整合,我們還可以定義方法來註冊新安裝的代理程式(minion),並自動在主側接受它們以完成這些代理程式的註冊過程。以下是一些此類別整合的一些範例:

VM 建立時安裝代理程式

Terraform 提供了一個名為 locals 的部分,您可以在新資源佈署後定義 start_up_command 來執行。要安裝 SaltStack minion,您需要在 VM 佈署過程中提供佈署可執行檔案。有多種方法可以提供 minion 安裝的可執行檔案。以下是 Terraform 組態檔案中的兩個範例:

locals {
    start_up_command = [
        "powershell.exe -command \"<File drive location>\\sample.exe\""
    ]
}

resource "vsphere_virtual_machine" "xxx" {
    ...

    customize {
        windows_options {
            computer_name = "xyz"
            ...
            run_once_command_list = local.start_up_command
        }
    }
}

內容解密:

上述程式碼片段展示瞭如何在使用 Terraform 建立 VM 時安裝 SaltStack minion。首先在 locals 塊中定義 start_up_command,然後在 vsphere_virtual_machine 資源中參照該命令。

  • locals 塊locals 是 Terraform 中用來定義本地變數和命令列表的一部分。start_up_command 是一個包含 PowerShell 命令字串列表。
  • PowerShell 命令powershell.exe -command "<File drive location>\\sample.exe" 用於呼叫指定位置上的可執行檔案來安裝 SaltStack minion。
  • vsphere_virtual_machine 資源:這部分程式碼定義了一個 VMware 虛擬機器資源。customize 塊中的 run_once_command_list 屬性指定了 VM 建立後要執行的一組命令列表。

透過這種方式,我們可以確保每次建立新虛擬機器時都會自動安裝 SaltStack minion。

locals {
    start_up_command = [
        "powershell.exe -command \"'$webclient.DownloadFile(\\\"https://<repo>/sample.exe\\\", \\\"$env:TEMP\\minion.exe\\\")' \"",
        "powershell.exe -command \"$env:TEMP\\minion.exe\""
    ]
}

resource "vsphere_virtual_machine" "xxx" {
    ...

    customize {
        windows_options {
            computer_name = "xyz"
            ...
            run_once_command_list = local.start_up_command
        }
    }
}

內容解密:

第二種方法涉及從中央倉函式庫下載代理程式可執行檔案,然後呼叫安裝過程。

  • locals 塊:包含兩個 PowerShell 命令字串列表。
    • 第一個命令使用 $webclient.DownloadFile 下載可執行檔案。
    • 第二個命令執行下載後的可執行檔案。
  • PowerShell 命令
    • powershell.exe -command "$webclient.DownloadFile(\\"https://<repo>/sample.exe\\", \\"$env:TEMP\\minion.exe\\\")" 用於下載可執行檔案到臨時目錄。
    • powershell.exe -command "$env:TEMP\\minion.exe" 用於執行下載後的可執行檔案。
  • vsphere_virtual_machine 資源:與第一個範例相似,但在本次範例中我們需要先下載可執行檔案才能執行它。

透過這種方式我們確保每次建立新虛擬機器時都能順利完成SaltStack minion 的下載及安裝過程。

這些範例展示瞭如何利用Terraform進行基礎設施即程式碼(IaC)並整合組態管理工具以實作端對端自動化維運流程。


Terraform 是一款非常靈活且強大的工具, 是一種根據宣告性語言(HashiCorp Configuration Language, HCL) 的開源軟體, 能夠提供一致性地描述資源以及能夠實作資源生命週期管理, 組態管理工具能夠完美與其搭配使用, 操作員們只需要在一次佈署時就能將其基本環境設定好, 不必再手動去修改每台伺服器或客戶端, 大幅提升效率.