Le déploiement

La séparation des environnements

La production et le hors-production sont hébergés dans des projets distincts. Ils ne partagent ni données, ni secrets, ni comptes, ni droits d’accès.

Aucune donnée de production non anonymisée n’est utilisée hors production. Les environnements de développement, d’intégration, de recette et de performance peuvent adopter une infrastructure moins isolée et moins redondante, dès lors qu’elle reste représentative du fonctionnement de la production.

L’anonymisation d’un extrait de production a ses limites : elle appauvrit les données sans écarter tout risque de réidentification. L’objectif est d’engendrer des jeux d’essai synthétiques, représentatifs des volumes et des cas métier, construits sans partir de données réelles.

Une infrastructure par tenant

En production, chaque tenant dispose de sa propre infrastructure : cluster Kubernetes, bus de messages, bases de données, espaces de stockage et chaîne de déploiement.

Cette séparation constitue la principale frontière entre les tenants. Elle peut être renforcée par les mécanismes propres à chaque composant, mais ne repose pas sur eux.

Tous les tenants exécutent les mêmes images applicatives. Leur infrastructure et leur dimensionnement peuvent varier sans nécessiter de modification du logiciel.

Le réseau

Chaque tenant s’exécute dans un réseau privé appliquant une politique de refus par défaut. Seuls les échanges nécessaires entre les points d’entrée, les composants applicatifs et leurs ressources techniques sont autorisés.

Les composants métier ne sont jamais directement accessibles depuis Internet. Les flux d’administration sont séparés des flux applicatifs, et les communications sortantes sont contrôlées comme les communications entrantes.

L’orchestration

Les composants sont répartis de manière à préserver les parcours critiques en cas de perte d’un nœud. Selon le niveau de disponibilité recherché, cela repose notamment sur plusieurs zones, plusieurs réplicas, des règles d’anti-affinité, des budgets d’interruption et le remplacement automatique des nœuds.

L’ajustement automatique du nombre de réplicas n’est activé que lorsque les métriques disponibles permettent de le piloter de manière fiable.

Les traitements ponctuels ou massifs s’exécutent dans des tâches dédiées. Les composants permanents n’ont ainsi pas à être dimensionnés pour leurs pics occasionnels.

Le bus d’événements

Chaque tenant possède son propre bus ou son propre espace d’événements, selon le déploiement retenu. Les événements portent également l’identifiant du tenant, que chaque consommateur vérifie par rapport à sa configuration.

Cette vérification complète l’isolation de l’infrastructure ; elle ne s’y substitue pas.

Le routage public

Une requête publique traverse successivement le service de bordure, le répartiteur de charge, le contrôleur d’entrée et le composant d’interface du tenant. Les composants métier et les ressources techniques restent sur le réseau privé.

Le nom d’hôte détermine le tenant destinataire. Chaque teneur de compte dispose d’un nom stable, tandis que Concerto utilise un nom commun à ses entreprises clientes. Seules les combinaisons d’hôte et de chemin explicitement déclarées sont routées ; un hôte inconnu est rejeté.

Le service de bordure assure la terminaison TLS, le filtrage et la limitation de débit. Il supprime tout identifiant de tenant fourni par l’appelant : cet identifiant provient exclusivement de la configuration du déploiement.

Le routage désigne le tenant, mais n’accorde aucun droit d’accès. L’autorisation est traitée selon les règles décrites dans Identité et autorisation.

Seuls les composants d’interface sont exposés publiquement. Diapason constitue le point d’entrée API des teneurs de compte qui y souscrivent. Les interfaces de supervision, les métriques, les sondes et les consoles techniques restent privées.

Le déploiement par tenant

Chaque composant produit une image commune, ensuite configurée et déployée séparément pour chaque tenant. La configuration précise notamment l’identifiant du tenant, les connexions aux bases et au bus ainsi que les espaces de stockage accessibles.

La chaîne de livraison conserve un inventaire des versions déployées, de l’état des migrations et de la date du dernier déploiement pour chaque tenant. Elle permet de maîtriser les écarts de version entre les installations.

La création d’un tenant est automatisée et ne nécessite aucune modification du code applicatif.

L’infrastructure décrite par le code

L’infrastructure est entièrement décrite dans des fichiers versionnés : réseau, cluster, bases, comptes, droits, stockage, secrets et routage.

Un modèle commun permet de créer chaque infrastructure de manière reproductible. Les différences entre tenants sont exprimées par la configuration, et non par des opérations manuelles ou des variantes du logiciel.

La chaîne de livraison

La chaîne de livraison construit des images reproductibles et signées, analyse les dépendances, exécute les tests et déploie progressivement les nouvelles versions.

Les migrations de schéma sont exécutées dans des tâches dédiées avant le démarrage des composants concernés. Chaque déploiement est vérifié automatiquement et peut être annulé lorsque l’évolution du schéma le permet.

Les commandes exécutées par la chaîne restent utilisables en dehors du pipeline, afin que la construction et le déploiement ne dépendent pas d’un outil d’intégration particulier.