Le Stack Harbor PaaS est une plateforme applicative : vous livrez du code, la plateforme l’exécute. Cette page explique ce que cela signifie concrètement — ce qu’est la plateforme, qui en bénéficie, quel travail opérationnel elle absorbe, et en quoi elle diffère d’une infrastructure infonuagique brute ou d’un hôte infogéré dédié.
Ce que couvre cette page
- Ce qu’est le Stack Harbor PaaS et le modèle sur lequel il repose.
- À qui la plateforme est destinée.
- Ce que vous cessez de gérer en l’adoptant.
- Comment elle se distingue d’un IaaS brut et d’un hôte infogéré à locataire unique.
- Où s’inscrit la relation d’opérations infogérées pour les équipes qui souhaitent une couche humaine en complément.
- Où aller ensuite dans la documentation.
Aucune commande n’apparaît sur cette page — elle est purement conceptuelle. Pour le parcours pratique, commencez par l’Aperçu de la plateforme puis l’Aperçu de l’architecture.
Ce qu’est la plateforme
Le Stack Harbor PaaS est une plateforme de conteneurs infogérée. Vous décrivez ce que votre application nécessite — un palier web, une base de données, un cache, un répartiteur de charge — et la plateforme provisionne, exécute et opère cette topologie pour vous dans une grappe régionale.
L’unité de travail sur la plateforme est un environnement : un regroupement logique de conteneurs pour une application dans une région. Dans un environnement, les conteneurs sont organisés en couches selon leur rôle. Chaque couche contient un ou plusieurs nœuds — les conteneurs individuels qui effectuent le travail. Vous redimensionnez une couche en modifiant son nombre de nœuds (horizontal) ou en ajustant l’allocation de ressources de chaque nœud (vertical).
Les ressources sont mesurées en cloudlets, l’unité de RAM et de CPU de la plateforme. Un conteneur dispose d’un plancher réservé et d’un plafond dynamique, ce qui lui permet de consommer plus de capacité quand la charge monte et de la libérer quand elle baisse. La plateforme prend en charge tout ce qui se trouve sous la couche applicative : l’hyperviseur, le runtime de conteneur, le plan de contrôle d’orchestration, la couche réseau, les correctifs au niveau OS et le substrat de stockage. Vous interagissez via un tableau de bord, le CLI de la plateforme ou l’API — les trois surfaces atteignent le même ensemble d’actions.
À qui elle s’adresse
Le Stack Harbor PaaS convient aux équipes qui souhaitent se concentrer sur l’écriture et la livraison de logiciels, sans gérer l’infrastructure qui les fait tourner. C’est un choix adapté lorsque :
- Votre équipe veut exécuter des conteneurs sans construire ni entretenir une grappe Kubernetes privée ou un parc de machines virtuelles.
- Vous souhaitez une infrastructure prévisible et consommable — payer ce que l’application utilise réellement, pas une capacité fixe réservée — sans gérer directement la relation de facturation avec un grand fournisseur infonuagique.
- Vos charges de travail sont des applications web, des API, des traitements en arrière-plan, des bases de données infogérées, ou des combinaisons de ceux-ci — les types d’applications qui se mappent naturellement sur une topologie de conteneurs en couches.
- Vous voulez des bases de données infogérées (MySQL, MariaDB, PostgreSQL, MongoDB, Redis, Memcached) comme membres de première classe de l’environnement, avec réplication, sauvegarde et topologies haute disponibilité gérées par la plateforme plutôt que par votre équipe.
- Vous avez besoin de plusieurs environnements isolés pour la même application — production, préproduction, révision — et souhaitez les cloner, exporter ou migrer sans écrire de code d’infrastructure.
Le Stack Harbor PaaS n’est pas conçu pour les charges de travail qui nécessitent un accès direct à l’hyperviseur, un OS hôte spécifique ou un contrôle au niveau matériel. Pour ces cas, la plateforme propose l’Elastic VPS — un parcours documenté séparément.
Ce que vous cessez de gérer
Adopter la plateforme, c’est déléguer un ensemble précis de responsabilités opérationnelles. La plateforme prend en charge :
- L’hyperviseur et le parc d’hôtes — les hôtes physiques, les mises à jour du noyau, le remplacement du matériel. Vous n’interagissez jamais directement avec les nœuds hôtes.
- Le runtime de conteneur — le substrat de conteneurs système qui isole votre environnement des autres locataires. Aucune installation de runtime, aucune gestion de version de votre côté.
- L’orchestration — le placement, la migration en direct entre hôtes, le basculement automatique et les opérations du cycle de vie (démarrage, arrêt, redémarrage, redéploiement) pilotées par l’orchestrateur.
- La couche réseau — le routage interne entre conteneurs, le répartiteur de charge partagé qui termine le TLS pour le trafic entrant, et le cycle de vie des certificats pour le TLS intégré.
- Les correctifs au niveau OS — les mises à jour de sécurité des images de base et de l’OS hôte sont appliquées par la plateforme, pas planifiées par votre équipe.
- Le substrat de stockage — la couche qui permet aux données de survivre au remplacement d’un conteneur ou à une migration d’hôte.
Ce qui reste de votre côté : le code de votre application, votre configuration de déploiement, vos données, et les décisions sur la façon d’architecturer et de dimensionner vos environnements. La plateforme vous fournit les contrôles ; elle ne prend pas les décisions applicatives à votre place.
Comment elle se distingue
Stack Harbor PaaS versus IaaS brut
Avec une infrastructure-as-a-service brute, vous louez de la capacité de calcul et de stockage et construisez tout ce qui se trouve au-dessus : choisir et maintenir l’OS, installer et mettre à jour les runtimes, configurer et opérer un orchestrateur de conteneurs, câbler des répartiteurs de charge, gérer les certificats TLS, et concevoir vos propres routines de sauvegarde et de correctifs. Vous avez un contrôle total sur chaque couche, et l’entière responsabilité qui va avec.
Le Stack Harbor PaaS prend en charge tout depuis l’hyperviseur. Vous bénéficiez de topologies d’environnements, de bases de données infogérées, de TLS intégré et d’un modèle d’opération cohérent — au prix de travailler dans le catalogue de conteneurs et de runtimes pris en charge par la plateforme.
La plateforme ne remplace pas tous les cas d’usage IaaS. Les charges de travail qui doivent configurer directement l’OS hôte, gérer des paramètres du noyau ou opérer en dehors du modèle de conteneurs de la plateforme appartiennent à l’IaaS ou à l’Elastic VPS.
Stack Harbor PaaS versus un hôte infogéré à locataire unique
Un hôte infogéré dédié vous donne un serveur connu et réservé — utile quand les exigences d’une application sont étroitement couplées à un OS spécifique ou quand les conditions de licence imposent du matériel physique ou dédié. La contrepartie est que la mise à l’échelle implique de commander un nouvel hôte, que le basculement nécessite une intervention manuelle ou scriptée, et que la portée infogérée s’arrête généralement à l’OS plutôt que de s’étendre au runtime de votre application.
Le Stack Harbor PaaS est multi-locataire au niveau de l’infrastructure (les conteneurs de différents comptes partagent des hôtes physiques, isolés par le substrat de conteneurs système) et infogéré au niveau applicatif. La mise à l’échelle est en direct. Le basculement est initié par la plateforme. La couche base de données, le cycle de vie des certificats et la chaîne de déploiement relèvent tous du modèle d’opération de la plateforme plutôt que d’en être extérieurs.
Où s’inscrit la relation d’opérations infogérées
Pour les équipes qui souhaitent une couche humaine aux côtés des contrôles de la plateforme, Stack Harbor opère les environnements dans le cadre de l’engagement Environnements infogérés. Cela couvre le travail opérationnel qui va au-delà de ce qu’exposent le tableau de bord et l’API — une migration de base de données délicate, un exercice de planification de capacité, un travail de tuning sur un plan de requête, ou la gestion d’incidents sur un environnement de production.
La plateforme et l’engagement d’opérations infogérées sont deux choses distinctes. Vous pouvez utiliser la plateforme sans l’engagement infogéré, et vous pouvez faire appel à l’engagement infogéré pour des opérations spécifiques sans céder le contrôle quotidien. Les deux sont conçus pour se combiner.
La suite
- Aperçu de la plateforme — le modèle complet côté développeur : environnements, couches, nœuds, cloudlets et les trois surfaces de contrôle.
- Aperçu de l’architecture — la grappe, l’orchestrateur et la couche infrastructure qui se trouvent sous chaque environnement.
- 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.