Déploiement

Un binaire, une configuration dans Git, toutes vos topologies.

Le même binaire et la même image signée, du poste au cluster : la configuration vit dans Git, se valide hors ligne et se recharge sans perdre une requête. Voici le cycle commun, puis chaque topologie avec son statut à la version publiée.

Ce qui fait la force d'exploitation

Un binaire, une image signée, un chart
La même chose du poste (docker run) à la VM (systemd) et au cluster (Helm) ; archive et image vérifiables avec cosign.
Git, seule source
Contrat et flexway.yaml versionnés, validés hors ligne ; la console propose en pull request, elle n'écrit jamais.
Rechargé sans perte
Sans redémarrer ni perdre une requête ; une configuration invalide est refusée en bloc, celle en cours continue de servir.
Refuser plutôt que tomber
Plafond en vol, délestage du délestable d'abord, drainage à l'arrêt ; chaque réplique dit son état à la console.

Le cycle de configuration GitOps

Commun à toutes les topologies : rien n'atteint la passerelle sans revue, la console n'écrit jamais en production.

flexwayPasserelle API, IA et agents

Le cycle de configuration : le contrat et flexway.yaml dans Git ; flexway validate hors ligne dans votre CI ; déploiement de la même image signée, par chart ou par fichier ; rechargement à chaud sans perdre une requête, une configuration invalide est refusée en bloc et celle en cours continue de servir ; la console observe ; une modification repart en proposition, un diff en pull request, jamais une écriture.

Dépôt Git: Le dépôt Git : le contrat et flexway.yaml versionnés, la seule source de vérité de la configuration.
Votre CI: Votre CI lance flexway validate hors ligne : une opération sans amont ou une politique qui ne compile pas fait échouer la CI.
Déploiement: Le déploiement : la même image signée, par chart Helm, conteneur ou binaire, du poste au cluster.
Rechargement: Le rechargement à chaud : la nouvelle configuration est servie sans redémarrer ; invalide, elle est refusée et l'ancienne sert.
Console: La console observe : version servie, dernier rechargement, trafic et santé de chaque réplique ; elle n'écrit pas.
Proposition: La proposition : un changement préparé dans la console devient un diff vérifié, ouvert en pull request.

Trafic

Les topologies

Quand l'utiliser, ce qui monte en charge et comment, ce qu'il faut opérer, le statut au catalogue de la version publiée. Aucun chiffre de débit ni de latence : aucun banc n'est publié.

Un binaire, un conteneurKubernetes, haute disponibilitéPlusieurs environnementsDevant un maillageSouverain, sans sortiePlusieurs passerellesPrévuEdgePrévu en 1.11

flexwayPasserelle API, IA et agents

Un binaire ou un conteneur : les appelants appellent un seul processus Flexway, qui lit un fichier flexway.yaml et son contrat et relaie vers vos amonts. SIGHUP recharge la configuration, SIGTERM draine.

Appelants: Les appelants (applications, partenaires, agents) : ils ne voient qu'une adresse, celle de Flexway.
flexway: Un seul processus Flexway : il lit son fichier, décide et relaie ; SIGHUP recharge, SIGTERM draine.
flexway.yaml: Le fichier flexway.yaml et son contrat : validés hors ligne, rechargés sans redémarrer.
Amonts: Vos amonts (services, modèles) : ils ne reçoivent que les requêtes que Flexway a laissées passer.

Trafic
Configuration et observation
Périmètre

Statut: Livré · v0.1.0
Quand l'utiliser: Un essai (docker run), une VM ou du bare metal : le binaire est le service, sous systemd ou tout superviseur.
Ce qui monte en charge: La machine. Une réplique, ses compteurs en mémoire ; pour plusieurs instances, la topologie Kubernetes ou un cache partagé compatible Redis.
Ce qu'il faut opérer: Un fichier flexway.yaml et son contrat ; l'archive signée vérifiée avec cosign ; SIGHUP recharge, SIGTERM draine.

flexwayPasserelle API, IA et agents

Kubernetes en haute disponibilité : les appelants passent par votre bord (ingress, répartiteur), qui répartit entre trois répliques de Flexway sans état. Chaque réplique décide seule et se réconcilie avec le cache partagé compatible Redis (Redis, Dragonfly ou Valkey). Le contrat et la configuration, versionnés dans Git, sont un ConfigMap : un helm upgrade est servi sans redémarrage. La console suit la santé de chaque réplique.

Appelants: Les appelants (applications, partenaires, agents) : ils ne voient qu'une adresse, celle de Flexway.
Bord: Votre bord (ingress, répartiteur) : il répartit entre les répliques et peut terminer le mTLS.
flexway · réplique 1: Une réplique de Flexway, sans état : elle décide seule ; on en ajoute pour monter en charge, SIGTERM la draine.
flexway · réplique 2: Une réplique de Flexway, sans état : elle décide seule ; on en ajoute pour monter en charge, SIGTERM la draine.
flexway · réplique 3: Une réplique de Flexway, sans état : elle décide seule ; on en ajoute pour monter en charge, SIGTERM la draine.
Amonts: Vos amonts (services, modèles) : ils ne reçoivent que les requêtes que Flexway a laissées passer.
ConfigMap: La ConfigMap : le contrat et flexway.yaml montés en répertoire ; un helm upgrade est servi sans redémarrage.
Dépôt Git: Le dépôt Git : la configuration versionnée, appliquée par votre outil de déploiement.
Cache des compteurs: Un cache partagé compatible Redis, facultatif : les répliques y réconcilient leurs compteurs à intervalle régulier, sans aller-retour sur le chemin.
Console: La console : santé de chaque réplique, tableaux de bord et alertes.

Trafic
Configuration et observation
Cache partagé des compteurs
Périmètre

Statut: Livré · v1.4.0
Quand l'utiliser: Production en grappe : plusieurs répliques sans état derrière votre bord (ingress, répartiteur).
Ce qui monte en charge: On ajoute des répliques. Chaque réplique décide seule et se réconcilie avec le cache partagé compatible Redis (Redis, Dragonfly ou Valkey) : aucun aller-retour sur le chemin. Sans cache partagé, les compteurs sont locaux à chaque réplique.
Ce qu'il faut opérer: helm install ; le contrat et la configuration en ConfigMap, un helm upgrade est servi sans redémarrage ; les Secret que le chart ne crée pas ; le cache des compteurs ; monitoring.enabled pose un tableau de bord et des alertes.

flexwayPasserelle API, IA et agents

Plusieurs environnements : un dépôt Git porte une configuration par environnement ; dév, préprod et prod font tourner la même image signée de Flexway ; une configuration validée en dév est promue en préprod puis en prod par pull request ; la console de chaque environnement observe et propose en pull request.

Dépôt Git: Le dépôt Git : un contrat commun, les valeurs de chaque environnement par références, jamais en clair.
Dév · flexway: L'environnement de développement : la même image signée que la production, seules les valeurs changent.
Préprod · flexway: La préproduction : la même image, promue par une pull request revue et tracée.
Prod · flexway: La production : la même image, promue par une pull request revue et tracée.
Console: La console : elle propose les changements en pull request, la promotion passe par Git.

Trafic
Configuration et observation
Périmètre

Statut: Livré · v1.2.0Livré par ses briques : même image, références ${VAR} et file:, validation hors ligne, propositions en pull request.
Quand l'utiliser: Dév, préprod et prod séparés, avec une promotion revue et tracée.
Ce qui monte en charge: Chaque environnement selon sa topologie (binaire ou Kubernetes) ; seules les valeurs changent, jamais le binaire.
Ce qu'il faut opérer: Une configuration par environnement dans Git, les secrets par référence ; flexway validate dans la CI de chaque branche ou dossier.
À noter: Le guide de Flexway ne décrit pas encore ce parcours de bout en bout : cette topologie assemble des fonctionnalités livrées, chacune documentée.

flexwayPasserelle API, IA et agents

Devant un maillage de services : les appelants passent par le proxy du maillage, qui vérifie l'identité mTLS du pair et répartit entre les répliques de Flexway ; Flexway lit cette identité dans un en-tête de confiance et relaie vers les services du maillage. Le chiffrement et le routage entre services restent au maillage.

Appelants: Les autres services du maillage : leur identité mTLS est vérifiée par le proxy avant d'arriver à Flexway.
Proxy du maillage: Le proxy du maillage de services : il vérifie l'identité mTLS du pair et répartit entre les répliques.
flexway · réplique 1: Une réplique de Flexway derrière le proxy du maillage : elle lit l'identité que le proxy a vérifiée.
flexway · réplique 2: Une réplique de Flexway derrière le proxy du maillage : elle lit l'identité que le proxy a vérifiée.
Services: Vos services : ils ne reçoivent que les requêtes que Flexway a laissées passer.

Trafic
Périmètre

Statut: Livré · v0.1.0
Quand l'utiliser: Une grappe avec un maillage de services : Flexway s'y insère au lieu de le remplacer.
Ce qui monte en charge: Les répliques, réparties par le maillage, qui voit les répliques.
Ce qu'il faut opérer: server.trusted_proxies: [local] et server.peer_identity_header (par exemple l5d-client-id) ; le chiffrement et le routage entre services restent au maillage.

flexwayPasserelle API, IA et agents

Souverain, sans sortie réseau : les appelants internes, Flexway, le dépôt Git, l'observabilité, les modèles internes et les services sont tous dans votre infrastructure ; aucun connecteur lié à un fournisseur de cloud ; la configuration se valide hors ligne. La licence vérifiée sans appel réseau est à venir.

Appelants internes: Vos appelants internes, dans votre réseau : rien ne transite par un service extérieur.
flexway: Flexway dans votre infrastructure : image signée, sans base de données ni service extérieur sur le chemin.
Dépôt Git: Votre dépôt Git, chez vous : la configuration y est validée hors ligne.
Observabilité: Votre observabilité OpenTelemetry, chez vous : traces et métriques ne sortent pas de votre infrastructure.
Modèles internes: Vos modèles internes : une requête marquée sensible y est épinglée.
Services: Vos services : ils ne reçoivent que les requêtes que Flexway a laissées passer.
Licence: Prévu : La licence de Flexway, vérifiée hors ligne, sans appel à un service de l'éditeur.

Trafic
Configuration et observation
Périmètre
Prévu

Statut: Livré · v0.1.0Livré, sauf la licence vérifiée hors ligne, à venir sans version.
Quand l'utiliser: Secteurs régulés, réseau fermé : tout doit tourner dans votre infrastructure.
Ce qui monte en charge: Comme sa topologie de base (binaire ou Kubernetes).
Ce qu'il faut opérer: Tout en interne : dépôt Git, observabilité OpenTelemetry, modèles ; aucun connecteur lié à un fournisseur de cloud ; flexway validate hors ligne.

flexwayPasserelle API, IA et agents

Plusieurs passerelles, une console : une console partagée suivrait plusieurs passerelles, avec des portées déclarées (passerelles, source de métriques, dépôt). À venir, sans version au catalogue : entièrement en pointillé.

Source de métriques: Prévu : Une source de métriques par portée, pour la console partagée.
Console partagée: Prévu : Une console partagée pour tout un parc de passerelles, avec des portées déclarées.
Dépôt: Prévu : Un dépôt de configuration par portée.
Passerelle A: Prévu : Une passerelle Flexway du parc, suivie depuis la console partagée.
Passerelle B: Prévu : Une passerelle Flexway du parc, suivie depuis la console partagée.
Passerelle C: Prévu : Une passerelle Flexway du parc, suivie depuis la console partagée.

Configuration et observation
Prévu

Statut: Prévu
Quand l'utiliser: Un parc de passerelles suivi depuis une seule console.
Ce qui monte en charge: -
Ce qu'il faut opérer: Aujourd'hui, une console par passerelle.

flexwayPasserelle API, IA et agents

Edge : le même binaire sur chaque site (usine, exploitation), la configuration signée tirée et vérifiée par le site, des décisions locales sans réseau, la mise en tampon laissée au courtier local. Prévu, entièrement en pointillé.

Configuration signée: Prévu en 1.11 : Une configuration signée, que chaque site tire et vérifie lui-même.
Site 1 · flexway: Prévu en 1.11 : Flexway sur un site : il décide localement, sans plan central, avec une configuration signée.
Site 2 · flexway: Prévu en 1.11 : Flexway sur un site : il décide localement, sans plan central, avec une configuration signée.
Courtier local: Prévu en 1.11 : Un courtier local au site, qui sert de tampon quand le réseau manque.
Courtier local: Prévu en 1.11 : Un courtier local au site, qui sert de tampon quand le réseau manque.

Trafic
Prévu

Statut: Prévu en 1.11
Quand l'utiliser: Des sites (usine, exploitation) qui doivent décider sans réseau.
Ce qui monte en charge: Une passerelle par site.
Ce qu'il faut opérer: Configuration signée tirée par le site ; la mise en tampon reste au courtier local.

Parlons de votre passerelle

Flexwiz est une jeune entreprise : vous parlez directement avec la personne qui la fonde. Dites-nous ce que vous voulez faire passer par Flexway. Nous parlons de votre infrastructure et de vos exigences de souveraineté numérique.

Parler à un expert Écrire à Flexwiz

La prise de rendez-vous en ligne arrive bientôt ; d'ici là, un e-mail suffit.

Un binaire, une configuration dans Git, toutes vos topologies.

Ce qui fait la force d'exploitation

Un binaire, une image signée, un chart

Git, seule source

Rechargé sans perte

Refuser plutôt que tomber

Le cycle de configuration GitOps

Les topologies

Un binaire ou un conteneur

Kubernetes, haute disponibilité

Plusieurs environnements

Devant un maillage de services

Souverain, sans sortie réseau

Plusieurs passerelles, une console

Edge : une passerelle par site

Parlons de votre passerelle