Bonjour à tous,

Aujourd’hui, je vais revenir sur la récente mise à jour du serveur et tout ce que ça a entrainé.

Contexte

Le serveur et le Raspberry

Tout d’abord, pour faire simple, j’ai un serveur chez Kimsufi sur lequel j’héberge la majorité de mes services. À la maison, j’ai un Raspberry Pi 4 (une version 8 Go de RAM qui est tout à fait agréable à utiliser) connecté à un disque dur. Le script qui effectue les sauvegardes du serveur commence par alimenter ce disque dur avec une prise 433 MHz.

Pour revenir sur le serveur, je l’avais installé à l’époque de Debian 9 puis fait la migration sous Debian 10. Presque 15 jours après la sortie de Debian 11 et profitant de mes vacances, je me suis lancé dans la mise à jour du serveur de Debian 10 vers Debian 11.

Par nature, Debian est un système d’exploitation très stable. Chaque version peut donc être utilisée sans soucis de compatibilité entre les logiciels par exemple. L’inconvénient à cela est que ces derniers sont rarement dans leurs toutes dernières versions.

Dans mon cas, tout est conteneurisé dans mon serveur, donc je choisis moi-même la version des services qui tournent sur le serveur. Je n’utilise pas d’orchestrateur mais simplement un script bash qui va lancer les docker-compose.yml décrivant mes services. En parallèle, toutes les données sont centralisées dans un dossier que l’on va appeler /data.

Je n’utilise pas de vrai orchestrateur car lorsque je me suis mis à Docker, je voulais maîtriser la chaine de bout en bout, ça pourrait être une évolution sympathique désormais.

Les machines de test

En plus du serveur et du Raspberry, j’ai également 2 machines virtuelles qui tournent sur Debian comme le serveur.

Le but est d’avoir une machine qui réplique le serveur et l’autre qui sert de client. J’ai donc également une copie du fameux dossier /data sur cette réplique. Je peux donc sans soucis faire des tests sur les machines virtuelles avant de déployer (ou non) sur le serveur de production.

La mise à jour

La procédure

Dans la théorie, la procédure de mise à jour de Debian 10 vers 11 est très simple:

apt update # pour mettre à jour la liste de dépôts
apt dist-upgrade # pour mettre à jour le système (sur la toute dernière version de Debian 10 pour l'instant)
sed -i 's/buster/bullseye/g' /etc/apt/sources.list # on remplace buster par bullseye
sed -i 's|bullseye/updates|bullseye-security|g' /etc/apt/sources.list # le paramètre semble avoir changé pour <debian-security>
# Vérifier également dans le dossier /etc/apt/sources.list.d/
apt update # on remet à jour la liste des dépôts avec les dépôts de Debian 11
apt full-upgrade # on met tout à jour, ça prend un peu de temps avec quelques questions à répondre
reboot # on vérifie que tout démarre toujours et on recharge tout proprement

Le test

Je teste tout d’abord sur la première machine virtuelle: tout fonctionne parfaitement sans accrocs. Puis sur la deuxième: même résultat.

Sur le serveur de production

Bien que la mise à jour des machines virtuelles se soit déroulée sans soucis et que mon serveur soit sauvegardé 2 fois par jour, je relance une petite sauvegarde avant de faire quoi que ce soit (on sait jamais !!).

Une fois la sauvegarde terminée, je joue la procédure de la même façon et je finis alors par le reboot et c’est parti pour une ou 2 minutes d’attente.

Finalement, 3-4 minutes après, le serveur ping de nouveau et le SSH est fonctionnel.

Les problèmes

À ce moment-là, il suffit que les containers Docker soient redémarrés et c’est plié. Je lance donc un htop pour voir les services Docker démarrer les uns après les autres … et là c’est le drame.

Les minutes passent, et rien n’apparait.

Je vais voir les logs, et une chose me saute aux yeux:

OCI runtime create failed: container_linux.go:380: starting container process caused: process_linux.go:545: container init caused: process_linux.go:508: setting cgroup config for procHooks process caused: bpf_prog_query(BPF_CGROUP_DEVICE) failed: invalid argument: unknown"

Ce problème ressemble étrangement à ce que j’avais déjà rencontré en essayant de faire tourner une image AMD sur un Raspberry Pi (donc sur ARM). Bizarre, l’erreur doit seulement être ressemblante. Mais le vrai problème est que je n’avais pas vu l’erreur sur les machines de test, donc j’ai le serveur de production qui est en rade …

Je vous passe tous les tests que j’ai faits, je n’ai pas pris le temps de tout noter. Entre autres, j’ai réinstallé intégralement Docker dans les versions avant la mise à jour, mis les mêmes que sur les machines de tests, etc…

Une solution

Après avoir bidouillé pendant environ 2 heures sans trouver de solution, j’ai lancé la réinstallation du serveur. Kimsufi ne propose pas encore Debian 11 donc les étapes que j’ai suivies sont:

• Installation de Debian 10.
• Mise à jour vers Debian 11.
• Installation de Docker et docker-compose.
• Copie du dossier /data (plus de 280 Go parce que j’avais mal utilisé l’option --exclude de rsync: je voulais copier les fichiers de Nextcloud dans un second temps mais tant pis …).
• Lancement du script qui lance tous les docker-compose.

Conclusion

C’est la première fois depuis avril 2016 (lancement du premier serveur) que j’ai une coupure aussi longue (environ 12h30). La longueur de cette coupure s’explique aussi par le fait que j’avais des choses à faire chez moi et j’avais aussi besoin de dormir et que j’avais loupé ma commande rsync avec l’option --exclude.

Au final, je suis quand même un peu déçu et frustré de ne pas avoir trouvé la vraie solution au problème mais au final, une réinstallation propre de temps en temps n’est pas si mauvaise. De plus, ça aurait pu servir à d’autres personnes qui auraient rencontré le même problème. N’hésitez pas à partager si vous avez aussi eu le problème !

Pour finir, les sauvegardes, c’est la vie, je le répète très souvent, mais c’est indispensable. Mais seules, elles ne servent pas à grand-chose, il faut savoir comment les restaurer, et mis à part ma commande rsync mal écrite, j’ai suivi sans le moindre souci ma procédure de restauration. Donc même avec un pépin dans la mise à jour, une fois la décision prise de réinstaller le serveur, je n’avais plus qu’à copier-coller les commandes à lancer.