このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

結局エバーグランデも座礁してしまったな……

#白昼夢の青写真

このアカウントは、notestockで公開設定になっていません。

Cookie2 とは何か | blog.jxck.io
https://blog.jxck.io/entries/2023-08-19/cookie2.html

感染症研究所職員がチフス　菌取り扱い、経路不明（共同通信） - Yahoo!ニュース https://news.yahoo.co.jp/articles/ff06eaf2f9fbf9258361beb887986ed44b8768f3

発症しただけよかったじゃん…… (よくない)

RancherOS は LXC 上で動かすのは非対応か……

よくよく調べてみたら RancherOS 1.x はもう unmaintained (正確には "no longer being actively maintained) らしくて、じゃあ今からは使えないわ……

terraform を勉強すべき時が来たか……

このアカウントは、notestockで公開設定になっていません。

エアコンども、押し付けがましい割に使わないスマ〜ト機能なんかよりも

* 現在時刻
* 室温
* 外気温
* 室内の明るさ

の4つの実数値を入力として目標温度を出力とするような簡単な関数をプログラムさせてくれる程度の機能が欲しい。ｽﾏﾋｮから入力させてくれれば十分だから

入力に日付を追加して出力に動作モード (冷房、暖房、除湿、送風等) を追加するくらいはあってもいいか

十年前の関数電卓ですらその程度のことができるんだから、現代のｽﾏﾋｮアプリとエアコンでできないはずがないんだよな。エンドユーザがとことん舐められて馬鹿にされているだけ

市民に日曜開発者になる覚悟がなくていつでも文句を言うだけのお客様気分だから、スマ〜ト家電もお節介プリセットばかりでユーザに十分なコントロールを与えないバカ家電ばかりになる。
つまりそれが舐められてるということなんだけど

最悪の場合、 ECHONET Lite 対応の家電であれば直に叩いて細かくコントロールするサーバを立てるという手もなくはないが、そこまでしないとスマ〜トな動作もさせられないならスマ〜ト家電の看板下ろしてくれという

まあご家庭の家電の制御をどうにかするなんて高尚な望みを垂れる前に、まずは職場でｴｸｾﾙマクロを見ると文句言うみたいな石器時代メンタルの人々が撲滅されるまで待たないといけないんですかね。世知辛い話だ

https://mastodon.cardina1.red/@lo48576/110918732866431629

関数電卓を例に出さずとも、現代の小学生なら Scratch とかのビジュアルプログラミングには慣れ親しんでいるだろうし、「エアコンの目標温度制御くらい、環境さえあれば小学生でもできるぞ」くらい言ってしまっても過言にはならないな

「夜は室温29℃、昼は室温28℃になってほしい」くらいのこと、 PID 制御を一切知らずとも言えるんじゃ

外 漕 ぎ

Adds ability to flatten image after build by cpuguy83 · Pull Request #22641 · moby/moby
https://github.com/moby/moby/pull/22641

10年前から issue 立ってて2016年11月に merge されたはずの docker build --squash、2023年の今になってもまだ experimental なのかよ……

まじでさぁ……

腰の重さが半端ではない

血の滲むような努力によって、どうにか社会性のある時間に起床することに成功した。再び労役日を迎える準備が整った…… (ほんまか？)

このアカウントは、notestockで公開設定になっていません。

ほしい

何故かメモリ 128GB 積んでる AMD64 サーバが2台あるので、水やって育てれば5台くらいまで増えないかなという気持ちがある。たぶんそのくらいあればリソースの割り当てとか深く考えずガバガバでやらせても大丈夫になりそうなので

そのころにはメイン NAS の HDD 20台くらいになってそうだしサーバラックの電気代がアイドル状態で 1kW 超えてそう

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

メインNASもメモリ 256GB 積んだ amd64 機だけど、これはマジで NAS 用途でしか使うつもりないので遊べるサーバにカウントしていない

オブジェクトストレージに使いたい場合に備えて minio とか立てといた方がいいかなぁと思いつつ、まだ何もしていない

S3 for MinIO |
https://www.truenas.com/docs/core/coretutorials/services/s3forminio/

あれ、もしかして S3-compatible なオブジェクトストレージって TrueNAS CORE にビルトインで対応入ってた？ てっきり jail で自分で用意しないといけないやつかと思ってたわ

このアカウントは、notestockで公開設定になっていません。

可能性はある

24Uラックはあるので頑張れば5台詰め込める、と思いきや 4U 相当の非ラックマウントケースを詰め込むとなると棚板で 0.5U くらい使ってしまうのでデカ・ケースだとギリギリあと2台入らなそうなのであった

ネットワーク機器 1U×4
サーバ 4U×3
PS5 3U+棚板
箱NAS 4U+棚板

という感じで埋まっている (<https://mastodon.cardina1.red/@lo48576/110677685942693577>)

そして改めていろいろ調べていたところ、 Proxmox VE で LXC コンテナを使うと、 rootfs 用ストレージに ZFS を選択する場合はディスクイメージではなく ZFS dataset をそのままマウントして使ってくれるようで、つまり /var/lib/docker が肥大化したとしても rootfs イメージの拡大をせずに済みそう。これは嬉しい。

はよ btrfs でも同じレベルのサポートが入ってほしいものだが

live migration したい場合はどうしても qemu による VM 使うことになるけど、まあそこまでしたい場合は稀だしべつにいいかなという感じ (マルチプレイのゲームサーバとかくらいか？)

ぶっちゃけ k8s の準備してたけど terraform + ansible で快適にできそうなら docker on LXC on Proxmox VE の方が快適なのかなという方向に傾いている

VPS 使ってると、あらゆるサービスについてナップサック問題を解いて複数コンテナを単一ホストに詰め込むみたいなダルいことをしがちなんだけど、自宅クラスタでマイグレーションとメモリ割り当ての変更を好き勝手できるならその辺り考える必要がないので

そんでもって「宣言的に管理」の部分を terraform + ansible でできるなら別に困らないよな、という感じ

もしかして第4章ずっとこんな感じのテイストでいくのか……？
緊張感があって大変よろしい

https://mastodon.cardina1.red/@lo48576/110767228303605584

オタク強く推奨 terraform の入門文書、ありますか

このアカウントは、notestockで公開設定になっていません。

その可能性もあるか

喧嘩かはさておき「スタッフの大部分は移動したが親組織との繋がりが保たれているわけではなく」みたいなことは普通にありそうだなとは思っていた

独立？

独立が先だったのか解散決定が先だったのかは知らんので完全に妄想だが

:⁠name_badge:

元の意味も知っているでしょう……

このアカウントは、notestockで公開設定になっていません。

自前インスタンスなら :⁠enji_mune: などで登録する手もありますよ (名前が最悪すぎる)

あまりに人聞きが

このアカウントは、notestockで公開設定になっていません。

個人的には物理スポーツのマナーも大概カスではという気持ちがあるけど (場合によってはプレイヤーも)

しかし言わんとしていることはわかる

このアカウントは、notestockで公開設定になっていません。

terraform 弄ってると今日が終わってしまうのでとりあえず後回し…… (と言って結局放置するパターンだなこれは)

btrfs は online grow/shrink に対応しているのがあまりに魅力的

iSCSI 上に何の FS を乗せるか考えている

まあ現実に実用するサーバを運用していてストレージを縮小したくなることはそうそうない気もするが……

NFS とか SMB/CIFS だと permission まわりの面倒を持ち込むことになりかねないのと、別の NAS への定期バックアップで小さなファイルが無限にあるのはあまりよろしくなさそうというのがあり……

iSCSI のターゲットを2つ同時に使って ミラーリング (btrfs raid0 等) することで NAS のプラットフォームを跨いだ冗長性を確保する手があるのか。頭いいな (落とし穴ありそうだが)

まっとうなレプリケーションは誰が落ちてもちゃんとフォールバックして権威が2つに分岐しないのが嬉しいのだが、ミラーリングにすると片方が落ちたときデフォルトだと read only になってしまうし、どちらを権威とするか手動選択する必要があるという問題がある。そこで手作業と決断が必要ならバックアップでも大差なくない？ という感じはするな

うーん……

* iSCSI の何かしらを LXC ct にマウントして docker からそこをアプリ用 volume として使うのなら安全そう。
* iSCSI の何かしらを rootfs として使うのも安全そうだが、 /var/lib/docker の肥大化に iSCSI ターゲットが巻き込まれるのでバックアップ面であまり幸せになれない気がする。
* アプリ用 volume を NFS か CIFS で確保するのはアリといえばアリだが、パフォーマンスは気になるのと、パーミッションまわりで絶対面倒なことになる。

さてどうするか

問題は iSCSI ターゲットへの接続を Proxmox VE にやらせるか VM や CT にやらせるか

iSCSI イニシエータを Proxmox VE 側にやらせる情報ばかり出てくるんだが、これクラスタ組んでる場合だとマイグレーションまわりで面倒なことになったりせんのか……？ という疑念がある

いやわからん、もしかすると単一の VM/CT にしか関連付けられないから大丈夫という話なのかもしれない (怪しい気がするけど)

[SOLVED] - Shared iscsi lvm not active on hosts in cluster | Proxmox Support Forum
https://forum.proxmox.com/threads/shared-iscsi-lvm-not-active-on-hosts-in-cluster.100223/post-432580

> The "iSCSI shared", especially with LVM on top of it, means that volume can be easily accessed and activated on one host at a time as needed. The PVE will activate the volume if the currently active host fails, or you move the VM that owns a specific LVM slice. PVE as an orchestration tool will make sure that volume is active where needed.

これが知りたかった！！

やっぱり live migration には支障ありみたいな情報あるな (原理的にそうでしょうね)

となると、 Proxmox VE にイニシエータをやらせるよりもコンテナにやらせる方が賢い気がするんですが。はてさて。

バグだか何だかで LXC 内から iSCSI 使うのに苦労しそうという情報が出てきている。 iSCSI なかなか持て余すな……

どうしよう

とりあえず飯にするか

iSCSI を VM の rootfs に使うと live migration できない。 [EDIT: まちがい？ → https://mastodon.cardina1.red/@lo48576/111827403015556319 ]
iSCSI を LXC ct の rootfs に使うと /var/lib/docker をバックアップに巻き込むことになる。
iSCSI を LXC 内でデバイスとしてマウントするのは問題があるらしい。
iSCSI を VM 内でデバイスとしてマウントするのは……いけそうか？

「何者かになりたい」は本質的には「『何者でもないもの』になりたくない」という二重否定なので、定義も困難だし目標も定まらないしすべきことも見えないし評価も難しいということになる

VM にすると、べつにシングルイメージになっていても嬉しくない rootfs がサイズ固定のファイルになってしまうので気乗りしないが、まあ試す価値はあるか……

凡人だろうが楽しい人生は楽しいし、偉人だろうがつまらん人生はつまらん

terraform については、たとえば「『Ubuntu 23.04 でインスタンス立てといて！』とやった1年後にインスタンス内から Ubuntu 24.04 に dist-upgrade したらどうなるんだろう」という素朴な疑問があり、どう動作してもモヤっとするなぁという気持ちがある

たぶん一番正解に近いのは「立てるときの指定は立てるときのものなので現状の OS は関知しない」とかなんだろうけど、それはそれで、だったらシェルスクリプトとかで存在確認とインスタンス作成をまとめちゃえば同じことなんか……？ という。それだったらスクリプト書いてしまうかもしれない

このアカウントは、notestockで公開設定になっていません。

でもインスタンス内部の詳細な状態って terraform とかよりも ansible とかの方の管轄だと思っていたので、現実的に in-place upgrade って理想的な方法を用意するのは難しそうじゃないですか

このアカウントは、notestockで公開設定になっていません。

やっぱこうなるよな

そもそもインスタンスの作成/削除ができるのだからこれが一番素朴でゴミが残らないというのはわかる

わかるが、この運用をするためにはバックアップ/リストアをちゃんとやる必要がある、具体的には OS イメージ丸ごとバックアップするのではなくアプリ固有のデータを分離して管理できるようにする必要がある (ちゃんとやれ)

べつに docker 系のもの使っていれば mount/volume 系の機構で勝手にこれ実現できるじゃんというのは、マジでそう

で、新インスタンスの IP アドレスなり何なりのリソースの移管は terraform とかがやってくれるわけよね

そもそも動的なプロビジョニングで固定 IP アドレスを活用するというのもどうなんだという気持ちが正直ある

DHCP サーバと DNS サーバが独自の生態を持っている実装であるところの YAMAHA ルータなので、あまりそっちでいろいろやりたくないというのがある (自動化できるにはできるが、純粋にダルい)

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

ﾂｲｯﾃｰを Twitter とも 𝕏 とも呼ばずﾁｭｲｯﾃと呼ぶ、そういう道だってあると思うんですよ (?)

iSCSI を直接 docker volume としてマウントできないのかと思ってググっていたが、どうにもまともな実装はなさそうか