Comme vous le savez, j’utilise beaucoup le cloud en particulier AWS dont je vous ai déjà parlé au travers de nombreux posts de blog, mais je travaille aussi beaucoup avec Scaleway qui à mon sens est une bonne alternative côté français. Malgré tout, j’ai pas mal de services qui me manquent quand je passe sur Scaleway. J’avais abordé brièvement ce problème dans l’article sur l’hégémonie du cloud, je guette donc leurs arrivés. Ce qui tombe bien, car l’un des services que j’attendais le plus, avec IAM est sorti : il s’agit des réseaux privés, très souvent abrégés par l’acronyme Virtual Private Network.

Les plus assidus avaient remarqué qu’avant cette offre vous aviez déjà des adresses privées notamment sur les instances Scaleway, mais vous n’aviez aucun moyen de contrôler le réseau, donc il était très compliqué de l’utiliser efficacement. De plus, cette nouvelle brique va introduire plusieurs fonctionnalités annexes, que nous allons découvrir.

Découverte de l’offre

La promesse

Techniquement, l’offre vous permet de créer des réseaux privés de niveau 2 dans la fameuse couche OSI. Ce qui nous donne la possibilité d’interconnecter des ressources, machines et services localement sans repasser sur internet ce qui est quand même plus sympa. À la découverte de la documentation, je suis assez agréablement surpris, la plupart des services Scaleway sont supportés, les instances, les load balancers et les bases de données, pour ce qui est de Kapsule leurs offres Kubernetes ce n’est malheureusement pas encore disponible.

La bonne surprise, c’est que l’ensemble des ressources est déjà exploitable par API et par extension sous Terraform. Je me permets d’insister là dessus, si vous proposez un service cloud et que celui-ci n’est pas disponible par API et par Terraform, je considère qu’il n’est pas prêt. Gérer des éléments par le biais d’une interface graphique est aujourd’hui contre-productif.

Petite déception pour moi, il s’agit d’une ressource monozone, contrairement aux VPC sur AWS par exemple. Ce qui va vous demander un gros effort d’intégration afin d’interconnecter plusieurs régions, aucune solution native n’étant prévue par Scaleway pour l’instant. J’ai néanmoins vu qu’un futur service Direct connect est en beta fermée, celui-ci a pour objectif d’offrir un moyen simple de relier les VPC à d’autres réseaux privés.

Dans la catégorie des bonnes nouvelles, la documentation affirme aussi qu’il est possible d’utiliser des IPv6 pour les VPC, mais je ne vais pas le tester dans le cadre de cet article.

Côté technique

Techniquement, l’offre se compose en réalité de 2 ressources que l’ont peut gérer :

• Le VPC qui est tout simplement la représentation de notre VLAN et c’est sur cette ressource que nous allons rattacher les différents objets que vous voulez mettre dans votre réseau privé, machine virtuelle, base de données managées, etc. Pour les moins fan de réseau d’entre vous ça équivaut à votre switch/hub que vous avez chez vous pour interconnecter vos machines. À noter, cette partie n’est pas facturée.
• Ensuite vient le second objet est la Public Gateway, qui a pour but de gérer l’adressage interne au réseau des machines (DHCP), le DNS et globalement le translation des IP (NAT) qui est nécessaire pour permettre d’avoir accès à internet à partir du réseau privé. Cette ressource est donc attachée à votre réseau privé et contrairement à lui, celle-ci est soumise à facturation. Pour continuer l’analogie précédente très simplifiée, c’est l’équivalant de la box de votre fournisseur internet chez vous.

Vous avez bien sûr la possibilité de personnaliser la configuration du réseau en définissant votre CIDR et le DHCP/NAT. Donc de quoi bien s’amuser !

Petit lab découverte

Sur le papier c’est une offre au top il faut l’avouer, mais entre la théorie et la pratique il y a un monde donc allons mettre tout ça à l’épreuve.

Pour tester ça plutôt que créer des ressources au hasard on va provisionner une petite infrastructure Nextcloud, histoire de voir comment ça se passe.

Globalement au final cela nous donne cette architecture :

C’est assez simple, on se repose sur les services managés pour la base de données (MySQL) et aussi pour le load balancer, pour le reste nous utiliserons 2 instances :

• Un bastion qui servira d’instance de rebond, même si cela n’est pas nécessaire ça va nous permettre de creuser un peu le fonctionnement du réseau
• Une instance Nextcloud des plus classiques qui hébergera notre serveur web, elle sera uniquement exposée en local à travers d’un VPC.

La configuration Terraform de base

J’utiliserai bien sûr Terraform qui est le standard pour faire de l’infra as code. Afin de simplifier le déploiement des différents niveaux, réseau, données et instance, j’ai découpé le tout dans des layers dont l’exécution est orchestrée avec Terragrunt, qui va surtout avoir pour but principal de gérer les dépendances.

Comme à chaque fois sur ce blog, vous pouvez tester par vous même, le code est entièrement disponible sur ce répertoire Github.

Pour la configuration du provider rien de vraiment nouveau, tout fonctionne comme décrit sur la documentation de celui-ci.

terraform {
  required_providers {
    scaleway = {
      source = "scaleway/scaleway"
      version = "2.2.1-rc.1"
    }
  }
}

provider "scaleway" {
  profile = "perso"
}

À noter que pour l’authentification j’utilise le système de profile, pour cela trois petites étapes :

• Installer la cli Scaleway
• Créer vos tokens dans la console.
• Éditez le fichier de configuration $HOME/.config/scw/config.yaml en le complétant avec vos tokens comme ci-dessous:

perso: #Mettez le non de profile que vous voulez
  myProfile:
    access_key: xxxxxxxxxxxxxxxxxxxx
    secret_key: xxxxxxxx-xxx-xxxx-xxxx-xxxxxxxxxxx
    default_organization_id: xxxxxxxx-xxx-xxxx-xxxx-xxxxxxxxxxx 
    default_project_id: xxxxxxxx-xxx-xxxx-xxxx-xxxxxxxxxxx
    default_zone: fr-par-2
    default_region: fr-par
    api_url: https://api.scaleway.com
    insecure: false

Les ressources de mon infrastructure ayant une grande interdépendance et aussi pour simplifier la maintenance, j’ai décidé de les séparer en 5 parties : vpc/internet gateway, base de données, instances, load balancer/PAT.

Création du VPC

Pour la ressource VPC en soi, c’est assez simple, on doit juste la nommer :

resource "scaleway_vpc_private_network" "private" {
    name = "private-subnet"
    tags = var.default_tags
}

La partie internet gateway est bien plus verbeuse et demande de créer divers éléments :

• L’IP publique

resource "scaleway_vpc_public_gateway_ip" "private" {
  zone = var.az
  tags = var.default_tags
}

• Le DHCP

Ici, je laisse l’ensemble des options par défaut et le DHCP propager les routes par défaut. Néanmoins si vous le souhaitez, vous pouvez empêcher le DHCP de les pousser, ce qui vous demandera de gérer de votre côté les problématiques d’adressage et de routage. Vous n’avez malheureusement pas la possibilité de personnaliser les routes que le DHCP ajoute, dans les cas complexes là aussi vous serez dans l’obligation de tout faire manuellement. Dans tous les cas dans l’état actuel des choses je vous déconseille de faire de l’attribution manuelle.

resource "scaleway_vpc_public_gateway_dhcp" "private" {
  zone = var.az
  subnet = var.network_private
}

• La gateway

On créer l’internet gateway à lequel on attache l’IP publique et le DHCP.

resource "scaleway_vpc_public_gateway" "private" {
  name  = var.ig_name
  type  = var.ig_type
  ip_id = scaleway_vpc_public_gateway_ip.private.id
}

resource "scaleway_vpc_gateway_network" "private" {
  gateway_id         = scaleway_vpc_public_gateway.private.id
  private_network_id = data.scaleway_vpc_private_network.private.id
  dhcp_id            = scaleway_vpc_public_gateway_dhcp.private.id
}

Les ressources ne sont pas très complexes, il est néanmoins à noter que j’ai séparé la création du VPC et de la gateway dans le code afin d’éviter les contraintes de dépendances qui peuvent arriver. Le point qui pose problème à mon sens est plus dans la limitation des options de personnalisation, notamment sur la table de routage comme expliqué plus tôt.

Création de la base de données

Notre socle réseaux étant créé on peut enfin y déployer nos ressources. Je commence par la base de données celle-ci étant l’élément demandant le plus de temps avant d’être disponible. Le code reste très basique, on y ajoute juste un bloc :

private_network {
  ip_net = "10.1.0.200/24" #pool high
  pn_id  = data.scaleway_vpc_private_network.this.id
}

Dans mon code, j’utilise des datasources afin de récupérer les informations sur les ressources créer dans les précédents layers, j’aurai aussi pu utiliser les remotes states.

Création de la partie instance

Pour la partie machine, il n’y a pas grand-chose à dire de plus que précédemment on ajoute à nouveau un bloc private_network à la ressource scaleway_instance_server.

Il y a par contre un élément assez étonnant je dois avouer, les security groups qui permettre de filtrer le trafic réseau sur les instances ainsi que les ACL des bases de données ne s’appliquent pas sur le VPC. Si jamais vous avez une machine sur un VPC elle pourra contacter les autres. Pour ajouter de l’isolation, vous devrez soit utiliser un pare-feu système, soit séparer les ressources sur différents VPC.

Load balancer & PAT

On a bien toutes nos ressources, par contre pour l’instant il n’est pas possible d’y accéder en effet elles sont placées sur un VPC donc privé. Nous allons avoir besoin de nous y connecter par ssh pour l’administration et en web pour l’instance Nextcloud, pour cela on va utiliser les deux solutions principales permises par les VPC :

• Un load balancer

Scaleway permet de créer des load balancer managés et surtout de les utiliser dans un VPC. Pour cela il suffit d’écrire un bloc private_network et de donner en backend notre machine Nextcloud :

resource "scaleway_lb" "this" {
  ip_id = scaleway_lb_ip.lb.id
  name  = "Nextcloud"
  type  = "LB-S"
  tags  = var.default_tags
  private_network {
    private_network_id = data.scaleway_vpc_private_network.private.id
    dhcp_config        = true
  }
}

resource "scaleway_lb_backend" "this" {
  lb_id            = scaleway_lb.this.id
  name             = "Nextcloud"
  forward_protocol = "http"
  forward_port     = "80"
  server_ips       = ["${data.external.dhcp_compute.result.ip}"]
}

• PAT

Il nous faut ensuite une possibilité d’accès au bastion afin de se connecter en SSH, pour cela nous allons créer une règle PAT. Cette règle va permettre de diriger le trafic reçu sur un port de notre NAT Gateway, ce qui est un des rôles de l’internet gateway vers le port d’une machine, ici notre bastion. Le code est relativement trivial.

resource "scaleway_vpc_public_gateway_pat_rule" "main" {
  gateway_id   = data.scaleway_vpc_public_gateway.this.id
  private_ip   = data.external.dhcp_bastion.result.ip
  private_port = 22
  public_port  = 22
  protocol     = "both"
}

Cette partie regroupant le load balancer et la configuration du PAT n’est pas particulièrement complexe néanmoins elle comporte une petite subtilité. En effet je vous expliquais précédemment que nous utilisions les fonctionnalités DHCP par défaut, nous ne connaissons pas les IP des machines dans Terraform. Pour résoudre ce problème le plus simple serais d’avoir une data source qui nous permettent de consulter les baux DHCP, malheureusement celle-ci n’existe pas. J’ai donc créé un script bash que j’exécute ensuite avec Terraform pour récupérer les IP des machines.

Le script au travers de la cli Scaleway collecte les adressages du DHCP et les affiches sous forme de json, plus facilement exploitable dans le Terraform.

all_data=`scw vpc-gw dhcp-entry list | grep $1`
arr=($all_data)
echo "{\"id\": \"${arr[0]}\",\"gateway\": \"${arr[1]}\",\"ip\": \"${arr[2]}\",\"mac\": \"${arr[3]}\",\"hostname\": \"${arr[4]}\",\"type\": \"${arr[5]}\"}"

Il ne reste plus qu’à appeler le code via le provider external avec en option le nom de la machine défini précédemment.

data "external" "dhcp_bastion" {
  program = ["bash", "./../bin/get_ip_from_hostname.sh", "bastion"]
}

Grâce à ce système, je peux retrouver les IP et d’autres informations de mes machines à partir de mon code Terraform.

Cette solution fonctionne bien et dans un cas normal il y a peu de chance que le DHCP change les IP. Néanmoins, il ne s’agit clairement pas d’une méthode adaptée pour de la production ou autre, où il serait trop risqué d’utiliser cette approche.

Voilà notre infrastructure et donc créé et disponible sur l’adresse IP du load balancer. Vous avez juste à compléter le formulaire et attendre quelques minutes avant d’avoir cette super page d’accueil :

Côté performance

Notre infrastructure fonctionne plutôt bien avec l’ensemble de nos ressources. On peut néanmoins voir à quoi s’attendre niveau réseau. En effet au-delà de la sécurité, les performances étaient aussi une des grandes promesses de ce service VPC, pour rappel avant vous étiez obligé de repasser par les endpoints internet.

Pour cela j’ai effectué un test avec la commande iperf exécutée sur les deux serveurs (Nextcloud et Bastion). J’ai utilisé les instances les plus petites disponibles.

Les résultats sont conformes à ce que j’espérai, je pense qu’en termes de performance vers internet par contre le type d’instance utilisé par l’internet gateway a bien plus d’impact.

Connecting to host 10.1.0.250, port 434
[  5] local 10.1.0.251 port 44984 connected to 10.1.0.250 port 434
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   194 MBytes  1.63 Gbits/sec  891    744 KBytes       
[  5]   1.00-2.00   sec   208 MBytes  1.74 Gbits/sec  717    676 KBytes       
[  5]   2.00-3.00   sec   175 MBytes  1.47 Gbits/sec  245    822 KBytes       
[  5]   3.00-4.00   sec   196 MBytes  1.65 Gbits/sec  1006    628 KBytes       
[  5]   4.00-5.00   sec   212 MBytes  1.78 Gbits/sec  105    834 KBytes       
[  5]   5.00-6.00   sec   214 MBytes  1.79 Gbits/sec  123    785 KBytes       
[  5]   6.00-7.00   sec   215 MBytes  1.80 Gbits/sec  325    665 KBytes       
[  5]   7.00-8.00   sec   209 MBytes  1.75 Gbits/sec  517    607 KBytes       
[  5]   8.00-9.00   sec   210 MBytes  1.76 Gbits/sec   92    814 KBytes       
[  5]   9.00-10.00  sec   165 MBytes  1.38 Gbits/sec  298    812 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  1.95 GBytes  1.68 Gbits/sec  4319             sender
[  5]   0.00-10.00  sec  1.95 GBytes  1.67 Gbits/sec                  receiver

iperf Done.

Le service tant attendu ?

Comme je le disais au début de l’article, c’est surement le service que j’attendais le plus chez Scaleway et il y a du bon et du moins bon.

On l’a vu, le code et l’intégration sont plutôt simples et clairs, la quasi-totalité des services est compatible avec, même si à l’heure de ce test l’utilisation avec certaines ressources sont encore marquées en beta et surtout sont disponibles au travers d’API et du provider Terraform. Malheureusement, la documentation de Terraform est très légère et je vous conseille fortement de préférer celle de l’API plus à jour et surtout les options de personnalisation sont très restreintes.

Travaillant avec AWS, je sais qu’il n’est pas possible d’avoir le même niveau de profondeur au vu de la maturité, mais pour moi on est sur une première version que de ce côté est trop limitée, notamment sur le multirégion. Ce n’est pas la première fois avec Scaleway, mais je ressens une sorte de frustration d’avoir le service que j’espérais, mais pas complet dans une V1 qui ne demande qu’à être améliorée.

Vient ensuite un point que je n’ai pas abordé dans l’article, l’utilisation avec la console. Scaleway a dès le départ souhaité faire une interface, simple, efficace, ce qui est une bonne chose, un choix d’ailleurs fait aussi par Nuage. Dans le cas des VPC par contre, la console web montre souvent ces limites, notamment sur le paramétrage et l’affichage des informations détaillées de la machine sur le réseau, par exemple si vous cherchez l’IP local d’une instance vous ne la trouverez pas dans cette même partie, mais dans internet gateway puis DHCP puis voir l’adressage. En soit, ce n’est pas grave on utilise en majorité du code ou l’API de nos jours, mais malheureusement traduit peut-être un manque de communication et de vision entre les équipes pour intégrer de manière homogène les solutions.

Il est part contre clair qu’avec les VPC on gagne en performance et l’on réduit le risque en termes de sécurité, même si là encore je suis un peu perdu sur le choix de ne pas permettre le filtrage par les security groups dans un VPC.

Scaleway avance dans la bonne direction, il me semble d’ailleurs avoir vu que l’IAM arrive bientôt en faisant un acteur solide du cloud. De plus en plus régulièrement, je me dis que je peux faire certains projets sur leurs clouds, même si dans beaucoup de cas les solutions sont encore trop limitées pour ne pas demander de gros sacrifices en termes de fonctionnalités.

Comme toujours, je vous donne mon ressenti la fonctionnalité. Je vous invite à le tester par vous-même et je vous fournis l’ensemble du code sur Github : lien.

Head photo by Luca Bravo on Unsplash