---
# System prepended metadata

title: 'FADI: GitOps architecture - Phase 1 - Transistor v2 + Flux'

---

# FADI: GitOps architecture - Phase 1 - Transistor v2 + Flux

For the initial phase of the GitOps rearchitecturing at FADI, Giant Swarm is proposing to use Flux 2 to deploy Helm charts of every application.

The first step of this solution consists in aggrementing the current Transistor setup to allow it to run on Giant Swarm clusters and to be able to generate Helm charts so that any GitOps tool can reconcile the helm charts.


## Cluster components

![](https://i.imgur.com/dbcBJxI.png)

Flux app is the component in charge of deploying the environments using Custom resource definitions

The kube-system namespace contains dex for OIDC authentication to the clusters, nginx ingress controller to give access to the pods from outside the cluster, the vertical pod autoscaler to scale flux vertically and an external dns app to update the pucis.net hosted zone.

The ecom-staging and ecom-development contain the applications as well as an oauth2-proxy app for services requiring OIDC.

## Current architecture

![](https://i.imgur.com/CbHO58D.png)


The current architecture rely on both transistor and flux to be running to deploy the environments.

Transistor handle the environment creation and configuration.
Emitter creates the helm charts and push them to the correct repository and flux deploy the helm charts to the correct clusters.

### Adding a new realm

To push a new realm, the emitter code must be updated.
You need to checkout the `feature/push-charts` branch on https://github.com/fid-dev/t8r2-emitter and add the repo for the new realm https://github.com/fid-dev/t8r2-emitter/blob/bdb491e31df3fd43e99dc1d8da5c1989479815b5/pkg/git/GitTransfer.go#L20


You also need to enable this emitter for the realm by adding the added realm to the controller manager configmap using:
`k --context giantswarm-mb5v6  -n t8r2-system edit cm environment-controller-config`

The list of allowed realm should be in the form of:
```yaml
apiVersion: v1
data:
  deploy_datatier_development: "false"
  deploy_datatier_production: "false"
  deploy_datatier_staging: "false"
  deploy_everything: "false"
  deploy_explicit_list: |
    flex.development
    ecom.staging.clone
    ecom.development
    ecom.staging
    ecom.production
kind: ConfigMap
metadata:
  creationTimestamp: "2021-05-06T05:54:43Z"
  name: environment-controller-config
  namespace: t8r2-system
  resourceVersion: "123521712"
  uid: 1946ceba-f799-4422-9eed-a95240bd0039
```

### Configuration per environment

By default, emitter works the same for every environment but a few things things can be tweaked by editing the FID Environment CR on `mb5v6`

#### Enable metrics support on the environment
To enable metrics collection on the environment, add the following annotation to the fidenvironment CR `qa.pucis.net/metrcis-enabled: "yes"`

#### Suspend the deployment of new helm charts (a.k.a kill switch)
To suspend emitter from doing any change to the helm repositories, you need to edit the fidenvironment CR and add the following annotation: `emitter.pucis.net/paused: "true"

#### Adjust the dns weight
Edit the fidenvironment CR and set the value you want under:

```yaml
spec:
  deviations:
    dnsWeight: 0
```

By default, the value is set to 0.

#### Override a specific app
To override a specific application for testing, you can add the branch in the fidenvironment CR like so:

```yaml
spec:
  repositoryBranches:
  - branch: master
  - branch: feature/dummy-page-maker-increase
    repository:
      name: ecom-realm-stack
      owner: fid-dev
```

## Secret management

Secret management is done via SOPS which is a secret provider supported by Flux by default.

This is currently using a generated GPG key.

See https://confluence.puc.services/display/ARCH/secrets+management

## Generated files

Emitter is in charge of generating the helm chart depending on what the collector fetches from Docker Hub and Github.

The generated files are defined as such:

generated/
 flux/
   development/
     secrets/
     configmaps/
     kustomizations.yaml
     ...
   staging/
   production/
   ...
 helm
   chart-name/
     Chart.yaml
     values.yaml
     templates/
     ...
     
The repository ecom-helm contains a base folder name generated to imply that any change here will be overwritten by emitter

### Helm

An example helm chart can be found here:
https://github.com/fid-dev/ecom-helm/tree/master/generated/helm/attributes-update

The folders contain the following:

Chart.yaml
values.yaml
templates/

*Chart.yaml* file contains the application description
*values.yaml* file contains the default values for the app
*templates* contains the templates describing the chart. They differ depending on the type of application (CronJob or Deployment)

### Flux

The flux folder contains what should be deployed in the cluster using Flux.
The flux folder is divided per environment and in each environment folder, you can find the secrets and configmaps respectively as well as the kustomization CRs explaining what application to deploy into the cluster

As you can see here https://github.com/fid-dev/ecom-helm/blob/master/generated/flux/development/attributes-update.yaml, the Kustomization CR contains the values to apply to the helm charts for this specific environment. We are currently using the reconcileStrategy of ChartVersion, which means that if the template chart changes in emitter, the version in the Chart.yaml file should also be bumped
