基于Terraform与AKS的企业级Azure OpenAI私有化部署实践

1. 项目概述：用Terraform在AKS上构建一个企业级的Azure OpenAI应用

最近在做一个挺有意思的项目，客户想在自己的Azure环境里部署一个类似ChatGPT的聊天机器人应用，但要求所有东西都得是私有的、安全的，不能走公网。这其实是个挺典型的场景，很多企业都想用大语言模型的能力，但又对数据安全和网络隔离有硬性要求。我琢磨了一下，用Azure Kubernetes Service（AKS）搭配Azure OpenAI Service，再用Terraform做基础设施即代码，是个挺完美的组合。

这个方案的核心思路，是在Azure里拉起一个私有的AKS集群，然后在同一个虚拟网络里部署Azure OpenAI服务，两者之间通过Azure Private Endpoint进行通信，完全走Azure的内部骨干网，数据不出VNet。应用本身是一个Python写的聊天机器人，它通过Azure AD Workload Identity这种无密码的方式去安全地获取访问Azure OpenAI的令牌。整个架构从网络、身份、到应用部署，全部用Terraform模块化地定义和部署，确保环境的一致性和可重复性。

我为什么推荐这个方案？首先，Terraform的声明式语法让基础设施的状态变得可预测、可版本控制，你改一行代码，跑一下terraform apply，就知道会新增、修改或销毁哪些资源，避免了手动操作的“配置漂移”。其次，AKS提供了成熟的Kubernetes托管服务，省去了自己搭K8s集群的运维负担。最后，Azure OpenAI Service提供了企业级的GPT模型访问，带有合规性和安全承诺，这是直接用OpenAI API不太容易做到的。这个方案特别适合那些需要将AI能力集成到现有企业应用里，同时又对安全、网络和运维有高要求的团队。

2. 架构设计与核心组件选型解析

2.1 整体网络与安全架构

这个项目的架构图看起来挺复杂，但拆解开来，核心就是“私有化”和“模块化”。整个部署被放在一个独立的Azure资源组里，核心是一个虚拟网络（VNet），里面划分子网给不同的组件用。

AKS集群本身我建议部署为私有集群。这意味着Kubernetes的API服务器端点（apiserver）只有一个内网IP，不暴露在公网上。要管理这个集群，你有几个选择：要么通过跳板机（Bastion Host或一台部署在同一个VNet里的虚拟机）来连接；要么给API服务器配置“授权IP范围”，只允许来自你公司办公室或VPN的IP地址访问。对于生产环境，私有集群加上Uptime SLA是更稳妥的做法。

所有依赖的PaaS服务，包括Azure OpenAI、Azure Container Registry（ACR）、Azure Key Vault和存储账户，都通过Azure Private Endpoint暴露在这个VNet内部。Private Endpoint本质上是在你的VNet里给这些服务分配了一个私有的IP地址。这样一来，你的Pod访问openai.azure.com这样的端点时，流量根本不会出Azure的数据中心，直接通过Azure的私有链路就到了后端服务，延迟低，安全性高。

为了让私有端点能正常解析，还需要配套的Azure Private DNS Zone。比如，为privatelink.openai.azure.com创建一个私有DNS区域，并关联到你的VNet。这样，当你的应用尝试解析服务的主机名时，DNS查询会被导向私有IP，而不是公网IP。Terraform模块里已经把创建Private Endpoint和关联Private DNS Zone的逻辑封装好了，你只需要指定要私有化的服务列表就行。

出站流量管理是另一个重点。AKS集群里的Pod如果需要访问外网（比如拉取公共镜像），默认会走负载均衡器分配的公网IP。但在企业环境，我们通常希望统一出口。这里我们用了一个用户自管理的Azure NAT网关，把它关联到AKS节点和Pod所在的子网。然后在创建AKS集群时，将outboundType设置为userAssignedNatGateway。这样，所有从集群发往互联网的流量都会经过这个NAT网关，它的公网IP是固定的，方便我们在防火墙做白名单规则。

2.2 核心Azure服务组件详解

1. Azure OpenAI Service：这是我们的“大脑”。部署时，关键是要创建一个自定义子域。因为后续我们要用Azure AD令牌来认证，而这是自定义子域模式才支持的功能。在Terraform里，azurerm_cognitive_account资源的custom_subdomain_name参数就是干这个的。模型部署（azurerm_cognitive_deployment）这一步不能少，它决定了你用的是GPT-3.5-Turbo还是GPT-4，以及具体的版本号。

2. Azure Kubernetes Service (AKS)：我们的大脑需要个“身体”来运行，AKS就是这个容器化的身体。Terraform的azurerm_kubernetes_cluster资源功能非常全。这里有几个关键配置：

   • private_cluster_enabled = true：启用私有集群。
   • oidc_issuer_url：这个输出值很重要，它用于后面配置Workload Identity的联邦身份凭证，让K8s里的Service Account能和Azure AD的托管身份建立信任关系。
   • network_profile：根据需求选择网络插件。对于需要精细控制Pod IP且与VNet深度集成的场景，azure（即Azure CNI）是首选。如果对Pod数量要求大且希望简化IP管理，可以考虑azure_cni_overlay。

3. Azure Container Registry (ACR)：存放我们聊天机器人应用镜像的私人仓库。同样配置为私有端点访问。AKS集群需要被授予从ACR拉取镜像的权限（AcrPull），这通常通过给AKS集群的系统分配托管身份（MSI）分配角色来实现。

4. Azure Key Vault：用来存敏感信息，比如应用的配置、证书。虽然这个示例应用可能没直接用上，但在真实场景中，数据库连接字符串、API密钥等都可以存在这里。然后通过Secrets Store CSI Driver插件，把这些秘密以文件或环境变量的方式安全地注入到Pod里。

5. Azure Monitor 与 Log Analytics：可观测性的基石。Terraform模块为几乎所有资源（AKS、OpenAI、Key Vault等）都配置了诊断设置，将日志和指标统一发送到一个Log Analytics工作区。这样我们就可以在一个地方查看所有组件的运行状态、性能指标和审计日志，排查问题非常方便。

2.3 身份与访问控制：Workload Identity的核心逻辑

这是整个方案安全链路上最精妙的一环。传统上，让K8s里的Pod访问Azure资源（比如我们的OpenAI服务），要么用放在代码或环境变量里的连接字符串（不安全），要么用挂载的Service Principal证书（管理麻烦）。

Azure AD Workload Identity提供了更优雅的解决方案。它的工作原理是这样的：

1. 我们在Azure AD里创建一个用户分配的托管身份（User-Assigned Managed Identity），并赋予它访问Azure OpenAI服务的权限（例如“Cognitive Services User”角色）。
2. 在AKS集群里，我们创建一个Kubernetes的Service Account。
3. 然后，我们建立一个联邦身份凭证（Federated Identity Credential），把K8s Service Account（具体来说是它的OIDC签发者URL和主题标识符）和Azure AD里的那个托管身份“绑定”起来。
4. 当Pod使用这个Service Account启动时，Pod内的应用（比如我们的Python聊天机器人）可以使用Azure SDK（如azure-identity包），它会自动探测到自己在K8s环境中，并携带Service Account的令牌去联系Azure AD的OIDC端点进行验证。
5. Azure AD验证通过后，就会颁发一个访问令牌给这个Pod，而这个令牌的权限范围就是我们之前给那个托管身份分配的权限。

整个过程对应用代码几乎是透明的，你不需要管理任何凭证。Terraform代码里对应的就是azurerm_user_assigned_identity、azurerm_role_assignment和azurerm_federated_identity_credential这几个资源。federated_identity_credential里的subject字段格式system:serviceaccount:<命名空间>:<服务账户名>，必须和你K8s YAML里定义的一模一样。

3. Terraform模块化部署实操详解

3.1 环境准备与前置条件

动手之前，得先把“柴火”备齐。首先是一个Azure订阅，如果没有，可以创建一个免费账户，不过注意免费账户可能有资源种类和额度的限制。对于生产用途，建议使用付费订阅。

本地开发环境，我习惯用Visual Studio Code，装上HashiCorp Terraform扩展，写代码和做语法检查都很方便。当然，任何你喜欢的文本编辑器或IDE都可以。

Azure CLI是必须的，它是我们和Azure资源管理器打交道的命令行工具。确保安装的是2.49.0或更高版本。安装后，用az login登录你的Azure账户。

因为这个示例用到了AKS的一些预览功能（比如特定的网络插件或特性），所以需要安装aks-preview这个CLI扩展。安装和更新命令如下：

az extension add --name aks-preview az extension update --name aks-preview

装好后，运行一下az version，确认aks-preview的版本在0.5.140以上。

最后，项目里提供了一个register-preview-features.sh脚本。在运行Terraform之前，务必先执行这个脚本。它的作用是向你的Azure订阅注册该示例可能依赖的预览功能提供商。如果不注册，在部署某些资源时可能会收到“Feature not registered”的错误。

3.2 配置文件解析与定制

Terraform用变量（variable）来参数化配置。这个项目的主要配置集中在terraform.tfvars文件里。我们来逐一拆解这些参数：

name_prefix = "magic8ball" # 所有Azure资源名称的前缀，用于保持唯一性和归类 domain = "contoso.com" # 你的主域名，用于构造Ingress的完整访问域名 subdomain = "magic" # 子域名部分，最终访问地址会是 magic.contoso.com namespace = "magic8ball" # Kubernetes命名空间，应用将部署于此 service_account_name = "magic8ball-sa" # 上面提到的用于Workload Identity的K8s服务账户名 ssh_public_key = "XXXXXXX" # 你的SSH公钥，用于AKS节点和跳板机VM的登录 vm_enabled = true # 是否部署跳板机虚拟机。如果为true，会创建一台Ubuntu VM用于管理私有集群。 location = "westeurope" # Azure区域，如 westeurope, eastus2 admin_group_object_ids = ["XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"] # Azure AD组ID，该组的成员将对AKS集群拥有管理员权限

几个关键点的实操心得：

• ssh_public_key：强烈建议不要把私钥或长字符串直接硬编码在tfvars里。更安全的做法是，先在Azure Key Vault里创建一个Secret来存储它，然后在Terraform里用data "azurerm_key_vault_secret"来引用。或者，至少使用Terraform的sensitive变量标记，并在运行时从环境变量传入。
• admin_group_object_ids：这个参数只在启用AKS的Azure AD集成和Azure RBAC时才需要。你需要先去Azure AD里创建一个安全组，把需要管理集群的用户加进去，然后把这个组的对象ID（Object ID）填在这里。获取对象ID可以用命令：az ad group show --group "你的组名" --query id -o tsv。
• vm_enabled：对于纯私有集群（没有授权IP范围），如果你不从Azure Bastion连接，那么部署一台跳板机是访问集群节点的唯一方式。如果你已经有现成的运维通道（比如站点到站点VPN或ExpressRoute连接到了这个VNet），可以将其设为false。

3.3 核心Terraform模块代码走读

项目里的Terraform代码是模块化设计的，main.tf是根模块，它调用了诸如modules/virtual_network、modules/aks、modules/openai这样的子模块。这种结构清晰，复用性强。

以部署Azure OpenAI服务的模块（modules/openai/main.tf）为例，我们看看关键部分：

resource "azurerm_cognitive_account" "openai" { name = var.name # ... 其他参数 kind = "OpenAI" custom_subdomain_name = var.custom_subdomain_name # 关键！启用自定义子域 sku_name = var.sku_name # 例如 "S0" public_network_access_enabled = false # 生产环境建议关闭公网访问，强制走Private Endpoint } resource "azurerm_cognitive_deployment" "deployment" { for_each = {for deployment in var.deployments: deployment.name => deployment} name = each.key # 部署名称，如“gpt-35-turbo” cognitive_account_id = azurerm_cognitive_account.openai.id model { format = "OpenAI" name = each.value.model.name # 模型名，如“gpt-35-turbo” version = each.value.model.version # 模型版本，如“0613” } scale { type = "Standard" } }

这个模块允许你通过deployments变量传入一个列表，一次性部署多个模型（比如一个用于聊天的GPT-3.5，一个用于生成的GPT-4）。public_network_access_enabled设置为false是关键一步，这样创建的服务从一开始就不暴露公网端点，逼着你必须通过Private Endpoint来访问，从源头保障安全。

Private Endpoint的创建在main.tf里是统一处理的。它会遍历一个资源列表（OpenAI, ACR, Key Vault等），为每个资源调用private_endpoint模块。这个模块内部做了两件事：创建Private Endpoint资源，以及创建或关联对应的Private DNS Zone。确保DNS解析指向私有IP，这是很多人在配置Private Link时容易遗漏的一步。

3.4 执行部署与验证

配置好terraform.tfvars后，标准的Terraform工作流如下：

1. 初始化：在terraform目录下运行terraform init。这会下载所需的Azure Provider和模块。
2. 规划：运行terraform plan -out=tfplan。这一步非常重要，它会展示Terraform将要创建、更改或销毁的所有资源。请花时间仔细核对这个计划，确认符合你的预期。特别是会创建多少收费资源（如AKS节点、OpenAI服务、VM等），避免产生意外费用。
3. 应用：确认无误后，运行terraform apply tfplan。接下来就是等待，整个过程可能需要15-30分钟，因为AKS集群的创建和节点就绪需要时间。
4. 验证：部署完成后，Terraform会输出一些关键信息，比如AKS的kubeconfig获取命令、跳板机的公共IP（如果部署了）、OpenAI服务的私有端点等。
   • 获取kubeconfig:az aks get-credentials -n <集群名> -g <资源组名> --admin（如果用了Azure AD集成，可能不需要--admin）。
   • 通过kubectl检查节点和系统Pod状态：kubectl get nodes，kubectl get pods -n kube-system。
   • 尝试从集群内部（比如通过跳板机ssh到某个节点，或运行一个测试Pod）curl一下OpenAI的私有端点域名，看是否能解析到私有IP并连通。

4. 应用部署与配置要点

4.1 应用容器化与镜像推送

示例中的聊天机器人是一个Python Flask应用。它的Dockerfile很简单，基于Python镜像，安装依赖，暴露端口，启动应用。代码的核心是使用azure-identity包和openai包（配置为使用Azure端点）。

在本地构建并测试镜像后，需要将其推送到我们刚创建的私有ACR中。因为ACR也是私有端点访问，所以从本地推送或者从AKS拉取，都需要确保网络连通性。如果你在本地开发，一种方法是在跳板机上构建和推送；另一种方法是暂时为ACR启用公网访问端点（推送完再关闭），或者使用Azure Container Registry Tasks在云端直接构建。

假设ACR名为myacr，镜像标签为chatbot:v1：

# 登录ACR（如果ACR启用了管理员账户） az acr login --name myacr # 或者使用托管身份/服务主体登录 # 给镜像打上ACR的完整标签 docker tag chatbot:v1 myacr.azurecr.io/chatbot:v1 # 推送镜像 docker push myacr.azurecr.io/chatbot:v1

4.2 Kubernetes资源配置清单解析

应用部署到AKS，需要几个关键的K8s YAML文件：Namespace、ServiceAccount、Deployment、Service和Ingress。这里重点看Deployment和ServiceAccount。

ServiceAccount(serviceaccount.yaml):

apiVersion: v1 kind: ServiceAccount metadata: name: magic8ball-sa # 必须与Terraform中federated_identity_credential的subject里的名字一致 namespace: magic8ball annotations: azure.workload.identity/client-id: <用户分配托管身份的客户端ID> # 这是关键注解！

这个client-id注解，就是告诉Azure AD Workload Identity插件：“这个Service Account代表的是Azure AD里哪个托管身份”。这个客户端ID可以从Terraform的输出变量aks_workload_identity_client_id获取，或者在Azure门户上查看你创建的那个用户分配托管身份的属性得到。

Deployment(deployment.yaml):

apiVersion: apps/v1 kind: Deployment metadata: name: magic8ball namespace: magic8ball spec: replicas: 2 selector: matchLabels: app: magic8ball template: metadata: labels: app: magic8ball annotations: azure.workload.identity/service-account: "magic8ball-sa" # Pod注解，关联Service Account spec: serviceAccountName: magic8ball-sa # 指定Pod使用的Service Account containers: - name: chatbot image: myacr.azurecr.io/chatbot:v1 env: - name: AZURE_OPENAI_ENDPOINT value: "https://<你的自定义子域>.openai.azure.com/" # 从Terraform输出获取 - name: AZURE_OPENAI_DEPLOYMENT_NAME value: "gpt-35-turbo" # 与Terraform中部署的名称一致 - name: AZURE_TENANT_ID valueFrom: configMapKeyRef: name: azure-config key: AZURE_TENANT_ID ports: - containerPort: 5000

Pod模板里的注解azure.workload.identity/service-account也是必需的，它激活了Pod内的令牌投射功能。环境变量AZURE_OPENAI_ENDPOINT的值，就是你在Terraform里为OpenAI服务设置的那个自定义子域名。

4.3 Ingress与对外暴露

为了让外部用户能访问到集群内的聊天机器人，我们需要一个Ingress控制器。示例中使用Helm部署了NGINX Ingress Controller。Terraform的部署脚本（install-nginx-via-helm-and-create-sa.sh）已经帮我们做了这件事。

然后，我们创建一个Ingress资源，将特定的主机名（如magic.contoso.com）路由到后端的Chatbot Service。这里通常还会用到Cert-Manager（同样由脚本安装）来自动从Let‘s Encrypt申请和管理TLS证书，实现HTTPS访问。

一个重要的网络细节：NGINX Ingress Controller默认是以LoadBalancer类型的Service暴露的。在私有AKS集群中，这会创建一个Azure内部负载均衡器（Internal Load Balancer），它也只有内网IP。因此，外部用户想要访问magic.contoso.com，你需要：

1. 要么在公有DNS（如Azure DNS或你的域名注册商）上，将magic.contoso.com的A记录指向这个内部负载均衡器的私有IP（这通常需要你的网络有路径能使外部流量到达这个私有IP，例如通过Azure Firewall或Application Gateway做反向代理）。
2. 要么，更常见的做法是，将Ingress Controller配置为使用一个公共负载均衡器（在Helm values中设置controller.service.annotations.service.beta.kubernetes.io/azure-load-balancer-internal: "false"），这样它会获得一个公网IP。然后你就可以将域名指向这个公网IP。此时，流量路径是：用户 -> 公网IP -> 公网LB -> NGINX Ingress Pod -> Chatbot Pod。虽然入口是公网，但AKS的API服务器和OpenAI服务之间的关键链路仍然是私有的。

5. 常见问题排查与运维经验

5.1 部署阶段常见错误与解决

• 错误：features.CognitiveServicesAccountis not registered

  • 原因：你的Azure订阅尚未注册Microsoft.CognitiveServices资源提供程序。
  • 解决：运行az provider register --namespace Microsoft.CognitiveServices。或者，确保已运行项目提供的register-preview-features.sh脚本。

• 错误：创建OpenAI服务时提示“Custom subdomain name not available”

  • 原因：自定义子域名在Azure OpenAI服务中必须是全局唯一的，你选的名称可能已被占用。
  • 解决：在Terraform变量中换一个更独特的custom_subdomain_name，比如加上环境或公司后缀。

• 错误：Terraform apply在AKS创建步骤卡住很久

  • 原因：AKS集群创建，尤其是节点池的初始化，本身就需要时间（10-20分钟）。如果卡在某个步骤超过30分钟，可能是配额不足或区域容量问题。
  • 解决：
    1. 检查订阅在目标区域的vCPU配额：az vm list-usage --location westeurope -o table。
    2. 检查是否选择了有现货（Spot）实例的节点池，现货实例可能因容量回收而创建失败。
    3. 尝试换一个区域部署。

• 错误：Pod启动失败，提示ImagePullBackOff

  • 原因：AKS节点无法从ACR拉取镜像。最常见的原因是ACR的访问权限未正确配置或网络不通。
  • 解决：
    1. 确认ACR已成功创建且为“Premium”SKU（支持私有端点）。
    2. 确认AKS集群的系统分配托管身份（或你指定的服务主体）已被授予ACR的“AcrPull”角色。Terraform模块应该已经处理了这一点，但可以手动验证：az role assignment list --assignee <AKS集群的客户端ID> --scope /subscriptions/<订阅ID>/resourceGroups/<资源组>/providers/Microsoft.ContainerRegistry/registries/<ACR名称>。
    3. 如果ACR是私有的，确认AKS节点所在的子网与ACR的Private Endpoint所在的子网之间网络是连通的，并且DNS能正确解析到私有IP。可以进入一个节点SSH，尝试nslookup <acr-name>.azurecr.io和curl -v https://<acr-name>.azurecr.io/v2/。

5.2 Workload Identity 身份验证失败

这是调试中最常见的环节。Pod跑起来了，但应用报错，无法从Azure AD获取令牌，或者令牌没有访问OpenAI的权限。

• 症状：应用日志显示DefaultAzureCredential failed to retrieve a token from the included credentials或AuthorizationFailed。
• 排查步骤：
  1. 检查Pod注解和ServiceAccount：kubectl describe pod <pod-name> -n magic8ball，查看Annotations里是否有azure.workload.identity/service-account: "magic8ball-sa"。再kubectl describe serviceaccount magic8ball-sa -n magic8ball，确认Annotations里有正确的client-id。
  2. 检查联邦身份凭证：在Azure门户，找到你创建的那个用户分配托管身份，进入“联合身份认证”标签页。确认有一条记录的“颁发者”是你AKS集群的OIDC签发者URL（可从az aks show -g -n --query oidcIssuerProfile.issuerUrl -o tsv获取），且“主题标识符”完全匹配system:serviceaccount:magic8ball:magic8ball-sa。
  3. 检查角色分配：在Azure门户，打开你的Azure OpenAI服务，进入“访问控制(IAM)”，查看是否有分配给那个用户分配托管身份的“Cognitive Services User”角色。
  4. 在Pod内手动测试：进入Pod执行命令，使用Azure CLI或写个小Python脚本测试凭据。

     kubectl exec -it <pod-name> -n magic8ball -- bash # 安装az cli (如果镜像里没有) # 然后尝试获取令牌 az login --identity --username <托管身份的客户端ID> # 获取到令牌后，尝试调用OpenAI的REST API

  5. 检查环境变量：确认Pod中AZURE_OPENAI_ENDPOINT和AZURE_OPENAI_DEPLOYMENT_NAME环境变量设置正确，且端点URL是HTTPS协议，并以斜杠结尾。

5.3 网络连通性问题排查

• 症状：应用能拿到令牌，但调用OpenAI API时超时或连接被拒。
• 排查：
  1. DNS解析：在Pod内执行nslookup <你的自定义子域>.openai.azure.com。它应该解析到的是一个以.privatelink.openai.azure.com结尾的CNAME，并最终指向一个10.x.x.x之类的私有IP。如果解析到的是公网IP，说明Private DNS Zone没有正确关联到VNet，或者Pod使用的DNS服务器不是Azure提供的（检查K8s的dnsConfig）。
  2. 网络策略：检查是否在AKS中启用了网络策略（如Calico或Azure Network Policy），并有无意中阻止了Pod到Private Endpoint IP的流量。可以临时创建一个NetworkPolicy允许所有出口流量来测试。
  3. NSG规则：检查OpenAI Private Endpoint所在的子网关联的网络安全组（NSG），确保允许来自AKS Pod子网的入站流量（通常是HTTPS 443端口）。
  4. 使用简单测试：在Pod内运行一个简单的curl -v https://<endpoint>/openai/deployments/<deployment-name>/chat/completions?api-version=2023-05-15 -H "Authorization: Bearer <token>"，观察详细的连接和响应信息。

5.4 成本优化与日常运维建议

1. 非生产环境自动启停：对于开发测试环境，AKS节点和OpenAI服务持续运行成本不菲。可以写一个自动化脚本，在非工作时间（如下班后、周末）用az aks scale命令将节点数缩容到0，并用az cognitiveservices account update暂停OpenAI服务（如果支持）。上班前再扩容回来。Azure Automation或Logic Apps可以轻松实现这个调度。
2. 利用Azure Spot节点池：对于可以容忍中断的工作负载（比如批处理任务、开发环境），在AKS中创建Spot节点池可以大幅降低计算成本。只需在节点池定义中设置priority: Spot并配置eviction_policy。
3. 监控与告警：利用已集成的Azure Monitor。为关键指标设置告警，例如：
   • AKS节点CPU/内存压力。
   • OpenAI服务的总令牌消耗量或请求失败率。
   • AKS Ingress的5xx错误率。
4. 密钥轮换与安全：虽然我们用了Workload Identity，但可能还有其他需要密钥的地方（比如Ingress Controller的TLS证书私钥）。定期轮换Key Vault中的秘密。利用Key Vault的版本控制功能，更新秘密后，重启对应的Pod即可加载新版本。
5. Terraform状态文件安全：terraform.tfstate文件包含了所有资源的敏感信息。切勿将其提交到Git。务必使用远程后端存储，如Azure Storage Account（配置私有端点访问和加密），并启用状态文件锁定（如使用Azure Blob存储的Lease功能），防止多人同时操作导致状态损坏。