4 ms·
I agree with this. I manage a monorepo of 10s of terraform/terragrunt modules most of which are deployed to a k8s cluster. the whole point of code as infrastru
by dmead 4y ago
I agree with this. I manage a monorepo of 10s of terraform/terragrunt modules most of which are deployed to a k8s cluster.
the whole point of code as infrastructure is that your git repo is an audit log of whats changed in your infra. Once you leave it up to operators or persistent volume claim templates (or whatever else makes side effectful changes with being told) you're throwing all that niceness of control out the window.
- encryptluks2 4y agoA Git repo can still be a good audit log even if you use templates, especially if you're adding a step to transform files with each push.
- raffraffraff 4y agoInfra as code can't actively manage things like database clusters, handling promotion of a secondary, automatic deployment of new replicas, scaling. Using it to deploy RDS Aurora doesn't count. My impression is that operators are designed to handle those "active" decisions in real-time, and that's outside the realm of terraform, GitOps etc.
- dmead 4y agoIndeed, and if the k8s api was so precisely laid out that you could look at a log of side effect changes that came as the result of scalers, operator, templates etc that would be one thing, but we aren't there yet. Right now what i have is "oh the cluster is in a different state (there is drift) than the code, lets be a detective to see why this changed".
- nunez 4y agoTo be fair there are tools that use operators (like Flux) to apply desired state onto Kubernetes clusters using Git, so the GitOps is still there. You can even combine flux with ClusterAPI to create clusters with CRDs through Git, which can be quite handy