@freeCodeCamp：内部开发者平台能帮助团队加快交付速度，无需手动管理基础设施。在本指南中，Ayobami…

内部开发者平台可以帮助团队加快交付速度，无需手动管理基础设施。在本指南中，Ayoboba 将教你如何使用 Backstage、ArgoCD 和 Crossplane 构建一个这样的平台。你将学习如何将这些工具连接成一个自助服务平台，用于部署应用和配置基础设施。https://freecodecamp.org/news/how-to-build-an-internal-developer-platform-a-complete-guide-to-backstage-argocd-and-crossplane/… — # 如何构建内部开发者平台：Backstage、ArgoCD 和 Crossplane 完整指南 来源：https://www.freecodecamp.org/news/how-to-build-an-internal-developer-platform-a-complete-guide-to-backstage-argocd-and-crossplane/ 如何构建内部开发者平台：Backstage、ArgoCD 和 Crossplane 完整指南每个快速发展的工程团队最终都会遇到同一个瓶颈。开发人员需要一个新的预发布环境，于是提交工单。平台团队排队处理。两周后，环境创建好了。但它的配置与上一个略有不同，命名规范与生产环境不一致，缺少上一个环境拥有的可观测性组件。开发人员部署后，出了问题。没人知道原因。问题不在于工单队列。问题在于缺乏一个平台：一条铺好的道路，让开发人员能够自助获取基础设施、部署和环境，这些资源一致、可审计、安全，无需每个请求都依赖平台工程师。内部开发者平台（IDP）解决了这个问题。它不是要把平台工程师排除在外，而是将他们的工作从执行单个请求转变为构建能够自动执行这些请求的系统。本手册将使用三个 CNCF 工具构建一个生产级 IDP，这些工具在 2026 年构成了其核心：Backstage 作为开发者门户和软件目录，ArgoCD 作为 GitOps 持续交付引擎，Crossplane 作为 Kubernetes 原生基础设施控制平面。最终，你平台上的开发人员将能够配置一个云数据库、将应用部署到预发布环境、并在目录中注册一个新服务——所有这些都无需提交任何工单。 ## 目录 - 你将学到什么 (https://www.freecodecamp.org/news/how-to-build-an-internal-developer-platform-a-complete-guide-to-backstage-argocd-and-crossplane/#heading-what-youll-learn) - 先决条件 (https://www.freecodecamp.org/news/how-to-build-an-internal-developer-platform-a-complete-guide-to-backstage-argocd-and-crossplane/#heading-prerequisites) - 第 1 部分：IDP 架构——三层模型 (https://www.freecodecamp.org/news/how-to-build-an-internal-developer-platform-a-complete-guide-to-backstage-argocd-and-crossplane/#heading-part-1-idp-architecture-the-three-layer-model) - 第 2 部分：ArgoCD——GitOps 基础 (https://www.freecodecamp.org/news/how-to-build-an-internal-developer-platform-a-complete-guide-to-backstage-argocd-and-crossplane/#heading-part-2-argocd-the-gitops-foundation) - 第 3 部分：Crossplane——基础设施即 Kubernetes 资源 (https://www.freecodecamp.org/news/how-to-build-an-internal-developer-platform-a-complete-guide-to-backstage-argocd-and-crossplane/#heading-part-3-crossplane-infrastructure-as-kubernetes-resources) - 第 4 部分：Backstage——开发者门户 (https://www.freecodecamp.org/news/how-to-build-an-internal-developer-platform-a-complete-guide-to-backstage-argocd-and-crossplane/#heading-part-4-backstage-the-developer-portal) - 第 5 部分：整合——黄金路径 (https://www.freecodecamp.org/news/how-to-build-an-internal-developer-platform-a-complete-guide-to-backstage-argocd-and-crossplane/#heading-part-5-wiring-it-together-the-golden-path) - 第 6 部分：FinOps 集成——IDP 上的成本归属 (https://www.freecodecamp.org/news/how-to-build-an-internal-developer-platform-a-complete-guide-to-backstage-argocd-and-crossplane/#heading-part-6-finops-integration-cost-attribution-on-the-idp) - 第 7 部分：平台成熟度模型——衡量你的构建成果 (https://www.freecodecamp.org/news/how-to-build-an-internal-developer-platform-a-complete-guide-to-backstage-argocd-and-crossplane/#heading-part-7-the-platform-maturity-model-measuring-what-youve-built) - 最佳实践总结 (https://www.freecodecamp.org/news/how-to-build-an-internal-developer-platform-a-complete-guide-to-backstage-argocd-and-crossplane/#heading-best-practices-summary) - 资源 (https://www.freecodecamp.org/news/how-to-build-an-internal-developer-platform-a-complete-guide-to-backstage-argocd-and-crossplane/#heading-resources) ## 你将学到什么 - 三层 IDP 架构，以及为什么必须以特定顺序实现每一层 - 如何安装和配置 ArgoCD 及其 ApplicationSets，实现多环境 GitOps 交付 - 如何使用 Crossplane Compositions 将云基础设施定义为 Kubernetes 自定义资源 - 如何部署和配置 Backstage，包括软件目录和软件模板 - 如何将 Backstage、ArgoCD 和 Crossplane 整合成一个单一的自助黄金路径 - 如何在 IDP 上实现成本归属，使每个通过它配置的资源都携带团队和成本中心元数据 - 如何使用 CNCF 平台工程成熟度模型衡量 IDP 的成熟度 让我们开始构建吧。 ## 先决条件 在继续阅读之前，你应该具备： 知识： - 熟悉 Kubernetes：能够部署应用、编写 YAML 清单、理解命名空间和 RBAC - 基本 GitOps 理解：知道“Git 作为唯一真相来源”在实践中意味着什么 - 能够阅读 Helm、Terraform HCL 和 TypeScript - 理解 AWS 服务：EKS、RDS、S3、IAM 工具和访问权限： - 一个运行 Kubernetes 1.28 或更高版本的 EKS 集群，至少 3 个节点（m5.xlarge 或同等配置） - 已配置并指向你的集群的 kubectl - 已安装 Helm 3.12 或更高版本 - 已配置 AWS CLI v2，并具有配置步骤所需的管理员权限 - Node.js 18 或更高版本以及 Yarn（用于 Backstage） - 你控制的一个 GitHub 组织（用于 GitOps 仓库和 Backstage GitHub 集成） 配套仓库： git clone https://github.com/aayostem/platform-toolkit cd platform-toolkit 该仓库包含本指南中引用的所有清单、Helm values 文件、Crossplane Compositions 和 Backstage 模板。每个部分对应仓库中的一个目录。 预计时间： 完整的实现对于有经验的平台工程师来说需要一到两天。第 1-3 部分可以在上午完成，得到一个可工作的 GitOps 交付层。 ## 第 1 部分：IDP 架构——三层模型 ### 1.1 IDP 到底是什么 内部开发者平台不是一种工具。它是一种产品：平台团队构建和维护的工具、工作流和抽象集合，使应用开发人员能够快速行动而无需直接管理基础设施。这种区别很重要，因为它决定了每一个架构决策。工具只需要安装和配置。产品则需要为用户设计，根据反馈迭代，并通过用户是否真正采用来衡量。那些构建开发者喜爱的 IDP 的平台团队，其思维方式更像产品经理，而不是系统管理员。 DORA 2025 报告 (https://cloud.google.com/resources/content/2025-dora-ai-capabilities-model-report) 发现，近 90% 的企业现在都有某种形式的内部平台。但拥有一个平台和拥有一个开发者真正使用的平台是两回事。调查发现，开发者对内部平台的满意度差异很大。满意与不满意团队之间的差距，直接与平台团队是否将 IDP 视为一个有路线图和用户研究的产品，还是视为一个有工单队列的基础设施项目相关。本指南中的三个工具——Backstage、ArgoCD 和 Crossplane——是 2026 年生产级 IDP 最广泛采用的开源栈。但连接它们的架构与工具本身同样重要。 ### 1.2 三层架构 一个生产级 IDP 包含三个不同的层，每层只有一个职责： 第 1 层：开发者界面 (Backstage) ├── 软件目录——所有服务、API 和资源的清单 ├── 软件模板——触发配置工作流的自助表单 ├── TechDocs——与每个目录实体共存的文档 └── 插件——与 ArgoCD、Kubernetes、PagerDuty、Grafana 的集成 第 2 层：交付层 (ArgoCD) ├── GitOps 同步——持续将集群状态与 Git 保持一致 ├── ApplicationSets——从单个定义进行多环境部署 ├── 发布管理——带健康检查的渐进式交付 └── 审计轨迹——每个部署变更都与 Git 提交关联 第 3 层：基础设施层 (Crossplane) ├── Composite Resources——定义为 Kubernetes CRD 的云资源 ├── Compositions——将简单声明扩展为完整 AWS 基础设施的模板 ├── ProviderConfigs——每个云提供商的凭证和区域配置 └── 使用跟踪——每个配置的资源都带有团队和成本中心标签 关键的架构规则：Backstage 从不直接与 Kubernetes 或云 API 通信。当开发人员在 Backstage 中提交软件模板时，输出是一个 Git 提交——一个代表 Crossplane 声明或 ArgoCD Application 清单的 YAML 文件。ArgoCD 获取该提交并将其应用到集群。Crossplane 将集群资源转换为实际的云基础设施。这种间接路径不是为了复杂而复杂。它意味着每一个基础设施变更都是一个 Git 提交，有作者、时间戳、拉取请求和审查。审计轨迹是自动的。回滚机制就是 git revert。 开发者 → Backstage 模板 → Git 提交 → ArgoCD → Crossplane → AWS ↑ 单一真相来源 完整的审计轨迹 回滚 = git revert 以下是错误的替代方案——Backstage 直接调用云 API： // 错误：Backstage 模板直接调用 AWS SDK // 没有审计轨迹，没有回滚，没有协调循环 // 如果调用中途失败，你会得到部分基础设施，没有记录 import { S3Client, CreateBucketCommand } from "@aws-sdk/client-s3"; const client = new S3Client({ region: "us-east-1" }); await client.send(new CreateBucketCommand({ Bucket: bucketName })); 正确的方法——Backstage 将 Crossplane 声明输出到 Git： # 正确：Backstage 模板输出——提交到 Git 的 Crossplane 声明 # ArgoCD 应用它，Crossplane 协调它，AWS 创建存储桶 # 每一步都被跟踪、可审计、可逆 apiVersion: platform.cloudfrugal.com/v1alpha1 kind: S3Bucket metadata: name: ${{ values.bucket_name }} namespace: ${{ values.team_namespace }} labels: team: ${{ values.team_name }} cost-centre: ${{ values.cost_centre }} environment: ${{ values.environment }} spec: versioning: true encryption: AES256 region: us-east-1 ### 1.3 实现顺序 按此顺序构建。偏离这个顺序会产生难以调试的集成问题： 第 1 步：ArgoCD——其他一切依赖的交付基础 第 2 步：Crossplane——基础设施控制平面，由 ArgoCD 交付 第 3 步：Backstage——门户，将 ArgoCD 和 Crossplane 作为后端 第 4 步：整合——生成 GitOps 清单的软件模板 第 5 步：FinOps 层——每个配置资源中的成本归属元数据 ## 第 2 部分：ArgoCD——GitOps 基础 ArgoCD 是 Kubernetes 的声明式持续交付工具，实现了 GitOps 模式。如果你以前没用过 GitOps 工具，核心思想很简单：你的 Git 仓库是集群中应该运行什么的唯一真相来源，ArgoCD 持续协调实际集群状态以匹配它。如果开发人员手动更改集群中的资源，ArgoCD 会检测到漂移并从 Git 重新同步。如果 Git 发生变化，ArgoCD 会将更改应用到集群。不需要人工干预，也不鼓励人工干预——目标是集群状态始终完全由 Git 中的内容解释。 ArgoCD 是 CNCF 毕业项目，意味着它已生产就绪并被广泛使用。它作为一组 Pod 在你的集群中运行，提供 Web UI、CLI 和 REST API。管理跨多个环境部署所需的一切都在一个地方。 ### 2.1 安装 ArgoCD # 创建 argocd 命名空间 kubectl create namespace argocd # 使用官方清单安装 ArgoCD kubectl apply -n argocd \ -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml # 等待所有 Pod 运行后再继续 kubectl wait --for=condition=Ready pods \ --all -n argocd --timeout=300s # 获取初始管理员密码 argocd_password=$(kubectl -n argocd get secret argocd-initial-admin-secret \ -o jsonpath="{.data.password}" | base64 -d) echo "ArgoCD 初始密码: $argocd_password" echo "在继续之前请安全保存此密码" # 端口转发以本地访问 ArgoCD UI kubectl port-forward svc/argocd-server -n argocd 8080:443 & # 通过 CLI 登录 argocd login localhost:8080 \ --username admin \ --password "$argocd_password" \ --insecure # 立即更改密码 argocd account update-password \ --current-password "$argocd_password" \ --new-password "your-secure-password" ### 2.2 GitOps 的仓库结构 ArgoCD 监视的仓库结构决定了你如何管理多个环境。最可扩展的模式是按环境划分目录，并使用 Kustomize 管理覆盖层。Kustomize 是一种 Kubernetes 原生配置管理工具，允许你定义一次基础配置，然后在其上叠加特定于环境的覆盖。这意味着你的预发布和生产配置共享相同的 YAML 结构，但在副本数、镜像标签和资源限制上有所不同。 gitops-repo/ ├── apps/ │ ├── base/ # 所有环境共享的配置 │ │ ├── payment-api/ │ │ │ ├── deployment.yaml │ │ │ ├── service.yaml │ │ │ └── kustomization.yaml │ │ └── user-api/ │ │ ├── deployment.yaml │ │ ├── service.yaml │ │ └── kustomization.yaml │ └── overlays/ │ ├── staging/ # 预发布特定覆盖 │ │ ├── payment-api/ │ │ │ └── kustomization.yaml # 覆盖：1 个副本，staging 镜像标签 │ │ └── kustomization.yaml │ └── production/ # 生产特定覆盖 │ ├── payment-api/ │ │ └── kustomization.yaml # 覆盖：3 个副本，固定镜像标签 │ └── kustomization.yaml └── infrastructure/ ├── crossplane/ # Crossplane 安装和提供商 ├── monitoring/ # Prometheus、Grafana └── ingress/ # NGINX 或 ALB ingress 控制器 ### 2.3 ApplicationSets——管理多个环境 ApplicationSet 是一种 ArgoCD 资源，可以从单个模板生成多个 Application 对象。不必为每个服务的每个环境创建一个 Application 清单——这在规模上会变得难以管理——而是定义一个覆盖所有服务在所有环境中的 ApplicationSet。矩阵生成器将环境列表与 Git 目录扫描结合起来，自动生成每个组合： `` # applicationset-apps.yaml # 这个单一资源为每个环境和应用目录的组合生成一个 ArgoCD Application apiVersion: argoproj.io/v1alpha1 kind: ApplicationSet metadata: name: platform-apps namespace: argocd spec: generators: - matrix: generators: # 生成器 1：环境 - list: elements: - environment: staging cluster: https://staging.eks.cluster.local - environment: production cluster: https://production.eks.cluster.local # 生成器 2：overlay 中的应用目录 - git: repoURL: https://github.com/your-org/gitops-repo revision: HEAD directories: - pa