こんなんなって、
$ docker compose ps Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
このQiitaの記事で復活した。
こんなんなって、
$ docker compose ps Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
このQiitaの記事で復活した。
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.
インストールメモ。
まさかの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/media0
guvcviewを開くとカメラの映像をWSLから見れる。
$ guvcview
# 追記
WSL2でコンテナでやるとうまく認識しなかったので、これをやった。
まさかのWSL2ではUSBカメラ使えないので、WSLのカーネルいじるらしい。
このパソコンを買ったので、Ubuntu22を入れて、ディープでポンできるようにしたかった。
多分このページは数カ月後には消えるので、PCのスペックはこんな感じ。
まずは何も考えずに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するとちゃんと動く。
嬉しい。
最近自宅のパソコンの電源を落とすことがあり、そのときに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 default
Minikubeは動いたっぽいので、ジョブを流す。が、また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何使ってるか足さないといけないっぽかったので、これ見てやってみた。