-
Notifications
You must be signed in to change notification settings - Fork 564
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: more support towards helmfile per team/microservice #247
Comments
@mumoshu This concept might also make sense for the |
@sstarcher That's absolutely an interesting idea. As I'm eager to keep each sub-helmfile.yaml self-contained, I won't like "inheriting the whole environment values" into sub-helmfiles. But I'm certainly ok with In the environments:
production:
values:
- ../some/team-wide/global/values.yaml
- filebeat/specific/values.yaml
releases:
- name: filebeat
# snip How does it sound to you? |
ya, that makes sense. When you wrote Did you mean |
Ahh, exactly! |
@mumoshu you're on a real tear! love all these new features. |
In #96 we have discussed about merging multiple sub-helmfiles into a single or central one, but stayed in favor of #151 #160. However it doesn't necessarily mean #160 is the end result.
How about introducing
helmfiles:
inhelmfile.yaml
to do the same thing with thehelmfile.d
feature, but for sub-helmfile located in arbitrary paths?For example. this example helmfile.yaml would work exactly same as the
helmfile.d
:Helmfiles are sorted alphabetically per group = array item inside
helmfiles:
, so that you have granular control over ordering(#137).Suppose I have my microservices organized in a Git reposistory that looks like:
kube-system
forclusterops
team)charts/
exists, because it depends on the stable/filebeat chart hosted on the official helm charts repository)<the content of the helm chart>
One of the benefits of this structure is that you can run
git diff
thing to locate in which directory=microservice a git commit has changes. My CI system is able to run a workflow for the changed microservice only.A downside of this is that you don't have an obvious way to sync all microservices at once. That is, I have to run:
At this point, you'll start writing a
Makefile
undermyteam/
so thatmake sync-all
will do the job.The question is, can't we do better? I believe we can, with the proposed feature.
You would write a helmfile.yaml like:
So that you can get rid of the
Makefile
and the bash snippet.Just run
helmfile sync
insidemyteam/
, and you are done.The text was updated successfully, but these errors were encountered: