できるという理由だけで、Docker で完全な Linux デスクトップを実行しています。

私と同じように、Docker の非公式ルールを聞いたことがあるでしょう。それは、グラフィカル インターフェイスではなく、軽量のヘッドレス サーバーとコマンド ライン アプリケーションのためのものです。私たちのほとんどは、CLI が Docker の目的であるという正当な理由でこのルールに従っています。しかし、ルールを破るとどうなるでしょうか?

私は何か普通ではないことをすることにしました。私の目標は、コンテナ内で本格的な Linux デスクトップを実行することでした。シェルだけが欲しいわけではありません。本来存在しない場所に完全に機能する GUI が必要です。試してみたらこうなりました。

それにしても、なぜ私はこんなことをしているのでしょうか？

それはほんの少しクレイジーです

では、なぜわざわざ Linux を実行する必要があるのでしょうか?結局のところ、単純に VirtualBox を使用することも、Windows と並行して Linux をデュアルブートすることもできます。私の答えは簡単です。好奇心と挑戦意欲です。

私はしばらく Docker に興味があり、フルスタックの Web 開発の経験はありましたが、Docker やコンテナ化の世界にはあまり興味がありませんでした。何かを試して、実際にやってみて学びたいと思っていたので、このプロジェクトがその答えでした。

最初から、これが簡単ではないことはわかっていました。私は、グラフィカル Linux システムを立ち上げて実行するには 1 日、長くても 2 日あれば十分だろうと予想していました。しかし、現実の課題は全く逆でした。次の 4 日間で私が直面した障害はまったく予想外で、予想していたよりもはるかに複雑で、準備していたものをはるかに超えて私の忍耐力が限界に達しました。

技術的な詳細に入る前に、いくつかの背景を説明します。

この実験全体は、「両方の長所を活用できたらどうなるでしょうか?」という特定の質問に基づいて、Windows 10 PC で行われました。 Docker コンテナ内で標準の Windows アプリケーションと並行して実行される完全な Linux 環境というアイデアは、無視するにはあまりにも興味深いものでした。再起動や個別のパーティションは必要ありません。シームレスなコンテナ化された Linux デスクトップだけです。

そこで、まず研究室の準備を整える必要がありました。これは、Docker のインストールと WSL のセットアップを意味します。基礎が整ったので、Docker の基本を再確認し、ドキュメントを読みました。これで私の最初の準備は完了しました。さあ、理論を実践するときが来ました。

Docker コンテナを実行する

私はこれを難しい方法でやってみました

Docker で Linux デスクトップを実行しようとした最初の試みは、今にして思えば、自信過剰からくる初歩的なミスでした。カスタム イメージを最初から構築することにしました。 Docker を初めて使用する場合、イメージはアプリケーションの実行に必要なものすべてが含まれた自己完結型のパッケージです。そのため、イメージを作成すると、ハードウェアやオペレーティング システムに関係なく、どこでも同じように実行されます。

私は最初から別の間違いを犯しました。カスタム イメージのコードを生成するために AI ツールに大きく依存していたのです。

これが苦労して得た教訓です。テクノロジーを理解していない場合は、私のようにコードをコピーして貼り付けないでください。明確な進むべき道がないままエラーのデバッグに何時間も費やし、理解できないコードの混乱を総当たりで解決しました。

この非生産的な道で丸一日を無駄にした後、私はついに諦めて戦術を切り替えました。私の新しいアプローチはシンプルで、Docker Hub から事前に構築されたイメージを使用します。 Docker Hub は、他の開発者によって作成および共有されたソリューションで満たされたコンテナ イメージの「アプリ ストア」と考えてください。これは待望の調整であり、ようやく実際の作業を開始できるようになりました。

最初の光線: 良いことと悪いこと

カスタム イメージの試みが失敗した後、Docker Hub で有望な XFCE ベースの Debian イメージを見つけました。数分でダウンロードし、いくつかのコマンドを実行して起動しました。 URL を開くと、ブラウザーで直接実行される、完全に機能する Linux デスクトップが表示されました。 Docker コンテナ内から提供される完全な OS を見るという純粋なオタクの喜びは、私にとって忘れられない感情でした。うまくいきました！

使用感は驚くほど良好でした。 LibreOffice と GIMP は、少し遅れはありましたが、正常に動作しました。ネイティブのパフォーマンスの約 70% と推定されますが、それでも十分に使用可能です。 Firefox も起動しましたし、YouTube も試してみました。そのとき、最初の大きなハードルにぶつかりました。色がくすんで色あせてしまったのです。簡単なチェックで私の疑いが確認されました。ブラウザはソフトウェア レンダリングを使用していました。 GPU がアイドル状態になっていました。

私が気づいた別の問題がありました。Flatpak が機能しませんでした。 Flatpak からアプリをインストールしようとするとエラーが発生して失敗したため、Debian パッケージに頼らざるを得ませんでした。こうした制限にもかかわらず、Docker から直接提供される完全な Linux デスクトップがブラウザーで実行されているのを確認できたのは、大きなメリットでした。

微調整と学習

自分自身を助けることができなかった

XFCE を数分間使用した後、状況を切り替えて、デスクトップ環境として GNOME を試してみることにしました。大間違い！実行するには何時間ものトラブルシューティングとエラー修正が必要で、最終的に起動したときには遅くてリソースを大量に消費していました。結局、私はプライドを捨てて XFCE に戻り、XFCE は派手ではないかもしれませんが、はるかに応答性が高いと自分に言い聞かせました。それでは、実用性に目を向けてみましょう。

パフォーマンスに新たに焦点を当てたので、最初の試み、つまりカスタム イメージを最初から構築することに再度取り組むことにしました。今回は以前使用したビルド済みイメージのDockerfileを勉強しました。内部で何が起こっているのかを正確に理解したかったし、自分自身でパフォーマンスを改善できるかどうかを確認したかったのです。私はいくつかの新しい構成を試し、特に noVNC 転送方法の代わりに xrdp を使用して、別のプロトコルがよりスムーズなエクスペリエンスを提供するかどうかを確認しました。しかし、xrdpとの違いはわかりませんでした。

複製するには、「dockerfile」という名前のファイルを作成し、コードを貼り付けて実行します。

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

# Create user
# Enter the below username and passoword in xrdp login screen
ARG USER=user
ARG PASS=1234
RUN useradd -m $USER -p $(openssl passwd $PASS) && \
    usermod -aG sudo $USER && \
    chsh -s /bin/bash $USER

# Environment for 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

# Setup VNC password
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

# Start script
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")

Docker Hub の探索

最初からこうすればよかった

これらすべてが面倒だと思われる場合は、良いニュースがあります。開始したり、エラーに対処したりするために独自のイメージを構築する必要はありません。私の調査により、より効率的なエクスペリエンスを提供する、すぐに使用できる 2 つの素晴らしいソリューションが見つかりました。

• Webtop by LinuxServer.io: これは、Docker イメージとして事前にパッケージ化されたさまざまな Linux デスクトップ フレーバーを提供する優れたオープンソース オプションです。 noVNC を使用してデスクトップをブラウザに直接配信し、セットアップは簡単です。

• Kasm Workspaces: これは、個人使用のためのもう 1 つのオープンソース オプションです。

これらのイメージの良い点は、特に Webtop など、すべてが事前に構成されていることです。 Docker イメージをプルして実行するだけです。コンテナーが実行されたら、URL を入力して Linux にアクセスできます。以前に試したものよりもパフォーマンスがはるかに優れていることがわかり、重要なことに、Kasm 画像では見つけられなかったオーディオ パススルーが備わっていました。

Webtop を実行するには、Windows CMD を開いてこのコードを貼り付けます。

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

思いがけない特典をいくつか発見しました

この愚かな設定にはいくつかの利点があります

Docker を学び、Linux コンテナを実験する楽しいプロジェクトとして始まったこのプロジェクトは、途中で驚くほど便利な機能をいくつか明らかにすることになりました。最大の発見、そして個人的な「なるほど！」リモート デスクトップ アクセスの威力を実感した瞬間でした。

ブラウザーで完全な Linux デスクトップが実行されているのを見たとき、私は突飛なアイデアを思いつきました。それよりも性能の低いデバイスからアクセスしたらどうなるでしょうか? Intel Celeron プロセッサを搭載した質素なマシンである Chromebook を手に取って URL を開くと、そこにはメイン PC のフルパワーが Chromebook でストリーミングされていました。突然、私は机に縛られなくなりました。ソファや家のどこにいても仕事を続けることができました。私の低消費電力の Chromebook は、コンテナのおかげで、デスクトップへの高性能ウィンドウになりました。

これとは別に、他にもいくつかの利点があることがわかりました。

• 使い捨てサンドボックス: Linux 環境では、メイン OS を台無しにすることを恐れることなく、テストしたり、問題を解決したりできました。危険な実験には最適な遊び場です。

• プライベート ブラウジング: 新しいコンテナを起動し、Web ブラウザを使用して、ワンクリックで環境全体を削除し、痕跡を残すことができません。

• 専用ワークスペース: 特定のタスクに合わせたカスタム Linux イメージを作成できます。つまり、気が散ることのない執筆環境、すべての開発ツールがプリインストールされたコーディング セットアップです。

この柔軟性により、プロジェクトを開始したときには考えもしなかった可能性が広がりました。

次は何でしょうか？

私の未完の実験

Docker で Linux デスクトップを実行できることを自分の目で確認しましたが、私の旅はまだ終わっていません。やりたかった実験がいくつかありましたが、時間がありませんでした。

• Flatpak と Snap Store: これらのアプリ ストアをコンテナ内で動作させてソフトウェア ライブラリを拡張する方法を見つけてみたいと思っています。

• ゲーム: GPU パススルーがなければこれは不可能ですが、これに対する解決策を見つけたいと思っています。

• さらなる最適化: セットアップの微調整を続けて、さらに優れたパフォーマンスを引き出し、入力ラグを軽減できるかどうかを確認したいと考えています。

Docker で Linux を実行するのはなぜ難しいのですか?

課題

さて、コンテナ内で完全なデスクトップ環境を実行し、それが Windows 上の通常のデスクトップと同じように動作することを期待することは可能ですが、苦痛で壊れやすく、VM を実行するよりはるかに面倒であることが理解できました。その主な理由は次のとおりです。

• コンテナーは分離されていません。 オペレーティング システム: Docker コンテナーはホスト カーネルを共有します。これが軽量で単一サービスに最適な理由です。一方、デスクトップ環境では、(systemd、logind、udev、DBus) などのシステム サービスやデバイス アクセスが利用可能であることが期待されます。コンテナーはデフォルトではこれを提供しません。

• 組み込みの表示サーバーなし: Linux GUI にはコンポジター/表示サーバー (X11 または Wayland) が必要です。コンテナにはこれが提供されていないため、自分で行う必要があります。

• GPU アクセス: コンテナーはデフォルトでは GPU を仮想化しないため、デバイス ノードをコンテナーに渡す必要があります。 Windows では、さらに WSL レイヤーを通過する必要があります。

苦労する価値はありましたか？

絶対に。楽しくて、とてもやりがいのあるプロジェクトでした。 Docker と Linux の内部の仕組みについてたくさんのことを学びました。何時間もトラブルシューティングを行って、最終的に自分の仕事が報われるのを見ると、特別な満足感が得られます。

それで、それをお勧めしますか？はい、特に好奇心があり、風変わりな週末プロジェクトを探している場合はそうです。しかし、そうでないとしても、リモート デスクトップ アクセス、使い捨てのサンドボックス、専用のワークスペースなど、私が発見した実際的な利点により、これは単なる実験以上のものになります。ここで実際の使用例を見ることができます。

Docker の非公式ルールには理由がありますが、ルールを破ることで最も貴重な教訓が得られる場合があります。したがって、ターミナルを起動し、事前に構築されたイメージを取得し (または勇気を出して独自のイメージを構築してください!)、その魔法を自分の目で見てください。途中で予期せぬ特典が見つかるかもしれません。