Je gère un bureau Linux complet dans Docker juste parce que je peux

Comme moi, vous avez probablement entendu la règle non officielle de Docker: c’est pour les serveurs légers et sans tête et les applications de ligne de commande, pas pour les interfaces graphiques. La plupart d’entre nous suivent cette règle pour une bonne raison – CLI est pour quoi Docker a été construit. Mais que se passe-t-il lorsque vous enfreignez les règles?

J’ai décidé de faire quelque chose de l’ordinaire. Mon objectif était de faire fonctionner un bureau Linux à part entière à l’intérieur d’un conteneur. Je ne veux pas juste un shell; Je veux une interface graphique entièrement fonctionnelle qui existe là où elle n’est pas censée le faire. C’est ce qui s’est passé quand j’ai essayé.

Pourquoi est-ce que je fais ça de toute façon?

Alors pourquoi quelqu’un irait-il à tous ces problèmes pour exécuter Linux? Après tout, nous avons simplement pu utiliser VirtualBox ou même Linux à double boot aux côtés de Windows. Ma réponse est simple: la curiosité et le désir d’un défi.

Je m’intéresse à Docker depuis un certain temps, et même si j’ai eu de l’expérience avec le développement Web complet, pas grand-chose dans le monde de Docker et de la conteneurisation. Je voulais expérimenter les choses et apprendre en les faisant, donc ce projet était la réponse.

Dès le début, je savais que ce ne serait pas facile. Je m’attendais à ce qu’un jour, peut-être deux jours au plus, soit suffisant pour faire fonctionner un système Linux graphique. Mais la réalité du défi était tout à fait le contraire. Les obstacles auxquels j’ai affronté au cours des quatre prochains jours étaient complètement inattendus et beaucoup plus complexes que je n’aurais jamais pu l’attendre, étirant ma patience bien au-delà de ce que je m’étais préparé.

Avant de plonger dans les détails techniques, voici un peu de contexte.

Toute cette expérience a eu lieu sur un PC Windows 10, motivé par une question spécifique: et si vous pouviez avoir le meilleur des deux mondes? L’idée d’un environnement Linux complet fonctionnant à l’intérieur d’un conteneur Docker, côte à côte avec mes applications Windows standard, était trop intrigante pour passer. Pas de redémarrage, pas de partitions distinctes – juste un bureau Linux sans couture et conteneurisé.

Donc, j’ai d’abord dû préparer mon laboratoire. Cela signifiait installer Docker et configurer WSL. Avec les bases posées, j’ai rafraîchi mes bases de Docker et lu sa documentation. Avec cela, ma préparation initiale était terminée; Maintenant, il était temps de mettre la théorie en pratique.

Exécuter mon conteneur Docker

Ma première tentative d’exécuter un bureau Linux dans Docker a été, avec le recul, une erreur de recrue hors de confiance excessive. J’ai décidé de construire une image personnalisée à partir de zéro. Si vous êtes nouveau sur Docker, une image est un package autonome de tout ce dont une application doit exécuter. De sorte qu’une fois que vous avez créé une image, il fonctionnera de la même manière partout, quel que soit le matériel ou le système d’exploitation.

J’ai fait une autre erreur dès le début: je me suis beaucoup appuyé sur un outil d’IA pour générer le code pour mon image personnalisée.

Voici la leçon durement gagnée: si vous ne comprenez pas la technologie, ne copiez pas le code de coller comme je l’ai fait. J’ai passé des heures à déboguer les erreurs sans chemin clair vers l’avant, à me frayer un chemin à travers un gâchis de code que je n’ai pas compris.

Après avoir gaspillé une journée entière sur ce chemin improductif, j’ai finalement abandonné et changé de tactique. Ma nouvelle approche était simple: j’utiliserais une image prédéfinie de Docker Hub. Considérez Docker Hub comme un “App Store” pour les images de conteneurs, rempli de solutions créées et partagées par d’autres développeurs. C’était un ajustement indispensable et a finalement permis au travail réel de commencer.

Premier rayon de lumière: les bonnes choses et les mauvaises choses

Après mon échec de tentative d’image personnalisée, j’ai trouvé une image Debian Image de XFCE prometteuse sur Docker Hub. Je l’ai téléchargé en quelques minutes et, avec quelques commandes, je l’ai lancé. Lorsque j’ai ouvert l’URL, j’ai été accueilli par un bureau Linux entièrement fonctionnel, fonctionnant directement dans mon navigateur. La joie de geek pure de voir un système d’exploitation complet servi de l’intérieur d’un conteneur Docker était un sentiment que je n’oublierai pas. Cela a fonctionné!

La convivialité était étonnamment décente. LibreOffice et Gimp fonctionnaient bien, bien qu’il y ait eu un peu de décalage. J’estimerais environ 70% des performances natives, mais toujours très utilisable. Firefox a également lancé et j’ai même essayé YouTube. C’est à ce moment-là que j’ai frappé le premier obstacle majeur: les couleurs étaient ternes et lavées. Une vérification rapide a confirmé mes soupçons: le navigateur utilisait le rendu du logiciel. Mon GPU était assis inactif.

Il y avait un autre problème que j’ai remarqué: Flatpak n’a pas fonctionné. Toute tentative d’installation d’une application de Flatpak a échoué avec des erreurs, j’ai donc dû recourir aux forfaits Debian. Malgré ces limites, voir un bureau Linux complet courir dans mon navigateur, servi directement de Docker, a été une victoire massive.

Peaufiner et apprendre

Après quelques minutes avec XFCE, j’ai décidé de changer les choses et d’essayer Gnome comme environnement de bureau. Grande erreur! Il a fallu des heures de dépannage et de fixation des erreurs pour le faire fonctionner, et quand il a finalement été lancé, il était lent et gourmand en ressources. En fin de compte, j’ai avalé ma fierté et je suis revenu à XFCE, et je me suis dit que XFCE n’était peut-être pas flashy, mais c’est beaucoup plus réactif. Alors appuyons vers la praticité.

Avec ma nouvelle concentration sur les performances, j’ai décidé de revisiter ma première tentative: construire une image personnalisée à partir de zéro. Cette fois, j’ai étudié le dockerfile de l’image prédéfinie que j’avais utilisée précédemment. Je voulais comprendre exactement ce qui se passait sous le capot, et je voulais voir si je pouvais améliorer la performance moi-même. J’ai expérimenté quelques nouvelles configurations, essayant spécifiquement d’utiliser XRDP au lieu de la méthode de transfert Novnc, pour voir si un protocole différent offrirait une expérience plus fluide. Mais je n’ai vu aucune différence avec XRDP.

Pour reproduire, créez un fichier avec le nom “dockerfile”, collez le code et exécutez-le.

        FROM ubuntu:jammy-20230425
RUN apt update && \
    DEBIAN_FRONTEND=noninteractive apt install -y \
        cinnamon locales sudo \
        tigervnc-standalone-server tigervnc-common \
        virtualgl mesa-utils mesa-vulkan-drivers \
        dbus-x11 xterm wget && \
    locale-gen en_US.UTF-8 && \
    update-locale LANG=en_US.UTF-8

ARG USER=user
ARG PASS=1234
RUN useradd -m $USER -p $(openssl passwd $PASS) && \
    usermod -aG sudo $USER && \
    chsh -s /bin/bash $USER

RUN echo "#!/bin/sh\n\
export XDG_SESSION_DESKTOP=cinnamon\n\
export XDG_SESSION_TYPE=x11\n\
export XDG_CURRENT_DESKTOP=X-Cinnamon\n\
export LIBGL_ALWAYS_INDIRECT=0\n\
exec cinnamon-session" > /home/$USER/.xinitrc && \
    chown $USER:$USER /home/$USER/.xinitrc && chmod +x /home/$USER/.xinitrc

RUN mkdir -p /home/$USER/.vnc && \
    echo $PASS | vncpasswd -f > /home/$USER/.vnc/passwd && \
    chmod 0600 /home/$USER/.vnc/passwd && \
    chown -R $USER:$USER /home/$USER/.vnc

RUN echo "#!/bin/bash\n\
export DISPLAY=:1\n\
Xvnc :1 -geometry 1920x1080 -depth 24 -SecurityTypes VncAuth -rfbport 5901 -localhost no &\n\
sleep 2\n\
sudo -u $USER startx &\n\
tail -f /dev/null" > /start && chmod +x /start
EXPOSE 5901
CMD ["/start"]
    

Explorer Docker Hub

Si tout cela semble trop de travail, il y a de bonnes nouvelles. Vous n’avez pas à créer votre propre image pour commencer ou gérer les erreurs. Mes recherches m’ont conduit à deux solutions fantastiques et prêtes à l’emploi qui offrent une expérience beaucoup plus rationalisée.

• Webtop by linuxserver.io: Il s’agit d’une excellente option open source qui fournit une variété de saveurs de bureau Linux préemballées sous forme d’images Docker. Il utilise Novnc pour livrer le bureau directement à votre navigateur, et la configuration est simple.

• KASM Workspaces: Il s’agit d’une autre option open source pour un usage personnel.

La bonne chose à propos de ces images est qu’elles ont tout pré-configuré, en particulier le webtop. Vous tirez simplement l’image Docker et l’exécutez. Une fois le conteneur en cours d’exécution, vous pouvez accéder à votre Linux en entrant dans l’URL. J’ai trouvé que la performance était bien meilleure que tout ce que j’avais essayé auparavant et, surtout, j’avais un pass-through audio, que je n’ai pas trouvé avec des images Kasm.

Pour exécuter le webtop, ouvrez Windows CMD et collez ce code

        docker run -d ^
-e PUID=1000 ^
-e PGID=1000 ^
-e TZ=Etc/UTC ^
-p 3000:3000 ^
lscr.io/linuxserver/webtop:latest

    

J’ai découvert quelques avantages inattendus

Ce qui a commencé comme un projet amusant pour apprendre Docker et expérimenter avec des conteneurs Linux a fini par révéler des fonctionnalités étonnamment utiles en cours de route. La plus grande découverte, et mon “aha!” Moment, réalisait la puissance de l’accès à distance de bureau.

Quand j’ai vu un bureau Linux complet fonctionner dans mon navigateur, j’avais une idée sauvage: que se passe-t-il si j’y accédais à partir d’un appareil moins puissant? J’ai attrapé mon Chromebook – une humble machine avec un processeur Intel Celeron – a ouvert l’URL, et il était là: la pleine puissance de mon PC principal, en streaming sur mon Chromebook. Soudain, je n’étais pas enchaîné à mon bureau. Je pourrais continuer à travailler depuis le canapé ou n’importe où ailleurs dans la maison. Mon Chromebook à faible puissance est devenu une fenêtre haute performance sur mon bureau, tout cela grâce à un conteneur.

En dehors de cela, je pouvais voir plusieurs autres avantages:

• Sandables jetables: je pourrais tester et casser les choses dans un environnement Linux sans aucune crainte de gâcher mon système d’exploitation principal. Un terrain de jeu parfait pour des expériences risquées.

• Version privée: je peux faire tourner un nouveau conteneur, utiliser un navigateur Web, puis supprimer l’environnement entier en un seul clic, ne laissant aucune trace derrière.

• Espaces de travail dédiés: Je peux créer des images Linux personnalisées adaptées à des tâches spécifiques – un environnement d’écriture sans distraction, une configuration de codage avec tous mes outils de développement préinstallés.

Cette flexibilité a ouvert des possibilités que je n’avais même pas envisagées lors du démarrage du projet.

Quelle est la prochaine étape? Mes expériences inachevées

Bien que j’avais vu par moi-même que l’exécution d’un bureau Linux dans Docker est possible, mon voyage n’est pas terminé. Il y a eu quelques expériences que je voulais faire, mais je n’ai pas eu le temps pour ça:

• Flatpak et Snap Store: j’aimerais comprendre comment faire fonctionner ces magasins d’applications à l’intérieur du conteneur pour agrandir la bibliothèque de logiciels.

• Gaming: Sans la passe du GPU, ce ne serait pas possible, mais je suis curieux de trouver une solution pour cela.

• Une optimisation plus approfondie: je veux continuer à peaufiner la configuration pour voir si je peux extraire des performances encore meilleures et réduire le décalage d’entrée.

Pourquoi est-il difficile d’exécuter Linux dans Docker?

Donc, maintenant que j’ai compris que l’exécution d’un environnement de bureau complet à l’intérieur d’un conteneur et que je m’attend à ce qu’il se comporte comme un bureau normal sur Windows est possible mais douloureux, fragile et beaucoup plus lourd que d’exécuter une machine virtuelle. Les principales raisons en sont:

• Les conteneurs ne sont pas des systèmes d’exploitation isolés: les conteneurs Docker partagent le noyau hôte. C’est ce qui les rend légers et parfaits pour les services uniques. Alors que les environnements de bureau s’attendent à des services système comme (Systemd, Logind, Udev, DBU) et un accès de l’appareil pour être disponible. Les conteneurs ne fournissent pas cela par défaut.

• Pas de serveurs d’affichage intégrés: Linux GUIS a besoin d’un serveur compositeur / affichage (X11 ou Wayland). Un conteneur n’en fournit pas, nous devons donc le faire nous-mêmes.

• Accès au GPU: les conteneurs ne virtualisent pas les GPU par défaut, vous devez donc transmettre les nœuds de périphérique dans le conteneur. Et sur Windows, il y a une couche WSL supplémentaire à traverser.

Cela en valait-il la peine?

Absolument. C’était un projet amusant et profondément enrichissant. J’ai appris une tonne sur le fonctionnement interne de Docker et Linux, et il y a un type spécial de satisfaction qui vient du dépannage pendant des heures et enfin de voir votre travail porter ses fruits.

Alors, je le recommanderais? Oui, surtout si vous êtes curieux et que vous cherchez un projet de week-end original. Mais même si vous ne l’êtes pas, les avantages pratiques que j’ai découverts – comme l’accès à un bureau à distance, les bacs de sable jetables et les espaces de travail dédiés – font bien plus qu’une expérience. Je peux voir des cas d’utilisation pratiques ici.

Bien que les règles non officielles de Docker soient là pour une raison, les leçons les plus précieuses sont parfois trouvées en les cassant. Alors, lancez votre terminal, prenez une image prédéfinie (ou soyez courageuse et construisez la vôtre!), Et voyez la magie par vous-même. Vous pouvez également trouver quelques avantages inattendus en cours de route.