拓冰网站定制 
【免费下载链接】pycaretOpen-source, low-code AutoML platform for Python. PyCaret 4.0: sklearn-native engine React control plane.项目地址https://gitcode.com/gh_mirrors/py/pycaret点击查看免费下载导读infra/terraform/是 PyCaret 平台为「企业云模式」预留的一键部署基础设施为 AWS、GCP、Azure 三个云厂商各提供一个自包含的 Terraform 模块让运维人员从零账本开始用一次terraform apply拉起完整的 Control PlaneAPI Worker 数据库 对象存储 缓存 密钥 日志。本文以仓库中的 infra/terraform/README.md 为骨架结合 docs/revamp/CONTROL_PLANE_SPEC.md 与 docs/revamp/PLATFORM_ARCHITECTURE.md 中的架构决策讲清模块现状、目标文件布局、三方云资源矩阵、最小变量面设计以及它与本地 Docker Compose 部署的边界关系。读完你将对 PyCaret 从单机到云的生产部署路径有完整认知并知道当模块正式落地时应如何接入。状态说明当前infra/terraform/三个云子目录均为V2 stub占位模块尚未包含可运行的.tf文件。本文属于目标设计文档解读所有文件布局与变量规划以仓库文档为准实际资源会随 V2 开发推进而实现。一、模块定位Control Plane 的Cloud One-Click交付路径在 PyCaret 平台的部署策略中见 CONTROL_PLANE_SPEC.md § 18.1–18.5存在五条并行的部署路径部署方式场景状态18.1 本地开发make dev前端 后端 Worker SQLite 本地工件存储可用18.2 Docker Composedocker compose upapi worker postgres redis minio deployment-runner当前 MVPinfra/README.md18.3 Electron 桌面版React UI 本地 FastAPI SQLite 本地工件目录V218.4 企业 KubernetesHelm chart manifests Terraform 容器镜像V218.5 云一键部署infra/aws、infra/gcp、infra/azureTerraform 模块V2 stub本文主题Terraform 模块是 18.5 的载体目标是在自带云账号前提下把整套 Control Plane 基础设施一次性铺到云上。它并非替代 Helm而是与 18.4 互为补充Helm 管 Kubernetes 集群内的编排Terraform 管集群之外的托管资源数据库、对象存储、缓存、密钥、负载均衡、日志。平台愿景文档 VISION.md 对此的描述是An enterprise can deploy to their AWS account withterraform apply, get SSO audit logs, and satisfy compliance review.——即企业只需一次 apply即可获得 SSO、审计日志与合规审查能力。二、三方云资源矩阵一套 Control Plane三种云映射模块的核心设计是每个云一个自包含模块负责从零铺起整套 Control Plane。infra/terraform/README.md给出的资源映射矩阵如下云计算数据库对象存储缓存密钥日志AWSECS/Fargate可选 EKSRDS PostgresS3ElastiCacheSecrets ManagerCloudWatchGCPCloud Run可选 GKECloud SQLGCSMemorystoreSecret ManagerCloud LoggingAzureContainer Apps可选 AKSAzure Database for PostgreSQLBlob StorageAzure CacheKey VaultApp Insights三个云的子模块 README 各自确认了目标组合infra/terraform/aws/README.mdECS/Fargate或可选 EKS RDS Postgres S3 ElastiCache ALB Secrets Manager CloudWatchinfra/terraform/gcp/README.mdCloud Run或可选 GKE Cloud SQL Postgres GCS Memorystore Cloud Load Balancer Secret Manager Cloud Logginginfra/terraform/azure/README.mdAzure Container Apps或可选 AKS Azure Database for PostgreSQL Blob Storage Azure Cache for Redis Application Gateway Key Vault Application Insights。对照平台后端抽象矩阵见 PLATFORM_ARCHITECTURE.md § 2可以发现 Terraform 铺的每一类托管资源都与平台七大后端槽位一一对应storageS3/GCS/Blob ↔S3ObjectStore/MinioObjectStore、databaseRDS/Cloud SQL/Azure PG ↔postgresqlpsycopg://、secretsSecrets Manager/Secret Manager/Key Vault ↔SecretsManagerBackend、queueSQS/Cloud Pub/Sub/Azure Service Bus ↔SqsBackend、computeFargate/Cloud Run/Container Apps ↔FargateTaskRunner、notifierSES ↔SesNotifier。也就是说Terraform 模块铺出的资源正是插拔后端架构在云上的具体落点——架构文档定义后端协议Terraform 定义这些协议实现所需的云资源。从源码结构看PLATFORM_ARCHITECTURE.md § 6 的分阶段计划GCP/Azure 模块被规划在 Phase 5 Multi-cloud 阶段AWS 模块则是 Phase 2 AWS pack 的交付物之一。三、最小变量面设计region、domain、tier模块的核心可用性主张是Variables expose the minimum surface (region, domain, tier), everything else is defaulted——对外暴露的变量面被刻意压到最小其余全部走默认值。三个变量即构成运维人员的最少输入变量作用域说明region云区域如us-east-1AWS决定所有托管资源所在地domain域名如ml.example.com用于 ALB/负载均衡 TLS 证书 Route53/DNS 绑定tier资源规格档位如small一个语义化档位内部映射到 CPU/内存/数据库实例规格AWS 子模块 README 给出了模块消费示例这是当前仓库中唯一一段 Terraform 调用示例module pycaret { source github.com/pycaret/pycaret//infra/terraform/aws?refv4 region us-east-1 domain ml.example.com tier small # small | medium | large # ... everything else defaulted }注意该示例使用了source github.com/pycaret/pycaret//infra/terraform/aws?refv4的模块引用方式//表示子目录refv4锁定版本。这意味着模块按版本化可复用模块registry 风格设计可在组织内多处复用。tier的设计意图是屏蔽底层规格细节small | medium | large三档覆盖从 POC 到生产的典型需求具体映射如ecs_task_cpu、rds_tier在variables.tf中展开见下文文件布局。四、预期文件布局模块内部分工文档明确给出了当 AWS 模块真正开工时的目录布局每个云模块预计同样结构infra/terraform/aws/ ├── main.tf # entry module ├── variables.tf # region, domain, ecs_task_cpu, rds_tier, ... ├── outputs.tf # endpoint URLs, db host, object bucket name ├── iam.tf ├── ecs.tf ├── rds.tf ├── s3.tf ├── alb.tf ├── secrets.tf └── README.md # per-cloud getting-started各文件职责与关键输出设计如下main.tf模块入口负责声明 provider、组装子资源与输出variables.tf变量声明除region/domain/tier外还包括ecs_task_cpu任务 CPU、rds_tier数据库实例档等细粒度旋钮与tier语义档位互补outputs.tf对外暴露 endpoint URLsAPI 访问地址、db host数据库主机、object bucket name存储桶名——这些输出正是平台后端FastAPI 应用接入云资源所需的连接信息iam.tfIAM 角色与策略ECS 任务角色、Worker 的 SQS/S3 权限等ecs.tf/rds.tf/s3.tf/alb.tf/secrets.tf分别管理计算集群、数据库、对象存储、负载均衡、密钥服务README.md该云专属的 getting-started 手册。五、AWS 目标架构从 Route53 到 SQS 的端到端拓扑PLATFORM_ARCHITECTURE.md § 5 给出了 AWS 模块的完整目标拓扑这也是参考实现最具体的云架构图景┌─ AWS account ──────────────────────────────────────────────┐ │ │ │ Route53 ── ACM ── ALB ────────┐ │ │ ▼ │ │ ┌─────────────┴────────────┐ │ │ │ ECS Fargate cluster │ │ │ │ ┌──────┐ ┌──────────┐ │ │ │ │ │ api │ │ worker │ │ │ │ │ │ x2 │ │ x2 │ │ │ │ │ └──┬───┘ └────┬─────┘ │ │ │ └─────┼──────────┼─────────┘ │ │ │ │ │ │ ┌────────────────┴──────────┴─────────────┐ │ │ │ │ │ │ ┌────▼─────┐ ┌──────────┐ ┌────────────┐ ┌──▼──────┐ │ │ │ RDS PG │ │ S3 bkt │ │ SecretsMgr │ │ SQS │ │ │ │ (state) │ │artifacts │ │ JWTFernet │ │ job q │ │ │ └──────────┘ └──────────┘ └────────────┘ └─────────┘ │ │ │ └─────────────────────────────────────────────────────────────┘关键设计点流量路径Route53DNS→ ACMTLS 证书→ ALB应用负载均衡→ ECS Fargate 集群集群内api与worker各起两个任务副本保证基本高可用数据平面RDS Postgres 承载平台关系状态S3 桶存放训练工件artifactsSecrets Manager 保存 JWT 签名密钥与 Fernet 加密密钥SQS 充当作业队列输入与输出契约输入为 domain 名称、实例规格、环境dev/staging/prod输出为 API URL 与创建首个管理员账号的命令并附带 SSO 配置所需的 IAM 信息。对应的目标 DevOps 流程cd infra/terraform/aws terraform init terraform apply -var domainml.acme.com -var envprod # … 8 min … terraform output # → https://ml.acme.com, plus IAM bits for SSO setup注上述env变量为架构文档示例用法模块当前 stub实际变量名以未来实现的variables.tf为准。六、安全边界Terraform 与运行时的职责分离模块设计中最值得强调的架构原则是Terraform 配置基础设施、运行时绝不配置云这一安全边界PLATFORM_ARCHITECTURE.md § 5Boundary:Terraform configures infrastructure. The running BE/UI never configures AWS — too dangerous a security boundary (cross-account write privs from a UI? no thanks). For Connect to AWS from the UI parity (Snowflake-style) we use IAM role assumption at the worker layer, never raw access keys in the app DB.翻译成可操作的规则所有云资源创建/销毁只发生在terraform apply时由运维人员触发应用后端与前端 UI 在运行期不具备任何跨账号写权限杜绝从 UI 改 AWS 配置的越权通道需要从 UI 连接云端能力时对标 Snowflake 式体验走 Worker 层的IAM role assumption角色代入应用数据库里永不落盘原始访问密钥access keys。这与平台整体的插拔后端哲学一脉相承后端选择是配置config而不是if AWS:分支。同一套代码既能在笔记本上docker compose up也能在 AWS 上由 Terraform 铺开处理器代码完全无感知PLATFORM_ARCHITECTURE.md § 1。七、与本地部署的关系一条代码、两级规模Terraform 云模块并不是一个孤立的独立发行版而是同一 Control Plane 代码库的另一种铺装方式。仓库中infra/的布局清楚地体现了这种分层infra/README.mdinfra/ ├── docker/ # local single-server distribution当前 MVP ├── helm/ # Kubernetes chart (V2 stub) └── terraform/ # one-click cloud modules (V2 stubs) ├── aws/ ├── gcp/ └── azure/当前处于激活状态的是infra/docker/本地 Compose 全栈入口见 infra/docker/docker-compose.prod.yml包含 postgres、redis、minio、api、worker、web 六个服务Terraform 与 Helm 均为 V2 规划项ARCHITECTURE.md 亦标注 V2 stubs。部署路径演进逻辑是local-first, cloud-second, multi-cloud-thirdPLATFORM_ARCHITECTURE.md § 6Phase 0当前本地单进程SQLite 文件系统 进程内 Worker Fernet-in-DBdocker compose up可用Phase 1抽取 5 个缺失的 Backend 协议默认行为零变化Phase 2AWS pack——实现S3ObjectStore已就绪、SecretsManagerBackend、SqsBackend、FargateTaskRunner、SesNotifier并交付infra/terraform/aws/Phase 5多云——GCP packCloud SQL、GCS、Cloud Run、Pub/Sub与 Azure packAzure SQL、Blob、Container Apps、Service Bus。因此Terraform 模块的实际可运行代码依赖 Phase 2 以后的后端抽象落地在 V2 完成前云上运行仍以 Docker Compose 部署到单台云主机为过渡手段。模块本身被明确规划为 self-hosted 边界PLATFORM_ARCHITECTURE.md § 7它部署到客户自带的云账号而非由 PyCaret 平台代管客户账号——Customer brings their own AWS account; Terraform is the boundary.八、仓库中的相关证据与延伸阅读模块总览与资源矩阵infra/terraform/README.md各云 stubinfra/terraform/aws/README.md、infra/terraform/gcp/README.md、infra/terraform/azure/README.md部署策略 18.5 定义与仓库结构图CONTROL_PLANE_SPEC.md § 18–19AWS 目标拓扑与安全边界PLATFORM_ARCHITECTURE.md § 5七大后端抽象矩阵与分阶段路线PLATFORM_ARCHITECTURE.md § 2 / § 6基础设施目录总览含 Docker 当前 MVP 与 Helm/terraform 路线infra/README.md愿景与路线图VISION.md、ROADMAP.md、STATUS.md结论infra/terraform是 PyCaret 平台企业云模式的落地骨架以每云一个自包含模块 最小变量面 资源全默认为设计原则为 AWS/GCP/Azure 各规划了一套与平台七大后端抽象一一对应的托管资源栈。当前以占位 stub 形态存在于仓库中其实现节奏被编排进 Phase 2AWS与 Phase 5GCP/Azure。对运维团队而言当模块正式可用时接入路径将是以region/domain/tier三个变量消费模块 →terraform init terraform apply→ 从outputs.tf取回 API 地址与数据库连接信息 → 在 Worker 层通过 IAM role assumption 完成云端能力对接。这一设计同时保证了配置即后端选择、Terraform 即安全边界两条架构红线。赞分享【免费下载链接】pycaretOpen-source, low-code AutoML platform for Python. PyCaret 4.0: sklearn-native engine React control plane.项目地址https://gitcode.com/gh_mirrors/py/pycaret点击查看免费下载相关推荐PyCaret 4.0 部署基础设施指南Docker Compose、Kubernetes Helm 与 Terraform 云部署全解析PyCaret 4.0 部署基础设施指南Docker Compose、Kubernetes Helm 与 Terraform 云部署全解析 PyCaret 4如何使用nli-mpnet-base-v2进行文本聚类完整指南与实战示例如何使用nli mpnet base v2进行文本聚类完整指南与实战示例 在当今信息爆炸的时代文本聚类技术成为了处理海量文本数据的关键工具。 nli mpn上一篇workerd 旧版模块注册表Legacy Module Registry深入解析从 V8 模块 API 到 Worker 模块加载全流程下一篇WarcraftHelper终极指南让经典魔兽3在现代电脑上完美运行创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 PyCaret Control Plane 云部署 Terraform 模块：`infra/terraform` 的架构目标与三方云落地规划
【免费下载链接】pycaretOpen-source, low-code AutoML platform for Python. PyCaret 4.0: sklearn-native engine React control plane.项目地址https://gitcode.com/gh_mirrors/py/pycaret点击查看免费下载导读infra/terraform/是 PyCaret 平台为「企业云模式」预留的一键部署基础设施为 AWS、GCP、Azure 三个云厂商各提供一个自包含的 Terraform 模块让运维人员从零账本开始用一次terraform apply拉起完整的 Control PlaneAPI Worker 数据库 对象存储 缓存 密钥 日志。本文以仓库中的 infra/terraform/README.md 为骨架结合 docs/revamp/CONTROL_PLANE_SPEC.md 与 docs/revamp/PLATFORM_ARCHITECTURE.md 中的架构决策讲清模块现状、目标文件布局、三方云资源矩阵、最小变量面设计以及它与本地 Docker Compose 部署的边界关系。读完你将对 PyCaret 从单机到云的生产部署路径有完整认知并知道当模块正式落地时应如何接入。状态说明当前infra/terraform/三个云子目录均为V2 stub占位模块尚未包含可运行的.tf文件。本文属于目标设计文档解读所有文件布局与变量规划以仓库文档为准实际资源会随 V2 开发推进而实现。一、模块定位Control Plane 的Cloud One-Click交付路径在 PyCaret 平台的部署策略中见 CONTROL_PLANE_SPEC.md § 18.1–18.5存在五条并行的部署路径部署方式场景状态18.1 本地开发make dev前端 后端 Worker SQLite 本地工件存储可用18.2 Docker Composedocker compose upapi worker postgres redis minio deployment-runner当前 MVPinfra/README.md18.3 Electron 桌面版React UI 本地 FastAPI SQLite 本地工件目录V218.4 企业 KubernetesHelm chart manifests Terraform 容器镜像V218.5 云一键部署infra/aws、infra/gcp、infra/azureTerraform 模块V2 stub本文主题Terraform 模块是 18.5 的载体目标是在自带云账号前提下把整套 Control Plane 基础设施一次性铺到云上。它并非替代 Helm而是与 18.4 互为补充Helm 管 Kubernetes 集群内的编排Terraform 管集群之外的托管资源数据库、对象存储、缓存、密钥、负载均衡、日志。平台愿景文档 VISION.md 对此的描述是An enterprise can deploy to their AWS account withterraform apply, get SSO audit logs, and satisfy compliance review.——即企业只需一次 apply即可获得 SSO、审计日志与合规审查能力。二、三方云资源矩阵一套 Control Plane三种云映射模块的核心设计是每个云一个自包含模块负责从零铺起整套 Control Plane。infra/terraform/README.md给出的资源映射矩阵如下云计算数据库对象存储缓存密钥日志AWSECS/Fargate可选 EKSRDS PostgresS3ElastiCacheSecrets ManagerCloudWatchGCPCloud Run可选 GKECloud SQLGCSMemorystoreSecret ManagerCloud LoggingAzureContainer Apps可选 AKSAzure Database for PostgreSQLBlob StorageAzure CacheKey VaultApp Insights三个云的子模块 README 各自确认了目标组合infra/terraform/aws/README.mdECS/Fargate或可选 EKS RDS Postgres S3 ElastiCache ALB Secrets Manager CloudWatchinfra/terraform/gcp/README.mdCloud Run或可选 GKE Cloud SQL Postgres GCS Memorystore Cloud Load Balancer Secret Manager Cloud Logginginfra/terraform/azure/README.mdAzure Container Apps或可选 AKS Azure Database for PostgreSQL Blob Storage Azure Cache for Redis Application Gateway Key Vault Application Insights。对照平台后端抽象矩阵见 PLATFORM_ARCHITECTURE.md § 2可以发现 Terraform 铺的每一类托管资源都与平台七大后端槽位一一对应storageS3/GCS/Blob ↔S3ObjectStore/MinioObjectStore、databaseRDS/Cloud SQL/Azure PG ↔postgresqlpsycopg://、secretsSecrets Manager/Secret Manager/Key Vault ↔SecretsManagerBackend、queueSQS/Cloud Pub/Sub/Azure Service Bus ↔SqsBackend、computeFargate/Cloud Run/Container Apps ↔FargateTaskRunner、notifierSES ↔SesNotifier。也就是说Terraform 模块铺出的资源正是插拔后端架构在云上的具体落点——架构文档定义后端协议Terraform 定义这些协议实现所需的云资源。从源码结构看PLATFORM_ARCHITECTURE.md § 6 的分阶段计划GCP/Azure 模块被规划在 Phase 5 Multi-cloud 阶段AWS 模块则是 Phase 2 AWS pack 的交付物之一。三、最小变量面设计region、domain、tier模块的核心可用性主张是Variables expose the minimum surface (region, domain, tier), everything else is defaulted——对外暴露的变量面被刻意压到最小其余全部走默认值。三个变量即构成运维人员的最少输入变量作用域说明region云区域如us-east-1AWS决定所有托管资源所在地domain域名如ml.example.com用于 ALB/负载均衡 TLS 证书 Route53/DNS 绑定tier资源规格档位如small一个语义化档位内部映射到 CPU/内存/数据库实例规格AWS 子模块 README 给出了模块消费示例这是当前仓库中唯一一段 Terraform 调用示例module pycaret { source github.com/pycaret/pycaret//infra/terraform/aws?refv4 region us-east-1 domain ml.example.com tier small # small | medium | large # ... everything else defaulted }注意该示例使用了source github.com/pycaret/pycaret//infra/terraform/aws?refv4的模块引用方式//表示子目录refv4锁定版本。这意味着模块按版本化可复用模块registry 风格设计可在组织内多处复用。tier的设计意图是屏蔽底层规格细节small | medium | large三档覆盖从 POC 到生产的典型需求具体映射如ecs_task_cpu、rds_tier在variables.tf中展开见下文文件布局。四、预期文件布局模块内部分工文档明确给出了当 AWS 模块真正开工时的目录布局每个云模块预计同样结构infra/terraform/aws/ ├── main.tf # entry module ├── variables.tf # region, domain, ecs_task_cpu, rds_tier, ... ├── outputs.tf # endpoint URLs, db host, object bucket name ├── iam.tf ├── ecs.tf ├── rds.tf ├── s3.tf ├── alb.tf ├── secrets.tf └── README.md # per-cloud getting-started各文件职责与关键输出设计如下main.tf模块入口负责声明 provider、组装子资源与输出variables.tf变量声明除region/domain/tier外还包括ecs_task_cpu任务 CPU、rds_tier数据库实例档等细粒度旋钮与tier语义档位互补outputs.tf对外暴露 endpoint URLsAPI 访问地址、db host数据库主机、object bucket name存储桶名——这些输出正是平台后端FastAPI 应用接入云资源所需的连接信息iam.tfIAM 角色与策略ECS 任务角色、Worker 的 SQS/S3 权限等ecs.tf/rds.tf/s3.tf/alb.tf/secrets.tf分别管理计算集群、数据库、对象存储、负载均衡、密钥服务README.md该云专属的 getting-started 手册。五、AWS 目标架构从 Route53 到 SQS 的端到端拓扑PLATFORM_ARCHITECTURE.md § 5 给出了 AWS 模块的完整目标拓扑这也是参考实现最具体的云架构图景┌─ AWS account ──────────────────────────────────────────────┐ │ │ │ Route53 ── ACM ── ALB ────────┐ │ │ ▼ │ │ ┌─────────────┴────────────┐ │ │ │ ECS Fargate cluster │ │ │ │ ┌──────┐ ┌──────────┐ │ │ │ │ │ api │ │ worker │ │ │ │ │ │ x2 │ │ x2 │ │ │ │ │ └──┬───┘ └────┬─────┘ │ │ │ └─────┼──────────┼─────────┘ │ │ │ │ │ │ ┌────────────────┴──────────┴─────────────┐ │ │ │ │ │ │ ┌────▼─────┐ ┌──────────┐ ┌────────────┐ ┌──▼──────┐ │ │ │ RDS PG │ │ S3 bkt │ │ SecretsMgr │ │ SQS │ │ │ │ (state) │ │artifacts │ │ JWTFernet │ │ job q │ │ │ └──────────┘ └──────────┘ └────────────┘ └─────────┘ │ │ │ └─────────────────────────────────────────────────────────────┘关键设计点流量路径Route53DNS→ ACMTLS 证书→ ALB应用负载均衡→ ECS Fargate 集群集群内api与worker各起两个任务副本保证基本高可用数据平面RDS Postgres 承载平台关系状态S3 桶存放训练工件artifactsSecrets Manager 保存 JWT 签名密钥与 Fernet 加密密钥SQS 充当作业队列输入与输出契约输入为 domain 名称、实例规格、环境dev/staging/prod输出为 API URL 与创建首个管理员账号的命令并附带 SSO 配置所需的 IAM 信息。对应的目标 DevOps 流程cd infra/terraform/aws terraform init terraform apply -var domainml.acme.com -var envprod # … 8 min … terraform output # → https://ml.acme.com, plus IAM bits for SSO setup注上述env变量为架构文档示例用法模块当前 stub实际变量名以未来实现的variables.tf为准。六、安全边界Terraform 与运行时的职责分离模块设计中最值得强调的架构原则是Terraform 配置基础设施、运行时绝不配置云这一安全边界PLATFORM_ARCHITECTURE.md § 5Boundary:Terraform configures infrastructure. The running BE/UI never configures AWS — too dangerous a security boundary (cross-account write privs from a UI? no thanks). For Connect to AWS from the UI parity (Snowflake-style) we use IAM role assumption at the worker layer, never raw access keys in the app DB.翻译成可操作的规则所有云资源创建/销毁只发生在terraform apply时由运维人员触发应用后端与前端 UI 在运行期不具备任何跨账号写权限杜绝从 UI 改 AWS 配置的越权通道需要从 UI 连接云端能力时对标 Snowflake 式体验走 Worker 层的IAM role assumption角色代入应用数据库里永不落盘原始访问密钥access keys。这与平台整体的插拔后端哲学一脉相承后端选择是配置config而不是if AWS:分支。同一套代码既能在笔记本上docker compose up也能在 AWS 上由 Terraform 铺开处理器代码完全无感知PLATFORM_ARCHITECTURE.md § 1。七、与本地部署的关系一条代码、两级规模Terraform 云模块并不是一个孤立的独立发行版而是同一 Control Plane 代码库的另一种铺装方式。仓库中infra/的布局清楚地体现了这种分层infra/README.mdinfra/ ├── docker/ # local single-server distribution当前 MVP ├── helm/ # Kubernetes chart (V2 stub) └── terraform/ # one-click cloud modules (V2 stubs) ├── aws/ ├── gcp/ └── azure/当前处于激活状态的是infra/docker/本地 Compose 全栈入口见 infra/docker/docker-compose.prod.yml包含 postgres、redis、minio、api、worker、web 六个服务Terraform 与 Helm 均为 V2 规划项ARCHITECTURE.md 亦标注 V2 stubs。部署路径演进逻辑是local-first, cloud-second, multi-cloud-thirdPLATFORM_ARCHITECTURE.md § 6Phase 0当前本地单进程SQLite 文件系统 进程内 Worker Fernet-in-DBdocker compose up可用Phase 1抽取 5 个缺失的 Backend 协议默认行为零变化Phase 2AWS pack——实现S3ObjectStore已就绪、SecretsManagerBackend、SqsBackend、FargateTaskRunner、SesNotifier并交付infra/terraform/aws/Phase 5多云——GCP packCloud SQL、GCS、Cloud Run、Pub/Sub与 Azure packAzure SQL、Blob、Container Apps、Service Bus。因此Terraform 模块的实际可运行代码依赖 Phase 2 以后的后端抽象落地在 V2 完成前云上运行仍以 Docker Compose 部署到单台云主机为过渡手段。模块本身被明确规划为 self-hosted 边界PLATFORM_ARCHITECTURE.md § 7它部署到客户自带的云账号而非由 PyCaret 平台代管客户账号——Customer brings their own AWS account; Terraform is the boundary.八、仓库中的相关证据与延伸阅读模块总览与资源矩阵infra/terraform/README.md各云 stubinfra/terraform/aws/README.md、infra/terraform/gcp/README.md、infra/terraform/azure/README.md部署策略 18.5 定义与仓库结构图CONTROL_PLANE_SPEC.md § 18–19AWS 目标拓扑与安全边界PLATFORM_ARCHITECTURE.md § 5七大后端抽象矩阵与分阶段路线PLATFORM_ARCHITECTURE.md § 2 / § 6基础设施目录总览含 Docker 当前 MVP 与 Helm/terraform 路线infra/README.md愿景与路线图VISION.md、ROADMAP.md、STATUS.md结论infra/terraform是 PyCaret 平台企业云模式的落地骨架以每云一个自包含模块 最小变量面 资源全默认为设计原则为 AWS/GCP/Azure 各规划了一套与平台七大后端抽象一一对应的托管资源栈。当前以占位 stub 形态存在于仓库中其实现节奏被编排进 Phase 2AWS与 Phase 5GCP/Azure。对运维团队而言当模块正式可用时接入路径将是以region/domain/tier三个变量消费模块 →terraform init terraform apply→ 从outputs.tf取回 API 地址与数据库连接信息 → 在 Worker 层通过 IAM role assumption 完成云端能力对接。这一设计同时保证了配置即后端选择、Terraform 即安全边界两条架构红线。赞分享【免费下载链接】pycaretOpen-source, low-code AutoML platform for Python. PyCaret 4.0: sklearn-native engine React control plane.项目地址https://gitcode.com/gh_mirrors/py/pycaret点击查看免费下载相关推荐PyCaret 4.0 部署基础设施指南Docker Compose、Kubernetes Helm 与 Terraform 云部署全解析PyCaret 4.0 部署基础设施指南Docker Compose、Kubernetes Helm 与 Terraform 云部署全解析 PyCaret 4如何使用nli-mpnet-base-v2进行文本聚类完整指南与实战示例如何使用nli mpnet base v2进行文本聚类完整指南与实战示例 在当今信息爆炸的时代文本聚类技术成为了处理海量文本数据的关键工具。 nli mpn上一篇workerd 旧版模块注册表Legacy Module Registry深入解析从 V8 模块 API 到 Worker 模块加载全流程下一篇WarcraftHelper终极指南让经典魔兽3在现代电脑上完美运行创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考