Scaleway propose une nouvelle gamme d’instances entièrement basée sur AMD EPYC allant de 4 à 48 cœurs, de 16 à 256 Go de mémoire, de 150 à 600 Go de stockage (SSD) et de 0,4 à 2 Gb/s de bande passante. Le tout, pour un tarif variant de 39 à 569 euros par mois, pouvant être facturé à l’heure. De fait, après avoir été un des premiers à miser sur des solutions ARM « BareMetal », Scaleway migre une bonne partie de son offre d’hébergement sur des serveurs EPYC d’AMD, au détriment d’Intel :
Je commence par créer une instance x86 dans Outscale qui hébergera le serveur Rancher 2.2.0 RC4 :
J’installe un client ZeroTier pour initier une liaison VPN qui servira à la jonction entre différentes instances. Le serveur Rancher est accessible via une adresse IP fournie via ZeroTier :
Je lance alors une instance GP1-XS à 4 coeurs, un stockage SSD de 150 Go et 16 Go de RAM dans Scaleway mettant en oeuvre ces processeurs AMD EPYC :
avec les extensions de virtualisation actives :
Propriétés spécifiques à cette génération de processeur AMD:
Et j’y installe Multipass que l’on a vu dans un précédent article :
sudo snap install multipass --beta --classic
Avec multipass je lance 3 machines virtuelles dans cette instance de Scaleway :
Ces VMs sont reliées au réseau VPN via ZeroTier :
Je retourne sur la console du serveur Rancher pour initier la création d’un cluster Kubernetes avec ces VMs imbriquées nouvellement créées :
Création du noeud maître du cluster Kubernetes :
et des deux autres noeuds du cluster :
Le cluster Kubernetes est actif :
J’ajoute l’ensemble des cataloguesde Charts fournis avec Helm :
et que l’on peut retrouver avec Bitnami via le Hub de KubeApps : https://hub.kubeapps.com/
J’active le monitoring au sein du Cluster Kubernetes via le portail du serveur Rancher avec Prometheus et Grafana :
Le dashboard Grafana devient accessible avec la visualisation d’un ensemble de métriques :
Il ne me reste plus qu’à effectuer le test No-Ops avec DevSpace. Pour rappel, NoOps (No Operations) — l’absence de personnel d’exploitation — est un concept selon lequel un environnement informatique a atteint un niveau d’automatisation et de virtualisation suffisant, par rapport à son infrastructure sous-jacente, pour que plus aucune équipe interne ne soit nécessaire à l’administration de l’infrastructure logicielle :
Le concept NoOps se distingue de celui de DevOps. En effet, dans ce dernier, la frontière entre les équipes de développement et d’exploitation devient floue, les membres de chaque équipe pouvant endosser certaines responsabilités de l’autre. Mais aucune des deux ne disparait. DevSpace permet de conteneuriser rapidement des applications existantes et d’utiliser les ressources comme les fichiers Dockerfile dans son projet. Le processus d’initialisation crée et vérifie tout ce qui a été créé. L’interface CLI de DevSpace est un outil open-source en ligne de commande qui permet de créer des espaces DevSpace et de les connecter à son de travail local :
Sous linux cela passe avec ces lignes de commande :
curl -s -L "https://github.com/devspace-cloud/devspace/releases/latest" | sed -nE 's!.*"([^"]*devspace-linux-amd64)".*!https://github.com\1!p' | xargs -n 1 curl -L -o devspace && chmod +x devspace;
sudo mv devspace /usr/local/bin;
Je récupère via Git les sources du dernier démonstrateur FranceConnect Particulier. DevSpace utilise Docker pour construire des images de containers, vous avez donc besoin de Docker localement pour initier DevSpace :
La construction de l’image Docker étant réalisée localement il n’y a plus qu’à la pousser ici vers le Docker Hub puis à la déployer dans un Pod au sein du cluster Kubernetes :
L’image apparaît au sein du Docker Hub avec ce tag :
et dans le portail du serveur Rancher avec ces deux Pods :
Sur la base de l’Ingress Controller fourni par défaut avec Nginx dans le cluster Kubernetes, je lance un accès sur la base d’un domaine Wildcard via xip.io
Le démonstrateur FCP est accessible :
En complément je peux initier un processus GitOps via Weave Cloud qui permet également de superviser le cluster Kubernetes :
Je lie mon projet dans Weave Cloud avec le dépôt Github et celui sur Docker Hub :
Une modification du Dockerfile dans Github entraîne la recréation d’une nouvelle image Docker du démonstrateur FCP ainsi que son redéploiement dans le cluster Kubernetes :
Je passe ici à la version 11 de l’image Alpine de Node.js :
Je réaccède au portail FCP mis à jour dans le cluster Rancher :
et les notifications sont faites dans un canal Slack préconfiguré :
L’informatique sans serveur est le rêve d’un développeur non seulement parce qu’il n’a plus besoin de s’inquiéter de l’endroit où le code va être exécuté, mais aussi parce qu’il n’a pas besoin d’un accès direct au système d’exploitation pour gérer ce code. Le résultat : Les développeurs peuvent se concentrer uniquement sur le codage, ce qu’ils font le mieux. Les deux principaux moteurs de l’approche NoOps selon une définition officielle, sont l’accroissement de l’automatisation IT et le Cloud computing. En poussant le concept à l’extrême, une organisation NoOps n’aurait aucun employé chargé de l’exploitation ; toutefois, divers autres systèmes méritent également le label « NoOps ». Par exemple, certains fournisseurs de solutions PaaS (Platform-as-a-Service) qualifient leurs offres de plateformes NoOps.
Quand à l’usage des processeurs AMD EPYC, il s’agit d’une offre qui occupe désormais le gros du terrain du catalogue de Scaleway, une claque pour Intel qui se retrouve marginalisé dans les solutions d’entrée de gamme, jusqu’à 8 cœurs, aux côtés d’ARM. Un tel choix est une première pour un service d’infrastructures Cloud.
A suivre ! …
Quelques liens à ce sujet :
