Stack Harbor PaaS combine deux technologies de conteneurs sous un seul modèle d’exploitation — conteneurs système et conteneurs applicatifs. Chacune est conçue pour une forme différente de charge de travail, mais la plateforme hérite des avantages des deux.
- Les conteneurs système sont la forme plus ancienne. Ils se comportent comme des machines virtuelles légères : avec état, centrés sur l’OS, capables d’exécuter plusieurs processus. Ils conviennent aux applications traditionnelles ou monolithiques et permettent de conserver les architectures, outils et configurations que vous exécuteriez autrement sur des VM. Les implémentations incluent LXC/LXD, OpenVZ, BSD jails, Linux vServer et autres.
- Les conteneurs applicatifs sont la forme plus récente, exécutant typiquement un seul processus par conteneur. Ils sont sans état et conçus pour la mise à l’échelle horizontale et l’infrastructure éphémère. Docker, containerd et CRI-O sont les implémentations les plus courantes. La plateforme utilise Docker.
La plupart des fournisseurs nuagiques exécutent les conteneurs applicatifs à l’intérieur d’une VM, ce qui ajoute un OS invité — mémoire, CPU et disque supplémentaires par conteneur. La plateforme évite cela : les conteneurs Docker s’exécutent à l’intérieur de conteneurs système sur un noyau d’hôte partagé, isolés mais sans la couche d’OS dupliquée.
La plateforme expose cinq modèles de déploiement de conteneurs. Choisissez celui qui correspond à votre charge de travail :
- Conteneurs gérés certifiés
- Serveurs privés virtuels (Elastic VPS)
- Conteneurs Docker personnalisés
- Docker Engine CE (Docker natif)
- Cluster Kubernetes
Conteneurs gérés certifiés
Le choix le plus courant. La plateforme livre des piles logicielles préconfigurées et gérées — serveurs applicatifs Java, PHP, Node.js, Ruby, Python, Go ; répartiteurs de charge (NGINX, HAProxy, Apache) ; bases de données gérées (MySQL, MariaDB, PostgreSQL, MongoDB, Redis, Memcached) — que vous composez en une topologie via l’assistant de topologie.
Ces piles sont testées et ajustées pour la plateforme. Elles obtiennent :
- Configuration adaptative aux ressources qui s’ajuste aux cloudlets alloués au conteneur.
- Installation et renouvellement automatisés des certificats SSL.
- Automatisation du déploiement applicatif via le gestionnaire de déploiement.
- Auto-clustering intégré pour les piles qui le prennent en charge.
- Livraison gérée des correctifs de sécurité.
C’est ce que vous voulez sauf si vous avez une raison spécifique de fournir votre propre image.
Serveurs privés virtuels (Elastic VPS)
Un conteneur système avec un OS nu — CentOS, Ubuntu ou Debian — et rien d’autre. L’accès root est fourni. Vous installez et configurez ce que vous voulez.
C’est ce qui se rapproche le plus d’une machine virtuelle sur la plateforme. C’est le bon choix pour les applications héritées qui doivent conserver leur configuration existante avec un minimum de changements, ou pour les charges de travail qui ne s’inscrivent pas naturellement dans les piles certifiées. Même s’il s’agit d’un OS vierge, la mise à l’échelle verticale et horizontale de la plateforme, les instantanés et le SSL s’appliquent toujours.
Conteneurs Docker personnalisés
Une image Docker — la vôtre ou n’importe quelle image publique — déployée à l’intérieur d’un conteneur système de la plateforme. Le système de fichiers de l’image Docker est décompressé à l’intérieur du runtime du conteneur système, ce qui signifie que le conteneur hérite de la plupart des fonctionnalités de la plateforme (mise à l’échelle verticale et horizontale, instantanés, gestionnaires de configuration et de journaux du tableau de bord).
Utilisez ceci quand les piles certifiées ne couvrent pas ce dont vous avez besoin. Vous choisissez l’image depuis Docker Hub, GitHub Container Registry, un registre privé ou n’importe où vos exécuteurs peuvent atteindre. L’opérabilité des images tierces est la responsabilité du mainteneur, pas de la plateforme — choisissez des images bien maintenues et vérifiez qu’elles se comportent correctement sous le modèle de conteneurs de la plateforme.
Docker Engine CE (Docker natif)
Un Docker Engine complet s’exécutant à l’intérieur d’un conteneur système, avec un outillage Docker natif. Utilisez-le quand vous voulez l’écosystème Docker lui-même plutôt qu’une application conteneurisée individuelle :
- Docker Engine — traite les manifestes Dockerfile ou exécute des images préconstruites.
- Docker Registry — stockage d’images publiques et privées.
- Docker Compose — applications multi-composants déclarées dans un seul fichier compose.
- Docker Swarm — plusieurs hôtes Docker joints en cluster.
La plateforme livre des solutions Docker Engine CE et Docker Swarm Cluster préempaquetées dans le Marketplace, toutes deux avec intégration de l’auto-clustering.
Cluster Kubernetes
Les conteneurs applicatifs peuvent aussi être gérés avec Kubernetes. L’implémentation Kubernetes de la plateforme automatise l’installation du cluster, la configuration et les mises à jour, et préintègre les services de cluster courants — Weave CNI, CoreDNS, Traefik et autres.
Choisissez Kubernetes lorsque votre application a été conçue pour Kubernetes dès le départ ou lorsque vous avez besoin de ses primitives spécifiques (déploiements, services, ingresses, demandes de volume persistant, espaces de noms). L’avantage d’exécuter Kubernetes via la plateforme est le modèle de ressources à l’usage : les nœuds se redimensionnent sans redémarrage, donc vous n’avez pas à surprovisionner pour éviter les problèmes de dimensionnement des conteneurs.