flux-releaser/docs/architecture.md

Architecture

Flux releaser is structured to support how flux2 recommends structuring a flux project. This means that we will end up with a structure like so

clusters/<cluster_names>/kustomizations
<cluster_names>/kubernetes manifests

Flux releaser goes a small step further in how it opinionates its folders

First of all each entry in flux-releaser is required to have a unique app and namespace, this is important for guaranteeing unique ness, otherwise flux-releaser can replace services it didn't intend to.

Flux releaser currently makes no guarantee that a namespace and app name is not taken over by another party, this is up to you to control access to the flux gitops repository

As such this means that flux-releaser will place folders in

clusters/<cluster_names>/<namespaces>/<apps>/kustomizations
<cluster_names>/<namespaces>/<apps>/kubernetes manifests

This means that each app can have one or more clusters, namespaces but only one app, but only one namespace pr cluster.

The way flux-releaser stages its commits, is that the producer (usually CI) prepares a setup folder. This mirrors the structure above

<tmp_dir>/  
  clusters/
    <cluster_names>/
      <namespace>/
        <kubernetes_manifests>

This will then all be bundled up in a tar ball and staged under a specific artifact id, along with some metadata about the release, (when it happened, whom the committer was, which branch it originated from, which service it belongs to etc).

When a flux release is processed it will be triggered via. a branch, the app name, the bundled artifact will then be applied on top of the gitops registry and finally released.