Lightwhale 3 : redonner du plaisir aux serveurs Linux

 (lightwhale.asklandd.dk)
4 points par GN⁺ 3 일 전 | 1 commentaires | Partager sur WhatsApp
  • Un OS serveur Linux conçu exclusivement pour les conteneurs Docker : il suffit de démarrer l’ISO pour arriver directement dans un environnement Docker Engine
  • Le système cœur adopte une architecture immuable et sans état, en séparant /etc, /var, /home et les données Docker dans des zones d’écriture distinctes, ce qui réduit fortement la charge liée à l’installation et à la configuration initiale
  • Le système de fichiers de données par défaut est un stockage volatil basé sur tmpfs ; si l’on active la persistance, un périphérique de stockage séparé est détecté automatiquement, partitionné, formaté et monté, avec possibilité de configuration en Btrfs RAID1 si nécessaire
  • Grâce à une racine en lecture seule basée sur squashfs et à un ensemble minimal de composants, la surface d’exposition aux malwares et aux modifications involontaires est réduite, tout en diminuant l’utilisation des ressources et la consommation électrique
  • Réservé au x86-64, il fonctionne sur bare metal comme en machine virtuelle, et permet de se concentrer immédiatement sur l’exécution de conteneurs et l’auto-hébergement plutôt que sur l’administration du serveur elle-même

Aperçu

  • Il s’agit d’un OS serveur Linux conçu exclusivement pour les conteneurs Docker ; un démarrage live depuis l’ISO mène directement à un environnement Docker Engine
  • Pour réduire la charge d’installation et de configuration initiale, le système cœur reste immuable, tandis que les données et la personnalisation utilisateur sont séparées dans des zones de stockage dédiées
  • Il vise les homelabs, le bare metal, les environnements virtualisés, les nœuds edge et même les clusters, mais l’architecture prise en charge se limite au x86-64
  • En privilégiant une composition minimale et la simplicité d’usage, il permet de se concentrer sur l’exécution et l’exploitation des conteneurs plutôt que sur l’administration du serveur

Principales caractéristiques

  • Son approche plug and play permet de télécharger simplement l’ISO et de démarrer : Docker Engine est alors immédiatement prêt, avec les outils nécessaires intégrés
  • La réduction au minimum des composants allège la courbe d’apprentissage et permet de comprendre rapidement le fonctionnement du système
  • Le cœur immuable et sans état réduit la surface d’exposition aux malwares et aux modifications involontaires, et garantit un démarrage identique à chaque fois
  • Il propose une persistance optionnelle : le système de fichiers de données par défaut est un tmpfs volatil en RAM, et si la persistance est activée, un périphérique de stockage séparé est automatiquement détecté, partitionné, formaté et monté
  • En limitant les processus inutiles, il réduit l’utilisation des ressources et la consommation électrique, et permet de prolonger la durée de vie de matériels anciens ou modestes
  • Il facilite l’auto-hébergement pour réduire la dépendance aux Big Tech et garder la maîtrise de ses données et de sa vie privée

Démarrage

  • Il suffit de télécharger la dernière ISO ou une image depuis la section de téléchargement, de l’écrire sur une clé USB puis de démarrer dessus
  • Sur certains systèmes, il peut être nécessaire de désactiver le safe boot dans le BIOS avant le démarrage
  • Les identifiants par défaut sont op comme nom d’utilisateur et opsecret comme mot de passe ; avant toute exposition à Internet, il faut au minimum changer le mot de passe
  • Le Wi‑Fi peut être configuré de manière optionnelle avec setup-wifi
  • L’exécution des conteneurs se fait comme avec Docker habituellement ; l’exemple donné est docker run -it --rm busybox ps
  • Lors de l’activation de la persistance, il faut écrire le magic header sur un périphérique bloc et non une partition, et ce processus efface les données existantes

Structure de démarrage et d’exécution

  • L’ISO peut démarrer aussi bien sur bare metal qu’en machine virtuelle, avec prise en charge de l’UEFI et du BIOS traditionnel
  • Le processus de démarrage utilise un système init de type sysv afin de conserver un flux de boot simple et transparent
  • Le bootloader charge en mémoire le noyau Linux et le système de fichiers racine, puis le noyau initialise le matériel et transmet le contrôle à /init
  • init lit /etc/inittab, monte les tmpfs pour /tmp et /run, puis exécute les scripts de /etc/init.d
  • Au début du processus, le data filesystem est monté afin de fournir les données Docker et les couches supérieures d’overlay pour /etc, /var et /home
  • Une fois tous les systèmes de fichiers et overlays prêts, le reste des services démarre, et les conteneurs peuvent alors être servis

Conception de l’immuabilité

  • Le système de fichiers racine est fourni sous forme d’image statique compressée squashfs, structurellement impossible à modifier par elle-même
  • Grâce à cela, les logiciels et paramètres essentiels sont intégrés à l’avance, ce qui en fait une image autonome amorçable sans processus d’installation
  • Cela évite le gestionnaire de paquets, la gestion des dépendances et la concurrence avec les mises à jour d’un système existant, en remplaçant la réinstallation de quelque chose qui fonctionne déjà par un simple redémarrage
  • Les fichiers du système de fichiers racine ne peuvent être ni supprimés par erreur ni modifiés par un virus, et l’ensemble noyau + binaires de base n’est pas exposé en écriture comme dans un système traditionnel
  • Avec une racine en lecture seule, on évite l’accumulation de fichiers parasites qui, au fil du temps, dégradent les sauvegardes, les performances et la propreté du système
  • Il est possible d’expérimenter librement sur une VM locale ou sur un autre ordinateur, puis d’annuler les changements par un redémarrage
  • Le support de démarrage ne contient aucune information importante et conserve cet état grâce à l’immuabilité ; en cas de dommage ou de perte de l’appareil, une nouvelle copie permet de restaurer l’environnement

Structure de la persistance

  • Installer et exécuter des conteneurs, modifier la configuration et écrire des données nécessitent un système de fichiers inscriptible ; pour conserver ces changements après redémarrage, la persistance est nécessaire
  • Lors des premières étapes du démarrage, un sous-système qui s’exécute automatiquement monte le data filesystem sur /mnt/lightwhale-data
  • Les données écrites par Lightwhale sont regroupées sous /mnt/lightwhale-data/lightwhale-state, et ce répertoire sert de couche supérieure inscriptible pour overlayfs
  • Par défaut, il s’agit d’un tmpfs volatil ; si la persistance est activée, le data filesystem est déplacé sur un périphérique de stockage séparé
  • Au lieu de recouvrir toute la racine, seuls /etc, /var et /home sont placés sélectivement sous overlay afin de préserver l’objectif d’immuabilité
    • /etc sert à personnaliser la configuration système, comme le réseau, les mots de passe ou sshd
    • /var sert aux journaux et à d’autres données applicatives
    • /home sert aux personnalisations utilisateur comme les clés SSH authorized, les clones de dépôts Git ou la gestion des stacks Docker et Swarm
  • Le data root de Docker se trouve directement dans /mnt/lightwhale-data/lightwhale-state/docker et stocke l’état des images, conteneurs, volumes et réseaux

Activation de la persistance et étapes automatiques

  • La persistance doit être activée explicitement en écrivant un magic header sur un périphérique de stockage, par exemple avec echo "lightwhale-please-format-me" | sudo dd conv=notrunc of=/dev/sdx
  • Il est possible d’écrire ce magic header sur plusieurs périphériques de stockage ; dans ce cas, ils sont combinés en volume Btrfs RAID1
  • Au démarrage suivant, le système détecte les magic disks, les formate et les utilise comme data filesystem
  • Le persistence subsystem est lancé depuis /etc/init.d/S11persistence

  • Détection du système de fichiers de données

    • Tous les disques sont inspectés afin de trouver une partition dont le label de système de fichiers est lightwhale-data
    • Si elle est trouvée, elle est utilisée comme data filesystem et les étapes de montage suivantes sont directement exécutées

  • Détection des magic disks et création des partitions

    • Le système identifie un magic disk en recherchant la séquence d’octets lightwhale-please-format-me au début du disque
    • Pour chaque magic disk, il crée une partition swap avec le label lightwhale-swap et une partition Linux utilisant tout l’espace restant avec le label lightwhale-data

  • Création du système de fichiers

    • Les partitions swap magiques sont formatées puis étiquetées lightwhale-swap
    • S’il n’y a qu’une seule partition de données magique, elle est formatée avec btrfs --data single --metadata dup
    • S’il y en a plusieurs, elles sont assemblées en RAID1 et formatées avec btrfs --data raid1 --metadata raid1cn
    • Les sous-volumes @lightwhale-data, @lightwhale-state, @lightwhale-state-snapshots sont créés

  • Montage et configuration de l’overlay

    • S’il existe un data filesystem, @lightwhale-data est monté sur /mnt/lightwhale-data, sinon un tmpfs est monté à la place
    • La couche inférieure immuable est préparée en bind-mountant /etc vers /run/lightwhale/overlay/lower/etc et en répliquant l’arborescence des répertoires du système de fichiers racine
    • La couche supérieure inscriptible est préparée dans des chemins comme /mnt/lightwhale-data/lightwhale-state/overlay/upper/etc
    • Ensuite, overlayfs fusionne les deux couches et les monte sur /etc, puis la même méthode est répétée pour /var et /home

Limitations et points clés de la FAQ

  • Le matériel pris en charge est exclusivement x86-64, avec support du BIOS et de l’EFI
  • Raspberry Pi n’est pas encore pris en charge et figure dans le backlog
  • Les Apple M-series ne sont pas prises en charge sur bare metal, mais une exécution en virtualisation est possible
  • Il peut fonctionner dans des environnements virtuels comme VMWare/ESX/Proxmox/cloud, et inclut des agents invités pour QEMU/KVM et VMware ESXi
  • Le logiciel ne permet d’installer que des conteneurs Docker ; une installation directe dans le système de fichiers racine est impossible
  • Le système cœur est immuable, mais la configuration, la personnalisation et les données des conteneurs sont écrites en mémoire par défaut et ne persistent après redémarrage que si la persistance est activée
  • Le nom d’hôte par défaut inclut un machine ID pour éviter les conflits sur le réseau, et si on le modifie avec setup-hostname, le changement s’applique immédiatement, sauf dans le shell courant
  • Aucune garantie n’est fournie, et la responsabilité de l’usage et de ses conséquences incombe à l’utilisateur
  • Le projet ne vise pas à ajouter à la racine des outils favoris comme wget ou nano, afin de conserver la contrainte d’un OS serveur minimal spécialisé
  • Côté politique de confidentialité, le TL;DR indique qu’aucune donnée personnelle n’est collectée et que des données anonymes ne sont recueillies qu’en cas de consentement à la télémétrie, avec possibilité d’en consulter le contenu
  • La conformité aux réglementations liées à l’âge ne relève pas de l’OS lui-même, mais de la responsabilité des services déployés par l’utilisateur

Liens associés

À lire aussi

1 commentaires

 
GN⁺ 3 일 전
Commentaires sur Hacker News

  • Félicitations pour avoir vraiment livré quelque chose, mais je ne vois pas encore très bien pourquoi il faudrait utiliser ça
    Il existe déjà des alternatives aux objectifs similaires comme Flatcar Container Linux, Fedora CoreOS, Talos Linux et IncusOS, qui semblent aussi bénéficier d’une communauté ou d’un soutien commercial plus solides
    Il faudrait expliquer plus clairement ce qui différencie ce projet pour que ce soit convaincant

    • J’utilise IncusOS dans mon homelab, et l’expérience de configuration comme d’utilisation est vraiment excellente
      J’ai migré depuis Proxmox et je gère désormais toutes mes VM avec, en m’appuyant fortement sur des assistants de code pour automatiser la configuration CLI d’IncusOS, convertir des images Docker-Compose vers Incus, et écrire des scripts bash pour lancer de nouveaux conteneurs sans trop d’inquiétude même avec --dangerously-skip-permissions
      Le meilleur point, c’est la gestion via des fichiers déclaratifs, qui permet de garder en permanence une vue claire sur la configuration réseau et les réglages de ressources
      Pour un usage similaire, IncusOS vaut le détour
    • Avec ce genre d’outils, il faut souvent des heures de configuration, alors qu’ici ça tourne immédiatement après le démarrage

  • Tant qu’il y a du logiciel, on ne peut pas échapper à la maintenance
    Il n’existe pas de logiciel sans bug, et prétendre qu’il n’y a jamais besoin de mises à niveau, de correctifs ou d’administration est souvent le chemin le plus rapide vers un système compromis

    • Ce n’est pas que cet OS serait sans maintenance
      C’est plutôt qu’il réduit une bonne partie de la maintenance nécessaire sur un système de base traditionnel, notamment parce que 1) il y a très peu de choses installées et 2) les mises à niveau de la base sont simples, puisqu’il suffit de redémarrer puis de relancer les conteneurs
      Bien sûr, les logiciels qui tournent dessus doivent toujours être mis à jour, mais avec une approche Docker, cette couche est généralement gérée ailleurs, donc il suffit de récupérer un nouveau conteneur et de le redémarrer, tandis que l’OS sert surtout à garantir que les données restent montées au même endroit
      Si faire tourner tous ses logiciels dans Docker vous convient, ça ressemble à une étape au-dessus de Debian ou Redhat, avec moins de complexité procédurale que CoreOS
      Je me demande encore à quel point c’est réellement pratique, surtout sur la gestion du stockage, mais au moins la proposition est très claire
    • Ça fait des années que je tiens ce discours
      L’auto-hébergement est possible, mais cela revient aussi à assumer de fait un SLA sur son temps libre hors des heures de travail
      C’est pour ça que j’ai supprimé depuis longtemps tout ce qui servait à plus d’un utilisateur
    • Bien sûr, rien n’est totalement sans bug
      Mais s’il existe des projets comme Talos, ce n’est pas pour rien
      Sans terminal, sans SSH, sans gestionnaire de paquets, avec un système de fichiers en lecture seule, sans systemd et avec un minimum d’exécutables, la surface d’attaque est clairement réduite
      Je ne parle pas forcément du projet présenté ici, mais des systèmes à la fois plus sûrs et demandant moins de maintenance existent bel et bien
      Puisqu’on ne pourra jamais être en sécurité à 100 %, la solution n’est pas non plus d’accepter en mode YOLO un paquet npm modifié il y a 3 minutes

  • C’est intéressant, mais je me demande comment sont gérés les correctifs, les mises à niveau et la construction d’ISO personnalisées
    Même en regardant le dépôt source, on ne voit quasiment rien sur ce point

    The actual repository here hosts the source code for Lightwhale, and is not of any interest for most people.

    https://bitbucket.org/asklandd/lightwhale/src/master/

    • Le dépôt a l’air abandonné depuis longtemps
      Le dernier commit remonte à 2 ans, et il semble ne pas y avoir de source pour la version 3.0

  • Ce n’est pas un OS, c’est plutôt une distribution Linux, non ?

    • Si ce n’est pas une distribution Linux, alors j’aimerais bien savoir ce qu’on appelle un OS

  • J’ai l’impression d’être presque débutant dans ce domaine, même si je fais de l’auto-hébergement depuis plus de 10 ans, et depuis 2019 environ je suis passé à Unraid
    L’approche centrée sur un portail web était facile à prendre en main et pratique à maintenir
    Je me demande comment on interagit avec cet OS pour serveur domestique
    Comme il n’y a pas d’images sur le site, j’imagine qu’il faut tout gérer en terminal

  • Je viens justement d’installer Docker sur Ubuntu Server en une seule ligne et de m’en servir tout de suite, donc je ne vois pas exactement la différence ici ni quelle est la proposition de valeur
    Je me demande aussi ce que recouvre concrètement cette histoire de maintenance, et si c’est un serveur allégé pour tourner sur du matériel moins puissant
    Je débute tout juste dans la mise en place d’un home server, donc je cherche sincèrement à comprendre quels en sont les avantages

    • Je fais exactement pareil
      On dit souvent que l’avantage de l’approche immutable se joue sur les mises à jour : si une nouvelle version de l’image pose problème, on peut simplement redémarrer sur la version précédente pour revenir en arrière
      Mais sur le plan fonctionnel, j’ai aussi l’impression que Ubuntu Server me suffit largement
      Quelques apt update et mises à niveau par an, et un accès limité au local ou à Tailscale
      Ce genre d’OS immutable me paraît plus séduisant sur un ordinateur portable ou de bureau que sur un home server
      Le fait que seul le répertoire personnel soit modifiable donne l’impression d’un OS plus stable et plus difficile à casser

  • Je me demande quelle est la méthode recommandée pour sauvegarder régulièrement les données des conteneurs exécutés sur Lightwhale

  • Je ne comprends pas vraiment
    Si l’idée est juste de faire tourner Docker, je ne vois pas pourquoi il faudrait de l’immutable, ni pourquoi il faudrait une variante spécialisée de Debian au lieu d’un Debian ou d’un Ubuntu où Docker peut être opérationnel en quelques minutes
    La maintenance, c’est déjà quelque chose qu’on gère via les dépôts de la distribution ou le dépôt officiel de Docker avec un gestionnaire de paquets, non ?
    J’aimerais bien que cette mode de l’immuable retombe un peu, et je pense pareil pour flatpak ou snap
    Linux faisait déjà à l’origine ce que ces solutions prétendent résoudre
    Sans root, l’utilisateur ne peut pas modifier le système de base, et les applications n’ont qu’à installer leurs dépendances dans /usr/lib

    • Pour moi, une combinaison Debian stable avec podman/Docker est déjà suffisamment immutable
      Et le fait qu’il soit facile d’obtenir de l’aide quand on est bloqué, c’est une très bonne assurance
      On peut sûrement faire plus léger, mais ça tourne déjà très bien sur du matériel atypique comme des BananaPi peu puissants ou du RISC-V d’entrée de gamme, donc je vois mal pourquoi j’aurais besoin d’autre chose

  • Ce genre de chose semble pouvoir très bien convenir à un cluster en mode Swarm
    Je ne sais pas si l’accent est mis uniquement sur les home servers, mais je vais continuer à suivre ça
    Le projet a vraiment l’air très bien

    • Pour l’instant, on ne communique que vers les home servers, parce que c’est là que les gens essaient le plus facilement ce genre de chose sans trop d’engagement
      Mais Lightwhale tourne déjà en production, et convient aussi très bien à des clusters Swarm

  • Ça a l’air super propre
    Du point de vue d’un débutant, c’est exactement le genre d’approche qu’il faut pour éviter de casser sa configuration, donc je compte vraiment l’essayer