Scaleway
Scaleway propose de l'hébergement hybride à base de virtualisation et de serveurs à haute densité, dans la droite ligne de leur maintenant célèbre Dédibox. Ils proposent différentes combinaisons de serveurs physique ou virtualisé, X86, Arm et Arm64. Les serveurs vont de tout petit à gros, sans pour autant brimer les premiers, ce qui change clairement des offres Cloud à l'américaine.
API et Terraform
Leur vraie force est une API distante propre et un excellent outil en ligne de commandes. Cette API, bien documenté avec l'aide de Swagger, et magnifiquement illustré par un ensemble de modules Terraform. Terraform étant un outil de gestion d'infrastructure de type "Infrastructure as code" : on décrit ce que l'on souhaite, on commit, Terraform agit pour que ça le devienne.
Ah, la liberté du terraform apply, terraform destroy sur des serveurs à 0.006 € de l'heure!
Ansible
Ansible est un outil de provisioning sans agent, lui aussi "Infrastructure as code", mais la couche au-dessus Terraform, quand il faut installer et configurer la machine en SSH.
L'intégration d'Ansible avec Scaleway est un peu plus spartiate que celle de Terraform, mais bon, Ansible reste une grosse télécommande SSH, et la jointure avec Scaleway se fait via la notion d'Dynamic Inventory.
Ce n'est pas compliqué, une version fonctionnelle est fournie : scw_ansible, donc, forkons et patchons, histoire d'avoir quelque chose d'agréable à utiliser.
Gestion des serveurs privés
Scaleway n'utilise pas de VLAN, mais tout un ensemble de sous réseau avec du firewalling simple, et un gros NAT devant, pour rediriger une IP publique vers un de vos serveurs. Il est tout à fait possible d'utiliser un bastion en SSH (passer par une machine publique pour atteindre une machine privée, derrière). Ça tombe bien, Ansible le gère très bien.
Uniformiser l'usage des tags avec les autres fournisseurs de Cloud
Ansible ne documente pas trop la création dynamique des groupes en fonction des tags des serveurs, mais comme c'est implémenté de manière homogène pour AWS et GCP, autant considérer que c'est la convetion.
Les serveurs ont des tags, et ces tags vont permettre de former des groupes avec une convention de nommage. On va ensuite pouvoir appliquer des roles sur ces groups. La convention est simple, pour le tag toto, on va créer le group tag_toto.
Configuration par projet et isolation des différents projets
Un même playbook Ansible pourra être utilisé plusieurs fois sur différent groupe de serveurs, pour différents clients par exemple.
Coté Scaleway, c'est plus surprenant. Il existe une notion d'organisation, et, pour l'instant, il n'en existe qu'une par compte. Donc, pour isoler, il faut créer plusieurs comptes (votre comptable va adorer), ou former un gros tas et voir comment bricoler.
Le code original de scw_ansible utilise la notion de tag préfixé par environment: et refuse de lister une machine qui n'en a pas. Autant suivre cette convention et utiliser environment:toto pour isoler les machines du projet toto. Coté Ansible, on précisera que l'on souhaite l'inventaire de l'environement toto.
Techniquement, ça marche bien, mais j'ai hâte de pouvoir gérer ça proprement avec des organisations distinctes et des tokens d'authentification restreinte à une seule organisation.
Normalisation des noms de machines
Quand on crée une machine Scaleway, on peut la nommer un peu comme on veut. Par contre, son hostname, lui, est plus contraint, et est déterminé en appliquant une règle tacite. Toto Db va devenir toto-db. Autant suivre cette convention pour ne pas perdre Ansible avec des noms farfelus.
Accéder aux machines sans IPv4 en IPv6
Scaleway permet d'avoir des machines sans IPv4 public. Pour une Db par exemple, ça parait sain, tant qu'elle est accessible en privé. Deux soucis, le réseau privé n'est pas restreint à votre compte, mais partagé entre tous les utilisateurs Scaleway, il n'est donc pas super privé. Il faut donc faire le ménage en mettant des rules dans des security group. Du firewalling, quoi.
Le second souci est qu'une machine sans IP n'a pas accès à Internet. Je comprends l'intérêt qu'Internet n'y accède pas, mais dans l'autre sens, c'est frustrant de ne pas pouvoir faire d'apt-get. Donc, pour ça, il faut faire le fou avec un proxy Socks, chose que gère bien apt et openssh, mais ça reste de la brimade difficilement justifiable.
Heureusement, il existe une solution simple : coller une IPv6 à son serveur. Comme ça, la machine peut sortir, et, pour peu que votre connexion gère l'IPv6, vous pouvez y accéder directement. Le NAT avec une IPv4 flottante reste bien évidement une option sage pour votre frontend.
Petite blague, le serveur C1, l'ARM premier prix (un raspberry Pi dans un rack, j'imagine), ne gère pas l'IPv6. Le reste de l'offre le gère très bien.
Ah tiens, je n'ai pas encore fait ce patch.
