Uruchamiam pełny pulpit Linux w Dockerze tylko dlatego, że mogę

Eksperyment z uruchomieniem pulpitu Linux w Dockerze ujawnia możliwości i wyzwania konteneryzacji, oferując nową perspektywę na elastyczność środowisk programistycznych.

Jak ja, prawdopodobnie słyszałeś nieoficjalną zasadę Dockera: jest dla lekkich, bezgłowych serwerów i aplikacji wiersza poleceń, a nie dla interfejsów graficznych. Większość z nas przestrzega tej zasady z dobrego powodu—CLI to coś, do czego Docker został stworzony. Ale co się stanie, gdy złamiesz zasady?

Postanowiłem zrobić coś nietypowego. Moim celem było uruchomienie pełnoprawnego pulpitu Linux w kontenerze. Nie chcę tylko powłoki; chcę w pełni funkcjonalnego GUI, które istnieje tam, gdzie nie powinno. Oto co wydarzyło się, gdy spróbowałem.

Dlaczego to robię w ogóle?

Więc czemu ktokolwiek miałby się trudzić, aby uruchomić Linux? W końcu moglibyśmy po prostu użyć VirtualBoxa lub nawet zainstalować dual-boot Linuxa obok Windows. Moja odpowiedź jest prosta: ciekawość i chęć wyzwania.

Interesowałem się Dockerem od jakiegoś czasu, a choć miałem doświadczenie w pełnym stosie rozwoju webowego, nie miałem zbyt wiele do czynienia ze światem Dockera i konteneryzacji. Chciałem eksperymentować z różnymi rzeczami i uczyć się przez działanie, więc ten projekt był odpowiedzią.

Od samego początku wiedziałem, że to nie będzie łatwe. Spodziewałem się, że dzień, może dwa max, wystarczą, aby uruchomić graficzny system Linux. Ale rzeczywistość wyzwania była całkowicie odwrotna. Przeszkody, z którymi się zetknąłem w ciągu następnych czterech dni, były całkowicie nieoczekiwane i znacznie bardziej złożone, niż mogłem przewidzieć, wyciągając moją cierpliwość daleko poza to, na co byłem przygotowany.

Zanim zanurzymy się w szczegóły techniczne, oto kontekst.

Cały ten eksperyment miał miejsce na komputerze z systemem Windows 10, napędzanym przez konkretne pytanie: co jeśli możesz mieć to, co najlepsze z obu światów? Pomysł pełnego środowiska Linux działającego w kontenerze Docker, obok moich standardowych aplikacji Windows, był zbyt intrygujący, aby go zlekceważyć. Żadnych restartów, żadnych osobnych partycji—tylko bezproblemowy, skonteneryzowany pulpit Linux.

Najpierw musiałem przygotować moje laboratorium. Oznaczało to instalację Dockera i skonfigurowanie WSL. Położenie fundamentów, odświeżyłem swoje podstawy Dockera i przeczytałem jego dokumentację. Na tym moje wstępne przygotowania się zakończyły; nadszedł czas, aby teoria przeszła w praktykę.

Uruchamianie mojego kontenera Docker

Moja pierwsza próba uruchomienia pulpitu Linux w Dockerze była, z perspektywy czasu, nowicjuszowskim błędem wynikającym z nadmiernej pewności siebie. Postanowiłem zbudować niestandardowy obraz od zera. Jeśli jesteś nowy w Dockerze, obraz to samodzielny pakiet wszystkiego, co aplikacja potrzebuje do działania. Tak więc, gdy stworzysz obraz, będzie on działał tak samo wszędzie, niezależnie od sprzętu czy systemu operacyjnego.

Popełniłem kolejny błąd od samego początku: mocno polegałem na narzędziu AI do generowania kodu dla mojego niestandardowego obrazu.

Oto trudna lekcja: jeśli nie rozumiesz technologii, nie kopiuj i wklejaj kod tak jak ja. Spędziłem godziny debugując błędy bez widocznej drogi naprzód, przymuszając się do przedzierania przez bałagan kodu, którego nie rozumiałem.

Po zmarnowaniu całego dnia na tej nieproduktywnej ścieżce, w końcu się poddałem i zmieniłem taktykę. Moje nowe podejście było proste: użyję wstępnie zbudowanego obrazu z Docker Hub. Myśl o Docker Hub jako "sklepie z aplikacjami" dla obrazów kontenerów, wypełnionym rozwiązaniami stworzonymi i udostępnionymi przez innych programistów. To była potrzebna zmiana i w końcu pozwoliło mi na rozpoczęcie prawdziwej pracy.

Pierwszy promień światła: Dobre i złe rzeczy

Po mojej nieudanej próbie z niestandardowym obrazem, znalazłem obiecujący obraz Debian oparty na XFCE na Docker Hub. Pobrałem go w kilka minut i, za pomocą kilku poleceń, uruchomiłem go. Kiedy otworzyłem URL, zostałem powitany przez w pełni funkcjonalny pulpit Linux, działający bezpośrednio w mojej przeglądarce. Czysta geekowska radość z zobaczenia pełnego systemu operacyjnego serwowanego z wnętrza kontenera Docker była uczuciem, którego nie zapomnę. To działało!

Użyteczność była zaskakująco niezła. LibreOffice i GIMP działały bez zarzutu, chociaż występowały pewne opóźnienia. Szacowałbym, że osiągnąłem około 70% wydajności natywnej, ale nadal bardzo użyteczne. Firefox również uruchomił się, a nawet spróbowałem YouTube'a. Wtedy napotkałem pierwszą główną przeszkodę: kolory były matowe i wyblakłe. Szybka kontrola potwierdziła moje podejrzenie: przeglądarka używała renderowania programowego. Moja karta GPU stała bezczynnie.

Był jeszcze jeden problem, który zauważyłem: Flatpak nie działał. Każda próba zainstalowania aplikacji z Flatpak kończyła się błędami, więc musiałem sięgnąć po pakiety Debiana. Pomimo tych ograniczeń, widząc pełny pulpit Linux działający w mojej przeglądarce, serwowany bezpośrednio z Dockera.

było ogromnym sukcesem.

Dopasowanie i Uczenie Się

Po kilku minutach z XFCE postanowiłem zmienić środowisko i spróbować GNOME jako mojego środowiska graficznego. Duży błąd! Spędziłem godziny na rozwiązywaniu problemów i naprawianiu błędów, żeby to uruchomić, a gdy w końcu wystartowało, było wolne i pochłaniało dużo zasobów. Ostatecznie przełknąłem swoją dumę i wróciłem do XFCE, mówiąc sobie, że XFCE może nie być błyszczące, ale jest znacznie bardziej responsywne. Skupmy się więc na praktyczności.

Z nowym naciskiem na wydajność postanowiłem powrócić do mojej pierwszej próby: stworzenia niestandardowego obrazu od podstaw. Tym razem studiowałem Dockerfile używanego wcześniej obrazu. Chciałem dokładnie zrozumieć, co się dzieje "pod maską", i zobaczyć, czy mogę poprawić wydajność samodzielnie. Eksperymentowałem z kilkoma nowymi konfiguracjami, próbując użyć xrdp zamiast metody przekazywania noVNC, aby sprawdzić, czy inny protokół zapewni lepsze doświadczenie. Ale nie zauważyłem żadnej różnicy z xrdp.

Aby powielić, stwórz plik o nazwie "dockerfile", wklej kod i uruchom go.

 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

# Stwórz użytkownika
# Wprowadź poniższe dane logowania w ekranie logowania xrdp
ARG USER=user
ARG PASS=1234
RUN useradd -m $USER -p $(openssl passwd $PASS) && \
 usermod -aG sudo $USER && \
 chsh -s /bin/bash $USER

# Środowisko dla Cinnamon
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

# Ustawienie hasła VNC
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

# Skrypt startowy
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"]

 

Badania Docker Hub

Jeśli to wszystko wydaje się zbyt pracochłonne, mam dobrą wiadomość. Nie musisz samodzielnie budować swojego obrazu, aby zacząć lub radzić sobie z błędami. Moje badania doprowadziły mnie do dwóch fantastycznych, gotowych rozwiązań, które oferują znacznie bardziej usprawnione doświadczenie.

• Webtop od LinuxServer.io: To świetna opcja open-source, która zapewnia różne smaki pulpitu Linuxa zapakowane jako obrazy Docker. Używa noVNC do dostarczania pulpitu bezpośrednio do twojej przeglądarki, a konfiguracja jest prosta.
• Kasm Workspaces: To kolejna opcja open-source do użytku osobistego.

Dobrą rzeczą w tych obrazach jest to, że mają wszystko skonfigurowane z góry, szczególnie Webtop. Po prostu ściągasz obraz Docker i uruchamiasz go. Gdy kontener działa, możesz uzyskać dostęp do swojego Linuxa, wpisując URL. Wydajność okazała się znacznie lepsza niż cokolwiek, co próbowałem wcześniej i, co ważne, miało przesyłanie dźwięku, czego nie znalazłem w obrazach Kasm.

Aby uruchomić Webtop, otwórz Windows CMD i wklej ten kod:

 docker run -d ^
--name webtop-xfce ^
-e PUID=1000 ^
-e PGID=1000 ^
-e TZ=Etc/UTC ^
-p 3000:3000 ^
--shm-size=1gb ^
lscr.io/linuxserver/webtop:latest
 

Odkryłem Kilka Niespodziewanych Zalet

To, co zaczęło się jako zabawny projekt, aby nauczyć się Dockera i eksperymentować z kontenerami Linux, okazało się ujawnieniem niezwykle użytecznych funkcji po drodze. Największym odkryciem i moim osobistym "aha!" momentem było uświadomienie sobie potęgi zdalnego dostępu do pulpitu.

Kiedy zobaczyłem pełen pulpit Linuxa działający w mojej przeglądarce, miałem szaloną myśl: co jeśli uzyskam do niego dostęp z mniej wydajnego urządzenia? Chwyciłem mojego...

Chromebook — skromna maszyna z procesorem Intel Celeron — otworzył adres URL, a tam było: pełna moc mojego głównego komputera, przesyłana na mój Chromebook. Nagle nie byłem przywiązany do biurka. Mogłem kontynuować pracę z kanapy lub z dowolnego miejsca w domu. Mój niskowydajny Chromebook stał się wysokowydajnym oknem do mojego komputera stacjonarnego, wszystko dzięki kontenerowi.

Aby uzyskać najlepsze doświadczenie, użyj podłączonego kabla Ethernet lub szybkiej sieci Wi-Fi 5 GHz.

Oprócz tego widziałem kilka innych korzyści:

• Jednorazowe piaskownice: Mogłem testować i zepsuć rzeczy w środowisku Linux bez obaw o uszkodzenie głównego systemu operacyjnego. Idealne miejsce do ryzykownych eksperymentów.
• Prywatne przeglądanie: Mogę stworzyć nowy kontener, użyć przeglądarki internetowej, a następnie usunąć całe środowisko za jednym kliknięciem, nie pozostawiając śladów.
• Dedykowane przestrzenie robocze: Mogę tworzyć niestandardowe obrazy Linux dostosowane do określonych zadań — środowisko pisania wolne od rozpr distractions, konfiguracja programistyczna z wszystkimi moimi narzędziami deweloperskimi wstępnie zainstalowanymi.

Ta elastyczność otworzyła możliwości, o których nawet nie myślałem, zaczynając projekt.

Co dalej? Moje niedokończone eksperymenty

Chociaż sam widziałem, że uruchomienie pulpitu Linux w Dockerze jest możliwe, moja podróż się nie kończy. Było kilka eksperymentów, które chciałem przeprowadzić, ale nie miałem na to czasu:

• Flatpak i Snap Store: Chciałbym dowiedzieć się, jak uruchomić te sklepy aplikacji w kontenerze, aby rozszerzyć bibliotekę oprogramowania.
• Gry: Bez przekazywania GPU, to nie byłoby możliwe, ale jestem ciekaw, jak znaleźć rozwiązanie w tej kwestii.
• Dalsza optymalizacja: Chcę kontynuować dostosowywanie ustawień, aby zobaczyć, czy mogę uzyskać jeszcze lepszą wydajność i zmniejszyć opóźnienia wejściowe.

Dlaczego trudno jest uruchomić Linux w Dockerze?

Teraz, gdy zrozumiałem, że uruchomienie pełnego środowiska pulpitu w kontenerze i oczekiwanie, że będzie działać jak normalny pulpit w systemie Windows, jest możliwe, ale bolesne, kruche i znacznie bardziej kłopotliwe niż uruchomienie maszyny wirtualnej, mogę wskazać główne powody:

• Kontenery nie są izolowanymi systemami operacyjnymi: kontenery Docker dzielą rdzeń hosta. To sprawia, że są lekkie i świetne dla pojedynczych usług. Natomiast środowiska pulpitowe oczekują, że usługi systemowe (takie jak systemd, logind, udev, DBus) i dostęp do urządzeń będą dostępne. Kontenery domyślnie tego nie zapewniają.
• Brak wbudowanych serwerów wyświetlania: interfejsy GUI Linuksa potrzebują kompozytora/serwera wyświetlania (X11 lub Wayland). Kontener nie zapewnia jednego, więc musimy to zrobić sami.
• Dostęp do GPU: kontenery nie wirtualizują GPU domyślnie, więc musisz przekazać węzły urządzeń do kontenera. A w systemie Windows istnieje dodatkowa warstwa WSL do pokonania.

Czy to było warte zachodu?

Absolutnie. To był zabawny i głęboko satysfakcjonujący projekt. Nauczyłem się mnóstwa o wewnętrznych mechanizmach Dockera i Linuxa, a istnieje szczególny rodzaj satysfakcji, który przychodzi z rozwiązywaniem problemów przez godziny i w końcu zobaczeniem efektów swojej pracy.

Czy bym to polecił? Tak, szczególnie jeśli jesteś ciekawy i szukasz dziwacznego projektu na weekend. Ale nawet jeśli nie jesteś, praktyczne korzyści, które odkryłem — takie jak zdalny dostęp do pulpitu, jednorazowe piaskownice i dedykowane przestrzenie robocze — sprawiają, że to więcej niż eksperyment. Widzę tutaj praktyczne zastosowania.

Chociaż nieoficjalne zasady Dockera istnieją z jakiegoś powodu, czasami najcenniejsze lekcje można wyciągnąć przez ich łamanie. Więc uruchom swoją konsolę, pobierz gotowy obraz (lub bądź odważny i zbuduj własny!) i zobacz magię na własne oczy. Możesz również znaleźć kilka niespodziewanych korzyści po drodze.

Jeśli ciekawią Cię artykuły podobne do Uruchamiam pełny pulpit Linux w Dockerze tylko dlatego, że mogę, zajrzyj do kategorii Linux i odkryj jeszcze więcej interesujących treści.