helm 模板 - Helmfile,该走哪条路?

问题描述 投票:0回答:2

我参与了几个使用 GitOps 原则部署到 Kubernetes 的 CI/CD 结构项目。

有些项目在我加入之前就开始了,我不能对那些项目和其他一些我在初创公司参与的项目产生太大影响,但我对最终结果并不满意,所以我在寻找理想的方式Kubernetes 的交付管道应该是这样的。

在阅读了几个人的建议和设计后,我得出了如下解决方案。

我尝试使用最佳实践,即来自多个来源的共识和12 Factor App的原则。

它从每个服务原则的 Git 存储库开始,并具有一个服务管道,该服务管道正在生成一个可执行文件、一个 Docker 映像并使用 Docker 映像 ID 和对所有环境都有效的配置推送到 Docker Registry 和 Helm Chart 并推送它到 Helm 存储库。

因此,每次提交到服务 Git 存储库时,服务管道都会触发生成新的 Docker 映像和 Helm 图表(只有一个约定,只有当 Helm 模板的结构发生实际变化时,Helm Chart 版本才会增加,仅将实际的 Docker Image Id 放入 Helm Chart 中不会影响 Helm Charts 的版本)。

对服务 Git 存储库的提交也会触发开发环境的环境管道(这被过度简化了,以便能够控制图表的大小,对于功能和错误修复分支,环境管道还可以在 Dev k8s 下创建额外的命名空间集群)。

在这一点上,与我之前类似管道的生产实施以及这个问题的原因相比是一个很大的变化。在这些实现中,此时 Environment Pipeline 将在 Helm Umbrella Chart 的帮助下从 Helm Repository 获取所有服务 Helm Charts(与下图不同)并执行 'helm upgrade --install appXXX -n dev -f values-s1。 yaml -f values-s2.yaml -f values-s3.yaml -f values-s4.yaml -f values-s5.yaml' 这有效,但缺点是审计。

我们可以通过检查 K8s 集群来识别我们稍后部署的内容,但这会很痛苦,所以我的想法是遵循 GitOps 原则(许多来源同意我的观点)并使用 'helm' 呈现 Helm Umbrella Chart 的清单在“环境管道”期间“模板”并将它们提交到环境存储库,这样一来,首先可以更轻松地审核它们,其次我可以在 ArgoCD 等持续部署工具的帮助下部署它们。

既然我解释了先决条件,我们就到了我的实际问题,我也从我提到的相同资源中读到,当我阅读文档时,'helmfile' 也是一个很棒的工具,它有一个非常好的工具来防止样板代码但是考虑到,我计划将环境 Git 存储库中的状态与 ArgoCD 同步,我不会使用“helmfile sync”和“helm template”基本上做“helmfile template”所做的事情,在此工作流程中也使用“helmfile”矫枉过正?此外,我认为 Helmfile 的“environment.yaml”的概念与我尝试使用 Environment Git Repository 实现的目标相冲突。

其次,如果我决定也使用“helmfile”,主要是因为很棒的额外模板功能阻止了样板文件,我应该如何将它与 ArgoCD 集成,似乎以前它可以集成在...

data:
  configManagementPlugins: |
  - name: helmfile
    generate:
      command: ["/bin/sh", "-c"]
      args: ["helmfile -q template --include-crds --skip-tests"]

但现在'configManagementPlugins'似乎已被弃用,我应该如何将它与 ArgoCD 集成?

感谢答案。

kubernetes-helm argocd helmfile
2个回答
1
投票

但现在'configManagementPlugins'似乎已被弃用,我应该如何将它与 ArgoCD 集成?

您需要通过 sidecars 使用 configManagementPlugins 而不是通常的 ConfigMap,请参见here.

ConfigMap 大致如下所示,然后像here 一样将ConfigMap 挂载到sidecar 中。

粗略的ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata: 
  name: helmfile-plugin
  namespace: argocd
data:
  plugin.yaml: |
    apiVersion: argoproj.io/v1alpha1
    kind: ConfigManagementPlugin
    metadata:
      name: helmfile
    spec:
      discover:
        find:
          command:
            - sh
            - -c
            - |
              find . -type f -name helmfile.yaml && find . -type d -name helmfile.d
      generate:
        command:
          - sh
          - -c
          - |
            helmfile template --skip-deps --include-crds "${ARGOCD_ENV_CLUSTER_ENV:+--environment="${ARGOCD_ENV_CLUSTER_ENV}"}";
      init:
        command:
          - sh
          - -c
          - |
            helmfile repos "${ARGOCD_ENV_CLUSTER_ENV:+--environment="${ARGOCD_ENV_CLUSTER_ENV}"}";
      version: v1.0

0
投票

@Vanderworld 的回答非常有用,但我遵循了另一种模式,您可以在这个blog 上阅读概念,并在这个blog 中阅读 Azure DevOps Pipelines 的完整实现。

基本上我决定使用 helmfile 模板渲染 k8s 清单,并将清单提交给 GiT,让 ArgoCD 从那里读取。

© www.soinside.com 2019 - 2024. All rights reserved.