WindowsのRDPで接続可能な日本語XWINDOW Dockerイメージ
(github.com/lancard)最新のDebian 13(Trixie)ベースの日本語XWINDOW (wayland) Dockerイメージを作成して公開します。
実際にWindowsをお使いの方は多いですが、ときどきDockerで日本語対応のLinux Xウィンドウを立ち上げて作業したくなることがあると思います。
そこで、
Windowsリモートデスクトップでアクセス可能なDebianベースの日本語GUI環境を作ってみました。
このイメージには、Visual Studio Code、Chromium、Vim、Git、Node.js + npm など、開発環境に必要な主要ツールがあらかじめインストールされているため、そのまま開発環境として活用できます。（その分少しサイズは大きめです）
主な特徴は、
- Windowsリモートデスクトップ(RDP)接続が可能
- データとボリュームを保持: /home/(ユーザー名) をDockerボリュームに接続するとデータを永続化可能
注意点として、
Docker上で実行されるため、VSCodeとChromiumではsandboxモードは使用されません。セキュリティにはご注意ください。また、サウンド機能は競合やバグが多いため除外されています。おそらく多くの方は音楽はWindows PC側で聴いていると思うので、省いてあります。
開発環境をすばやく構築したい日本語ユーザーに特に便利なイメージです。
ソースは https://github.com/lancard/x11-korean にあるので参考にしてください。必要な機能があれば、いつでもissueやPRを送ってください！
25件のコメント
内部の vscode では新しいファイルの作成はできますが、既存ファイルの修正はできません。既存ファイルを
chmod 777に変更しても同じです。権限やグループ所有権の問題のようなので、もう少しいろいろ試してみます。エントリーポイントにある
shファイルを修正し、XWINDOW_USER_IDを作業フォルダの ID に合わせることで解決したようです。username を設定
XWINDOW_USER="${XWINDOW_USER:-user}"
if ! id -u $XWINDOW_USER >/dev/null 2>&1; then
useradd -m -s /bin/bash $XWINDOW_USER
echo "user '$XWINDOW_USER' generated."
fi
の部分を
XWINDOW_USER="${XWINDOW_USER:-user}"
XWINDOW_USER_ID="${XWINDOW_USER_ID:-1000}" # デフォルトは1000
if ! id -u $XWINDOW_USER >/dev/null 2>&1; then
useradd -m -s /bin/bash -u $XWINDOW_USER_ID $XWINDOW_USER
echo "user '$XWINDOW_USER' generated with UID $XWINDOW_USER_ID."
else
echo "user '$XWINDOW_USER' already exists."
fi
に変更して、USER_ID をホストマシンのアカウントIDと同じ値で設定しました。
WSLの代わりに使えるでしょうか？
はい、使えます。私は個人的に WSL / WSL2 があまり好きではないので、Hyper-V に Docker を入れてこれを使っています。
もし差し支えなければ、苦手な理由をそっとお伺いしてもいいでしょうか？
2種類のOSが混在するのは好きではありません。どんな副作用があるかも分かりませんし。私は、それぞれのOSはサンドボックスであるか、あるいは物理サーバー1台を単独で占有すべきだと考えています。しかも、過去にWSLの挙動がおかしかった経験もあります。
私の知っている知識ではおっしゃっている内容があまりよく理解できないのですが、もしかして
WSL や Docker の基本的な論理構造と似たようなものではないのでしょうか？
私が何か勘違いしている部分はありますか？
WSL2 は少し似ていると言えるかもしれませんが、WSL は構造が少し異なります。基本的には Windows カーネル上で動作します。WSL2 はハイパーバイザー上で動くのは確かですが、隔離レベルは少し違うと考えています。自動マウントを双方で行うため、OS が互いのファイルシステムにアクセスできます。その結果、望ましくない事態が起こり得ます。たとえば Windows が ext4 に
$RECYCLE.BINを自動作成したり、片方の OS がハッカーに乗っ取られた状況では両方にとって致命的です。私が作ったものは、必要なら何もマウントしなくても構いません。Windows と接続せず、それ単体で動かすことができます。さらに、インストール速度にも影響があるというか……。私のイメージ方式は、気に入らなければ docker イメージを削除して新しいものをもう一つコピーすれば済みます。アップデートするときも、単にイメージを取得すればよいだけです。WSL2 のネットワーク周りにも多少問題があったと記憶しています。また、Linux カーネルも純粋な Linux カーネルではなく、MS がカスタマイズしたものだと認識しています。
純粋な Linux を志向する私には（つまり、互いに隔離されていることを望むので）あまり合いません。
欠点ばかり列挙してしまいましたが、実際のところは個人の好みの違いもあるので、望むものを選べばよいと思います。
確認が遅くなりました。
ご丁寧なご回答ありがとうございます！
また、Docker自体がほぼLinux専用でもあり、NAS上でDockerを動かしたり、大文字・小文字の区別があったりと、Dockerで行うことの利点が多いため作ったものだと考えていただければと思います。
privileged mode の場合は sandbox で動作するように修正しました。privileged mode の場合はローカルリソース（Cドライブなど）を接続できます。接続先は
$HOME/thinclient_drivesにマウントされます。ローカルリソース（C:、D: など）を接続したい場合は、privileged モードで実行してください。（そうすると CTRL + C / V によるファイルコピーが動作します）
おおっと.. VS Code が実行できませんね :)
自己回答です。反応がなかったのでいろいろ見ていたところ、ターミナルで
code --no-sandboxとすると開けますね。えっ？ デスクトップにあるものが開かなかったのでしょうか？
ああ、はい、だめでしたね。何を間違えたのか…
私が継続的にイメージを変更しているので、途中段階のイメージだと思われるかもしれません。
まずデスクトップの vscode アイコンのコマンドが
/usr/bin/code %Fになっているか確認してみてください。そして
/usr/bin/codeファイルを開いて、末尾から2行目がELECTRON_RUN_AS_NODE=1 "$ELECTRON" "$CLI" --no-sandbox --disable-gpu "$@"となっているか確認してみてください。
最近 Docker を勉強している者です。
trivyでこのイメージの脆弱性を検査してみたところ、1053件の脆弱性が出ました。どれも重要というわけではなさそうで、単にあらゆるものを検出しているようにも見えるのですが、実務的にはイメージの安全性をどのように確認し、確保しているのか、もしよければアドバイスをお願いできますでしょうか。実際、脆弱性の除去方法はあまりにも多く、これが正解というものはありませんが、
私の場合はできるだけ安定した最新版を使い、GitHub Actions を使う際には security bot をできるだけ有効にしています。実際、今回の xwindow イメージはご覧のとおりプログラミングした部分がないので、インストールされているプログラム自体の基本的な脆弱性だけがあるはずです。
sandboxモードが適用されていないことが、なぜセキュリティ上の注意事項になるのか気になりました。
Dockerは内部プロセスにサンドボックス機能を提供していないということですか？ だからやむを得ずrootで実行するしかなく、たとえDockerで隔離された環境であっても、ホストにマッピングされたボリュームにはマルウェアが侵入するおそれがある、という意味でしょうか？ それとも、Docker内部のファイルシステムにユーザーが作成したファイルが安全ではない可能性がある、ということでしょうか？
私の知る限り、WindowsでもLinuxでもChromeはサンドボックスモードで動作します。つまり……仮に
javascriptなどで exploit を作って脆弱性攻撃をしても、実際のOSには影響しないということです。ただ、コンテナモードでは
privilegedモードを有効にしないと、おそらくその機能は有効にできないはずです。もちろんそのモードを有効にするよう案内することもできますが、私はコンテナ自体がサンドボックスだと考えていました。手軽に起動したり停止したりできるWindowsのような感覚、と言えばいいでしょうか……
なので、Chromium と Electron ベースの vscode は、サンドボックスではないモードで動くようにしてあります。
あくまで Chromium と vscode に脆弱性があり、その攻撃者がそれを利用して exploit を作れると仮定すれば、危険になり得るという意味です。
Docker名は
lancard/xwindow-koreanですWayland のため、repo 名を https://github.com/lancard/xwindow-korean に変更しました〜
Ubuntu は Debian 系なので、
aptなども気軽に使えます。Ubuntu のベースイメージより Debian のほうが良かったです。