Metal as a Service on Zwindler's Reflection

Sidero Omni - Talos Linux sur Oracle Cloud (en free tier)

Sat, 04 Jan 2025 18:00:00 +0200

Fun fact, le 4 janvier 2024 (il y a tout pile un an donc), mon premier article de l’année était sur Maas. Commencer 2025, le même jour, avec un autre article à propos d’une solution qui vise à automatiser de l’infra, notamment en bare metal, c’est drôle :)

Contexte

J’ai gagné !!!

Je joue de temps en temps à des jeux sur les réseaux sociaux (plus rarement maintenant) et il m’arrive aussi de faire des concours parfois en conférence.

Et là, j’ai gagné un an d’abonnement au SaaS de Sidero Labs (les créateurs de Talos Linux), Omni.

Pour celles et ceux qui se demandent, Omni est une solution de déploiement de clusters Kubernetes qui permet d’orchestrer des serveurs sous Talos, un système d’exploitation Linux minimaliste et sécurisé dédié à Kubernetes. Pour ce qui est de Talos, on en reparlera certainement dans de prochains articles.

Quel rapport avec Oracle Cloud ?

Gagner, c’est bien, ça fait toujours plaisir. Mais j’en fais quoi, désormais, de ce SaaS ?

La première idée qui vient à l’esprit est de commander un serveur dédié quelque part et d’installer Talos dessus (avec un ISO généré par Omni), ou alors de faire la même chose, mais d’installer un hyperviseur, puis de créer des VMs Talos Linux (là encore, grâce à Omni).

Mais je suis ~~radin~~ un éternel économe et j’ai vu qu’Oracle Cloud Infrastructure (OCI) est supporté par Talos Linux et Omni, et donc j’ai voulu essayer.

Pour ceux qui ne connaissent pas OCI, j’ai fait une série d’articles en 2023 pour expliquer comment créer un cluster gratuit avec kubeadm sur le free tier (assez généreux) :

On va donc réutiliser le free tier ici, mais pour déployer et gérer des clusters avec Omni.

Note : vous pouvez les relire, mais j’ai fait mieux depuis car j’ai réussi à intégrer les machines du free tier DANS un cluster Kubernetes managé, bien plus agréable à utiliser. Stay tuned pour l’article à venir ;).

Prérequis

Pour Talos Linux sur Oracle Cloud Infrastructure (OCI) et plus spécifiquement intégrer les machines à Omni, il y a quelques étapes de configuration nécessaires.

Note : ce tutoriel s’appuie partiellement sur la documentation officielle de Talos Linux, adaptée pour Omni et avec des détails complémentaires sur Oracle Cloud Infrastructure.

Je pars du principe que vous avez déjà un compte sur Oracle Cloud Infrastructure, ainsi que les binaires talosctl et la CLI oci. Sinon un petit :

brew update && brew install oci-cli talosctl

Authentifiez-vous avec l’outil CLI :

oci session authenticate

Lorsque l’authentification est demandée, choisissez la région correspondant à votre localisation (par exemple, eu-paris-1). Une fois terminé, vous verrez un message de confirmation dans le navigateur et il faudra donner un petit nom mignon au profil pour oci dans le terminal et valider.

Récupération du compartment ID

Un des concepts intéressants d’Oracle Cloud Infrastructure (qu’on retrouve chez d’autres cloud providers sous une forme ou une autre) est la notion de “compartment”. Grosso modo, les ressources sont stockées dans des “compartiments” (la traduction littérale fonctionne pour comprendre) pour organiser les ressources.

On peut travailler dans le “root” compartment, mais c’est quand même plus propre d’en créer un spécifique pour l’occasion.

Exemple d’OCID :

ocid1.compartment.oc1..aaaaaaaayrmiilkb5m2b7never345435gonna345give87978you12upu6ifoh6csihm4awsjq

Préparation de l’environnement Oracle Cloud

Une fois qu’on a ça, on va utiliser la CLI pour créer tous les trucs dont on va avoir besoin pour que nos machines virtuelles puissent s’enregistrer sur le SaaS d’omni.

Création d’un VCN (Virtual Cloud Network) et configuration réseau :

export cidr_block=10.0.0.0/16
export subnet_block=10.0.0.0/24
export compartment_id=<votre_ocid_compartment>

Créer le VCN et le sous-réseau :

export vcn_id=$(oci network vcn create --cidr-block $cidr_block --display-name talos-example --compartment-id $compartment_id --query data.id --raw-output)
export rt_id=$(oci network subnet create --cidr-block $subnet_block --display-name kubernetes --compartment-id $compartment_id --vcn-id $vcn_id --query data.route-table-id --raw-output)

À l’issue de la 2e commande, on récupère non pas l’OCID du subnet (on n’en a pas besoin), mais celui de la “Route Table”, un sous-composant du subnet, qui permet de définir la table de routage du subnet qu’on vient de créer.

Configurer une passerelle (Internet Gateway) :

export ig_id=$(oci network internet-gateway create --compartment-id $compartment_id --is-enabled true --vcn-id $vcn_id --query data.id --raw-output)

Ajouter une règle de routage (à notre route table) pour permettre l’accès Internet :

oci network route-table update --rt-id $rt_id --route-rules "[{\"cidrBlock\":\"0.0.0.0/0\",\"networkEntityId\":\"$ig_id\"}]" --force

Désactiver les règles par défaut du pare-feu (YOLO) :

export sl_id=$(oci network vcn list --compartment-id $compartment_id --query 'data[0]."default-security-list-id"' --raw-output)

À partir de là, on a la partie réseau fonctionnelle, prête à accueillir nos machines !

Mais ce n’est pas terminé :-/

Chez Oracle Cloud Infrastructure, il est possible de booter une liste d’OS prédéfinis, mais dans notre cas, Talos Linux n’est pas dans la liste.

Heureusement, Omni va nous générer un disque virtuel préconfiguré avec nos credentials, qui va nous permettre d’enrôler des serveurs Talos Linux à notre SaaS Omni dès le premier boot. Classe 😎.

On se connecte donc à notre interface Omni et on télécharge l’image de Talos Linux adaptée :

Ici, j’ai choisi la version 1.9.1 (la toute dernière car on aime le danger), pour architecture amd64. Je récupère l’image oracle-amd64-omni-zwindler-v1.9.1.qcow2.xz que je décompresse :

xz --decompress ./oracle-amd64-omni-zwindler-v1.9.1.qcow2.xz

Rappel : le free tier d’OCI consiste en :

2 machines amd64 de 1 oCPU (= vCPU) et 1 Go de RAM chacune
une combinaison flexible d’instances arm64 ayant 1 x n oCPU et 6 x n Go, tant que le total n’excède pas 4 oCPU (et donc 6x4 = 24 Go de RAM).

Sur OCI, il existe plusieurs formats pour importer des disques. Le plus simple est d’utiliser le format “maison” d’OCI (le .oci, extra original comme nom), qui se compose d’un fichier de métadonnées et du QCOW2.

Créez le fichier de métadonnées pour l’importation, avec la shape VM.Standard.E2.1.Micro car on a une image amd64 (sinon c’est VM.Standard.A1.Flex) :

cat > image_metadata.json << EOF
{
 "version": 2,
 "externalLaunchOptions": {
 "firmware": "UEFI_64",
 "networkType": "PARAVIRTUALIZED",
 "bootVolumeType": "PARAVIRTUALIZED",
 "remoteDataVolumeType": "PARAVIRTUALIZED",
 "localDataVolumeType": "PARAVIRTUALIZED",
 "launchOptionsSource": "PARAVIRTUALIZED",
 "pvAttachmentVersion": 2,
 "pvEncryptionInTransitEnabled": true,
 "consistentVolumeNamingEnabled": true
 },
 "imageCapabilityData": null,
 "imageCapsFormatVersion": null,
 "operatingSystem": "Talos",
 "operatingSystemVersion": "1.9.1",
 "additionalMetadata": {
 "shapeCompatibilities": [
 {
 "internalShapeName": "VM.Standard.E2.1.Micro",
 "ocpuConstraints": null,
 "memoryConstraints": null
 }
 ]
 }
}
EOF

Et créez ensuite l’image pour l’importation :

qemu-img convert -f raw -O qcow2 oracle-amd64-omni-zwindler-v1.9.1.raw oracle-amd64-omni-zwindler-v1.9.1.qcow2
tar zcf oracle-amd64-omni-zwindler-v1.9.1.oci oracle-amd64-omni-zwindler-v1.9.1.qcow2 image_metadata.json

Importation de l’image sur Oracle Cloud

On a le fichier prêt à être uploadé… mais on l’uploade où ??

Pas de chance, cette étape se fait en 2 parties. D’abord, il faut uploader le fichier .oci sur un bucket. C’est assez simple à faire dans l’UI (on aurait aussi pu le faire en CLI) :

Créez un bucket dans la section Storage pour uploader l’image compressée.
Uploadez l’image (oracle-amd64-omni-zwindler-v1.9.1.oci) dans ce bucket.

Deuxième étape, on transforme le fichier en “Custom images” (dans la section Compute) :

Cette étape est bizarrement assez longue, l’image qui ne fait que 100 Mo a pris 10 minutes à chaque essai que j’ai fait pour l’instant.

Création de la VM

Une fois l’image importée, on peut maintenant utiliser notre image customisée par Omni pour booter nos machines free tier.

Je l’ai fait là aussi via l’interface OCI, mais là encore, on pourrait le faire en CLI.

Quelques secondes après le boot, elle apparaît dans l’UI d’Omni et peut être ajoutée à un cluster.

Have fun !!

Addendum : est-ce que c’est vraiment gratuit ?

Oui…-ish.

En théorie, les machines sont gratuites (forever free comme ils disent). Mais attention, plein de petits trucs peuvent être payants.

Par exemple, le bucket sur lequel on a uploadé le QCOW2/.oci est très probablement payant. Idem pour la custom image, qui est facturée comme 1 Go de stockage (selon l’UI, je n’ai pas encore la facture LOL).

Si vous mettez les VMs derrière un load balancer (il n’y a pas de raison que vous le fassiez ici), attention, seul le LB “non flexible” bridé à 10 Mbps est gratuit (et un seul).

Et si comme moi, vous avez déjà 4 disques de 50 Go, le stockage de l’OS est payant (1,85€ / mois).

Bref, vous l’aurez compris, c’est comme souvent dans le cloud, rien n’est vraiment gratuit et il faut bien lire tous les petits caractères.

Déployer un hyperviseur VMware ESXi avec MAAS

Mon, 08 Jan 2024 18:00:00 +0200

Cet article fait partie d’une série d’articles dédiés à la découverte de MAAS, un outil de déploiement d’OS sur un parc de serveurs (souvent baremetal mais pas que) :

Résumé des épisodes précédents

Dans les deux derniers épisodes, on a vu comment déployer MAAS sur un lab perso, comment déployer ensuite nos premiers OS sur des machines baremetal de manière automatisée, comment les customiser en changeant de version d’Ubuntu ou avec cloud-init.

Mais dans les promesses de MAAS, il y a plus que ça. En théorie, on doit pouvoir démarrer “out of the box” (ouais pas tout à fait, mais je ne spoil pas plus) des serveurs d’autres OS, comme Windows (beurk) ou des hyperviseurs VMware ESXi. Et même plus (mais ça n’est pas le but de cet article pour l’instant).

ESXi ?

Vous l’avez compris, point de Windows Server dans ce tutoriel, cependant sachez qu’avec les deux liens que j’ai déjà donnés dans l’article précédent, vous devriez pouvoir vous en sortir :

Même si c’est un hyperviseur propriétaire, j’ai quand même passé pas mal de temps à travailler avec VMware et j’ai toujours été relativement content d’ESXi (no comment sur le reste de la “suite” par contre).

Note : vous pouvez d’ailleurs retrouver tous les articles qui parlent de VMware sur ce blog, ça date un peu, mais il reste peut-être des trucs utiles.

On va donc voir si c’est si facile que ça…

Ubuntu Pro ?

La première chose qu’on apprend dans la doc, c’est qu’il existe 2 manières de customiser des OS non Ubuntu pour les faire marcher dans MAAS :

Packer MAAS
MAAS Image Builder

MAAS Image Builder nécessitant une souscription Ubuntu Pro, je vais évidemment me rabattre uniquement sur Packer MAAS…

Heureusement, le projet est relativement bien fourni, avec des CentOS (8 ou 9 stream), des Debian jusqu’à la 12, et donc… VMware ESXi, de la 6 à la 8.

Pour cet article, je me suis d’abord basé sur le tutoriel officiel, mais il est sévèrement “pas à jour” (on a un petit doute dès la première étape qui demande d’utiliser Ubuntu 18.04) et pointe vers des versions obsolètes…

Installer Packer

Comme son nom le laisse deviner, on va avoir besoin de Packer, un tool de mes copain⋅es de chez Hashicorp. Pour l’instant personne n’a forké Packer, donc :

wget -O- https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install packer

On vérifie que ça a bien marché

packer --version
 Packer v1.10.0

Récupérer un ISO chez VMware

Alors, là, c’est la partie pénible. Si on n’est pas client VMware, il n’est pas possible de télécharger d’ISO de VMware ESXi sans :

se créer un compte
demander un trial sur une version (idéalement la dernière) d’ESXi

C’est pénible, ça demande plein d’infos personnelles et ça pourri les BAL, mais bon… c’est ça aussi, d’utiliser des logiciels privateurs. Avant, l’usage de l’ESXi était gratuit, mais visiblement, c’est de l’histoire ancienne…

Pas de bol, j’avais fait mes premiers tests sur VMware ESXi 8.0u1, et j’ai voulu récupérer la u2, mais voici ce que me dit VMware

Your evaluation has expired on August 29, 2023

Pour paraphraser un certain Linus T., F… YOU VMware! Tant pis, je vais donc faire avec l’ISO que j’ai…

VMware-VMvisor-Installer-8.0U1a-21813344.x86_64.iso

Récupérer packer-maas

Si vous suivez le tuto que je vous ai donné en début d’article, il y a un moment où on va vous demander un Nom/Prénom/Email pour avoir le droit de télécharger un script pour transformer notre ISO VMware en image MAAS.

maas.io/vmware-images

Sauf que :

l’archive que vous allez télécharger est obsolète et ne fonctionnera pas
les sources et les releases sont dispos et à jour sur le github du projet

Rant: Je suis éventuellement OK pour donner mes informations personnelles en échange de l’outil, mais s’il vous plait, gardez vos tutos à jour !?!

On va donc plutôt télécharger directement la dernière version de packer-maas qui supporte les Debian et des variantes de RHEL supplémentaires :) et est disponible ici (page de la release / archive tgz)

wget https://github.com/canonical/packer-maas/archive/refs/tags/v1.1.0.tar.gz
tar xzf v1.1.0.tar.gz
cd packer-maas-1.1.0/vmware-esxi/

Construire l’image VMware ESXi pour MAAS

On commence par charger le driver nbd. Si comme moi, vous ne savez pas ce que c’est, sachez que c’est Network Block Devices.

sudo modprobe nbd
# si ça ne renvoie rien, c'est bon

Ensuite, on lance Packer avec les arguments suivants :

sudo packer init .
sudo PACKER_LOG=1 packer build -var 'vmware_esxi_iso_path=../../VMware-VMvisor-Installer-8.0U1a-21813344.x86_64.iso' .

Note: packer-maas fourni aussi un Makefile pour vous simplifier encore plus la vie… Vous pouvez juste lancer make ISO=/path/to/VMware-VMvisor-Installer.iso

À ce moment-là, les scripts de packer-maas vont booter une VM avec notre ISO et réaliser des actions pour “l’installer” en envoyant des caractères dans une session VNC !

Quand on y réfléchit, c’est à la fois un peu bourrin et awesome à la fois.

Si tout se passe bien, vous devriez vous retrouver avec un fichier vmware-esxi.dd.gz au bout de quelques minutes.

ESXi dans MAAS

Maintenant qu’on a notre image, on va l’envoyer dans MAAS !

Sur l’UI, récupérer une clé pour API (sinon on ne pourra pas pousser l’image) sur votre utilisateur (il doit être avec des privilèges admin) :

Je n’ai pas trouvé de menu dans la GUI pour le faire, mais on peut loguer notre terminal avec la commande suivante (en n’oubliant pas de renseigner l’API key) :

maas login admin http://192.168.x.y:5240/MAAS/
API key (leave empty for anonymous access):

Puis envoyer l’image en CLI

maas admin boot-resources create name='esxi/8.0u1' title='VMware ESXi 8.0u1' architecture='amd64/generic' filetype='ddgz' content@=vmware-esxi.dd.gz

Note 1 : ne faites pas de Packer sur une partition Windows montée sous Linux (fuse + packer = KK) Note 2 : si vous avez installé MAAS en tant que snap sur votre poste, vous ne pouvez accéder aux fichiers que dans votre /home (vous vous prendrez un “no such file or directory”)

À partir de là, elle devrait apparaitre dans la liste des “Images” disponibles !

Let’s go la déployer sur une machine du lab… Et au bout de quelques minutes…

Victoire !

Un peu plus loin avec MAAS - Metal as a Service, l’outil de déploiement de machines baremetal de Canonical

Thu, 04 Jan 2024 06:00:00 +0200

Cet article fait partie d’une série d’articles dédiés à la découverte de MAAS, un outil de déploiement d’OS sur un parc de serveurs (souvent baremetal mais pas que) :

Introduction

Dans la première partie, nous nous étions arrêté au moment où MAAS était installé sur un Raspberry Pi, routeur entre mon LAN et mon lab. Nous avions également déployé un OS (Ubuntu 20.04 par défaut) pour valider que l’installation fonctionnait

Dans cette partie, on va essayer d’aller un peu plus loin et de faire des trucs plus funs pour déployer des OS différents, et pourquoi pas des hyperviseurs !

Modifier l’OS par défaut

Il est possible de modifier l’OS installé par défaut sur nos machines lors des phases “Commissioning” et “Deploying”

Comme j’avais déjà récupéré les ISO pour Ubuntu 22.04, j’ai donc essayé de modifier toutes les étapes en Ubuntu 22.04.

La procédure est assez simple, on peut même changer le kernel par défaut (pratique pour profiter des dernières avancées eBPF, notamment si vous voulez faire du Kubernetes! )

Rappel : la phase commissioning sert à faire une première installation d’un hôte minimal pour l’enrôler dans notre pool de serveurs disponibles avec MAAS, en vue d’une future installation. Si on veut modifier l’OS installé par défaut quand on déploie une machine, c’est bien le menu de la phase “Deploying” qu’il faut modifier.

Déployer un hôte “KVM”

Par défaut, il est également possible de déployer des hôtes qui vont gérer des machines virtuelles directement depuis MAAS.

Même si j’avais le doute au début, les machines LXD sont bien de vraies machines virtuelles (pas de containers LXC), comme l’explique la documentation officielle LXD vs libvirt - maas.io/docs/virtual-machines (lien mort, j’utilise Internet Archive)

Both libvirt KVMs and LXD VMs are based on QEMU, but LXD VMs offer more advantages such as enhanced security and a robust API. Unlike libvirt KVMs, LXD VMs can be managed remotely without requiring SSH access.

A noter, les machines libvirt sont aujourd’hui considérées comme “legacy” et il n’est pas possible d’en ajouter provenant de l’extérieur dans l’UI 3.4.0 beta que j’ai installé, contrairement aux machines LXD qui peuvent être ajoutées à MAAS même si elles ne sont pas sur des serveurs gérés par MAAS.

On peut ensuite aller dans virsh/LXD (selon ce qu’on a choisi) et poper des VMs depuis l’interface de MAAS.

Et ce qui est rigolo, c’est qu’on peut ensuite installer des trucs sur ces machines, qui se retrouvent dans notre liste :

Machines making machines! How perverse.

– C3PO - Star Wars Episode 2

Et on peut déployer des trucs dessus bien sûr ;-)

Bon, ce n’est par contre pas spécialement user friendly (mais ça marche). L’idée est probablement un peu plus utile avec Juju (que je ne testerai pas ici).

VM hosts offer unique benefits when integrated with Juju, including dynamic VM allocation with custom interface constraints.

Customiser son OS avec cloud-init

Avouez que déployer des OS nus (juste l’OS, rien d’autre) avec MAAS, c’est cool, mais c’est quand même un poil limité en prod. Pour aller plus loin, MAAS nous donne accès à plusieurs mécanismes pour customiser notre OS.

Pour faire simple et parce que c’est devenu un des standards du marché, je vais tester l’utilisation de cloud-init avec MAAS pour customiser mon OS.

Et parce que j’aime Kubernetes, je vais poper un “cluster” de test avec microk8s. En l’état celà ne servira pas à grand-chose en utilisation réelle, mais ça vous donne une idée de ce qu’on peut faire avec.

#cloud-config
runcmd:
- |
# install and start microk8s
snap install microk8s --classic
microk8s start
usermod -a -G microk8s ubuntu
mkdir /home/ubuntu/.kube
chown -R ubuntu ~/.kube
apt_update: true
apt_upgrade: true
package_update: true
package_upgrade: true
package_reboot_if_required: false

Au bout de quelques minutes, la machine est déployée, et l’OS est correctement customisé :

ssh -J 192.168.x.y ubuntu@10.10.0.4

microk8s kubectl get pods
No resources found in default namespace.

Note : Ici j’utilise le RPi comme “JumpHost” car je n’ai pas d’accès direct aux machines depuis mon LAN.

Aller plus loin - déployer ses propres images sur ses machines

Ici, je tease un peu le(s) prochain(s) article(s). Ne vous attendez pas à lire la solution ici, il faudra attendre un peu ;-).

Par défaut, les OS disponibles sur MAAS proviennent d’images qui sont stockées sur maas.io. On y retrouve toutes les LTS d’Ubuntu jusqu’à la 12.04 (!?!) ainsi que les non-LTS de la 20.10 à la 23.10, et pour plusieurs architectures.

Dans la section “Other Images”, il n’y a malheureusement que CentOS 7 et 8.

Pour utiliser d’autres images, on va pouvoir utiliser des registry customs depuis l’interface ou créer nos propres builds qu’on poussera sur l’interface.

Si vous êtes trop curieux, je vous laisse quand même quelques liens qui devraient vous donner une bonne idée de ce qu’on va faire la prochaine fois.

En attendant, have fun !

Premiers pas avec MAAS - Metal as a Service, l’outil de déploiement de machines baremetal de Canonical

Thu, 21 Dec 2023 14:00:00 +0200

Cet article fait partie d’une série d’articles dédiés à la découverte de MAAS, un outil de déploiement d’OS sur un parc de serveurs (souvent baremetal mais pas que) :

Introduction

Il y a quelques mois, après plusieurs discussions avec mon collègue (et ami!) Julien, j’ai voulu tester MAAS (Metal As A Service) sur mon homelab.

Pour ceux qui ne connaissent pas cet outil, c’est un logiciel qui va permettre de déployer des machines baremetal de manière automatique.

En théorie, l’outil est plutôt prévu pour faciliter le déploiement de serveurs de manière flexible en datacenters, mais il existe plusieurs exemples de personnes qui ont réussi à l’utiliser sur des NUCs ou des machines desktop.

C’est donc un parfait premier cas d’usage pour mon homelab, composé de 3 dell micro et d’un raspberry pi.

J’avais deux possibilités en termes d’architecture et j’ai d’ailleurs testé les deux. La première était de créer le lab dans mon LAN. Ca nécessite de bidouiller un peu le DHCP de ma box Bouygues pour que MAAS puisse gérer les IPs des machines ainsi que de configurer le DHCP pour propager le PXE.

A priori c’est faisable, mais j’ai trouvé ça pénible dans l’idée et potentiellement disruptif pour mon LAN perso, alors j’ai décidé de mettre le homelab dans un LAN à part, dont le RPi serait le routeur. J’ai ajouté une interface réseau à l’aide d’un adaptateur ethernet USB et roule ma poule.

A l’époque (en juin), ça n’avait pas marché (peut être à cause d’un bug ?), les machines étaient bien déployables, mais je ne pouvais pas réaliser l’action “Deploy”.

Node has no address family in common with the server

Cependant, cette fois-ci, ça a marché ! Voici donc un premier article sur le sujet !

Préparer le RPI

Avant de toucher aux Dell micro, j’ai donc commencé par configurer le Raspberry Pi, avec Rpi Imager.

https://ubuntu.com/tutorials/how-to-install-ubuntu-on-your-raspberry-pi#1-overview

Une fois la carte préparée, sur la partition system-boot, éditer le fichier config.txt pour configurer l’écran portable (ou /boot/firmware/config.txt une fois booté). Ici, ça sert juste pour mon petit écran portable 7 pouces (peut être que ça peut aider dans d’autres cas) mais je vous le mets quand même, pour info.

[all]
max_usb_current=1
hdmi_force_hotplug=1
config_hdmi_boost=10
hdmi_group=2
hdmi_mode=87
hdmi_cvt 1024 600 60 6 0 0 0

On boot le pi, on se connecte en ssh, on update/upgrade tous les packages et on reboot, histoire de commencer sur des bases saines.

Installer MAAS sur le RPI

maas.io/docs/how-to-do-a-fresh-install-of-maas

En prérequis MAAS demande de désactiver le client ntp existant pour éviter des conflits

sudo systemctl disable --now systemd-timesyncd

Et comme j’ai décidé que mes machines seraient dans un LAN à part (cf schéma ci-dessus) et que le RPi serait le “routeur” entre les deux, il faut bien sûr autoriser le routage :

sudo vi /etc/sysctl.conf
 net.ipv4.ip_forward = 1
 net.ipv6.conf.all.forwarding=1

sudo sysctl -p /etc/sysctl.conf

Et pour finir, je vais configurer mon resolver DNS dans /etc/resolv.conf sur ma Box internet

sudo vi /etc/resolv.conf
[...]
 nameserver @IP
[...]

Addendum : histoire d’éviter des soucis de changement d’adresse IP à cause de mon DHCP pourri, on fixe les IPs via une configuration netplan. Ici, mon interface ethernet du RPi est eth0 (celle reliée à mon LAN) et celle (USB) reliée à mon lab et aux 3 dell micros est enxa0cec80428b7.

vi /etc/netplan/50-cloud-init.yaml
network:
 ethernets:
 eth0:
 dhcp4: false
 addresses: [192.168.x.y/24]
 gateway4: 192.168.x.z
 nameservers:
 addresses: [9.9.9.9,192.168.x.z]
 enxa0cec80428b7:
 dhcp4: false
 addresses: [10.10.0.1/16]
 version: 2

Et on valide avec

netplan apply

Si vous suivez la doc bêtement comme je le fais moi, MAAS propose de s’installer en tant que snap. Si c’est le cas, il ne pourra accéder qu’à /home et /media (cf ce post sur le discourse de maas.io). Il existe aussi une version .deb de MAAS mais pour le test je me suis contenté de ça.

zwindler@maas:~$ sudo snap install --channel=3.4/beta maas
maas (3.4/beta) 3.4.0-14319-g.3ab76533f from Canonical✓ installed

Note : point important, l’expérience utilisateur entre la version 3.3 et la version 3.4 est significativement différente. Au delà de l’UI qui change d’un menu horizontal à un menu vertical, certaines opérations semblent ne pas être totalement identiques. Il est possible que ce tuto ne marche pas en 3.3.

Plutôt qu’installer une base PostgreSQL pour stocker les données de MAAS, je vais également simplement utiliser le snap maas-test-db, qui comme son nom l’indique, est une base de données postgres préconfigurée pour faire des tests avec MAAS (donc pas production ready !).

zwindler@maas:~$ sudo snap install maas-test-db
maas-test-db (3.3/stable) 14.2-29-g.ed8d7f2 from Canonical✓ installed

A partir de là, mon Raspberry Pi 4 modèle 2 Go (oui j’ai été radin) est à l’agonie. Heureusement, un petit reboot suffit à lui donner un second souffle.

Configurer MAAS

Une fois que c’est fait, on peut initialiser notre MAAS en mode “region+rack”. Ca va nous permettre d’avoir la totalité des fonctionnalités sur le serveur MAAS du RPi.

zwindler@maas:~$ sudo maas init region+rack --database-uri maas-test-db:///
MAAS URL [default=http://@IP:5240/MAAS]: (valider avec entrée)
[/] Performing database migrations
MAAS has been set up.

If you want to configure external authentication or use
MAAS with Canonical RBAC, please run

 sudo maas configauth

To create admins when not using external authentication, run

 sudo maas createadmin

To enable TLS for secured communication, please run

 sudo maas config-tls enable

Pour faire simple, je ne vais pas configurer une authentification externe et me contenter (là encore) de simplement créer un utilisateur local d’administration :

zwindler@maas:~$ sudo maas createadmin
Username: zwindler
Password:
Again:
Email: blog@zwindler.fr
Import SSH keys [] (lp:user-id or gh:user-id):

On peut donc ouvrir la page d’admin (http://@IP:5240/MAAS/r/) et rentrer le login/mdp qu’on vient de créer.

La première chose qu’on va nous demander c’est de finir le setup via un wizard. On va créer notre première région, ajouter nos premières images, ajouter une clé SSH

Configurer un subnet

Une fois le wizard terminé, on va avoir l’auto-découverte de ce qui se passe sur notre LAN. Le truc, c’est que dans mon cas précis, ce n’est pas ce qui est sur mon LAN (de ma box) qui m’intéresse, mais ce qui va être sur le LAN de MAAS, via mon autre interface Ethernet (USB).

Je vais donc créer un réseau interne 10.10.0.0/16 (cf la doc maas.io/docs/about-networking)

Une fois créé, je l’édite pour ajouter des infos

De retour sur la fabric, on va sur le VLAN par défaut et on configure le DHCP

Une fois que c’est fait, on va pouvoir commencer à booter des machines en PXE pour les enroller dans MAAS !!

Enroller des machines

A partir de là en vrai, il n’y a plus grand-chose à faire. J’ai configuré le BIOS de mes dell micro pour qu’il boot d’abord sur le PXE. Le serveur DHCP / PXE de MAAS sur le RPi a pris le relai, et a fait booter la machine sur une image d’enrôlement.

Au bout de plusieurs minutes, dans l’onglet Machines, on voit mon Dell micro arriver. On peut la tester :

Et là, patatra, error !

En vrai, c’est parce qu’il me manque une étape. J’ai oublié d’indiquer à MAAS comment démarrer la machine.

Dans mon cas, il ne s’agit pas de matériel de type “serveur”. Je ne peux donc pas piloter l’allumage de la machine à distance avec un ILO / iDRAC. De même, je n’ai pas pris de multiprise manageable (je vais y réfléchir cela dit). Je dois donc configurer la “power source” de la machine et indiquer comme “Power type” la valeur “Manual”.

Une fois que c’est fait, je fais un “Commission” (et j’appuie moi même si le bouton “On”).

Et si tous les tests sont bien passés, on doit se retrouver avec une machine à l’état “Ready”. A partir de là, je peux la “Deploy” (et il faut encore que j’appuie sur le bouton “On”).

Et cette fois-ci, c’est une victoire ;-)

➜ ~ ssh -J zwindler@@IP ubuntu@10.10.0.2
Welcome to Ubuntu 20.04.6 LTS (GNU/Linux 5.4.0-169-generic x86_64)
[...]
ubuntu@daring-tomcat:~$

Metal as a Service on Zwindler's Reflection

Sidero Omni - Talos Linux sur Oracle Cloud (en free tier)

Contexte

Quel rapport avec Oracle Cloud ?

Prérequis

Récupération du compartment ID

Préparation de l’environnement Oracle Cloud

Mais ce n’est pas terminé :-/

Importation de l’image sur Oracle Cloud

Création de la VM

Addendum : est-ce que c’est vraiment gratuit ?

Déployer un hyperviseur VMware ESXi avec MAAS

Résumé des épisodes précédents

ESXi ?

Ubuntu Pro ?

Installer Packer

Récupérer un ISO chez VMware

Récupérer packer-maas

Construire l’image VMware ESXi pour MAAS

ESXi dans MAAS

Un peu plus loin avec MAAS - Metal as a Service, l’outil de déploiement de machines baremetal de Canonical

Introduction

Modifier l’OS par défaut

Déployer un hôte “KVM”

Customiser son OS avec cloud-init

Aller plus loin - déployer ses propres images sur ses machines

Premiers pas avec MAAS - Metal as a Service, l’outil de déploiement de machines baremetal de Canonical

Introduction

Préparer le RPI

Installer MAAS sur le RPI

Configurer MAAS

Configurer un subnet

Enroller des machines

Liens en vrac