3 ms·
I generally agree. I use Ruby for this. Duck typing is sufficient. I’ve also found that coupling manifests generation with application deployment to close a l
by hosh 2y ago
I generally agree.
I use Ruby for this. Duck typing is sufficient.
I’ve also found that coupling manifests generation with application deployment to close a lot of doors. It’s better to modify manifests to change image references (or something similar), and have a separate process for applying manifest changes.
- FridgeSeal 2y agoI’ve had great success with Flux and a small bit of CI for this. We currently have configs in raw K8s yaml in our monorepo in kustomize base+overlay style setup. It’s super duper obvious what’s in each env, and straightforward to change them. Images are swapped in using Kustomize’s “newImage” functionality. Flux watches git and deploys to K8s. At any point it’s super clear what the configs are, what image we were using at the time, flux just pulls in what it finds in git, so there complete separation between “make them” and “deploy them”. Nicest CICD experience ever. Zero helm tempting, zero pain.
- hosh 2y agoThanks for sharing that. That validates my observation. I had implemented a system with separate manifest and deployment and it had worked great. I came to a team with an existing process that coupled manifest and deployment process … and it contributed to their inability to respond to changing circumstances; you get the Kubernetes complexity and none of the Kubernetes advantages.