# 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.