Développeurs/Mise à l’échelle

Mise à l’échelle

Une app peut tourner en plusieurs copies sur plusieurs serveurs. Vous pouvez le faire à la main sur des serveurs que vous avez déjà (multi-serveur), ou laisser Hostwolf ajouter et retirer des serveurs selon la charge CPU (mise à l’échelle automatique). Dans les deux cas, ne gardez pas d’état sur le disque de l’app : placez les données dans une base de données managée, accessible à chaque copie.

Multi-serveur#

Ajoutez un autre de vos serveurs d’applications à une app, puis déployez. Hostwolf fait le build de l’image une seule fois, démarre une copie sur chaque serveur, et le serveur principal de l’app répartit les requêtes entre toutes les copies en bonne santé. Si une copie s’arrête, les requêtes vont aux autres.

# The other server's destination (a Docker network on that server)
DEST=$(hw $API/servers/$OTHER_SERVER/destinations | jq -r '.[0].uuid')

hw -X POST $API/applications/$APP/destinations -d "{\"destination_uuid\": \"$DEST\"}"
hw -X POST $API/applications/$APP/start

hw $API/applications/$APP/destinations | jq   # primary + copies

$OTHER_SERVER est un server_uuid issu de GET /hostwolf/servers. Pour arrêter une copie sur un serveur :

hw -X DELETE $API/applications/$APP/destinations/$DEST

• Chaque serveur doit être l’un de vos serveurs d’applications Hostwolf. Le serveur principal ne peut pas être retiré ; c’est là que l’app est construite.
• Pendant un déploiement, chaque serveur redémarre sa copie, et les requêtes vont entre-temps aux copies disponibles.
• Les volumes sont propres à chaque serveur : chaque copie a le sien. Les données partagées ont leur place dans une base de données managée.
• Dans le SDK : applications.addServer(appUuid, serverUuid) ; dans MCP : add_app_server.

Mise à l’échelle automatique#

La mise à l’échelle automatique ajoute un serveur d’applications quand le CPU moyen de l’app reste élevé, et le retire quand la charge baisse. Les nouveaux serveurs sont placés dans la ville qui envoie le plus de trafic, ou dans les villes que vous autorisez. Chaque serveur ajouté a la même taille que le serveur principal de l’app.

hw $API/applications/$APP/autoscaling | jq

{
  "configured": false,
  "blocker": null,
  "policy": {
    "enabled": false, "min_copies": 1, "max_copies": 2, "monthly_cap_usd": 50,
    "allowed_cities": [], "scale_up_cpu": 60, "scale_up_minutes": 2,
    "scale_down_cpu": 15, "scale_down_minutes": 5, "cooldown_minutes": 3
  },
  "cities": [{"id": "vultr:fra", "city": "Frankfurt", "country": "DE", "monthly_price": 18.79, "hourly_price": 0.0257}],
  "status": null
}

Activez-la avec PUT. Les champs omis gardent leur valeur :

hw -X PUT $API/applications/$APP/autoscaling -d '{"enabled": true, "max_copies": 4, "monthly_cap_usd": 40}'

cities, dans la même réponse, liste les identifiants de région qu’accepte allowed_cities pour cette app, du moins cher au plus cher, avec le prix horaire d’un serveur à cet endroit. GET /hostwolf/regions?size=s liste toutes les villes avec le prix de chaque taille ; autoscaling: true signale les villes utilisables par la mise à l’échelle automatique.

Facturation : les serveurs ajoutés automatiquement coûtent le prix normal à l’heure (prix mensuel ÷ 730), ajouté à votre prochaine facture de serveur. Dès que les heures automatiques du mois atteignent monthly_cap_usd, plus aucun serveur n’est ajouté et les administrateurs de l’équipe reçoivent un e-mail. status.spend_usd indique les dépenses du mois jusqu’ici, et status.copies liste les copies en cours avec leur ville et leur CPU.

Quand elle ne peut pas être activée, blocker (et la réponse 409 à PUT) en donne la raison :

• le serveur principal de l’app n’est pas l’un de vos serveurs d’applications Hostwolf, ou n’est pas démarré ;
• l’app n’a pas de port défini (ports_exposes) ;
• votre équipe n’a pas d’abonnement serveur actif auquel ajouter les heures.

Un nouveau serveur met environ quatre minutes à rejoindre l’app ; définissez donc min_copies avant un lancement prévu.

Déploiements par push avec plusieurs copies#

Les déploiements par push et les déploiements depuis la CI fonctionnent de la même façon avec plusieurs copies : un seul build, puis chaque copie est mise à jour, y compris sur les serveurs ajoutés par la mise à l’échelle automatique.