Le Stack Harbor PaaS repose sur trois couches qui, ensemble, rendent les environnements simples à opérer : vous déclarez ce que vous voulez, la plateforme le place. Cette page explique ce que contient chaque couche, comment elles interagissent et pourquoi ces choix de conception influencent la façon dont vous opérez vos applications.
Ce que couvre cette page
- Le modèle à trois couches : environnements applicatifs, orchestrateur de cluster et niveau d’infrastructure.
- Ce qu’est un cluster et comment les régions correspondent aux clusters.
- Comment l’orchestrateur traite chaque action que vous effectuez — tableau de bord, API ou CLI.
- Comment les nœuds hôtes sont partitionnés en conteneurs et pourquoi cela rend possible le redimensionnement vertical en direct.
- La couche réseau et le répartiteur de charge partagé qui entourent chaque environnement.
- Comment un environnement est physiquement placé lors de sa création.
Cette page est conceptuelle (Débutant → Intermédiaire). Elle ne contient pas de commandes. Pour le modèle mental qui se situe au-dessus de cette architecture, consultez l’Aperçu de la plateforme. Pour la création d’environnements en pratique, consultez la Gestion des environnements.
Les trois couches
La plateforme empile trois couches, du haut vers le bas :
- Environnements applicatifs — l’unité avec laquelle vous interagissez en tant que développeur. Un environnement est un regroupement logique de conteneurs qui exécutent une application : un niveau web, une base de données, un cache, un répartiteur de charge. C’est là que votre travail réside.
- Orchestrateur de cluster — le plan de contrôle. Chaque action que vous effectuez via le tableau de bord, l’API ou la CLI est traitée ici. L’orchestrateur provisionne les environnements, planifie les conteneurs sur les hôtes matériels, exécute les opérations de cycle de vie, applique les règles de pare-feu et expose les métriques.
- Niveau d’infrastructure — la flotte matérielle. Les hôtes physiques sont partitionnés en conteneurs isolés à l’aide d’un substrat de conteneurs système. L’orchestrateur décide sur quel hôte chaque conteneur est placé.
Clusters et régions
Un cluster correspond à une région. Chaque cluster dispose de sa propre capacité matérielle, de son propre réseau interne et de sa propre instance d’orchestrateur. Lorsque vous choisissez une région pour un environnement, vous choisissez un cluster.
Les clusters sont indépendants. Une interruption dans une région n’affecte pas les autres. Les environnements sont rattachés à un seul cluster à la fois, mais ils peuvent être exportés et réimportés dans un autre cluster pour déplacer une charge de travail entre régions — consultez la Gestion des environnements.
L’orchestrateur de cluster
L’orchestrateur est le plan de contrôle de la plateforme. Il est le seul composant à communiquer avec le matériel ; vous ne le faites jamais directement.
Lorsque vous créez un environnement, redimensionnez un conteneur, redéployez une application ou modifiez une règle de pare-feu, l’action est transmise à l’orchestrateur, qui la valide, planifie le travail, le dispatche vers l’hôte cible et renvoie le résultat au tableau de bord et à l’API. L’orchestrateur gère :
- Le provisionnement et le placement des conteneurs — choisit quel nœud hôte reçoit chaque nouveau conteneur, en tenant compte de la capacité, de l’isolation et des règles d’affinité.
- Les opérations de cycle de vie — démarrage, arrêt, redémarrage, redéploiement, migration. Ces opérations sont atomiques : l’orchestrateur suit chaque opération comme une tâche observable dans le panneau des tâches du tableau de bord.
- La mise à l’échelle verticale et horizontale — modifie les limites de ressources d’un conteneur en cours d’exécution (vertical) ou ajoute et supprime des nœuds d’une couche (horizontal), en coordonnant les déploiements pour préserver la disponibilité.
- L’émission et le renouvellement des certificats SSL — gère le cycle de vie complet des certificats pour le SSL intégré et les certificats Let’s Encrypt, sans intervention manuelle.
- L’évaluation des règles de pare-feu — applique les règles entrantes et sortantes au niveau du conteneur avant que le trafic n’atteigne votre application.
- La planification des sauvegardes et la gestion des instantanés — coordonne les sauvegardes planifiées et les instantanés à la demande dans la couche de stockage.
- La collecte de métriques et les alertes de charge — collecte les métriques de ressources par conteneur et évalue les seuils pour déclencher des alertes de charge.
Niveau d’infrastructure : nœuds hôtes et conteneurs
La couche matérielle est une flotte d’hôtes physiques exécutant un substrat de conteneurs système. Comprendre le fonctionnement de cette couche explique plusieurs comportements de la plateforme qui pourraient autrement sembler inattendus.
Conteneurs système et modèle imbriqué
Chaque hôte physique exécute plusieurs conteneurs système. Un conteneur système est un environnement complet au niveau de l’OS : il possède son propre système de fichiers, ses propres interfaces réseau et son propre arbre de processus, mais partage le noyau de l’hôte. Il n’y a ni hyperviseur ni OS invité — cela élimine la surcharge de la virtualisation traditionnelle.
Vos conteneurs applicatifs (conteneurs Docker, pods Kubernetes) s’exécutent à l’intérieur d’un conteneur système. Cette imbrication confère à la plateforme deux propriétés :
- Isolation au niveau du noyau sans surcharge de machine virtuelle. Les conteneurs de chaque environnement sont isolés des autres locataires au niveau de l’OS, mais ne portent pas la latence ni le coût mémoire d’un OS invité complet.
- Redimensionnement vertical en direct sans redémarrage. L’orchestrateur ajuste les limites de ressources d’un conteneur (parts CPU, plafond mémoire) en place. Le conteneur continue de s’exécuter ; la charge de travail voit les nouvelles limites en quelques secondes.
Le cloudlet — l’unité de RAM et de CPU de la plateforme — est appliqué à cette couche. Chaque conteneur reçoit un plancher réservé de cloudlets (minimum garanti) et un plafond dynamique de cloudlets (limite de burst). La consommation est mesurée sur l’hôte ; vous payez ce qui est réellement utilisé, et non le plafond.
Placement des environnements
Lorsque vous créez un environnement et choisissez une région, l’orchestrateur évalue les nœuds hôtes disponibles dans ce cluster et place les conteneurs de chaque couche selon les contraintes de capacité et d’isolation. Vous ne choisissez pas l’hôte ; l’orchestrateur gère le placement de façon transparente.
Si un nœud hôte devient défaillant, l’orchestrateur peut migrer les conteneurs en direct vers un autre hôte du même cluster sans nécessiter d’action manuelle de votre part.
La couche réseau
Chaque cluster exécute une couche réseau interne qui connecte les conteneurs entre eux et avec l’extérieur.
- Adressage interne — les conteneurs d’un même environnement peuvent se joindre par nom d’hôte. Les conteneurs d’environnements différents sont isolés par défaut.
- Répartiteur de charge partagé (SLB) — le frontal de la plateforme qui termine le TLS et achemine le trafic entrant vers le bon environnement. Pour les environnements sans IP publique dédiée, le répartiteur partagé est le point d’entrée. Le SSL personnalisé nécessite une IP dédiée ou le chemin de certificat compatible SLB ; consultez l’Aperçu SSL et TLS.
- IP publiques — vous pouvez associer une IP publique dédiée à n’importe quelle couche de conteneurs. Le trafic contourne alors le SLB et arrive directement à l’interface réseau de ce conteneur. Consultez IP publique.
- Points de terminaison (Endpoints) — pour exposer des ports non HTTP (bases de données, services TCP/UDP personnalisés) sans IP publique, la plateforme mappe un port du SLB vers le conteneur cible. Consultez Endpoints.
La couche de stockage
Les données persistantes sont stockées en dehors du système de fichiers éphémère du conteneur, via un stockage infogéré. La plateforme fournit :
- Stockage dans le système de fichiers local — données écrites vers des chemins spécifiques dans un conteneur qui survivent à un redéploiement. Consultez Stockage dans le système de fichiers local.
- Volumes de conteneurs — montages de volumes explicites qui persistent lors des remplacements de conteneurs. Consultez Volumes de conteneurs.
- Conteneurs de stockage dédiés — un type de conteneur distinct optimisé pour le stockage de données, accessible via NFS par les autres conteneurs de l’environnement. Consultez Conteneur de stockage dédié.
- Points de montage — montages NFS permettant aux conteneurs de partager des données au sein d’un environnement ou entre environnements. Consultez Points de montage.
Les bases de données infogérées gèrent leur stockage en interne ; vous interagissez avec elles via des chaînes de connexion et les contrôles de sauvegarde et de réplication de la plateforme.
Contraintes et cas particuliers
- Un environnement réside dans exactement un cluster (région). Pour opérer dans plusieurs régions, vous créez plusieurs environnements et gérez la distribution du trafic au niveau DNS ou du répartiteur de charge.
- Le redimensionnement vertical est effectué en direct pour les conteneurs système exécutant les piles supportées par la plateforme. Certains processus au niveau applicatif peuvent nécessiter un redémarrage pour observer les nouvelles limites — cela dépend de la façon dont le runtime lit la configuration des ressources.
- La migration en direct entre hôtes est initiée par l’orchestrateur et transparente pour la plupart des charges de travail. Les charges de travail avec état qui maintiennent des connexions ouvertes peuvent subir de brèves interruptions ; testez le comportement de migration dans un environnement de test avant de vous y fier en production.
- Le répartiteur de charge partagé a des limites de connexion et de débit de requêtes qui s’appliquent à tous les environnements qui l’utilisent. Les environnements à fort débit ou avec des exigences strictes en matière de latence devraient utiliser une IP publique dédiée et une couche de répartiteur de charge (NGINX ou HAProxy) à l’intérieur de l’environnement.
La suite
- Aperçu de la plateforme — le modèle orienté développeur (environnements, couches, nœuds, cloudlets) qui se situe au-dessus de l’architecture.
- Types de conteneurs et cas d’usage — conteneurs système, Docker personnalisé et Kubernetes ; quand utiliser chacun.
- Gestion des environnements — créer, cloner, exporter, importer et transférer des environnements.
- Mise à l’échelle et clustering — scaling vertical et horizontal, auto-clustering, patrons multi-régions.
- Aperçu SSL et TLS — comment le répartiteur partagé, le SSL intégré et le SSL personnalisé s’articulent.
- IP publique — associer une IP dédiée pour contourner le répartiteur partagé.
- Guide du tableau de bord — où trouver chaque concept architectural dans l’interface.