Serveurs Ubuntu 24.04 : Snap vs apt — quand Snap cause discrètement des problèmes (et que faire)

Snap vs apt en une page : ce qui change sur un serveur

apt installe des paquets Debian (.deb) depuis des dépôts APT. Les fichiers arrivent dans les emplacements habituels du système de fichiers,
les bibliothèques sont partagées, les mises à jour sont contrôlées par votre politique APT, et les outils de gestion de configuration ont eu vingt ans pour apprivoiser la situation.
Quand vous mettez à jour, vous mettez à jour tout le graphe de dépendances que le dépôt fournit à ce moment. Vous pouvez garder des versions, bloquer des paquets et préparer des mises à jour.

Snap installe des images squashfs plus une couche runtime (snapd). Chaque application est plus autonome, embarque davantage de ses dépendances,
et s’exécute sous confinement (profils AppArmor, espaces de noms de montage, intégration cgroups, etc.). Les mises à jour sont principalement pilotées par
snap refresh (automatique par défaut), et les applications peuvent se mettre à jour indépendamment du reste de l’OS.
Cette séparation est à la fois l’objectif et le problème.

Réalité serveur, pas marketing

• Contrôle opérationnel : apt est « votre gestion des changements » ; Snap est « votre gestion des changements plus une seconde ».
  Si vous ne les alignez pas délibérément, vous finirez par trébucher sur la dérive.
• Disque et montages : Snap ajoute des périphériques loop et des montages. Ce n’est pas intrinsèquement mauvais, mais cela change ce que signifie « df affiche plein »
  et comment certains outils se comportent en conditions de pression.
• Modèle de sécurité : le confinement peut réduire le rayon d’impact, mais casse aussi des hypothèses sur les chemins de fichiers, les sockets et l’accès aux ressources de l’hôte.
• Dépendance réseau : Snap s’attend à communiquer avec le Snap Store. Proxys, inspection TLS, environnements isolés et egress restreint rendent cela… divertissant.

Mon biais : sur les serveurs de production, privilégiez par défaut apt sauf si Snap vous apporte un avantage spécifique, audité et opérable.
« C’était le défaut de l’image d’installation » n’est pas un avantage. C’est juste de l’entropie avec un logo.

Blague n°1 : Snap, c’est comme un minibar — pratique jusqu’à ce que vous vérifiiez la note et découvriez que vous avez payé pour de petites bouteilles de choses que vous possédez déjà.

Faits et histoire qui comptent vraiment

Ce ne sont pas des anecdotes de quiz. C’est le contexte qui explique pourquoi votre serveur Ubuntu 24.04 se comporte différemment de votre modèle mental.

1. Snap a commencé comme « snappy » pour Ubuntu Core et l’IoT, où les mises à jour atomiques et le bundling d’apps sont des fonctionnalités, pas des ennuis.
   Les serveurs ont hérité de cette approche de packaging plus tard, parfois sans les mêmes contraintes.
2. snapd s’exécute comme service système et gère les montages, le confinement et la planification des refresh. Sur un serveur minimal, c’est un démon de plus
   avec ses propres logs, timers et modes de défaillance.
3. Les snaps sont des images squashfs montées via des loop devices. C’est pourquoi vous voyez des périphériques /dev/loop* et des montages sous /snap.
4. Les revisions de Snap sont conservées pour le rollback (généralement plusieurs révisions). C’est utile quand un refresh vous casse, et aussi une raison pour laquelle l’usage du disque augmente en silence.
5. Le refresh est transactionnel au niveau Snap. Vous obtenez en général soit « l’ancienne révision fonctionne », soit « la nouvelle révision fonctionne », ce qui est excellent — jusqu’à ce que le refresh se produise
   durant votre heure de pointe.
6. Canonical a poussé certains paquets en distribution Snap-first au fil du temps. L’exemple classique est les navigateurs sur postes ; sur les serveurs, la pression apparaît
   quand « le paquet attendu » est remplacé ou déprécié.
7. Le confinement Snap s’appuie fortement sur AppArmor. Si vous désactivez AppArmor ou exécutez dans des contextes de sécurité inhabituels, le modèle de sécurité de Snap peut se dégrader ou échouer de façon étrange.
8. systemd s’intègre avec Snap via des unit files générés et des services gérés par snapd. Votre hypothèse habituelle « l’unité vit dans /etc/systemd/system » peut être fausse.

Une idée paraphrasée qui tient en ops : « l’espoir n’est pas une stratégie. » — attribuée au général Gordon R. Sullivan (paraphrasée).
Les choix de packaging sont une stratégie. Soit vous le choisissez, soit vous l’héritez.

Où Snap cause discrètement des problèmes (modes d’échec réels)

1) Mises à jour surprises en pleine charge

Snap refresh est automatique par conception. Le comportement par défaut est acceptable sur un laptop. Sur un serveur, « acceptable » est un synonyme de « finira par déclencher un pager ».
Le refresh peut redémarrer des services, remplacer des binaires et modifier le comportement sous une charge en cours d’exécution.

La partie pernicieuse n’est pas que des mises à jour arrivent. C’est qu’elles arrivent en dehors du chemin de contrôle des changements que votre équipe suit déjà pour apt,
la gestion de configuration et les fenêtres de maintenance.

2) Usage disque qui monte sans en avoir l’air

Snap conserve plusieurs révisions et stocke des données sous /var/snap et /var/lib/snapd.
Si vous utilisez de petits volumes racine (courant dans les images cloud), Snap peut vous pousser en territoire « racine 100% pleine » plus vite que prévu.
Pendant ce temps, la sortie de df devient plus bruitée à cause des images snap montées.

Le mode de défaillance est classique : la rotation des logs échoue, journald ne peut plus écrire, les opérations de paquet échouent, puis quelque chose d’important tombe.
Snap n’est pas le seul coupable, mais c’est un contributeur silencieux fréquent parce que ça ne ressemble pas à des « données d’app » pour ceux qui scannent vite l’usage du disque.

3) Le confinement casse des hypothèses d’intégration

Les snaps sont sandboxés. Super. Mais « sandboxé » signifie « votre app ne voit pas l’hôte comme vous pensez qu’elle le voit ».
Points douloureux courants :

• Accès à /etc et /var que vous supposez existants (ou écrits).
• Se lier à des ports privilégiés, ou utiliser le réseau de l’hôte de façons inattendues selon le snap et les connexions d’interfaces.
• Lire des certificats d’hôte, des clés SSH ou des bundles CA depuis les emplacements standard quand le snap utilise les siens.
• Communiquer avec des sockets d’hôte (socket Docker, activation systemd, sockets Unix personnalisés) sans les interfaces appropriées.

Dans les revues d’incident, cela apparaît souvent comme : « Mais le fichier de config est correct. » Oui. Le processus ne peut tout simplement pas le lire.

4) Dérive observabilité : logs, chemins et unités de service pas là où vous les attendez

Avec apt, vous savez où se trouve le fichier d’unité, où atterrissent les logs et où patcher les configs. Snap abstrait ces détails et les déplace parfois.
C’est vivable, mais ça vous ralentit sous pression.

5) Dépendance au Store et comportement de flotte sous réseaux contraints

Si vos serveurs vivent derrière des règles d’egress strictes, des proxys ou une inspection TLS, snap refresh peut échouer à répétition.
Les échecs répétés peuvent causer :

• Timers persistants qui se réveillent et font du travail (spam de logs, réveils CPU).
• Refresh bloqués qui empêchent d’autres opérations.
• Dérive partielle de la flotte : certaines machines se mettent à jour, d’autres non, et vous obtenez des mensonges du type « même version » dans les postmortems.

6) Surcharge de montages et de loop devices dans des environnements fragiles

La plupart des serveurs ne se soucieront pas de quelques montages supplémentaires. Certains le feront :

• Systèmes avec hypothèses strictes sur les namespaces de montage (certains conteneurs, outils basés sur chroot, ou scripts de durcissement).
• Monitoring legacy qui prend « plus de loop devices » pour « quelqu’un mine des cryptos ».
• Hôtes avec limites strictes sur les loop devices ou comportement initramfs étrange.

7) « Mais ça marchait hier » parce que le runtime a changé

Les mises à jour Snap peuvent tirer de nouveaux runtimes et bases (par exemple, core snaps). Cela peut changer subtilement le comportement TLS, les ciphers par défaut
ou le comportement des bibliothèques embarquées. Vous ne le verrez pas dans l’historique apt. Vous le verrez comme une erreur de handshake client et un sentiment croissant d’angoisse.

Blague n°2 : Quand Snap dit qu’il « refresh », il n’offre pas à votre serveur une journée au spa — il redécore la cuisine pendant le service du dîner.

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

Voici des tâches que vous pouvez exécuter sur Ubuntu 24.04 tout de suite. Chaque tâche inclut : une commande, une sortie réaliste, ce que ça signifie et la décision à prendre.
Elles sont écrites pour les personnes qui doivent réparer les choses, pas débattre de la philosophie du packaging.

Tâche 1 : Identifier si Snap est installé et actif

cr0x@server:~$ systemctl status snapd --no-pager
● snapd.service - Snap Daemon
     Loaded: loaded (/usr/lib/systemd/system/snapd.service; enabled; preset: enabled)
     Active: active (running) since Mon 2025-12-29 08:11:22 UTC; 2h 14min ago
TriggeredBy: ● snapd.socket
   Main PID: 1123 (snapd)
      Tasks: 14 (limit: 18956)
     Memory: 54.7M
        CPU: 1min 12.333s
     CGroup: /system.slice/snapd.service
             └─1123 /usr/lib/snapd/snapd

Ce que ça signifie : snapd tourne et est activé. Les refresh et montages Snap sont en jeu.

Décision : Si c’est un serveur de production et que Snap n’est pas explicitement requis, prévoyez de le supprimer/désactiver ou de bloquer le comportement de refresh.

Tâche 2 : Lister les snaps installés (et repérer les paquets « surprise »)

cr0x@server:~$ snap list
Name        Version           Rev   Tracking       Publisher   Notes
core22      20241001          1380  latest/stable  canonical✓  base
lxd         5.21              33110 5.21/stable    canonical✓
snapd       2.63.1            23159 latest/stable  canonical✓  snapd

Ce que ça signifie : Vous exécutez LXD depuis Snap, plus la base et snapd lui-même.

Décision : Confirmez la propriété : votre équipe plateforme prend-elle en charge LXD en snap ? Sinon, migrez vers les paquets apt (si disponibles) ou documentez Snap comme dépendance.

Tâche 3 : Voir quand Snap rafraîchira ensuite (et s’il est bloqué)

cr0x@server:~$ snap refresh --time
timer: 00:00~24:00/4
last: today at 06:17 UTC
next: today at 10:19 UTC

Ce que ça signifie : Le refresh Snap peut arriver n’importe quand dans la journée, approximativement toutes les 4 heures selon la politique.

Décision : Sur les serveurs, fixez une fenêtre de refresh alignée sur votre fenêtre de maintenance, ou mettez les refresh en pause temporairement pendant les événements critiques.

Tâche 4 : Définir une fenêtre de refresh (contrôle fenêtre de maintenance)

cr0x@server:~$ sudo snap set system refresh.timer=Sun03:00-05:00

Ce que ça signifie : Snap tentera de refresh le dimanche de 03:00 à 05:00.

Décision : Utilisez une fenêtre qui reflète votre réalité on-call. Si votre fenêtre de maintenance est « jamais », votre système fonctionne déjà sur des ondoiements.

Tâche 5 : Bloquer les refresh pendant un gel (court terme, pas pour toujours)

cr0x@server:~$ sudo snap refresh --hold=24h
General refreshes of "all snaps" held until 2025-12-30T08:33:10Z

Ce que ça signifie : Vous avez mis en pause les refresh pendant 24 heures.

Décision : Utilisez ceci pendant la réponse à incident ou les lancements majeurs. Créez un ticket de suivi pour lever le hold et patcher intentionnellement.

Tâche 6 : Vérifier si un snap refresh a récemment redémarré un service

cr0x@server:~$ journalctl -u snapd --since "today" --no-pager | tail -n 12
Dec 29 06:16:59 server snapd[1123]: Refreshing "lxd"
Dec 29 06:17:21 server snapd[1123]: Restarted snap.lxd.daemon.service
Dec 29 06:17:22 server snapd[1123]: Refreshing "core22"
Dec 29 06:17:35 server snapd[1123]: Finished refresh, 2 snaps updated

Ce que ça signifie : LXD a été rafraîchi et son daemon redémarré.

Décision : Si vous n’avez pas planifié ce redémarrage, serrez le contrôle des refresh et ajoutez de la supervision pour les redémarrages déclenchés par snap.

Tâche 7 : Identifier les unités systemd gérées par snap

cr0x@server:~$ systemctl list-units --type=service | grep -E '^snap\.'
snap.lxd.activate.service          loaded active exited  Service for snap application lxd.activate
snap.lxd.daemon.service            loaded active running Service for snap application lxd.daemon
snap.snapd.apparmor.service        loaded active exited  Load AppArmor profiles managed internally by snapd

Ce que ça signifie : Ce sont des unités générées par snap ; les éditer directement est en général une mauvaise idée.

Décision : Utilisez les options de configuration snap ou des drop-ins systemd (avec prudence) et documentez ce qui est pris en charge.

Tâche 8 : Comprendre les loop devices et montages ajoutés par Snap (bruit disque/montage)

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,MOUNTPOINT | grep -E 'loop|NAME'
NAME   TYPE   SIZE MOUNTPOINT
loop0  loop  74.2M /snap/core22/1380
loop1  loop  95.3M /snap/lxd/33110
loop2  loop  53.6M /snap/snapd/23159

Ce que ça signifie : Chaque révision de snap est une image squashfs montée via loop.

Décision : Ne « nettoyez » pas manuellement les loop devices. Si le disque est serré, réduisez les révisions conservées et supprimez les snaps inutilisés.

Tâche 9 : Mesurer combien d’espace Snap utilise (et où)

cr0x@server:~$ sudo du -sh /var/lib/snapd /var/snap 2>/dev/null
1.3G	/var/lib/snapd
612M	/var/snap

Ce que ça signifie : Vous dépensez ~2 Go pour l’infrastructure Snap et les données d’apps snap.

Décision : Sur de petits volumes racine, soit budgétez de l’espace pour Snap, soit supprimez-le. Si vous le conservez, configurez la rétention et surveillez /var.

Tâche 10 : Réduire les révisions conservées (contrôle disque)

cr0x@server:~$ sudo snap set system refresh.retain=2

Ce que ça signifie : Snap conservera moins d’anciennes révisions (la valeur par défaut est souvent plus élevée).

Décision : Paramétrez retain à 2 sur les serveurs sauf si vous avez une forte politique de rollback nécessitant plus, et que votre budget disque le supporte.

Tâche 11 : Revenir à une version précédente après un mauvais refresh

cr0x@server:~$ sudo snap revert lxd
lxd reverted to 5.21

Ce que ça signifie : Vous êtes revenu à la révision précédente conservée par snapd.

Décision : Traitez revert comme une étape de stabilisation. Ensuite : geler les refresh, ouvrir un incident et planifier une correction contrôlée vers l’avant.

Tâche 12 : Trouver les connexions d’interfaces Snap (pourquoi l’accès est refusé)

cr0x@server:~$ snap connections lxd | head
Interface  Plug            Slot                 Notes
network    lxd:network     :network             -
network-bind lxd:network-bind :network-bind     -
mount-observe lxd:mount-observe :mount-observe  -

Ce que ça signifie : Les snaps utilisent des interfaces pour les permissions. Des connexions manquantes peuvent causer des « permission denied » même pour des services exécutés en root.

Décision : Si un snap ne peut pas accéder à quelque chose, vérifiez les interfaces avant de réécrire les permissions de fichiers à l’aveugle. Utilisez snap connect seulement quand vous comprenez le compromis de sécurité.

Tâche 13 : Repérer les timers de refresh Snap et ce qu’ils feront

cr0x@server:~$ systemctl list-timers --all | grep -E 'snap|apt' | head -n 20
snapd.refresh.timer         loaded active waiting   Tue 2025-12-29 10:19:00 UTC  1h 41min left
apt-daily.timer             loaded active waiting   Tue 2025-12-29 06:12:41 UTC  21h left
apt-daily-upgrade.timer     loaded active waiting   Tue 2025-12-29 06:27:10 UTC  21h left

Ce que ça signifie : Vous avez deux planificateurs de mises à jour indépendants : les timers apt et le timer de refresh snapd.

Décision : Alignez-les avec votre plan de maintenance. Si vous utilisez un système de patch centralisé, envisagez de désactiver les timers par défaut et de piloter les mises à jour explicitement.

Tâche 14 : Confirmer si une commande donnée est un snap, pas un deb

cr0x@server:~$ command -v lxd
/snap/bin/lxd

Ce que ça signifie : Vous exécutez le binaire fourni par le snap, pas un paquet installé via apt.

Décision : Dans les runbooks, notez les chemins. En incident, vérifiez quel binaire tourne avant de supposer des emplacements de configuration et des chemins de mise à jour.

Tâche 15 : Vérifier les équivalents apt et ce qui est installé

cr0x@server:~$ apt-cache policy lxd | sed -n '1,12p'
lxd:
  Installed: (none)
  Candidate: 1:0.0~git20240301.abcdef-0ubuntu1
  Version table:
     1:0.0~git20240301.abcdef-0ubuntu1 500
        500 http://archive.ubuntu.com/ubuntu noble/universe amd64 Packages

Ce que ça signifie : LXD est disponible via apt, mais n’est pas installé. Vous exécutez la version snap.

Décision : Choisissez un canal de packaging par service. Les installations mixtes causent des bugs fantômes et des comportements « dépend de l’hôte ».

Tâche 16 : Supprimer proprement un snap (si vous optez pour apt-first)

cr0x@server:~$ sudo snap remove --purge lxd
Remove "lxd" snap
lxd removed

Ce que ça signifie : Le paquet snap et ses données ont été supprimés (purge).

Décision : Ne faites cela qu’après avoir migré les données et validé le plan de déploiement basé sur apt. Purge n’est pas « peut-être ». Purge, c’est « je le pense vraiment ».

Tâche 17 : Désactiver snapd (si vous devez garder le paquet mais stopper le comportement)

cr0x@server:~$ sudo systemctl disable --now snapd.service snapd.socket
Removed "/etc/systemd/system/multi-user.target.wants/snapd.service".
Removed "/etc/systemd/system/sockets.target.wants/snapd.socket".

Ce que ça signifie : snapd est arrêté et ne redémarrera pas automatiquement via le socket.

Décision : Si des composants critiques sont des snaps, cela les cassera. N’utilisez ceci que lorsque vous avez vérifié que l’hôte est exempt de snaps, ou si vous prenez volontairement la casse.

Tâche 18 : Prouver que snapd n’est plus fonctionnel (vérification)

cr0x@server:~$ snap list
error: cannot communicate with server: Post "http://localhost/v2/snaps": dial unix /run/snapd.socket: connect: no such file or directory

Ce que ça signifie : Le client snap ne peut pas parler à snapd. Bien — si c’était votre intention.

Décision : Mettez à jour vos contrôles de base et images dorées pour ne pas vous retrouver avec des hôtes à moitié gérés.

Playbook de diagnostic rapide : que vérifier en premier/deuxième/troisième

C’est la séquence « ça brûle et j’ai 15 minutes » pour la douleur liée à Snap sur serveurs Ubuntu 24.04.
L’objectif n’est pas de faire élégant. L’objectif est d’être juste rapidement.

Premier : Quelque chose s’est-il rafraîchi ou redémarré ?

• Vérifiez le timing des refresh Snap :

  cr0x@server:~$ snap refresh --time
  timer: 00:00~24:00/4
  last: today at 06:17 UTC
  next: today at 10:19 UTC

  Interprétation : Si last correspond au début de l’incident, suspectez un changement induit par un refresh.

• Vérifiez les logs snapd pour des redémarrages :

  cr0x@server:~$ journalctl -u snapd --since "today" --no-pager | grep -E 'Refreshing|Restarted' | tail -n 20
  Dec 29 06:16:59 server snapd[1123]: Refreshing "lxd"
  Dec 29 06:17:21 server snapd[1123]: Restarted snap.lxd.daemon.service

  Interprétation : Snap a fait quelque chose. Maintenant il faut décider de revert/hold.

Deuxième : La douleur vient-elle du disque, CPU, réseau ou des permissions ?

• Pression disque (root/var):

  cr0x@server:~$ df -h / /var
  Filesystem      Size  Used Avail Use% Mounted on
  /dev/vda1        30G   28G  1.2G  96% /
  /dev/vda1        30G   28G  1.2G  96% /var

  Interprétation : Vous êtes à une montée de log d’un mauvais jour. La rétention Snap et /var/lib/snapd sont des suspects principaux.

• Churn CPU dû aux tentatives de refresh:

  cr0x@server:~$ top -b -n 1 | head -n 12
  top - 10:41:10 up  1 day,  2:30,  1 user,  load average: 1.21, 1.05, 0.88
  Tasks: 231 total,   1 running, 230 sleeping,   0 stopped,   0 zombie
  %Cpu(s):  9.0 us,  2.1 sy,  0.0 ni, 88.2 id,  0.3 wa,  0.0 hi,  0.4 si,  0.0 st
  MiB Mem :  3906.7 total,   612.3 free,  1298.4 used,  1996.0 buff/cache
  MiB Swap:  2048.0 total,  2048.0 free,     0.0 used.  2340.1 avail Mem
      PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
     1123 root      20   0 1349808  56032  19840 S   6.0   1.4   1:12.33 snapd

  Interprétation : snapd consomme du CPU. Si cela coïncide avec des boucles de refresh ou des problèmes de connectivité au Store, corrigez le réseau/proxy et définissez une fenêtre de refresh.

• Problèmes de permissions ou de confinement:

  cr0x@server:~$ journalctl -u snap.lxd.daemon --since "today" --no-pager | tail -n 8
  Dec 29 06:18:04 server lxd[14555]: Error: failed to open /etc/lxd/cluster.crt: permission denied
  Dec 29 06:18:04 server lxd[14555]: Error: daemon failed to start

  Interprétation : Le service ne peut pas accéder à un chemin d’hôte. Vérifiez les interfaces snap et les attentes de confinement avant de « réparer » les permissions de fichiers à l’aveugle.

Troisième : Stabiliser, puis décider de la stratégie de canal

• Stabiliser : mettre en hold les refreshs et revert si nécessaire.

  cr0x@server:~$ sudo snap refresh --hold=24h
  General refreshes of "all snaps" held until 2025-12-30T10:44:22Z

• Décider : conserver Snap mais l’exploiter (fenêtres, monitoring, retention), ou le retirer et standardiser sur apt.

Trois mini-récits d’entreprise depuis le terrain

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

Une entreprise de taille moyenne opérait une flotte de serveurs Ubuntu hébergeant des outils internes aux développeurs : miroirs d’artefacts, runners CI, et un petit cluster LXD pour des environnements de test éphémères.
Ils étaient bons en patching : les mises à jour apt se déployaient en vagues hebdomadaires, avec canaris, tableaux de bord et une personne surveillant les budgets d’erreur.

Pendant un sprint chargé, les développeurs ont commencé à se plaindre que des conteneurs LXD échouaient à démarrer sur un sous-ensemble d’hôtes. L’ingénieur on-call a vérifié l’historique apt et n’a rien trouvé.
Le repo de config était inchangé. CPU et mémoire allaient bien. Les hôtes semblaient « identiques » sur le papier.

La mauvaise hypothèse était simple : « Si c’est installé, c’est géré par apt. » En réalité, LXD était installé via Snap sur ces images parce que quelqu’un avait suivi un guide upstream des mois plus tôt.
Snap a rafraîchi LXD sur quelques hôtes plus tôt ce matin-là, redémarrant le daemon. La nouvelle révision a durci une règle de confinement et le daemon a cessé de lire un chemin de certificat qui se trouvait hors des accès autorisés du snap.

La correction a été rapide une fois qu’ils ont compris : snap revert pour stabiliser, snap refresh --hold pour arrêter la churn, puis une solution d’interfaces/chemins appropriée.
Le vrai travail a été le postmortem : ils ont ajouté un contrôle de base dans le provisionnement qui signalait tout hôte avec des snaps inattendus installés, et ils ont documenté « canaux de packaging supportés » pour les services centraux.

Personne n’a été licencié. Mais quelques runbooks ont été réécrits avec moins d’optimisme et plus de commandes.

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

Une autre organisation avait un projet de réduction des coûts : volumes racine plus petits sur instances cloud, envoi agressif des logs, et mandat pour « garder l’OS minimal ».
Ils ont basculé certains outils vers des snaps parce que les apps étaient autonomes et « réduiraient le bazar des dépendances ». Cette partie était vraie.

Le retour de bâton est venu de la simple arithmétique. Les révisions Snap se sont accumulées sur une flotte qui redémarrait rarement et n’avait presque jamais de maintenance manuelle.
Entre /var/lib/snapd, les anciennes révisions et les données d’application sous /var/snap, des machines avec racines de 20–30 Go ont commencé à flirtter avec 90% d’utilisation.
Pas assez pour alerter. Suffisamment pour être fragile.

Puis un incident « voisin bruyant » ailleurs a causé des pics de logs. Quelques hôtes ont franchi 100% d’utilisation, journald a cessé d’écrire, les checks de santé ont commencé à expirer, et l’orchestrateur a commencé à reprogrammer des workloads.
La reprogrammation a surchauffé les hôtes restants, et un problème disque ennuyeux est devenu une panne en cascade qui ressemblait à de « l’instabilité aléatoire de services ».

Leur « optimisation » visait à réduire la complexité de l’image de base. La réalité : ils ont introduit un second cache de packaging avec son propre comportement de rétention, et ils ne l’ont pas budgété.
Ils ont corrigé en définissant refresh.retain=2, en déplaçant certaines données hors des volumes racine, et — la partie que les gens zappent — en ajoutant un tableau de bord qui ventilait l’usage disque par catégorie,
incluant les chemins gérés par Snap. Si vous ne le mesurez pas, ça remplira quand même. Mais silencieusement.

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

Une équipe de services financiers exploitait des serveurs Ubuntu avec des fenêtres de changement strictes. Ils n’étaient pas anti-Snap, mais ils traitaient Snap comme toute autre source de changement :
programmer, observer et rendre réversible.

Leur baseline comprenait :
une fenêtre de refresh alignée au dimanche de maintenance,
une rétention de refresh réglée à 2,
de la supervision sur les redémarrages des unités snapd,
et un job CI simple comparant la sortie de snap list sur la flotte pour détecter la dérive.
Rien de sophistiqué. Juste de la discipline.

Un week-end, une mise à jour snap a introduit un changement de comportement dans un agent de monitoring. Quelques canaris ont mis à jour en premier (les fenêtres de refresh étaient échelonnées par groupe).
Les tableaux de bord ont immédiatement signalé le changement : le taux de reconnexion de l’agent a chuté, le CPU a légèrement augmenté, et les logs présentaient une nouvelle signature d’avertissement.

Parce que l’équipe avait une voie opérationnelle, la réponse a été ennuyeuse : hold des refresh sur la flotte, revert sur les canaris, ouvrir un ticket interne chez le fournisseur,
et retester en staging. La production n’a jamais subi d’impact large. Personne ne l’a appris via les clients.

Voici à quoi ressemble l’ingénierie de fiabilité la plupart des jours : vous empêchez l’excitation. C’est profondément pas sexy. Ça marche.

Erreurs courantes : symptôme → cause racine → correctif

1) Symptom : « Le service a redémarré tout seul »

Cause racine : un snap refresh a redémarré une unité systemd gérée par snap.

Correctif : Définir refresh.timer sur une fenêtre de maintenance ; surveiller les redémarrages snapd ; envisager de mettre en hold les refresh pendant les événements critiques.

2) Symptom : « Le système de fichiers racine se remplit lentement alors que les données d’app sont ailleurs »

Cause racine : révisions Snap et données snap sous /var/lib/snapd et /var/snap.

Correctif : Définir refresh.retain à 2 ; supprimer les snaps inutilisés ; budgéter l’espace ; surveiller explicitement les répertoires Snap.

3) Symptom : « Permission denied lecture /etc/… même en root »

Cause racine : confinement Snap et connexions d’interfaces manquantes ; le processus s’exécute dans un contexte restreint.

Correctif : Utiliser snap connections pour inspecter ; ajuster la config vers des chemins approuvés par snap ; connecter seulement les interfaces nécessaires en connaissance de cause.

4) Symptom : « snap refresh échoue en boucle, logs spam, CPU réveils »

Cause racine : egress restreint, problèmes de proxy, inspection TLS ou DNS empêchant l’accès au Store.

Correctif : Valider la connectivité sortante ; configurer le proxy pour snapd ; si vous ne pouvez pas supporter l’accès au Store, ne pas exécuter de snaps dans cet environnement.

5) Symptom : « Le monitoring montre beaucoup de loop devices ; quelqu’un panique sur une compromission »

Cause racine : comportement normal de Snap : chaque révision monte une image squashfs comme loop device.

Correctif : Éduquer le monitoring et les humains ; alerter sur l’usage disque et les événements de refresh, pas sur l’existence de loop devices.

6) Symptom : « Nous avons mis à jour via apt, mais le binaire en cours d’exécution n’a pas changé »

Cause racine : le binaire provient de /snap/bin et n’est pas géré par apt.

Correctif : Vérifier command -v, standardiser le canal de packaging et l’appliquer lors du provisionnement.

7) Symptom : « Les overrides systemd ne fonctionnent pas »

Cause racine : les unités générées par snap peuvent être régénérées ; éditer le fichier d’unité directement est fragile.

Correctif : Utiliser des drop-ins avec prudence ; préférer les options de configuration snap ; documenter quelles modifications survivent aux refresh.

8) Symptom : « Même app, comportement différent selon les hôtes »

Cause racine : dérive de refresh Snap (révisions différentes), surtout dans des flottes sans fenêtres de refresh cohérentes ou avec des refresh échoués sur certains nœuds.

Correctif : Comparer snap list sur la flotte ; imposer des fenêtres de refresh ; alerter sur le skew de version ; pour des services critiques, envisager apt avec versions épinglées.

Listes de contrôle / plan étape par étape

Plan A : Vous conservez Snap (mais l’exploitez sérieusement)

1. Inventaire des snaps sur chaque rôle serveur.

   cr0x@server:~$ snap list
   Name   Version   Rev   Tracking       Publisher   Notes
   snapd  2.63.1    23159 latest/stable  canonical✓  snapd

   Décision : Si un rôle a des snaps inattendus, arrêtez-vous et décidez de la propriété.

2. Définir une fenêtre de refresh alignée à la maintenance.

   cr0x@server:~$ sudo snap set system refresh.timer=Sun03:00-05:00
   

   Décision : Placez les mises à jour là où des humains sont présents.

3. Réduire la rétention sauf si le disque est abondant.

   cr0x@server:~$ sudo snap set system refresh.retain=2
   

   Décision : Si vous voulez un « rollback infini », achetez un « disque infini ». Sinon, gardez la rétention serrée.

4. Alerter sur les redémarrages snapd et des services gérés par snap.

   cr0x@server:~$ systemctl list-units --type=service | grep -E '^snap\.'
   snap.snapd.apparmor.service        loaded active exited  Load AppArmor profiles managed internally by snapd

   Décision : Traitez le refresh comme des déploiements. Faites-les remonter.

5. Documenter les attentes de confinement pour chaque snap (chemins, sockets, ports).

   cr0x@server:~$ snap connections snapd | head
   Interface  Plug         Slot           Notes
   network    snapd:network :network      -
   

   Décision : Si votre app nécessite une intégration hôte au-delà des interfaces standard, reconsidérez Snap pour cette app.

6. Exécuter des canaris : échelonnez les fenêtres de refresh par groupe.

   Décision : Vous voulez un petit rayon d’impact quand la prochaine mise à jour est « intéressante ».

Plan B : Vous optez pour apt-first (recommandé pour la plupart des serveurs de production)

1. Repérer les binaires fournis par snap dans votre PATH opérationnel.

   cr0x@server:~$ command -v lxd
   /snap/bin/lxd

   Décision : Si votre runtime critique est sous /snap/bin, planifiez la migration avant la suppression.

2. Migrer service par service (ne supprimez pas snapd en premier).

   cr0x@server:~$ snap list
   Name  Version  Rev  Tracking       Publisher   Notes
   lxd   5.21     33110 5.21/stable   canonical✓

   Décision : Supprimez un snap à la fois, vérifiez la fonctionnalité, puis continuez.

3. Supprimer proprement les snaps une fois migrés.

   cr0x@server:~$ sudo snap remove --purge lxd
   Remove "lxd" snap
   lxd removed

   Décision : Purge supprime les données. Faites des sauvegardes d’abord.

4. Désactiver snapd lorsque l’hôte est exempt de snaps.

   cr0x@server:~$ sudo systemctl disable --now snapd.service snapd.socket
   Removed "/etc/systemd/system/multi-user.target.wants/snapd.service".
   Removed "/etc/systemd/system/sockets.target.wants/snapd.socket".

   Décision : C’est un choix de politique. Faites-le respecter dans votre image de base.

5. Confirmer la propriété apt et épingler/mettre en hold si nécessaire.

   cr0x@server:~$ apt-mark showhold
   

   Décision : Pour les composants critiques, utilisez le pinning/hold apt et un déploiement contrôlé, pas « ce qui s’est mis à jour en dernier ».

6. Rendre difficile la réintroduction accidentelle de Snap via images dorées et contrôles CI.

   Décision : La dérive de packaging est une régression comme une autre. Testez-la.

FAQ

1) Snap est-il « mauvais » pour les serveurs ?

Pas intrinsèquement. C’est un second système de packaging avec des mises à jour automatiques, du confinement et des dépendances au Store.
Ce sont des caractéristiques acceptables quand elles correspondent à votre modèle opérationnel. Sur beaucoup de serveurs de production, elles ne le font pas — sauf si vous les gérez activement.

2) Quel est le risque Snap le plus important en production ?

Le changement non coordonné. L’auto-refresh qui redémarre des daemons hors fenêtre de maintenance est la manière n°1 dont Snap se transforme en pager.
Corrigez cela en premier : fenêtres de refresh, hold pendant les gels et monitoring.

3) Puis-je simplement désactiver le refresh Snap et l’oublier ?

Vous pouvez mettre les refresh en hold temporairement et contraindre leur timing. Mais figer les mises à jour définitivement, c’est comment vous créez un problème de sécurité
avec une belle interface. Si vous ne pouvez pas patcher les snaps de façon fiable, n’exécutez pas de snaps pour des services critiques.

4) Pourquoi Snap consomme-t-il de l’espace disque même après la suppression d’une app ?

Snap conserve des révisions, et snapd plus les bases prennent de la place. Si vous avez seulement supprimé une app, vous pouvez encore avoir des snaps de base.
Vérifiez snap list, du -sh /var/lib/snapd /var/snap et réduisez refresh.retain.

5) Pourquoi vois-je autant de loop devices ?

Chaque snap est une image squashfs montée présentée comme loop device. C’est normal.
L’action opérationnelle n’est pas « supprimer les loop devices ». C’est « contrôler combien de révisions sont conservées » et « surveiller l’usage disque intelligemment ».

6) Quelle est la manière la plus simple de savoir si un binaire vient de Snap ?

Utilisez command -v ou which. Si c’est sous /snap/bin, vous exécutez le snap.
Ensuite vérifiez snap list pour voir quelle révision et quel canal.

7) Les snaps sont-ils plus sûrs grâce au confinement ?

Le confinement peut réduire le rayon d’impact, oui. Mais la sécurité est une propriété du système : il vous faut aussi une cadence de patchs que vous contrôlez, de l’observabilité
et un modèle réseau qui supporte le Store. Un deb bien géré peut être plus sûr qu’un snap que vous n’actualisez jamais.

8) Et pour les environnements air-gapped ou à egress restreint ?

Supposez que Snap sera pénible à moins d’avoir une stratégie hors-ligne supportée et d’avoir testé le comportement des refresh de bout en bout.
Si vous ne pouvez pas garantir l’accès au Store (directement ou via un mécanisme approuvé), les dépôts apt que vous répliquez en interne sont généralement plus simples et prévisibles.

9) Si je conserve Snap, quels contrôles minimum dois-je appliquer ?

Définir une fenêtre de refresh, réduire la rétention, surveiller les redémarrages de snapd et des services gérés par snap, et auditer régulièrement la dérive de versions sur la flotte.
Si vous ne pouvez pas faire cela, vous ne « possédez » pas Snap — Snap vous possède.

10) Pourquoi le dépannage semble-t-il plus lent avec Snap ?

Parce que la cartographie mentale change : les unit files sont générés, les emplacements des logs et des données peuvent différer, les erreurs de confinement ressemblent à des permissions,
et les mises à jour se produisent sur un calendrier séparé. Une fois que vos runbooks incluent des vérifications spécifiques à Snap, ça devient plus facile.

Prochaines étapes pratiques

Décidez si vos serveurs sont apt-first ou opérés par Snap. Ne soyez pas « ce qui s’est passé historiquement ».
Une stratégie mixte est l’endroit où les bugs ne se reproduisent que le vendredi.

1. Inventaire : exécutez snap list sur chaque rôle serveur et enregistrez ce qui est installé.
2. Contrôle du changement : si Snap existe, définissez refresh.timer sur une vraie fenêtre de maintenance et refresh.retain=2.
3. Surveillance : alertez sur les événements de refresh snapd et les redémarrages des unités gérées par snap ; tracez la croissance de /var/lib/snapd.
4. Standardiser : pour les services critiques, choisissez un canal, documentez-le et faites-le respecter dans la construction de vos images et les contrôles CI.
5. Pratiquer le rollback : testez snap revert et votre stratégie de rollback apt en staging pour ne pas apprendre sous pression.

Ubuntu 24.04 est une plateforme serveur solide. Snap peut faire partie de cette histoire. Mais sur les serveurs, la commodité n’est pas une fonctionnalité à moins que vous puissiez l’exploiter.
Le meilleur système de packaging est celui qui ne vous surprend pas. Le second meilleur est celui que vous pouvez remettre en arrière avant que les clients ne le remarquent.