仮想化ではvmwareから利用しはじめてもう15年以上たつ。
dockerは5年以上たった。
実務でvirtualboxやvagrant使うことはあったけど、wslでdocker使ったことない。
そもそもwslってどんなんやろ、ってとこから始まる。
dockerはlinuxで動かしてmacからdjango開発ソース作りながら使ってる。
実務でgke使うので、そのdocker環境をwslで扱うことになったので練習してみる。
win11 + wsl2 + docker
msの概要ドキュメントをまずは読んだ。
linuxバイナリを動かす環境をサンドボックスみたいな感じで使えるってことか。
wsl1が最初にあったもので、wsl2ならlinuxカーネルが動くらしい。
vscodeのプラグインにremote wsl拡張機能ってのがあるから推奨ともあった。
wslインストール
導入方法を解説してくれてるサイトがあった。
win10と11で導入方法が違うらしい。winverしたときに見えるバージョンにも制限あるらしい。
作者さんありがとう。
win10だとOS機能を追加してからmicrosoft storeからダウンロードして使うらしい。
win11だとwsl --installってやったらええだけ。
docker desktopインストール
すんなり入った。
OS再起動必要やけどdockerは使えるみたいでhello-worldでイメージをpullしてできてた。
docker desktopの画面でもイメージ取れてることがわかった。
docker-compose versionってやったらv2.17.3が戻るから使えるんかもしれん。
データ置き場
データ置き場調べてみた。
C:\Users\nari\AppData\Local\Docker のディレクトリ
2023/05/06 04:59 <DIR> .
2023/05/06 04:52 <DIR> ..
2023/05/06 04:35 0 backend.lock
2023/05/06 04:46 <DIR> engine_tasks
2023/05/06 04:31 881 install-log.txt
2023/05/06 04:35 <DIR> log
2023/05/06 04:38 201,381 log.0.txt
2023/05/06 04:43 339,923 log.1.txt
2023/05/06 04:59 595,139 log.2.txt
2023/05/06 05:06 68,858 log.txt
2023/05/06 04:46 <DIR> tasks
2023/05/06 04:46 <DIR> wsl
6 個のファイル 1,206,182 バイト
6 個のディレクトリ 56,264,491,008 バイトの空き領域
C:\Users\nari\AppData\Local\Docker>
hyper-vで使うvhdxファイルがあるなぁ。150MBぐらいある。
C:\Users\nari\AppData\Local\Docker\wsl\data のディレクトリ
2023/05/06 04:46 <DIR> .
2023/05/06 04:46 <DIR> ..
2023/05/06 05:01 1,522,532,352 ext4.vhdx
1 個のファイル 1,522,532,352 バイト
2 個のディレクトリ 56,264,269,824 バイトの空き領域
C:\Users\nari\AppData\Local\Docker\wsl\data>
windowsのdocker desktopは有料になってた
んんん？
個人利用じゃなかったら有料？
まぁ練習の間はええけど、業務では使えんな。
練習やめとこ。
大昔にローカル環境でkubenetes扱おうとしてrancherって仕組みを考えてたんやけど、そのときはLAN環境がうまくいかず諦めたことがあった。
rancherって名前が入ったデスクトップ環境が今はあるらしいから次にやってみる。
win11 + Rancher desktop
docker desktop入れちゃったので、インストール前の状態にvmwareの仮想マシンを巻き戻した。
練習できるからvm環境は手放せない。
rancher desktop紹介されてる人がいた。
作者さんありがとう。
本家のインストール方法見たらwin/mac/linuxとも行けるみたい。
4コアのCPUと8GBメモリが必要ってさ。
インストール
githubに1.8.1がlatestってあったので700MB弱をダウンロードして入れてみた。
docker desktopと同じでインストールはOS再起動必要。wslを有効にしてるっぽい。
デスクトップのアイコンをクリックすると、しばらく何か動いてた。
コンテナ動くか確認
コマンドライン見るとdocker/docker-composeが使えそうな上にkubectlが使える。
gkeのコマンドライン練習できるかも。
hello-worldもやってみたらできた。
イメージも取れてる。hello-worldのイメージが入ってきてる。
ubuntu動くかやってみる。
jammy jellyfishのコマンドライン使えてええ感じ。
業務ではrancher使えばよさそう。
リソースの消費具合
vmにはメモリ12GBつけてる。
ubuntuのコンテナ動かして何が一番メモリ食うのか見てみると、VmmemWSLってプロセスが3GBぐらい使ってた。
コンテナでtopしてみると、6GBぐらいメモリ認識してるみたい。
どっかで調整できるんかな。
windowsでdocker compose
もうちょっと突っ込んでやってみる。
自前のpythonアプリがubuntuのvmの中でdockerコンテナとして動いてる。
これをwindows11+rancherの環境で使えるかやってみる。
django/nginx-https/mariadbを普段から動かしてるから練習にはちょうどええ。
準備
mariadbは前に10.5.7から10.11.2にバージョンあげた。
djangoはwebサービス、nginx-httpsはdjangoをssl提供してくれる。
この３つをrancher環境で動かす。
docker-compose使ってビルドして実行するのは割とスンナリ動いた。
永続化領域
フォルダ構成はこんな感じ。
\\永続化領域のためのファイル置き場
└─nariDockerDat
├─sv_mariadb11conf ★mariadbの設定ファイル置き場
│ └─nari
├─sv_mariadb11 ★mariadbのデータ置き場
│ └─data
│ ├─nariDB_1st
│ ├─performance_schema
│ ├─nariDB_Django
│ ├─mysql
│ └─sys
├─sv_django-uwsgi-nginx ★djangoアプリのデータ置き場
│ ├─.VSCodeCounter
│ ├─.git
│ └─app
│ ├─templates
│ │ └─gvisDjango3
│ ├─gvisDjango3
│ │ ├─__pycache__
│ │ └─migrations
│ ├─media
│ ├─gvisWebApp
│ │ ├─views
│ │ ├─templates
│ │ ├─forms
│ │ ├─templatetags
│ │ ├─models
│ │ ├─common
│ │ └─migrations
│ └─website
└─sv_django-ssl_certs ★djangoのhttpをhttpsにしてくれるコンテナのための置き場
├─dynamic-env
├─default_server
└─gvis-windows
└─local
これをdocker-composeに書いておいて使わせる。
普段はgcpとローカルのlinuxホストで使ってるけど、★の箇所を書き換えてやってみた。
version: "3"
services:
sv_mariadb1011:
hostname: svmariadb1011
build:
context: ./nariDockerDat/sv_mariadb11/
dockerfile: sv_mariadb11_Dockerfile
image: mariadb:1011
ports:
- "13306:3306"
env_file:
- ./nariDockerDat/sv_mariadb11/env_sv_mariadb11.txt
volumes:
- ./nariDockerDat/sv_mariadb11/data:/var/lib/mysql
- ./nariDockerDat/sv_mariadb11conf:/etc/mysql/conf.d
sv_https-portal:
image: steveltn/https-portal:1
ports:
- "30080:80"
- "30443:443"
environment:
DOMAINS: 'gvis-windows -> http://svdjango:8080' ★ホスト名をgvis-windowsって変えた
STAGE: 'local' # or 'production'
volumes:
- ./nariDockerDat/sv_django-ssl_certs:/var/lib/https-portal
sv_django:
image: sv_django:4
build: ./nariDockerDat/sv_django-uwsgi-nginx
hostname: svdjango
volumes:
- ./nariDockerDat/sv_django-uwsgi-nginx/app:/code/app
ports:
- "38080:8080"
mariadb
やってみて１つ困った点を挙げると、永続化領域をwindowsのファイルシステムに置いたとき、mariadbちゃんと動かんことがあった。
なんとなく思い出した。
docker使うときに気をつけるのはファイルシステムで、ファイルの読み書き権限。
rancherのubuntuと親ホストのwindowsじゃファイルシステムにext4とntfsの違いがある。
理由はわからんけど、ntfsの領域をubuntuに使わせてlsで確認するとファイル権限がおかしくなってまうとか昔あった。
データ置き場をファイル共有にできるんかなぁって昔試してうまくいかんかったときやったかも。
今はできるんかな。
普段はlinuxのファイルシステムにssdのディスクをマウントして使ってるからもうやらんけど。
それを思い出したから、ubuntuの領域にファイルを置けないか探した。
wslって共有があって/homeとかにデータ置くのに使えるみたい。
windows側からpowershellで見るとModeがd-----ってわけわかめになってる。
PS C:\Users\nari> cd \\wsl.localhost\Ubuntu-22.04\home\nari\rancher-workspace
PS Microsoft.PowerShell.Core\FileSystem::\\wsl.localhost\Ubuntu-22.04\home\nari\rancher-workspace> dir
ディレクトリ: \\wsl.localhost\Ubuntu-22.04\home\nari\rancher-workspace
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 2023/05/11 6:18 extract
d----- 2023/05/12 6:54 nariDockerDat
------ 2023/05/12 6:36 1963 docker-compose.yml
PS Microsoft.PowerShell.Core\FileSystem::\\wsl.localhost\Ubuntu-22.04\home\nari\rancher-workspace>
これをubuntuの中で見たらちゃんとdrwxr-xr-xとかアクセス権見えてる。
nari@gvis-windows:~/rancher-workspace$ uname -a Linux gvis-windows 5.15.90.1-microsoft-standard-WSL2 #1 SMP Fri Jan 27 02:56:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux nari@gvis-windows:~/rancher-workspace$ cat /etc/os-release PRETTY_NAME="Ubuntu 22.04.2 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04.2 LTS (Jammy Jellyfish)" VERSION_CODENAME=jammy ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/" SUPPORT_URL="https://help.ubuntu.com/" BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" UBUNTU_CODENAME=jammy nari@gvis-windows:~/rancher-workspace$ ll total 20 drwxr-xr-x 4 nari nari 4096 May 12 07:51 ./ drwxr-x--- 12 nari nari 4096 May 13 09:02 ../ -rw-r--r-- 1 nari nari 1963 May 12 06:36 docker-compose.yml drwxr-xr-x 3 nari nari 4096 May 11 06:18 extract/ drwxr-xr-x 7 nari nari 4096 May 12 06:54 nariDockerDat/ nari@gvis-windows:~/rancher-workspace$
おお、いけてる。
んじゃ、mysqlの永続化領域をubuntuから見ると、999って所有者で見えるはず。999ってのはコンテナの中からみたときのmysqlっていうユーザのuid。
nari@gvis-windows:~/rancher-workspace/nariDockerDat/sv_mariadb11/data$ ll total 1208472 drwxr-xr-x 7 999 999 4096 May 14 04:52 ./ drwxr-xr-x 3 nari nari 4096 May 11 06:23 ../ -rw-r--r-- 1 999 999 16850944 May 12 06:56 aria_log.00000001 -rw-r--r-- 1 999 999 52 May 12 06:56 aria_log_control -rw-rw---- 1 999 999 9 May 14 04:52 ddl_recovery-backup.log -rw-rw---- 1 999 999 9 May 14 04:52 ddl_recovery.log -rw-rw---- 1 999 999 22454 May 12 06:56 ib_buffer_pool -rw-rw---- 1 999 999 134217728 May 14 04:52 ib_logfile0 -rw-r--r-- 1 999 999 1073741824 May 12 06:56 ibdata1 -rw-rw---- 1 999 999 12582912 May 14 04:52 ibtmp1 -rw-r--r-- 1 999 999 0 Mar 13 07:03 multi-master.info drwxr-xr-x 2 999 999 4096 May 11 06:24 mysql/ -rw-r--r-- 1 999 999 15 Mar 13 07:03 mysql_upgrade_info drwxr-xr-x 2 999 999 4096 May 11 06:24 nariDB_1st/ drwxr-xr-x 2 999 999 4096 May 11 06:24 nariDB_Django/ drwxr-xr-x 2 999 999 4096 May 11 06:24 performance_schema/ drwxr-xr-x 2 999 999 12288 May 11 06:24 sys/ nari@gvis-windows:~/rancher-workspace/nariDockerDat/sv_mariadb11/data$
同じ場所をコンテナから見たとき。
docker-compose.ymlに書いた/var/lib/mysqlのフォルダをllしてみるといけてますな。
nari@gvis-windows:~/rancher-workspace$ docker ps | grep maria 43d754a24288 mariadb:1011 "docker-entrypoint.s…" 2 days ago Up 51 minutes 0.0.0.0:13306->3306/tcp, :::13306->3306/tcp rancher-workspace-sv_mariadb1011-1 nari@gvis-windows:~/rancher-workspace$ docker exec -it rancher-workspace-sv_mariadb1011-1 bash root@svmariadb1011:/# ll /var/lib/mysql/ total 1208476 drwxr-xr-x 7 mysql mysql 4096 May 14 04:52 ./ drwxr-xr-x 1 root root 4096 May 10 07:47 ../ -rw-r--r-- 1 mysql mysql 16850944 May 12 06:56 aria_log.00000001 -rw-r--r-- 1 mysql mysql 52 May 12 06:56 aria_log_control -rw-rw---- 1 mysql mysql 9 May 14 04:52 ddl_recovery-backup.log -rw-rw---- 1 mysql mysql 9 May 14 04:52 ddl_recovery.log -rw-rw---- 1 mysql mysql 22454 May 12 06:56 ib_buffer_pool -rw-rw---- 1 mysql mysql 134217728 May 14 04:52 ib_logfile0 -rw-r--r-- 1 mysql mysql 1073741824 May 12 06:56 ibdata1 -rw-rw---- 1 mysql mysql 12582912 May 14 04:52 ibtmp1 -rw-r--r-- 1 mysql mysql 0 Mar 13 07:03 multi-master.info drwxr-xr-x 2 mysql mysql 4096 May 11 06:24 mysql/ -rw-r--r-- 1 mysql mysql 15 Mar 13 07:03 mysql_upgrade_info drwxr-xr-x 2 mysql mysql 4096 May 11 06:24 nariDB_1st/ drwxr-xr-x 2 mysql mysql 4096 May 11 06:24 nariDB_Django/ drwxr-xr-x 2 mysql mysql 4096 May 11 06:24 performance_schema/ drwxr-xr-x 2 mysql mysql 12288 May 11 06:24 sys/ root@svmariadb1011:/#
ついでにバージョン確認もOK。
root@svmariadb1011:/# mysql -unari -p Enter password: Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 6 Server version: 10.11.2-MariaDB-1:10.11.2+maria~ubu2204-log mariadb.org binary distribution Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MariaDB [(none)]> select version() ; +---------------------------------------------+ | version() | +---------------------------------------------+ | 10.11.2-MariaDB-1:10.11.2+maria~ubu2204-log | +---------------------------------------------+ 1 row in set (0.004 sec) MariaDB [(none)]>
nginx-https
永続化領域のフォルダの中をいったん削除し、用意したdocker-compose.ymlの中をDOMAINS: 'gvis-windows -> http://svdjango:8080'ってwindowsホストからdjangoコンテナのホストになりかわる設定を入れてビルドするだけ。
django
django特有の変更。
ソースの中にsettings.pyってのがあって、ALLOWED_HOSTS = [GV_CONST_HOST]って書いてるところがある。
許可ホストなので、GV_CONST_HOSTの定義を書き換えた。
データベース接続設定はそのままでいけた。
# ローカルデータベース
GV_CONST_HOST = 'gvis-windows'
GV_CONST_HOST_LCL_HTTP = "http://" + GV_CONST_HOST
GV_CONST_HOST_LCL_HTTPS = "https://" + GV_CONST_HOST
GV_CONST_DOCKER_HTTPS_PORT = "30443"
GV_CONST_DOCKER_HTTP_PORT = "38080"
GV_CONST_DBENVNAME = "nariDB_1st"
GV_CONST_DBUSERNAME = "nari"
GV_CONST_DBPASSWD = "xxxxxxxx"
GV_CONST_DBPORT = "13306"
#######################################################################
ALLOWED_HOSTS = [GV_CONST_HOST]
# Database
# https://docs.djangoproject.com/en/3.1/ref/settings/#databases
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.mysql',
'NAME': GV_CONST_DBENVNAME, # 実際に作ってあるDB名を設定する
'USER': GV_CONST_DBUSERNAME,
'PASSWORD': GV_CONST_DBPASSWD,
'HOST': GV_CONST_HOST,
'PORT': GV_CONST_DBPORT,
'OPTIONS': {
'init_command': "SET sql_mode='STRICT_TRANS_TABLES'",
},
}
}
はい、docker-comopseで一括起動してブラウザで見たら完成。
rancher+wsl2環境の中でdjangoのバージョンやらデータベース情報やら取れてるし、pythonのmatplotlibでの円グラフも表示されて、データ集計した結果も見えてた。
その他
やってみてできるかなって試したこと。
docker statsが使えん。
何かやり方悪いんかなぁ。
wslの共有をwindows側のwinmergeとかで開ける。
変更点を機械的に確認したいときは助かる。
vscodeでコンテナにつないで使う開発環境
remote developmentっていうプラグインがあって、これを使うとコンテナのインタプリタで開発ができそう。
解説してる方がおられた。
作者さんありがとう。
雰囲気わかったのでリモートエクスプローラからwindowsローカルのrancher+wsl2で動いてるubuntu22のコンテナにつないでみた。
remote developmentのアイコンが左下のほうにあるので押してみるとファイラみたいなのが開く。
やってみると、コンテナのソースが見える。
djangoでもブレークポイント設定してデバッグできるんかな。
インポートしてる箇所にオレンジ色の波線いっぱい見える。
pythonのインタプリタ解釈できてへんのやろか。
デバッグでdjango選べそうやな。
デバッグでvscodeのやり方探したら、あるのはあるけどdjangoないって怒られた。
解説されている方がおられる。
作者さんありがとう。
よく考えたらコンテナのデバッグとはちょっと違うのかも。
デバッグ手軽にできるかと思ったけど、そうやなさそう。
こっから根が深そうやからいったんここまで。
やっぱwindowsのdocker desktopきらい
5年以上前、railsの開発業務でwindowsのdocker desktop使ってる人がいて、ロクに使いこなせないものをこっちに引きつごうとしてる人がいた。
「動かんものを引き継がれても困るなぁ、この人何がしたいんやろなぁ、なんでvirtualbox入れてlinuxでちゃんと環境作らへんのやろ」ってムカついた。
メモリは食うけど、virtualbox使ったから一発で動いた。
だからdocker desktopあんまりいい印象ない。
rancherになっても同じかなぁ。
