feat: more support towards helmfile per team/microservice

[mumoshu]

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: in helmfile.yaml to do the same thing with the helmfile.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:
- helmfile.d/*.yaml

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:

• myteam/ (sometimes it is equivalent to a k8s ns, that is kube-system for clusterops team)
  • apps/
    • filebeat/
      • helmfile.yaml (no charts/ exists, because it depends on the stable/filebeat chart hosted on the official helm charts repository)
      • README.md (each app managed by my team has a dedicated README maintained by the owners of the app)
    • metricbeat/
      • helmfile.yaml
      • README.md
    • elastalert-operator/
      • helmfile.yaml
      • README.md
      • charts/
        • elastalert-operator/
          • <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:

for d in apps/*; do helmfile -f $d diff; if [ $? -eq 2 ]; then helmfile -f $d sync; fi; done

At this point, you'll start writing a Makefile under myteam/ so that make 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:

helmfiles:
- apps/*/helmfile.yaml

So that you can get rid of the Makefile and the bash snippet.
Just run helmfile sync inside myteam/, and you are done.

[sstarcher]

@mumoshu This concept might also make sense for the environment concept that we talked about in another ticket. As we had the issue of loading the environment before loading the helmfile. In this situation this helmfile.yaml that references other helmfile could load global defaults that could be used by all of the other helmfiles.

[mumoshu]

@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 helmfile --environment production sync to propagate just the environment name, so that all the sub-helmfiles are synced, conceptually, with helmfile --environment -f apps/filebeat/helmfile.yaml where the filebeat should be replaced by each directory to which the glob pattern matched.

In the apps/filebeat/helmfile.yaml, would you define the filebeat's own production environment":

environments:
  production:
    values:
    - ../some/team-wide/global/values.yaml
    - filebeat/specific/values.yaml

releases:
- name: filebeat
   # snip

How does it sound to you?

[sstarcher]

ya, that makes sense. When you wrote helmfile --environment -f apps/filebeat/helmfile.yaml

Did you mean helmfile --environment production -f apps/filebeat/helmfile.yaml

[mumoshu]

Ahh, exactly!

[osterman]

@mumoshu you're on a real tear! love all these new features.