なにかを試すときに一時的なコンテナを作ってそこで作業してることがよくあります
そこで作ったものを Windows 側で使いたいなんてことがときどきあります
Windows 側とまで行かなくてもホスト側の WSL に持ってきたいこともあります
また逆に Windows 側で用意したファイルをコンテナで使いたかったりします

それを見越して とりあえずで docker run するときにカレントディレクトリをコンテナの /mnt にマウントするようにしてるのですが 時々忘れます
そして忘れたときに限ってコピーしたくなったりするものです
コンテナを作り直してもいいのですが 色々パッケージをインストールしたり 環境の設定を変えたりしているともう一度やり直しは面倒です
その時点のコンテナをイメージ化してそこからコンテナを作るという方法もとれますが 一時的なもののためにイメージ化するのも面倒です
それならコンテナを作り直しでもいいかなと思うくらい

ただやっぱり面倒なのでいい方法がないかなと考えていてふと思いつきました
WSL で sshd サーバーを起動しよう
コンテナから WSL には通信できるので scp でコピーできます
やってみると簡単にできました

sudo apt install openssh-server
sudo service ssh start

という感じです
sshd が入ってなければ sshd のインストールとサービスの起動をします
あとはコンテナから

scp file.txt user@172.21.76.78:

みたいな感じに使います

user は WSL のユーザー名で 172.21.76.78 は WSL の IP アドレスです

WSL まで持ってきたら Windows からは \\wsl$\... のフォルダでアクセスできるので扱いやすいです

---

以前使ってた方法

◯ http

ウェブサーバーを起動して GET/POST で通信してました
ウェブサーバーは扱いやすいですし GET だけなら python3 がデフォルトで入ってるので http.server モジュールの起動だけで使えるなど楽でした
しかし POST で保存するとなると面倒ですし GET に揃えると送りたい側でサーバーを起動しないといけないです
また フォルダをコピーしたいときには zip 化するなど一手間が必要でした
コンテナ環境だと zip の操作コマンドも入ってなかったりしますし

◯ cifs mount

フォルダのコピーなら共有フォルダがあると便利です
ただ Linux の cifs マウントって結構面倒ですし 頻繁にセットアップ時にうまく行かなくてググってます
オプションも覚えづらくて毎回ググる必要があります

Windows と Docker コンテナ間が直接通信できたらこれでもいいのですが ネットワークが違うので Windows ←→ WSL と WSL ←→ コンテナでしか通信できないです
それなら ssh を通して scp 等のコピーのほうが手軽だと思います

---

書いた後で思い出しましたが そういえば docker コマンド内にも cp みたいなのがあった気がします
コンテナ内からのコマンドで実行できませんが もうひとつ WSL ウィンドウを開いてホスト側から操作する場合はこっちでもいいかもしれません

久々に使うと忘れてるので

「docker build」 で指定するのは Dockerfile ファイルじゃなくて Dockerfile があるフォルダ
コマンドを実行したカレントディレクトリを問わずに そのフォルダがカレントディレクトリとしてビルド処理が実行される
なので COPY コマンドの from 側の相対パスは指定した Dockerfile のあるフォルダになる

もっと正確にいうと 選択したフォルダがビルドのコンテキストになる
デフォルトではコンテキストのルートにある Dockerfile が使われる
コンテキストの中にあるファイルしか使えないので COPY で 「../」 を使って外側を参照できない

例えば複数の Dockerfile で共通のデータを使いたくてこういうフォルダ構造になってる場合

- common/common_file.txt
- image1/Dockerfile
- image2/Dockerfile

image1 をコンテキストにしてしまうと common の中身を参照できない
コンテキストを common や image1 があるフォルダにして 使用する Dockerfile のパスを別に指定することで解決できる
-f オプションを使って コンテキストのルートからの相対パスで Dockerfile の場所を指定する
ファイル名も指定するので Dockerfile という名前以外も可能

docker build -f image1/Dockerfile .

この場合 image1 のビルド時に image2 もコンテキストに含まれる
コンテキスト内のすべてのデータはビルド時にコピーされるので image2 のデータのコピーはムダになる
.dockerignore ファイルを用意することでコンテキストからファイルを除外できる

- image1/Dockerfile.dockerignore
- image2/Dockerfile.dockerignore

を作ってそれぞれのビルド時にコンテキストから除外したいファイルのパターンを指定する
基本は .gitignore みたいな記法
記法の詳細
https://docs.docker.com/build/building/context/#syntax

・ 最初に / があってもなくてもコンテキストのルートからのパスとして扱われる
・ ? や * のワイルドカードが使える
・ */foo でルートの任意のサブディレクトリの foo
・ **/foo で任意の階層の foo
・ # でコメント
・ ! で除外指定

環境はストア版 WSL (Ubuntu) で systemd から Docker を起動します
インストール直後はなんの問題もなく docker-ce をインストールして systemd から起動するだけで普通に使えていたのですが 強制終了されてから動かなくなりました
再起動の原因はストア版 WSL が勝手に更新されること
更新時にそのアプリが終了されるので WSL が実行中だと強制終了されてしまいます
その後に WSL を起動して Docker を使おうとすると動きません

docker コマンドを実行して docker サーバーと通信しそうなところで反応がなくてずっと応答が返ってこない状態です
systemctl status で見てみると inactive らしいですが ランプは緑色でよくわからない状態です
停止してみようにも失敗します
sock ファイルのせいでアクティブなままになってるみたいな警告が出てました
sock ファイルは残ってたので削除して containerd も停止してから再起動してみました
これでも解決しません
WSL ごと停止して再起動してみても同じ状況になります
sock ファイルは再度作られていて journalctl でログを見ると 一旦起動してすぐ終了してる感じです

この現象はこれまでも数回起きていて docker を再インストールすれば直ってます
アップデートでもパッケージを入れ直すことになるみたいなので アップデートでもいいです
発生頻度は数ヶ月に 1 回で その頃には更新があることも多いのでアップデートで対処してることが多いです

はっきりした原因がわからないのが気持ち悪いですが とりあえずの対処方法はわかるので今のところこれで対処してます
ただ今回はアップデートで直ったものの docker-ce は更新対象に含まれてなかったです
containerd は含まれていたのでこっちが原因なのかもしれないですが containerd は再起動後も問題なく動いていて stop/start でもエラーもなかったです

少し気になってるのはストア WSL の更新で強制終了してるというところです
「wsl --shutdown」 で強制停止は何度かあるはずですが このときは Docker に問題が起きてない気がします
WSL 自体の更新のせいでコンテナの仕組みに影響してる ということもありえるのでしょうか
再インストールすれば最新版に更新されますし アップデートでその変更に対処してるのかもしれません
ストア版にしてから発生というのも ストア版になるまでは WSL 自体の更新はほぼなかったので気づかなかっただけなのかもです

結構ありえるかもと思ってみたものの アップデートしないとコンテナが動かなくなるような変更を何度もするかという疑問がありますし 変更履歴を簡単にみても WSL 対応みたいなのはなかったです

---

その後 また同じ状態が発生しました
ただ今回は前と違って containerd が停止しています
起動しようとしても反応がなく 1 分程度待っても終わりません
起動コマンドは強制終了して再インストールを試しました
期間が短いこともあって containerd も docker-ce も最新版で apt のアップデートはなかったので再インストールです
しかし インストール直後のセットアップ処理で起動しようとするからか containerd のセットアップで固まったままになります
強制終了して何度か試しても同じ結果です

固まった状態で CPU の使用率や IO の負荷を見ても特に負荷が高いわけでもなく 何もしてない待機状態みたいです
事前に起動しないといけないサーバーとかはないと思うのですけど
WSL 自体の再起動も試しましたが変わりません

処理が重たくて時間がかかってるわけじゃないなら なにかの対処をしないと改善しなさそうだけど 原因が見当たらないです
半分あきらめて 固まったまま放置していて 数十分後に見てみるとなぜかコマンドが完了していました
containerd のステータスを見ると起動しています
docker も問題なく起動できました

やっぱり原因は不明ですが containerd の起動で進まないならしばらくそのまま放置で起動できる場合もあるようです

Ubuntu 20.04 の環境を 22.04 にアップグレードすると Docker が起動しなくなりました
この環境では docker.io を入れて service コマンドで起動していました

今年に入ってから WSL を入れた環境だと Ubuntu 20.04 ですが docker サービスが見つからないエラーになっていて docker.io をやめて消して リポジトリを追加してから docker-ce を入れていました
🔗 WSL2 で Docker サービスが見つからない

この環境でも docker-ce にしないといけないのかと docker-ce に置き換えましたが変わりません

sudo service docker start

では OK と表示されるのに docker に接続できず

sudo service docker status

を見ると起動していないと言われます

この現象ってちょっと前に debian の WSL であった記憶が……
🔗 WSL2 の debian で docker サービスが起動しない

このときと同じように iptables をレガシーモードにすることで起動できるようになりました

sudo update-alternatives --set iptables /usr/sbin/iptables-legacy
sudo update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy

昔は来るとか言われてた Fedora の公式 WSL も来なかったですし 最近はディストリビューションに代わり映えがしない気がします
みんな何使ってるだろうとネットを見てると CentOS だったり ストアにおいてないディストリビューションを使ってるという書き込みもところどころで見かけます
以前でも公式に用意されないディストリビューションを WSL で使うための手順は見かけましたが とても面倒で複雑な方法でそこまでして入れるなら Ubuntu でいいよと思ったほど
しかし 思ったより見かけるのでやり方が簡単になったのかなと調べてみると なんと Docker コンテナのエクスポートデータを WSL にインポートするとかいう驚きの方法
WSL 内でバックアップしたり クローンしたりするために export/import 機能があるのは知っていましたが Docker コンテナのフォーマットと同じとは思いませんでした

WSL の export/import 機能は 昔試したときは謎のエラーで動作しなくて結局使ってませんでしたが どういうフォーマットか気になるのでエクスポートを試してみました

wsl --export Ubuntu export.tar

というコマンドを Windows 側で実行すれば Ubuntu ディストリビューションを export.tar ファイルにエクスポートできます
今回は成功したので tar ファイルの中身を見てみます

一番上の階層は「.」フォルダだけ
「.」フォルダの中に

bin
boot
dev
etc
home
mnt
proc
usr
var

など Linux のルートにあるフォルダが並んでいます
VM で使われる仮想ディスク的な専用のファイルではなく 単純にルートからすべてをファイルとしてエクスポートしてるようです
そんなに使ってないのに 2.4GB もありましたが ファイルを tar でまとめただけだからなんですね
なんとなく 7z に圧縮してみると 850MB になって 35% のサイズになりました
バックアップ用途なら圧縮が効率良さそうです

boot や proc ってどうなってるのと思いましたが中身は空でフォルダだけした
データとして必要な etc や usr などのファイルだけをエクスポートして その他の実行時に使うものは WSL や Docker の各環境で用意するってことなんですかね

エクスポートされたデータは上記の通りで中身だけです
WSL としてのメタデータはなくて バージョンやディストリビューション名もありません
一応 /etc/os-release を見ればディストリビューションの種類の確認はできますけど 中身をみることになります
WSL はバージョンの 1 か 2 で結構違っていますが 設定やプログラムやユーザデータ等をファイルとして export/import するのだと 1 でも 2 でも問題ないのかもしれません
WSL 上のディストリビューション名が含まれてないので 同じディストリビューションで Ubuntu_1, Ubuntu_2, ... のように複数の WSL ディストリビューションを作ることもできます

Docker を使っていて それなりによく使うツールで試したいことがあると毎回準備が面倒でコンテナは使い捨てではなく使いまわしすることが多いので Docker コンテナではなく WSL ディストリビューションとしてしまうのもありかもですね

docker コマンドを見ていたら logs というのがあって何が見えるんだろうとためしてみたら 操作していたログが全部見れました
fedora コンテナを起動して適当にコマンドをいくつか打ってみます

user@PC005:/mnt/c/WINDOWS/system32$ sudo docker run -it fedora
[root@b50fa270db7e /]# ls
bin  boot  dev  etc  home  lib  lib64  lost+found  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var
[root@b50fa270db7e /]# cat /etc/fedora-release
Fedora release 35 (Thirty Five)
[root@b50fa270db7e /]# python3
Python 3.10.0 (default, Oct  4 2021, 00:00:00) [GCC 11.2.1 20210728 (Red Hat 11.2.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 1+1
2
>>> exit()
[root@b50fa270db7e /]# exit
exit

単純に出力する ls や cat だけでなく python3 のインタラクティブモードで処理を実行したりもしてます
logs サブコマンドでこのコンテナを指定すると

user@PC005:/mnt/c/WINDOWS/system32$ sudo docker logs b50 -t
2022-02-02T08:27:57.299750500Z [root@b50fa270db7e /]# ls
bin  boot  dev  etc  home  lib  lib64  lost+found  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var
2022-02-02T08:28:04.372611200Z [root@b50fa270db7e /]# cat /etc/fedora-release
Fedora release 35 (Thirty Five)
2022-02-02T08:28:14.276586600Z [root@b50fa270db7e /]# python3
Python 3.10.0 (default, Oct  4 2021, 00:00:00) [GCC 11.2.1 20210728 (Red Hat 11.2.1-1)] on linux
2022-02-02T08:28:14.303025200Z Type "help", "copyright", "credits" or "license" for more information.
2022-02-02T08:28:18.316116000Z >>> 1+1
2022-02-02T08:28:18.316329100Z 2
2022-02-02T08:28:20.756528500Z >>> exit()
2022-02-02T08:28:29.796579000Z [root@b50fa270db7e /]# exit
exit-02-02T08:28:29.796598700Z

自分の入力したコマンドも出力もすべて表示できました
-t オプションでタイムスタンプを表示です
-t をなくせばタイムスタンプなしでコンソール上の見た目と一緒です

ログデータはただのテキストではなく シェルのエスケープ文字等も含まれるようでタイムスタンプを表示すると一部おかしくなったりします
最後の行で 2022 が exit に置き換わっていますが こういうのがたまに発生します

ログの実体のファイルは↓にあります
/var/lib/docker/containers/{id}/{id}-json.log
id にコンテナ id が入ります

user@PC005:/mnt/c/WINDOWS/system32$ sudo ls /var/lib/docker/containers
b50fa270db7ea5ee9eb14aadbe09fe9803aeae6f54ba342600f0079d4c43aef8

user@PC005:/mnt/c/WINDOWS/system32$ sudo cat /var/lib/docker/containers/b50fa270db7ea5ee9eb14aadbe09fe9803aeae6f54ba342600f0079d4c43aef8/b50fa270db7ea5ee9eb14aadbe09fe9803aeae6f54ba342600f0079d4c43aef8-json.log
{"log":"\u001b]0;@b50fa270db7e:/\u0007\u001b[?2004h[root@b50fa270db7e /]# ls\r\n","stream":"stdout","time":"2022-02-02T08:27:57.2997505Z"}
{"log":"\u001b[?2004l\r\u001b[0m\u001b[01;36mbin\u001b[0m  \u001b[01;34mboot\u001b[0m  \u001b[01;34mdev\u001b[0m  \u001b[01;34metc\u001b[0m  \u001b[01;34mhome\u001b[0m  \u001b[01;36mlib\u001b[0m  \u001b[01;36mlib64\u001b[0m  \u001b[01;34mlost+found\u001b[0m  \u001b[01;34mmedia\u001b[0m  \u001b[01;34mmnt\u001b[0m  \u001b[01;34mopt\u001b[0m  \u001b[01;34mproc\u001b[0m  \u001b[01;34mroot\u001b[0m  \u001b[01;34mrun\u001b[0m  \u001b[01;36msbin\u001b[0m  \u001b[01;34msrv\u001b[0m  \u001b[01;34msys\u001b[0m  \u001b[30;42mtmp\u001b[0m  \u001b[01;34musr\u001b[0m  \u001b[01;34mvar\u001b[0m\r\n","stream":"stdout","time":"2022-02-02T08:27:57.30205Z"}
{"log":"\u001b]0;@b50fa270db7e:/\u0007\u001b[?2004h[root@b50fa270db7e /]# cat /etc-o\u0008\u001b[K\u0008\u001b[K/fedora-release \r\n","stream":"stdout","time":"2022-02-02T08:28:04.3726112Z"}
{"log":"\u001b[?2004l\rFedora release 35 (Thirty Five)\r\n","stream":"stdout","time":"2022-02-02T08:28:04.3758671Z"}
{"log":"\u001b]0;@b50fa270db7e:/\u0007\u001b[?2004h[root@b50fa270db7e /]# python3\r\n","stream":"stdout","time":"2022-02-02T08:28:14.2765866Z"}
{"log":"\u001b[?2004l\rPython 3.10.0 (default, Oct  4 2021, 00:00:00) [GCC 11.2.1 20210728 (Red Hat 11.2.1-1)] on linux\r\n","stream":"stdout","time":"2022-02-02T08:28:14.3029901Z"}
{"log":"Type \"help\", \"copyright\", \"credits\" or \"license\" for more information.\r\n","stream":"stdout","time":"2022-02-02T08:28:14.3030252Z"}
{"log":"\u003e\u003e\u003e 1+1\r\n","stream":"stdout","time":"2022-02-02T08:28:18.316116Z"}
{"log":"2\r\n","stream":"stdout","time":"2022-02-02T08:28:18.3163291Z"}
{"log":"\u003e\u003e\u003e exit()\r\n","stream":"stdout","time":"2022-02-02T08:28:20.7565285Z"}
{"log":"\u001b]0;@b50fa270db7e:/\u0007\u001b[?2004h[root@b50fa270db7e /]# exit\r\n","stream":"stdout","time":"2022-02-02T08:28:29.796579Z"}
{"log":"\u001b[?2004l\rexit\r\n","stream":"stdout","time":"2022-02-02T08:28:29.7965987Z"}

一つ一つの行が JSON 形式で 日付や本文が入っています

Docker は試しにあれこれやるときによく使うので その時のログをコンソールだけじゃなくてファイルにもログを残しておきたいってときに便利そうです
本来は シェルで自分が操作したログではなく データベースやウェブサーバのサービスを起動させたときのログを見る用途だと思いますけど

mariadb と postgresql で機能比較しようとしたとき とりあえず Docker 環境で動かそうと思ったけど それぞれを別コンテナにしてネットワーク関係の設定をして というのは面倒だったので 1 つの fedora のコンテナにまとめて入れることに
だけどそうすると systemctl が使えなくていつもの方法が使えず困ったので systemd なしで初期化と起動する方法
コンテナは fedora34 を使用

◯ postgresql

インストール

dnf install postgresql postgresql-server

バージョンは 13
最初は initdb が必要だけど

postgresql-setup --initdb

は systemd が必要でエラーになる
代わりに pg_ctl コマンドを使う
-D で data フォルダの場所の指定が必要
postgres ユーザの必要があるので su コマンドを通す

su postgres -c "pg_ctl -D /var/lib/pgsql/data initdb"
su postgres -c "pg_ctl -D /var/lib/pgsql/data start"

これで起動できたので

psql -U postgres

で接続できる

◯ mariadb

インストール

dnf install mariadb mariadb-server

バージョンは 10.5
mariadb も root ユーザじゃなく mysql ユーザに変更が必要
root で mariadb-install-db を実行すると root ユーザのファイルになるので 起動時に権限不足でファイルが読めなくてエラーになって即終了してた
mysql ユーザはシェルが指定されてないみたいで -s で bash 指定が必要だった

su mysql -s /usr/bin/bash -c "mariadb-install-db"
su mysql -s /usr/bin/bash -c "/usr/bin/mysqld_safe --datadir=/var/lib/mysql"

上側の mariadb-install-db コマンドの出力に起動方法のコマンド (下側) が表示される

fedora 35 で確認したいことがあったので Docker で fedora 35 のコンテナを起動
dnf でパッケージをインストールしようとしたらエラーでインストールできない

Errors during downloading metadata for repository 'fedora':
  - Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-35&arch=x86_64 [getaddrinfo() thread failed to start]
Error: Failed to download metadata for repo 'fedora': Cannot prepare internal mirrorlist: Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=fedora-35&arch=x86_64 [getaddrinfo() thread failed to start]

ネットにつながらない？

単に curl を使うと

# curl https://google.com
curl: (6) getaddrinfo() thread failed to start

見覚えのないエラー
dnf のエラーメッセージ的には名前解決の問題みたいなので IP 直接指定で ping してみる
とりあえずこういうときによく使う 8.8.8.8

ping 8.8.8.8

ping コマンドが入ってないらしい
入れたいけど dnf が使えない
8.8.8.8 はウェブサーバがないので curl で試せない
ホスト側で適当なウェブサイトの IP アドレスを調べてから curl で確認

# curl --head -k https://52.69.186.44
HTTP/2 301
content-length: 0
location: https://github.com/

レスポンスを受け取れてるので名前解決の問題であってそう
でもなんで？
fedora だし多少のバグありは仕方ないと思ってるけど rawhide でもないし このイメージのリリースは 20 日ほど前
前回の cifs-utils みたいな一部の用途ならまだしも 名前解決できないような致命的なバグをここまで放置は考えづらい

探してみるとこんな記事が
https://medium.com/nttlabs/ubuntu-21-10-and-fedora-35-do-not-work-on-docker-20-10-9-1cd439d9921

fedora 35 だけじゃなく Ubuntu 21.10 でも発生する問題みたい
これらは glibc のバージョンが 2.34 になっていてこのバージョンでは clone のシステムコール関係の変更があったみたい
その変更に Docker が対応できてないからエラーになっていて Docker のバージョンを上げればいいんだとか
バージョン 20.10.10 で修正されたようで Ubuntu のパッケージだと 20.10.7 で修正されてるらしい

Linux 環境で動きを確認したいところがあって WSL2 内の Docker を使います
ファイルがいくつかあって編集して実行を繰り返す時 コンテナ内のコマンドラインだけで作業するのは不便が多いです
コンテナのコマンドラインでは実行だけにして ファイル操作は Windows 側の VSCode などで編集したいです

コンテナ内だし samba とかを入れてのフォルダ共有とかだと面倒そうです
WSL なんだし /mnt/c で C ドライブにアクセスできるんだから docker run するときに --mount でマウントしてしまえばできないかなと試してみると あっさり解決できました

sudo docker run -it --mount type=bind,source=/mnt/c/files/tmp,target=/mnt centos:8

コンテナのイメージはとりあえず centos8 にしました
C:\files\tmp をコンテナ内の /mnt で見れます
あとはこのフォルダ内に必要なファイルを作って シンボリックリンクでそれぞれの場所に配置します

この方法だと実体は Windows 上のファイルです
読み書き速度が求められる場合は WSL2 内のフォルダをコンテナにマウントして Windows からは \\wsl$\ でアクセスするほうが良いかもです

気分を変えて debian を使っていて docker を起動しようとしたら起動できませんでした
実行するとデーモンにつながらないというエラーで status では failed になってます

user@SURFACE:~$ docker -v
Docker version 18.09.1, build 4c52b90
user@SURFACE:~$ sudo docker run -it centos:8
[sudo] password for user:
docker: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?.
See 'docker run --help'.
user@SURFACE:~$ sudo service docker status
[FAIL] Docker is not running ... failed!

start したときは ok って書いてたはずだけど
もう一度 start してみるも status では failed と言われます

user@SURFACE:~$ sudo service docker start
grep: /etc/fstab: No such file or directory
[ ok ] Starting Docker: docker.
user@SURFACE:~$ sudo service docker status
[FAIL] Docker is not running ... failed!

debian だと特別な設定いったりするのかなと調べると同じ問題の issue が
https://github.com/microsoft/WSL/discussions/4872

なんか fstab を作って iptables をレガシーモードにすればいいんだとか
よく見れば service の start 時に fstab がみつからないとメッセージが出てますし
docker のログには iptable がどうこういうメッセージが出てました

やってみると

user@SURFACE:~$ sudo touch /etc/fstab
user@SURFACE:~$ sudo update-alternatives --set iptables /usr/sbin/iptables-legacy
update-alternatives: using /usr/sbin/iptables-legacy to provide /usr/sbin/iptables (iptables) in manual mode
user@SURFACE:~$ sudo update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy
update-alternatives: using /usr/sbin/ip6tables-legacy to provide /usr/sbin/ip6tables (ip6tables) in manual mode
user@SURFACE:~$ sudo service docker start
[ ok ] Starting Docker: docker.
user@SURFACE:~$ sudo service docker status
[ ok ] Docker is running.
user@SURFACE:~$ sudo docker run -it centos:8
Unable to find image 'centos:8' locally
8: Pulling from library/centos
7a0437f04f83: Pull complete
Digest: sha256:5528e8b1b1719d34604c87e11dcd1c0a20bedf46e83b5632cdeac91b8c04efc1
Status: Downloaded newer image for centos:8
[root@b200f1bb83d4 /]#

無事 status も ok となりコンテナを起動できました

以前 試したときは特に困りもせずにすんなり使えたのに
別の環境で Docker を使えるようにしようとしたらうまくいきません

docker パッケージは Ubuntu の標準パッケージの docker.io のはず
Fedora ではパッケージ名が途中で docker から docker-ce に変わりましたが
Ubuntu だと docker.io はあるけど docker-ce はないです
リポジトリの追加でつかえるかもですがそういう手間がかかることは前回もしてないはずです

docker.io のインストールはできましたが docker デーモンを起動できません
WSL は systemd が使えないので service コマンドを使うのですが

service docker start

で docker が見つからないと言われます
dockerd や docker.io にしてみてもやっぱりみつからないようです

service --status-all

のリストでもそれらしいものはありません
docker コマンドや systemd 用の service ファイルはあるのですけどね
以前は service コマンドで普通にデーモンが起動できたはずです

実行時のエラーならともかく service 自体がないのだとインストールの問題だと思うので Ubuntu や docker.io パッケージのバージョンの問題でしょうか……

新しく docker run で起動したコンテナで dnf を使うと全然進まない
Ctrl-C で停止したら名前解決失敗してるようなエラーが出てきた
curl で Google にアクセスしてもホスト名が解決できないとか
一旦コンテナを出て ホストから curl すると名前解決できてる

SELinux や firewalld など通信部分に影響しそうなものはホストもコンテナも止まってる
コンテナを新しく起動し直しても一緒

その他いろいろ試したけど全部ダメで最終的に docker デーモンの再起動したら動くようになった
なんだったんだろう

動かしたい PHP のページがあるけど ちょうど使える環境がない
Docker に CentOS のイメージ入ってたしこれでいいか

みたいな感じで試してみたら systemctl が動かない！


Docker だと PID 1 が systemd じゃなくて systemd が起動していません
そのせいで systemctl コマンドは使えません

Apache の場合 httpd コマンドを実行するだけでバックグラウンドで動作します
再起動や停止するには httpd -k に stop などのコマンドを指定します

httpd -k stop
httpd -k restart

また systemd が使えないと apachectl も同様に使えません

System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down