-
Notifications
You must be signed in to change notification settings - Fork 566
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
feat: add '--output-dir' option to other options (apply/sync etc) write generated YAML output to disk #751
Comments
@bitsofinfo is my assumption correct, that you're trying to get some sort of gitOps style deployment. When basically every state of the cluster is stored in repo or somewhere and could be applied or rolled back? |
ideally yes, my helmfiles generate a lot of releases based on other simplified input. I just like capturing as much of whats going on as possible, and being able to capture all yaml generated and be able to store that separately anywhere else I want would be great. I could def do that now w/ |
I see, I had similar requirements when I suggested that Back to the original issue: |
you using flux? |
no, I chose argo-cd |
@bitsofinfo Hey! I'd recommend The biggest gotcha I'm aware of so far is that you can't use But https://github.com/mumoshu/helm-x could give you |
@bitsofinfo @lwolf Btw how are you folks handling secrets in GitOps? Are you using sealed secrets, aws-secret-operatpr? Or are you by any chance committing raw secret YAMLs generated by |
I'm not currently even started on any of the gitops stuff yet. I just currently have a need to capture the yaml output for auditing purposes and would ideally like to not have to invoke things 2x (or use another tool at yet) |
@mumoshu custom internal operator, similar to the |
You do use a CI system, right? So probably your goal for this issue is to extend helmfile to achieve GitOps without introducing an another CD system like flux? Also back to your original issue:
What's your goal for this? Auditing? |
Yes the goal for this kind of thing is auditing and just checking in the YAML output to git so we can quickly refer to it should a need arise without having to go digging into the cluster. We always have a copy of the literal YAML generated and applied to the cluster. I currently have no defined or set in stone process, I just see this requirement coming from the higher ups. Right now I can get this from I classify this as a nice to have. For me #752 is more important (for me anyways) as right now I have to write a custom parser that captures all the stdout from |
The new
--output-dir
option added w/ #629 is awesome.In my use case, I'd really like to optionally capture the generated YAML output from all helmfile commands (i.e. apply/sync etc) and be able to flush it to disk, in addition to the normal behavior of actually invoking helm and sending to kubernetes. I'd like to to this to be able to always have records of releases generated and sent off to k8s.
This way we could just run a single command instead of both
template --output-dir
followed byapply
@lwolf @olivierboudet
The text was updated successfully, but these errors were encountered: