GUI application を docker で起動する

私は Host の環境を汚したくないので、開発環境の構築は Docker でなるべくやっています。
今のところDocker 固有の凶悪な問題に遭遇していないので、軽いVM みたいな形で使ってます。
centos:7 でコマンドを試した後、 ubuntu:16.04 でもそのコマンドを試す、とか。ぽんぽん立ち上げられるのが良い。
CUI の場合はガンガンコンテナを作るのですが、GUIはさてどうするんだろう、と疑問。
それで調べたりしたログがこの記事です。

結論としては、この記事は Docker の話では無く X11 の話です。
正確には「X11 に詳しいと、プロセスが走る場所がコンテナ内でも ssh 先でも、GUI を表示できる」という話。

環境

• macOS Sierra: 10.12.6
• Docker: 18.03.0-ce-mac60 (23751)
• XQuartz: 2.7.11 (xorg-server 1.18.4)

GUI Application Container

GUI を利用する Container を調べていたら実行コマンド付きの firefox がありました。

XQuartz を起動して、いろいろオプションを足せばOKみたいです。

XServer の起動

Docker で GUI を使うには X11 の Server を起動してそこに繋げているみたいです。

X11 の Server として XQuartz を使っていたっぽい。

まずは Server(GUI への remote access を許可) を起動するために

• Preferences > Security > Allow connections from network clients

にチェックを入れる。

これで XQuartz を起動時に 6000 番とかで listen してくれる。

• $ netstat -at

とかして :x11 とかがあればOK。

xauth とかで access control もできるっぽいんだけれど、まずは全てのアクセスを許可。

• $ xhost +

これで X11 Server 側は準備OK。

XServer を指定してコンテナ起動

XServer の情報をオプションで run する時に渡せば firefox が起動しそうです。
元ページのコマンドは

• $ docker run -d -e DISPLAY=$ip:0 -v /tmp/.X11-unix:/tmp/.X11-unix jess/firefox

ですが、今回は volume の mount はいらないので

• $ docker run -d -e DISPLAY=$ip:0 jess/firefox

にしてみる。$ip には XServer の ip が入っていると仮定します。

実行すると X11 Server 側で firefox が起動します。やったね。

ちなみに 10.0.0.10:2.0 などのフォーマットはこういうことらしいです。

コンテナの中で DISPLAY を設定してみる

さて、docker run の時の -e オプションは単に環境変数を渡すだけみたいですね。

ということは後から変更できたりするかも。

一旦 centos:7 を起動して、後から DISPLAY を設定してみる。

• $ docker run -it centos:7
• # yum install -y epel-release
• # yum install --enablerepo=epel xcalc
• # export DISPLAY=10.0.0.30:0.0
• # xcalc

xcalc は x11 を使う計算機です。

firefox の setup などは難儀なのでこれで代替。

まー、こいつも epel を入れるとか、ちょっとだけ面倒ですが割愛。

結論としては、run した後から DISPLAY を設定しても GUI は起動します。ふむふむ。

ssh 先での GUI Application

DISPLAY が設定できていれば GUI は起動する。

その前提として docker for mac <-> XQuartz 間の疎通が必要。

何故かといえば IP でディスプレイを指定しているからです。

なら、 docker on ssh server <-> XQuartz も可能?

ということで ssh した先でも DISPLAY を設定して xcalc 。

表示される計算機。

なるほど、別に docker だろうと、 ssh 先の linux だろうと、 DISPLAY にデータが送れるのなら GUI process は起動できるっぽい。

この場合、 GUI の描画は X11 経由で mac に、Application のプロセスは ssh した Server の中の docker が起動、なんて状態に。複雑。

ということで、 DISPLAY を適切に設定できれば GUI はぽこぽこ生やせる。

結論

DISPLAY を設定すれば GUI Application も docker で動きます。

というか DISPLAY を設定すれば ssh 先のサーバだろうと何だろうと GUI Application は動きます。

おまけ: xhost 

• $ xhost +

は全てのIPからGUI access を許可するので危なすぎる。

• $ xhost -

で access control を再び有効にできます。

本来なら 

• $ xhost + 10.0.0.20

とかするらしいです。

Docker 触ってると思ったら X Window を触っている。

トレンドを追ってるのか、過去を追ってるのか分からなくなってきます。

参考

• docker/Tutorials/GUI - ROS Wiki
• Docker X11 Client Via SSH - DZone Integration
• OSX + Docker + GUI · GitBook
• | Docker Documentation
• DISPLAY - なんなんなん行く？

https proxy があるネットワークで Docker を動かす

時にプロキシを介さないと外に出られないネットワークがあります。
curl とかは http_proxy や https_proxy の環境変数を設定するだけで外に出られるので楽。
具体的にはこんな感じ。

• $ export http_proxy=http://192.168.100.200:12345
• $ export https_proxy=https://192.168.100.200:54321

しかし docker は環境変数の設定だけでは外に出られない。

具体的には docker pull ができなかった。
docker pull はデフォルトだと https で docker.io に image を取るので引っかかる。

環境

• Ubuntu 16.04 LTS
• Docker: 1.5-1

proxy 設定

素直に公式のドキュメントを見る。

systemd controlled だと /etc/systemd の下に config を書く必要があるらしい。

具体的には

• $ mkdir -p /etc/systemd/system/docker.service.d
• $ vi /etc/systemd/system/docker.service.d/http-proxy.conf
• [Service]
• Environment="HTTP_PROXY=http://192.168.100.200:12345"
• [Service]
• Environment="HTTPS_PROXY=https://192.168.100.200:54321"

でOK。

systemctl restart docker をすると proxy 経由で pull ができるようになります。

参考

• Control Docker with systemd | Docker Documentation
• Configure Docker to use a proxy server | Docker Documentation

tmux 2.7 を全角記号対応させる

2018/03/29 に tmux 2.7 がリリースされました。
ということで自分用の border-ascii 版も update しました。(2.6 の時はこんな感じ)
実際やったことは cherry-pick して細かいところの修正とか。

環境

• OS: macOS 10.12.6
• tmux: 2.7-border-ascii (65784831fcf0040b78d68b180c6ca8c1210e4317)
• utf8proc: 2.1(562edab805b82d66622914d06a5da3f53cd54a17)
• Homebrew: 1.6.0-19-gf9f9dbc
• Homebrew/homebrew-core: (git revision 6e3b1; last commit 2018-04-14)

利用方法

• $ brew tap atton/customs
• $ brew install atton/customs/utf8proc
• $ brew install --HEAD atton/customs/tmux

これで縦に画面分割する時の線が - になります。

--------------------------------- みたいな感じですね。

おまけ: update 手順

私は tmux の自分用 fork を持っているので、まずはそれに patch を当ててビルド。

OK なら homebrew の formula にしてインストール。

最後に homebrew の tap としてインストール、という流れで作業をしました。

今回はちょろっとした問題があったので、メモてがら書いておきます。

tmux の make

まずは最新の tmux を落としてきてpatch を当てます。

• $ git pull upstream # upstream は公式の tmux/tmux です。
• $ git checkout 2.7
• $ git cherry-pick border-ascii # patch の 1 commit を拾います
• $ git checkout -b 2.7-border-ascii

これで patched 2.7 ができました。

次に make します。

• $ ./configure --enable-utf8proc
• $ make

すると以下のような文言が。

WARNING: 'aclocal-1.15' is missing on your system.
         You should only need it if you modified 'acinclude.m4' or
         'configure.ac' or m4 files included by 'configure.ac'.
         The 'aclocal' program is part of the GNU Automake package:
         <http://www.gnu.org/software/automake>
         It also requires GNU Autoconf, GNU m4 and Perl in order to run:
         <http://www.gnu.org/software/autoconf>
         <http://www.gnu.org/software/m4/>
         <http://www.perl.org/>
make: *** [aclocal.m4] Error 127

んー。 aclocal はあるのだけれどどうしてかな。

• $ which aclocal
• /usr/local/bin/aclocal
• $ aclocal --version
• aclocal (GNU automake) 1.16.1

バージョンが 1.15 固定じゃないと動かないとかなのだろうか。

とりあえず調べてみる。

そうすると

• $ touch *

で解決する、とのページが。

うーん。タイムスタンプ周りの問題か。

にしてもこんなんで解決……しました。はい。

ということで動作確認。

• $ ./tmux -V
• tmux master
• $ tmux
• うん。問題無く起動するし画面分割も問題無し。

手で make する分には動く状態になりました。

ということで github の自分用 fork に反映

• $ git push

formula の修正

さて、お次は brew で install できるようにします。

自分用の formula は atton/customs で持っているのでそこへ修正をかける。

その前に local の repository で install できるかを確認します。

素直に 2.6 を 2.7 に置換して、local で install

• $ brew install --HEAD tmux.rb

とすると

Error: Calling <<-EOS.undent is disabled!
Use <<~EOS instead.

と怒られた。ので素直に <<~ を使う。

もう一度 install

• $ brew install --HEAD tmux.rb

install できました。 tmux -V は tmux master と出るので少々確認しづらいですが。

homebrew の tap へ反映

最後に homebrew の tap で使えるようにします。

といっても既に repository は作ってあるので、そこに push するだけです。

さて、最後の install 確認。

• $ brew install --HEAD atton/customs/tmux

問題無く install されました。良し良し。

CentOS7 で root 以外のユーザも Docker を操作できるようにする

基本的に Docker を使う時は root です。
しかし複数人数で Docker を利用したい場合、全員に root をあげるのは良くない。
調べたところ docker というグループに所属させることで、 root でなくても Docker を操作できるらしい。

環境

• OS:CentOS Linux release 7.4.1708 (Core) 
• Kernel: 3.10.0-693.5.2.el7.x86_64
• Docker: version 17.06.2-ee-7, build 925df35

dockerroot group

さて docker group の gid でも見るかと

• $ cat /etc/group | grep docker
• dockerroot:x:985:

すると docker group が無い。

が、 dockerroot というものがある。

• $ sudo gpasswd -a atton dockerroot

して所属させてみる。

しかし、

• $ docker ps 

すると見られない。

Socket の Owner

どうやら /var/run/docker.sock の owner は root:root らしい。

docker を yum install したら dockerroot group を作るのに何故 owner は root のみなんだろ。

まー root 以外に操作させないように念のため、ってことなのかな。

とりあえず dockerroot が読み書きできるように変更。

• $ sudo chown root:dockerroot /var/run/docker.sock

そして一旦 exit して

• $ docker ps

すると見られた。

• $ docker -it run ubuntu:16.04 bash

しても動く。良し良し。

権限とか

ちなみにコンテナ内部で

• $ whoami

すると root と言われる。

あと、他人が起動したコンテナも操作できてしまう。

なので

複数人数で Docker 操作+他人のコンテナに干渉しない

場合は wrapper を作るか、他の手段に頼る必要がありそう。

参考

• Post-installation steps for Linux | Docker Documentation
• CentOS7でsudoなしでdockerを利用するちょっとした工夫 - Qiita
• How can I use docker without sudo? - Ask Ubuntu