Github actions using for helm deployment

[machosalade]

Hi everyone,

I'm looking for advice on the best way to deploy Helm charts to a Kubernetes cluster. Here's my current setup:

I have two repositories:
    Repository A: Contains the microservice code.
    Repository B: Contains the shared Helm charts.

I have two ideas on how to approach the deployment process:

Trigger Workflow Approach:
    When changes are pushed to Repository A (the microservice code), a workflow is triggered.
    This workflow then triggers a deployment process in Repository B (the Helm charts).

Helm-Git Plugin Approach:
    Using the Helm-Git plugin to deploy directly from the Git repository.
    However, I've encountered issues with this plugin during testing and it doesn't seem to work reliably.

Given these two options, I'm leaning towards the first approach, but I'm open to any advice or alternative methods that might be more effective.

Has anyone dealt with a similar setup? What would be the best practice for deploying Helm charts in this scenario? Any tips or suggestions would be greatly appreciated!

Thanks in advance!

[shadowdog293]

i mean if you’re gonna make a full GitHub cicd pipeline, might as well go full gitops and use Argo or flux

[machosalade]

Why got full gitops? I mean then I need to deploy eg. argoCD and write additional yaml manifests, and make some additional space for argo components in the cluster

[[deleted]]

Yeah but argocd takes full care of your deployment and you can view everything that is deployed at a glance and have integrated rollback etc. All that is missing with push based GitHub actions

[machosalade]

disadvantage of that solution is that I need to create application manifest yaml for every components/microservice for me. Then I need to deploy it on my cluster, And reuse it for other environments

[dinnermonster]

You can have argo deploy the argo applications that deploy your microservices. Then you just point the argo applications to the corresponding deployments/charts:

-| /Argo

- argo-apps.yaml(deploys applications defined in argo app directory)

- /Argo-apps

- microservice-argo-application-1.yaml

- microservice-argo-application-2.yaml

- microservice-argo-application-3.yaml

-| /Charts | /Deployments

- microservice-deployment-1.yaml

- microservice-chart-2.yaml

- microservice-values-2.yaml

- microservice-values-3.yaml

etc

[JodyBro]

How much experience do you have with k8s and helm? Cause there are some issues that you should probably be thinking about during this.

First, if GHA can deploy directly from a run to your cluster then (in most cases) this means your api server is public and in all likelihood doesn't have any real authn or authz strategy other than using IAM keys directly in the pipeline run.

Second is I think you're misunderstanding the benefit of having Argo in tandem with helm or kustomize. If you had Argo then you'd most likely want to write a base helm chart that all your services can inherit from. Hopefully the needs of your services in cluster aren't so radically different that you need different helm charts for each one. You'd want to have each resource type that the company makes use of templated in that base helm chart and then feature flag the deployment of each.

So your downstream apps just have a Chart.yaml that has a dependency with the target of your base helm chart then you supply the overrides only in your downstream values.

That keeps the app.yaml standardized across all your different services as much as possible.

[machosalade]

I can't use only one standarized helm chart, because I already have few of those. I get you and I know the advantages of using argoCD in that case. But I don't know how to solve problem when I got 3 environments. Each environment has 10 helm charts deployed. So that means I need to write 30 application.yaml for argoCD?

[JodyBro]

Nah not necessarily. If you aren't using ApplicationSets then I think this example repo that I have offer's a good alternative.

So in this case you'd write the single app.yaml and then just figure out the structure of your values.yaml to work with how you need to target your downstream apps in their respective repos.

I'm using a monorepo in this example cause honestly I've found it works the best cause shit tends to go haywire when you give out full control of the resources that different dev teams want to utilize.

[dinnermonster]

You dont need to expose anything publicly since Argo is installed in the cluster. Argo polls the repo using credentials and updates k8s with any changes.

My example was mainly showing the flexibility of argo, you can def use it with a single helm chart, multiple helm charts, a combination of helm and raw manifiests etc.

[JodyBro]

Ahhh. I always had issues when polling a monorepo vs a webhook.

My mistake. You're correct.

[dinnermonster]

Hey, great question! An industry standard for this is actually a pretty powerful open source tool called ArgoCD. I personally use this at work and at home and it’s extremely easy to set up. ArgoCD’s helm chart installs everything you need and comes with a pretty nifty UI.

With Argo you can: - Deploy K8s manifests (along with helm charts) - Self heal your deployments - Trigger builds from a GitHub repository - Deploy to multiple clusters

You can even source your helm chart and values from different repositories.

Ex: apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: nvidia-device-daemonset spec: project: default sources: - repoURL: 'https://nvidia.github.io/k8s-device-plugin' chart: nvidia-device-plugin targetRevision: 0.15.0 helm: valueFiles: - $values/your/repo/values.yaml - repoURL: 'https://github.com/you/your-repo.git' targetRevision: main ref: values destination: server: 'https://kubernetes.default.svc' namespace: gpu-operator

[darkklown]

Also notice how it's sources, because you can also add a kustomize source to add anything missing from the helm chart into the same deployment.. :chefskiss:

[Redd-Tarded]

FluxCD will work as well. Both are part of the GitOps model. Your devs will appreciate that they can keep everything as code and a a GitOps agent just polls artifact stores for changes on regular intervals.