Now the actual CI/CD/thing-doers tools that all suck... I'm still stuck with those.
Same with build.sh and doing it in such a way that I can use all the build.sh in my ci.yml for Github Actions.
Some Kustomize, a little bit of envsubst and we're good to go thank you very much.
Hooks: I want to apply my database migrations and populate the database with static datasets before I deploy my application, without having my CI connect to the database cluster (at places I've worked, the CI cluster and K8s cluster were completely separate).
kubectl delete -f <manifests.yaml>
kubectl delete -k <kustomization_directory>
A Job feels like a good fit for this. CI deployes the Job without connecting to DB, Job runs migrations using the same connectivity as the application.
Regarding hooks: I don't know. All applications that I've used, implemented migrations internally (it's usually Java with Flyway), so I don't need to think about it. One possible approach could be to use flux CD with Job definition. I think that Flux will re-create Job when it changes. So if you change image tag, it'll re-create Job and it'll trigger Pod execution. But I didn't try this approach, so not sure if that would work for you.
You could a) have the app acquire a lock in the db and do its own migrations, or b) create a k8s job that runs the migration tool, but make sure the app waits for the schema to be updated or at least won't do anything bad.
cat manifests.yaml | kubectl apply -f - --server-side --field-manager "$FIELD_MANAGER" --prune --applyset "$APPLYSET" --namespace "$NAMESPACE"
For the simple use case you're describing, Helm is not required. Plenty of other solutions around.
For use cases where it starts getting useful, we both agree that something has gone terribly wrong.
I still don't know why Helm exists. It's a solution that created lots of problems that didn't exist.
Using one of the most horrible templating languages since ASP. Helm is what happens when a devops team decides to yolo into software development.
What's the issue with kustomize? It works well for us.
I manage 100+ variations on a single helm chart and 50+ such helm charts at work daily for 7 years across 11 datacenters/kubernetes clusters. And I have team members who swear by kustomize. The number of kustomize typo errors and issues that I have deal with is unimaginable. Whereas if I test and deploy a helm chart, I know it will work everywhere in every variation.
Kustomize is just plain terrible and backwards as a solution. It doesn't scale, it is half assed. It tries to basically require you to build your own compiler and parser and transform. With kustomize + envsubst: dear friend, you have built helm.
Fun times.
For very simple deployments, you don't need anything at all. Just write manifests and use `kubectl apply`. You can write `deploy.sh` but it'll be trivial.
If you want templating, there are many options. You can use `sed` for the most simple templating needs. You can use `cpp`, `m4`, `helm` or `kustomize`. I, personally, like `kustomize`, but `helm` probably not the worst template engine out there.
Kustomize is even somewhat included into basic kubernetes tooling, so if you want something "opinionated", it is there for you. It works.
Git and Kubetnetes configuration cannot go hand in hand. You cannot go back in past indefinitely because cluster state might not be that reversible. If so, git is useless.
And no, doesn't apply for database migrations. You can mostly run migrations backwards if each migration was written carefully.
I have a "simple" representation of services using CUE, that generates the yaml manifests and flux deploys them.
I hesitated a while before going the k8s route but before that I had a overly error-prone Ansible configuration and I got sick of manual templating (hence the move to CUE for type safety).
There's also the fact that I wanted my services to be as plug and play as possible, so for example automatically generated openid credentials and very easily configurable central SSO, along with the easily configurable reverse-proxy.
If anyone thinks that k8s is not the best tool for this, I'm always interested in advice.
(Also a lot of complexity in my setup is due to self hosting, I have Istio, MetalLB, proxmox CSI, and all other kind of stuff that your cloud provider would already have, and these are the things that take most of the configuration files in my repo)
(I tend to think this one is acceptable in the beginning, but certainly doesn’t scale.)