Skip to main content

​
Prérequis

  • Docker Engine 24 ou une version ultérieure avec Compose v2
  • Node.js 22 ou une version ultérieure, pour générer les secrets
  • au moins 2 vCPU, 4 Go de RAM et un stockage disque durable
  • un nom DNS public pour le tableau de bord
  • des comptes Twilio et OpenAI pour les appels en direct, et un trunk Twilio Elastic SIP pour les appels téléphoniques

​
Configurer l’environnement

Le script copie .env.example vers .env et remplit chaque mot de passe de rôle PostgreSQL et chaque secret interne avec une valeur aléatoire de 64 caractères. Il n’écrase pas un .env existant, sauf si vous passez --force, qui remplace aussi tous les secrets qu’il contient. Ouvrez ensuite .env et définissez APP_BASE_URL, OPENAI_API_KEY et vos identifiants Twilio. Les services construisent leurs chaînes de connexion à la base de données à partir des mots de passe des rôles. Vous n’avez donc à écrire aucune URL de base de données. Compose définit STORAGE_PROVIDER=local par défaut. L’admin et le worker montent le même volume persistant storage_data dans /var/lib/lobbystack/storage.
N’exposez pas une pile qui utilise encore les mots de passe d’exemple ou les secrets change-me.

​
Démarrer LobbyStack

Le migrator applique les migrations PostgreSQL avant le démarrage des services admin et worker. Les vérifications d’état retiennent les services dépendants jusqu’à ce que leurs prérequis soient prêts. La réponse de disponibilité de l’admin inclut des vérifications de la base de données et du stockage. La réponse de disponibilité du worker inclut l’état de PostgreSQL, de Redis et du stockage. LobbyStack n’exécute pas de conteneurs de surveillance. Les journaux de l’application restent accessibles avec docker compose logs, et les points de terminaison de santé continuent de fonctionner.

​
Choisir un backend de stockage

Le fournisseur local par défaut prend en charge un seul hôte Docker. Sauvegardez le volume storage_data en même temps que PostgreSQL et restaurez les deux à partir du même point de restauration. Utilisez S3 quand l’admin et le worker tournent sur des hôtes différents. Définissez ces valeurs dans .env :
Les charges de travail AWS peuvent omettre les variables de clé d’accès quand le conteneur peut utiliser un rôle d’identifiants AWS. MinIO reste disponible par un profil Compose. Configurez les variables S3 pour MinIO, puis démarrez la pile avec ce profil :
Pour inspecter les courriels en local, démarrez Mailpit :

​
Exporter les données OpenTelemetry

L’export OpenTelemetry est désactivé quand OTEL_EXPORTER_OTLP_ENDPOINT est vide. Pour envoyer des traces, des métriques et des journaux OpenTelemetry à PostHog, ajoutez ces valeurs à .env :
Utilisez l’hôte PostHog de votre région et le jeton de votre projet. LobbyStack ajoute /v1/traces, /v1/metrics et /v1/logs à l’URL de base. Vous pouvez utiliser les mêmes variables avec un autre backend compatible OTLP. Redémarrez les conteneurs de l’application après avoir modifié les valeurs :
L’analytique produit directe et le signalement des erreurs utilisent leur propre configuration PostHog.

​
Vérifier le déploiement

Les ports de service par défaut écoutent sur localhost. Faites passer le trafic public par Caddy ou par un autre proxy inverse de confiance.

​
Liste de vérification pour la production

  • remplacez tous les identifiants de développement et limitez les permissions de .env
  • utilisez une valeur HTTPS de production pour APP_BASE_URL
  • définissez OPENAI_WEBHOOK_SECRET et TWILIO_SIP_TRUNK_SID pour répondre aux appels téléphoniques. Le worker ne provisionne pas de numéro de téléphone sans TWILIO_SIP_TRUNK_SID. Les variables des appels vocaux décrivent le rôle de chacune
  • définissez WEB_CALL_ALLOWED_ORIGINS avec les sites exacts qui hébergent votre appel de démo public, si vous en avez un
  • configurez des sauvegardes de PostgreSQL et du stockage de fichiers hors de l’hôte
  • faites un exercice de restauration avant d’accepter du trafic de production
  • limitez les ports de PostgreSQL, de Redis et de MinIO (facultatif) aux réseaux privés
  • surveillez l’état de l’admin, du worker, de la file d’attente, de la base de données et du stockage d’objets
  • épinglez les versions des images avant les mises à niveau planifiées

​
Mises à niveau

Sauvegardez PostgreSQL et le backend de stockage configuré avant la mise à niveau. Passez en revue les nouvelles migrations et variables d’environnement avant de redémarrer les services.