musl ou glibc : ce qu'Alpine Linux change sur un VPS et dans vos conteneurs Docker

Depuis le 5 novembre 2026 et la faille d'authentification de sshd sur Alpine Linux, beaucoup d'administrateurs découvrent que leur serveur ou leurs images Docker ne tournent pas sur la même bibliothèque C que Debian ou Ubuntu. Alpine est construite autour de musl, une libc légère, là où presque toutes les autres distributions Linux utilisent la glibc du projet GNU. Le noyau est le même, les commandes se ressemblent, mais la couche qui relie vos programmes au noyau change : allocation mémoire, résolution DNS, chargement des binaires, authentification. Ce guide explique concrètement ce que musl implique quand on administre un VPS Linux, un serveur dédié ou des conteneurs, et se termine par une règle de choix : quand garder Alpine, quand repasser sur Debian.

Sources : avis de sécurité Alpine du 5 novembre 2026, notes de version OpenSSH 10.6p2, wiki musl : différences fonctionnelles avec glibc, versions de musl, gcompat, calendrier des branches Alpine, plateformes supportées par Node.js, PEP 656, JEP 386, ticket Kubernetes 64924, mesures de Nick Babcock sur l'allocateur de musl, documentation Bell-SW sur les allocateurs, mesures d'Itamar Turner-Trauring sur Python et Alpine, tailles d'images relevées sur Docker Hub le 8 novembre 2026.

musl et glibc : deux bibliothèques C pour le même noyau Linux

La bibliothèque C (libc) est le socle de tout ce qui tourne sur un système Linux. C'est elle qui fournit malloc pour allouer la mémoire, getaddrinfo pour résoudre un nom de domaine, crypt pour hacher un mot de passe, les threads POSIX, les locales, et le chargeur dynamique qui ouvre un binaire et lui attache ses bibliothèques partagées. Un programme compilé pour une libc attend ses symboles, ses conventions et son chargeur : c'est pour cela qu'un binaire glibc ne démarre pas tel quel sur musl.

La glibc équipe Debian, Ubuntu, Rocky Linux, AlmaLinux et Fedora. Debian 13 « trixie » embarque la version 2.41. musl, créée par Rich Felker, vise à être « rapide, simple, léger et correct » selon son wiki, avec un code beaucoup plus court. Sa dernière version, 1.2.6, date du 20 mars 2026 ; c'est celle qu'Alpine 3.24 fournit dans le paquet musl. On retrouve aussi musl dans des systèmes embarqués (OpenWrt, Buildroot, Yocto) et dans les binaires statiques produits avec Go ou Rust pour la cible x86_64-unknown-linux-musl.

Aucune des deux n'est « la bonne ». La glibc privilégie la compatibilité et les performances sur les gros serveurs multi-cœurs ; musl privilégie la taille, la lisibilité du code et un comportement strict vis-à-vis des standards. Ce sont ces choix qui expliquent chacun des points suivants.

Pas de PAM par défaut : ce que la faille OpenSSH a montré

PAM (Pluggable Authentication Modules) est la couche qui, sur Debian ou Ubuntu, vérifie les mots de passe pour sshd, login ou sudo, et qui porte les règles de verrouillage de compte, de plages horaires ou de double facteur. Alpine ne s'appuie pas dessus par défaut : son paquet openssh-server est compilé sans PAM, et la variante qui l'utilise est un paquet distinct, openssh-server-pam (version 10.3_p1-r2 dans la branche 3.24). Le paquet linux-pam existe dans le dépôt main, mais rien ne l'installe à votre place.

Sans PAM, c'est sshd lui-même qui hache le mot de passe soumis avec la fonction crypt() de la libc, puis compare le résultat au champ stocké dans /etc/shadow. Or la crypt() de musl renvoie la chaîne * quand le mot de passe dépasse 256 octets : c'est sa façon de signaler une erreur. Et * est exactement ce que contient le champ mot de passe d'un compte qui n'en a pas, comme root dans les images Alpine récentes ou un utilisateur créé pour se connecter uniquement par clé. Un mot de passe de 257 à 1 024 octets produisait donc une « correspondance » et ouvrait la session, à condition qu'un autre compte local ait une vraie empreinte $5$ ou $6$ dont sshd réutilise le sel. Toutes les branches d'Alpine de 3.16 à 3.24 et edge étaient touchées. OpenSSH a publié la version 10.6p2 le 5 novembre 2026 pour contourner le problème, Alpine a corrigé ses paquets le même jour, et la faille a reçu depuis l'identifiant CVE-2026-123158. Notre actualité OpenSSH 10.6p2 : connexion sans mot de passe sur Alpine détaille la vérification et la correction.

La leçon dépasse cette faille : sur un système musl, les comportements que vous tenez pour acquis sur Debian (PAM, modules NSS, options GNU des commandes) ne sont pas forcément là. Sur un VPS Alpine, vérifiez ce que sshd applique réellement, la version du paquet et redémarrez le démon après mise à jour, car le paquet ne remplace pas le processus déjà lancé :

sshd -T | grep -iE '^(usepam|passwordauthentication|permitrootlogin)'
apk info -v openssh-server
apk upgrade -U -a && rc-service sshd restart

Quelle que soit la libc, désactivez l'authentification par mot de passe (PasswordAuthentication no) et connectez-vous par clé : c'est le réglage qui rendait la faille inexploitable, et c'est celui que nous recommandons dans notre guide sécuriser SSH sur un VPS Linux. Les conteneurs Alpine qui ne font pas tourner sshd, soit l'immense majorité, n'étaient pas concernés.

Résolution DNS : le resolver de musl ne se comporte pas comme celui de glibc

C'est la différence qui fait perdre le plus de temps en production, parce que les symptômes sont intermittents. Le wiki de musl documente quatre écarts avec glibc qui touchent directement un serveur ou un conteneur.

• Tous les serveurs de noms en parallèle. glibc interroge le premier nameserver de /etc/resolv.conf, puis passe au suivant après un délai. musl envoie la requête à tous les serveurs en même temps (trois au maximum) et garde la première réponse. Si vous listez un résolveur interne qui connaît vos noms privés et un résolveur public qui ne les connaît pas, le public répond parfois le premier avec un NXDOMAIN : le nom interne « disparaît » une fois sur trois. Règle : sous musl, ne listez que des résolveurs qui donnent les mêmes réponses.
• search et ndots sans repli. Les domaines de recherche sont pris en charge depuis musl 1.1.13, mais un nom qui contient au moins autant de points que ndots n'est cherché que dans l'espace global, jamais dans les domaines search. Une ligne search de plus de 256 caractères est ignorée. C'est l'origine du ticket Kubernetes 64924 : avec le options ndots:5 injecté dans les pods, des images Alpine n'arrivaient plus à résoudre des noms externes que des images Ubuntu résolvaient sans problème. Les contournements retenus : ndots:1 via dnsConfig, ou des noms absolus terminés par un point (api.example.com.).
• DNS sur TCP seulement depuis musl 1.2.4. Avant cette version du 1er mai 2023, le resolver ne basculait pas sur TCP quand une réponse UDP était tronquée. Les gros enregistrements (DNSSEC, listes de serveurs mail, longs TXT) échouaient. Une vieille image Alpine encore en production peut avoir ce défaut.
• Pas de modules NSS. musl n'implémente pas le mécanisme nsswitch.conf de glibc. Les comptes venus d'un annuaire LDAP ou Active Directory passent par un démon séparé, musl-nscd, et les bibliothèques qui s'appuient sur un module NSS (mDNS, résolution par un service externe) ne fonctionnent pas.

Pour diagnostiquer dans un conteneur, regardez ce que Docker ou Kubernetes a écrit dans resolv.conf, puis testez avec le nslookup de BusyBox, d'abord avec le nom absolu :

cat /etc/resolv.conf
nslookup api.example.com.
docker run --rm alpine:3.24 nslookup elypsecloud.com

Sur un réseau Docker défini par l'utilisateur, le démon fournit un seul résolveur interne (127.0.0.11) : le problème des serveurs parallèles ne se pose pas. Il revient dès qu'un conteneur hérite du resolv.conf de l'hôte avec plusieurs serveurs, ou dans un cluster avec des domaines de recherche multiples. Nos guides installer Docker sur un VPS et Docker Compose sur VPS Linux couvrent la mise en place des réseaux.

Binaires glibc, erreur « not found » et gcompat

Le symptôme typique : vous téléchargez un outil livré en binaire (agent de supervision, client d'un service, serveur de jeu, CLI propriétaire), vous le rendez exécutable, et le shell répond not found alors que le fichier est bien là. Ce n'est pas le fichier qui manque, c'est son interpréteur : le binaire demande le chargeur de glibc, /lib64/ld-linux-x86-64.so.2, qui n'existe pas sur Alpine, dont le chargeur s'appelle /lib/ld-musl-x86_64.so.1. La commande file (paquet file) ou scanelf -i (paquet pax-utils) affiche l'interpréteur attendu :

file ./monoutil
# ... dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2 ...

La réponse d'Alpine s'appelle gcompat, « couche de compatibilité glibc pour musl », version 1.1.0 dans le dépôt main. Le paquet fournit et remplace l'ancien libc6-compat. Il installe un faux chargeur portant le nom du chargeur glibc, qui redirige le binaire vers musl et précharge libgcompat.so.0, puis des liens libc.so.6, libm.so.6, libpthread.so.0, libresolv.so.2 ou libcrypt.so.1 qui pointent vers cette bibliothèque :

apk add gcompat
./monoutil

Ses limites sont écrites noir sur blanc dans son README : gcompat ne fournit aucun en-tête et ne permet pas de compiler un logiciel qui exige glibc ; il ne couvre que x86, x86_64, aarch64, ARM 32 bits et ppc ; il ne garantit pas qu'un binaire donné fonctionne, et il annonce par défaut une fausse version de glibc (GLIBC_FAKE_VERSION, « 2.8 ») à ceux qui la demandent. C'est un dépannage honnête pour un petit outil, pas une base pour une application de production. Pour celle-ci, deux solutions propres : une version compilée pour musl (c'est ce que produisent Go et Rust en statique) ou une image glibc.

Deux cas concrets de serveurs de jeu illustrent la question. FiveM : l'archive Linux de FXServer (fx.tar.xz) contient une arborescence alpine/ complète avec sa propre musl, et une image Docker peut la lancer depuis scratch sans aucune libc de l'hôte. Autrement dit, FXServer embarque son Alpine : installer la distribution hôte en Alpine n'apporte rien, et un hôte Debian ou Ubuntu reste le plus simple pour MariaDB, txAdmin et les outils autour, comme le montre notre guide FiveM dans Docker sur un VPS Linux. La documentation Cfx.re ne cite d'ailleurs que Debian et Ubuntu et présente le port Linux comme fourni « à titre de courtoisie ». Rust et les autres serveurs Steam : SteamCMD, l'outil qui télécharge le serveur, est un programme 32 bits qui attend les bibliothèques glibc 32 bits ; les images Docker qui le font tourner partent de debian:bookworm-slim et installent lib32gcc-s1 et lib32stdc++6. Aucune version musl n'est proposée : un serveur Rust se monte sur Debian ou Ubuntu.

malloc : pourquoi Node, Python ou Java peuvent ralentir sous musl

musl utilise depuis sa version 1.2.1 (août 2020) un nouvel allocateur, mallocng, conçu pour résister aux débordements de tas, détecter les doubles libérations et limiter la fragmentation. Ces protections ont un prix : quand plusieurs threads allouent et libèrent de la mémoire en même temps, ils se disputent un verrou. La glibc, avec ses arènes par thread, encaisse mieux cette charge.

Les mesures publiées vont toutes dans le même sens. Nick Babcock a documenté en février 2025 un serveur Rust dont un test de référence passait de 0,17 s sous glibc à 1,18 s sous musl, soit environ sept fois plus lent, avec 6,7 s passées dans l'appel futex contre 0,5 s et près de 200 000 changements de contexte au lieu de 1 200 : la signature d'un verrou contesté. La documentation de Bell-SW mesure un script Python à dix threads qui lit /proc/kallsyms : 0,685 s avec le malloc de musl, 0,439 s avec celui de glibc, et 0,451 s sous musl dès qu'on remplace l'allocateur par mimalloc. Un seul scénario ne fait pas une loi, mais l'ordre de grandeur est là : sur une charge multi-thread qui alloue beaucoup, comptez entre 30 % et plusieurs fois plus lent tant que vous gardez l'allocateur par défaut.

Qui est concerné ? Pas le tas JavaScript de V8 ni le tas Java, que leurs moteurs gèrent eux-mêmes. Mais la JVM appelle malloc pour le code compilé par le JIT, les appels JNI, les buffers de compression et les threads ; Node.js l'utilise pour les Buffer, le pool de threads de libuv et les modules natifs ; Python passe par lui pour tout objet de plus de 512 octets, pymalloc ne gérant que les petits. Plus votre application a de workers ou de threads, plus l'effet se voit.

Le remède, si vous tenez à Alpine, est de précharger un autre allocateur. Les paquets jemalloc (5.3.0, dépôt main) et mimalloc2 (2.2.7, dépôt community) sont disponibles dans la branche 3.24 ; apk info -L donne le chemin exact de la bibliothèque à charger :

apk add jemalloc
apk info -L jemalloc | grep '\.so'
LD_PRELOAD=/usr/lib/libjemalloc.so.2 node server.js

Dans un Dockerfile, la même chose se fait avec une instruction ENV LD_PRELOAD=.... Mesurez avant et après sur votre charge réelle, pas sur un test synthétique. Second point à connaître : la pile par défaut d'un thread fait 128 Ko sous musl contre plusieurs mégaoctets sous glibc. Un programme à récursion profonde qui tournait sans souci sur Debian peut planter sur Alpine ; des utilisateurs de Python l'ont constaté. La JVM n'est pas touchée, car elle fixe elle-même la taille de pile de ses threads (option -Xss). Si vous surveillez la mémoire de votre VPS, notre guide comprendre l'OOM killer aide à distinguer un plantage de pile d'un manque de RAM.

Ce que chaque écosystème supporte officiellement

• Python. Les paquets précompilés (wheels) pour Linux ciblaient glibc avec le tag manylinux. La PEP 656, finalisée en 2021, a créé le tag musllinux (par exemple musllinux_1_2_x86_64) : quand un projet publie ce wheel, pip l'installe en quelques secondes sur Alpine ; quand il ne le publie pas, pip compile depuis les sources et il vous faut gcc, musl-dev et les en-têtes de chaque dépendance. En 2020, avant la PEP 656, une image pandas et matplotlib se construisait en 30 s sur python:3.8-slim et en près de 26 minutes sur python:3.8-alpine, pour 363 Mo contre 851 Mo. L'auteur de ces mesures note en 2026 que les wheels musl ont réduit le problème, sans le faire disparaître pour tous les paquets. La page Docker Hub de l'image python prévient encore que musl « peut poser problème selon les besoins de la bibliothèque C du logiciel ».
• Node.js. Le projet classe Linux x64 avec musl 1.2.5 ou plus récent (donc Alpine 3.22 et suivantes) en Tier 2, contre Tier 1 pour glibc, et son tableau ne comporte aucune ligne musl pour arm64. Des archives officielles linux-x64-musl sont publiées à chaque version (par exemple node-v24.22.2-linux-x64-musl.tar.xz). Les modules natifs précompilés visent souvent glibc ; sur Alpine, ils se recompilent avec python3, make et g++, ou disposent d'une variante musl. Pour un VPS classique, notre guide installer et sécuriser Node.js avec nvm part de Debian ou Ubuntu.
• Java. La JEP 386 a intégré le port Alpine et musl dans OpenJDK 16, pour x64 et AArch64 ; seule l'attache du Serviceability Agent de HotSpot n'est pas prise en charge. Les images eclipse-temurin:<version>-alpine en sont la déclinaison officielle. Un serveur Minecraft Paper, Forge ou Fabric tourne donc sur Alpine, voir plus bas pour savoir si c'est une bonne idée.

Images Docker : alpine ou debian-slim, chiffres à jour

L'argument numéro un d'Alpine est la taille. Voici les tailles compressées des images officielles pour amd64, telles que l'API de Docker Hub les donnait le 8 novembre 2026 :

L'écart est à peu près constant, autour de 20 à 26 Mo : c'est le poids de la base Debian et de ses outils, pas celui du langage. Rapporté à une image Node de 60 à 80 Mo, il représente moins d'un quart ; rapporté à une image applicative avec son node_modules ou ses dépendances Python, il tombe à quelques pour cent. Sur un VPS, 26 Mo de plus par image ne changent ni le temps de docker pull ni l'espace disque de façon perceptible, et un nettoyage régulier des images compte bien davantage. Alpine fait vraiment la différence quand vous avez des dizaines de petits conteneurs, des sidecars, ou un binaire Go ou Rust statique qui n'a besoin de rien d'autre.

Le second argument est la surface d'attaque. Une image Alpine contient moins de paquets, donc moins de composants à mettre à jour et moins de lignes dans le rapport d'un scanner de vulnérabilités. C'est réel, mais à relativiser : ce qui compte pour un attaquant, c'est le service exposé et ses dépendances, pas les pages de manuel que debian-slim a déjà retirées. Et un projet léger reste une infrastructure à défendre, comme l'a rappelé l'attaque contre le GitLab d'Alpine Linux en octobre 2026.

Les mainteneurs des images officielles python et node écrivent la même phrase : sauf contrainte d'espace forte, « nous recommandons vivement l'image par défaut », et la variante Alpine convient « quand la taille finale est la préoccupation première ». Les variantes slim de Debian sont décrites comme « une expérience » qui retire ce qui ne sert pas dans un conteneur, pages de manuel et documentation en tête ; elles gardent glibc, apt et bash. Alpine, elle, s'appuie sur BusyBox : pas de bash ni de git par défaut, un shell ash, et des commandes grep, sed ou awk aux options réduites par rapport aux versions GNU, ce qui casse parfois un script d'entrée copié d'une image Debian.

Bonnes pratiques communes aux deux : épinglez la version (alpine:3.24, pas alpine:latest), installez avec apk add --no-cache, et séparez la compilation de l'exécution avec un build multi-étapes. Ce dernier point réconcilie souvent les deux mondes : vous compilez dans une image complète, puis vous copiez le résultat dans une image alpine si le binaire est statique, ou dans une image debian-slim s'il dépend de glibc. Si vous hésitez encore entre moteurs, notre comparatif Podman ou Docker sur VPS Linux ne change rien à ce choix d'image : la libc est celle de l'image, pas celle du moteur.

Alpine comme système d'un VPS : OpenRC, apk et support de deux ans

Hors conteneur, installer Alpine sur un VPS ou une machine virtuelle est un autre engagement. Les atouts annoncés par le projet sont réels : une installation minimale occupe environ 130 Mo de disque, tous les binaires sont compilés en PIE avec protection de pile, le gestionnaire de paquets apk est rapide, et l'init OpenRC se pilote par de simples scripts. Pour une passerelle VPN, un résolveur DNS, un relais mail ou un petit reverse proxy, cette sobriété est agréable.

En contrepartie, tout ce que vous savez de systemd ne s'applique plus : pas de systemctl, de journalctl ni de timers, mais rc-service, rc-update, un /var/log/messages et cron de BusyBox. Et surtout, le cycle de vie est court : Alpine ouvre une branche tous les six mois environ et la maintient deux ans. La branche 3.24 a été créée le 9 juin 2026 et sera supportée jusqu'au 1er juin 2028 ; la 3.21 est arrivée en fin de vie le 1er novembre 2026, et n'a reçu le correctif OpenSSH qu'à titre exceptionnel. Debian, de son côté, assure environ cinq ans par version avec Debian LTS (bookworm jusqu'au 30 juin 2028). Sur un VPS de production, cela veut dire une montée de version majeure tous les deux ans au plus sous Alpine, contre une tous les cinq ans sous Debian, comme nous l'expliquons dans notre guide migrer de Debian 12 vers Debian 13.

Pour identifier la libc d'un serveur ou d'un conteneur que vous reprenez :

cat /etc/os-release | grep -E '^(ID|VERSION_ID)='
cat /etc/alpine-release        # présent uniquement sur Alpine
apk info -v musl               # version de musl sur Alpine
ldd --version                  # version de glibc sur Debian et Ubuntu

Notre guide quelle distribution Linux pour un VPS replace Alpine parmi les autres choix possibles.

La règle de choix : quand garder Alpine, quand repasser sur Debian

En une phrase : gardez Alpine quand vous contrôlez tout ce qui tourne dedans et que c'est compilé pour musl ; repassez sur Debian dès qu'un binaire fourni par un tiers, un module natif ou un runtime multi-thread entre en jeu, et pour tout serveur de jeu. Le détail par cas :

Pour un serveur Minecraft, la question se pose surtout en conteneur : une image Temurin Alpine démarre très bien, mais c'est la RAM allouée à la JVM et le CPU qui font les TPS, pas les 26 Mo de la base. Notre guide héberger un serveur Minecraft moddé sur un VPS Linux part donc d'une Debian ou d'une Ubuntu, et nos recommandations pour optimiser les TPS ne dépendent pas de la libc.

Sur un VPS Linux KVM avec accès root, le choix de la distribution et des images vous appartient. Si vous gardez de l'Alpine quelque part, notez-le dans votre inventaire : la prochaine faille propre à musl, ou le prochain module qui refuse de se compiler, se traitera en quelques minutes au lieu d'une après-midi à chercher pourquoi « ça marchait sur Debian ».