母艦として利用してるローカルlinuxも、xrdpコンテナもベースosをjammyからnumbatへ切り替えた。 ローカルkubernetesもminikubeからmicrok8sに切り替えて、利用イメージをnumbatへ切り替えた。 google cloudの中のベースosもxrdpも同じくnumbatへ切り替えた。 面倒やし書かへんけど、業務利用してるawsの中のamazonlinux2023で動かしてるコンテナもnumbatのxrdpに変えてみた。 今月けっこうがんばったな。 もしかしてと思ってdockerhub見たら、mariadbもベースosがnumbatのが出てるやん。 ただ上がるだけやったら放置やけど、LTSが出とる。 コンテナのバージョンアップしたほうがええな。 検証利用やし、メモなしで業務利用のawsの中のmariadbをnumbatにバージョン上げてダンプファイル突っ込んだら、あっさり動いた。 今回は母艦の中のdockerで動いてるmariadbをnumbatに上げる。 mariadbのダンプファイルはテキストになってて、createしたりinsertしたりするからデータの保全はほぼ常にできてる。 バージョンの特定 世間一般へのアナウンスは11.4がLTSってなってた。 MariaDB | endoflife.date endoflife.date dockerhubにタグがあって11.4がある。 hub.docker.com 11.4-nobleは11.4.2ってのと同じdigestになってるから、11.4.2を使えばええっぽい。 11.4.2より新しい11.5ってのもあるけど、LTSやないみたいやから要らん。 ubiってもしや？ なんと、タグ名にubiってのがついてるのがある。 もしかしてUniversalBaseImageの略？　redhatのこととちゃうんか？ ググったら出てきた。 UBI based Docker Official Images - MariaDB.org mariadb.org 「エンタープライズ向けユーザにお知らせでーす」って赤い帽子かぶってるやん。 いろんなプラットフォームで動いてくれるのはええことかなって思う。 サポートの都合でredhat一択っていうユーザ企業もあるやろし。 redhatは母艦にあるubuntuに比べたら、使ってるカーネルが古い傾向があったはず。 dockerは親ホストとコンテナがカーネル共有するから、わけわかめな誤動作出たらイヤやしubiは使わん。 ibmの息がかかったプロダクトはredhat/centosみたいな末路たどるんとちゃうかってイヤな予感。 mysqlがubi使ってもええけど、mariadb大丈夫か？ もしDBMSを切り替えるとしたら、postgresqlでもええけど、あのデータベースは運用途中で勝手に最適化動いて遅くなるのがイマイチ。 何年か前に業務で、javaのガベージコレクションがまとめて動いたときみたいな、悲惨な応答速度になることが夜間バッチであったな。 別のデータベースの可能性を探しながら様子見るしかないな。 どのへんが変わったか データベースそのものを変えるときはsql発行で使えんようになったものとか、使ってる処理に制限が出て影響出えへんかを気にする。 シンプルなsqlだけ使ってたら気にせずでええんやけど、ストアドとか使ってたらdbmsの変更すらできん。 世の中にはこのせいでoracleから抜け出せへんユーザ企業あるやろしな。 同じデータベースで、しかもバージョン変更だけやし、djangoから利用するのが前提やから、それほど気にせずアプリケーションテストでほぼ大丈夫なはずやけど、リリースノートは軽く読む。 MariaDB 11.4.2 Release Notes | MariaDB Documentation mariadb.com けっこういっぱい書いてある。 LTSやししゃぁないんかもしれん。 mysqldumpはmariadb-dumpに変わったんかな。 データの流し込みのとき気をつけなアカンかもな。 真面目に英語読んだのは５行。あとは読む気が萎えた・・・。 バグ対処とかいろいろあるんやろな。 型とかsqlは致命的な変更なさそうに思うけど大丈夫なんかなぁ。 事実を列挙するだけやのうて、使う側目線でもうちょっと読みやすかったらええのに。 どう保全するか 扱ってるデータベースには、djangoアプリからお金の情報/時間の情報/活動記録として数値とテキスト、名刺とか受け取り資料のpdf/jpegがblob列に入ってる。 帳簿は7年分を別途でpdf保管してるから、数字とかテキストを目検で追いかけたり、登録可否を確認する。 古いほうのバージョンのdbmsからのダンプを登録できる(インポート) ７年分の合計金額が１円単位であう(sql集計の確認) djangoのmatplotlibで円グラフ表示させてるパーセンテージが小数点以下でズレてへん(djangoでの集計) 月次の活動記録のテキストとpdf/jpegを任意で拾って化けてたり読み取り不良になってへん(blob列のデコード) mariadbに設定してるmax_allowed_packetを超えへんサイズのpdfがblob列にinsertできる(blob列へのbase64保管) 極端に挙動が遅くなってたりせんか(django画面での応答速度) 意識しながらdjangoの画面を開いて確認やな。 ...

ubuntu24使いはじめのとき、リモートデスクトップ接続で内部エラーってなってた。 dockerコンテナでxrdpコンテナはホイホイ動いたけど、母艦にrdpできてへんかったなって思い出した。 今回はwindows/macから接続できるようにしてみる。 接続結果 windowsからやとこうなる。 ただし、警告が出る。 これを解決せんとmacosからはつなげられへん。 解決させて、macosから接続するとこうなる。 ほな、解決の経緯こっから下な。 アプローチ ubuntu24へのリモートデスクトップを真面目にやると、いくつもヒットする。 作者さんありがとう。 How to Install Remote Desktop (Xrdp) on Ubuntu 24.04 - Linux Genie linuxgenie.net Ubuntu 24.04 LTS : Xrdp サーバーの設定 : Server World www.server-world.info 自分はdockerコンテナで使ってるxfce使いたいなって思ったから、１つ目のリンクでやりかけた。 1 2 # sudo apt install xfce4 xfce4-goodies # sudo apt install xrdp せやけど、途中でsystemctlでステータス確認したらエラーが出てきた。 1 2 3 4 7月 21 03:05:31 nafslinux-ubu24 xrdp[27860]: [ERROR] g_tcp_bind(7, 3389) failed bind IPv6 (errno=98) and IPv4 (errno=22). 7月 21 03:05:31 nafslinux-ubu24 xrdp[27860]: [ERROR] trans_listen_address failed 7月 21 03:05:31 nafslinux-ubu24 xrdp[27860]: [CORE ] Failed to start xrdp daemon, possibly address already in use. 7月 21 03:05:31 nafslinux-ubu24 systemd[1]: xrdp.service: Control process exited, code=exited, status=1/FAILURE なんやねん、already in useってあるやんけ。 先にどっかのプロセスが使ってるってどういうことやねん。 ...

2023年はGKEから派生して、ローカルmacの中で minikube使い始めた。 先月までのminikubeのクラスタは、hyperkitの中で独自のlinuxが動いて、dockerコンテナとしてkubernetesのコントロールプレーンが動いてた。 2024年6月ぐらいからhyperkitが非推奨になったので、脱却して qemuを使い始める 。 今年の下期にm4のmacmini仕入れて使いたいから、qemuで練習始めたる。 minikubeのドライバ指定と、qemu2用のサービス指定 最初にminikubeアンインストールしてhyperkitの入ってた領域も潰した。 もう１回minikubeインストールしてqemuを仮想マシン指定して使い始める。 minikubeのサイトに指定の方法が書いてある。 qemu | minikube minikube.sigs.k8s.io 名前はqemuってあるけど、実際はqemu2をドライバに指定する。 前に一回やってみた けど深くは調べずにあきらめた。 nari@gvis-mac script % minikube config set driver qemu2 よー見たら、socket_vmnetってのを使わなアカンらしい。 え、これrootで動かさなあかんのか。 そういえば、ubuntu24をqemuでbridgeネットワーク使って動かすときには、特権いるみたいなこと書いてるところあったっけ。 ログ捨てたけど、これやっとかんとディスクのマウントがうまくいかんかったし、「トンネリングにいるで」ってある。 とりあえずbrewでインストールやっとく。 1 2 brew install socket_vmnet brew tap homebrew/services せっかくスクリプト化してんのにパスワード打たなアカンのかぁ。 この時点でhyperkitのほうがええなぁ。 クラスタ作り替えのスクリプト 普段はクラスタのバージョンあげるためのスクリプトを作って用意してる。 このへん で手動でやってることをまとめた処理。 それを少しいじって、qemuでのクラスタを用意する。 処理の後半でpv/configmap/serviceの定義もやってる。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 ## ------------------------------------------------------------------------- ## Script Name : 300_minikubeClusterRecreate.sh ## Created by : T.Naritomi ## on : 2023.08.26 ## Updated by : 2024.06.23 ## on : ## Parameters : ## Return Code : 0=Normal End ## Comments : change driver hyperkit -> qemu2 ## ------------------------------------------------------------------------- ## ---define---------------------------------------------------------------- EXEC_HOME=/Users/nari/Documents/personal/script # Execute Home directory MINK_HOME=/Users/nari/Documents/personal/minikube # minikube Home directory LOG_FILE=/Users/nari/Documents/personal/log/300_minikube.log # Log file NEWEST_VER=`minikube config defaults kubernetes-version | head -1 | awk '{ print $2}'` GVIS_CPU=4 GVIS_MEM=6000 GVIS_DSK=90GB ⭐️50GBにしてたのを、qcow2でどうなるかやってみたかったから容量増やした GVIS_DRV=qemu2 ⭐️書き換えた ## ---detail---------------------------------------------------------------- echo '---newest version---' echo ${NEWEST_VER} read -p "--- minikube Data save ready ? ---(y/N):" yn case "$yn" in [yY]*) ;; *) echo "abort." ; exit ;; esac read -p "--- minikube Recreate cluster ready ? ---(y/N):" yn case "$yn" in [yY]*) ;; *) echo "abort." ; exit ;; esac echo '---Recreate start---' rm -f ${LOG_FILE} echo ${LOG_FILE} minikube delete --purge --all ⭐️クラスタ完全削除 ## add socket_vmnet because use qemu2 HOMEBREW=$(which brew) && sudo ${HOMEBREW} services restart socket_vmnet　⭐️sudoせなアカン残念な行、再実行することあるからrestart指定 minikube config set cpus ${GVIS_CPU} minikube config set memory ${GVIS_MEM} minikube config set disk-size ${GVIS_DSK} minikube config set driver ${GVIS_DRV} echo -------- `date +%F_%T` -------- >> ${LOG_FILE} minikube config view >> ${LOG_FILE} minikube delete >> ${LOG_FILE} minikube start --kubernetes-version ${NEWEST_VER} \ --driver=${GVIS_DRV} \ --network socket_vmnet >> ${LOG_FILE} ## --mount --mount-string ${MINK_HOME}/:/minikubeMac >> ${LOG_FILE} ⭐️マウントしたらクラスタ落ちることあるからやめとく cat ${LOG_FILE} sleep 20　⭐️kubernetesクラスタが安定するまでちょっと一息、こっから下のapplyしてる箇所で永続化領域作ったり他の定義も作ってもらいましょ kubectl config get-contexts kubectl get pod -n kube-system kubectl apply -f ${MINK_HOME}/gvis-PersistentVol-mariadb1011.yaml kubectl apply -f ${MINK_HOME}/gvis-PersistentVol-mariadb1011conf.yaml kubectl apply -f ${MINK_HOME}/gvis-PersistentVol-sv_django-ssl_certs.yaml kubectl apply -f ${MINK_HOME}/gvis-PersistentVol-sv_django-uwsgi-nginx.yaml kubectl apply -f ${MINK_HOME}/gvis-PersistentVol-ubun.yaml kubectl apply -f ${MINK_HOME}/mariadb11-txt-configmap.yaml kubectl apply -f ${MINK_HOME}/sv-django-service.yaml kubectl apply -f ${MINK_HOME}/sv-https-portal-service.yaml kubectl apply -f ${MINK_HOME}/sv-mariadb1011-service.yaml echo -------- `date +%F_%T` -------- >> ${LOG_FILE} minikube dashboard & sleep 300 ⭐️何度かやって必要って思った ls -lh ~/.minikube/machines/minikube ⭐️目で見て確認 ## minikube cp ${MINK_HOME}/nariDockerDat/gvis-pv-ubun.tar.gz /data/ ⭐️ここでコピー処理するとクラスタ停止してまう exit $? qemuでminikube発進 マシンを作ってる途中のファイルを確認してみる。 ...

brewで定期更新してたら、hyperkitが非推奨って出た。 minikubeで使ってるから次の手考えはじめる。 appleがarmのcpu出しはじめたときから、いつかはこの日が来るかなって思ってた。 hyperkitはintel系のcpuでvm動かすためにあるから、arm載せてるマシンでは動かん。 m4のmacmini出たら買うつもりやから、今年あたりqemuでminikube動かす練習し始める。 どんな感じか試すため、qemuをmacに入れてubuntu動かしてみる。 だいたいの動き方つかんだら、qemuベースのminikubeに踏み込む。 hyperkitとminikubeアンインストール いったんhyperkit外してqemuやってみた。 hyperkitの代わり探せっていうメッセージはこんな感じ。 1 2 3 4 5 6 7 8 9 nari@gvis-mac ~ % brew doctor Please note that these warnings are just used to help the Homebrew maintainers with debugging if you file an issue. If everything you use Homebrew for is working fine: please don't worry or file an issue; just ignore this. Thanks! Warning: Some installed formulae are deprecated or disabled. You should find replacements for the following formulae: hyperkit nari@gvis-mac ~ % hyperkitは1年ほど使ったな。 ...

ローカルlinuxをubuntu24にバージョン上げて様子見しながら、google cloudのも準備。 Google cloudのubuntu ちゃんとubuntu24LTSのイメージもgoogle cloudにあった。 intel系のだけやなくarmもあんねんな。 macosとかwindowsとか出始めは「バグ多いから出始めは使ったらアカン」みたいな人多いけど、ベータ版とか極端な危険の懸念とかないかぎり、必要機能が使えるって判断したらすぐ利用開始に着手するで。 linuxでもwindowsでもOSは新規インストール一択。 パーティション新規作成して入れる。 windows98もwindows11でもアップグレードしてインストールしたらうまくいかんこと多かったな。 今はvmあるんやから、新規でvm作ってデータパーティションだけマウントしたらええ。 新ＯＳを準備 「noble numbat」って名前長い。 端的に「numbat」でええ。 nobleの意味は「高貴で尊い」ってなってて、あんまり好かん。 フクロアリクイの絵柄が王冠みたいになってた壁紙とかイヤやなぁ。 ubuntu22はjelly-fslinuxってつけて作ってた から、24はnumbat-fslinuxってつける。 やることは前と同じ。 google cloudのコンソールで、まずは外部IPと内部IPを準備・特定しとく。 次にネットワーキングにファイアウォールのタグつけて、ネットワークとサブネットワークの設定つけたら鍵ファイル作って設定。 １回作っておさらいしながらやっておいて潰す。 ２回目に点検しながら作ってまう。 teraterm接続できてssh転送が終わってdocker入れる直前まで、E2シリーズのマシンタイプにしとこ。 uid=1000のユーザ名を変更 今更なんやけど、osインストールしたらユーザidが1000としてubuntuって名前のユーザが元からある。 以下、赤い背景がubuntu22(jammy jellyfish)で水色のがubuntu24(noble numbat)。 ローカルlinuxのubuntu24は、centosの頃から使ってるファイル類があるから、uid=1000は自分のユーザでないと困んねん。 特にgoogle cloudでファイル維持してるものをローカルlinuxに持ってきたとき、uidが変わってたらgit管理してるファイルがいっつも全更新みたいな感じになる。 一時的に別ユーザ作っておいて、ubuntuユーザを削除して作り直してく。 ユーザidの操作メモを書いてくれてる人がいた。ロックする方法もあった。 作者さんありがとう。 Linuxコマンド - ユーザ・グループの確認/追加/削除 #ユーザー管理 - Qiita qiita.com Linuxでユーザアカウントを無効化するエトセトラ - astamuse Lab lab.astamuse.co.jp 変更する方法ってのもあるのね。 UID と GID の変更 - プレイヤーズ・ハイ i97506051502.hatenablog.com 作り直した結果はこうなった。 1 2 3 4 naritomitsukasa@gcp-numbat-fslinux:~$ cat /etc/passwd | grep nari naritomitsukasa:x:1101:1101::/home/naritomitsukasa:/bin/bash nari:x:1000:1000::/home/nari:/bin/bash naritomitsukasa@gcp-numbat-fslinux:~$ ログインしといたまま、次に実施するssh鍵作った後で$HOME/.ssh/authorized_keysに最終的に作った鍵ファイルの内容を入れてく。 ...