L’instruction RUN a une option --mount=type=cache qui est peut être plus pratique que les options sans cache des gestionnaires de paquets pour optimiser les images dans certains cas. Certaines images sont reconstruites régulièrement malgré les couches arrangées comme il faut et les astucieux “multi-stage build”. Monter un cache avec RUN permet de ne pas avoir de cache dans l’image finale et permet de réutiliser le cache entre différentes images et/ou constructions. Ceci dit, la cache monté prend bien de la place sur le système hôte.

Et que va-t-il se passer le jour où l’IANA va attribuer le TLD .docker à une organisation quelconque ?

Non ce n’est pas moi ;)

Pour Debian/Ubuntu

LASTKERNEL=$(apt list --installed ~nlinux-image-[[0-9]]* | sort -Vr | awk -F "/" 'NR==1 {print substr($1,13)}')

devrait fonctionner à condition que le nom du noyau commence par linux-image- (13 caractères)

Cela me semble assez délicat de trouver un motif qui fonctionne dans tous les cas. Peut-être vaudrait-il mieux se baser sur la liste des fichiers vmlinuz* présents sous /boot et sélectionner le plus récent.

Merci, c’est toi qui as mis un commentaire sur le Github ? En tout cas merci pour le coup du proxmox, je vais peut être adapter le script pour un usage plus générique

Merci très bon petit article ! Et le script indiqué est facilement adaptable pour Debian et dérivés ;)

Voici un playbook qui déploie cette astuce: https://gitlab.com/bersace/config/-/blob/master/docker.yml

Le playbook dépend de python-docker.

Ton contenu est bien écrit. J’aime bien l’esthétique de ton site Web. Par contre, je désapprouve l’idée véhiculée sur la philosophie Unix. Cela relève d’une vision utopiste quelque peu passéiste. L’analogie avec la « clé tubulaire, un tournevis et une pince » est incomplète. Ce n’est pas en raccord avec mon expérience. Nombres d’utilisateurs « Unix » avertis sont reluctant à utiliser le Shell comme langage de programmation ou « boîte à outils ». Cette conception a des limites : maîtriser des utilitaires, créer de nouveaux programmes implémentés dans un autre langage (pour ajouter des commandes ou définir des interfaces), connaître plusieurs concepts inhérents à la conception d’un système d’exploitation et tordre un langage de commandes (le Shell) dans tous les sens pour les plus malchanceux. C’est une vision illustre des choses mais déplorable qui est érigée en mantra et qui contrevient au bon sens.

Je cite cet extrait du GNU Linux magazine n°277, de l’article « Programmation robuste avec Bash ».

« Développer avec Bash ? Impossible, ce n’est pas un véritable langage de programmation ! Et ce genre de scripts sont bien trop fragiles ! » Voilà des idées reçues sur l’un des plus célèbres interpréteurs Shell que nous allons tenter, aujourd’hui, dans cet article, de faire disparaître pour de bon !

[…]

« L’interpréteur Shell a de nombreuses fonctionnalités permettant de le rendre aussi robuste et fiable qu’un programme réalisé à l’aide de soi-disant [langages] plus évolués tels que Python ou Java, il suffit d’en avoir conscience et de les utiliser à bon escient. »

Voici la conclusion de ChatGPT 5 nano :

L’affirmation est trop générale et peut être trompeuse. Le shell peut être robuste dans des cadres limités et bien encadrés, mais il ne remplace pas les avantages des langages comme Python ou Java pour des applications plus complexes.

Sympa diskonaut ! J’aime beaucoup.

J’utilise duf (CLI) pour une analyse rapide du système et baobab pour une analyse plus poussée, mais je crois que je vais pouvoir me passer de baobab maintenant.

Merci du conseil. C’est exactement pour ça que j’aime faire ce genre d’article, tu apprends souvent des choses intéressantes dans les coms. Et en plus c’est fait avec bienveillance, ça change de certains ;)

Merci pour l’article ! J’utilise diskonaut qui rend le même type de service en tui, mais il est peut être plus très maintenu, je retesterai ce ncdu …

Il vaut mieux passer à gdu, plus rapide, Go avec un seul fichier binaire à drop.

ncdu avec Zig pour la version 2, c’est plus compliqué. La version 1 était intéressante il y a quelques années mais dépassée maintenant.

Tcho !

Merci, hâte de voir la suite :)

Merci :)

Sinon, y a BAN (https://adresse.data.gouv.fr/) directement, c’est Français et auto-hébergeable, c’est ce qu’il y a derrière addok d’ailleurs.

Bonjour et merci pour les remarques qui sont très justes. C’est une méthode volontairement “simpliste” pour expliquer les bases de la migration. Dans tous les cas une sauvegarde est OBLIGATOIRE, l’idéal étant un snapshot si VM. Mon site a pour but de démocratiser des choses qui peuvent sembler complexes et je persisterai dans cette voie ;)

Bonne méthode pour risquer de casser une installation. Il n’y a aucun traitement des éventuels dépôts tiers et des paquets qui en proviennent. Il n’y a aucun traitement avant mise à niveau des éventuels paquets obsolètes. Il n’y a aucune vérification de l’état des paquet installés (dpkg –audit) Il n’y a aucun nettoyage des fichiers sous /etc (dpkg-old/new et autres)…

Il n’y a aucune précaution sur d’éventuels services installés connus pour poser problème lors de la mise à niveau (mariadb par exemple)

La procédure prudente pour mettre à niveau c’est apt upgrade –without-new-pkgs puis apt full-upgrade

(sur un système « propre on peut se contenter de la seconde commande)

Le nettoyage après la mise à niveau est tout à fait insuffisant. Il faut aussi vérifier et éventuellement purger les paquets obsolètes et les résidus de configuration (apt list ~c et apt list ~o pur les afficher)

J’oublie probablement d’autres points ;)

Merci pour la remarque ;)

sudo apt autoremove --purge => sudo apt autopurge ;-)

En passant, je découvre l’option modernize-sources ! Merci.

Et félicitations à vous pour le boulot accompli !

Tcho !

Un grand merci pour avoir mis en avant cet article concernant notre projet