41 lines
1.6 KiB
Markdown
41 lines
1.6 KiB
Markdown
# 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.
|
|
|
|
|