LangFlow sur GKE Autopilot

LangFlow est un outil visuel open source et low-code de création d'agents et de workflows d'IA, basé sur LangChain — vous assemblez des chaînes de modèles de langage, des pipelines RAG et des agents en glissant et en reliant des composants sur un canevas, puis vous les exposez sous forme d'API. Ce module déploie LangFlow sur GKE Autopilot en s'appuyant sur le socle App_GKE, qui provisionne et gère l'infrastructure Google Cloud et Kubernetes partagée.

Ce guide se concentre sur les services cloud utilisés par LangFlow et sur la manière de les explorer et de les exploiter depuis la console Google Cloud et la ligne de commande. Pour les mécanismes communs à toutes les applications GKE — Workload Identity, entrée, mise à l'échelle automatique, CI/CD, Cloud Armor, IAP, Binary Authorization, VPC Service Controls, sauvegardes et cycle de vie du déploiement — reportez-vous au guide du socle App_GKE plutôt que de les répéter ici.

1. Vue d'ensemble

LangFlow s'exécute comme une charge de travail web Python unique (FastAPI + React). Le déploiement assemble un ensemble ciblé de services Google Cloud :

Fonctionnalité	Service Google Cloud	Remarques
Calcul	GKE Autopilot	Pods Python sur le port 7860, 1 vCPU / 2 GiB par défaut, mise à l'échelle automatique horizontale
Base de données	Cloud SQL for PostgreSQL 15	Obligatoire — LangFlow conserve l'ensemble des flux, composants et identifiants dans Postgres
Stockage d'objets	Cloud Storage	Un bucket `data` dédié est provisionné par défaut ; l'état applicatif de LangFlow réside lui-même dans PostgreSQL
Cache et file d'attente	Redis (facultatif)	Non requis par LangFlow ; câblé uniquement par souci de compatibilité future
Secrets	Secret Manager	`LANGFLOW_SECRET_KEY` et `LANGFLOW_SUPERUSER_PASSWORD` générés automatiquement ; mot de passe de la base de données
Entrée	Cloud Load Balancing	LoadBalancer externe, domaine personnalisé + certificat géré en option

Valeurs par défaut judicieuses à connaître d'emblée :

PostgreSQL 15 est obligatoire. Le moteur de base de données est imposé par la couche applicative partagée (database_type = "POSTGRES_15") ; choisir un autre moteur empêche le démarrage.
LANGFLOW_SECRET_KEY est généré automatiquement et stocké dans Secret Manager. Il chiffre chaque identifiant stocké intégré dans un flux. Il ne doit jamais faire l'objet d'une rotation après le premier démarrage — sa rotation casse définitivement tous les identifiants stockés, qu'il faut alors ressaisir dans chaque flux.
Le compte administrateur est provisionné à partir d'un mot de passe généré. LANGFLOW_AUTO_LOGIN = "false" active l'authentification ; LangFlow crée l'administrateur initial (admin par défaut) à l'aide du secret LANGFLOW_SUPERUSER_PASSWORD. Récupérez-le dans Secret Manager pour vous connecter.
La base de données se connecte via le sidecar Cloud SQL Auth Proxy sur 127.0.0.1 ; le point d'entrée compose LANGFLOW_DATABASE_URL via TCP avec sslmode=disable (le proxy termine le TLS).
L'affinité de session est ClientIP par défaut. LangFlow conserve un état de session et d'éditeur de flux en mémoire de processus ; le routage persistant maintient un client sur le même pod.
Un seul pod par défaut (min_instance_count = 1, max_instance_count = 1). GKE ne descend pas à zéro ; l'état en mémoire de processus de LangFlow fait d'un réplica unique la valeur par défaut sûre.
L'état applicatif réside dans PostgreSQL ; NFS est désactivé par défaut. Un bucket Cloud Storage data est provisionné par défaut (storage_buckets), mais LangFlow conserve lui-même les flux, composants et identifiants dans la base de données.

2. Services Google Cloud et comment les explorer

Toutes les commandes supposent que vous avez exécuté gcloud container clusters get-credentials <cluster> --region <region> --project <project> et que PROJECT, REGION et NAMESPACE sont définis. L'espace de noms et les autres identifiants sont indiqués dans les sorties du déploiement.

A. GKE Autopilot — la charge de travail LangFlow

Les pods LangFlow sont planifiés sur Autopilot, qui facture le CPU et la mémoire réellement demandés par les pods. L'autoscaling horizontal des pods dimensionne le déploiement entre le nombre minimal et le nombre maximal de réplicas.

Console : Kubernetes Engine → Workloads → sélectionnez la charge de travail LangFlow pour voir les pods, les révisions et les événements. Kubernetes Engine → Services & Ingress affiche l'IP externe.

CLI :

kubectl get pods,svc,hpa -n "$NAMESPACE"
kubectl logs -n "$NAMESPACE" deploy/<service-name> --tail=100
kubectl describe hpa -n "$NAMESPACE"          # current vs target utilisation

Consultez App_GKE pour la gestion d'Autopilot, de la mise à l'échelle et du type de charge de travail (Deployment ou StatefulSet).

B. Cloud SQL for PostgreSQL 15

LangFlow stocke toutes les données applicatives (flux, composants, identifiants, historique d'exécution, utilisateurs) dans une instance gérée Cloud SQL for PostgreSQL 15. Les pods y accèdent de façon privée via le sidecar Cloud SQL Auth Proxy sur 127.0.0.1 ; aucune IP publique n'est exposée. Au premier déploiement, un job d'initialisation crée la base de données applicative, le rôle et les droits.

Console : SQL → sélectionnez l'instance pour les connexions, les sauvegardes, les flags et les métriques.

CLI :

gcloud sql instances list --project "$PROJECT" --filter="name~langflow"
gcloud sql instances describe <instance-name> --project "$PROJECT"
# Open an interactive shell to inspect schema/data:
gcloud sql connect <instance-name> --user=<db-user> --database=<db-name> --project "$PROJECT"

Le nom de l'instance, le nom de la base de données, l'utilisateur et le secret Secret Manager contenant le mot de passe figurent tous dans les sorties. Pour le modèle de connexion, les sauvegardes automatiques et la rotation des mots de passe, consultez App_GKE.

C. Redis (facultatif — non utilisé par LangFlow)

Redis est désactivé par défaut et LangFlow n'en a pas besoin ; les entrées enable_redis sont câblées uniquement par souci de compatibilité future. Laissez enable_redis = false, sauf si une fonctionnalité future le requiert.

CLI (uniquement s'il est activé) :

kubectl exec -n "$NAMESPACE" deploy/<service-name> -- env | grep -i redis

D. Secret Manager

Deux secrets sont générés automatiquement et stockés dans Secret Manager : LANGFLOW_SECRET_KEY (chiffre tous les identifiants stockés) et LANGFLOW_SUPERUSER_PASSWORD (le mot de passe de connexion de l'administrateur initial). Ils sont fournis aux pods via l'intégration Secret Store CSI. Le mot de passe de la base de données est géré séparément par le socle.

Console : Security → Secret Manager.

CLI :

gcloud secrets list --project "$PROJECT" --filter="name~langflow"
gcloud secrets versions access latest --secret=<secret-name> --project "$PROJECT"

Le nom du secret du mot de passe de la base de données figure dans les sorties. Consultez App_GKE pour l'intégration Secret Store CSI et la rotation.

E. Réseau et entrée

Par défaut, la charge de travail est exposée via une IP externe Cloud Load Balancing (service_type = LoadBalancer). Un domaine personnalisé avec un certificat géré par Google peut être activé, et une IP statique peut être réservée afin que l'adresse survive aux redéploiements.

Console : Network services → Load balancing ; VPC network → IP addresses.

CLI :

kubectl get ingress,svc -n "$NAMESPACE"
gcloud compute addresses list --project "$PROJECT"

Consultez App_GKE pour les détails sur les domaines personnalisés, Cloud CDN et l'IP statique.

F. Cloud Logging et Monitoring

Les sorties stdout/stderr des pods sont envoyées à Cloud Logging ; les métriques GKE et Cloud SQL à Cloud Monitoring. Des tests de disponibilité et des règles d'alerte facultatives sont disponibles.

Console : Logging → Logs Explorer ; Monitoring → Dashboards / Alerting.

CLI :

gcloud logging read 'resource.type="k8s_container" AND resource.labels.namespace_name="'"$NAMESPACE"'"' \
  --project "$PROJECT" --limit 50

3. Comportement de l'application LangFlow

Configuration de la base de données au premier déploiement. Un job d'initialisation exécute create-db-and-user.sh à l'aide de postgres:15-alpine. Il attend PostgreSQL, puis crée de manière idempotente le rôle applicatif et la base de données, définit le propriétaire et accorde les privilèges sur la base et sur le schéma public, puis signale au sidecar Cloud SQL Auth Proxy de s'arrêter (POST /quitquitquit) afin que le pod du job se termine proprement. Il peut être relancé sans risque.
Migrations de schéma au démarrage. LangFlow exécute ses migrations Alembic à chaque démarrage du conteneur ; les tables sont donc créées et mises à niveau par l'application elle-même — le job db-init ne gère que le rôle, la base et les droits. Prévoyez un délai supplémentaire au premier démarrage.
LANGFLOW_SECRET_KEY est immuable après le premier démarrage. Il est généré une seule fois et écrit dans Secret Manager. Le modifier casse définitivement chaque identifiant stocké intégré dans un flux ; ceux-ci ne peuvent plus être déchiffrés. Ne procédez à une rotation que pendant une fenêtre de maintenance planifiée, avec un plan de ressaisie des identifiants.
Compte administrateur initial. Avec LANGFLOW_AUTO_LOGIN = "false", LangFlow crée le superutilisateur (admin par défaut, défini via langflow_username) à l'aide du secret LANGFLOW_SUPERUSER_PASSWORD. Récupérez le mot de passe et connectez-vous :
```
gcloud secrets versions access latest \
  --secret=<langflow-password-secret> --project "$PROJECT"
```
L'URL de la base de données est composée à l'exécution. Le point d'entrée construit LANGFLOW_DATABASE_URL à partir des variables DB_* injectées, via TCP. Sur GKE, DB_HOST = 127.0.0.1 (le sidecar Auth Proxy) ; sslmode=disable est donc utilisé — ne définissez pas le DSN manuellement.
Chemin de santé. Les sondes de démarrage et de vivacité ciblent /health, le point de terminaison public de vivacité de LangFlow, qui renvoie 200 dès que le serveur est opérationnel. Au premier démarrage, prévoyez le temps des migrations Alembic avant que le pod ne devienne Ready.
Affinité de session. session_affinity = ClientIP maintient chaque client sur le même pod — important, car LangFlow conserve l'état de l'éditeur de flux en mémoire de processus.

Inspecter l'exécution des jobs :

kubectl get jobs -n "$NAMESPACE"
kubectl logs -n "$NAMESPACE" job/<job-name>

4. Variables de configuration

Les variables sont regroupées exactement comme elles apparaissent sur la plateforme de déploiement. Seuls les paramètres propres à LangFlow ou notables pour lui sont listés ; toutes les autres entrées sont héritées d'App_GKE avec leur comportement et leurs valeurs par défaut standard.