Stratégie de déploiement

La plateforme est pensée pour Kubernetes via Helm.

# Déployer Kalli
helm install kalli-release ./helm --set bot.id=kalli

# Déployer un second bot
helm install newbot-release ./helm --set bot.id=newbot

Pourquoi Helm ?

• Standard Kubernetes: Helm structure les déploiements (charts, valeurs, templates) et évite la duplication YAML.
• Paramétrage par valeurs: Permet de dériver plusieurs instances (bots) d’une même base avec des overrides légers.
• Opérations fiables: helm upgrade --install, rollback natif, historique des révisions.

Modèle multi-bots (multi-tenant léger)

• Objectif: Lancer plusieurs bots partageant la même structure logique (web, serveur, base, index), mais avec identités/config propres.
• Isolation logique: Préfixes/labels/annotations par bot.id, ConfigMaps/Secrets dédiés, éventuellement namespaces distincts.
• Mutualisation: Un même chart + valeurs spécifiques par bot (réduction du coût d’exploitation et homogénéité).

Comment déployer

# 1) Préparer les valeurs (valeurs par défaut dans ./helm/values.yaml)
# 2) Déployer un bot "kalli" avec override minimal
helm upgrade --install kalli-release ./helm \
  --namespace bots --create-namespace \
  --set bot.id=kalli --set image.tag=latest

# 3) Déployer un 2e bot avec un autre ID et sa config
helm upgrade --install foobot-release ./helm \
  --namespace bots \
  --set bot.id=foobot --values ./overrides/foobot.values.yaml

# 4) Mettre à jour
helm upgrade kalli-release ./helm --namespace bots --values ./overrides/kalli.values.yaml

# 5) Rollback si nécessaire
helm rollback kalli-release 1 --namespace bots

Structure des valeurs Helm (exemple)

bot:
  id: kalli
  displayName: "Kalli"
  domain: kalli.example.com

image:
  repository: registry.example.com/naivi-bot
  tag: "2025.08.11"

resources:
  requests:
    cpu: "100m"
    memory: "256Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"

env:
  - name: NODE_ENV
    value: production
  - name: BOT_ID
    value: kalli

secrets:
  - name: AUTH_SECRET
    valueFrom: secretRef: auth-secret

ingress:
  enabled: true
  host: kalli.example.com

Adaptez env et secrets à votre politique (ConfigMaps vs Secrets, External Secrets…).

Environnements (dev, stage, prod)

• Séparez les namespaces et/ou clusters par environnement.
• Overrides dédiés: values.dev.yaml, values.stage.yaml, values.prod.yaml.
• Politiques de ressources et d’autoscaling adaptées à la charge.

Sécurité & isolation

• Secrets K8s ou gestion externe (External Secrets, Vault).
• RBAC/NetworkPolicy: limiter l’accès inter-services et inter-bots.
• Noms/labels par bot: éviter collisions et faciliter l’observabilité.

Bonnes pratiques opérationnelles

• CI/CD: valider les manifests (helm lint, kubeconform) avant déploiement.
• Probing: readiness/liveness probes cohérentes pour un rollout fiable.
• Observabilité: logs, métriques, traces corrélées par bot.id.