使用 Crossplane 接入应用
在当今的软件开发中,自动化部署和管理应用程序变得越来越重要。本文将探讨如何使用 Crossplane 实现应用程序的自动化部署,包括自动化需求分析、解决方案设计、控制平面配置、应用部署环境自动化、仓库和 CI 配置以及部署依赖管理等方面。
1. 自动化需求
假设有一个组织计划开发一个名为 product-a 的新电子商务网站。该网站有多个模块,如购物车、支付和客户支持等,每个模块需要独立发布和扩展,同时共享标准的网站主题和统一的用户体验。产品架构团队建议采用微前端架构,并在 Kubernetes 中对每个模块进行单独部署。此外,还建议由一个团队开发网站框架、共享 UI 组件和跨领域关注点,并以库的形式提供给独立模块团队使用。
产品团队听说了 Crossplane 能够实现应用程序的端到端自动化,希望借此机会开发一个全新的产品,并尝试使用 Crossplane 建立高速、可靠的产品开发实践。他们请求平台团队帮助开发一个概念验证(POC)项目。
2. 解决方案
解决方案分为三个步骤:
1. 自动化部署环境配置 :完全自动化 product-a 部署环境(Kubernetes)的配置和跨领域关注点的设置,以支持所有微前端的部署。
2. 应用接入 :包括创建新仓库和为特定微前端设置 CI 管道。
3. CD 管道和依赖基础设施配置 :为创建的仓库设置 CD 管道,并配置微前端所需的依赖基础设施(如数据库)。
将使用一组提供者,如 Helm、GitLab、GCP 和 Kubernetes 来实现这些步骤。
3. 准备控制平面
控制平面的配置分为四个阶段:
1. 准备 Crossplane 控制平面 :安装所需的提供者(GCP、Helm、Kubernetes 和 GitLab)和配置。
2. 创建 Kubernetes 集群 :使用 GCP 提供者创建一个 Kubernetes 集群来部署微前端。同时,在控制平面集群中创建 Helm 和 Kubernetes 提供者配置,以支持 Argo CD 的安装和微前端应用的部署。
3. 创建微前端仓库 :为每个微前端应用创建一个新仓库,并克隆 CI 管道。
4. 设置 CD 管道和数据库 :使用 Kubernetes 提供者为创建的仓库设置 CD 管道,并创建微前端所需的云数据库实例。
3.1 GCP 提供者配置
为了完成 GCP 提供者的设置,需要执行以下步骤:
1. 执行 GCP-Provider.yaml 安装提供者,并等待提供者 Pod 启动并运行。
2. 确保集群中存在包含 product-a GCP 服务账户的 Kubernetes Secret。该 Secret 将在提供者配置中引用。
3. 执行 Provider-Config.yaml 创建特定于产品的提供者配置,配置名称为 product-a 。
4. 应用 namespace.yaml 创建 product-a 命名空间,用于保存 Claim 对象。
# 安装 GCP 提供者
kubectl apply -f Step-1-ProviderSetup/Platform-OPS/GCP
kubectl apply -f Step-1-ProviderSetup/Platform-OPS/GCP/product-a
3.2 GitLab 提供者配置
使用 GitLab 提供者管理微前端仓库和 CI 管道,设置步骤如下:
1. 创建 GitLab 凭证 :在 GitLab UI 用户设置中生成访问令牌,并使用以下命令将其创建为 Kubernetes Secret:
kubectl create secret generic gitlab-credentials -n crossplane-system --from-literal=gitlab-credentials=<YOUR_ACCESS_TOKEN>
- 安装提供者 :执行
provider-gitlab.yaml安装 GitLab 提供者,并等待 Pod 启动并运行。 - 配置提供者 :执行
provider-config.yaml创建特定于产品的提供者配置,名称为product-a。
# 安装 GitLab 提供者
kubectl apply -f Step-1-ProviderSetup/Platform-OPS/Gitlab
kubectl apply -f Step-1-ProviderSetup/Platform-OPS/Gitlab/product-a
3.3 Helm 和 Kubernetes 提供者配置
Helm 和 Kubernetes 提供者用于配置远程或本地的 Kubernetes 集群。目前只需安装提供者:
# 安装 Helm 提供者
kubectl apply -f Step-1-ProviderSetup/Platform-OPS/Helm
# 安装 Kubernetes 提供者
kubectl apply -f Step-1-ProviderSetup/Platform-OPS/k8s
4. 自动化应用部署环境
通过开发 XR/claim API 来自动化 Kubernetes 集群的创建和跨领域关注点的配置,具体步骤如下:
1. 创建远程 GKE 集群 :使用 XR/claim API 提供远程 GKE 集群。
2. 设置提供者配置 :为 GKE 集群设置 Helm 和 Kubernetes 提供者配置。
3. 安装 Argo CD :使用 Helm 提供者在 product-a GKE 集群中安装 Argo CD。
以下是 API 的详细信息:
- XRD 和组合 :捕获两个必需参数(节点数量和机器大小),组合中包含五个资源,分别用于 GKE 集群配置、提供者配置和 Argo CD 安装。
- 资源列表 :
| 资源名称 | 用途 |
| ---- | ---- |
| Cluster 和 NodePool | 负责 GKE 集群的配置 |
| Helm 和 Kubernetes ProviderConfig | 为 GKE 集群设置提供者配置 |
| Argo CD | 为微前端仓库启用 CD |
# 安装 GCP 集群 XR/Claim API
kubectl apply -f Step-2-CreateProductTeamsKubernetesCluster/Platform-OPS
# 验证安装的 API 健康状态
kubectl get xrd
kubectl get composition
应用操作员可以使用以下命令创建 GKE 集群:
# 使用 Claim 对象创建 GCP 集群
kubectl apply -f Step-2-CreateProductTeamsKubernetesCluster/Application-OPS
# 验证 GKE 集群和 Argo CD 的健康状态
kubectl get GCPCluster -n product-a
kubectl get release
5. 仓库和 CI 设置
在这个阶段,将开发一个 XR/claim API 来克隆模板仓库,创建新的微前端仓库和 CI 管道。
5.1 GitLab 配置
在开发 XR/claim API 之前,需要在 GitLab 中进行以下一次性配置:
1. 创建模板项目 :创建一个模板仓库,用于克隆新的微前端仓库。可以访问 模板仓库 。
2. 创建产品组 :创建一个 GitLab 组来组织所有微前端仓库,并管理用户权限和 CI 管道的环境变量。可以访问 产品组 。
3. 设置环境变量 :在组级别设置环境变量,以允许 GitLab 管道访问 Docker Hub。
graph LR
A[创建模板项目] --> B[创建产品组]
B --> C[设置环境变量]
5.2 接入 XR/claim API
XRD(gitproject-xrd.yaml)接受两个参数作为输入:模板名称和组 ID。这两个参数使 API 具有通用性,可以在整个组织中使用。新创建的微前端仓库 URL 和访问令牌将存储为连接 Secret。
# 安装接入 API
kubectl apply -f Step-3-GitProjectOnboarding/Platform-OPS
# 验证安装的 API 健康状态
kubectl get xrd
kubectl get composition
应用操作员可以使用以下命令创建仓库和 CI 管道:
# 创建 claim 并验证
kubectl apply -f Step-3-GitProjectOnboarding/Application-OPS
kubectl get gitproject -n product-a
kubectl get xrd
通过以上步骤,就可以使用 Crossplane 实现应用程序的自动化部署,提高开发效率和部署的可靠性。后续将继续探讨部署依赖管理等方面的内容。
使用 Crossplane 接入应用
6. 部署依赖
最后一个阶段是自动化微前端的部署依赖,这主要涉及两个方面:
6.1 基础设施依赖
本步骤需要为微前端配置所需的基础设施依赖,这里以创建 GCP MySQL 数据库为例,为简化示例,仅考虑数据库这一依赖。
6.2 持续部署
模板仓库(https://gitlab.com/unified.devops/react-template/-/tree/main/template - helm)中的 template - helm 文件夹包含用于将应用部署到 Kubernetes 的 Helm 图表。为了以 GitOps 方式部署该 Helm 图表,需要在 product - a Kubernetes 集群中添加 Argo CD 配置以同步图表。将构建一个对象类型的 Kubernetes 提供者配置,用于将任何 Kubernetes 配置应用到目标集群。
将构建一个嵌套 XR 来满足上述需求, XWebApplication 作为父 API, XGCPdb 作为嵌套的内部 XR。父 API 接收产品 Git 组和数据库大小作为输入,微前端名称从 claim 名称派生。父组合将组合 Argo CD 配置和一个 XGCPdb 资源(内部 XR)。
以下是一些关键代码片段:
- 仓库 URL 补丁代码 :
- type: CombineFromComposite
toFieldPath: spec.forProvider.manifest.spec.source.repoURL
combine:
variables:
- fromFieldPath: spec.parameters.productGitGroup
- fromFieldPath: spec.claimRef.name
strategy: string
string:
fmt: "https://gitlab.com/%s/%s.git"
- 动态修补 Kubernetes 提供者配置名称 :
- fromFieldPath: spec.claimRef.namespace
toFieldPath: spec.providerConfigRef.name
transforms:
- type: string
string:
fmt: "%s - cluster - k8s - provider - config"
- 动态绑定 Docker 镜像名称 :
- fromFieldPath: spec.claimRef.name
toFieldPath: spec.forProvider.manifest.spec.source.helm.parameters[0].value
transforms:
- type: string
string:
fmt: "arunramakani/%s"
Argo CD 配置的关键部分如下:
source:
# 仓库 URL 待修补
repoURL: # To be patched
# Argo CD 查找更改的分支
# 代码准备发布时,切换到此分支
targetRevision: HEAD
# ArgoCD 自动同步查找的仓库文件夹
path: template - helm
helm:
# 待修补的发布名称
releaseName: # To be patched
parameters:
- name: "image.repository"
# 待修补的值
value: # To be patched
- name: "image.tag"
value: latest
- name: "service.port"
value: "3000"
destination:
# 表示目标 Kubernetes 集群是运行 ArgoCD 的本地 Kubernetes 集群
server: https://kubernetes.default.svc
# 应用部署的命名空间
namespace: # to be patched
为了在控制平面中建立和验证 API,执行以下命令:
kubectl apply -f Step - 4 - WebApplication/Platform - OPS/Application
kubectl apply -f Step - 4 - WebApplication/Platform - OPS/DB
kubectl get xrd
kubectl get composition
应用操作员可以使用以下 claim 配置来配置数据库作为基础设施依赖并设置 CD:
apiVersion: learn.unified.devops/v1alpha1
kind: WebApplication
metadata:
# 使用与仓库相同的名称
name: micro - frontend - one
namespace: product - a
spec:
compositionRef:
name: web - application - dev
parameters:
# GitLab 中产品 a 的组名称
productGitGroup: unified - devops - project - x
databaseSize: SMALL
应用操作员使用以下命令:
# 应用 claim
kubectl apply -f Step - 4 - WebApplication/Application - OPS
# 验证应用状态,包括数据库和 ArgoCD 配置
kubectl get webapplications - n product - a
kubectl get XGCPdb
kubectl get object
总结
通过以上一系列步骤,我们完成了使用 Crossplane 实现应用程序自动化部署的整个流程,涵盖了从自动化需求分析、解决方案设计、控制平面配置、应用部署环境自动化、仓库和 CI 配置到部署依赖管理的各个方面。以下是整个流程的关键步骤总结:
| 步骤 | 操作内容 |
|---|---|
| 1 | 明确自动化需求,确定产品架构和目标 |
| 2 | 制定三步骤解决方案,包括部署环境配置、应用接入、CD 管道和依赖基础设施配置 |
| 3 | 准备控制平面,安装并配置 GCP、GitLab、Helm 和 Kubernetes 提供者 |
| 4 | 自动化应用部署环境,创建 GKE 集群并安装 Argo CD |
| 5 | 进行仓库和 CI 设置,克隆模板仓库创建新的微前端仓库和 CI 管道 |
| 6 | 处理部署依赖,配置基础设施和持续部署 |
graph LR
A[自动化需求] --> B[解决方案]
B --> C[准备控制平面]
C --> D[自动化应用部署环境]
D --> E[仓库和 CI 设置]
E --> F[部署依赖]
通过遵循这些步骤,可以提高开发效率,确保部署的可靠性和一致性,为应用程序的开发和部署提供有力支持。
超级会员免费看
443

被折叠的 条评论
为什么被折叠?



