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.