-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
reevaluate CLI design #23
Comments
One drawback is that |
Will also need a way to filter out noise if we're going to have useful diffs; otherwise, there will be countless - kubenix/hash: bf784eba18bc4ac54f30ad01873205d7486b0163
+ kubenix/hash: 67c3651392deea6752d5d05c0e83a369e6caabaa on every execution. |
Hashes cluttering up the diff was solved by using diff -N -u -I ' kubenix/hash: ' $@ So the linked MR for the full implementation. |
I've added basic deletion with More importantly, that raises another issue of verifying/matching the version skew policy. Should be possible since we already have access to the user's API version. |
For what it's worth, the approach I use it to keep encrypted secrets within the repo and the k8s manifests and have them decrypted in an init container (a slightly evolved version of this), before the pod starts. I use sops for encrypting\decrypting as it integrates with various cloud providers.
I use an intermediate repo with final generated manifests and then argocd which watches for changes on the repo to syncs them to the cluster. This also takes care of pruning deleted resources. So a CI job, instead of running |
I like agenix as it matches how I manage secrets outside of k8s but this is also a nice approach (that's probably worth adding to the docs). I might have to play around with something along these lines and see how it goes.
I think gitops is a bit overkill for my own use-case. ArgoCD is pretty nice but adds more complexity than I personally want/need. That said, it's also a perfectly valid approach and does solve a lot of the same problems in a slightly different way. I appreciate having these details though. I'd like to beef up the docs with more stuff like this. I recently added a "tips-n-tricks" section which I mean to use as a bucket to collect pages for these sort of "this is how you might do X" approaches. Might not be the best title but having them is nicer than having to discover things on your own. |
Fair point.
Cool, happy to contribute |
Another tool which can be used to track changes and prune resources when deploying |
Ooh, kapp looks to fit this definition pretty nicely with ordered applies, ready checks, even targeting with labels. Thanks for pointing that out, hadn't seen it before. So maybe a bigger question is should we provide a "golden" apply path? The alternative (so far as I understand) is just documenting a few suggestions and leaving implementation to the user. |
Thanks for being a sounding board here, @adrian-gierakowski 💯 I'm going to assume most users are in the same boat as you and are currently relying on some outside deployment mechanism (which is perfectly fine, and in many ways better, of course; maybe I'll go that way myself one of these days 🙃). I've merged the associated MR which does about all I'm personally looking for here (will continue to iterate, of course). |
I'm starting to come around to the idea of templating charts out of Helm and then piping them to
kubectl
(as opposed to installing withhelm
). In part, this is because the current CLI doesn't handle releases defined within submodules. So I've an immediate need to make improvements there. However, the current implementation is already clunky and I'm not convinced the existing complexity is worthwhile.Overall, this is what I'd like from a CLI:
agenix
then piping tovals
; I'm pretty satisfied with this setup and supporting it is hardly one line of shell script on its own.All of these on their own are fairly simple with
kubectl
alone. Once I threwhelm
in the mix, things started getting a little hairy (with questionable benefit); especially, since the current modules all appear to be designed under the assumption that manifests will be piped tokubectl
.All this to say, I'm going to (on a branch for now) drop helm from the CLI to focus solely on the above tasks. I'd be happy to hear how others feel and what they'd like to see accomplished here.
The text was updated successfully, but these errors were encountered: