Stratégie de déploiement

Le dépôt contient un seul chart Helm (helm/) et un seul jeu d'images Docker. Chaque bot est une release Helm distincte, configurée par son propre fichier de valeurs.

Un bot = une release

Le nom de release est ai-<botFullId>, dans le namespace global.namespace du fichier de valeurs.
global.botFullId identifie le bot dans les noms de ressources, les tags d'images et le nom de release.
Les noms de ressources Kubernetes utilisent global.botId. Les ConfigMap et Secret du bot s'appellent <botId>-configmap et <botId>-secrets.

Les valeurs propres à chaque bot sont stockées dans des variables de fichier GitLab, une par bot. Le fichier de valeurs n'est jamais commité : il contient aussi les secrets (secrets.*).

Images

Le Dockerfile à la racine a un target par service :

Image	Target	Déployée si
`naivi_rag_agent`	`rag-agent`	toujours
`naivi_website_server`	`server`	toujours
`naivi_website_web`	`web`	toujours
`naivi_index`	`index`	toujours
`naivi_document_processor`	`document-processor`	toujours
`naivi_docs`	`docs`	`global.components.docs: true`

Les images sont poussées dans gitlab.amplitudes.com:4567/ia/naivi-bots avec le tag <branche>-<sha court>-<botFullId> : chaque job de déploiement installe les images de son propre commit. Le chart reçoit ce tag par --set images.tag=....

Branches et pipeline

Le pipeline de build et de déploiement est .amplitudes-gitlab-ci.yml. Les tests, eux, sont dans .gitlab-ci.yml.

Branche	Variable listant les fichiers de valeurs	Cluster
`pre-prod`	`VALUES_FILES_PREPROD`	pré-production
`prod`	`VALUES_FILES_PROD`	production
`test`	`VALUES_FILES_TEST`	pré-production (même accès Kubernetes que `pre-prod`)

Chaque variable contient la liste, séparée par des virgules, des noms de variables de fichier GitLab. Le pipeline fonctionne en deux étapes :

package : pour chaque fichier de valeurs, lit botFullId, shadcnPreset, botName et components.docs, puis construit et pousse les images. L'image docs n'est construite que si components.docs vaut true. Elle reçoit le nom du bot en build-arg DOCS_BOT_NAME.
deploy : pour chaque fichier, lance helm upgrade --install ai-<botFullId> ./helm avec --wait --rollback-on-failure --timeout 600s, --set images.tag=<branche>-<sha court>-<botFullId> et --set certificate.create=false. Sur prod, le pipeline passe aussi --set ingress.enabled=false.

Un échec pendant le déploiement annule la révision (--rollback-on-failure). Un retour arrière manuel reste possible avec helm history ai-<botFullId> -n <namespace> puis helm rollback.

Activer les composants

global.components contrôle les ressources générées par le chart : web, server, ragAgent, database, index, documentProcessor et docs. La valeur docs est false par défaut.

Site de documentation

Le site Documentation n'est déployé que si le fichier de valeurs du bot contient :

global:
  components:
    docs: true

Dans ce cas, la CI construit l'image naivi_docs avec le nom du bot, et le chart crée le déploiement, le service et l'entrée d'Ingress docs. En prod, l'Ingress est désactivé : la documentation n'est donc joignable qu'en pré-production.

Ajouter un bot

Créer le fichier de valeurs, à partir d'un fichier existant : global.namespace, global.botFullId, global.botId, global.botName, ingress.hosts, configMap.*, secrets.*, i18n et global.components.
Si les traductions changent, éditer i18n.json.example puis lancer python scripts/convert_i18n_to_helm_values.py (voir Traductions).
Créer une variable de fichier GitLab avec ce fichier, et ajouter son nom à la variable VALUES_FILES_* de chaque branche concernée.
Lancer le pipeline sur pre-prod d'abord.

Sécurité

Les secrets sont dans le fichier de valeurs (secrets.*), donc dans la variable GitLab du bot. Ne jamais les mettre dans le dépôt ni dans une image.
Les déploiements déclarent runAsNonRoot (UID 1000) au niveau du pod, et allowPrivilegeEscalation: false avec capabilities.drop: ALL au niveau des conteneurs.
Les variables du Secret sont listées dans Variables d'environnement.

Stratégie de déploiement

On this page