Installation d’Alpine Linux 3.23.3 : Petit, rapide, sécurisé — et réellement utilisable

Pourquoi Alpine sur des systèmes réels (et quand ne pas l’utiliser)

Alpine Linux est la rare distribution dont le minimalisme n’est pas du cosplay. Elle est petite parce qu’elle est construite autour de musl libc et BusyBox, utilise OpenRC au lieu de systemd et garde les paquets serrés. Cette combinaison est excellente quand vous voulez :

• Une surface d’attaque réduite sur des boxes edge, des bastions ou des VM de type appliance.
• Des démarrages rapides et une gestion des services prévisible avec OpenRC.
• Des conteneurs non gonflés (Alpine reste une image de base courante).
• Des systèmes raisonnables parce que moins de composants sont installés par défaut.

Mais Alpine n’est pas une solution universelle. Évitez-la quand :

• Vous dépendez d’un agent propriétaire qui suppose glibc, systemd ou des chemins de distribution « standards ».
• Vous avez besoin d’une compatibilité maximale avec des binaires upstream et que vous ne voulez pas réfléchir aux différences de libc.
• Vous construisez un poste de travail où « minimal » devient rapidement « tout manque ».

Utilisez Alpine lorsque vous voulez Linux intentionnel, pas Linux qui se comporte comme les autres Linux.

Blague n°1 : Alpine est si petit que vous serez tenté de le placer où il ne devrait pas aller — comme sur la liste des « plateformes supportées » d’un fournisseur.

Une réalité opérationnelle : plus votre système de base est minimal, plus vous devez être discipliné à propos de l’observabilité, du rythme des mises à jour et de la gestion des configurations. Alpine vous permet de construire un serveur propre. Il vous permet aussi de construire volontiers un serveur silencieux. Le silence n’est pas la sérénité ; c’est l’absence de télémétrie.

Faits et histoire qui expliquent les étrangetés d’Alpine

Un peu de contexte rend les choix de conception d’Alpine moins étrangers et plus délibérés :

1. Alpine a commencé (mi-2000s) comme une distribution axée sur la sécurité inspirée par l’idée de systèmes petits et auditables plutôt que des installations « tout-en-un ».
2. musl libc a été choisi pour la simplicité et la correction, et il change des comportements subtils (DNS, locales, cas limites liés au threading) par rapport à glibc.
3. BusyBox fournit de nombreuses utilitaires dans un seul binaire ; pratique, mais parfois les options diffèrent de GNU coreutils. Des scripts qui supposent le comportement GNU peuvent casser.
4. OpenRC précède systemd et reste utilisable : init basé sur les dépendances, scripts lisibles, moins de couches. Ce n’est pas « vieux » ; c’est différent.
5. Alpine a popularisé la culture de l’image de base minimale dans les conteneurs, qui a ensuite influencé les attentes sur le comportement de Linux dans CI/CD.
6. apk (Alpine Package Keeper) est rapide et simple ; les dépôts sont curatorés avec un focus sur des builds propres et des valeurs par défaut raisonnables.
7. Des valeurs par défaut durcies ont longtemps été une thématique (par ex. PIE, stack-protector, RELRO), avec des réglages variant selon la version et le paquet.
8. Le mode « diskless » d’Alpine est un concept de première classe, pas un bricolage : exécuter depuis la RAM et écrire l’état sur un stockage persistant quand vous le souhaitez.

Ce ne sont pas des réponses de quiz. Elles prédisent un comportement opérationnel. Si vous déployez Alpine et que vous ne savez pas ce que musl, BusyBox et OpenRC impliquent, vous installez des surprises.

Une citation, parce que c’est toujours la meilleure posture opérationnelle dans n’importe quelle distribution : L’espoir n’est pas une stratégie. (Rudy Giuliani, souvent cité dans les cercles opérationnels)

Listes de contrôle / plan étape par étape (ce qu’il faut décider avant le démarrage)

Décisions à prendre d’emblée

• Mode de démarrage : BIOS vs UEFI. Si c’est un serveur de la dernière décennie, supposez UEFI sauf preuve du contraire.
• Agencement du stockage : disque unique vs RAID (RAID matériel, mdadm, ZFS, ou « disque cloud qui ment »).
• Système de fichiers : ext4 pour la correction basique ; XFS pour des charges avec de gros fichiers et du parallélisme ; btrfs seulement si vous voulez btrfs volontairement (instantanés, send/receive et la charge opérationnelle associée).
• Chiffrement : LUKS ou pas. Si c’est un laptop/edge : oui. Si c’est un serveur distant sans histoire de gestion des clés : ne pas improviser.
• Réseau : DHCP vs IP statique, et si vous avez besoin de VLANs/bonds.
• Modèle d’accès : uniquement clés SSH, pas d’authentification par mot de passe (recommandé). Décidez qui a sudo et comment auditer les changements.
• Temps : source NTP, fuseau horaire et si la machine doit être correcte même sans réseau.
• Mises à jour : suivez-vous uniquement les dépôts stables ? Épinglez-vous des paquets ? Avez-vous une fenêtre de maintenance ?
• Journaux : uniquement journaux locaux, ou redirection vers un système central. Décidez maintenant, pas après votre premier incident.

Checklist pré-vol (avant d’exécuter setup-alpine)

• Vérifiez que vous avez démarré de la manière que vous pensez (UEFI vs BIOS).
• Confirmez le nom du disque cible (/dev/sda vs /dev/nvme0n1), et s’il contient déjà des partitions importantes.
• Vérifiez l’état du lien et l’attribution IP (surtout sur des serveurs avec plusieurs NIC).
• Décidez d’où viendront vos clés autorisées SSH (coller, récupérer via gestion de configuration ou monter un ISO de seed).

Séquence d’installation (par défaut sensé)

1. Démarrer l’ISO Alpine.
2. Exécuter setup-alpine et répondre honnêtement aux invites.
3. Partitionner et installer sur disque (mode sys).
4. Premier démarrage depuis le disque.
5. Renforcer SSH et l’accès utilisateur.
6. Activer une base d’observabilité minimale mais réelle : journaux, synchronisation temporelle et hooks de monitoring basiques.
7. Hygiène des paquets : mises à jour, versions épinglées si nécessaire, et plan de rollback.

Parcours d’installation (setup-alpine, disque, utilisateurs, SSH)

Démarrer et obtenir un shell fiable

Démarrez l’ISO Alpine 3.23.3. Vous arriverez dans un shell root. Le flux d’installation d’Alpine est principalement setup-alpine, mais vous devez toujours vérifier que le monde correspond à vos attentes.

Tâche 1 : Confirmer le mode de démarrage (UEFI vs BIOS)

cr0x@server:~$ ls /sys/firmware/efi
efivars

Ce que la sortie signifie : Si /sys/firmware/efi existe (et contient efivars), vous avez démarré en mode UEFI.

Décision : UEFI signifie que vous devez créer une partition système EFI (ESP) et installer un chargeur de démarrage UEFI. BIOS signifie que vous n’en avez pas besoin.

Tâche 2 : Identifier les disques et partitions existantes

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
sda     240G disk
├─sda1    1G part vfat
└─sda2  239G part ext4

Ce que la sortie signifie : Ici sda est le disque ; il contient déjà une partition vfat de 1G (probablement une ESP) et une racine ext4.

Décision : Si c’est une réinstallation, vous pouvez l’effacer. Si ce n’est pas le cas, arrêtez-vous et confirmez que vous n’êtes pas sur le point d’effacer une base de données.

Tâche 3 : Mettre le réseau en marche (et le vérifier)

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00
eth0             UP             52:54:00:12:34:56

cr0x@server:~$ ip -br addr show eth0
eth0             UP             192.0.2.10/24

Ce que la sortie signifie : Le lien est up et vous avez une adresse IPv4.

Décision : Si vous n’avez pas d’adresse, décidez : DHCP (rapide, correct dans beaucoup d’environnements) ou statique (requis pour certains rôles serveur). Corrigez le réseau avant l’installation pour éviter des échecs lors de l’installation des paquets.

Exécuter l’installateur guidé

Utilisez l’outil attendu par Alpine. Ce n’est pas élégant, mais c’est fiable.

cr0x@server:~$ setup-alpine
...interactive prompts...

Ce que cela fait : configure le clavier, le nom d’hôte, le réseau, les dépôts, le fuseau horaire, le mot de passe root, le serveur SSH et lance le processus d’installation sur disque.

Décision : Lorsqu’on vous demande pour SSH, choisissez openssh. Si vous construisez quelque chose d’accessible sur le réseau, dropbear n’est pas le bon choix sauf si vous savez exactement pourquoi.

Modes d’installation sur disque : sys vs diskless

Alpine peut fonctionner en « diskless » (rootfs en RAM, état persistant sauvegardé sélectivement) ou en « sys » (OS installé normalement). Diskless est excellent pour les appliances et les nœuds edge en lecture seule. Pour un serveur général, choisissez sys. C’est plus simple, et vous passerez votre temps sur votre application plutôt que sur des bizarreries de persistance.

Partitionnement : restez basique sauf besoin spécifique

Pour la plupart des serveurs :

• UEFI : créer une ESP (vfat, 512M–1G) et une partition racine.
• Système de fichiers racine : ext4 pour un usage général ; XFS si vous savez en tirer profit.
• Swap : optionnel ; envisagez zram sur les systèmes à mémoire limitée ou si vous voulez éviter l’IO de swap.

Blague n°2 : Le partitionnement, c’est comme le café : tout le monde pense être expert jusqu’à ce qu’il en renverse par terre.

Tâche 4 : Confirmer la résolution DNS avant d’installer des paquets

cr0x@server:~$ cat /etc/resolv.conf
nameserver 192.0.2.53

cr0x@server:~$ nslookup dl-cdn.alpinelinux.org
Server:         192.0.2.53
Address:        192.0.2.53:53

Non-authoritative answer:
Name:   dl-cdn.alpinelinux.org
Address: 151.101.2.132

Ce que la sortie signifie : Votre résolveur est configuré et les requêtes DNS fonctionnent.

Décision : Si le DNS échoue, corrigez-le maintenant. N’« essayez pas l’installation quand même ». Les récupérations de paquets échoueront plus tard et vous perdrez du temps à déboguer la mauvaise couche.

Installer sur disque

Pendant setup-alpine, vous choisirez un disque et un mode d’installation. Si vous le faites manuellement après coup, vous exécuteriez :

cr0x@server:~$ setup-disk -m sys /dev/sda
...partitioning, formatting, installing...

Ce que la sortie signifie : Il partitionne, formate, installe des paquets et configure le démarrage.

Décision : Si vous avez besoin d’un partitionnement personnalisé (séparer /var, RAID, chiffrement), faites-le avant setup-disk puis pointez l’installateur vers la disposition préparée.

Premier démarrage

Redémarrez, retirez l’ISO et connectez-vous une fois sur la console. Ensuite passez à SSH et ne regardez plus en arrière.

Post-installation : le rendre utilisable, pas seulement minimal

Un OS minimal est un point de départ. Un serveur utilisable a : synchronisation temporelle, journaux, résolution de noms prévisible, SSH durci, une stratégie de patchs et suffisamment d’outils pour se déboguer lui-même quand il casse.

Tâche 5 : Vérifier les dépôts et mettre à jour les index

cr0x@server:~$ cat /etc/apk/repositories
https://dl-cdn.alpinelinux.org/alpine/v3.23/main
https://dl-cdn.alpinelinux.org/alpine/v3.23/community

cr0x@server:~$ apk update
fetch https://dl-cdn.alpinelinux.org/alpine/v3.23/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.23/community/x86_64/APKINDEX.tar.gz
v3.23.3-xx-gabcdef12345 [https://dl-cdn.alpinelinux.org/alpine/v3.23/main]
v3.23.3-yy-g12345abcdef [https://dl-cdn.alpinelinux.org/alpine/v3.23/community]
OK: 13234 distinct packages available

Ce que la sortie signifie : Les index ont été téléchargés ; vous suivez les dépôts v3.23.

Décision : Restez sur la branche de version (v3.23) pour la stabilité. Ne mélangez pas les dépôts edge en production sauf si vous aimez les chaînes de dépendances surprises.

Tâche 6 : Mettre à jour le système de base (contrôlé, pas imprudent)

cr0x@server:~$ apk upgrade
(1/3) Upgrading busybox (1.37.0-r0 -> 1.37.0-r1)
(2/3) Upgrading musl (1.2.5-r0 -> 1.2.5-r1)
(3/3) Upgrading openssh (9.9_p1-r2 -> 9.9_p1-r3)
OK: 178 MiB in 64 packages

Ce que la sortie signifie : Les paquets ont été mis à niveau en place ; les composants centraux ont été mis à jour.

Décision : Si cet hôte fait partie d’une flotte, consignez les mises à jour via l’automatisation et déployez par lots. Alpine est rapide ; votre plan de rollback peut ne pas l’être.

Durcissement SSH : des clés, pas de l’espoir

Sur Alpine, la configuration d’OpenSSH est là où vous l’attendez. La discipline est la même : désactiver l’authentification par mot de passe, restreindre la connexion root et garder la config lisible.

Tâche 7 : Inspecter l’état et la configuration du démon SSH

cr0x@server:~$ rc-service sshd status
 * status: started

cr0x@server:~$ sshd -T | grep -E 'passwordauthentication|permitrootlogin|pubkeyauthentication'
passwordauthentication no
permitrootlogin no
pubkeyauthentication yes

Ce que la sortie signifie : sshd tourne et la configuration effective désactive les mots de passe et la connexion root, autorise les clés.

Décision : Si vous avez encore l’authentification par mot de passe activée, corrigez-le avant d’exposer l’hôte. Si vous avez besoin d’un accès « break-glass », faites-le via la console, pas via une politique SSH faible.

Synchronisation temporelle : ennuyeux, correct, obligatoire

La dérive temporelle est la façon d’obtenir des échecs TLS « aléatoires » et un tracing distribué qui ressemble à de l’art moderne. Alpine utilise souvent chrony ou openntpd ; je préfère chrony pour la plupart des rôles serveur.

Tâche 8 : Installer et activer chrony

cr0x@server:~$ apk add chrony
(1/3) Installing libcap (2.71-r0)
(2/3) Installing chrony (4.6-r0)
(3/3) Installing chrony-openrc (4.6-r0)
OK: 182 MiB in 66 packages

cr0x@server:~$ rc-update add chronyd default
 * service chronyd added to runlevel default

cr0x@server:~$ rc-service chronyd start
 * Starting chronyd ... [ ok ]

cr0x@server:~$ chronyc tracking
Reference ID    : C0000201 (192.0.2.1)
Stratum         : 3
System time     : 0.000012345 seconds fast of NTP time
Last offset     : -0.000001234 seconds
RMS offset      : 0.000010000 seconds
Frequency       : 12.345 ppm fast

Ce que la sortie signifie : chrony suit une source temporelle ; l’offset est minime ; vous êtes cohérent.

Décision : Si le stratum est 16 ou la référence manquante, votre NTP ne fonctionne pas — corrigez le pare-feu, les routes ou la config NTP avant de faire confiance aux journaux.

Journaux : choisissez un défaut et gardez la cohérence

Alpine peut utiliser syslog-ng ou busybox syslogd. Pour des serveurs réels, choisissez syslog-ng sauf raison forte contraire. Il est flexible, bien connu et fonctionne avec les schémas de forwarding.

Tâche 9 : Vérifier que syslog tourne et que des journaux existent

cr0x@server:~$ rc-service syslog status
 * status: started

cr0x@server:~$ ls -lh /var/log | head
total 1.2M
-rw-r-----    1 root     adm        512.0K Feb  5 10:12 messages
-rw-r-----    1 root     adm        256.0K Feb  5 10:10 auth.log
-rw-r-----    1 root     adm        128.0K Feb  5 10:12 daemon.log

Ce que la sortie signifie : le service syslog tourne et des fichiers de logs sont écrits.

Décision : Si les logs n’existent pas, vous volez à l’aveugle. Corrigez la journalisation avant d’installer votre pile applicative. Votre réponse aux incidents future vous remerciera.

Outils de base : installez ce que vous utilisez toujours

Minimal ne veut pas dire impuissant. Installez des outils qui paient lors des incidents : curl, bind-tools, tcpdump, iperf3, lsblk (dans util-linux), strace, et un vrai éditeur si vous y tenez.

cr0x@server:~$ apk add curl bind-tools tcpdump iperf3 util-linux strace
(1/8) Installing curl (8.12.1-r0)
(2/8) Installing bind-tools (9.20.4-r0)
(3/8) Installing tcpdump (4.99.5-r0)
(4/8) Installing iperf3 (3.17.1-r0)
(5/8) Installing util-linux (2.40.2-r0)
(6/8) Installing strace (6.10-r0)
(7/8) Installing libpcap (1.10.5-r0)
(8/8) Installing ca-certificates (20241121-r0)
Executing busybox-1.37.0-r1.trigger
Executing ca-certificates-20241121-r0.trigger
OK: 220 MiB in 92 packages

Ce que la sortie signifie : Outils installés, certificats mis à jour.

Décision : Si vous construisez une appliance durcie, vous pouvez omettre certains outils. Pour les serveurs généraux, conservez-les. Déboguer sans eux, c’est se faire du mal volontairement.

Tâches pratiques (12+ commandes, sorties, décisions)

Voici les commandes que j’exécute sur des installations Alpine fraîches pour confirmer que la machine est réelle, accessible et supportable. Chaque tâche inclut ce que la sortie signifie et la décision à prendre.

Tâche 10 : Vérifier le noyau, l’architecture et la release

cr0x@server:~$ cat /etc/alpine-release
3.23.3

cr0x@server:~$ uname -a
Linux server 6.12.12-0-lts #1-Alpine SMP PREEMPT_DYNAMIC x86_64 GNU/Linux

Ce que la sortie signifie : Vous êtes sur Alpine 3.23.3 avec un noyau LTS.

Décision : Pour des serveurs, restez sur LTS à moins d’avoir besoin d’un pilote ou d’une fonctionnalité d’un noyau edge. « Noyau plus récent » n’est pas un plan de performance.

Tâche 11 : Confirmer la réalité CPU et mémoire (attraper les instances sous-dimensionnées)

cr0x@server:~$ grep -E 'model name|cpu cores' /proc/cpuinfo | head -n 4
model name      : Intel(R) Xeon(R) CPU
cpu cores       : 2
model name      : Intel(R) Xeon(R) CPU
cpu cores       : 2

cr0x@server:~$ free -m
              total        used        free      shared  buff/cache   available
Mem:           2048         210        1320           8         517        1710
Swap:             0           0           0

Ce que la sortie signifie : 2 vCPU, 2 Go de RAM, pas de swap.

Décision : Si cet hôte va exécuter quelque chose de JVM-ish, une base de données ou même des pics modérés, ajoutez du swap ou zram, ou redimensionnez. L’absence de swap va bien jusqu’à ce que ça ne soit plus le cas, et alors c’est violent.

Tâche 12 : Confirmer points de montage et types de systèmes de fichiers

cr0x@server:~$ findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS
/              /dev/sda2 ext4   rw,relatime
/boot/efi      /dev/sda1 vfat   rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro

Ce que la sortie signifie : La racine est ext4 ; l’ESP est vfat.

Décision : Si vous voyez ro de manière inattendue, vous avez probablement des erreurs de système de fichiers ou un mauvais périphérique. Ne déployez pas d’applications tant que vous ne comprenez pas pourquoi vous êtes en lecture seule.

Tâche 13 : Vérifier les signaux de santé du disque (exemple NVMe)

cr0x@server:~$ apk add nvme-cli
(1/1) Installing nvme-cli (2.10-r0)
OK: 224 MiB in 93 packages

cr0x@server:~$ nvme smart-log /dev/nvme0
critical_warning                    : 0
temperature                         : 34 C
available_spare                     : 100%
percentage_used                     : 1%
data_units_read                     : 123,456
data_units_written                  : 78,901

Ce que la sortie signifie : Pas d’avertissements critiques, faible usure.

Décision : Si critical_warning est non nul ou si la température est constamment élevée, planifiez une fenêtre de maintenance. Les pannes de stockage ne deviennent pas moins coûteuses avec le temps.

Tâche 14 : Vérifier l’ordonnanceur I/O et les indices de profondeur de file d’attente

cr0x@server:~$ cat /sys/block/sda/queue/scheduler
[mq-deadline] none kyber bfq

Ce que la sortie signifie : mq-deadline est actif.

Décision : En général, ne pas y toucher. Si vous êtes sur NVMe rapide et que la latence compte, testez none. Faites des benchmarks avec votre charge, pas avec des impressions d’optique.

Tâche 15 : Vérifier les runlevels OpenRC et services activés

cr0x@server:~$ rc-status -a
Runlevel: default
 sshd                                                         [  started  ]
 chronyd                                                      [  started  ]
 syslog                                                       [  started  ]

Ce que la sortie signifie : Ces services démarreront dans le runlevel par défaut.

Décision : Si quelque chose de critique n’est pas listé, ajoutez-le avec rc-update add. Si quelque chose de suspect est listé, retirez-le maintenant — pas plus tard.

Tâche 16 : Confirmer le chemin de résolution de noms (les nuances de musl apparaissent ici)

cr0x@server:~$ cat /etc/nsswitch.conf
hosts: files dns

cr0x@server:~$ getent hosts localhost
127.0.0.1       localhost

Ce que la sortie signifie : Ordre de résolution simple ; getent fonctionne.

Décision : Si le DNS d’entreprise repose sur du split-horizon et des suffixes de recherche, validez la chaîne complète (/etc/resolv.conf, suffixes de recherche et le comportement du résolveur de votre application). Le résolveur de musl peut différer de glibc dans des cas limites. Testez, n’assumez pas.

Tâche 17 : Mesurer la latence réseau et la correction du MTU

cr0x@server:~$ ping -c 3 192.0.2.1
PING 192.0.2.1 (192.0.2.1): 56 data bytes
64 bytes from 192.0.2.1: seq=0 ttl=64 time=0.401 ms
64 bytes from 192.0.2.1: seq=1 ttl=64 time=0.382 ms
64 bytes from 192.0.2.1: seq=2 ttl=64 time=0.396 ms

--- 192.0.2.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.382/0.393/0.401 ms

cr0x@server:~$ ping -c 2 -M do -s 1472 192.0.2.1
PING 192.0.2.1 (192.0.2.1): 1472 data bytes
1480 bytes from 192.0.2.1: seq=0 ttl=64 time=0.521 ms
1480 bytes from 192.0.2.1: seq=1 ttl=64 time=0.509 ms

Ce que la sortie signifie : La latence de base est correcte ; le chemin MTU 1500 supporte les pings DF avec une charge utile de 1472.

Décision : Si le test MTU échoue, vous pouvez avoir des trames jumbo mal appariées ou un tunnel avec un MTU plus petit. Corrigez cela avant d’accuser des timeouts gRPC « aléatoires ».

Tâche 18 : Vérifier les ports à l’écoute (confirmer l’exposition)

cr0x@server:~$ ss -lntup
Netid  State   Recv-Q  Send-Q   Local Address:Port   Peer Address:Port  Process
tcp    LISTEN  0       128      0.0.0.0:22           0.0.0.0:*          users:(("sshd",pid=712,fd=3))
udp    UNCONN  0       0        0.0.0.0:323          0.0.0.0:*          users:(("chronyd",pid=655,fd=5))

Ce que la sortie signifie : SSH est exposé ; chrony a une socket UDP.

Décision : Si vous voyez des listeners inattendus, arrêtez-vous et enquêtez. Le minimalisme d’Alpine ne vous protège pas de vos propres choix de paquets.

Tâche 19 : Vérifier l’état du pare-feu (nftables ou iptables)

cr0x@server:~$ apk add nftables
(1/1) Installing nftables (1.1.1-r0)
OK: 229 MiB in 96 packages

cr0x@server:~$ nft list ruleset
table inet filter {
        chain input {
                type filter hook input priority filter; policy drop;
                iif "lo" accept
                ct state established,related accept
                tcp dport 22 accept
        }
}

Ce que la sortie signifie : Politique par défaut drop, loopback autorisé, connexions établies autorisées, SSH autorisé.

Décision : C’est une base sensée pour un serveur sans interface graphique. Si votre politique est accept-all, soit vous êtes sur un réseau de confiance (rare), soit vous procrastinez.

Tâche 20 : Confirmer que les journaux système montrent les démarrages et services

cr0x@server:~$ tail -n 20 /var/log/messages
Feb  5 10:12:01 server syslog-ng[540]: syslog-ng starting up; version='3.38.1'
Feb  5 10:12:02 server sshd[712]: Server listening on 0.0.0.0 port 22.
Feb  5 10:12:03 server chronyd[655]: Selected source 192.0.2.1

Ce que la sortie signifie : Vous avez des preuves de démarrage de service et de synchronisation temporelle.

Décision : Si vous ne voyez pas de messages de service, votre pipeline de logs ne capture pas ce que vous pensez. Corrigez-le avant d’en avoir besoin.

Playbook de diagnostic rapide (trouver le goulot vite)

Quand quelque chose est lent, cassé ou instable, ne tergiversez pas. Alpine est minimal ; votre boucle de diagnostic doit l’être aussi. Vérifiez d’abord ce qui change vos décisions.

Première question : est-ce le réseau ou l’hôte ?

• Vérifier le lien et l’IP : ip -br link, ip -br addr. Si le lien est down, rien d’autre n’a d’importance.
• Vérifier la route par défaut : ip route. S’il n’y a pas de route par défaut, les fetchs sortants échouent et on blâme à tort le DNS.
• Vérifier le DNS : nslookup d’un nom connu. Si le DNS échoue, les installations de paquets et les handshakes TLS échouent « aléatoirement ».
• Vérifier le MTU rapidement : ping -M do -s 1472 vers votre gateway. Un mauvais MTU produit des comportements applicatifs bizarres, pas des échecs nets.

Deuxième question : I/O stockage, pression mémoire ou saturation CPU ?

• Mémoire : free -m. Si la mémoire disponible est faible et qu’il n’y a pas de swap, attendez-vous à des OOM kills ou des pics de latence.
• Disque plein : df -h. Des disques pleins causent des « cannot write », journaux corrompus et mises à jour de paquets cassées.
• I/O wait : installez sysstat si nécessaire, ou utilisez vmstat 1 pour voir les processus bloqués. Un iowait élevé signifie que le stockage est votre goulot, pas le CPU.
• Charge CPU : uptime et top. Si la charge est élevée avec une faible utilisation CPU, suspectez l’I/O ou des blocages de la file d’exécution.

Troisième question : est-ce le gestionnaire de services ou le service lui-même ?

• État du service : rc-service <name> status.
• Activé au démarrage : rc-status -a.
• Journaux : tail -n 100 /var/log/messages et les journaux propres à l’application.

Quatrième question : confirmer ce qui écoute et ce qui est joignable

• ss -lntup pour voir les listeners.
• curl -v ou nc -vz pour vérifier la connectivité depuis l’hôte.
• nft list ruleset pour confirmer que les règles du pare-feu correspondent à l’intention.

Le but d’un playbook n’est pas l’exhaustivité. C’est la vitesse. Vous voulez une « échelle de triage » fiable qui trouve la classe du problème avant que vous ne disputiez la cause.

Erreurs courantes : symptômes → cause racine → correctif

1) « apk update » se bloque ou échoue de façon intermittente

Symptômes : erreurs de fetch, échecs de handshake TLS, timeouts aléatoires.

Cause racine : mauvaise configuration DNS, route par défaut manquante, mismatch MTU, ou proxy/inspection dans les réseaux d’entreprise.

Correctif : vérifiez ip route, cat /etc/resolv.conf, test MTU ping, et si besoin définissez un miroir explicite et les paramètres proxy. Si vous êtes derrière un proxy interceptant, installez correctement les certificats CA d’entreprise.

2) SSH fonctionne en console mais pas à distance

Symptômes : connection refused, timeout, ou handshake mais échec d’authentification.

Cause racine : sshd non démarré/activé, pare-feu bloquant le port 22, binding sur la mauvaise interface ou permissions de clés erronées.

Correctif : rc-service sshd status, rc-update add sshd default, ss -lntup pour le port 22, validez la propriété de ~/.ssh/authorized_keys et chmod 600.

3) Un script shell fonctionne sur Ubuntu mais casse sur Alpine

Symptômes : « option invalide » venant d’outils comme sed, grep ou date.

Cause racine : les variantes BusyBox diffèrent des GNU coreutils.

Correctif : installez les outils GNU si nécessaire (apk add coreutils findutils grep sed) ou réécrivez les scripts pour un comportement POSIX. Envisagez aussi d’exécuter ces outils dans une image conteneur qui correspond à la production.

4) Un service « démarre » mais le port ne s’ouvre jamais

Symptômes : OpenRC dit started ; ss ne montre rien à l’écoute.

Cause racine : le service plante après avoir forké, répertoires runtime manquants, problèmes de permissions ou config pointant vers des chemins inexistants.

Correctif : vérifiez les logs dans /var/log, lancez le service au premier plan si possible, validez les chemins de configuration et assurez-vous que les répertoires runtime existent (surtout sous /run) et ont la bonne propriété.

5) « No space left on device » alors qu’il reste de l’espace disque

Symptômes : écritures échouent ; df -h montre de l’espace disponible.

Cause racine : épuisement d’inodes, un tmpfs /run plein, ou système de fichiers monté en lecture seule suite à des erreurs.

Correctif : vérifiez df -i, les options de mount et les messages du noyau. Si c’est en lecture seule, investigatez la santé du stockage et l’intégrité du FS avant de remonter.

6) « Pourquoi TLS échoue seulement sur cet hôte ? »

Symptômes : erreurs de vérification de certificat, échecs de confiance étranges.

Cause racine : ca-certificates manquants, mauvaise heure système ou MITM d’entreprise sans CA installée.

Correctif : installez ca-certificates, vérifiez l’heure via chrony et installez la CA d’entreprise dans le magasin de confiance si nécessaire. Ne désactivez pas la vérification pour « faire marcher » les choses. C’est ainsi qu’on construit un incident futur.

Trois mini-récits du monde de l’entreprise

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une équipe a déployé Alpine sur une petite flotte de gateways API internes. La motivation était solide : réduire la taille des images, accélérer les déploiements, moins de paquets, moins de CVE à suivre. La première semaine était excellente. Les déploiements se sont accélérés. L’équipe de sécurité a cessé d’envoyer des e-mails hebdomadaires « veuillez tout patcher » qui ressemblaient à des notes de rançon.

Puis une intégration partenaire a commencé à échouer en production, mais seulement depuis les gateways Alpine. Les retries aidaient, jusqu’à ce qu’ils n’aident plus. Le partenaire jurait que son endpoint était sain. L’équipe jurait que leur code n’avait pas changé. Ils avaient tous les deux techniquement raison, ce qui est la forme la plus agaçante de la justesse.

La mauvaise hypothèse : « DNS, c’est DNS ». Ils avaient modifié le comportement de résolution sans comprendre les différences de musl et la manière dont leur application gérait les suffixes de recherche et le caching négatif. Certaines requêtes résolvaient vers la mauvaise adresse backend sous une condition de split-horizon spécifique, et les échecs ressemblaient à des problèmes TLS intermittents.

La solution n’a pas été d’abandonner Alpine. C’était de configurer explicitement le comportement du résolveur, d’éliminer la dépendance accidentelle aux suffixes de recherche et d’ajouter un contrôle au démarrage qui validait la résolution FQDN cible avant que le service ne se considère sain. La leçon réelle : Alpine n’a pas cassé le DNS. Leur conception système dépendait de sontes implicites du résolveur, et changer l’OS de base les a fait remonter à la surface.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Un groupe plateforme a essayé de grappiller encore plus de vitesse dans les builds en standardisant Alpine pour les étapes de build et de runtime. Ils ont aussi décidé d’épurer agressivement les outils des images runtime. « Ambiance distroless », disaient-ils, tout en gardant discrètement un shell pour le débogage. C’est ainsi que naît le compromis.

Ça a marché jusqu’à ce qu’ils rencontrent une régression de performance en production qui ressemblait à un problème CPU. Le service était écrit dans un langage compilé, ils s’attendaient donc à un comportement similaire entre distributions. Ce ne fut pas le cas. Les percentiles de latence dérivaient sous charge. Rien d’évident : CPU OK, mémoire OK, réseau OK.

Le retour de bâton : leur optimisation a supprimé les outils exacts qui auraient prouvé ce qui se passait. Pas de strace, pas de ss, pas de tcpdump, pas de moyen facile de valider le comportement DNS et des logs limités. Ils ont perdu du temps à reproduire le problème ailleurs parce que les conteneurs de production étaient trop « minimaux » pour être inspectés.

Ils ont finalement trouvé une interaction de configuration impliquant la planification des threads et des retries DNS dans certaines conditions d’échec. La cause réelle était simple une fois visible — mais la visibilité était ce qu’ils avaient optimisé hors production. La remédiation fut un changement de politique : garder une image « debug » disponible et conserver assez d’observabilité en production pour répondre aux questions de premier ordre sans redéployer à l’aveugle.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe SRE a exécuté Alpine sur un ensemble de collecteurs edge : petites VM récupérant métriques et journaux depuis des segments réseau compliqués. Rien de glamour. Tout le monde voulait les réécrire. Personne ne voulait les maintenir. Territoire parfait pour Alpine.

L’équipe avait une habitude fastidieuse : traiter les mises à jour de l’OS de base comme n’importe quel autre changement. Fenêtre de patch hebdomadaire. Canary d’abord. Puis petits lots. Ils capturaient la diff des paquets et redémarraient quand le noyau ou la libc changeaient. Pas d’héroïsme, juste un calendrier et de la discipline.

Une semaine, une vulnérabilité a été publiée nécessitant des mises à jour sur toute la flotte. Le reste de l’organisation panique, débattant de la fenêtre d’arrêt et de la compatibilité. Les collecteurs edge Alpine ? Ils ont passé le pipeline existant. Le canary n’a montré aucune surprise. Le déploiement par lots s’est achevé selon le planning.

Les « économies » n’étaient pas mesurées en argent mais en chaos évité. La pratique correcte n’était pas exotique. C’était une maintenance régulière avec boucle de rétroaction. En opérations, « ennuyeux » n’est pas un manque d’ambition. C’est un manque d’incidents.

FAQ

1) Alpine Linux 3.23.3 est-il adapté aux serveurs de production ?

Oui, pour les bons serveurs : gateways, appliances, nœuds edge, services internes et charges de travail à périmètre restreint. Évitez-le là où le support fournisseur, des binaires glibc-only ou des outils centrés sur systemd sont obligatoires.

2) Dois-je utiliser musl ou installer une compatibilité glibc ?

Préférez les paquets et builds natifs musl. Si vous devez exécuter des binaires uniquement compatibles glibc, vous êtes déjà en exception — documentez-le, testez-le et attendez-vous à des cas limites. Ne laissez pas « juste ce binaire » devenir une norme de flotte.

3) OpenRC vs systemd : qu’est-ce que je perds ?

Vous perdez les outils et la sémantique spécifiques à systemd. Vous gagnez des scripts init plus simples et moins de couches. Pour beaucoup de services, OpenRC suffit totalement. L’important est de standardiser vos patterns de gestion des services et de ne pas prétendre que c’est systemd.

4) ext4 ou XFS sur Alpine ?

ext4 pour la plupart des serveurs généraux car il est prévisible et facile à récupérer. XFS pour de grands systèmes de fichiers, de l’I/O parallèle et des charges qui en bénéficient. Choisissez selon la charge et le plan de récupération, pas la mode.

5) Comment garder Alpine « réellement utilisable » sans l’alourdir ?

Installez une petite boîte à outils d’incident (curl, bind-tools, tcpdump, util-linux, strace), configurez la synchro temporelle, assurez-vous que les journaux existent et configurez SSH correctement. Utilisable n’est pas gonflé ; c’est supportable.

6) Ai-je besoin de swap sur Alpine ?

Pas toujours, mais il faut un plan pour la pression mémoire. Pour les petites VM, zram ou un swap modeste peut transformer un OOM catastrophique en latence gérable. Pour des charges sensibles à la latence, testez soigneusement.

7) Pourquoi certains scripts échouent sur Alpine ?

Les utilitaires BusyBox ne sont pas identiques aux outils GNU. Si votre script suppose des options GNU, installez les paquets GNU ou réécrivez pour POSIX. C’est la surprise Alpine la plus courante.

8) Comment confirmer que le système est sécurisé par défaut ?

N’assumez rien. Vérifiez : politique du pare-feu, configuration SSH, services en cours et état des mises à jour. « Sécurisé par défaut » est du marketing tant que vous n’avez pas inspecté qui écoute et ce qui est permis.

9) Le mode diskless en vaut-il la peine ?

Oui pour les appliances et nœuds principalement en lecture où vous voulez la résilience via l’immuabilité et root en RAM. Non pour des serveurs généraux sauf si vous êtes prêts à gérer la persistance intentionnellement.

Conclusion : prochaines étapes actionnables

Alpine Linux 3.23.3 peut être petit, rapide et sécurisé sans être un cauchemar de débogage auto-infligé. L’astuce est de l’installer comme vous comptez l’exploiter : choisissez un agencement de disque ennuyeux, vérifiez le réseau et le DNS avant de récupérer des paquets, durcissez SSH, activez la synchro temporelle et la journalisation, et gardez juste assez d’outils pour diagnostiquer la réalité.

Prochaines étapes :

• Notez votre baseline : choix de système de fichiers, politique de pare-feu, services activés et cadence de mises à jour.
• Automatisez les essentiels post-install (politique SSH, chrony, syslog, outils de base) pour que chaque nœud soit cohérent.
• Ajoutez un contrôle de santé rapide qui valide DNS, synchro temporelle et espace disque au démarrage — et échoue bruyamment quand c’est incorrect.
• Effectuez un exercice : simulez une panne DNS ou une condition disque-plein et confirmez que vous pouvez le diagnostiquer en minutes, pas en heures.

Le minimal est une fonctionnalité. L’opérable est une exigence. Alpine peut faire les deux — si vous arrêtez d’assumer et commencez à vérifier.