企业官网建设流程全解析

导读

本文以 infra/terraform/azure/README.md 为骨架，梳理 PyCaret 4.0 平台面向微软 Azure 的 Terraform 部署模块设计。读者将了解到：该模块作为 V2 阶段性占位（stub）声明了哪些 Azure 托管服务组合、它与 AWS / GCP 模块在多云矩阵中的对应关系、Control Plane 各组件（API、Worker、数据库、对象存储、缓存、密钥、可观测性）在 Azure 生态中的落点，以及从当前本地 Docker Compose 交付走向云上一键部署的整体演进路线。文章同时结合仓库源码，说明这些云服务在后端运行时层面的对接现状与约束。

模块定位：面向 Azure 的 Control Plane 一键部署模块（V2 stub）

infra/terraform/azure/目录当前仅包含一份 README（infra/terraform/azure/README.md），自述为"Azure deployment module (V2 stub)"，即 V2 阶段性的部署模块占位。它在仓库中的上级语境由两份文档共同定义：

• infra/terraform/README.md：明确标注aws/、gcp/、azure/三个子目录均为stubs（占位），目标是 V2；每个云各提供一个自包含的 Terraform 模块，从零开始完整交付 Control Plane。
• infra/README.md：将infra/terraform/归入"非源码、用于交付 PyCaret Control Plane"的部署基础设施，并指出当前处于 MVP 激活状态的只有infra/docker/，Terraform 与 Helm 均为路线图项。

该模块的声明目标如下：Container Apps（或可选 AKS）+ Azure Database for PostgreSQL + Blob Storage + Azure Cache for Redis + Application Gateway + Key Vault + Application Insights。也就是说，Azure 模块要把计算、数据库、对象存储、缓存、网关、密钥管理与可观测性全部纳入一个terraform apply的交付范围，这与 AWS、GCP 模块的粒度保持一致。

多云矩阵：Azure 在三朵云中的对应位置

infra/terraform/README.md 给出了三朵云逐项对应的服务矩阵，Azure 列是本模块的直接参照：

该矩阵揭示了三条设计准则：

1. 每朵云自包含：每个模块都是独立的 Terraform 模块，一次terraform apply即可从零交付整套 Control Plane；
2. 变量面最小化：每个模块只暴露region、domain、tier等最少输入，其余全部使用默认值（"Variables expose the minimum surface (region, domain, tier), everything else is defaulted"）；
3. 计算层允许替换：AWS 用 ECS/Fargate、GCP 用 Cloud Run、Azure 用 Container Apps，同时各自保留 K8s（EKS / GKE / AKS）作为 opt-in 选项。

从 docs/revamp/PLATFORM_ARCHITECTURE.md 的路线图看，AWS 模块被定义为 canonical "production deploy" 路径（阶段 2），而 Azure 模块被明确列入阶段 5 "Multi-cloud"，属于"far future"的远期交付物，配套的设想是 "Azure pack (Azure SQL, Blob, Container Apps, Service Bus)"。

目标架构：Azure 托管服务与 Control Plane 组件的映射

Azure 模块要交付的对象是 PyCaret Control Plane——由 compose.yml 与 docs/revamp/CONTROL_PLANE_SPEC.md 描述的完整平台：FastAPI 后端（services/api）、React 前端（apps/web）、任务 Worker（services/worker，V1 为进程内 APScheduler）与部署运行时（services/deployment-runtime）。对照 Azure 模块声明的服务清单，可得到如下映射：

这种"本地实现 → 云托管服务"的对应关系，在 docs/revamp/STATUS.md 的待办清单中得到了印证：待办项明确写着 "K8s Helm chart + per-cloud Terraform (AWS / GCP / Azure)" 与 "Postgres + MinIO + Redis + Caddy + TLS" 的docker-compose.prod.yml，说明云交付是在本地全栈跑通之后的演进目标。

从源码看 Azure 服务的运行时对接现状与约束

Azure 模块当前是 stub，后端源码也尚未实现 Azure 原生驱动，但从现有抽象层可以准确评估"哪些能复用、哪些待新增"。以下结论均可在源码中找到依据。

存储层：S3 协议先行，Blob Storage 待新增驱动

对象存储抽象定义在 services/api/pycaret_server/storage/，由base.py（ObjectStore协议）、factory.py（按PYCARET_STORAGE_BACKEND分发的工厂）、local_fs.py与s3.py组成。factory.py 目前只接受三个后端值：local、s3、minio，其中minio与s3复用同一份 boto3 实现、仅追加PYCARET_STORAGE_ENDPOINT_URL。因此：

• 若 Azure 模块选择 Blob Storage，需要新增一个azure驱动（实现put_bytes/ 生成az://bucket/key这类 URI），这与 docs/revamp/DECISIONS.md 中"LLM 提供商可插拔"的同类设计思路一致；
• 若采用 Azure Blob 的 S3 兼容端点，则可以复用现有s3驱动，仅调整端点配置。

队列与调度：Redis 后端已就绪，服务总线为远期

services/api/pycaret_server/runs/dispatch.py 的调度逻辑显示，当settings.runs_backend == "redis"时会通过queue_redis.py的enqueue_job向 Redis 入队，失败时回退进程内执行（fall back to the in-process），并有default/cpu-heavy/gpu/inference多队列的路由逻辑（GPU 队列由 services/api/pycaret_server/runtime/gpu.py 支撑）。这为 Azure Cache for Redis 作为任务队列提供了直接可用的对接路径。而路线图中提到的 Azure Service Bus（见 docs/revamp/PLATFORM_ARCHITECTURE.md 阶段 5 的 "Azure pack" 设想）则属于尚未落地的远期项。

密钥与配置：环境变量驱动，Key Vault 为未来注入点

服务端配置由 services/api/pycaret_server/config.py 统一定义，全部以PYCARET_前缀的环境变量读取，关键项包括：

这套纯环境变量配置模型意味着：Azure 模块在交付时只需把 Key Vault 中的值以环境变量形式注入 Container Apps 的容器运行时即可完成密钥托管，无需改动应用代码。

可观测性：从本地日志到 Application Insights

compose.yml 中 API 与 Web 服务均带健康检查（healthcheck探针），后端日志由 pycaret_server/ 内部日志体系输出。Azure 模块将 Application Insights 列为日志/指标落点，属于容器平台层可观测性的标准替换，应用侧无需新增代码。

云上交付的预期使用方式

尽管 Azure 模块尚未落地，但 AWS 模块 README（infra/terraform/aws/README.md）给出了整个infra/terraform家族预期的调用形态，可作为 Azure 模块成型的模板：

module "pycaret" { source = "github.com/pycaret/pycaret//infra/terraform/azure?ref=v4" region = "eastus2" domain = "ml.example.com" tier = "small" # small | medium | large # ... 其余全部使用模块默认值 }

而 docs/revamp/PLATFORM_ARCHITECTURE.md 中 AWS 模块的 DevOps 流程，也预示了 Azure 模块成型后的操作范式：

cd infra/terraform/azure terraform init && terraform apply -var domain=ml.example.com -var env=prod terraform output # → API 地址、数据库主机、存储桶名等

此外，该文档还强调了一条重要的安全边界：Terraform 只负责配置基础设施，运行中的后端/前端永远不会反过来配置云资源（"Terraform configures infrastructure. The running BE/UI never configures AWS"）。这一边界同样适用于 Azure 模块——云凭据与密钥只存在于部署期与托管密钥库中，而不进入应用数据库。

模块的文件结构预期

参照 infra/terraform/README.md 给出的 AWS 模块文件布局，Azure 模块成型后的目录结构可以合理推断为：

infra/terraform/azure/ ├── main.tf # 入口模块：声明全部 Azure 资源 ├── variables.tf # region、domain、tier 等最小变量面 ├── outputs.tf # 端点 URL、数据库主机、Blob 容器名 ├── network.tf # VNet / Application Gateway ├── container-apps.tf # Container Apps 环境与 API / Worker 容器 ├── postgres.tf # Azure Database for PostgreSQL ├── blob.tf # Blob Storage 账户与容器 ├── redis.tf # Azure Cache for Redis ├── keyvault.tf # Key Vault 与机密 ├── insights.tf # Application Insights └── README.md # 本云的使用入门

需要强调的是，这是基于仓库现有布局的推断（docs/revamp/ARCHITECTURE.md 也确认infra/helm/+infra/terraform/{aws,gcp,azure}/均为 V2 stubs），具体文件名以模块正式落地为准。

现状与路线图总结

综合 docs/revamp/STATUS.md、docs/revamp/PLATFORM_ARCHITECTURE.md 与 docs/revamp/ROADMAP.md，Azure 部署模块的定位可归纳为：

• 现状（V2 stub）：仅有一份声明性的 README，明确了目标服务组合与多云矩阵位置；infra/terraform/azure/目录下暂无.tf文件（infra/terraform/azure/）；
• 路线位置：三朵云 Terraform 属于 V2 阶段目标，Azure 更具体地落在多云的远期阶段（阶段 5）；当前可交付的部署入口仍是本地 Docker Compose（docker compose -f compose.yml up，前端 http://localhost:3020）；
• 后端就绪度：环境变量驱动的配置模型、S3 兼容的存储抽象与 Redis 队列后端，为 Azure 服务的注入预留了清晰的扩展点，而 Blob Storage 原生驱动、Service Bus 队列等属于待实现项。

对于希望在微软 Azure 上交付 PyCaret Control Plane 的团队，本文档与配套源码提供了完整的服务选型参考：Container Apps + PostgreSQL + Blob Storage + Redis Cache + Application Gateway + Key Vault + Application Insights 的组合，即该模块声明的目标拓扑；在模块正式发布前，团队可以依据后端配置模型（services/api/pycaret_server/config.py）先行规划环境变量与密钥注入方案，为后续terraform apply落地做好准备。