Je loue des Virtual Private Server (VPS) chez Scaleway depuis 2016 et j'en ai toujours été globalement satisfait. Les performances sont correctes et c'est un hébergeur qui malgré ses tarifs lowcost a su prendre le virage du Cloud en ajoutant toujours plus de services indépendants, et en proposant une bonne intégration avec Terraform.
Et puis les choses ont changé:
- L'été 2020, Scaleway a augmenté ses tarifs. Moi qui utilisait les instances DEV1-S, cela se traduisit par +40% !
- A l'automne 2020, Scaleway a mis fin à la limite mensuelle. De base, la facturation se faisait à l'heure, mais au delà d'un certain seuil le tarif était bloqué à une valeur fixe (comme une sorte de forfait au mois). Ce n'est désormais plus le cas.
Au final, le DEV1-S que je payais 2,99€ HT / mois me coûte maintenant 7,30€ HT / mois soit une augmentation de +144%, aïe.
Puisque mes besoins sont croissants (deux nouveaux VPS à venir) j'ai décidé de regarder ce qui se faisait à côté, et je suis tombé sur Hetzner qui jouit d'une réputation plutôt correcte tout en proposant des tarifs lowcost. Comparons les prix :
- 2 vcpu, 2GB de RAM, 20GB stockage: Hetzner CX11 (2,96€ / month), Scaleway DEV1-S (7,30€ / month).
- 4 vcpu, 8GB de RAM, 80GB stockage: Hetzner CPX31 (14,76€ / month), Scaleway DEV1-L (29,20€ / month).
La migration a donc commencé, le blog est maintenant hébergé chez Hetzner (toujours en Kubernetes) à Helsinki.
On dirait le titre d'un WTC mais ce n'est pas le cas, c'est plutôt un bug à la con qui m'a bloqué toute une soirée.
Je fais tourner mon blog et d'autres sites chez Scaleway, sur un VC1S avec Docker (debian 9 + installation custom). Je fais au plus simple avec docker-compose qui jusque là était satisfaisant pour mes besoins. Mais depuis quelques temps je songe à passer à la vitesse supérieure avec swarm, qui me permettra d'ajouter d'autres nodes et former un vrai cluster.
Après avoir mené une phase de tests en VM, j'ai décidé de me lancer et migrer sous swarm. Mais je me suis confronté à un bug énervant, impossible de publier des ports, par exemple:
$ docker network create -d overlay net-web
t1q2kzso3a5fnlkd0s8tvywid
$ docker service create --network net-web --publish 80:80 nginx
xl35ov6bkehabkx4547omrodj
overall progress: 1 out of 1 tasks
1/1: running [==================================================>]
verify: Service converged
$ telnet 127.0.0.1 80
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused
Connexion refusée, le port n'est donc pas publié :/
Cela m'a rendu fou car en machine virtuelle VirtualBox ou KVM ça fonctionne du premier coup, et la lecture de documentation ou divers blogs ont confirmé qu'il n'y avait pas plus de manipulations à faire, ça devrait juste marcher !
J'ai commencé à soupçonner Scaleway, et en faisant une recherche avec les bons mots clés je suis tombé sur ce blog et cette issue github.
Ben voilà, c'est bien un problème avec Scaleway, car leur architecture est un peu particulière. Les serveurs ou VM n'ont pas de grub, ce sont des nodes provisionnées à la volée en PXE, avec script de démarrage et kernel maison. Et il s'avère qu'avec ces deux bootscripts, ça ne marche pas:
- x86_64 4.10.8 std #1
- x86_64 4.10.8 docker #1
C'est con, car le premier est celui proposé par defaut, le second est celui vers lequel on s'oriente naturellement quand on veut faire fonctionner du Docker.
Voici donc le bon bootscript: x86_64 mainline 4.14.23 rev1.
Proposer un kernel custom est une sale habitude des hébergeurs, mais à 3€/mois le vps, peut-on vraiment se plaindre de Scaleway?