Un Talos européen de qualité - Part IX - Flux

part-09

Objectif 🎯

L’essentiel de l’infrastructure étant enfin finalisée, il ne reste plus qu’à mettre en place le déploiement continu (CD) avec Flux.

Pour rappel, Flux est un outil GitOps qui permet de synchroniser l’état d’un cluster Kubernetes avec un dépôt Git. Ainsi, toute modification dans le dépôt Git sera automatiquement appliquée au cluster Kubernetes.

Installation Flux

Créer votre repo git vide flux source sur GitHub ou tout autre VCS, l’URL ici sera https://github.com/ohmytalos/flux-source.git.

1
module "kube_delivery" {
2
  source = "../../modules/kube/delivery"
3

4
  flux_git_repository      = "https://github.com/ohmytalos/flux-source.git"
5
  flux_git_password        = var.flux_git_password
6
  flux_bootstrap_git_path  = "clusters/dev"
7
  flux_sops_age_secret_key = var.flux_sops_age_secret_key
8
}

Explanation

Cette configuration du module de delivery Kubernetes initialise Flux avec le dépôt Git spécifié. Le chemin clusters/dev indique où se trouvent les configurations spécifiques à ce cluster de développement.

Enfin, GitOps oblige, nous utiliserons sops avec une clé age pour chiffrer les secrets dans notre dépôt Git via la clé publique. Stocker la clé privée dans Bitwarden pour une utilisation par Flux au sein du cluster pour le déchiffrement.

1
// ...
2

3
variable "flux_git_password" {
4
  type      = string
5
  sensitive = true
6
}
7

8
variable "flux_sops_age_secret_key" {
9
  type      = string
10
  sensitive = true
11
}

# ...

export TF_VAR_flux_git_password=$(bw_field password flux_git)
export TF_VAR_flux_sops_age_secret_key=$(bw_field password flux_sops_age)

Explanation

Pour obtenir la clé flux_git, aller créer un PAT nommé flux-dev, avec les droits d’accès uniquement au repo flux précédemment créée sur les metadatas en lecture puis lecture/écriture sur le contenu/code, puis récupérer la clé générée.

Utiliser age-keygen -o age.agekey pour générer une paire de clés age, puis stocker les dans votre Bitwarden sous l’item flux_sops_age.

1
variable "flux_git_repository" {
2
  description = "The flux git repository"
3
  type        = string
4
}
5

6
variable "flux_git_password" {
7
  description = "The password for the flux git repository"
8
  type        = string
9
  sensitive   = true
10
}
11

12
variable "flux_bootstrap_git_path" {
13
  description = "The path within the git repository to bootstrap flux"
14
  type        = string
15
}
16

17
variable "flux_sops_age_secret_key" {
18
  description = "The SOPS age secret key for flux"
19
  type        = string
20
  sensitive   = true
21
}

1
terraform {
2
  required_providers {
3
    flux = {
4
      source  = "fluxcd/flux"
5
      version = ">=1.0.0"
6
    }
7
  }
8
}
9

10
provider "flux" {
11
  kubernetes = {
12
    config_path = "~/.kube/config"
13
  }
14
  git = {
15
    url    = var.flux_git_repository
16
    branch = "main"
17
    http = {
18
      username = "git"
19
      password = var.flux_git_password
20
    }
21
  }
22
}

1
resource "kubernetes_namespace_v1" "flux_system" {
2
  metadata {
3
    name = "flux-system"
4
  }
5

6
  lifecycle {
7
    ignore_changes = [
8
      metadata[0].labels
9
    ]
10
  }
11
}
12

13
resource "kubernetes_secret_v1" "flux_sops_age" {
14
  metadata {
15
    name      = "sops-age"
16
    namespace = kubernetes_namespace_v1.flux_system.metadata[0].name
17
  }
18
  data = {
19
    "age.agekey" = var.flux_sops_age_secret_key
20
  }
21
}
22

23
resource "flux_bootstrap_git" "this" {
24
  path               = var.flux_bootstrap_git_path
25
  embedded_manifests = true
26

27
  components_extra = [
28
    "image-reflector-controller",
29
    "image-automation-controller"
30
  ]
31

32
  kustomization_override = file("${path.module}/kustomization.yaml")
33

34
  depends_on = [kubernetes_secret_v1.flux_sops_age]
35
}

1
apiVersion: kustomize.config.k8s.io/v1beta1
2
kind: Kustomization
3
resources:
4
  - gotk-components.yaml
5
  - gotk-sync.yaml
6
patches:
7
  - patch: |
8
      - op: add
9
        path: /spec/decryption
10
        value:
11
          provider: sops
12
          secretRef:
13
            name: sops-age
14
    target:
15
      kind: Kustomization
16
      name: flux-system
17
      namespace: flux-system

Explanation

Le 1er élément important est la configuration du provider Flux, en précisant l’accès au dépôt Git et l’accès au cluster Kubernetes nécessaire pour le bootstrapping.

Ensuite on passe à la création du secret Kubernetes contenant la clé privée age.agekey pour SOPS, qui sera utilisé par Flux pour déchiffrer les secrets stockés dans le dépôt Git.

Puis on paramètre le bootstrap Git de Flux, en spécifiant le chemin dans le dépôt Git où se trouvent les configurations spécifiques au cluster. On ajoute également les contrôleurs d’automatisation d’images pour gérer les mises à jour automatiques des images conteneurisées. Puis on applique un patch pour configurer le déchiffrement SOPS en utilisant le secret Kubernetes créé précédemment.

Plus qu’à déployer avec terraform apply pour lancer le bootstrap de Flux dans le cluster Kubernetes. Une fois le processus terminé, Flux commencera à synchroniser l’état du cluster avec le dépôt Git. Lancer kgp -n flux-system pour vérifier l’état des 6 composants flux :

1
NAME                                           READY   STATUS    RESTARTS   AGE
2
helm-controller-58854b78db-x7jc9               1/1     Running   0          19s
3
image-automation-controller-854587f458-zx5sz   1/1     Running   0          19s
4
image-reflector-controller-745b9fffd6-6wjsb    1/1     Running   0          19s
5
kustomize-controller-cc4f4cbbf-tznk5           1/1     Running   0          19s
6
notification-controller-c58679c45-jfd8l        1/1     Running   0          19s
7
source-controller-86968b9cb8-b9fz7             1/1     Running   0          18s

Nom	Tâche
`source-controller`	Synchronise les sources Git et défini l’état courant de réconciliation.
`kustomize-controller`	Applique les configurations Kustomize fournies par `source`.
`helm-controller`	Déploie les releases Helm fournies par `source`.
`image-reflector-controller`	Surveille les registres d’images pour les nouvelles versions.
`image-automation-controller`	Automatise les mises à jour des images dans les manifests.
`notification-controller`	Gère les notifications basées sur les événements dans Flux.

Nous en avons enfin fini pour l’installation de l’infrastruture Kubernetes côté Terraform. La suite concernera la partie applicative géré par Flux, la 3ème brique de ce guide.

Monitoring Flux

La 1ère chose utile serait d’installer de quoi monitorer notre instance de flux. Pour cela, nous allons nous appuyer sur le repo flux-monitoring-example qui contient déjà tout ce qu’on veut.

1
---
2
apiVersion: source.toolkit.fluxcd.io/v1
3
kind: GitRepository
4
metadata:
5
  name: flux-monitoring
6
  namespace: flux-system
7
spec:
8
  interval: 30m0s
9
  ref:
10
    branch: main
11
  url: https://github.com/fluxcd/flux2-monitoring-example
12
---
13
apiVersion: kustomize.toolkit.fluxcd.io/v1
14
kind: Kustomization
15
metadata:
16
  name: monitoring-config
17
  namespace: flux-system
18
spec:
19
  interval: 1h0m0s
20
  path: ./monitoring/configs
21
  prune: true
22
  sourceRef:
23
    kind: GitRepository
24
    name: flux-monitoring

Commiter ce fichier et vous devriez observer le déploiement automatique de :

Un PodMonitor, permettant de scrapper les métriques de flux via Prometheus, disponible via k get pmon -n monitoring -l app.kubernetes.io/part-of=flux.
Des dashboards Grafana, contenant des dashboards préconfigurés pour visualiser les métriques de flux, disponibles via k get cm -n monitoring -l app.kubernetes.io/part-of=flux.

Dashboard Flux

Tip

Pour éviter d’attendre une minute et forcer la synchronisation de l’état avec votre dépôt Git, vous pouvez utiliser la commande flux reconcile kustomization flux-system --with-source.

Cas pratique avec n8n

Pour illustrer l’utilisation de Flux pour gérer les applications dans notre cluster Kubernetes, nous allons déployer n8n, l’outil de prédilection d’automatisation de flux de travail.

Storage n8n

Commencer par créer une base de données PostgreSQL pour n8n, directement sur pgAdmin, avec un utilisateur n8n (n’oubliez pas de mettre le privilège Can login?) et de l’associer en Owner sur une même base de données n8n.

Nous voulons aussi lui dédié un volume Longhorn pour la persistance des données. Créer un volume n8n-data de 8Gi via l’interface Longhorn.

Longhorn create volume n8n

Ensuite, créer un PersistentVolume (et uniquement un PV, pas de PVC) pour ce volume Longhorn. Laissez les paramètres par défaut. Il devrait prendre le StorageClass longhorn-crypto par défaut (précisé lors de l’installation de longhorn).

Longhorn create pvc n8n

Enfin, n’oubliez pas de rajouter le groupe backup à ce volume pour qu’il soit inclus dans les backups réguliers.

Longhorn recurring jobs schedule

Tip

L’intérêt principal de passer par l’interface Longhorn pour créer le volume est de faciliter la restauration en s’assurant que le nom du volume et du backup restent consistants.

Secrets n8n

Nous allons maintenant créer les secrets nécessaires pour n8n (clé encryption n8n, mdp postgres, accès smtp), en utilisant SOPS pour chiffrer les informations sensibles. Créer les fichiers suivants dans clusters/dev/tools/ :

1
apiVersion: v1
2
kind: Secret
3
metadata:
4
  name: encryption-key-secret
5
  namespace: n8n
6
type: Opaque
7
data:
8
  N8N_ENCRYPTION_KEY: <openssl rand -hex 16 | base64>

1
apiVersion: v1
2
kind: Secret
3
metadata:
4
  name: database-secret
5
  namespace: n8n
6
type: Opaque
7
data:
8
  postgres-password: <votre-mot-de-passe-postgres | base64>

1
apiVersion: v1
2
kind: Secret
3
metadata:
4
    name: smtp-secret
5
    namespace: n8n
6
type: Opaque
7
data:
8
    N8N_SMTP_USER: <guid | base64>
9
    N8N_SMTP_PASS: <guid | base64>

Pour faciliter le chiffrement des fichiers secrets avec SOPS, créer un fichier .sops.yaml à la racine du dépôt Git :

1
creation_rules:
2
  - path_regex: clusters/dev/.*/secret-.*.yaml
3
    encrypted_regex: ^(data|stringData)$
4
    age: <votre clé publique age créée lors de l'installation de flux>

Plus qu’à chiffrer les fichiers secrets avec la commande sops.

sops -e -i clusters/dev/tools/secret-n8n-database.yaml
sops -e -i clusters/dev/tools/secret-n8n-encryption-key.yaml
sops -e -i clusters/dev/tools/secret-n8n-smtp.yaml

Sur vscode, l’extension https://github.com/kabolt/vscode-sops marche très bien.

Créer le namespace n8n puis ajouter vos secrets dans le fichier kustomization.yaml pour qu’ils soient appliqués par flux.

1
apiVersion: v1
2
kind: Namespace
3
metadata:
4
  name: n8n

1
apiVersion: kustomize.config.k8s.io/v1beta1
2
kind: Kustomization
3
resources:
4
  - deployment-n8n.yaml
5
  - secret-n8n-database.yaml
6
  - secret-n8n-smtp.yaml
7
  - secret-n8n-encryption-key.yaml

Puis commiter le tout et lancer une synchronisation avec la commande flux reconcile kustomization flux-system --with-source.

Vous devriez voir vos secrets déchiffrés via kgsec -n n8n.

Déploiement n8n

Plus qu’à déployer n8n via le fichier deploy-n8n.yaml.

1
# ...
2
---
3
apiVersion: source.toolkit.fluxcd.io/v1
4
kind: HelmRepository
5
metadata:
6
  name: n8n
7
  namespace: flux-system
8
spec:
9
  interval: 1h0m0s
10
  url: https://community-charts.github.io/helm-charts
11
---
12
apiVersion: helm.toolkit.fluxcd.io/v2
13
kind: HelmRelease
14
metadata:
15
  name: n8n
16
  namespace: flux-system
17
spec:
18
  chart:
19
    spec:
20
      chart: n8n
21
      reconcileStrategy: ChartVersion
22
      sourceRef:
23
        kind: HelmRepository
24
        name: n8n
25
      version: ">=1.15.16"
26
  interval: 1m
27
  releaseName: n8n
28
  targetNamespace: n8n
29
  maxHistory: 2
30

31
  values:
32
    strategy:
33
      type: Recreate
34

35
    main:
36
      persistence:
37
        enabled: true
38
        existingClaim: n8n-data
39
        volumeName: n8n-data
40
      extraEnvVars:
41
        N8N_EMAIL_MODE: smtp
42
        N8N_SMTP_HOST: smtp.tem.scw.cloud
43
        N8N_SMTP_PORT: "465"
44
        N8N_SMTP_SENDER: n8n@ohmytalos.io
45
      extraSecretNamesForEnvFrom:
46
        - smtp-secret
47

48
    existingEncryptionKeySecret: encryption-key-secret
49

50
    db:
51
      type: postgresdb
52

53
    externalPostgresql:
54
      host: ohmytalos-dev-rw.postgres
55
      username: n8n
56
      database: n8n
57
      existingSecret: database-secret
58

59
    serviceMonitor:
60
      enabled: true
61

62
    webhook:
63
      url: https://n8n.ohmytalos.io/
64
---
65
apiVersion: v1
66
kind: PersistentVolumeClaim
67
metadata:
68
  name: n8n-data
69
  namespace: n8n
70
spec:
71
  resources:
72
    requests:
73
      storage: 8Gi
74
  volumeName: n8n-data
75
  storageClassName: longhorn-crypto
76
  accessModes:
77
    - ReadWriteOnce
78
---
79
apiVersion: traefik.io/v1alpha1
80
kind: IngressRoute
81
metadata:
82
  name: n8n
83
  namespace: n8n
84
spec:
85
  routes:
86
    - match: Host(`n8n.ohmytalos.io`)
87
      kind: Rule
88
      services:
89
        - name: n8n
90
          port: http

Explanation

On crée d’abord un HelmRepository pour référencer le dépôt Helm officiel de n8n, puis un HelmRelease pour déployer n8n dans le namespace n8n, en utilisant les secrets précédemment créés pour la configuration.

La configuration de la base de données PostgreSQL externe est spécifiée via externalPostgresql, en utilisant le secret database-secret pour les informations d’authentification.

Enfin, on crée un PersistentVolumeClaim pour le volume Longhorn n8n-data, et une IngressRoute Traefik pour exposer n8n publiquement via le domaine n8n.ohmytalos.io. Si uniquement à vocation interne, utiliser n8n.dev.ohmytalos.io.

Et voilà, une fois le commit poussé et la synchronisation effectuée, n8n devrait être opérationnel dans votre cluster Kubernetes.

n8n dashboard

Outils DevOps

Déploiement Gitea

Allons plus loin avec l’installation de notre propre solution self-hosted VCS + CI légère, Gitea. Le processus est en tout point similaire à celui de n8n.

Création de la base de données PostgreSQL gitea avec un utilisateur gitea sur pgAdmin.
Création du volume Longhorn gitea-data chiffré de 10Gi + configuration backup, mais avec le tag volume pour stocker les données dans les disques attachés aux nœuds storage.
Création du PersistentVolume gitea-data chiffré dans Kubernetes.
Création des secrets SOPS pour Gitea (mot de passe postgres, clé secrète Gitea).
Déploiement de Gitea via HelmRelease Flux.

1
apiVersion: v1
2
kind: Secret
3
metadata:
4
  name: gitea-admin-secret
5
  namespace: gitea
6
type: Opaque
7
data:
8
  password: <password-admin-gitea | base64>
9
  username: <admin-gitea | base64>

1
apiVersion: v1
2
kind: Secret
3
metadata:
4
  name: gitea-app-ini-secret
5
  namespace: gitea
6
type: Opaque
7
data:
8
  cache: HOST=redis://:<redis-password>@dragonfly.dragonfly:6379/0
9
  database: PASSWD=<postgres-password>
10
  mailer: PASSWD=<smtp-password>
11
USER=<smtp-username>
12
  queue: CONN_STR=redis://:<redis-password>@dragonfly.dragonfly:6379/0
13
  session: PROVIDER_CONFIG=redis://:<redis-password>@dragonfly.dragonfly:6379/0
14
  storage: MINIO_ACCESS_KEY_ID=<access-key>
15
MINIO_SECRET_ACCESS_KEY=<secret-access-key>

Important

La construction de la config Gitea app.ini est un peu particulière, référez-vous à la documentation officielle pour plus de détails sur les différentes options de configuration. Le secret gitea-app-ini-secret ne concerne que les valeurs sensibles nécessaires pour configurer Gitea, telles que les informations de connexion à la base de données, les paramètres SMTP pour l’envoi d’e-mails, et la configuration du cache et de la session avec Redis, le stockage S3 externe.

N’oubliez pas de remplacer les valeurs entre chevrons par les valeurs réelles de vos secrets puis réencoder le tout en base64.

Nous allons rajouter également en frontal de Gitea Anubis pour s’éviter les ennuis liés au scraping IA sur ce genre d’instance.

1
apiVersion: v1
2
kind: Secret
3
metadata:
4
  name: gitea-anubis-key
5
  namespace: gitea
6
type: Opaque
7
data:
8
  ED25519_PRIVATE_KEY_HEX: <openssl rand -hex 32 | base64>

On chiffre tout ça :

sops -e -i clusters/dev/build/secret-gitea-admin.yaml
sops -e -i clusters/dev/build/secret-gitea-app-ini.yaml
sops -e -i clusters/dev/build/secret-gitea-anubis-key.yaml

Le point d’entrée pour flux :

1
apiVersion: kustomize.config.k8s.io/v1beta1
2
kind: Kustomization
3
resources:
4
  - deployment-gitea.yaml
5
  - secret-gitea-admin.yaml
6
  - secret-gitea-app-ini.yaml
7
  - secret-gitea-anubis-key.yaml

Le déploiement Gitea complet :

1
apiVersion: v1
2
kind: Namespace
3
metadata:
4
  name: gitea
5
---
6
apiVersion: source.toolkit.fluxcd.io/v1
7
kind: HelmRepository
8
metadata:
9
  name: gitea
10
  namespace: flux-system
11
spec:
12
  interval: 1h0m0s
13
  url: https://dl.gitea.io/charts
14
---
15
apiVersion: helm.toolkit.fluxcd.io/v2
16
kind: HelmRelease
17
metadata:
18
  name: gitea
19
  namespace: flux-system
20
spec:
21
  chart:
22
    spec:
23
      chart: gitea
24
      reconcileStrategy: ChartVersion
25
      sourceRef:
26
        kind: HelmRepository
27
        name: gitea
28
      version: ">=12.4.0"
29
  interval: 1m
30
  releaseName: gitea
31
  targetNamespace: gitea
32
  maxHistory: 2
33

34
  values:
35
    image:
36
      tag: "1.25.3"
37
    gitea:
38
      admin:
39
        existingSecret: gitea-admin-secret
40
        email: admin@ohmytalos.io
41
      metrics:
42
        enabled: true
43
        serviceMonitor:
44
          enabled: true
45
      additionalConfigSources:
46
        - secret:
47
            secretName: gitea-app-ini-secret
48
      config:
49
        server:
50
          DOMAIN: gitea.ohmytalos.io
51
          SSH_DOMAIN: ssh.ohmytalos.io
52
          ROOT_URL: https://gitea.ohmytalos.io
53
        database:
54
          DB_TYPE: postgres
55
          HOST: ohmytalos-dev-rw.postgres
56
          NAME: gitea
57
          USER: gitea
58
        storage:
59
          STORAGE_TYPE: local
60
          MINIO_ENDPOINT: s3.gra.io.cloud.ovh.net
61
          MINIO_LOCATION: gra
62
          MINIO_BUCKET: ohmytalos-dev
63
          MINIO_USE_SSL: true
64
        storage.attachments:
65
          STORAGE_TYPE: local
66
          MINIO_BASE_PATH: attachments/
67
        storage.actions_log:
68
          STORAGE_TYPE: local
69
          MINIO_BASE_PATH: actions_log/
70
        storage.packages:
71
          STORAGE_TYPE: minio
72
          MINIO_BASE_PATH: gitea/packages/
73
        indexer:
74
          REPO_INDEXER_ENABLED: true
75
        mailer:
76
          ENABLED: true
77
          FROM: gitea@ohmytalos.io
78
          SMTP_ADDR: smtp.tem.scw.cloud
79
          SMTP_PORT: "587"
80
        cache:
81
          ADAPTER: redis
82
        session:
83
          PROVIDER: redis
84
        queue:
85
          TYPE: redis
86
        service:
87
          DISABLE_REGISTRATION: true
88
        repository:
89
          DEFAULT_BRANCH: main
90
        metrics:
91
          ENABLED_ISSUE_BY_REPOSITORY: true
92
          ENABLED_ISSUE_BY_LABEL: true
93
        webhook:
94
          ALLOWED_HOST_LIST: "*"
95

96
    postgresql-ha:
97
      enabled: false
98

99
    valkey-cluster:
100
      enabled: false
101

102
    persistence:
103
      create: false
104
      claimName: gitea-data
105

106
    strategy:
107
      type: Recreate
108

109
    resources:
110
      requests:
111
        cpu: 100m
112
        memory: 1Gi
113
      limits:
114
        cpu: 2000m
115
        memory: 1Gi
116

117
    tolerations:
118
      - key: node-role.kubernetes.io/storage
119
        operator: Exists
120
    nodeSelector:
121
      node.kubernetes.io/role: storage
122
---
123
apiVersion: v1
124
kind: PersistentVolumeClaim
125
metadata:
126
  name: gitea-data
127
  namespace: gitea
128
spec:
129
  resources:
130
    requests:
131
      storage: 10Gi
132
  volumeName: gitea-data
133
  storageClassName: longhorn-crypto
134
  accessModes:
135
    - ReadWriteOnce
136
---
137
apiVersion: apps/v1
138
kind: Deployment
139
metadata:
140
  name: anubis
141
  namespace: gitea
142
spec:
143
  selector:
144
    matchLabels:
145
      app: anubis
146
  template:
147
    metadata:
148
      labels:
149
        app: anubis
150
    spec:
151
      containers:
152
        - name: anubis
153
          image: ghcr.io/techarohq/anubis:latest
154
          env:
155
            - name: BIND
156
              value: :8080
157
            - name: DIFFICULTY
158
              value: "4"
159
            - name: ED25519_PRIVATE_KEY_HEX
160
              valueFrom:
161
                secretKeyRef:
162
                  name: gitea-anubis-key
163
                  key: ED25519_PRIVATE_KEY_HEX
164
            - name: METRICS_BIND
165
              value: :9090
166
            - name: SERVE_ROBOTS_TXT
167
              value: "true"
168
            - name: TARGET
169
              value: http://gitea-http.gitea.svc:3000
170
            - name: OG_PASSTHROUGH
171
              value: "true"
172
            - name: OG_EXPIRY_TIME
173
              value: 24h
174
          resources:
175
            limits:
176
              cpu: 750m
177
              memory: 256Mi
178
            requests:
179
              cpu: 250m
180
              memory: 256Mi
181
          securityContext:
182
            runAsUser: 1000
183
            runAsGroup: 1000
184
            runAsNonRoot: true
185
            allowPrivilegeEscalation: false
186
            capabilities:
187
              drop:
188
                - ALL
189
            seccompProfile:
190
              type: RuntimeDefault
191
---
192
apiVersion: v1
193
kind: Service
194
metadata:
195
  name: anubis
196
  namespace: gitea
197
spec:
198
  selector:
199
    app: anubis
200
  ports:
201
    - name: http
202
      port: 8080
203
---
204
apiVersion: traefik.io/v1alpha1
205
kind: IngressRouteTCP
206
metadata:
207
  name: gitea-ssh
208
  namespace: gitea
209
spec:
210
  entryPoints:
211
    - ssh
212
  routes:
213
    - match: HostSNI(`*`)
214
      services:
215
        - name: gitea-ssh
216
          port: ssh
217
---
218
apiVersion: traefik.io/v1alpha1
219
kind: IngressRoute
220
metadata:
221
  name: gitea-http
222
  namespace: gitea
223
spec:
224
  routes:
225
    - match: Host(`gitea.ohmytalos.io`) && PathRegexp(`^/(api|v2)`)
226
      kind: Rule
227
      services:
228
        - name: gitea-http
229
          port: http
230
    - match: Host(`gitea.ohmytalos.io`) && !PathRegexp(`^/(api|v2)`)
231
      kind: Rule
232
      services:
233
        - name: anubis
234
          port: http

Explanation

Ça commence à devenir assez velu, mais le principe reste le même que pour n8n. On crée un namespace gitea, puis on déploie Gitea via un HelmRelease, en utilisant les secrets SOPS.

On s’assure de configurer l’accès au postgresql, au SMTP et au S3 OVH externe (n’oublier de configurer des accès gitea dédiés). Le stockage S3 n’est activé que sur la partie packages, le plus volumineux (artifacts, registry docker), le reste notamment les repos git restant sur le volume local longhorn.

Nous déployons Gitea sur les nœuds storage, nécessaire pour se brancher au volume Longhorn créé précédemment sur les disques externes via le tag volume.

Côté Ingress, on rajoute l’entrée ssh pour le git over ssh, et on place Anubis en frontal HTTP sauf pour les routes API et docker registry pour éviter de se faire bloquer côté client docker cli ou runner.

Commiter et espérer. Déboguer avec kgp -n gitea en cas de problème et vérifier les logs des pods Gitea et Anubis.

Et voilà, c’est magnifique, tester immédiatement la connexion admin puis la section dashboard.

Gitea Home

Gitea Dashboard

Déploiement SonarQube

Allons encore plus loin avec l’installation de SonarQube pour l’analyse de la qualité du code. Le processus reste similaire à celui de n8n et Gitea, en plus simple sans nécessité de persistance.

1
apiVersion: v1
2
kind: Secret
3
metadata:
4
  name: sonarqube-secret
5
  namespace: sonarqube
6
type: Opaque
7
data:
8
  db-password: <mot-de-passe-postgres | base64>
9
  monitoring-passcode: <mot-de-passe-monitoring | base64>

1
apiVersion: kustomize.config.k8s.io/v1beta1
2
kind: Kustomization
3
resources:
4
  - #...
5
  - deployment-sonarqube.yaml
6
  - secret-sonarqube.yaml

1
apiVersion: v1
2
kind: Namespace
3
metadata:
4
  name: sonarqube
5
  labels:
6
    pod-security.kubernetes.io/enforce: "privileged"
7
---
8
apiVersion: source.toolkit.fluxcd.io/v1
9
kind: HelmRepository
10
metadata:
11
  name: sonarqube
12
  namespace: flux-system
13
spec:
14
  interval: 1h0m0s
15
  url: https://SonarSource.github.io/helm-chart-sonarqube
16
---
17
apiVersion: helm.toolkit.fluxcd.io/v2
18
kind: HelmRelease
19
metadata:
20
  name: sonarqube
21
  namespace: flux-system
22
spec:
23
  chart:
24
    spec:
25
      chart: sonarqube
26
      reconcileStrategy: ChartVersion
27
      sourceRef:
28
        kind: HelmRepository
29
        name: sonarqube
30
      version: ">=2025.6.0"
31
  interval: 1m
32
  releaseName: sonarqube
33
  targetNamespace: sonarqube
34
  maxHistory: 2
35

36
  values:
37
    community:
38
      enabled: true
39
      buildNumber: "26.1.0.118079"
40

41
    monitoringPasscode: null
42
    monitoringPasscodeSecretName: sonarqube-secret
43
    monitoringPasscodeSecretKey: monitoring-passcode
44

45
    resources:
46
      requests:
47
        cpu: 100m
48
        memory: 3Gi
49
      limits:
50
        cpu: 1000m
51
        memory: 3Gi
52

53
    prometheusMonitoring:
54
      podMonitor:
55
        enabled: true
56
        namespace: sonarqube
57

58
    jdbcOverwrite:
59
      enable: true
60
      jdbcUrl: jdbc:postgresql://ohmytalos-dev-rw.postgres/sonarqube
61
      jdbcUsername: sonarqube
62
      jdbcSecretName: sonarqube-secret
63
      jdbcSecretPasswordKey: db-password
64

65
    postgresql:
66
      enabled: false
67
---
68
apiVersion: traefik.io/v1alpha1
69
kind: IngressRoute
70
metadata:
71
  name: sonarqube
72
  namespace: sonarqube
73
spec:
74
  routes:
75
    - match: Host(`sonarqube.ohmytalos.io`)
76
      kind: Rule
77
      services:
78
        - name: sonarqube-sonarqube
79
          port: http

Pour le coup bien plus simple, rien de nouveau par rapport à ce qu’on a déjà vu. Commité et admirer (attention les yeux le dark mode est uniquement présent sur la version payante, les filous).

SonarQube Home

Conclusion

Voilà, nous avons mis en place un système de déploiement continu (CD) avec Flux dans notre cluster Kubernetes. Nous avons également déployé plusieurs applications pratiques telles que n8n, Gitea et SonarQube, avec support des mises à jour automatique des charts Helm.

Il est temps de tester notre infrastructure sur toute la chaîne, sur un cas concret d’application type, du développement jusqu’à la production, suite dans la prochaine section.