理由はわからんけど、たまにコンテナの挙動がおかしくなったり、ディスク食いすぎて領域不足になることもある。
dockerそのもののバージョンアップでエラーあったから、イメージ初期化とコンテナの作り直しやってみた。
今までは記憶に頼って作り直してたけど、忘れそうになってきたのでメモしとく。
バージョン上がってた
昨日気づいたらdockerのバージョンが20から23に上がってた。
21と22飛ばしてるのは、oracleとかみたいにリリース年の末尾２桁使ってるってことか。
先週にローカルvmで定期apt実行してたら、docker起動でエラー出たから原因探してコンテナ作り直した。
aptするときに更新対象が表示されるけど、ローカルvmは躊躇せず全部上げてくようにしてる。
このトラブル解決がええ勉強になる。
自分のlinuxにはローカルvmの中で動いてるものと、gcpで動いているものがある。
gcpが本番、ローカルvmが実験とか検証用。
ローカルvmで問題解決してからgcpの分もコンテナ作成しなおした。
今回はストレージドライバが原因
ローカルvmのはテキスト残すの忘れたけどdevicemapper使ってて、gcpで動いてるのはこんな感じでoverlayってなってた。
:(中略)
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で確認してみた。
このメッセージ横に長くてめっちゃ貼り付けにくかった。
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して修正して起動してみる。
## Requires=docker.socket containerd.service
ExecStart=/usr/bin/dockerd --storage-driver=overlay2 --data-root /gvis/nari/nariDocs/Docker/nariDockerSys指定しなおしたらコンテナ一覧とかイメージ一覧がすっからかんになるやろなって思ったら、やっぱりそう。
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
$いったんdocker停止させて--data-rootにあるフォルダを完全に抹消してから起動する。
最終的に作り直した後のdocker infoにはこんな感じでoverlay2を使ってるのが見えた。
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にしかないものもあるけどだいたいこんな感じ。
$ 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!!
細かいaptも必要で面倒やけど、新しく維持できるのは気持ちいいねぇ。
コンテナ作り直したからgitlabのリモートホスト名も変える
内容は維持できてるけど、ローカルのgitが指し示すホストは作り替える前のホスト名。
originってあるところの次にhttpで始まるホスト名がついてる。
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をテキストエディタに貼り付けて内容確認したものを使う。
git remote set-url origin http://968362845kegq/naritomitsukasa/gvis-memo2023.git
これでpushできる。
