理由はわからんけど、たまにコンテナの挙動がおかしくなったり、ディスク食いすぎて領域不足になることもある。 dockerそのもののバージョンアップでエラーあったから、イメージ初期化とコンテナの作り直しやってみた。

今までは記憶に頼って作り直してたけど、忘れそうになってきたのでメモしとく。

バージョン上がってた

昨日気づいたらdockerのバージョンが20から23に上がってた。 21と22飛ばしてるのは、oracleとかみたいにリリース年の末尾２桁使ってるってことか。

先週にローカルvmで定期apt実行してたら、docker起動でエラー出たから原因探してコンテナ作り直した。 aptするときに更新対象が表示されるけど、ローカルvmは躊躇せず全部上げてくようにしてる。 このトラブル解決がええ勉強になる。

自分のlinuxにはローカルvmの中で動いてるものと、gcpで動いているものがある。 gcpが本番、ローカルvmが実験とか検証用。

ローカルvmで問題解決してからgcpの分もコンテナ作成しなおした。

今回はストレージドライバが原因

ローカルvmのはテキスト残すの忘れたけどdevicemapper使ってて、gcpで動いてるのはこんな感じでoverlayってなってた。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

 :(中略)
Server:
 Containers: 5
  Running: 0
  Paused: 0
  Stopped: 5
 Images: 43
 Server Version: 20.10.23
 Storage Driver: overlay
  Backing Filesystem: extfs
  Supports d_type: true
 :(中略)

エラーをjournalctl -xeu docker.serviceで確認してみた。 このメッセージ横に長くてめっちゃ貼り付けにくかった。

1
2
3

failed to start daemon: error initializing graphdriver: prior storage driver overlay is deprecated and will be removed in a future release; 
update the the daemon configuration and explicitly choose this storage driver to continue using it; 
visit https://docs.docker.com/go/storage-driver/ for more information

ストレージドライバ関連でエラー。 エラーメッセージにあるURL開くと、「devicemapperは性能貧弱やし非推奨やで」とか「overlayは非推奨」ともある。 今のデフォルトはoverlay2っぽい。 gcpのは去年の5月に全部作り直したのに、なんでoverlay2やなかったんやろ。

デーモンの起動オプションをvi /lib/systemd/system/docker.serviceして修正して起動してみる。

1
2

## Requires=docker.socket containerd.service
ExecStart=/usr/bin/dockerd --storage-driver=overlay2 --data-root /gvis/nari/nariDocs/Docker/nariDockerSys

指定しなおしたらコンテナ一覧とかイメージ一覧がすっからかんになるやろなって思ったら、やっぱりそう。

1
2
3

$ docker images
REPOSITORY   TAG       IMAGE ID   CREATED   SIZE
$

いったんdocker停止させて--data-rootにあるフォルダを完全に抹消してから起動する。 最終的に作り直した後のdocker infoにはこんな感じでoverlay2を使ってるのが見えた。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

Server:
 Containers: 9
  Running: 9
  Paused: 0
  Stopped: 0
 Images: 10
 Server Version: 23.0.0
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
 :(中略)

1月末まで100GBぐらい/dockerの領域使ってた。

/dev/sdb                   629G  109G  489G  19% /docker

今は27GB。減ったなぁ。散髪した後みたいなスッキリした気分。

/dev/sdb                   629G   27G  571G   5% /docker

ローカルvmもgcpのも、永続化領域使って動かしてるから、gitlab/django/xrdp/maridb/jupyterlab/redhat8・9とか作業ディレクトリは全部維持できる。 電子証明書は作り直しになるから、それだけ配り直して設定しなおした。

必要なら起動オプション見直す

前は–containerdのオプションつけてた。

ExecStart=/usr/bin/dockerd -–containerd=/run/containerd/containerd.sock --data-root /docker/nariDockerSys

つけなくてもエラー出ないしコンテナも動いたので、外して使うことにした。 これもスッキリ。

ExecStart=/usr/bin/dockerd --data-root /docker/nariDockerSys

実は必要なものがあるのかもしれんけど、そのときまた考える。

コンテナを順番に起動する

バックエンドを起動してからフロントエンドを起動してく。 起動するとイメージ取り直しからやってくれる。

ローカルvmの場合、データベース起動、LDAPサーバ起動を先にやる。 依存性がないものは最初でも最後でもいい(jupyterlab/gitlab)。 jupyterlabはmac/windows/linuxどこからでも使うメモのファイルを置いてるから、先にやったほうがいいかも。

その後でフロントエンドのredhat起動、django4起動ってやってく。 最後にxrdpはビルドしてから起動して、全部のサービスへの接続確認実施。

ローカルvmにしかないものとか、gcpにしかないものもあるけどだいたいこんな感じ。

1
2
3
4
5
6
7

$ docker-compose up sv_jupyter
$ docker-compose up sv_mariadb
$ docker-compose up SVgitlab2023
$ docker-compose up sv_django
$ docker-compose up sv_https-portal
$ docker build -f ./ubuntu-xfce/Dockerfile -t ubu:22gvis .
$ docker-compose up cl_ubu22

アプリケーションの挙動を確認する

最後のcl_ubu22はxrdpコンテナなので、全部のサービスを使うための入り口みたいなもん。 ここからブラウザでサービスを使うし、gitlabにアプリケーションやファイルの履歴を残してる。 こんな感じで確認できたらOK!!

gvis-docker-ubu22xrdp

細かいaptも必要で面倒やけど、新しく維持できるのは気持ちいいねぇ。

gvis-docker-ubu22xrdp

コンテナ作り直したからgitlabのリモートホスト名も変える

内容は維持できてるけど、ローカルのgitが指し示すホストは作り替える前のホスト名。

originってあるところの次にhttpで始まるホスト名がついてる。

1
2
3

nari@gvisMac gvis-memo2023 % git remote -v 
origin	http://01910255bdfb/naritomitsukasa/gvis-memo2023.git (fetch)
origin	http://01910255bdfb/naritomitsukasa/gvis-memo2023.git (push)

これを変えとかないとpushしたとき、「そんなホストあらへんで」ってなる。

作り直したホストからいったんgit cloneしておいて、git remote -vってしてからURL調べたら、そのホストを設定する。

クローンするURLはgitlabのリポジトリ見たらコピーするボタンがあるから、そのURLをテキストエディタに貼り付けて内容確認したものを使う。

http://968362845kegq/naritomitsukasa/gvis-memo2023.git

git remote set-url origin http://968362845kegq/naritomitsukasa/gvis-memo2023.git

これでpushできる。