Dans mon quotidien, j’utilise Docker selon le principe KISS (Keep It Simple Stupid) : je configure le dépôt de paquets Docker sur ma station de travail, j’installe le paquet docker-ce et j’active le service correspondant. À partir de là, je manipule les conteneurs en utilisant le client en ligne de commande docker.
Sous le capot, les conteneurs utilisent les ressources de mon système Linux. C’est léger et rapide, et ça tourne comme une flèche sur n’importe quel PC, même une vieille rougne avec un processeur double cœur et un ou deux Go de RAM.
J’avoue platement que jusque-là j’ai toujours regardé d’un mauvais œil les clicodromes genre « usine à gaz » comme Docker Desktop. Si j’en viens à m’y intéresser aujourd’hui, c’est que je me suis rendu compte que ça peut constituer une solution assez intéressante dans certains contextes.
La principale différence de Docker Desktop par rapport à une installation traditionnelle de Docker, c’est qu’on utilise un hyperviseur avec un sous-système virtualisé et une instance isolée de Docker sous le capot :
- HyperV puis WSL sous Windows
- Hyperkit et QEMU sous MacOS
- KVM et QEMU sous Linux
Certes, c’est lourd. Mais ça présente également une série d’avantages :
- En dehors de la ligne de commande traditionnelle avec le client
docker, on se retrouve également avec un clicodrome assez pratique, notamment dans un contexte pédagogique. - Dans le cadre d’une formation, on est souvent confronté en tant que formateur à un parc de machines hétérogènes, avec du Windows, du MacOS et du Linux sur les portables des étudiants ou des stagiaires.
- L’approche virtualisée permet d’isoler l’installation Docker du reste du système. Ce qui résout un problème agaçant dans mon quotidien, puisque l’installation traditionnelle de Docker torpille le bridge KVM de mon hyperviseur.
- Enfin, Docker Desktop fournit un cluster Kubernetes pédagogique out of the box, et qui JusteMarche(tm).
Voici en grandes lignes comment se déroule une installation de Docker Desktop en fonction du système d’exploitation que vous utilisez :
- Sous Windows vous installez le
Docker Desktop Installer.execorrespondant, vous double-cliquez pour lancer l’installation, vous acceptez tous les choix par défaut, et c’est tout. Au pire, vous devrez mettre à jour WSL, ce que vous pourrez effectuer avec un simplewsl --update. - Sous MacOS, vous sélectionnez la famille de votre processeur (Intel ou Apple), vous téléchargez le
Docker.dmgcorrespondant, vous faites un glisser-déposer vers le dossierApplications, et c’est tout. - Sous Red Hat Enterprise Linux et Rocky Linux, vous lisez d’abord la documentation officielle. Vous repérez toutes les incohérences de celle-ci. Vous passez une heure à chercher le lien de téléchargement. Vous sautez à travers des cerceaux en feu en vous arrachant les cheveux. Au bout de quelques après-midi ensoleillées, vous arrivez enfin à tout faire fonctionner correctement.
- Il semblerait que c’est plus facile sous Ubuntu et Fedora, mais vu que j’ai un kink pour la pérennité des clones Red Hat, je n’ai pas vérifié.
Dans cet article, je vais donc décrire l’installation de Docker Desktop sur Rocky Linux. La procédure décrite fonctionne aussi bien sur les versions 8.x que les versions 9.x. J’ai testé et validé pour vous sur une machine bac à sable dans mon bureau.
Prérequis
Le point de départ, c’est n’importe quel poste de travail tournant sous Rocky Linux 8.x ou 9.x. Pour ma part j’utilise l’environnement de bureau KDE en provenance du dépôt tiers EPEL, mais a priori ça fonctionnera tout aussi bien avec Xfce ou GNOME ou n’importe quel autre environnement graphique.
En dehors du dépôt EPEL (Extra Packages for Enterprise Linux) j’ai également activé le dépôt Docker pour récupérer une seule dépendance. Reportez-vous à cet article pour les détails de ce dépôt.
L’hyperviseur KVM doit être installé et activé sur la machine :
# dnf install -y qemu-kvm libvirt virt-install # systemctl enable libvirtd --now # systemctl enable libvirt-guests --now
J’ajoute mon utilisateur commun mortel (non root) au groupe système libvirt :
# usermod -aG libvirt microlinux
Lors de ma première tentative d’installation de Docker Desktop, je me suis rendu compte que l’application cherchait en vain un binaire /usr/bin/qemu-system-x86_64 sous le capot. Le problème, c’est que sur les systèmes Red Hat, ce binaire s’appelle qemu-kvm et se trouve dans /usr/libexec. La solution la plus simple consiste ici à créer un lien symbolique :
# ln -s /usr/libexec/qemu-kvm /usr/bin/qemu-system-x86_64
Téléchargement
Si vous êtes sous Windows ou sous MacOS, vous vous contentez de vous rendre sur la page du projet en identifiant clairement le lien de téléchargement qui correspond à votre système.
Les utilisateurs de Red Hat Enterprise Linux ou Rocky Linux n’ont pas cette chance. Un clic sur le lien de téléchargement avec le petit pingouin vous renvoie vers la documentation officielle, qui constitue un amalgame assez déplaisant de rigueur et de bordel.
- L’index de la documentation cite explicitement Ubuntu, Debian, Fedora et Arch.
- Une fois que vous cliquez sur la section correspondante, le chapitre Supported platforms cite Ubuntu, Debian, Red Hat Enterprise Linux et Fedora. WTF.
- Partant de là, amusez-vous bien pour trouver les liens de téléchargement dans ce fatras d’informations.
En fin de compte, j’ai jeté un œil sur les Docker Desktop Release Notes, et c’est là où j’ai trouvé mon bonheur :
Je crée un répertoire de téléchargement :
# mkdir docker # cd docker
Je copie le lien RPM dans le presse-papier et je récupère la cible du lien :
# wget -c https://desktop.docker.com/linux/main/amd64/167172/docker-desktop-x86_64.rpm
Je note en passant qu’il manque la version dans le nom du paquet et que rien n’indique non plus si c’est un binaire pour Fedora, RHEL 8.x ou RHEL 9.x. J’ai posé la question dans le forum du projet Docker, et j’ai reçu une série d’informations contradictoires. Pour le dire poliment.
Installation
Soyons sur nos gardes et jetons un regard curieux et vaguement inquiet sur les dépendances du paquet :
# rpm -ivh --test docker-desktop-x86_64.rpm
error: Failed dependencies:
docker-ce-cli is needed by docker-desktop-4.34.2-167172.x86_64
gtk3-devel is needed by docker-desktop-4.34.2-167172.x86_64
pass is needed by docker-desktop-4.34.2-167172.x86_64
qemu-system-x86 >= 5.2.0 is needed by docker-desktop-4.34.2-167172.x86_64
Je peux déjà récupérer trois des quatre dépendances depuis les dépôts officiels et tiers :
# dnf install -y docker-ce-cli gtk3-devel pass
Pour la suite des événements, j’utilise l’option --nodeps en connaissance de cause. Le paquet qemu-system-x86 n’est certes pas trouvé, mais la dépendance logicielle est bien satisfaite par le lien symbolique que j’ai créé plus haut :
# rpm -ivh --nodeps docker-desktop-x86_64.rpm Verifying... ################################# [100%] Preparing... ################################# [100%] Updating / installing... 1:docker-desktop-4.34.2-167172 ################################# [100%] Enabling use of privileged ports by Docker Desktop kubernetes.docker.internal added to /etc/hosts Reloading systemd daemon for logged in users Cannot access user instance remotely. Done reloading systemd daemon for logged in users Enabling use of privileged ports by Docker Desktop
Les développeurs de Docker Desktop n’ont vraisemblablement jamais essayé d’installer leur propre paquet RPM sur un système Red Hat, alors même que cette distribution est citée dans la liste des systèmes officiellement supportés. Quant à Red Hat, ça doit leur en secouer une sans faire bouger l’autre, vu qu’ils préfèrent leur propre solution Podman à Docker.
Authentification
Pour la suite des événements nous avons besoin d’un compte chez Docker. Si vous n’en avez pas, c’est le moment d’en créer un. Non, ce n’est pas la peine de sortir la carte bleue. Oui, c’est gratuit.
Docker Desktop est installé, mais il nous reste un problème à régler avant le premier lancement. C’est que la gestion de l’authentification avec les credential helpers ne fonctionne pas dans la configuration par défaut.
La solution la plus simple consiste ici à utiliser la simple commande docker login dans un terminal. Si tout se passe bien, cette commande crée un fichier local ~/.docker/config.json.
$ docker login -u kikinovak
Password: ************
...
Login Succeeded
Attention : l’utilisateur fourni en argument à l’option -u c’est bien l’identifiant de connexion de votre compte Docker, et non pas votre utilisateur Linux dans le shell.
Premier lancement
Repérez Docker Desktop dans le menu des applications et démarrez-le. La fenêtre de bienvenue vous affiche un lien vers la licence d’utilisateur qui stipule que votre maison, votre voiture, votre femme et votre chien appartiennent désormais à Docker Inc. Acceptez tout ça sans broncher :
Cliquez trois fois sur Skip dans les fenêtres subséquentes pour échapper à toute une série de questions intrusives.
Si tout se passe bien, vous vous retrouvez dans la fenêtre principale de Docker Desktop. Repérez en bas à gauche la zone de notification de l’application qui vous indique que le moteur Docker est en cours d’exécution (Engine running) :
Si vous utilisez un thème clair, l’icône de Docker Desktop dans la zone de notification de votre environnement de bureau est à peu près invisible. Dans mon bureau KDE, elle s’affiche en blanc sur un fond gris clair. Essayez quand-même de la repérer et d’afficher le menu contextuel en cliquant dessus.
Ouvrez les Paramètres > Software Updates et décochez l’option Automatically check for updates :
Kubernetes
Docker Desktop inclut une installation pédagogique de Kubernetes. Pour l’activer, ouvrez la section Kubernetes dans les Paramètres et cliquez successivement sur Enable Kubernetes et Install :
Patientez quelques minutes lors de la mise en place initiale du cluster. Si tout se passe bien, la zone de notification de Docker Desktop vous indiquera que Kubernetes est en cours d’exécution :
La commande kubectl ne fait pas partie d’une installation par défaut de Docker Desktop. Pour la récupérer, on va d’abord configurer le dépôt de paquet tiers correspondant :
# /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://pkgs.k8s.io/core:/stable:/v1.30/rpm/
enabled=1
priority=10
gpgcheck=1
gpgkey=https://pkgs.k8s.io/core:/stable:/v1.30/rpm/repodata/repomd.xml.key
Ma version de Docker Desktop inclut Kubernetes dans la version 1.30. La configuration du dépôt de paquets Kubernetes correspondant est codée « en dur » dans le fichier /etc/yum.repos.d/kubernetes.repo.
À présent, on installe le paquet kubectl :
# dnf install -y kubectl
Et on vérifie l’état du cluster :
$ kubectl get nodes NAME STATUS ROLES AGE VERSION docker-desktop Ready control-plane 14m v1.30.2
L’authentification revisitée
J’ai finalement réussi à faire fonctionner les credential helpers avec un peu d’obstination. Voici ce qu’il faut faire dans un premier temps :
- Arrêter Docker Desktop.
- Supprimer
~/.docker/config.json. - Supprimer
~/.password-store.
Générer une clé GPG sans mot de passe. Par exemple :
$ gpg --batch --passphrase '' --quick-gen-key kikinovak default default
Afficher les clés GPG et identifier celle qu’on vient de générer :
$ gpg --list-keys
/home/kikinovak/.gnupg/pubring.kbx
----------------------------------
pub rsa2048 2024-10-04 [SC]
15787457AC319D41B5D88F9418B23BFDD4E82465
uid [ ultime ] kikinovak
sub rsa2048 2024-10-04 [E]
J’initialise l’enregistrement chiffré des mots de passe :
$ pass init 15787457AC319D41B5D88F9418B23BFDD4E82465 mkdir: création du répertoire '/home/kikinovak/.password-store/' Password store initialized for 15787457AC319D41B5D88F9418B23BFDD4E82465
Si tout s’est bien passé, je peux désormais utiliser le bouton Sign In de Docker Desktop en renseignant mon identifiant de connexion et mon mot de passe Docker dans une fenêtre de Firefox :
La rédaction de cette documentation demande du temps et des quantités significatives de café espresso. Vous appréciez ce blog ? Offrez un café au rédacteur en cliquant sur la tasse.
0 commentaire