Le redimensionnement vertical sur Stack Harbor PaaS modifie la RAM et le CPU disponibles pour un conteneur sans le reconstruire. La plateforme réalloue dynamiquement les ressources en fonction de la charge — sans intervention manuelle ni redémarrage de l’application. Vous fixez un plafond, et la plateforme reste en dessous.
Cette page couvre la mécanique : l’unité d’allocation (cloudlets), les deux classes de cloudlets et la manière d’ajuster les limites depuis l’assistant de topologie.
Ce qui se redimensionne verticalement
Le redimensionnement vertical s’applique à tout conteneur d’un environnement — serveur d’applications, base de données, répartiteur, conteneur Docker personnalisé, VPS élastique, nœud de cache, nœud de build. Il opère sur place : la plateforme alloue davantage de ressources quand la charge augmente, puis les reprend quand elle redescend.
Cloudlets — l’unité d’allocation
Les ressources sont mesurées en cloudlets. Un cloudlet vaut 128 Mio de RAM et 200 MHz de CPU. Deux classes :
- Cloudlets réservés — capacité que vous engagez. Le conteneur y a toujours accès, et vous êtes facturé quel que soit l’usage réel. Le coût unitaire est plus bas que celui des cloudlets dynamiques.
- Cloudlets dynamiques — capacité dans laquelle le conteneur peut croître. Vous n’êtes facturé qu’à la consommation réelle.
Le redimensionnement vertical automatique opère dans le pool de cloudlets dynamiques. La limite dynamique que vous fixez sur une couche est le plafond de ce que la plateforme allouera — et le plafond de ce qui pourra vous être facturé si la charge le justifie. Le mélange réservés / dynamiques est le levier entre coût mensuel prévisible et capacité élastique.
Valeurs de cloudlets par défaut par pile
Chaque pile ajoutée à un environnement reçoit des valeurs par défaut raisonnables. Quelques exemples :
| Pile | Réservés | Limite dynamique |
|---|---|---|
| Tomcat, Jetty | 1 | 6 |
| TomEE | 1 | 8 |
| GlassFish | 6 | 16 |
| Apache, NGINX, répartiteur NGINX | 1 | 4 |
| NGINX-Ruby | 1 | 6 |
| Apache-Ruby, Apache-Python | 1 | 8 |
| Node.js | 4 | 8 |
| MySQL, MariaDB, PostgreSQL | 1 | 6 |
| Memcached | 1 | 4 |
| VPS | 1 | 16 |
| Maven | 1 | 16 |
Ce sont des points de départ. Utilisez les statistiques collectées automatiquement par la plateforme (visibles dans le tableau de bord) pour observer ce que votre application consomme réellement sur le mois écoulé, puis dimensionnez en conséquence.
Ajuster les limites
Ouvrez l’assistant de topologie de l’environnement et utilisez les curseurs de cloudlets dans la section Vertical Scaling du panneau central. Appliquez les changements.
Modifier la limite dynamique (le plafond haut) sur un serveur d’applications, une base de données ou un nœud de cache existant redémarre la couche. L’assistant affiche un avertissement avant la confirmation. La valeur réservée peut généralement être modifiée sans redémarrage, mais lisez l’avertissement de l’assistant avant d’appliquer.
Si la capacité d’un seul conteneur ne suffit plus — même à la limite maximale de cloudlets — c’est le signal que le redimensionnement vertical a atteint son rôle et qu’il faut passer à l’autre axe : ajouter des nœuds manuellement par redimensionnement horizontal, ou configurer des déclencheurs de mise à l’échelle horizontale automatique.
Pages connexes
- Redimensionnement horizontal — ajouter des nœuds quand un conteneur ne suffit plus.
- Redimensionnement horizontal automatique — ajout et retrait de nœuds pilotés par la charge.
- Conteneurs isolés — comment le redimensionnement vertical interagit avec les garanties d’isolation des conteneurs.