Using helm to manage an "environment?"

Question

I'm new to Kubernetes, and hence helm, so I've been reading a lot, and teaching myself by setting up a cluster, services, deployments, and pods. In my case I use AWS EKS.

I now at least understand each piece from a technical point of view. But now I want to put it all together in managing an "environment." I believe this is the idea behind GitOps.

Say I'm a QA person and am testing a "staging" environment. This environment comprises a number of microservices with their own respective versions. So logically I can represent it this way

/staging-2021-03-06-4 # 4th build of staging environment on 2/06/2021
- microservice1:1.1.0
- microservice2:1.2.0
- microservice3:1.3.0

When we build the next staging, e.g, staging-2021-03-06-5, anyone of those microservices versions can change.

But now I, the QA guy, find an issue with above staging-2021-03-06-4 build, and I ask a developer to look at it. I want to be able to just tell the developer to "check out" the staging-2021-03-06-4 environment so he/she can have exactly the environment that I have to reproduce the issue.

I'm thinking I can set up this idea of "environment" with helm, since the "environment" is nothing but a package of packages? Is this the correct utility of helm? If so, do I just set up a staging-2021-03-06-4 helm chart that has dependencies of other charts, and those other charts are for each microservice?

I'm also reading How to manage 10+ team environments with Helm and Kubernetes? since it applies to me also, but that describes a different (additional) problem I'm trying to solve with helm.

Update: I think I'm essentially wanting GitOps, so I'll read up on that.

Answer 1

Helm charts should not be built for a specific environment, IMHO. You can see that many of the official helm charts have a set of default values and they are configurable from outside. You also can create a helm chart like that and declare your deployment + environment-specific values with another tool like Helm Operator or ArgoCD. In this way, you can both simplify your build pipeline and increase dev/prod parity. You can use that one chart and promote the same build into different environments so you can be sure that different environments are identical except the configuration.

Example ArgoCD application manifests:

production-application.yaml:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: production-yourservice
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/yourorganisation/helm-charts
    path: yourservice
    targetRevision: master
    helm:
      values: |
        environment: production
        replicas: 10
  destination:
    server: https://kubernetes.default.svc
    namespace: production-yourservice

staging-application.yaml:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: staging-yourservice
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/yourorganisation/helm-charts
    path: yourservice
    targetRevision: master
    helm:
      values: |
        environment: staging
        replicas: 1
  destination:
    server: https://kubernetes.default.svc
    namespace: staging-yourservice