Configuration

Le chart se configure à partir d'un fichier de valeurs Helm. example-values.yaml, livré dans le chart, est un exemple complet et fonctionnel — copiez-le et remplacez les valeurs d'exemple, comme décrit dans Installation.

Lorsqu'une valeur correspond à une variable d'environnement du déploiement Docker, cette page renvoie vers la référence de configuration Docker plutôt que de la répéter.

_Obligatoire_ signifie que la plateforme ne fonctionnera pas tant que la valeur n'est pas renseignée.

Valeurs générales et communes

Valeur	Valeur par défaut	Description
`envName`	Aucune	Nom de l'environnement, affiché à des fins de support. Équivalent de `ENV_NAME`.
`imageCredentials.dockerConfigJson`	Obligatoire	base64 d'un `config.json` Docker avec les identifiants `quay.io/octopize`. Octopize les fournit.
`global.imageRegistry`	Aucune	Récupérer toutes les images du chart depuis ce registre. À utiliser pour une installation par miroir.
`global.imagePullSecrets`	`[]`	Secrets de pull existants à ajouter à tous les pods. Les entrées sont des maps : `- name: my-registry-creds`.
`nameOverride`	Aucune	Valeur du label `app.kubernetes.io/name` sur chaque objet.
`commonLabels`	`{}`	Labels supplémentaires sur chaque objet créé par le chart.
`commonAnnotations`	`{}`	Annotations supplémentaires sur chaque objet créé par le chart.

Générer les secrets

L'archive du chart contient un script qui fabrique ces valeurs pour vous. Lancez-le dans le répertoire qu'a écrit helm pull --untar :

bash scripts/generate-secrets.sh

Utilisez bash, et non ./. Helm empaquette chaque fichier avec le mode 0644, donc la copie dans l'archive n'est pas exécutable.

Le script écrit avatar-secrets.yaml. Donnez ce fichier à Helm après votre propre fichier de valeurs, et donnez-le à chaque mise à jour :

helm install avatar . --values my-values.yaml --values avatar-secrets.yaml

Helm obéit au dernier fichier --values, donc le fichier généré remplace ces clés dans votre propre fichier. Gardez ces clés hors de votre propre fichier. Si vous avez déjà un de ces identifiants, écrivez-le dans le fichier généré. Un storage.sseKek qui protège des objets stockés en est l'exemple habituel.

Conservez le fichier généré. Une deuxième exécution du script écrit un nouveau fichier. Elle ne remplace pas un fichier qui existe, car storage.sseKek ne peut pas changer après la première installation.

Le script ne fabrique pas les valeurs qui appartiennent à votre propre infrastructure. Ce sont les identifiants administrateur de PostgreSQL, le secret de pull du registre, le relais SMTP, les noms d'hôte et les identifiants d'un point d'accès S3 externe. Le script les liste quand il s'arrête.

Vous pouvez aussi fabriquer chaque valeur vous-même. Chaque secret que vous devez inventer fait 32 octets aléatoires. Nous les écrivons en hexadécimal, soit 64 caractères, mais le chart ne l'exige pas. Seuls storage.sseKek et databaseConnections.encryptionKeys ont une contrainte, et les autres valeurs acceptent tout texte non vide.

python -c "import secrets; print(secrets.token_hex(nbytes=32), end='')"
openssl rand -hex 32

Valeur	Contrainte	Si vous la changez plus tard
`api.auth.jwtSecretKey`	Aucune	Chaque utilisateur doit se reconnecter. Rien de stocké n'est perdu
`database.password`	Tout texte que PostgreSQL accepte comme mot de passe	Changez-le d'abord sur le serveur. Voir Changer un mot de passe de base de données
`storage.admin.accessKeyId`	Aucune	Sans risque avec le SeaweedFS intégré, que le chart écrit depuis cette valeur. Avec votre propre `existingConfigSecret`, changez-la des deux côtés en même temps
`storage.admin.secretAccessKey`	Aucune	Comme ci-dessus
`storage.sseKek`	64 caractères hexadécimaux minuscules. Le chart le vérifie seulement quand il écrit lui-même le Secret	Ne la changez jamais. Chaque objet stocké devient illisible
`storage.seaweedfsAdminPassword`	Aucune	Redémarrez le serveur d'administration SeaweedFS : `kubectl rollout restart statefulset/seaweedfs-admin`
`sso.clientId`	Aucune. Ce n'est pas un secret, mais il se fabrique de la même façon	Redémarrez le serveur et le worker Authentik, puis appliquez de nouveau le blueprint
`sso.clientSecret`	Aucune	Redémarrez le serveur et le worker Authentik, puis appliquez de nouveau le blueprint
`sso.apiToken`	Aucune	Redémarrez le serveur et le worker Authentik, puis appliquez de nouveau le blueprint
`sso.webhookSecret`	Aucune	Redémarrez le serveur et le worker Authentik, puis appliquez de nouveau le blueprint
`authentik.authentik.secret_key`	Aucune.	Chaque utilisateur doit se reconnecter à Authentik
`authentik.authentik.postgresql.password`	Tout texte que PostgreSQL accepte comme mot de passe	Changez-le d'abord sur le serveur. Voir Changer un mot de passe de base de données
`connector.secret`	Aucune. Lue seulement quand `connector.enabled` vaut `true`	Les jetons des jobs de base de données en cours deviennent invalides. Voir Connecteur de bases de données
`databaseConnections.encryptionKeys`	Une clé Fernet, pas une chaîne hexadécimale. Voir Connecteur de bases de données	Placez la nouvelle clé en premier et gardez l'ancienne. Voir Connecteur de bases de données

database.adminPassword ne figure pas dans la liste, car son origine dépend de votre serveur. Si vous créez le compte administrateur pour Avatar, fabriquez son mot de passe comme les autres. Si vous pointez le chart vers un compte qui existe déjà, par exemple un administrateur de PostgreSQL managé ou un rôle provisionné par un DBA, utilisez le mot de passe qu'il a déjà. Le chart ne crée jamais ce rôle et ne change jamais son mot de passe. Pour le changer, changez-le sur le serveur, puis mettez la valeur à jour.

Vous renseignez les quatre valeurs SSO une seule fois, sous sso. Helm ne peut pas écrire dans les valeurs d'un sous-chart, donc les entrées AVATAR_AUTHENTIK_BLUEPRINT_* sous authentik.global.env référencent les objets dans lesquels le chart écrit ces valeurs. Le blueprint relit ainsi la valeur que vous avez posée. Le chart compare les deux références et refuse le rendu si elles ne concordent pas. Pour garder ces valeurs hors du fichier, voir Utiliser des Secrets existants.

Utiliser des Secrets existants

Par défaut, vous écrivez chaque identifiant dans votre fichier de valeurs. Le chart peut à la place lire chacun d'eux depuis un Secret. Créez ce Secret dans le namespace avant l'installation, avec external-secrets, sealed-secrets, Vault ou kubectl create secret. Le chart se contente de le lire : votre fichier de valeurs ne contient alors aucun identifiant, et vous pouvez le versionner.

example-values-existing-secrets.yaml, livré dans le chart, est une installation complète sans aucun identifiant dans un fichier de valeurs. Ajoutez-le après le vôtre :

helm install avatar oci://quay.io/octopize/helm/services-api/avatar \
  --version <version> --namespace avatar --create-namespace \
  --values my-values.yaml \
  --values example-values-existing-secrets.yaml

Chaque identifiant emprunte l'une de quatre voies : les sept blocs que le chart gère, le pull d'images, les réglages propres à Authentik, ou SeaweedFS. Les trois dernières existent parce que Helm ne peut pas écrire dans les valeurs d'un sous-chart.

Les blocs que le chart gère

Sept blocs contiennent des identifiants : database, api.auth, storage, sso, smtp, telemetry.s3 et authentikDatabase. Chacun accepte les valeurs en clair, existingSecret pour nommer le Secret, et secretKeys pour associer chaque identifiant à une clé de ce Secret.

database:
  password: "" # vide : le Secret ci-dessous le fournit
  adminPassword: ""
  existingSecret: avatar-secrets
  secretKeys:
    password: db-password # la clé dans ce Secret
    adminPassword: db-admin-password

Un seul Secret peut servir tous les blocs, et chaque bloc peut aussi avoir le sien. Sans secretKeys, chaque bloc cherche ces noms de clés :

Bloc	Identifiant	Clé recherchée
`database`	`password`, `adminPassword`	`db-password`, `db-admin-password`
`api.auth`	`jwtSecretKey`	`authjwt-secret-key`
`storage`	`admin.accessKeyId`, `admin.secretAccessKey`	`storage-access-key-id`, `storage-secret-access-key`
`sso`	`clientSecret`, `apiToken`, `webhookSecret`	`sso-client-secret`, `sso-api-token`, `sso-webhook-secret`
`smtp`	`password`	`smtp-password`
`telemetry.s3`	`accessKeyId`, `secretAccessKey`	`telemetry-s3-access-key-id`, `telemetry-s3-secret-access-key`
`authentikDatabase`	mot de passe de la base d'Authentik	`authentik-db-password`

Le connecteur de bases de données a deux blocs de plus : connector (clé connector-secret) et databaseConnections (clés database-connections et connection-encryption-keys). Ils acceptent existingSecret et secretKeys de la même façon.

Quatre règles s'appliquent :

Chaque clé nommée par secretKeys doit exister dans le Secret. Si une clé est absente, les pods qui la montent ne démarrent pas.
Pour garder un identifiant dans le fichier de valeurs, videz son entrée secretKeys.
Si vous renseignez une valeur en clair et existingSecret en même temps, le Secret l'emporte et la valeur en clair est ignorée. Le chart n'avertit pas : videz les valeurs que le Secret fournit.
Une nouvelle valeur dans un Secret ne redémarre pas les pods. Faites un kubectl rollout restart sur l'API ainsi que sur le serveur et le worker Authentik. Pour un mot de passe de base de données, changez-le d'abord sur le serveur. Voir Changer un mot de passe de base de données.

Pour activer database.existingSecret ou authentikDatabase.existingSecret sur une release qui existe déjà, augmentez aussi la version du chart. Voir Vérification et dépannage.

Identifiants de pull d'images

Renseignez global.imagePullSecrets avec des Secrets de pull que vous avez créés, et videz imageCredentials.dockerConfigJson. Cette valeur atteint tous les pods du chart ainsi que les pods Authentik et SeaweedFS, mais pas Dask, qui nomme ses Secrets de pull lui-même. Chaque entrée doit être une map, pas un nom simple. Le chart ne fait échouer le rendu sur un nom simple que si Authentik est activé.

imageCredentials:
  dockerConfigJson: ""
global:
  imagePullSecrets:
    - name: my-registry-creds
dask:
  scheduler:
    image:
      pullSecrets:
        - name: my-registry-creds
  worker:
    image:
      pullSecrets:
        - name: my-registry-creds

Authentik

Authentik lit AUTHENTIK_SECRET_KEY, AUTHENTIK_POSTGRESQL__PASSWORD et AUTHENTIK_EMAIL__PASSWORD depuis son environnement. Ajoutez pour chacun une entrée authentik.global.env avec un secretKeyRef, et videz le réglage authentik.authentik.* correspondant. Le sous-chart laisse alors ce réglage en dehors de son propre Secret, ce qui libère le nom de variable.

authentik:
  global:
    env:
      # Helm remplace cette liste. Redonnez chaque entrée dont vous avez besoin.
      - name: AUTHENTIK_SECRET_KEY
        valueFrom:
          secretKeyRef:
            name: avatar-secrets
            key: authentik-secret-key
      - name: AUTHENTIK_POSTGRESQL__PASSWORD
        valueFrom:
          secretKeyRef:
            name: avatar-secrets
            key: authentik-db-password
  authentik:
    secret_key: ""
    postgresql:
      password: ""

authentikDatabase.existingSecret est le côté Avatar de ce même mot de passe de base de données. Il indique au Job d'amorçage et aux init containers d'attente où le lire.

SeaweedFS

SeaweedFS lit son identité d'administration dans un seul document JSON, et non dans une clé par identifiant. Construisez ce Secret à la main. Le même Secret peut aussi contenir l'utilisateur et le mot de passe d'administration SeaweedFS :

kubectl create secret generic avatar-seaweedfs-secrets \
  --from-literal=sse-kek=<64 caractères hexadécimaux> \
  --from-literal=admin-user=admin \
  --from-literal=admin-password=<mot-de-passe> \
  --from-literal=seaweedfs_s3_config='{"identities":[{"name":"power_user","credentials":[{"accessKey":"...","secretKey":"..."}],"actions":["Admin"]}]}'

storage:
  sseKek: "" # vide : l'entrée ci-dessous le fournit
  seaweedfsAdminPassword: "" # vide : admin.secret ci-dessous le fournit
seaweedfs:
  admin:
    secret:
      existingSecret: avatar-seaweedfs-secrets
      userKey: admin-user
      pwKey: admin-password
  s3:
    existingConfigSecret: avatar-seaweedfs-secrets
    extraEnvironmentVars:
      WEED_S3_SSE_KEK:
        secretKeyRef:
          name: avatar-seaweedfs-secrets
          key: sse-kek

La clé d'accès et la clé secrète de ce document JSON sont la même paire que storage.existingSecret donne à l'API. Les deux doivent concorder, et le chart refuse le rendu si un identifiant reste à un endroit qui l'emporterait sans message.

Après avoir changé le mot de passe d'administration dans le Secret, exécutez kubectl rollout restart statefulset/seaweedfs-admin.

Surcharger une valeur définie par le chart

Trois des ConfigMaps que le chart génère contiennent sa configuration d'exécution. Leurs clés deviennent des variables d'environnement dans les conteneurs. Les autres contiennent l'habillage, les modèles et les traductions d'Authentik, qui sont des fichiers et non des réglages.

ConfigMap	Lu par	Construit à partir de
`avatar-api-config`	les pods API, le CronJob sync-tables, l'ordonnanceur Dask, les pods `helm test`	`ingress`, `envName`, `database`, `storage`, `sso`, `smtp`, `telemetry`, `api.config`
`avatar-web-config`	les pods web	`ingress`, `storage`, `web.config`, `envName`
`avatar-authentik-config`	le serveur et le worker Authentik	`ingress`, `api.service.port`, `sso.trustedProxyCidrs`

Ne modifiez pas ces objets avec kubectl. Le prochain helm upgrade les génère de nouveau depuis vos valeurs. Pour changer une clé, renseignez la valeur dont le chart la construit. Les tableaux de cette page donnent ces valeurs. Si le chart n'a aucune valeur pour cette clé, surchargez la clé sur le conteneur.

Sur les charges de travail que le chart gère

api, web, syncTables et tests acceptent chacun une liste extraEnvVars, dans la forme env de Kubernetes. Le chart écrit ses propres entrées d'abord, puis ajoute cette liste. L'API server accepte les noms en double et ne définit aucun ordre, mais le kubelet construit l'environnement dans l'ordre : le conteneur reçoit donc la dernière entrée portant un nom donné. Une entrée ici remplace ainsi la valeur de la ConfigMap.

Cet exemple pointe DB_HOST vers une ConfigMap à vous :

api:
  extraEnvVars:
    - name: DB_HOST
      valueFrom:
        configMapKeyRef:
          name: my-database-config
          key: host

Cette même liste remplace aussi un identifiant. L'API lit ses identifiants dans des fichiers que le chart monte, mais une variable d'environnement a une priorité plus haute que ces fichiers. Une entrée qui porte le nom d'un identifiant l'emporte donc :

api:
  extraEnvVars:
    - name: DB_PASSWORD
      valueFrom:
        secretKeyRef:
          name: my-database-credentials
          key: password

Une valeur vide ne surcharge rien : l'API ignore une variable d'environnement vide et utilise le fichier monté.

Utilisez la même liste pour une variable que le chart ne connaît pas du tout, par exemple un HTTPS_PROXY.

Deux points de plus. api.extraEnvVars atteint aussi chaque init container du chart, c'est-à-dire la préparation de la base et la fusion du bundle de CA, car leur environnement doit être correct avant le début des migrations. Et Helm ne traite pas ces valeurs comme des templates : un {{ dans une valeur est du texte, pas de la syntaxe.

Sur les sous-charts

extraEnvVars n'atteint ni Authentik, ni Dask, ni SeaweedFS. Chaque sous-chart a sa propre clé :

Sous-chart	Clé	Forme
`authentik`	`authentik.global.env` pour les deux pods, `authentik.server.env` ou `authentik.worker.env` pour un seul	une liste d'entrées `env` avec `value` ou `valueFrom`
`dask`	`dask.scheduler.env`, `dask.worker.env`	la même forme de liste
`seaweedfs`	`seaweedfs.global.seaweedfs.extraEnvironmentVars` pour tous les composants, `seaweedfs.<composant>.extraEnvironmentVars` pour un	une map de noms de variables : une chaîne devient `value`, une map devient `valueFrom`

Authentik. avatar-authentik-config arrive par authentik.global.envFrom. Kubernetes donne à env une priorité plus haute qu'à envFrom : une entrée global.env du même nom remplace donc la clé. Si vous surchargez envFrom, gardez l'entrée configMapRef. Sans elle, Authentik perd le domaine sous lequel il enregistre l'application Avatar.
Dask. dask.scheduler.env lit déjà ENV_NAME et IS_SENTRY_ENABLED dans avatar-api-config avec configMapKeyRef. Lisez de la même façon toute autre clé de cette ConfigMap, ou une clé d'un Secret à vous.
SeaweedFS. Le extraEnvironmentVars d'un composant remplace l'entrée globale du même nom. Une valeur de type map devient un valueFrom, comme le montre WEED_S3_SSE_KEK ci-dessus.

dask:
  worker:
    env:
      - name: LOG_LEVEL
        valueFrom:
          configMapKeyRef:
            name: avatar-api-config
            key: LOG_LEVEL

Helm remplace une liste env, il ne la fusionne pas

Si votre fichier de valeurs renseigne authentik.global.env, dask.scheduler.env ou dask.worker.env, redonnez chaque entrée que le values.yaml livré définit. Sinon, les pods les perdent.

Un conteneur lit son environnement une seule fois, au démarrage

Une modification de votre propre ConfigMap ou Secret ne redémarre rien. Les annotations checksum du chart ne couvrent que ce qu'il génère lui-même. Faites un kubectl rollout restart sur les charges de travail qui lisent la valeur.

Base de données

Vous fournissez le serveur. Le chart y crée les bases, les rôles et les extensions.

Valeur	Valeur par défaut	Description
`database.host`	Obligatoire	Nom d'hôte du serveur PostgreSQL.
`database.port`	`5432`	Port de ce serveur.
`database.name`	`avatar`	Nom de la base Avatar. Équivalent de `DB_NAME`.
`database.username`	`avatar`	Rôle avec lequel l'API se connecte. Équivalent de `DB_USER`.
`database.password`	Obligatoire	Mot de passe de ce rôle.
`database.adminUsername`	Obligatoire	Compte administrateur qui crée les rôles et les bases. Non monté dans l'API en fonctionnement.
`database.adminPassword`	Obligatoire	Mot de passe du compte administrateur.

Ce que le chart crée

Objet	Nom par défaut	Créé par	Se connecte comme
Le rôle Avatar	`database.username`, `avatar`	l'init container `init-avatar-api`, qui exécute `bin/dbtool.py setup`	`database.adminUsername`
La base Avatar, ses tables et la première organisation	`database.name`, `avatar`	le même init container	`database.adminUsername`
Le rôle Authentik	`authentik.authentik.postgresql.user`, `authentik`	le Job `avatar-authentik-db-init-<version du chart>`	`database.adminUsername`
La base Authentik, avec les extensions `uuid-ossp` et `citext`	`authentik.authentik.postgresql.name`, `authentik`	le même Job	`database.adminUsername`
Les tables Authentik	—	le serveur Authentik, au premier démarrage	`authentik.authentik.postgresql.user`

Les deux étapes sont idempotentes et rejouées à chaque rollout, car l'init container fait partie du template de pod de l'API et le nom du Job contient la version du chart. L'init container migre aussi le schéma Avatar lors d'une mise à niveau : il exécute les migrations sur une base existante, et crée les tables sur une base neuve.

authentikDatabase.createDatabase: false arrête le Job. Utilisez-le quand un DBA a déjà créé le rôle et la base d'Authentik, ou quand aucun compte disponible depuis le cluster ne peut en créer une. La base Avatar n'a pas d'équivalent, parce que l'init container porte aussi les migrations. Créez à l'avance ce que vous voulez, l'init container le trouve.

Quel rôle fait quoi

Rôle	Fait	Utilisé par
`database.adminUsername`	crée les rôles et les bases, pose le schéma, exécute les migrations	l'init container `init-avatar-api` et le Job d'amorçage Authentik
`database.username`	chaque requête qu'Avatar fait en fonctionnement	le conteneur API, le CronJob sync-tables et les pods `helm test`
`authentik.authentik.postgresql.user`	le schéma et les requêtes d'Authentik	le serveur et le worker Authentik

Le mot de passe administrateur n'est pas dans le Secret de l'API en fonctionnement. Il va seulement à l'init container et au Job d'amorçage : un conteneur API en fonctionnement ne peut pas le lire.

Ce dont chaque rôle a besoin

database.adminUsername est le seul compte que vous devez créer. Il n'a pas besoin d'être superutilisateur.

Il lui faut	Parce que
`LOGIN`	Il se connecte au serveur.
`CONNECT` sur `template1`	Le setup y exécute ses instructions à l'échelle du serveur. Il y cherche aussi le rôle et la base, même quand les deux existent déjà. Si votre serveur ne le permet pas, renseignez `DB_MASTER_NAME` dans `api.extraEnvVars`.
`CONNECT` sur `postgres`	Le Job d'amorçage Authentik fait de même depuis la base `postgres`.
`CREATEROLE`	Il crée les deux rôles. Inutile si vous les créez.
`CREATEDB`	Il crée les deux bases. Inutile si vous les créez.
La propriété de la base Avatar et de son schéma `public`	Le setup y crée les tables, exécute les migrations et fait `REVOKE CREATE ON SCHEMA public FROM PUBLIC`. `CREATE DATABASE` sans clause `OWNER` lui donne la base. À partir de PostgreSQL 15, cela comprend aussi le schéma `public`. Avant 15, le schéma reste au superutilisateur d'amorçage et vous devez le transférer.

database.username a besoin de LOGIN seulement. Le setup lui donne SELECT, INSERT, UPDATE et DELETE sur chaque table de public, et le refait à chaque rollout, si bien qu'une migration qui ajoute une table ne la laisse pas sans permissions. Le CONNECT vient du droit que PostgreSQL donne par défaut à PUBLIC. Ce rôle ne reçoit jamais CREATE et ne fait jamais de DDL.

Le rôle Authentik possède la base d'Authentik et exécute les migrations d'Authentik. Le chart ne lui donne aucune permission sur la base Avatar.

Changer un mot de passe de base de données

Le chart définit le mot de passe d'un rôle une seule fois, quand il crée le rôle. Il ne le change jamais ensuite. Le setup crée le rôle Avatar seulement quand ce rôle est absent, et le Job d'amorçage crée le rôle Authentik seulement quand il est absent. Aucun des deux ne fait ALTER ROLE.

Une nouvelle valeur dans database.password n'atteint donc pas PostgreSQL. Elle change seulement le mot de passe que l'API envoie. Les deux valeurs ne concordent plus, et l'API ne peut plus se connecter. L'init container init-avatar-api s'arrête sur son test de connexion, et le pod ne démarre pas.

Changez d'abord le mot de passe sur le serveur :

ALTER ROLE avatar WITH PASSWORD '<nouveau mot de passe>';

Renseignez ensuite la nouvelle valeur, ou écrivez-la dans le Secret qui la contient, puis redémarrez les charges de travail qui la lisent :

kubectl rollout restart deployment/avatar-api

Le CronJob sync-tables et les pods helm test lisent le même mot de passe. Ils le reçoivent à leur exécution suivante : ils n'ont pas besoin de redémarrage.

authentik.authentik.postgresql.password fonctionne de la même façon. Exécutez ALTER ROLE authentik WITH PASSWORD '<nouveau mot de passe>', puis redémarrez deployment/avatar-authentik-server et deployment/avatar-authentik-worker.

Cette panne est visible et ne perd rien

L'API ne sert pas avec un mot de passe qui ne fonctionne pas, et aucune donnée ne change. Pour revenir en arrière, exécutez le ALTER ROLE ci-dessus, ou remettez l'ancienne valeur.

Créer les bases à la main

Le SQL ci-dessous fait ce que fait le chart. Exécutez-le en superutilisateur, ou avec tout compte qui peut créer des rôles et des bases sur ce serveur.

-- 1. Le compte administrateur que vous donnez au chart. Vous pouvez retirer
--    CREATEDB et CREATEROLE si vous faites aussi les étapes 2 et 3.
CREATE ROLE avatar_dba WITH LOGIN PASSWORD '<database.adminPassword>' CREATEDB CREATEROLE;

-- 2. Le rôle et la base Avatar. Optionnel : le setup crée les deux s'ils sont
--    absents. Créez-les ici pour retirer CREATEDB et CREATEROLE ci-dessus.
CREATE ROLE avatar WITH LOGIN PASSWORD '<database.password>';
CREATE DATABASE avatar OWNER avatar_dba;

-- 3. Le rôle et la base Authentik. C'est ce que
--    authentikDatabase.createDatabase: false s'attend à trouver.
CREATE ROLE authentik WITH LOGIN PASSWORD '<authentik.authentik.postgresql.password>';
CREATE DATABASE authentik OWNER authentik;
\connect authentik
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
CREATE EXTENSION IF NOT EXISTS "citext";

PostgreSQL 14 et antérieurs

Le superutilisateur d'amorçage possède le schéma public, et non le propriétaire de la base. Le setup n'échoue pas sans cette étape. Son REVOKE CREATE ON SCHEMA public FROM PUBLIC affiche WARNING: no privileges could be revoked for "public" et continue : l'installation réussit et cette seule mesure de durcissement est ignorée sans erreur. Donnez la propriété au compte administrateur :

\connect avatar
ALTER SCHEMA public OWNER TO avatar_dba;

Ces valeurs décrivent ensuite ce que vous avez créé :

database:
  host: postgres.example.com
  port: "5432"
  name: avatar
  username: avatar
  password: <database.password>
  adminUsername: avatar_dba
  adminPassword: <database.adminPassword>

authentikDatabase:
  createDatabase: false # uniquement si vous avez fait l'étape 3

authentik:
  authentik:
    postgresql:
      host: postgres.example.com
      name: authentik
      user: authentik
      password: <authentik.authentik.postgresql.password>

Gardez les mots de passe dans des Secrets, pas dans ce fichier. Voir Utiliser des Secrets existants.

Ingress et contrat d'URL

Un seul hôte, et quel chemin y sert quoi :

Chemin	Servi par	Préfixe
`/api`	L'API	Supprimé
`/web`	Le client web	Conservé
`/storage`	La passerelle S3	Supprimé
`/sso`, `/`	Authentik	Conservé

ingress.host est le seul endroit où le domaine d'un déploiement est défini. Toutes les URL publiques transmises à l'API, au client web et à Authentik en découlent.

Valeur	Valeur par défaut	Description
`ingress.enabled`	`true`	Créer les objets Ingress. Positionnez-la à `false` pour router vous-même vers les services.
`ingress.host`	Obligatoire	Le domaine sur lequel la plateforme est servie.
`ingress.authentikHost`	`ingress.host`	Donner à Authentik son propre domaine.
`ingress.className`	`nginx`	IngressClass. Le routage nécessite ingress-nginx ; avec un autre contrôleur, mettez `ingress.enabled: false`.
`ingress.tls.enabled`	`true`	Servir en TLS, et dériver toutes les URL publiques en `https`.
`ingress.tls.secretName`	Aucune	Nom d'un Secret `kubernetes.io/tls` existant. Laissée vide, le contrôleur sert son propre certificat.
`ingress.annotations`	`{}`	Annotations supplémentaires sur chaque Ingress créé par le chart.
`ingress.proxyBodySize`	`1024m`	Limite de téléversement. Augmentez-la pour des jeux de données plus volumineux.
`ingress.proxyBufferSize`	`16k`	Taille des buffers de réponse.
`ingress.proxyBuffersNumber`	`4`	Nombre de buffers de proxy.
`ingress.wwwRedirect`	`false`	Rediriger le domaine apex vers son équivalent `www.`.
`ingress.api.path`	`/api`	Chemin sur lequel l'API est servie. Chaque route accepte aussi ses propres `annotations`.
`ingress.web.path`	`/web`	Chemin sur lequel le client web est servi.
`ingress.sso.path`	`/sso`	Chemin sur lequel Authentik est servi. Doit correspondre à `authentik.authentik.web.path`.
`ingress.storage.path`	`/storage`	Chemin sur lequel le stockage objet est servi.
`ingress.storage.service.name`	Aucune	Faire pointer la route de stockage vers votre propre Service, à la place du SeaweedFS intégré.
`ingress.storage.service.port`	`8333`	Port de ce service.

Mettre en place l'ingress

Avec ingress-nginx, pour lequel le chart génère les objets :

Faites pointer le DNS de votre domaine vers le load balancer du contrôleur d'ingress.
Créez un Secret kubernetes.io/tls pour ce domaine dans le namespace de la release. Le chart n'en crée jamais.
Renseignez ingress.host et ingress.tls.secretName, et laissez ingress.enabled: true et ingress.className: nginx.

Le chart crée alors les quatre routes ci-dessus, et toutes les URL publiques en découlent.

Utiliser un autre contrôleur d'ingress

Positionnez ingress.enabled: false et gardez ingress.host renseignée — le chart continue d'en dériver toutes les URL. Créez ensuite vos propres routes pour les quatre chemins ci-dessus, avec :

le préfixe supprimé sur /api et /storage, conservé sur /web et /sso
x-forwarded-prefix: /storage sur la route de stockage
une limite de taille de requête suffisante pour vos téléversements de jeux de données
X-Forwarded-For remplacé, et non complété, et le réseau des pods de votre contrôleur dans sso.trustedProxyCidrs

ingress.className ne s'applique qu'aux objets créés par le chart, et ceux-ci portent des annotations ingress-nginx : la pointer vers un autre contrôleur ne les rend pas fonctionnels.

Si vous activez aussi networkPolicy.enabled, renseignez networkPolicy.ingressController avec les labels des pods de votre contrôleur.

API

Valeur	Valeur par défaut	Description
`api.image.registry`	`quay.io`	Registre de l'image de l'API.
`api.image.repository`	`octopize/avatar-service-api`	Dépôt de l'image de l'API.
`api.image.tag`	`3.4.0`	Version de l'API. Renseignez celle fournie par Octopize ; évitez `latest`.
`api.image.digest`	Aucune	Récupérer par digest plutôt que par tag.
`api.image.pullPolicy`	`IfNotPresent`	Politique de pull de l'image.
`api.replicaCount`	`1`	Réplicas de l'API. À laisser à `1` — voir Mise à jour.
`api.resources`	`4Gi` / `1000m`, requêtes = limites	Ressources du conteneur de l'API.
`api.containerPort`	`8000`	Port sur lequel l'API écoute.
`api.service.type`	`ClusterIP`	Type du Service de l'API.
`api.service.port`	`8000`	Port exposé par le Service de l'API.
`api.service.annotations`	`{}`	Annotations sur le Service de l'API.
`api.livenessProbe.failureThreshold`	`3`	Échecs avant redémarrage du conteneur. `periodSeconds` et `timeoutSeconds` l'accompagnent.
`api.readinessProbe.failureThreshold`	`3`	Échecs avant que le pod ne quitte le Service. Mêmes compagnons.

api accepte également les points d'extension d'ordonnancement, de sécurité et d'injection.

Paramètres applicatifs

Toutes les URL ci-dessous sont dérivées du bloc ingress lorsqu'elles sont laissées vides. N'en renseignez une que pour la figer.

Valeur	Valeur par défaut	Description
`api.auth.jwtSecretKey`	Obligatoire	Clé de signature des JWT. À générer de la même façon.
`api.config.organizationName`	Obligatoire	Nom de votre organisation. Équivalent de `ORGANIZATION_NAME`.
`api.config.baseUrl`	dérivée	URL publique de l'API. Équivalent de `AVATAR_API_URL`.
`api.config.webClientUrl`	dérivée	URL publique du client web, utilisée dans les emails. Équivalent de `AVATAR_WEB_CLIENT_URL`.
`api.config.logLevel`	`INFO`	Équivalent de `LOG_LEVEL`.
`api.config.useConsoleLogging`	`false`	Journaux lisibles au lieu du JSON structuré. Équivalent de `USE_CONSOLE_LOGGING`.
`api.config.sentry.enabled`	`false`	Remonter les erreurs à Sentry. Renseignez `dsn` avec votre propre projet avant de l'activer.
`api.config.sentry.dsn`	Aucune	Projet Sentry vers lequel les erreurs sont envoyées.
`api.config.compatibilityMappingUrl`	`https://license.octopize.io/compatibility/compatibility_mapping.json`	URL depuis laquelle l'API télécharge la table de compatibilité des clients. Laissée vide, cette URL est utilisée. Mettez `"disabled"` derrière un pare-feu qui bloque les connexions sortantes : l'API utilise alors la copie embarquée dans son image.

TLS et autorités de certification privées

Valeur	Valeur par défaut	Description
`api.caBundle`	Aucune	Certificat(s) d'autorité au format PEM à ajouter à ceux que l'image embarque déjà.

Un certificat issu d'une autorité privée nécessite api.caBundle

Si le certificat de votre domaine a été émis par une autorité interne ou est auto-signé, toutes les connexions échouent avec CERTIFICATE_VERIFY_FAILED tant que vous ne l'avez pas renseignée :

api:
  caBundle: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----

Elle atteint les pods de l'API et le CronJob de synchronisation, mais pas les workers Dask — voir Calcul.

Client web

Valeur	Valeur par défaut	Description
`web.image.registry`	`quay.io`	Registre de l'image web.
`web.image.repository`	`octopize/avatar-web`	Dépôt de l'image web.
`web.image.tag`	`0.68.0`	Version du client web. Octopize la fournit avec celle de l'API.
`web.image.digest`	Aucune	Récupérer par digest plutôt que par tag.
`web.image.pullPolicy`	`IfNotPresent`	Politique de pull de l'image.
`web.replicaCount`	`1`	Réplicas du client web.
`web.resources`	`2Gi` / `500m`, requêtes = limites	Ressources du conteneur web.
`web.containerPort`	`3000`	Port sur lequel le client web écoute.
`web.service.type`	`ClusterIP`	Type du Service web.
`web.service.port`	`3000`	Port exposé par le Service web.
`web.service.annotations`	`{}`	Annotations sur le Service web.
`web.livenessProbe.failureThreshold`	`3`	Échecs avant redémarrage du conteneur.
`web.readinessProbe.failureThreshold`	`3`	Échecs avant que le pod ne quitte le Service.

web accepte les mêmes points d'extension que api.

Les URL sous web.config — publicUrl, apiPublicUrl, storagePublicUrl, authentikUrl, ssoUrl — sont dérivées du bloc ingress lorsqu'elles sont laissées vides. N'en renseignez une que pour la figer. web.config.apiInternalUrl et web.config.storageInternalUrl sont internes au cluster et n'ont que rarement besoin d'être modifiées.

info

Le nom d'environnement affiché dans l'interface provient de envName.

Adapter le chart à votre cluster

Chaque charge de travail accepte le même ensemble de valeurs optionnelles, toutes vides par défaut :

Clé (par charge de travail)	À renseigner pour
`nodeSelector`, `tolerations`, `affinity`, `topologySpreadConstraints`	Un pool de nœuds étiqueté ou marqué (taint), une répartition sur les zones
`priorityClassName`	Maîtriser ce qui est évincé en premier lorsqu'un nœud se remplit
`podSecurityContext`, `containerSecurityContext`	Un Pod Security Standard, ou un moteur de politiques qui en applique un
`extraEnvVars`	Surcharger une valeur définie par le chart
`extraVolumes`, `extraVolumeMounts`	Une configuration injectée, un chemin inscriptible, un certificat monté
`initContainers`, `sidecars`	Un agent de secrets, un sidecar de journalisation ou de service mesh
`podAnnotations`, `podLabels`	Ce sur quoi s'appuient un injecteur de sidecar, un collecteur ou une politique
`updateStrategy`	La façon dont un rollout remplace les pods
`extraPodSpec`	N'importe quel champ de pod spec que le chart n'expose pas

api et web les acceptent tous. syncTables les accepte tous sauf updateStrategy. authentikDatabase accepte les clés d'ordonnancement, priorityClassName, extraPodSpec et les deux contextes de sécurité.

app.kubernetes.io/component ne peut pas être défini dans podLabels.

Les sous-charts disposent de leurs propres clés pour les mêmes champs : authentik.server.securityContext et authentik.server.containerSecurityContext, seaweedfs.<composant>.podSecurityContext, dask.worker.nodeSelector. Leurs variables d'environnement ont elles aussi leurs propres clés — voir Sur les sous-charts.

Pod Security Standard `restricted`

example-values-restricted.yaml, livré dans le chart, est une surcouche prête à l'emploi. Appliquez-la par-dessus votre propre fichier de valeurs :

helm install avatar oci://quay.io/octopize/helm/services-api/avatar \
  --version <version> --namespace avatar --create-namespace \
  --values my-values.yaml \
  --values example-values-restricted.yaml

Deux points à conserver si vous écrivez la vôtre :

Renseignez runAsUser avec runAsNonRoot: true, sinon le conteneur ne démarre pas. Il diffère selon l'image : 1000 pour l'API, la synchronisation des tables et Dask, et 1001 avec le groupe 65533 pour le client web. Donner 1000 au client web échoue silencieusement : il sert, mais toutes ses écritures de cache échouent.
Laissez readOnlyRootFilesystem non renseignée, sauf à ajouter aussi un montage inscriptible — ce à quoi servent extraVolumes et extraVolumeMounts.

Le sous-chart Dask ne peut pas fonctionner sous ce profil

Ses pods sont rejetés par un namespace restricted quelle que soit la configuration : Dask doit donc s'exécuter là où il est admis. Tout le reste est couvert par la surcouche.

Stockage objet

Où vivent les jeux de données et les résultats, et avec quels identifiants l'API les atteint.

Valeur	Valeur par défaut	Description
`storage.sharedPath`	SeaweedFS du chart	Emplacement des jeux de données et des fichiers générés. Équivalent de `SHARED_STORAGE_PATH`.
`storage.endpoint.host`	SeaweedFS du chart	Hôte interne au cluster de la passerelle S3.
`storage.endpoint.port`	`8333`	Port de ce point d'accès.
`storage.admin.accessKeyId`	Obligatoire	Identité avec laquelle l'API s'authentifie auprès du stockage. À traiter comme un identifiant root.
`storage.admin.secretAccessKey`	Obligatoire	Son secret.
`storage.sseKek`	Obligatoire	Clé de chiffrement de clés pour le chiffrement au repos. Obligatoire si `seaweedfs.enabled`.
`storage.seaweedfsAdminPassword`	Obligatoire	Mot de passe d'administration SeaweedFS. Obligatoire si `seaweedfs.enabled`, sauf si `seaweedfs.admin.secret.existingSecret` désigne votre propre Secret. Voir SeaweedFS.

Générez storage.sseKek une seule fois et ne la changez jamais

Une nouvelle clé rend tous les objets stockés indéchiffrables. Lors de la migration d'un SeaweedFS existant, récupérez la valeur depuis l'ancien filer — voir Chiffrement SeaweedFS.

SeaweedFS intégré au chart

Valeur	Valeur par défaut	Description
`seaweedfs.enabled`	`false`	Déployer le stockage objet interne au cluster. `example-values.yaml` la positionne à `true`.
`seaweedfs.volume.dataDirs`	un PVC de 20Gi	Le budget disque de la plateforme. Augmentez-le selon les données à héberger.
`seaweedfs.filer.data`	un PVC de 10Gi	Métadonnées du filer. C'est le volume à sauvegarder.
`seaweedfs.filer.extraArgs`	voir `example-values.yaml`	La surcharger remplace la liste du chart : répétez l'argument `-ip` qu'elle contient.
`seaweedfs.s3.extraArgs`	voir `example-values.yaml`	Idem. Ajoutez `-allowedOrigins` pour restreindre le CORS navigateur au client web.
`seaweedfs.networkPolicy.enabled`	`false`	Doit être égale à `networkPolicy.enabled`.

SeaweedFS autorise toutes les origines navigateur tant que -allowedOrigins n'est pas défini

Ni le filer ni la passerelle S3 ne reçoivent cet argument par défaut, et SeaweedFS sert alors le stockage objet à n'importe quelle origine. Ajoutez-le aux deux, en listant l'URL du client web :

seaweedfs:
  filer:
    extraArgs:
      - "-ip=${POD_NAME}.seaweedfs-filer.${NAMESPACE}.svc.cluster.local"
      - "-allowedOrigins=https://avatar.mycompany.com"
  s3:
    extraArgs:
      - "-iam.readOnly=false"
      - "-allowedOrigins=https://avatar.mycompany.com"

Helm ne peut pas templater les extraArgs d'un sous-chart : la valeur ne peut pas être dérivée de api.config.webClientUrl et doit être écrite en clair.

SSO

Valeur	Valeur par défaut	Description
`sso.clientId`	Obligatoire	Identifiant client OAuth. Le blueprint le relit dans la ConfigMap `avatar-api-config`.
`sso.clientSecret`	Obligatoire	Secret client OAuth. Le blueprint le relit dans le Secret `api`.
`sso.providerAppName`	`avatar-api`	N'y touchez pas. Toute autre valeur casse la connexion.
`sso.providerUrl`	dérivée	Émetteur OIDC.
`sso.apiToken`	Obligatoire	Jeton de l'API de gestion Authentik. Le blueprint le relit dans le Secret `api`.
`sso.webhookSecret`	Obligatoire	Secret partagé du webhook. Le blueprint le relit dans le Secret `api`.
`sso.trustedProxyCidrs`	toutes les plages privées	Réseaux dont Authentik accepte `X-Forwarded-Proto` et `X-Forwarded-For`. Voir Le proxy devant Authentik.

astuce

C'est vous qui choisissez les quatre. Authentik n'en émet aucune. Fabriquez-les comme décrit dans Générer les secrets. Vous les renseignez une seule fois. Le blueprint les relit dans les objets dans lesquels le chart les écrit.

sso.apiToken et sso.webhookSecret sont ce qui révoque les clés d'API d'un utilisateur que vous désactivez ou supprimez dans Authentik : le secret du webhook authentifie Authentik lorsqu'il signale l'événement à l'API, et le jeton permet à l'API de vérifier le statut de cet utilisateur avant toute révocation. Les clés d'API sont validées contre la base de données d'Avatar et non contre Authentik : sans elles, un utilisateur qui a perdu son authentification unique conserve des clés d'API fonctionnelles. Le chart refuse de se rendre lorsque l'une des deux manque, plutôt que d'installer un déploiement où cette application est silencieusement absente.

Le proxy devant Authentik

Authentik lit le schéma et l'adresse du client d'une requête dans X-Forwarded-Proto et X-Forwarded-For, mais uniquement lorsque la connexion vient d'une adresse de sso.trustedProxyCidrs. Cette adresse est celle du pod de votre contrôleur d'ingress. À partir d'Authentik 2026.8, Authentik ignore ces deux en-têtes lorsqu'ils viennent d'une autre adresse.

La valeur par défaut contient toutes les plages privées. Elle couvre le réseau des pods des réseaux Kubernetes courants, y compris 100.64.0.0/10 sur Scaleway Kapsule :

sso:
  trustedProxyCidrs:
    - 10.0.0.0/8
    - 172.16.0.0/12
    - 192.168.0.0/16
    - 100.64.0.0/10
    - 127.0.0.0/8
    - fc00::/7
    - fe80::/10
    - ::1/128

Si le réseau de vos pods est public, ajoutez-le. Une liste que vous renseignez remplace la valeur par défaut : gardez les plages dont vous avez encore besoin. Une liste vide ne fait confiance à aucune adresse : elle ne revient pas à la valeur par défaut d'Authentik.

Authentik ne lit cette valeur qu'au démarrage, et helm upgrade ne le redémarre pas. Après chaque modification, lancez kubectl -n avatar rollout restart deploy/avatar-authentik-server.

Remplacer `X-Forwarded-For` au contrôleur d'ingress

Authentik prend la première adresse de X-Forwarded-For comme adresse du client. Il enregistre cette adresse et la transmet à ses politiques. Votre contrôleur d'ingress doit remplacer cet en-tête par l'adresse d'où il reçoit la connexion. S'il complète un en-tête envoyé par le client, le client choisit l'adresse qu'Authentik enregistre. Sur ingress-nginx, faites l'une de ces actions :

Laissez use-forwarded-headers désactivé. C'est la valeur par défaut d'ingress-nginx.
Si vous avez besoin de use-forwarded-headers, limitez proxy-real-ip-cidr à l'adresse de votre load balancer.
Utilisez le protocole PROXY entre le load balancer et le contrôleur d'ingress.

Tout pod d'un réseau de confiance qui joint le serveur Authentik peut aussi choisir cette adresse. N'exposez pas le serveur Authentik hors du cluster par un Service qui lui est propre. networkPolicy.enabled limite les pods qui le joignent. Pour ne faire confiance qu'au contrôleur d'ingress, listez les adresses de ses pods dans sso.trustedProxyCidrs.

Lorsque le contrôleur d'ingress est hors de sso.trustedProxyCidrs, Authentik prend chaque requête pour du HTTP simple. Il construit des URL http:// et pose son cookie de session sans l'attribut Secure. La connexion revient alors à son premier écran après chaque saisie de l'adresse e-mail. Un navigateur Chromium n'affiche qu'une icône d'erreur, car la page appelle son API en http://. Pour corriger :

Trouvez l'adresse du pod du contrôleur d'ingress :
```
kubectl get pods -A -o wide
```
Ajoutez son réseau à sso.trustedProxyCidrs, en gardant les plages dont vous avez encore besoin.

Lancez helm upgrade, puis redémarrez le serveur Authentik :

kubectl -n avatar rollout restart deploy/avatar-authentik-server

Connectez-vous de nouveau, puis lisez le journal du serveur Authentik :
```
kubectl -n avatar logs deploy/avatar-authentik-server --tail=100
```
Une requête de connexion affiche "scheme": "https", et son "remote" est l'adresse du client, et non celle du pod du contrôleur d'ingress.

SMTP

Laissées vides, tout envoi de message échoue.

Valeur	Valeur par défaut	Équivalent Docker
`smtp.host`	Aucune	`SMTP_HOST`
`smtp.port`	`587`	`SMTP_PORT`
`smtp.useTls`	`true`	`SMTP_USE_TLS`
`smtp.startTls`	`false`	`SMTP_START_TLS`
`smtp.verify`	`true`	`SMTP_VERIFY`
`smtp.senderEmail`	Aucune	`SMTP_SENDER_EMAIL`
`smtp.username`	Aucune	`SMTP_USERNAME`
`smtp.password`	Aucune	`SMTP_PASSWORD`

Authentik envoie ses propres emails et se configure séparément sous authentik.authentik.email. Renseignez les deux.

Télémétrie

La télémétrie permet à Octopize de vous assister plus rapidement, de suivre les versions que vous exécutez et de suivre l'usage des licences. Seules des données système, des métadonnées de traitement et des données utilisateur (email et organisation) sont transmises — aucune donnée sensible, aucun jeu de données. Octopize fournit le nom du bucket et les identifiants. Voir Données envoyées à Octopize pour savoir pourquoi nous la recommandons et ce qui est envoyé.

Valeur	Équivalent Docker
`telemetry.s3.endpointUrl`	`TELEMETRY_S3_ENDPOINT_URL`
`telemetry.s3.region`	`TELEMETRY_S3_REGION`
`telemetry.s3.bucketName`	`TELEMETRY_S3_BUCKET_NAME`
`telemetry.s3.accessKeyId`	`telemetry_s3_access_key_id`
`telemetry.s3.secretAccessKey`	`telemetry_s3_secret_access_key`

L'export est assuré par le CronJob de synchronisation des tables : il faut donc aussi syncTables.enabled.

Tâches planifiées

Valeur	Valeur par défaut	Description
`syncTables.enabled`	`false`	Activer le CronJob de synchronisation des tables.
`syncTables.schedule`	`0 1 * * *`	Expression cron de la planification.
`syncTables.failureEmail`	Aucune	Adresse à notifier en cas d'échec. Nécessaire pour que le CronJob soit créé.

C'est ce CronJob qui exporte la télémétrie : activez-le si vous envoyez de la télémétrie. Il exécute l'image de l'API — api.caBundle l'atteint donc aussi — et accepte l'ensemble des points d'extension sous syncTables.*.

Authentik

Avatar embarque Authentik comme fournisseur d'identité. Il se configure lui-même au premier démarrage ; la seule étape manuelle est le premier compte administrateur.

Valeur	Valeur par défaut	Description
`authentik.enabled`	`true`	Détermine si Authentik est déployé.
`authentik.global.image.tag`	figé par le chart	Tag de l'image Authentik.
`authentik.global.env`	voir ci-dessous	Variables du blueprint.
`authentik.authentik.secret_key`	Obligatoire	Clé de signature des sessions Authentik.
`authentik.authentik.log_level`	`info`	Niveau de journalisation d'Authentik.
`authentik.authentik.web.path`	`/sso/`	Doit correspondre à `ingress.sso.path` suivi d'un slash.
`authentik.authentik.postgresql.host`	Obligatoire	Serveur PostgreSQL hébergeant la base propre à Authentik.
`authentik.authentik.postgresql.port`	`5432`	Son port.
`authentik.authentik.postgresql.name`	`authentik`	Nom de la base.
`authentik.authentik.postgresql.user`	`authentik`	Nom du rôle.
`authentik.authentik.postgresql.password`	Obligatoire	Mot de passe de ce rôle.
`authentik.authentik.email.*`	voir `example-values.yaml`	Paramètres SMTP par lesquels Authentik envoie ses propres emails.

Le chart dérive le domaine et les URI de redirection de ingress.host : il ne reste que ces entrées sous authentik.global.env à renseigner. Elles sont décrites en détail dans Variables de blueprint. Helm remplace une liste au lieu d'y fusionner : un fichier de valeurs qui renseigne authentik.global.env doit donc redonner chaque entrée dont il a besoin.

Variable d'environnement	Description
`AVATAR_AUTHENTIK_BLUEPRINT_CLIENT_ID`	Référence `sso.clientId`. Laissez-la telle quelle.
`AVATAR_AUTHENTIK_BLUEPRINT_CLIENT_SECRET`	Référence `sso.clientSecret`. Laissez-la telle quelle.
`AVATAR_AUTHENTIK_BLUEPRINT_SELF_SERVICE_LICENSE`	Type de licence attribué aux utilisateurs créés par inscription libre.
`AVATAR_AUTHENTIK_BLUEPRINT_API_TOKEN`	Référence `sso.apiToken`. Laissez-la telle quelle.
`AVATAR_AUTHENTIK_BLUEPRINT_WEBHOOK_SECRET`	Référence `sso.webhookSecret`. Laissez-la telle quelle.
`_GOOGLE_CLIENT_ID` / `_GOOGLE_CLIENT_SECRET`	Optionnelles. Renseignez les deux pour ajouter une source OAuth Google.

Chacune d'elles peut porter un valueFrom.secretKeyRef à la place de value. Voir Authentik. Utilisez la même liste pour surcharger tout autre réglage Authentik, y compris une clé que le chart construit lui-même. Voir Sur les sous-charts.

AVATAR_AUTHENTIK_BLUEPRINT_API_WEBHOOK_URL ne figure pas dans cette liste. Le chart la dérive de api.service.port et la transmet aux pods Authentik par la ConfigMap avatar-authentik-config désignée dans authentik.global.envFrom : elle survit donc au remplacement de liste ci-dessus et ne demande aucune entrée. Une entrée de ce nom l'emporte toujours si vous en ajoutez une — Kubernetes donne la priorité à env sur envFrom — mais une entrée redonnée avec une valeur vide désactiverait le webhook d'événements utilisateur, et le chart refuse de se rendre plutôt que de laisser cela passer inaperçu.

Amorçage de la base de données Authentik

Un Job crée le rôle, la base et les extensions d'Authentik à la première installation.

Valeur	Valeur par défaut	Description
`authentikDatabase.createDatabase`	`true`	Positionnez-la à `false` si un DBA les a déjà créés.
`authentikDatabase.image`	`postgres:17-alpine`	N'importe quelle image avec un client `psql` au moins aussi récent que le serveur.
`authentikDatabase.imagePullPolicy`	`IfNotPresent`	Politique de pull de l'image du Job.
`authentikDatabase.backoffLimit`	`5`	Nombre de tentatives avant abandon.
`authentikDatabase.ttlSecondsAfterFinished`	`3600`	Durée pendant laquelle le Job terminé reste consultable via `kubectl logs`.

Il accepte également nodeSelector, tolerations, priorityClassName et les deux contextes de sécurité — voir Adapter le chart à votre cluster.

Calcul

L'ordonnanceur et les workers Dask exécutent les traitements d'avatarisation.

Valeur	Valeur par défaut	Description
`dask.enabled`	`true`	Détermine si l'ordonnanceur et les workers Dask sont déployés.
`dask.scheduler.image.repository`	`quay.io/octopize/avatar-service-api`	Image de l'ordonnanceur. À surcharger pour un miroir.
`dask.scheduler.image.tag`	`3.4.0`	Doit être égale à `api.image.tag`.
`dask.worker.image.repository`	`quay.io/octopize/avatar-service-api`	Image des workers.
`dask.worker.image.tag`	`3.4.0`	Doit être égale à `api.image.tag`.
`dask.worker.replicas`	`2`	Nombre de workers. Le principal levier sur le débit.
`dask.worker.resources`	requêtes `2Gi` / `1` CPU, limites `32Gi` / `1` CPU	Augmentez la limite mémoire pour les gros jeux de données.
`dask.jupyter.enabled`	`false`	À laisser désactivé.

info

Les pods Dask récupèrent leurs images avec docker-local-pull-secret. Si vous apportez votre propre secret de pull via global.imagePullSecrets, modifiez dask.{scheduler,worker}.image.pullSecrets en conséquence.

api.caBundle n'atteint pas les workers Dask

Si un worker établit une connexion TLS s'appuyant sur votre autorité privée, pointez les workers dessus à l'aide du bloc commenté sous dask.worker dans values.yaml. Le bundle y remplace le magasin de confiance : il doit donc embarquer les racines publiques dont le worker a besoin.

Dask est également le seul composant qui ne peut pas fonctionner sous un Pod Security Standard restricted.

Isolation réseau

Valeur	Valeur par défaut	Description
`networkPolicy.enabled`	`false`	Créer les objets `NetworkPolicy`. Nécessite un CNI qui les applique.
`networkPolicy.ingressController.podSelector`	`{}`	Labels des pods de votre contrôleur d'ingress, pour l'autoriser à joindre la plateforme.
`networkPolicy.ingressController.namespaceSelector`	`{}`	Nécessaire uniquement si le contrôleur d'ingress est dans un autre namespace que la release.

seaweedfs.networkPolicy.enabled doit être positionnée à la même valeur ; sinon le chart refuse de se rendre.

Valeurs générales et communes​

Générer les secrets​

Utiliser des Secrets existants​

Les blocs que le chart gère​

Identifiants de pull d'images​

Authentik​

SeaweedFS​

Surcharger une valeur définie par le chart​

Sur les charges de travail que le chart gère​

Sur les sous-charts​

Base de données​

Ce que le chart crée​

Quel rôle fait quoi​

Ce dont chaque rôle a besoin​

Changer un mot de passe de base de données​

Créer les bases à la main​

Ingress et contrat d'URL​

Mettre en place l'ingress​

Utiliser un autre contrôleur d'ingress​

API​

Paramètres applicatifs​

TLS et autorités de certification privées​

Client web​

Adapter le chart à votre cluster​

Pod Security Standard restricted​

Stockage objet​

SeaweedFS intégré au chart​

SSO​

Le proxy devant Authentik​

Remplacer X-Forwarded-For au contrôleur d'ingress​

La connexion revient à son premier écran​

SMTP​

Télémétrie​

Tâches planifiées​

Authentik​

Amorçage de la base de données Authentik​

Calcul​

Isolation réseau​

Valeurs générales et communes

Générer les secrets

Utiliser des Secrets existants

Les blocs que le chart gère

Identifiants de pull d'images

Authentik

SeaweedFS

Surcharger une valeur définie par le chart

Sur les charges de travail que le chart gère

Sur les sous-charts

Base de données

Ce que le chart crée

Quel rôle fait quoi

Ce dont chaque rôle a besoin

Changer un mot de passe de base de données

Créer les bases à la main

Ingress et contrat d'URL

Mettre en place l'ingress

Utiliser un autre contrôleur d'ingress

API

Paramètres applicatifs

TLS et autorités de certification privées

Client web

Adapter le chart à votre cluster

Pod Security Standard `restricted`

Stockage objet

SeaweedFS intégré au chart

SSO

Le proxy devant Authentik

Remplacer `X-Forwarded-For` au contrôleur d'ingress

La connexion revient à son premier écran

SMTP

Télémétrie

Tâches planifiées

Authentik

Amorçage de la base de données Authentik

Calcul

Isolation réseau