使用 Azure 開發者 CLI 進行全端部署

結合前端與後端服務的全端應用程式是現代網頁開發中常見的模式。 Azure Developer CLI（azd）支援部署全端應用程式，將前端與後端作為獨立服務託管。 本文說明如何使用 azd 全端應用程式部署，並強調有效部署的策略與好處。

什麼是全端部署？

完整的全端部署通常由 azd 組成：

• 前端服務：面向使用者的網頁應用程式，通常使用 React、Angular、Vue 或 Blazor 等框架建構。 前端可以是靜態站點或容器化應用程式。
• 後端服務：處理業務邏輯、資料存取與整合的 API 或服務層。 後端通常以容器或無伺服器功能的形式來運行。
• 共享資源：資料庫、儲存帳號、金鑰庫，以及其他兩個服務可能共用的 Azure 資源。

透過使用 azd，你可以將兩個服務定義在同一個檔案中 azure.yaml ，並利用基礎設施作為程式碼（Bicep 或 Terraform）一起配置。

Azure Developer CLI 生命週期

Azure Developer CLI 遵循結構化工作流程，並有不同的生命週期事件：

1. 套件：建立你的應用程式原始碼並準備部署工件。
2. 配置：使用 Bicep 或 Terraform 建立或更新 Azure 基礎設施資源。
3. 部署：將你已打包的應用程式碼部署到已配置的基礎設施。

azd up 指令會順序執行所有三個階段。 你也可以透過使用 azd package、 azd provision、 azd deploy 來獨立運行每個相位，以進行更細緻的控制。 了解這個生命週期對於管理服務間的相依性至關重要，尤其是在全端部署中，時機與順序都非常重要。

欲了解有關 azd 生命週期與工作流程自訂的更多資訊，請參閱 探索 azd up 工作流程。

基礎設施設計考量

在使用 azd 設計全端應用程式時，請為前端和後端選擇適合的 Azure 託管服務。

服務類型	託管選項	用例
前端	Azure Static Web Apps， Azure App Service， Azure Container Apps	靜態網站、SPA、伺服器渲染應用程式
後端	Azure Container Apps， Azure App Service， Azure Functions， Azure Kubernetes Service	API、微服務、無伺服器功能

了解更多關於 在 Azure 上託管應用程式的資訊。

了解前端與後端應用程式之間的相互依賴性

全端部署常面臨循環依賴性挑戰，即每個服務都需要彼此的資訊才能完整配置。 了解這些相互依賴關係有助於設計有效的部署工作流程。

前端需要後端 URL：你的前端應用程式通常需要在建置時或執行時知道後端 API 端點的 URL。 不過，後端服務在部署到 Azure 之前是沒有網址的。

後端需要前端 URL：你的後端服務可能需要前端 URL 來設定 CORS 政策，但前端在部署前沒有 URL。

共享資源依賴：兩種服務可能都依賴共享資源，如資料庫、金鑰庫或儲存帳號。 這些資源必須先配置好，才能設定使用任一服務。

環境專屬配置：不同環境（開發、暫定、生產環境）需要不同的端點 URL 和設定，但這些值直到配置完成後才會被知道。

了解配置策略

Azure Developer CLI 透過兩種方式處理這些相互依賴關係：

• 部署時配置：在配置與部署過程中解決相依性
• 執行時配置：將相依性設定延後至應用程式執行時

這些方法代表你在建置應用程式時所做的設計決策。 你可以根據架構和需求，只用一種策略，或結合兩種策略。

部署時間設定

部署時配置意指服務連接與配置會在azd provision與azd deploy階段中被確定並鎖定。 透過這種方法，你可以在服務開始運行前，先設定特定的端點網址、連線字串及其他相依資訊。 此配置成為部署服務環境的一部分，無論是作為環境變數或隨部署封裝的設定檔。

基礎設施優先配置：當你執行 azd up 或 azd provision時，基礎設施會先建立。 此步驟會在部署開始前產生必要的網址與連接字串，確保相依服務擁有所需資訊。

輸出變數：Bicep 和 Terraform 在配置後可以輸出 URL 和連接字串等數值。 這些輸出會在部署階段以環境變數形式提供，因此你可以在服務開始前就配置正確的端點。

順序部署：對於複雜情境，您可能需要依特定順序部署服務。 使用 azd掛鉤 來管理部署順序，確保先啟動前置服務，再部署相依服務。

容器 upsert 模式：Azure Verified Modules（AVM）提供像 container-app-upsert 這樣的容器應用模式，能與 azd 的雙階段工作流程無縫協作。 在配置過程中，基礎設施與初始容器會被建立。 部署期間，azd 會將環境變數更新到容器映像檔中，這些變數包含在佈署時生成的值，例如資料庫連接字串或服務網址。 此模式解決了先有雞還是先有蛋的問題，是透過先建立基礎架構，然後更新容器配置，以包含所有必要的相依資訊。

React 前端與容器 API 後端的工作流程範例：

1. Run azd up，依序執行套件、配置與部署階段。
2. 在配置過程中，Bicep 使用 AVM container-app-upsert 模組建立 Azure 容器應用基礎架構，並輸出後端 API URL。
3. 部署時， azd 會自動將兩個容器上傳正確的環境變數，包括前端的 API URL。
4. 兩項服務都從正確的設定開始。 未來當執行 azd up 或 azd deploy 以更新容器時，會使用任何新的設定值進行更新。

執行時配置

執行時設定讓應用程式能在執行時載入設定，而非部署期間。 此方法提供更新服務端點、連線字串與政策的彈性，而無需重新部署您的應用程式。

配置來源：應用程式可從兩個主要來源載入執行時配置：

• 本地設定檔：將配置檔（如 config.json）與應用程式一同部署。 應用程式在啟動時載入此檔案，以取得目前的端點網址、認證設定及其他設定值。 這種方法非常適合客戶端框架，如 React、Angular、Vue 和 Blazor WebAssembly，這些框架能在應用程式啟動時擷取設定。

• 雲端配置服務：使用 Azure App Configuration 或類似服務，集中管理所有環境的設定。 應用程式在啟動時或按需查詢組態服務以取得當前值。 此方法適用於多個服務需要協調配置更新的微服務架構。

優點：無論哪種方式，設定變更都能立即啟用，無需重新部署。 透過你的部署管線更新設定檔，或透過 Azure 入口網站更改 Azure App Configuration 的設定值。 當應用程式重新啟動或刷新設定時，會接收新的值。 此圖案特別適合：

• 需要發現後端 API URL、認證端點及微服務位置的前端應用程式
• 需要在前端 URL 變更時更新 CORS 政策的後端服務
• 需要在開發、預備和生產環境中不同配置的服務

React 前端發現後端 API 的工作流程範例：

1. 執行 azd up 以配置基礎設施並部署兩個服務。
2. 部署後 hook 會生成一個包含後端 URL 的 config.json 檔案，並將其上傳至前端的儲存位置。
3. React 應用程式在啟動時會擷取 config.json 資料以發現 API 端點。
4. 若要之後更新端點，只需修改 config.json 而不重新部署前端。

這種做法對於所有內容在建置時都預先渲染的靜態生成網站不適用。

規劃你的部署工作流程

在設計全端部署時，請考慮以下因素：

1. 辨識相依關係：規劃哪些服務需要其他服務的資訊。 對於單向相依（例如依賴資料庫的 API），配置平台（Bicep 或 Terraform）會自動處理排序。 對於循環依賴（例如前端與後端服務，啟動時雙方都需要彼此的 URL），你必須使用部署時或執行時的配置策略來設計協調。
2. 部署前配置：部署應用程式碼前確保所有基礎設施都已存在。
3. 使用環境變數：透過 azd 環境變數在基礎設施層與應用層間傳遞設定。
4. 多重環境設計：規劃開發、預備與生產環境間配置的差異。
5. 考慮部署順序：有些情境可能需要依特定順序部署服務。

此 azd up 指令能自動執行配置，接著在單一工作流程中部署，來處理大多數部署情境。 對於標準單一應用，這種方法運作良好且只需最少的設定。

對於較複雜的部署，例如帶有循環相依的全方位堆疊：

• 設定服務順序：在您的檔案中 azure.yaml ，依照您希望部署的服務順序定義服務。 雖然 azd 預設是平行部署服務，但你也可以在需要時使用 掛鉤 強制執行順序部署。

• 自訂工作流程步驟：透過在檔案azd up中定義自訂workflows屬性來覆蓋預設azure.yaml工作流程。 例如，你可以在建置應用程式原始碼前，將預設行為設定為執行配置：

  name: todo-nodejs-mongo
  metadata:
    template: todo-nodejs-mongo@0.0.1-beta
  workflows:
    up: 
      steps:
        - azd: provision
        - azd: package
        - azd: deploy
  

  當建置過程需要只有在配置完成後才能取得的設定值時，這個模式非常有用。

• 分開配置與部署：不要使用 azd up、執行 azd provision 和 azd deploy 作為獨立指令。 這種分離在你需要在部署應用程式碼前驗證基礎設施配置，或是排查部署問題時非常有用。 你可以先配置一次基礎設施，然後多次部署和重新部署應用程式碼，而不必重新配置。

• 用鉤子自定義：在你的檔案中加入前置鉤和後置鉤，以便在配置與部署階段之間執行自定義邏輯。 使用掛鉤來填充設定檔、驗證環境狀態，或協調複雜的部署序列。

最佳做法

在使用 azd 建構全端應用程式時，請遵循以下最佳實務：

1. 及早繪製相依關係圖：在設計階段識別哪些服務需要其他服務的資訊。 請區分可以由 Bicep 或 Terraform 自動處理的單向相依與需要在部署時或運行時採取配置策略的循環相依。
2. 選擇正確的配置策略：當服務在部署時需要鎖定配置時，使用部署時的配置。 當你需要彈性更新配置且不重新部署時，使用執行時配置。 適當時可結合兩種策略。
3. 使用 Azure Verified Modules （AVM）：利用 Azure Verified Modules 的 Bicep 模組，例如 container-app-upsert 容器應用程式。 這些模式能與 azd的兩階段工作流程無縫結合，解決循環依賴關係。
4. 必要時自訂工作流程：簡單部署時，使用azd up預設設定。 對於具有循環依賴的複雜情境，請自訂 workflows 檔案中的 azure.yaml 屬性，以控制封包、配置與部署步驟的順序。
5. 善用執行時設定：為了跨環境的最大彈性，可以使用 Azure App Configuration 或本地設定檔來管理服務端點與設定，且這些服務可以無需重新部署即可更新。
6. 跨環境測試：確保您的配置策略在開發、預備及生產環境中，服務網址與設定有所不同時都能正確運作。

後續步驟

• 使用 Azure Developer CLI 部署至 Azure Container Apps
• 全端部署範本
• Azure 開發人員 CLI 樣板概述
• 探索 azd up 的工作流程