やーーーーっと nginx の設定生成/更新の自動化ができた (n年ぶりm回目)
らりお・ザ・何らかの🈗然㊌ソムリエ(@lo48576@mastodon.cardina1.red)の投稿
やーーーーっと nginx の設定生成/更新の自動化ができた (n年ぶりm回目)
ansible で reverse proxy と grafana と loki が立った
ヨシ👉
オタクおすすめの Vultr で立てたので IPv6 セットアップが (ConoHa に比べると) クッッッッソ楽だった、そのうち全部引っ越すのが確定した
IPv6 アドレスが16個しかない VPS で docker なんて使うもんじゃねえよ、 /64 くれる VPS 使おうな
git submodule って、大元のリポジトリも参照されているリポジトリも fork して別の場所にホストしたとしても submodule のメタデータが URI で fork 前のものを参照しているところが気になっていて、分散管理原理主義的 vendoring にはちょっと使いづらいよなぁという感覚がある
submodule を使っていない場合、基本的にリポジトリがどこに存在しようが等価なものとして扱えるのよね。ローカルにあろうがサーバにあろうが。
ところが vendoring は「同じリポジトリ内に同梱されている」というある種の自己完結を目的としているのに対して submodule は「特定の場所のリポジトリを参照する」という fixed なリンクを実現するものなので、この場合目的と手段が噛み合わなくなってしまう
つまり vendoring されているプロジェクトを、 submodule とは別の方法で履歴まで含めて保存・参照したいという欲求がある
特定のスナップショットをコピーしてきて大元のリポジトリにコミットするという手はそこそこ使われがちだけど、結局これって vendored なリポジトリの履歴は捨ててるので、かなりもったいない
nested なリポジトリをうまく表現する方法はないものですかね。
とかいって片付けると急に暑くなったりするんだろ、俺は詳しいんだ
プロジェクト内での依存をプロジェクト内に全部突っ込む (vendoring) するなら、それらへの参照は理想的には内部的に完結していて内部でのみ unique な名前さえ用意できていれば十分なのに、 submodule はそうなっていない。まあつまり vendoring のための機能ではないということなんだろうけど……
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
たとえば台形に変形したときに普通に平面上で変形するのとパースペクティブに(つまり Z 方向に)変形するのでは変化率が違ったはず
だから HLSL とかには noperspective といったオプションがあってそれの計算を抑制できるなどの機能があった気がする
あ、同じような形にして奥行があるように見えても実際には奥行があるときとは見え方が違うよという話です
インテルネッチにあるわかりやすい例だとこれぐらい違うはず
http://www.c-jump.com/bcc/common/Talk3/OpenGL/Wk05_pipeline2_GLSL/W05_0170_noperspective_example.htm
普通は三角形しか描画できないのでそうなるんですが、 頂点以外の UV を補完するときに奥行を考慮しないと画面と平行な面で変形しているように見えてしまうという例
Prometheus と InfluxDB について調べている
Grafana と Loki はとりあえず立てたけど、 Loki はログを溜めるものっぽいのでひとまず先に Prometheus でメトリクスを集める方を準備すべきだったか……みたいな気持ちになっている
とりあえずデータは長いこと永続化したいので S3-compatible object storage とかに突っ込めるようにしたくて、 Prometheus 側を調べるべきか InfluxDB でのダウンサンプリングを前提に調べるべきか……みたいな技術選択から迷っている
軽くググっても日本語だと「試してみた」とかそんな感じのチラ裏レベルの話ばかりで本質情報が全然ないんだよな、これだから日本語圏は……という気持ちを抑えられない
永続的なメトリクスなら Retention Rule 細かく設定できる InfluxDB のほうが向いてるかもしれない
Prometheus は全部のデータを直近 n 日とかそういうためかたしか指定できなかった気がするのと PromQL が若干わかりづらい
PromQL はどうせ Grafana 経由であれこれするつもりなのであまり気にしてなかった
いつぞや Mastodon を見て「思想から入るｿﾌﾄｴﾔは流行らない」とか言ってる人を見たものだけど、そりゃ「試してみた」記事ばかり触れていればそういう思考パターンになるよな……という感想です
まあクエリ言語なんて「おれのかんがえたさいきょうのダッシュボード」ができれば以後そうそう弄るものでもないし、正直ちゃんと使えればそれで良い
あーあと Prometheus はけっこうオートスケールするサービスを前提に設計されている感はあるので、固定かつ少数のホストを見るときはちょっと冗長っぽい見た目になってしまうかもしれない(でも Pull 型アーキがメインというのは大きなメリット)
タグを付けて同じサービスの異なるホストを区別するとかそういう系の話か
Prometheus 自体をスケールさせるために Thanos なるものがあるっぽくて、界隈マジで無限にスケールさせてるな……という感想
InfluxDB は その点 created_at 必須の RDBMS ぐらいの感覚で扱えるので少数管理にも向いてそう感はありますわね
素朴で object storage 使える TSDB があればそれでいいんだけどな…… (とは言うがどうせクエリ機能で爆発するのでクソデカになるのだろうな)
Prometheus の方が時間の分解能が低いとかデータ構造が単純だとかで InfluxDB より表現力が低いみたいな話はどこかで見た
このアカウントは、notestockで公開設定になっていません。
ちょうど CPU と GPU みたいな違いかもしれない、 Prometheus はとにかく homogenous なインスタンス群を気持ち良くまとめて扱うことに重きを置いている感がある、逆に InfluxDB はその点でいうとクエリ時の集約がちょっとめんどうかも
まあ metric 用のサービスだからデータ型がプリミティブで似通うのは当然といえば当然ではあるか
6月4日以外にもだめな日があったのか。
＞日中戦争の発端となった盧溝橋事件と同じ、7月7日に新製品を発表すると予告したことを当局が問題視した。
ソニー、中国当局から約1778万円の罰金命令 7月7日の製品発表予告が「中国の威厳損なった」 - ITmedia NEWS
https://www.itmedia.co.jp/news/articles/2110/18/news139.html
もしかして InfluxDB って古いデータを object storage に退避させるみたいなことできないのか……？
backup を固めて S3 に投げられるよみたいな話はあったけど、 Grafana からクエリできないとうまあじがない
や、まあン年前のデータをリアルタイムのデータと一緒に使おうとするなという話か……
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
ベンチマークソフト「ちはやローリングWE」を公開｜Key Official HomePage
https://key.visualarts.gr.jp/info/2010/08/we.html
Thanos - Highly available Prometheus setup with long term storage capabilities
https://thanos.io/tip/thanos/quick-tutorial.md/
真面目に Thanos 検討するか……
