この記事は約7分55秒で読むことができます。

dockerコンテナにbrave-browserをインストール際「–pid=host」とつけるとインストールできた

brave-browserをインストールする手順は以下のコマンドを打つ。実行ユーザーはすべてroot。


apt install -y apt-transport-https curl

apt install -y gnupg  gnupg2 gnupg1

curl -s https://brave-browser-apt-release.s3.brave.com/brave-core.asc | apt-key --keyring /etc/apt/trusted.gpg.d/brave-browser-release.gpg add -

echo "deb [arch=amd64] https://brave-browser-apt-release.s3.brave.com/ stable main" | tee /etc/apt/sources.list.d/brave-browser-release.list

apt update

apt install -y brave-browser

apt-transport-httpsをインストールする際に、policykit-1関連でエラーになる。
以下がdockerコンテナ内でのエラー。


$ apt install -y apt-transport-https curl
Reading package lists... Done
Building dependency tree       
Reading state information... Done
curl is already the newest version (7.58.0-2ubuntu3.9).
apt-transport-https is already the newest version (1.6.12ubuntu0.1).
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
 aptdaemon : Depends: policykit-1 but it is not going to be installed
 packagekit : Depends: policykit-1 but it is not going to be installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).

このエラーで結構手こずっていたが、dockerホスト内でbrave-browserをインストールするとうまいこと起動してくれた。ライオンのロゴが出てきて、嬉しくなる。

GUIアプリで遊んでいると、クライアント(dockerコンテナ)で起動したGUIアプリをXサーバー(dockerホスト)に転送するX転送と/sbin/initコマンド起点のsystemd管理(dbusプロセスと関連)をうまいこと同居させたいなーと考えるようになった。

よく見る「Failed to connect to bus: No data available」のエラー文言で検索していたら、以下のサイトを見つけた。

Docker – dockerコンテナ内からラズベリーパイホストを再起動する

ベストアンサーに以下の文言を発見した。


 docker run -v /run/dbus:/run/dbus -v /run/systemd:/run/systemd --pid=host ...

公式で調べた。

PID 設定(–pid)

どうやら、–pid=hostとdocker run時に指定すると、dockerコンテナ内でdockerホスト側の PID 名前空間を使うことができるようだ。

このオプションを指定した状態で、再度作り直したら、エラーも特に出ず、無事にライオンのロゴをdockerコンテナで見ることができた。

このdockerコンテナ内で、以下のコマンドをdockerコンテナとdockerホストで実行すると同じような出力が得られる。


ps aux

もう少し調べていると、発見している方がすでにいた。

Dockerで、PID名前空間を他のコンテナと共有する

デバッグ用にコンテナ用意して、そのコンテナにインストールされている機能を別の検証コンテナで借用できる仕組みのようだ。「dockerコンテナ 対 dockerコンテナ」と「dockerホスト 対 dockerコンテナ」で使い分けることができるようだ。

–pid=hostのオプションはデスクトップアプリケーションとかをお試しで入れて見るような際に便利なのかな。snapなどに応用効きそう。便利そうなオプションを発見できて良かった。

pid=1の/sbin/initプロセスもコンテナ内でみることができるようになったので、もしかしたら、systemdもいけるかなど思ったが、以下のエラーがdockerコンテナで見ることができた。


$ systemctl
Failed to list units: Connection reset by peer


$ sudo systemctl
Running in chroot, ignoring request.


$ systemctl status
Failed to read server status: Connection reset by peer


$ sudo systemctl status
Running in chroot, ignoring request: status

エラーでしらべると、以下のサイトを発見した。

Connection reset by peer on systemctl as root

アンサーにあるコードを実行してみた。


$ git clone https://github.com/DamionGans/ubuntu-wsl2-systemd-script.git
$ cd ubuntu-wsl2-systemd-script
$ bash ubuntu-wsl2-systemd-script.sh

wsl2じゃないので、だめだった。ただ、今後需要がありそうなレポジトリを発見できてよかった。

「Running in chroot, ignoring request: status」で調べてみた。wikiにもあった。結構ヤバそうな操作だ。

chroot

結構有名らしい。

Start a systemd service inside chroot

詳しそうなページを見つけた。systemd-nspawnコマンドでいい感じにできそう。dockerはこのコマンドの機能を使いやすくgolangに移植したのかな。

systemd for Administrators, Part VI

systemd-nspawnコマンド単一の機能検証したほうがよさげ。–pid=hostをしていない検証コンテナでsystemd-nspawnコマンドの動きを見てもいいかも。ないしはdockerホストで検証など。

archLinux端末用意しないと。。
これは試したい。。

開発環境の構築に systemd-nspawn を使用する

Leave a Reply

Your email address will not be published. Required fields are marked *