Argo CD Config Management PluginsCMP完整指南从 Sidecar 安装、发现规则到迁移与调试【免费下载链接】argo-cdDeclarative Continuous Deployment for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ar/argo-cdArgo CD 的原生配置管理工具是 Helm、Jsonnet 与 Kustomize当需要接入其他工具或原生支持无法满足特定需求时就需要引入 Config Management PluginCMP。本文以 docs/operator-manual/config-management-plugins.md 为核心系统讲解如何创建、安装、配置和使用 CMP你将掌握 Sidecar 插件的完整安装流程、发现Discovery规则、环境变量与参数传递机制、从旧版argocd-cmConfigMap 插件的迁移步骤以及常见问题的调试手段并结合仓库源码cmpserver/plugin/plugin.go、cmpserver/plugin/config.go、examples/plugins/helm理解其底层实现原理。说明本文对应文档原位于docs/user-guide/config-management-plugins.md现已迁移至 docs/operator-manual/config-management-plugins.md。CMP 的工作原理与信任边界Argo CD 的repo-server组件负责根据 Helm、OCI 或 Git 仓库中的源文件构建 Kubernetes 清单。当配置管理插件被正确配置后repo-server 可以将构建清单的任务委托给插件执行。CMP 的运行方式是在argocd-repo-serverPod 中注入一个Sidecar 容器该容器以argocd-cmp-server一个轻量级 gRPC 服务作为入口Argo CD 通过 Unix Socket 与该服务通信从而调用插件的init、generate、discover等命令。[!WARNING] 插件在 Argo CD 系统中被赋予一定程度的信任因此必须安全地实现插件。Argo CD 管理员只应从可信来源安装插件并应审计插件以权衡其特定的风险与收益。从源码结构看CMP 的 gRPC 服务暴露了GenerateManifest、MatchRepository、GetParametersAnnouncement、CheckPluginConfiguration四个核心 RPC见 cmpserver/plugin/plugin.go分别对应清单生成、仓库匹配发现、参数通告与插件配置校验整个服务器通过 Unix Socket 监听实现在 cmpserver/server.go。安装一个配置管理插件Sidecar 方式安装一个插件需要三步编写插件配置文件 → 将配置文件放入 Sidecar → 将插件注册为 repo-server 的 Sidecar 容器。第一步编写插件配置文件插件通过一个ConfigManagementPlugin 清单进行配置该清单存放在插件容器内部。下面是一个覆盖全部核心字段的完整示例apiVersion: argoproj.io/v1alpha1 kind: ConfigManagementPlugin metadata: # 插件名称在给定的 Argo CD 实例内必须唯一。 name: my-plugin spec: # 插件版本。可选。如果指定了版本Application 的 spec.source.plugin.name 字段 # 必须为 插件名-插件版本。 version: v1.0 # init 命令在每次清单生成开始时于 Application 源目录中运行。init 命令可以输出任何内容。 # 非零退出码将导致清单生成失败。 init: # init 总是在 generate 之前立即执行但其输出不会被视为清单。 # 这是下载 chart 依赖等操作的理想位置。 command: [sh] args: [-c, echo Initializing...] # generate 命令在每次生成清单时于 Application 源目录中运行。 # 标准输出必须 ONLY 是 YAML 或 JSON 格式的有效 Kubernetes 对象。 # 非零退出码将导致清单生成失败。 # 如需输出日志消息请写入 stderr它将始终被显示。 # 错误输出会发送到 UI因此避免打印敏感信息如密钥。 generate: command: [sh, -c] args: - | echo {\kind\: \ConfigMap\, \apiVersion\: \v1\, \metadata\: { \name\: \$ARGOCD_APP_NAME\, \namespace\: \$ARGOCD_APP_NAMESPACE\, \annotations\: {\Foo\: \$ARGOCD_ENV_FOO\, \KubeVersion\: \$KUBE_VERSION\, \KubeApiVersion\: \$KUBE_API_VERSIONS\,\Bar\: \baz\}}} # discovery 配置作用于仓库。如果每一个配置的 discovery 工具都匹配 # 则该插件可用于为该仓库的 Application 生成清单。 # 如果省略 discovery 配置则插件不会匹配任何 Application # 但可以通过在 app spec 中显式指定插件名来调用。 # fileName、find.glob、find.command 三者只能指定其一若指定多个仅第一个按此顺序会被评估。 discover: # fileName 是一个 glob 模式https://pkg.go.dev/path/filepath#Glob应用于 Application 的源目录。 # 如果有匹配则该插件可用于该 Application。 fileName: ./subdir/s*.yaml find: # glob 与 fileName 作用相同但支持双星号嵌套目录glob 模式。 glob: **/Chart.yaml # find 命令在仓库根目录运行。要匹配成功必须以状态码 0 退出 # 并且向标准输出产生非空输出。 command: [sh, -c, find . -name env.yaml] # parameters 配置描述 UI 应为 Application 显示哪些参数。 # 实际在 Application 清单中设置参数位于 spec.source.plugin.parameters由用户负责。 # 这些通告仅用于 App Details 页面的 Parameters 标签页。 parameters: # 静态参数通告会发送给该插件处理的所有 Application 的 UI。 # 这里的 string、array、map 值可视为默认值。 # 插件作者需要确保当用户未显式设置不同值时这些默认值真实反映插件的行为。 static: - name: string-param title: Description of the string param tooltip: Tooltip shown when the user hovers the # 若设置该字段UI 会提示用户必须设置该值。 required: false # itemType 告诉 UI 如何展示参数的值对于数组和 map 则是其元素。默认为 string。 # 未来可能支持 boolean 或 number 等其他类型。 # 即使 itemType 不是 stringApplication spec 中的参数值也会以字符串形式发送给插件 # 由插件负责进行适当的转换。 itemType: # collectionType 描述该参数接受的值类型string、array 或 map # 允许 UI 展示匹配的表单。默认为 string。 # 非字符串类型必须显式设置此字段它不会因为存在 array 或 map 字段而被自动推断。 collectionType: # 该字段将参数的默认值传达给 UI。设置此字段是可选的。 string: default-string-value # 上述除 string 之外的所有字段同样适用于 array 和 map 类型的参数通告。 - name: array-param # 该字段将参数的默认值传达给 UI。设置此字段是可选的。 array: [default, items] collectionType: array - name: map-param # 该字段将参数的默认值传达给 UI。设置此字段是可选的。 map: some: value collectionType: map # 动态参数通告是针对该插件处理的某个具体 Application 的通告。 # 例如Helm chart 的 values.yaml 文件中的值可以作为参数通告发送。 dynamic: # 命令在 Application 的源目录中运行。 # 标准输出必须是符合静态参数通告列表 schema 的 JSON。 command: [echo, [{name: example-param, string: default-string-value}]] # 若设置为 true插件将接收保留原始文件模式的仓库文件。 # 这很危险因为仓库中可能存在可执行文件。仅在信任 CMP 插件作者时才设为 true。 preserveFileMode: false # 若设置为 true插件可以在 generate 期间从 reposerver 获取 git 凭据。 # 插件作者应确保这些凭据在执行期间得到适当保护。 provideGitCreds: false[!NOTE] 尽管 ConfigManagementPlugin 看起来像一个 Kubernetes 对象但它并不是真正的自定义资源只是遵循了 Kubernetes 风格的 spec 约定。几个关键约束需要牢记generate命令必须在 stdout 打印一串有效的 Kubernetes YAML 或 JSON 对象流init与generate命令都在 Application 源目录内执行。从源码看生成的输出会经过kube.SplitYAMLToString解析为清单列表任何非 K8s 对象内容都会导致生成失败见 cmpserver/plugin/plugin.go。discover.fileName作为 glob 模式判断仓库是否被插件支持。如果未提供discover.fileName则会执行discover.find.command来判断命令需要以非错误退出码退出并且在标准输出产生输出才表示该源类型被支持。discover: find: command: [sh, -c, find . -name env.yaml]从源码的matchRepository实现可以确认三种发现方式的评估顺序spec.Discover.FileName→spec.Discover.Find.Glob使用支持**的第三方库zglob实现→spec.Discover.Find.Command三者都未配置时返回未启用发现见 cmpserver/plugin/plugin.go。第二步将插件配置文件放入 SidecarArgo CD 期望插件配置文件位于 Sidecar 的/home/argocd/cmp-server/config/plugin.yaml配置文件名plugin.yaml定义于 common/common.go。如果为 Sidecar 使用自定义镜像可以直接将该文件打入镜像WORKDIR /home/argocd/cmp-server/config/ COPY plugin.yaml ./如果使用官方镜像或更愿意将插件配置维护在 ConfigMap 中则可以将插件配置嵌套在 ConfigMap 的plugin.yamlkey 下并挂载到 SidecarapiVersion: v1 kind: ConfigMap metadata: name: my-plugin-config data: plugin.yaml: | apiVersion: argoproj.io/v1alpha1 kind: ConfigManagementPlugin metadata: name: my-plugin spec: version: v1.0 init: command: [sh, -c, echo Initializing...] generate: command: [sh, -c, echo {\kind\: \ConfigMap\, \apiVersion\: \v1\, \metadata\: { \name\: \$ARGOCD_APP_NAME\, \namespace\: \$ARGOCD_APP_NAMESPACE\, \annotations\: {\Foo\: \$ARGOCD_ENV_FOO\, \KubeVersion\: \$KUBE_VERSION\, \KubeApiVersion\: \$KUBE_API_VERSIONS\,\Bar\: \baz\}}}] discover: fileName: ./subdir/s*.yaml第三步注册插件 Sidecar要安装插件需要 patchargocd-repo-server将插件容器作为 Sidecar 运行并以argocd-cmp-server作为其入口。可以使用现成镜像或自定义构建的插件镜像作为 Sidecar 镜像containers: - name: my-plugin command: [/var/run/argocd/argocd-cmp-server] # 入口应为 Argo CD 轻量级 CMP server 即 argocd-cmp-server image: ubuntu # 可以是现成镜像或自定义构建镜像 securityContext: runAsNonRoot: true runAsUser: 999 volumeMounts: - mountPath: /var/run/argocd name: var-files - mountPath: /home/argocd/cmp-server/plugins name: plugins # 如果选择将配置文件打入 Sidecar 镜像请移除这个 volumeMount。 - mountPath: /home/argocd/cmp-server/config/plugin.yaml subPath: plugin.yaml name: my-plugin-config # 从 v2.4 开始不要挂载与 repo-server 容器相同的 tmp 卷。 # 文件系统隔离有助于缓解路径遍历攻击。 - mountPath: /tmp name: cmp-tmp volumes: - configMap: name: my-plugin-config name: my-plugin-config - emptyDir: {} name: cmp-tmp[!IMPORTANT]请务必核对以下三项确保使用/var/run/argocd/argocd-cmp-server作为入口。argocd-cmp-server是一个轻量级 gRPC 服务允许 Argo CD 与插件交互。确保 Sidecar 容器以用户 999 运行。确保插件配置文件存在于/home/argocd/cmp-server/config/plugin.yaml它既可以通过 ConfigMap 卷映射也可以打入镜像。仓库中的 examples/plugins/helm/argocd-repo-server-deployment-patch.yaml 提供了一个完整的真实部署示例通过 initContainer 下载 helm/jq/yq 工具到共享卷插件容器以argocd-cmp-server为入口并挂载plugin.yaml与脚本同时使用独立的emptyDir作为临时卷。从源码看Sidecar 的 socket 文件命名规则为指定了spec.version时是插件名-版本.sock否则是插件名.sock见 cmpserver/plugin/config.go这与文档中插件名称必须为metadata.name-spec.version的约定一一对应。在插件中使用环境变量插件命令可以访问以下环境变量Sidecar 的系统环境变量。标准构建环境变量详见 docs/user-guide/build-environment.md例如ARGOCD_APP_NAME、ARGOCD_APP_NAMESPACE、ARGOCD_APP_REVISION、KUBE_VERSION、KUBE_API_VERSIONS等上文的 generate 示例即引用了这些变量。Application spec 中的变量对系统变量和构建变量的引用会在变量值中进行插值apiVersion: argoproj.io/v1alpha1 kind: Application spec: source: plugin: env: - name: FOO value: bar - name: REV value: test-$ARGOCD_APP_REVISION在到达init.command、generate.command和discover.find.command命令之前Argo CD 会为所有用户提供的环境变量上述第 3 项添加ARGOCD_ENV_前缀以防止用户直接设置可能敏感的环境变量。从源码environ函数可以看出这些变量最终会被拼接到插件命令的cmd.Env中执行见 cmpserver/plugin/plugin.go。Application spec 中的参数apiVersion: argoproj.io/v1alpha1 kind: Application spec: source: plugin: parameters: - name: values-files array: [values-dev.yaml] - name: helm-parameters map: image.tag: v1.2.3参数会以 JSON 形式放入ARGOCD_APP_PARAMETERS环境变量。上面的示例会产生如下 JSON[{name: values-files, array: [values-dev.yaml]}, {name: helm-parameters, map: {image.tag: v1.2.3}}][!NOTE] 参数通告即使指定了默认值不会通过ARGOCD_APP_PARAMETERS发送给插件。只有 Application spec 中显式设置的参数才会发送给插件。插件需要自行应用与 UI 通告相同的默认值。同一组参数也可以作为独立的环境变量使用命名约定如下- name: some-string-param string: some-string-value # PARAM_SOME_STRING_PARAMsome-string-value - name: some-array-param value: [item1, item2] # PARAM_SOME_ARRAY_PARAM_0item1 # PARAM_SOME_ARRAY_PARAM_1item2 - name: some-map-param map: image.tag: v1.2.3 # PARAM_SOME_MAP_PARAM_IMAGE_TAGv1.2.3[!WARNING]净化/转义用户输入作为 Argo CD 清单生成系统的一部分配置管理插件被赋予一定程度的信任。请务必在插件中转义用户输入防止恶意输入引发意外行为。仓库示例 examples/plugins/helm/generate.sh 展示了如何消费这些变量用jq从ARGOCD_APP_PARAMETERS中解析出values-files数组生成--values参数、解析helm-parametersmap 生成--set参数最终组装成helm template命令。在 Application 中使用配置管理插件在plugin节中可以将name字段留空让插件根据其发现规则自动匹配 Application。如果填写了名称必须确保其为metadata.name-spec.version当 ConfigManagementPlugin spec 中声明了 version 时或metadata.name未声明 version 时。当显式指定名称时只有该插件在其发现模式/命令匹配提供的 Application 仓库时才会被使用。apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: guestbook namespace: argocd spec: project: default source: repoURL: https://github.com/argoproj/argocd-example-apps.git targetRevision: HEAD path: guestbook plugin: env: - name: FOO value: bar如果不需要设置任何环境变量可以设置空的 plugin 节plugin: {}[!IMPORTANT] 如果 CMP 命令运行时间过长命令会被终止UI 会显示错误。CMP server 会遵循argocd-cmd-params-cm中server.repo.server.timeout.seconds和controller.repo.server.timeout.seconds项设置的超时时间默认 60 秒必要时请调大。每条 CMP 命令还会依据 CMP Sidecar 上设置的ARGOCD_EXEC_TIMEOUT独立超时默认 90 秒。因此如果将 repo server 超时调大到 90 秒以上务必在 Sidecar 上设置ARGOCD_EXEC_TIMEOUT。如果 CMP 命令未能在ARGOCD_EXEC_TIMEOUT内优雅退出它将在额外一段ARGOCD_EXEC_FATAL_TIMEOUT时间后被强制杀死。[!NOTE] 每个 Application 同一时间只能配置一个配置管理插件。如果正在将原本通过argocd-cmConfigMap 配置的插件转换为 Sidecar请确保将插件名更新为metadata.name-spec.version若 ConfigManagementPlugin spec 中声明了 version或直接使用metadata.name。也可以完全移除名称让自动发现来识别插件。[!NOTE] 如果 CMP 渲染出空白清单且prune设置为trueArgo CD 会自动删除资源。CMP 插件作者应确保错误体现在退出码中。常见的kustomize build . | cat这类写法会因管道而吞掉错误请考虑使用set -o pipefail让任何管道命令在失败时都能传递错误。调试一个 CMP如果你正在积极开发一个 Sidecar 安装的 CMP请记住以下几点如果是从 ConfigMap 挂载 plugin.yaml需要重启 repo-server Pod插件才会拾取变更。如果已将 plugin.yaml 打入镜像则需要构建、推送并强制重新拉取该镜像。若使用:latestPod 总是会拉取新镜像若使用其他静态标签请在 CMP 的 Sidecar 容器上设置imagePullPolicy: Always。CMP 错误会被 repo-server 缓存在 Redis 中。重启 repo-server Pod 无法清除缓存。开发 CMP 时始终执行 Hard Refresh以获得最新输出。通过查看 Pod 确认 Sidecar 已正常启动两个容器都在运行kubectl get pod -l app.kubernetes.io/componentrepo-server -n argocd将日志消息写入 stderr并在 Sidecar 上设置--loglevelinfo标志。这将打印所有写入 stderr 的内容即使在命令成功执行时也会打印。其他常见错误| 错误信息 | 原因 | | -- | -- | |no matches for kind ConfigManagementPlugin in version argoproj.io/v1alpha1|ConfigManagementPluginCRD 已在 Argo CD 2.4 中弃用并在 2.8 中移除。此错误意味着你试图将插件配置直接作为 Kubernetes CRD 放入集群。请参考上文编写插件配置文件一节了解如何编写插件配置文件并将其正确放入 Sidecar。 |插件 tar 流排除Plugin tar stream exclusions为提高清单生成速度可以排除某些文件和文件夹使其不发送给插件。如果.git目录非必需建议将其排除。使用**跨目录边界匹配。例如.git/**会排除.git/内的所有内容。[!NOTE] 在 v3.6 之前不支持**。如果现有排除规则中包含/例如.git/*升级后请复查它们因为匹配行为可能与之前不同。可以通过以下三种方式之一设置repo server 上的--plugin-tar-exclude参数可重复多次。使用argocd-cmd-params-cm时的reposerver.plugin.tar.exclusionskey。直接在 repo server 上设置ARGOCD_REPO_SERVER_PLUGIN_TAR_EXCLUSIONS环境变量。对于方式 2 和 3可以用分号分隔多个 glob 规则。使用 argocd.argoproj.io/manifest-generate-paths 注解生成清单为了优化应用清单生成过程可以启用argocd.argoproj.io/manifest-generate-paths注解。启用后只有该注解指定的资源会被传给 CMP server 用于生成应用清单而不是发送整个仓库。这对于**单体仓库monorepo**尤其有用。同样有三种设置方式repo server 上的--plugin-use-manifest-generate-paths参数。使用argocd-cmd-params-cm时的reposerver.plugin.use.manifest.generate.pathskey。直接在 repo server 上设置ARGOCD_REPO_SERVER_PLUGIN_USE_MANIFEST_GENERATE_PATHS环境变量为true。从 argocd-cm 插件迁移通过修改argocd-cmConfigMap 安装插件的方式自 v2.4 起已弃用自v2.8起被完全移除。CMP 插件通过向argocd-repo-server添加 Sidecar 以及该 Sidecar 中位于/home/argocd/cmp-server/config/plugin.yaml的配置来工作。一个 argocd-cm 插件可以通过以下步骤轻松转换。将 ConfigMap 条目转换为配置文件首先将插件的配置复制到它自己的 YAML 文件中。以下面的 ConfigMap 条目为例data: configManagementPlugins: | - name: pluginName init: # 可选初始化应用源目录的命令 command: [sample command] args: [sample args] generate: # 生成 YAML 或 JSON 格式 Kubernetes 对象的命令 command: [sample command] args: [sample args] lockRepo: true # 默认 false。见下文。pluginName条目会被转换为如下配置文件apiVersion: argoproj.io/v1alpha1 kind: ConfigManagementPlugin metadata: name: pluginName spec: init: # 可选初始化应用源目录的命令 command: [sample command] args: [sample args] generate: # 生成 YAML 或 JSON 格式 Kubernetes 对象的命令 command: [sample command] args: [sample args][!NOTE]lockRepokey 对 Sidecar 插件没有意义因为 Sidecar 插件在生成清单时不会共享同一个源仓库目录。接下来需要决定如何将此 YAML 添加到 Sidecar可以将其直接打入镜像也可以从 ConfigMap 挂载。如果使用 ConfigMap示例将如下所示apiVersion: v1 kind: ConfigMap metadata: name: pluginName namespace: argocd data: pluginName.yaml: | apiVersion: argoproj.io/v1alpha1 kind: ConfigManagementPlugin metadata: name: pluginName spec: init: # 可选初始化应用源目录的命令 command: [sample command] args: [sample args] generate: # 生成 YAML 或 JSON 格式 Kubernetes 对象的命令 command: [sample command] args: [sample args]然后将此 ConfigMap 挂载到插件 Sidecar 中。为插件编写发现规则Sidecar 插件既可以使用发现规则也可以使用插件名称来匹配 Application 与插件。如果省略发现规则则必须在 app spec 中显式指定插件名否则该插件不会匹配任何应用。如果希望使用发现而不是插件名来匹配应用请按照上文编写插件配置文件一节的规则编写适用于你的插件的规则并将其添加到配置文件中。若要使用名称而非发现请将 Application 清单中的名称更新为metadata.name-spec.version若 ConfigManagementPlugin spec 中声明了 version或直接使用metadata.name。例如apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: guestbook spec: source: plugin: name: pluginName # 如需自动发现请删除此项如果 name 是唯一值则设置 plugin: {}或使用正确的 sidecar 插件名确保插件能访问它需要的工具使用 argocd-cm 配置的插件运行在 Argo CD 镜像上因此默认可以访问该镜像上安装的所有工具可查看仓库根目录的 Dockerfile 了解基础镜像与已安装工具。现在可以选择使用现成镜像如 ubuntu、busybox 或 alpine/k8s也可以设计包含插件所需工具的自定义基础镜像。出于安全考虑应避免使用比插件实际需要安装更多二进制的镜像。测试插件按照上文安装一个配置管理插件的步骤将插件安装为 Sidecar 后在将所有Application 迁移到 Sidecar 插件之前先在少数 Application 上测试。测试通过后从argocd-cmConfigMap 中移除插件条目。附加设置保留仓库文件模式Preserve repository files mode默认情况下配置管理插件接收的源仓库文件会重置文件模式这是出于安全考虑。如果希望保留原始文件模式可以在插件 spec 中设置preserveFileMode为true[!WARNING] 请确保你信任所使用的插件。如果将preserveFileMode设为true插件可能会收到带有可执行权限的文件这可能带来安全风险。apiVersion: argoproj.io/v1alpha1 kind: ConfigManagementPlugin metadata: name: pluginName spec: init: command: [sample command] args: [sample args] generate: command: [sample command] args: [sample args] preserveFileMode: true从源码看该开关会直接传递给仓库文件流接收逻辑cmp.ReceiveRepoStream见 cmpserver/plugin/plugin.go决定解包时是否保留原文件权限位。提供 Git 凭据Provide Git Credentials默认情况下配置管理插件需要自行为其在清单生成期间可能需要访问的其他Git 仓库提供凭据。而 repo-server 在其 git 凭据存储中已经持有这些凭据。当允许凭据共享时repo-server 用于克隆仓库内容的 git 凭据会在配置管理插件执行的整个生命周期内共享通过 git 的ASKPASS机制让配置管理 Sidecar 容器调用 repo-server 以获取已初始化的 git 凭据。利用ASKPASS意味着凭据不是主动共享的而是仅在某个操作确实需要时才提供。ASKPASS需要在配置管理插件与 repo-server 之间共享一个socket。为缓解路径遍历攻击建议使用专用卷共享该 socket并将其挂载到 repo-server 和 Sidecar 中。若要更改 socket 路径必须为两个容器都设置ARGOCD_ASK_PASS_SOCK环境变量。要允许插件访问 repo-server 的 git 凭据可以在插件 spec 中设置provideGitCreds为true[!WARNING] 请确保你信任所使用的插件。如果将provideGitCreds设为true插件将收到用于克隆源 Git 仓库的凭据。apiVersion: argoproj.io/v1alpha1 kind: ConfigManagementPlugin metadata: name: pluginName spec: init: command: [sample command] args: [sample args] generate: command: [sample command] args: [sample args] provideGitCreds: trueprovideGitCreds状态会通过CheckPluginConfigurationRPC 暴露给 repo-server见 cmpserver/plugin/plugin.go由 repo-server 决定是否在生成阶段为插件启用凭据转发。参考资源官方文档主体docs/operator-manual/config-management-plugins.md完整可运行的 Helm 示例插件examples/plugins/helm/plugin.yaml、examples/plugins/helm/argocd-repo-server-deployment-patch.yaml、examples/plugins/helm/generate.sh、examples/plugins/helm/get-parameters.shCMP 服务端实现cmpserver/server.go、cmpserver/plugin/plugin.go插件配置解析与校验cmpserver/plugin/config.go常用路径与常量定义common/common.go标准构建环境变量说明docs/user-guide/build-environment.md【免费下载链接】argo-cdDeclarative Continuous Deployment for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ar/argo-cd创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考