AlpineLinux est une distribution souvent utilisée pour des conteneurs (lxc/lxd, Docker, etc.) car la taille des images d'AlpineLinux est minuscule (seulement 6 Mo !). C'est un avantage réel, surtout si on a beaucoup de conteneurs. Si cette performance est remarquable, il est cependant nécessaire de prendre en compte l'ensemble des choix réalisés par la distribution. Sur le site web, il est clairement indiqué « Alpine Linux is a security-oriented, lightweight Linux distribution based on musl libc and busybox. ». Voyons quelles contraintes cela apporte :

Les performances de musl

AlpineLinux a fait le choix de musl comme bibliothèque C, contrairement à la plupart des distributions Linux qui utilisent la libc GNU. Il peut y avoir des problèmes de compilation ou d'exécution de logiciel qui ont été testées avec la glibc et pas avec musl mais nous n'avons jamais rencontré ce problème.

À l'exécution, musl est plus lente que la glibc. Par exemple, une compilation de cpython est deux fois plus lente qu'avec la glibc. C'est un problème connu des mainteneurs qui pourrait être résolu dans le futur en changeant d'allocateur mémoire. Mimalloc semble être une bonne piste à l'avenir, mais pour l'instant, il faut vivre avec ce niveau de performance.

L'environnement espace utilisateur

busybox

AlpineLinux utilise busybox pour les outils Unix de base. Busybox est un projet éprouvé et utilisé depuis de nombreuses années dans l'embarqué.

Ce choix permet de minimiser la taille des outils embarqués par Alpine.

Mais, si le développement de script shell est réalisé sur un système disposant des outils GNU, il est possible qu'il y ait des erreurs lors de son exécution sur un système Alpine car le comportement n'est pas exactement le même : par exemple, il peut manquer des paramètres à certains outils (en particulier lorsque ce sont des extensions GNU à la norme Unix). Dans ce cas, il faut modifier le code ou installer un paquet pour embarquer l'outil GNU que l'on souhaite.

systemd

AlpineLinux utilise les scripts de démarrage classique Unix (dans /etc/init.d/) et non systemd. Selon les besoins et préférences de chacun, cela peut être une qualité ou un défaut.

Les mises-à-jour

Mettre à jour une version mineure d'alpine à l'autre (par exemple de 3.14 à 3.15) est très vite réalisé en quelques minutes. Comparé à la migration d'une version stable de Debian à la suivante, c'est étonnant et confortable puiqu'il n'y a pas de messages bloquants affichant les Changelog de changement incompatible ou des différences de fichiers de configuration entre la version du maitenant et celle du système en cours. L'inconvénient étant que les services peuvent être non fonctionnels ensuite...

Ce comportement n'est pas forcément un problème si l'usage est celui de conteneurs Docker qui sont supprimés et reconstruits à chaque modification. Dans le cas d'un usage classique avec des mises-à-jour, ça l'est beaucoup plus. L'usage d'instantanés (snapshot) peut permettre de limiter le problème : une fois la mise-à-jour faite, si des problèmes sont présents, il faut restaurer l'instantané fait avant la mise-à-jour puis chercher quel est le problème sur la version mise-à-jour.

Conclusion

Ces différents défauts ne sont pas forcément rédhibitoires selon l'usage fait d'AlpineLinux (par exemple pour des environnements docker locaux jetables). Il semble cependant important de les prendre en compte et se demander s'ils sont bloquants ou non avant de décider d'utiliser AlpineLinux selon l'usage prévu.

Après avoir utilisé AlpineLinux pour nos conteneurs lxc, nous avons conclu que l'utilisation de Debian était plus adapté à nos besoins dans ce cadre. Les prochains conteneurs seront donc basé sur Debian et les anciens migrés au fur et à mesure.