簡介

  • 8 分鐘

基礎架構即程式碼（IaC）是指透過機器可讀的設定檔來定義和管理雲端資源，而非透過手動選擇入口網站或非計畫腳本來進行。 你不是登入 Azure 入口網站來建立虛擬網路，而是寫一個描述網路的檔案。 接著工具會讀取該檔案，並為你建立資源。

這種做法帶來了基礎建設管理方式的根本轉變。 變更會在版本控制中被追蹤，部署可重複，且環境可隨時從零重建。 如果有什麼東西壞掉了，你可以回滾回之前的狀態。 如果你需要一個模擬生產環境的暫存環境，就使用相同的檔案但使用不同的參數。

IaC 也將基礎建設與應用程式碼劃入同一工程領域。 適用於你應用程式的拉取請求工作流程、程式碼審查和自動化測試做法，現在也能應用在你應用程式運行的系統上。

若無 AI 協助，基礎設施即程式碼（IaC）撰寫流程會呈現如下：

  1. 撰寫範本
  2. 查閱相關文件
  3. 修正語法
  4. 在本地驗證
  5. 執行假設分析
  6. 部署到預備環境
  7. 檢閱變更
  8. 部署至生產位置

每次部署，不論是新部署還是更新，都要重複同樣的操作。

學習目標

完成本模組後，您將可以：

  • 說明什麼是基礎架構即程式碼（Infrastructure as Code），以及它在現代雲端運營中的重要性
  • 描述宣告式與命令式 IaC 方法的差異
  • 辨識傳統 IaC 製作工作流程及其摩擦點
  • 解釋 GitHub Copilot 如何改變 IaC 內部迴圈
  • 請描述與基礎架構工作最相關的 GitHub Copilot 功能

基礎設施即程式碼的挑戰

每一步都有摩擦。 從零開始撰寫 Bicep 範本需要了解資源類型、API 版本、所需屬性以及 Azure 專屬的命名規則。 查詢 Microsoft.Network/virtualNetworks 的正確 API 版本，必須瀏覽文件或從先前專案複製。 執行建置指令後，語法錯誤會被發現。 隨著 Azure API 演進，保持範本的更新是一項持續的維護負擔。

結果是 IaC 常被視為一項專業技能。 不經常撰寫範本的工程師會依賴 portal select，這破壞了 IaC 所應提供的一致性。

宣告式與命令式方法

IaC 有兩種基本風格。 了解兩者差異有助於你選擇合適的工具，並為 GitHub Copilot 製作更好的提示。

宣告式 IaC

在宣告式方法中，你描述基礎設施所需的最終狀態。 工具會找到方法到達那裡。

「我要一個VNet，位址空間是10.0.0.0/16，還有兩個子網。」

Azure Bicep 和 ARM 範本是宣告式的。 你定義應該存在哪些資源，而 Azure Resource Manager 負責排序和建立。 如果資源已經以正確狀態存在，則不會套用任何變更。 如果不存在，它就會被創造出來。 如果不同，就會更新。

命令式 IaC

在命令式方法中，你描述了達到理想狀態所需的 步驟 。 你寫的是程序，不是聲明。

「查查VNet是否存在。 如果沒有，請執行 az network vnet create...。

Azure CLI 和 Azure PowerShell 腳本通常是指令式的。 你自己掌控流程、處理錯誤，並管理訂單。 這樣你有更多掌控權，但也更有責任感。 這也包括處理冪등 性，意即腳本必須安全可以多次執行。

你應該用哪一個？

正確的選擇取決於情況。 像 Bicep 這類宣告式工具更適合管理長壽命的基礎設施資源，因為它們能自動處理狀態和漂移。 像 CLI 腳本這類命令式工具，更適合用於操作任務、一次性設定步驟，或涉及邏輯、條件與迴圈的自動化。

實務上，大多數雲端工程師會兩者兼用。 而 GitHub Copilot 也同時支援這兩者。

GitHub Copilot 如何改變範本製作流程

GitHub Copilot 縮短並簡化了 IaC 創作流程的每一個步驟。

在寫作階段，Copilot 從自然語言描述中產生完整的資源定義。 你不用查 Azure 資源的 Bicep 語法，只要描述你需要什麼，Copilot 就能在幾秒內產生起始點。

在審查階段，Copilot 可以分析現有範本，找出安全漏洞、缺失屬性或過時的模式。 它在部署範本前充當第二雙眼睛。

在轉換階段，Copilot 可以在 Azure CLI 與 PowerShell、Azure Resource Manager JSON 與 Bicep，或 Azure Pipelines 與 GitHub Actions 之間轉換。 降低更換工具或改編文件範例的成本。

在文件化階段，Copilot 能閱讀完成的範本，並產生人類可讀的說明、參數參考及架構描述。 這些工作常常被跳過，因為手動操作太繁瑣。

這種變化不僅限於速度。 而是降低進入門檻。 非 Bicep 專家的工程師現在也能透過用淺顯語言說明意圖，製作出正確且結構良好的範本。

GitHub Copilot 用於基礎結構工作的功能

GitHub Copilot 在 VS Code 中以多種方式呈現，每種方式都適合 IaC 工作流程的不同部分。

內嵌建議

當你輸入 .bicep、.yaml、.ps1 或 .sh 檔案時，Copilot 會即時提供補全。 如果你輸入資源定義的開頭，Copilot 會預測剩下的部分。 包括所需的屬性、預設值和常見模式。 你可以用 Tab 接受或用 Escape 拒絕。

內嵌建議最適合用於檔案中已建立的持續模式。 如果你正確定義一種資源，Copilot 會根據結構，並以相同風格建議類似資源。

副駕駛聊天室

Copilot聊天（Ctrl+Alt+I）是一個對話介面，你可以在這裡提問、描述你想建什麼、貼上現有程式碼供審查，或請求說明。

對於需要更多上下文的任務，聊天比內嵌建議更好。 例如從零產生整個範本、重構複雜檔案，或詢問資源運作原理。

搭配 MCP (模型內容通訊協定) 的 Copilot

MCP 允許 Copilot 連接外部工具與資料來源。 Bicep MCP server 提供Copilot存取即時Bicep型別定義、當前 API 版本及驗證規則。 讓其 Bicep 輸出比僅依賴訓練資料所能產生的內容更準確。

為什麼 IaC 非常適合 AI 協助

基礎設施定義具有適合進行 AI 輔助生成的特質：

  • 它們結構嚴謹：資源定義遵循結構架構。 屬性基於已知類型、有效值及必要/可選的指定。 這種結構化特性使模型更容易產生語法正確的輸出。
  • 它們模式豐富：大多數Azure部署使用相對較少的常見資源類型：虛擬網路、儲存帳號、運算資源與身份。 這些模式在訓練資料中經常出現，意味著 Copilot 依賴許多範例。
  • 手動研究成本高昂：找到適合不熟悉資源類型的 API 版本、所需屬性與有效 SKU 組合可能需要相當多時間。 Copilot 將這些研究壓縮成一個提示訊息。
  • 這些流程可以安全地迭代：先驗證，再部署。 Copilot 提出的錯誤建議會在觸及任何實際資源之前，於 az bicep build 或 what-if 中被攔截。 這個安全網鼓勵了各種嘗試。

重點摘要

  • IaC 將基礎建設視為程式碼：具備版本控制、可重複且可審查。
  • 宣告式工具如 Bicep 描述期望的最終狀態;命令式工具如 CLI 描述達成該狀態的步驟。
  • 傳統的 IaC 工作流程在每個階段都有相當大的摩擦。 Copilot 可降低這種阻礙。
  • GitHub Copilot 透過內嵌建議、Copilot Chat 和 MCP 增強內容提供協助。
  • IaC 非常適合 AI 協助，因為它結構化、模式豐富且可以安全迭代。