在本指南中，我們將介紹如何利用 CI/CD 和基礎設施即代碼 （IaC） 以自動化和可重複的方式使用 GitHub Actions 部署到 Azure。
本文是 架構概觀 ，並提供結構化解決方案，用於在 Azure 上設計可調整、安全、復原且高可用性的應用程式。 若要查看雲端架構和解決方案構想的更多真實範例，請 瀏覽 Azure 架構。
使用 IaC 和自動化進行部署的好處
部署至 Azure 的方式有很多種，包括 Azure 入口網站、CLI、API 等等。 在本指南中，我們將使用 IaC 和 CI/CD 自動化。 這種方法的好處包括：
宣告式：當您在程式碼中定義基礎結構和部署程序時，可以使用標準軟體開發生命週期對其進行版本控制和檢閱。 IaC 也有助於防止組態中出現任何漂移。
一致性：遵循 IaC 流程可確保整個組織遵循標準、完善的方法來部署基礎設施，該方法包含最佳實踐並經過強化以滿足您的安全需求。 對中央範本所做的任何改進都可以輕鬆地應用於整個組織。
安全性：集中管理的範本可以由雲端營運或安全性小組強化和核准，以符合內部標準。
自助服務：團隊可以利用集中管理的模板來部署自己的基礎設施。
提高生產力：透過利用標準模板，團隊可以快速配置新環境，而無需擔心所有實施細節。
您可以在 Azure 架構中心的 可重複基礎結構 下找到其他資訊，或 DevOps 資源中心的 基礎結構即程式碼是什麼 。
Architecture
數據流
- 建立新分支並提交所需的 IaC 程式碼的修改。
- 準備好將變更合併到環境中後，請在 GitHub 中建立提取要求 （PR）。
- 將觸發 GitHub Actions 工作流程，以確保您的程式碼格式正確、內部一致，並產生安全的基礎結構。 此外，「Terraform Plan」或「Bicep what-if 分析」將會執行，以產生 Azure 環境中即將發生的變更之預覽。
- 經過適當審查後，PR 可以合併到您的主分支中。
- 另一個 GitHub Actions 工作流程將從主分支觸發，並使用您的 IaC 提供者執行變更。
- （Terraform 獨有） 還應該執行定期排程的 GitHub Action 工作流程，以偵測環境中的任何配置偏移，如果偵測到變更，則建立新的議題。
先決條件
使用 Bicep
建立 GitHub 環境
工作流程會利用 GitHub 環境和秘密來儲存 Azure 身分識別資訊，並設定部署的核准程式。 依照這些
production建立命名的環境。 在production環境中，設定保護規則，並新增您想要在生產部署上簽核的任何必要核准者。 您也可以將執行環境限制到您的主要分支。 詳細說明 可以在這裡找到。設定 Azure 身分識別：
需要具有在 Azure 訂用帳戶內部署許可權的 Azure Active Directory 應用程式。 建立單一應用程式，並在 Azure 訂用帳戶中授與適當的讀取/寫入權限。 接下來，設定同盟認證，以允許 GitHub 使用 OpenID Connect （OIDC） 來使用身分識別。 如需詳細指示，請參閱 Azure 檔 。 需要新增三個聯合認證：
- 將 [實體類型] 設定為
Environment，並使用production環境名稱。 - 將「圖元類型」設定為
Pull Request。 - 將 [實體類型] 設定為
Branch，並使用main分支名稱。
- 將 [實體類型] 設定為
新增 GitHub 機密
備註
雖然 Azure 身分識別的相關資料都不包含任何秘密或認證，但我們仍會利用 GitHub 秘密作為參數化每個環境身分識別資訊的便利方式。
使用 Azure 身分識別在存放庫上建立下列秘密：
-
AZURE_CLIENT_ID：Azure 中應用程式註冊的應用程式 （用戶端） 識別碼 -
AZURE_TENANT_ID：定義應用程式註冊的 Azure Active Directory 租用戶識別碼。 -
AZURE_SUBSCRIPTION_ID：定義應用程式註冊的訂閱 ID。
如需將密碼新增至存放庫的指示，請參閱 此處。
-
使用 Terraform
設定 Terraform 狀態位置
Terraform 會利用 狀態檔案 來儲存受管理基礎結構和相關組態目前狀態的相關資訊。 此檔案必須在工作流程的不同執行之間保存。 建議的方法是將此檔案儲存在 Azure 儲存體帳戶或其他類似的遠端後端中。 通常，此儲存體會手動或透過個別的工作流程進行佈建。 Terraform 後端區塊將需要更新為您選擇的儲存位置（請參閱此處以取得文件）。
建立 GitHub 環境
工作流程會利用 GitHub 環境和秘密來儲存 Azure 身分識別資訊，並設定部署的核准程式。 依照這些
production建立命名的環境。 請在production的環境中設定保護規則，並新增任何您希望在生產部署上簽核的必要核准者。 您也可以將執行環境限制到您的主要分支。 詳細說明 可以在這裡找到。設定 Azure 身分識別：
需要具有在 Azure 訂用帳戶內部署許可權的 Azure Active Directory 應用程式。 為 和
read-onlyread/write帳戶建立個別的應用程式，並在 Azure 訂用帳戶中授與適當的許可權。 此外，這兩個角色至少需要對存放步驟 1 中 Terraform 狀態的儲存體帳戶擁有Reader and Data Access許可權。 接下來，設定同盟認證，以允許 GitHub 使用 OpenID Connect （OIDC） 來使用身分識別。 如需詳細指示，請參閱 Azure 檔 。針對
read/write身分，建立一個聯合憑證，如下所示：- 設定
Entity Type為Environment並使用production環境名稱。
針對身分識別，
read-only請建立兩個聯合認證，如下所示：- 將
Entity Type設定為Pull Request。 - 設定
Entity Type為Branch並使用main分支名稱。
- 設定
新增 GitHub 機密
備註
雖然 Azure 身分識別的相關資料都不包含任何秘密或認證，但我們仍會利用 GitHub 秘密作為參數化每個環境身分識別資訊的便利方式。
使用身分識別在
read-only存放庫上建立下列密碼：-
AZURE_CLIENT_ID：Azure 中應用程式註冊的應用程式 （用戶端） 識別碼 -
AZURE_TENANT_ID：定義應用程式註冊的 Azure Active Directory 租用戶識別碼。 -
AZURE_SUBSCRIPTION_ID：定義應用程式註冊的訂閱 ID。
如需將密碼新增至存放庫的指示，請參閱 此處。
使用
read-write身分在production環境中建立另一個機密：-
AZURE_CLIENT_ID：Azure 中應用程式註冊的應用程式 （用戶端） 識別碼
如需將機密新增至環境的指示，請參閱 這裡。 部署至
production環境的步驟中，如果需要提升讀取/寫入許可權，環境密碼將覆蓋存放庫密碼。-
使用 GitHub Actions 部署
使用 Bicep
參考架構中包含兩個主要工作流程：
-
此工作流程會在每次提交時執行，並由基礎結構程式碼上的一組單元測試組成。 它會執行 bicep 組建 ，將 bicep 編譯為 ARM 範本。 這可確保沒有格式錯誤。 接下來，它會執行 驗證 以確保範本可部署。 最後，IaC 的開源靜態程式碼分析工具 checkov 將運行以偵測安全性和合規性問題。 如果存放庫使用 GitHub Advanced Security （GHAS），則結果會上傳至 GitHub。
-
此工作流程會在每個拉取請求及每次提交到主要分支時執行。 工作流程的假設階段可用來藉由執行 假設來瞭解 IaC 變更對 Azure 環境的影響。 然後，此報告會附加至 PR 以方便檢閱。 部署階段會在假設分析之後執行，當工作流程由推送至主要分支觸發時。 此階段會在手動檢閱簽核之後，將範本 部署 至 Azure。
使用 Terraform
參考架構中包含三個主要工作流程：
-
此工作流程會在每次提交時執行，並由基礎結構程式碼上的一組單元測試組成。 它會執行 terraform fmt ，以確保程式碼已正確整理並且遵循 terraform 的最佳實務。 接下來，它會執行 terraform 驗證 ，以檢查程式碼在語法上是否正確且內部一致。 最後，IaC 的開源靜態程式碼分析工具 checkov 將運行以偵測安全性和合規性問題。 如果存放庫使用 GitHub Advanced Security （GHAS），則結果會上傳至 GitHub。
-
此工作流程會在每次拉取請求及每次提交至主要分支時執行。 工作流程的計劃階段可用來藉由執行 terraform 計劃來了解 IaC 變更對 Azure 環境的影響。 然後，此報告會附加至 PR 以方便檢閱。 當推送至主分支時觸發工作流程後，套用階段會在計畫階段之後執行。 此階段將採用計劃文件，並在手動檢閱簽核後 套用 變更（如果環境有任何擱置的變更）。
-
此工作流程會定期執行，以掃描您的環境，以找出在 Terraform 外部進行的任何組態漂移或變更。 如果偵測到任何漂移，則會引發 GitHub 問題，以警示專案的維護人員。
相關資源
- 什麼是基礎設施即代碼
- 可重複的基礎設施
- 比較 Terraform 和 Bicep
- Checkov 和 原始碼
- GitHub 進階安全性