共用方式為

使用 GitHub Actions 部署至 Azure 基礎結構

  • 發行項

在本指南中，我們將討論如何使用 CI/CD 和基礎結構即程式碼 （IaC） 以自動化且可重複的方式部署至 Azure 。

本文是 架構概觀 ，並提供結構化解決方案，可在 Azure 上設計可調整、安全、復原且高可用性的應用程式。 若要查看雲端架構和解決方案概念的更多真實世界範例， 請流覽 Azure 架構 。

使用 IaC 和自動化進行部署的優點

有許多方式可以部署到 Azure，包括Azure 入口網站、CLI、API 等等。 針對本指南，我們將使用 IaC 和 CI/CD 自動化。 此方法的優點包括：

  • 宣告式 ：當您在程式碼中定義基礎結構和部署程式時，可以使用標準軟體發展生命週期進行版本設定和檢閱。 IaC 也有助於防止設定中的任何漂移。

  • 一致性：遵循 IaC 程式可確保整個組織都遵循標準且完善的方法，以部署包含最佳做法的基礎結構，並強化以符合您的安全性需求。 對中央範本所做的任何改進，都可以輕鬆地在整個組織中套用。

  • 安全性 ：雲端作業或安全性小組可以強化並核准集中管理的範本，以符合內部標準。

  • 自助 ：Teams 可以使用集中管理的範本來部署自己的基礎結構。

  • 改善生產力 ：藉由使用標準範本，小組可以快速布建新環境，而不需要擔心所有實作詳細資料。

您可以在 Azure 架構中心內可重複的基礎結構 下 找到其他資訊，或 DevOps Resource Center 中的基礎結構即程式碼 。

架構

Architecture overview of using CI/CD to deploy Azure

資料流程

  1. 建立新的分支，並簽入所需的 IaC 程式碼修改。
  2. 一旦您準備好將變更合併到您的環境，請在 GitHub 中建立提取要求 （PR）。
  3. GitHub Actions 工作流程會觸發，以確保程式碼的格式正確、內部一致，並產生安全的基礎結構。 此外，Terraform 方案或 Bicep 模擬分析將會執行，以產生將在 Azure 環境中發生的變更預覽。
  4. 經過適當檢閱之後，PR 可以合併到您的主要分支。
  5. 另一個 GitHub Actions 工作流程會從主要分支觸發，並使用您的 IaC 提供者執行變更。
  6. （專屬於Terraform） 定期排程的 GitHub Action 工作流程也應該執行 來尋找環境中的任何設定漂移，並在偵測到變更時建立新的問題。

必要條件

使用 Bicep

  1. 建立 GitHub 環境

    工作流程會利用 GitHub 環境和秘密來儲存 Azure 身分識別資訊，並設定部署的核准程式。 依照這些 指示建立名為 production 的環境 。 在 production 環境中，設定保護規則，並新增您需要在生產環境部署上登出的任何必要核准者。 您也可以將環境限制為主要分支。 如需詳細指示，請參閱 這裡 。

  2. 設定 Azure 身分 識別：

    Azure Active Directory 應用程式必須具備在 Azure 訂用帳戶內部署的許可權。 建立單一應用程式，並在您的 Azure 訂用帳戶中提供適當的讀取/寫入權限。 接下來設定同盟認證，以允許 GitHub 使用 OpenID 連線 （OIDC） 來利用身分識別。 如需詳細指示， 請參閱 Azure 檔 。 必須新增三個同盟認證：

    • 將 [實體類型] 設定為 Environment ，並使用 production 環境名稱。
    • 將 [實體類型] 設定為 Pull Request 。
    • 將 [實體類型] 設定為 Branch ，並使用 main 分支名稱。

  3. 新增 GitHub 秘密

    注意

    雖然 Azure 身分識別沒有任何資料包含任何秘密或認證，但我們仍會使用 GitHub 秘密作為參數化每個環境身分識別資訊的便利方式。

    使用 Azure 身分識別在存放庫上建立下列秘密：

    • AZURE_CLIENT_ID ：Azure 中應用程式註冊的應用程式（用戶端）識別碼
    • AZURE_TENANT_ID ：定義應用程式註冊之 Azure Active Directory 的租使用者識別碼。
    • AZURE_SUBSCRIPTION_ID ：定義應用程式註冊的訂用帳戶識別碼。

    如需將秘密新增至存放庫的指示，請參閱 這裡 。

使用 Terraform

  1. 設定 Terraform 狀態位置

    Terraform 會 利用狀態檔案 來儲存受控基礎結構和相關聯組態目前狀態的相關資訊。 此檔案必須在工作流程的不同執行之間保存。 建議的方法是將此檔案儲存在Azure 儲存體帳戶或其他類似的遠端後端。 一般而言，此儲存體會以手動方式或透過個別的工作流程布建。 Terraform 後端區塊 需要使用您選取的儲存位置進行更新（如需檔，請參閱 這裡 ）。

  2. 建立 GitHub 環境

    工作流程會利用 GitHub 環境和秘密來儲存 Azure 身分識別資訊，並設定部署的核准程式。 依照這些 指示建立名為 production 的環境 。 在 production 環境中設定保護規則，並新增您需要在生產部署上登出的任何必要核准者。 您也可以將環境限制為主要分支。 如需詳細指示，請參閱 這裡 。

  3. 設定 Azure 身分 識別：

    Azure Active Directory 應用程式必須具備在 Azure 訂用帳戶內部署的許可權。 為 read-only 和 read/write 帳戶建立個別的應用程式，並在您的 Azure 訂用帳戶中提供適當的許可權。 此外，這兩個角色也需要步驟 1 中 Terraform 狀態所在的儲存體帳戶至少 Reader and Data Access 許可權。 接下來，設定同盟認證，以允許 GitHub 使用 OpenID 連線 （OIDC） 來利用身分識別。 如需詳細指示， 請參閱 Azure 檔 。

    針對身 read/write 分識別，請建立一個同盟認證，如下所示：

    • 將 設定 Entity Type 為 Environment ，並使用 production 環境名稱。

    針對身分識別， read-only 建立兩個同盟認證，如下所示：

    • 將 Entity Type 設定為 Pull Request。
    • 將 設定 Entity Type 為 Branch ，並使用 main 分支名稱。

  4. 新增 GitHub 秘密

    注意

    雖然 Azure 身分識別沒有任何資料包含任何秘密或認證，但我們仍會使用 GitHub 秘密作為參數化每個環境身分識別資訊的便利方式。

    使用 read-only 身分識別在存放庫上建立下列秘密：

    • AZURE_CLIENT_ID ：Azure 中應用程式註冊的應用程式（用戶端）識別碼
    • AZURE_TENANT_ID ：定義應用程式註冊之 Azure Active Directory 的租使用者識別碼。
    • AZURE_SUBSCRIPTION_ID ：定義應用程式註冊的訂用帳戶識別碼。

    如需將秘密新增至存放庫的指示，請參閱 這裡 。

    使用 read-write 身分識別在 production 環境上建立另一個秘密：

    • AZURE_CLIENT_ID ：Azure 中應用程式註冊的應用程式（用戶端）識別碼

    如需將秘密新增至環境的指示，請參閱 這裡 。 當需要提升許可權的讀取/寫入權限時，環境秘密會在執行部署步驟至 production 環境時覆寫存放庫密碼。

使用 GitHub Actions 進行部署

使用 Bicep

參考架構 包含 兩個主要工作流程：

  1. Bicep 單元測試

    此工作流程會在每次認可上執行，並且是由基礎結構程式碼上的一組單元測試所組成。 它會執行 bicep 組建 ，以將 bicep 編譯至 ARM 範本。 這可確保沒有任何格式錯誤。 接下來，它會執行 驗證 ，以確保範本可部署。 最後， checkov 是 IaC 的開放原始碼靜態程式碼分析工具，會執行 以偵測安全性和合規性問題。 如果存放庫使用 GitHub 進階安全性 （GHAS），結果會上傳至 GitHub。

  2. Bicep What-If / Deploy

    此工作流程會在每個提取要求上執行，並在每個認可至主要分支時執行。 工作流程的假設階段是用來透過執行 假設 狀況來瞭解 IaC 變更對 Azure 環境的影響。 接著，此報告會附加至 PR，以便輕鬆檢閱。 當工作流程由推送至主要分支觸發時，部署階段會在假設分析之後執行。 此階段會在 手動檢閱登出之後，將範本部署 至 Azure。

使用 Terraform

參考架構 包含 三個主要工作流程：

  1. Terraform 單元測試

    此工作流程會在每次認可上執行，並且是由基礎結構程序代碼上的一組單元測試所組成。 它會執行 terraform fmt ，以確保程式代碼正確配置，並遵循 terraform 最佳做法。 接下來，它會執行 terraform 驗證 ，以檢查程式代碼語法是否正確且內部一致。 最後，checkov 是 IaC 的 開放原始碼 靜態程式代碼分析工具，將會執行 以偵測安全性和合規性問題。 如果存放庫使用 GitHub 進階安全性 （GHAS），結果會上傳至 GitHub。

  2. Terraform 方案 / 套用

    此工作流程會在每個提取要求上執行，並在每個認可至主要分支時執行。 工作流程的計劃階段是用來瞭解 IaC 變更對 Azure 環境的影響，方法是執行 terraform 方案。 接著，此報告會附加至 PR，以便輕鬆檢閱。 當工作流程由推送至主要分支觸發時，套用階段會在計劃之後執行。 如果環境有任何擱置的變更，此階段會採用計劃檔，並在 手動檢閱註銷之後套用 變更。

  3. Terraform 漂移偵測

    此工作流程會定期執行，以掃描您的環境是否有 Terraform 以外的任何設定漂移或變更。 如果偵測到任何漂移，就會引發 GitHub 問題，以警示專案的維護人員。