使用 GitHub Actions 部署至 Azure 基礎結構
在本指南中，我們將討論如何使用 CI/CD 和基礎結構即程式碼 （IaC） 以自動化且可重複的方式部署至 Azure 。
本文是 架構概觀 ，並提供結構化解決方案，可在 Azure 上設計可調整、安全、復原且高可用性的應用程式。 若要查看雲端架構和解決方案概念的更多真實世界範例， 請流覽 Azure 架構 。
使用 IaC 和自動化進行部署的優點
有許多方式可以部署到 Azure，包括Azure 入口網站、CLI、API 等等。 針對本指南，我們將使用 IaC 和 CI/CD 自動化。 此方法的優點包括：
宣告式 ：當您在程式碼中定義基礎結構和部署程式時，可以使用標準軟體發展生命週期進行版本設定和檢閱。 IaC 也有助於防止設定中的任何漂移。
一致性：遵循 IaC 程式可確保整個組織都遵循標準且完善的方法，以部署包含最佳做法的基礎結構，並強化以符合您的安全性需求。 對中央範本所做的任何改進，都可以輕鬆地在整個組織中套用。
安全性 ：雲端作業或安全性小組可以強化並核准集中管理的範本，以符合內部標準。
自助 ：Teams 可以使用集中管理的範本來部署自己的基礎結構。
改善生產力 ：藉由使用標準範本，小組可以快速布建新環境，而不需要擔心所有實作詳細資料。
您可以在 Azure 架構中心內可重複的基礎結構 下 找到其他資訊，或 DevOps Resource Center 中的基礎結構即程式碼 。
架構
資料流程
- 建立新的分支，並簽入所需的 IaC 程式碼修改。
- 一旦您準備好將變更合併到您的環境，請在 GitHub 中建立提取要求 （PR）。
- GitHub Actions 工作流程會觸發，以確保程式碼的格式正確、內部一致，並產生安全的基礎結構。 此外，Terraform 方案或 Bicep 模擬分析將會執行，以產生將在 Azure 環境中發生的變更預覽。
- 經過適當檢閱之後，PR 可以合併到您的主要分支。
- 另一個 GitHub Actions 工作流程會從主要分支觸發，並使用您的 IaC 提供者執行變更。
- （專屬於Terraform） 定期排程的 GitHub Action 工作流程也應該執行 來尋找環境中的任何設定漂移，並在偵測到變更時建立新的問題。
必要條件
使用 Bicep
建立 GitHub 環境
工作流程會利用 GitHub 環境和秘密來儲存 Azure 身分識別資訊，並設定部署的核准程式。 依照這些 指示建立名為
production的環境 。 在production環境中，設定保護規則，並新增您需要在生產環境部署上登出的任何必要核准者。 您也可以將環境限制為主要分支。 如需詳細指示，請參閱 這裡 。設定 Azure 身分 識別：
Azure Active Directory 應用程式必須具備在 Azure 訂用帳戶內部署的許可權。 建立單一應用程式，並在您的 Azure 訂用帳戶中提供適當的讀取/寫入權限。 接下來設定同盟認證，以允許 GitHub 使用 OpenID 連線 （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：定義應用程式註冊的訂用帳戶識別碼。
如需將秘密新增至存放庫的指示，請參閱 這裡 。
使用 Terraform
設定 Terraform 狀態位置
Terraform 會 利用狀態檔案 來儲存受控基礎結構和相關聯組態目前狀態的相關資訊。 此檔案必須在工作流程的不同執行之間保存。 建議的方法是將此檔案儲存在Azure 儲存體帳戶或其他類似的遠端後端。 一般而言，此儲存體會以手動方式或透過個別的工作流程布建。 Terraform 後端區塊 需要使用您選取的儲存位置進行更新（如需檔，請參閱 這裡 ）。
建立 GitHub 環境
工作流程會利用 GitHub 環境和秘密來儲存 Azure 身分識別資訊，並設定部署的核准程式。 依照這些 指示建立名為
production的環境 。 在production環境中設定保護規則，並新增您需要在生產部署上登出的任何必要核准者。 您也可以將環境限制為主要分支。 如需詳細指示，請參閱 這裡 。設定 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分支名稱。
- 將 設定
新增 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
參考架構 包含 兩個主要工作流程：
-
此工作流程會在每次認可上執行，並且是由基礎結構程式碼上的一組單元測試所組成。 它會執行 bicep 組建 ，以將 bicep 編譯至 ARM 範本。 這可確保沒有任何格式錯誤。 接下來，它會執行 驗證 ，以確保範本可部署。 最後， checkov 是 IaC 的開放原始碼靜態程式碼分析工具，會執行 以偵測安全性和合規性問題。 如果存放庫使用 GitHub 進階安全性 （GHAS），結果會上傳至 GitHub。
-
此工作流程會在每個提取要求上執行，並在每個認可至主要分支時執行。 工作流程的假設階段是用來透過執行 假設 狀況來瞭解 IaC 變更對 Azure 環境的影響。 接著，此報告會附加至 PR，以便輕鬆檢閱。 當工作流程由推送至主要分支觸發時，部署階段會在假設分析之後執行。 此階段會在 手動檢閱登出之後，將範本部署 至 Azure。
使用 Terraform
參考架構 包含 三個主要工作流程：
-
此工作流程會在每次認可上執行，並且是由基礎結構程序代碼上的一組單元測試所組成。 它會執行 terraform fmt ，以確保程式代碼正確配置，並遵循 terraform 最佳做法。 接下來，它會執行 terraform 驗證 ，以檢查程式代碼語法是否正確且內部一致。 最後，checkov 是 IaC 的 開放原始碼 靜態程式代碼分析工具，將會執行 以偵測安全性和合規性問題。 如果存放庫使用 GitHub 進階安全性 （GHAS），結果會上傳至 GitHub。
-
此工作流程會在每個提取要求上執行，並在每個認可至主要分支時執行。 工作流程的計劃階段是用來瞭解 IaC 變更對 Azure 環境的影響，方法是執行 terraform 方案。 接著，此報告會附加至 PR，以便輕鬆檢閱。 當工作流程由推送至主要分支觸發時，套用階段會在計劃之後執行。 如果環境有任何擱置的變更，此階段會採用計劃檔，並在 手動檢閱註銷之後套用 變更。
-
此工作流程會定期執行，以掃描您的環境是否有 Terraform 以外的任何設定漂移或變更。 如果偵測到任何漂移，就會引發 GitHub 問題，以警示專案的維護人員。