こんなんなって、
$ docker compose ps Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
このQiitaの記事で復活した。
minioをWindowsのDドライブに入れる
CドライブのWSLのストレージがヤバくなってきたので、Dドライブにストレージ作ることにした。Dドライブに入れるのでWindowsに入れる。
Windowsへのminoのインストール。
Windowsでminioのadminのユーザ名とかパスワードをかえる。今の環境変数一覧は、
Get-ChildItem Env:
で調べられる。
minioの環境変数は、'MINIO_ROOT_USER'と'MINIO_ROOT_PASSWORD'で、これを変える。変更の仕方は、
$Env:MINIO_ROOT_USER="root-user-name" $Env:MINIO_ROOT_PASSWORD="root-password"
みたいにしてやる。
参考リンク。
ただ、これでWSLからminioの中を見ようとして、AWS CLIでlsすると怒られる。
$ aws --endpoint-url http://192.168.1.1:9090:9000 s3 ls Invalid region: region was not a valid DNS name.
久しぶりにminikubeつかう
インストールメモ。
WSL2でUSBカメラ
まさかのWSL2ではUSBカメラ使えないので、WSLのカーネルいじるらしい。
B-ingちゃんに聞いたらうまいこといった。
手順だけ書いとくとpower shellをAdminで起動して、USBカメラをアタッチするとWSLから見れるようになったみたい。
PS C:\WINDOWS\system32> usbipd list Connected: BUSID VID:PID DEVICE STATE 1-10 056e:7019 ELECOM 1MP Webcam, Webcam internal mic Shared Persisted: GUID DEVICE PS C:\WINDOWS\system32> usbipd wsl detach --busid 1-10
WSLでDISPLAYにwindowsのipconfigで調べたIPとDISPLAYのポート番号を指定する。
WSLの/dev/video0とか/dev/video1とかにUSBカメラがマウントされるので、そいつのパミッションを変えて、v412-ctlでカメラをWSLが認識してるか調べる。
VcXSRVは起動してるものとする。
$ export DISPLAY=1292.168.1.194:0
$ sudo chmod 777 /dev/video*
$ $ sudo v4l2-ctl --list-devices
ELECOM 1MP Webcam: ELECOM 1MP W (usb-vhci_hcd.0-1):
/dev/video0
/dev/video1
/dev/media0guvcviewを開くとカメラの映像をWSLから見れる。
$ guvcview
# 追記
WSL2でコンテナでやるとうまく認識しなかったので、これをやった。
WSL2でUSBカメラ
まさかのWSL2ではUSBカメラ使えないので、WSLのカーネルいじるらしい。
HPのOMENにUbuntu22を入れてそれにNVIDIAのドライバ入れた
このパソコンを買ったので、Ubuntu22を入れて、ディープでポンできるようにしたかった。
多分このページは数カ月後には消えるので、PCのスペックはこんな感じ。
- PC: OMEN by HP 16-k0058TX
- CPU: インテル Core i5-12500H
- CPU: NVIDIA GeForce RTX 3060 Laptop
- ストレージとメモリはそれなり。多分あまり今の時点では問題にならない。
- WiFi: Alder Lake-P PCH CNVi というやつ。これが後々色々な問題を引き起こす。
まずは何も考えずにUSBメモリにUbuntu22.04LTSのインストールイメージを入れて、PCにブッさしてインストールする。
そうすると有線LANにはつながるが、無線に繋がらない。ググると、Ubuntu22.04LTSのカーネルがあってないので、アップデートするといい感じになったと書いてあった。
$ sudo apt-cache search linux-image-
ってやると色んなカーネルがびゃーって出てくるが、今つかってるのが5.15なので、それの一つ上の5.17にしようとする。6系統はなんかまだ人柱感が強いので、そこまでやる勇気がない。
$ sudo apt install linux-image-5.17.0-1026-oem
ってやるとインストールできる。
再起動するとWiFiにつながるようになる。
NVIDIAのドライバを入れようとするが、大体500番台のならなんとかなる気がするので、適当なのをaptでインストールするがnvidia-smiやってもそんなもんはねえといわれるので、本家からrunのインストーラを引っ張ってくる。そしてこいつがDownloadに入ってるので、これを動かす。
$ cd Downloads $ sudo chmod 755 NVIDIA-Linux-x86_64-510.108.03.run $ sudo sh NVIDIA-Linux-x86_64-510.108.03.run
そうするとインストーラが立ち上がって、OKとかNOを適当に押してるといい感じになるのだが、お前の使ってるカーネルのソースの場所が分からんと言われる。どうも純正のUbuntu22.04LTSの使ってるカーネルと違うの使ってるから怒られてるみたい。
ググると、カーネルのソースのヘッダインストールして、NVIDIAのインストーラにヘッダの場所教えてあげればいいんやでって書いてあるからそれっぽくやる。
forums.developer.nvidia.com
www.tecmint.com
まず自分の使ってるカーネルのヘッダをaptで入れる。下のコマンドは uname -rで返ってきたLinuxのカーネルのバージョンのヘッダをaptでインストールしている。
$ sudo apt install linux-headers-$(uname -r)
一応中身があるか確認する。
$ ls /usr/src/linux-headers-5.17.0-1026-oem
で中身が入ってるのが分かる。
次にこのヘッダの入ってるパスをNVIDIAのインストーラに食わせながらインストールする。
$ sudo sh NVIDIA-Linux-x86_64-510.108.03.run --kernel-source-path /usr/src/linux-headers-5.17.0-1026-oem
適当にOKとかNGとかやってるとインストールができてた。nvidia-smiするとちゃんと動く。
嬉しい。
WSL2+Minikube1.27.1でImagePullBackoffになるやつ
最近自宅のパソコンの電源を落とすことがあり、そのときにminikubeが止まって、再起動してpodを立ち上げようとしたらImagePullBackOffが出た。どうやらコンテナイメージを取ってくるののタイムアウトに引っかかってたらしい。Torchが入ってるからそりゃデカいわなと。
kubectl describe podで調べたら、
$ kubectl get po -n cnn
NAME READY STATUS RESTARTS AGE
signma-chan-cnn-hlpdp 0/1 ImagePullBackOff 0 12m
$ kubectl describe pod signma-chan-cnn-hlpdp -n cnn
Name: signma-chan-cnn-hlpdp
Namespace: cnn
Priority: 0
Service Account: default
Node: minikube/192.168.49.2
Start Time: Sun, 01 Jan 2023 01:15:13 +0900
Labels: controller-uid=091a21b9-f414-4e7e-83de-c5ba6e857228
job-name=signma-chan-cnn
Annotations: <none>
Status: Pending
(中略)
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 14m default-scheduler Successfully assigned cnn/signma-chan-cnn-hlpdp to minikube
Normal Pulling 6m39s (x4 over 14m) kubelet Pulling image "nsakairi/sigma-chan-cnn@sha256:7d1879427b6fc4e438e1680069f327a14a5a664ca4f411fd760bd40d8b12773e"
Warning Failed 4m40s (x4 over 12m) kubelet Failed to pull image "nsakairi/sigma-chan-cnn@sha256:7d1879427b6fc4e438e1680069f327a14a5a664ca4f411fd760bd40d8b12773e": rpc error: code = Unknown desc = context deadline exceeded
Warning Failed 4m40s (x4 over 12m) kubelet Error: ErrImagePull
Warning Failed 4m10s (x7 over 12m) kubelet Error: ImagePullBackOff
Normal BackOff 3m56s (x8 over 12m) kubelet Back-off pulling image "nsakairi/sigma-chan-cnn@sha256:7d1879427b6fc4e438e1680069f327a14a5a664ca4f411fd760bd40d8b12773e"
$ kubectl delete -f manifest/run_single_job.yaml -n cnnこんなんでてきて、つまり、コンテナを引っ張ってくるののタイムアウトに引っかかってるらしかった。
これまでも何回かImagePullBackOffが出ることがあったが、数時間ほっとけば勝手にpodが立ち上がってたが、今回はそうはいかなくて、色々調べてくとminikubeが新しくなって、k8sもアップデートされてこれまで通りに行かなくなった模様。色々調べたけど忘れたが、ググれば色々出てくるからいいことにする。
ちなみにコンテナイメージ自体はdockerhubにあげてて、普通にdocker pullできる状態。
Google先生にお伺いを立てたところ、こういうgithubのissueが出てきて、
image-pull-progress-deadlineというオプションをつけたらいいんやでってサジェストされたので、kubeletでオプション指定してminikubeを立ち上げなおそうとしたら、
$ minikube start --extra-config=kubelet.image-pull-progress-deadline=15m
😄 minikube v1.27.1 on Ubuntu 20.04 (amd64)
✨ Automatically selected the docker driver
📌 Using Docker driver with root privileges
👍 Starting control plane node minikube in cluster minikube
🚜 Pulling base image ...
🔥 Creating docker container (CPUs=2, Memory=3400MB) ...
🐳 Preparing Kubernetes v1.25.2 on Docker 20.10.18 ...
▪ kubelet.image-pull-progress-deadline=15m
▪ Generating certificates and keys ...
▪ Booting up control plane ...
💢 initialization failed, will try again: wait: /bin/bash -c "sudo env PATH="/var/lib/minikube/binaries/v1.25.2:$PATH" kubeadm init --config /var/tmp/minikube/kubeadm.yaml --ignore-preflight-errors=DirAvailable--etc-kubernetes-manifests,DirAvailable--var-lib-minikube,DirAvailable--var-lib-minikube-etcd,FileAvailable--etc-kubernetes-manifests-kube-scheduler.yaml,FileAvailable--etc-kubernetes-manifests-kube-apiserver.yaml,FileAvailable--etc-kubernetes-manifests-kube-controller-manager.yaml,FileAvailable--etc-kubernetes-manifests-etcd.yaml,Port-10250,Swap,Mem,SystemVerification,FileContent--proc-sys-net-bridge-bridge-nf-call-iptables": Process exited with status 1といわれて、そんなオプションは知らんと言われたので、k8sのkubeletがサポートしてるやつを調べた。
Kubeletのオプションを調べるとどうやらimage-pull-progress-deadlinehは見つからず、ググるとimage-pull-progress-deadlineはもう新しいk8sでは使えないんだよ、これからはお前らdockerdとかcontenerdを使えよといってるらしき英語の文章が目に入った。
K8sがDockerのサポートをやめてContenerdに移行していくという噂は聞いており、マジかって思ってたらNTTの方がとてもよいまとめを作ってくださっていた。
一瞬contenerdに移行しようかと考えがよぎったが、よくよく見るとsystemctlとかsystemdを使わないといけないのだけれど、色々な理由でWSLでそれらを使うと僕の環境ではあまり嬉しくないので、そのやり方はちょっと避けたくて、再度minikubeのissueを見ると、minikubeでコンテナランタイムをcontainerdにするとcontainerd使えるらしいことが分かったので、それでなんとかしてみようとした。
$ minikube start --container-runtime=containerd
😄 minikube v1.27.1 on Ubuntu 20.04 (amd64)
✨ Automatically selected the docker driver
📌 Using Docker driver with root privileges
👍 Starting control plane node minikube in cluster minikube
🚜 Pulling base image ...
🔥 Creating docker container (CPUs=2, Memory=3400MB) ...
📦 Preparing Kubernetes v1.25.2 on containerd 1.6.8 ...
▪ Generating certificates and keys ...
▪ Booting up control plane ...
▪ Configuring RBAC rules ...
🔗 Configuring CNI (Container Networking Interface) ...
🔎 Verifying Kubernetes components...
▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
🌟 Enabled addons: storage-provisioner, default-storageclass
🏄 Done! kubectl is now configured to use "minikube" cluster and "default" namespace by defaultMinikubeは動いたっぽいので、ジョブを流す。が、またImagePullBackOffが出るが、これはcontainerdがDockerHubのcredentialがねえって怒ってるみたいだった。
DockerHubはパブリックで使ってるがなんか認証しないといけないらしかった。
$ kubectl get po -n sigma-chan-cnn
]NAME READY STATUS RESTARTS AGE
signma-chan-cnn-6gtjz 0/1 ImagePullBackOff 0 10m
$ kubectl describe pod signma-chan-cnn-6gtjz -n sigma-chan-cnn
Name: signma-chan-cnn-6gtjz
Namespace: sigma-chan-cnn
Priority: 0
Service Account: default
Node: minikube/192.168.49.2
Start Time: Fri, 06 Jan 2023 15:12:15 +0900
Labels: controller-uid=e8c52db2-fdfe-4251-aec6-ea8f93ef000c
job-name=signma-chan-cnn
(中略)
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 10m default-scheduler Successfully assigned sigma-chan-cnn/signma-chan-cnn-6gtjz to minikube
Warning Failed 3m35s kubelet Failed to pull image "nsakairi/sigma-chan-cnn@sha256:7d1879427b6fc4e438e1680069f327a14a5a664ca4f411fd760bd40d8b12773e": rpc error: code = Unknown desc = failed to pull and unpack image "docker.io/nsakairi/sigma-chan-cnn@sha256:7d1879427b6fc4e438e1680069f327a14a5a664ca4f411fd760bd40d8b12773e": failed to copy: httpReadSeeker: failed open: server message: invalid_token: authorization failed
Warning Failed 3m35s kubelet Error: ErrImagePull
Normal BackOff 3m34s kubelet Back-off pulling image "nsakairi/sigma-chan-cnn@sha256:7d1879427b6fc4e438e1680069f327a14a5a664ca4f411fd760bd40d8b12773e"
Warning Failed 3m34s kubelet Error: ImagePullBackOff
Normal Pulling 3m23s (x2 over 10m) kubelet Pulling image "nsakairi/sigma-chan-cnn@sha256:7d1879427b6fc4e438e1680069f327a14a5a664ca4f411fd760bd40d8b12773e"一応手元のターミナルではdocker loginしてるけど、minikubeにsecret食わせないといけないみたいだった。
discuss.kubernetes.io
kubernetes.io
大体上のページに書いてある通りにやるとsecret作れた。
DockerHub使ってるときはこんな感じ。
$ kubectl create secret docker-registry regcred --docker-server=https://index.docker.io/v1/ --docker-username=<docker-hub-username> --docker-password=<docker-hub-password> --docker-email=<docker-hub-e-mail-address> secret/regcred created $ kubectl get secret NAME TYPE DATA AGE regcred kubernetes.io/dockerconfigjson 1 11s <|| うまくsecret作れてるっぽかった。 そしてまたminikubeにジョブを投げてみると、 >|| $ kubectl get po -n sigma-chan-cnn NAME READY STATUS RESTARTS AGE signma-chan-cnn-z7xh4 1/1 Running 0 1s
無事podが動いてるのが分かった。偉い解決に時間がかかってしまった。k8sはやっぱ色々あって大変だな。
# 追記
yamlにsecret何使ってるか足さないといけないっぽかったので、これ見てやってみた。
