インターネット嫌いなものシリーズを始める

突然だけど始めます。インターネットを見ていてイラついたものを手当り次第放り込んでいきます。特に狙いとかないですが、強いて言えば「インターネットの風景」というものを記録しておきたいということです。各時代で流行ったものを振り返るのは簡単だろうけど、イラッとした広告やPV稼ぎの手法なんかも歴史として残しておきたいなと思った。

【悲報】牛めしや定食などでお馴染みの松屋がとうとう2023年3月15日から・・。
https://shiga2.jp/matsuya-20230315/%E3%83%8B%E3%83%A5%E3%83%BC%E3%82%B9/

3月15日から何だよ(値上げです)。「【悲報】」もすっかりまとめサイトタイトル構文として定着し、YouTubeなんかでも見るようになったね。

他の記事のタイトルも全部この調子。アドブロなしで開くと広告が上に9個下に10個。ワハハ。

Xiaomi Smart Band 7で水泳?/川口まちこうば芸術祭2023/GoでMySQLで文字列検索/dockerコンテナ内からホストにアクセスできない

Xiaomi Smart Band 7で水泳?

僕はXiaomi Smart Band 7を使っている。健康診断で心拍が多いと指摘を受けたときに病院でスマートウォッチを勧められて買った(なんでもなかった)。スマートウォッチ界の低予算部門のスターのような製品だ。心拍は一応そこそこ正しい値が取れる。歩数は実際の19%増しくらいの値になる(数えた)。

先日初めて水泳の測定に使ってみた。Workout > Swimmingで水泳モードに入れる。水泳モードでは水で画面が傷まないように(?)画面表示がデフォルトでオフになる。画面を操作するためには画面を↑↓と繰り返し撫でる必要があるが、水がノイズになってなかなか入力に成功しない。泳ぐプールの長さを入力することができ、休憩やターンを自動で検知して今何往復したのかを記録してくれる。泳いでいるとカウントがわからなくなるのでこれは助かる。そこそこ正確だ。ストローク数も取れる。

水泳モード中は心拍数の計測が止まる。水中では光学式心拍測定の信頼性が低いから取っても意味ないってことなのかな。水泳モードにしなければ心拍数は取れるらしい。

川口まちこうば芸術祭2023

こんなイベント。
https://www.kawaguchicci.or.jp/kawaguchifaf/

やってたので見てきた。金属加工を使った家具やおもちゃ、芸術品などが展示されていた。特に新光ステンレス研磨による時計は特殊研磨によって美しく妖しく光り輝いていて欲しくなっちゃったが(買える)、さすがに高かったので諦めた。

GoでMySQLで文字列検索

愚直に

db.Query("SELECT * FROM status WHERE text LIKE '%?%' ", includedText)

みたいに書いたんだけど?がplaceholderとして扱われずincludedTextが入らなかった。なんか調べてみたら
https://graff-it-i.com/2021/06/24/golang-mysql-like/
こういう話があって

db.Query("SELECT * FROM status WHERE text LIKE CONCAT('%', ?, '%') ", includedText)

CONCATでやるらしい。へぇ〜。

dockerコンテナ内からホストにアクセスできない

今作ってるアプリケーションのコンテナから、同じサーバーに乗っているmstdn.chao.tokyoにアクセスしようとしたらconnection refusedになってしばらく頭をひねっていた。コンテナ内でdig mstdn.chao.tokyoすると127.0.0.1に解決されていた。本来ならグローバルIPが引けるはずなのに、これはおかしい。

ホストの/etc/hostsに127.0.0.1 mstdn.chao.tokyoが書いてあるせいだった(たぶん以前動作確認のために書いた)。理屈はよくわからないがコンテナ内からの名前解決でもホストの/etc/hostsが読まれてしまうことがあるようで、コンテナ内から127.0.0.1に解決されるので、コンテナ自分自身にアクセスが戻ってくる。コンテナ自身の443ポートは開いてないのでconnection refusedになったわけだ。

https://qiita.com/tksugimoto/items/804e0051bf1b1ddab168
この記事によるとホストの/etc/hostsはコンテナ内の名前解決に影響を与えないとのことだが、僕のサーバーはnginx-proxyを活用するために結構変なdocker networkが立っているのでその影響があるのかもしれない。

gotosocialのサーバーを別のマシンに移動した

サーバーコスト削減の流れで、全てをさくらのVPSに集約することができた。

gotosocialのサーバー移動はやや手間取ったが、終わってみれば別段難しいことではなかった。一応ドキュメントに記述があるが、大雑把だ。

https://docs.gotosocial.org/en/latest/admin/backup_and_restore/

やったこと

  • 新しいサーバーにdocker-compose.ymlを配置する
    • gotosocialのdocker imageのバージョンが変わらないように注意する。ここを間違えて0.6から0.7に上がってしまい手間取った。gotosocialのバージョンが上がるとDBのスキーマが変わることがあり、マイグレーションが上手く通らなくてDBを参照できずに落ちる。
gotosocial    | timestamp="04/03/2023 15:27:59.346" func=admin.(*processor).MediaPrune.func3 level=ERROR msg="MediaPrune: error pruning meta: SQL logic error: no such column: account.last_webfingered_at (1)"

https://github.com/superseriousbusiness/gotosocial/blob/main/internal/db/bundb/migrations/20230202212700_rename_account_webfingered_to_fetched.go この辺かな?

  • 古いサーバーのsqliteのデータをdumpする
$ cd data
$ sqlite3 sqlite.db
> .output ./dump.sql
> .dump
  • このdump.sqlを新しいサーバーに持っていく
    • scpなりrsyncなりご自由に
  • 新しいインスタンス用のsqliteデータベースを作りdumpファイルを読み込む
    sqlite3 newdb
    .read ./dump.sql
  • 画像等のファイル(dataディレクトリ内のsqliteではないフォルダ群)も新サーバーに持ってくる
  • docker-compose.ymlをよしなに変更する
    • sqliteデータベースの名前とか注意
  • docker-compose upしてDNSを新しいサーバーのIPに向け直す
    • DNSが効くまで時間がかかって面倒なときはローカルマシンの /etc/hosts に書き込んじゃうとすぐ動作確認できる

日記

急に本格派の焼売が食べたくなったので中国人がやってる中華料理屋で食べた。その後近所を少し散歩した。
コミュニティセンターのような施設があって初めて入ってみたら、大小いろいろな集まりの募集があって面白かった。しかし公的な施設というのはどこも節電で薄暗くて陰気で良くない。

帰宅してのんびりアニメを見たり、RimWorldを見たり、カレーを食べたり。今のロットのカレーはじゃがいもも人参も大きすぎて火の通りが悪いのが反省点だ。

エアコンのフィルタの掃除をした。猛烈にほこりが飛ぶかと思ったがそこまででもなく、粘着コロコロと流水だけでかなりきれいになった。掃除機がなくてもなんとかなるね。

digのオプションが多すぎる

ってmanに書いてあって笑った。

BUGS
       There are probably too many query options.

もっと面白いバージョンもあるようだ。翻訳前の文章は見つからなかった。
https://linuxjm.osdn.jp/html/bind/man1/dig.1.html

dig は "潜行性機能過多" を患っています。 これは開発中に潜在的な用途をいくつも考えていた結果です。 苛酷なダイエットをしたらきっとよくなるでしょう。 同様に、表示フラグとそれで指定できる表示項目の粗さとから、 これらがその場限りの必要性から追加されたものだということが わかるはずです。

ところでdigしたときのANSWER SECTIONの謎の数字って残りキャッシュ時間らしいんだけど本当ですかね?確かに減っていくんだけど。

新しいことへの挑戦とリファクタリングを同時にしてはならない 五木寛之『生きるヒント 自分の人生を愛するための12章』を読んでいる

新しいことへの挑戦とリファクタリングを同時にしてはならない

サーバーコスト節約と技術的チャレンジを同時にやろうとしてk8sがわからなくて遅れているけどとりあえずサーバーコストだけでも落としたほうが良い。一番の金食い虫のt2.microのインスタンスを早急に潰したい。

その後さくらの方に全部移してみて、それでスペック足りるようだったら一旦終わりにしよう。大半のアプリケーションは常時起動が前提だからElasticである必要がない(何にでもElasticを注ぐAWS)。

五木寛之『生きるヒント 自分の人生を愛するための12章』を読んでいる

ぼんやりと落ち込んでいた時期に友人に勧められた本。今4章。

筆者が人生経験と知識に基づいて、「こうあると人生が楽しいんじゃないか」という話を取り留めなく書き連ねている。職業柄厳密に事実を書いた本を読むことが多いけど、こういう「私の感想」全開の本というのも良い。時間も空間も超えて他人の言葉に触れられるという本の特質を鑑みれば、むしろこういう本こそ読書の楽しみなのだと思う(まあ金持ってるジジイだから余裕ぶっこいた物言いができるんだよね、と鼻白むようなところもないでもない)。

3章「悲む」ではまず明治時代に「悲しいではないか」を挨拶とした若者たちがいたことに触れ、人生には悲しみが満ちていることを認め、現代の娯楽が明るさを求めすぎていることを指摘し、私達はもっと率直に悲しんで良いはずだと主張する。

みんなが、〈暗い〉と言われることを恐れている。そして明るく軽快で楽しげであることを求めている。
これはひとつの病気ではないかと、ぼくには思えるのです。

これは僕もその通りだと思う。アニメを見ていてキャラクターの底なしの明るさと作品に満ちるエネルギーに圧倒されてしまうことが多い。思えば記憶に残るお気に入りの作品は静かで悲しいものが多い。

仕事をしていても、目標は高く輝かしく、失敗も問題点の分析と修正して次は頑張ろうというエネルギーに転化される。もちろん営利企業だからそのエネルギー、欲望でカツオのように泳ぎ続ける宿命にあるわけだが、一人の人間としてはついていくのが辛いときもある。

k8sデカスギSGSG

t4g.microの上に小さいクラスタ立てて練習しようとか思ってたけど、プロダクション向けのクラスタ立てツールであるkubeadmを走らせてみたらいきなり「メモリは最低1700MB用意しろ」とか言われてひっくり返ってる。ノードも複数台で本格的にやることしか想定してなさそうだし、これどうすればいいんだ(世の趣味でkubernetesで使っている人間は結構なインフラコストを払ってやっているのか?EKS最小構成でも月額73ドルらしい)。

k8sはクラスタ自体が容易に作成・管理できるものではないといろいろな場所で言われていたが、やってみてようやく規模感が理解できた。そして困った。

minikubeはproductionに使うなと繰り返し書かれているが、練習だからと割り切って使ってしまうのもありだろう。

また k8s lightweight とかで雑に検索してみると

  • k3s
  • microk8s
  • k0s

などがヒットした。k3sならいけるか、見てみよう。あるいは自宅に物理鯖置いてそこにクラスタを組み、トンネリングツールか何かで公開するという方法もあるのかな(もう全く安くないが)。

k8sをやってみる―サービスの公開―

サービスを公開する

https://kubernetes.io/ja/docs/tutorials/kubernetes-basics/expose/expose-intro/

なんかいろいろ公開の種類もあるが、随分ローレベルだなあと思ったらServiceとは別にIngressというやつがあるらしい。

https://kubernetes.io/ja/docs/concepts/services-networking/ingress/

Ingressにはいろいろな実装?がある。kubernetes自体が未知の領域なのでなるべく慣れたものに寄せるため、nginxによる実装を使う。

https://kubernetes.github.io/ingress-nginx/deploy/

インストール方法に with kubectl apply, using YAML manifests がある。嬉しい。

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.6.4/deploy/static/provider/cloud/deploy.yaml

で必要なリソースが諸々立つらしい。先に作っていたDeploymentとここで作るリソースを統合するためkustomizeを導入する。と言っても

resources:
- deployment.yml
- https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.6.4/deploy/static/provider/cloud/deploy.yaml

と書かれたファイルを用意し、起動コマンドを kubectl apply -k . に変更するだけだ。

https://github.com/chao7150/barrack-k8s-spec/commit/977fb3c90989f96c5a070508e90aad45b570adad

この段階でこれらのファイルを保存しておくGitHubのリポジトリを作った。

本題に戻って外部からいい感じに内部のサービスにリクエストが通るように進める。

https://kubernetes.github.io/ingress-nginx/deploy/#local-testing

既にDeploymentは存在するとして、exposeでそのDeploymentを公開し(これはServiceを立てることと等しいので後々ymlでそれを書く)

kubectl create ingress demo-localhost --class=nginx \
  --rule="demo.localdev.me/*=demo:80"

でアクセスをDeploymentに向けるようなingressを立てる。classはいろいろあり得るingressの実装のなかでingress-nginxを使いますよという意味。ruleは demo.localdev.me/* へのアクセスをdemoという名のDeploymentの80番ポートにフォワーディングしますよという意味。

なんで demo.localdev.me がlocalhostに向いてるんだよと思って調べてみたら

https://qiita.com/masahata/items/89b2be02ee36b82cfced

このドメインを誰かが取得して 127.0.0.1 に向けているらしい。マジかよ。そして何の説明もなしにやるなよドキュメントで。

ここから先は本番のクラスタでやることらしいので、次回は本番のサーバにクラスタを組んでもろもろやっていくか。本番のサーバは既にgotosocialで稼働しているので、nginxでgotosocial以外へのアクセスをk8sクラスタに流す方針でやってみる。SSLオフロードとかも前段nginxでやっちゃいたい。

IYマイレジ ピピットスマホを会員限定にするな うたもくとgfnと酒を飲んだ

たまには日記を書く。

起きて、昼食に丸亀製麺のトマトカレーうどんチーズのせを食べた。

スポーツクラブに行って30分歩いたり走ったりした。本来日曜日は泳ぐのだが、今日は足腰の筋肉痛が持続していたので軽くした。マシントレーニングで同じ筋肉を週1回鍛えるとして、筋肉痛が1週間持続したらその間その筋肉の負荷は抑えるべきらしいので、有酸素運動を軽減せざるを得ない。なんというか、配分が難しい。人生を通してきちんと体を鍛えたことがなかったのでどうやればいいのかわからないことが多い。

IYマイレジ ピピットスマホを会員限定にするな

その後スーパーで納豆とヨーグルトを買って帰った。これまでスーパーではスマホをセルフレジ代わりにするサービスが使えたのだが、今日行ったら会員登録しないと使えなくなっていた。しかもその会員登録がスマホからしかできず、登録したらメール送りまくりますメール停止は面倒にしておきますと宣言するかのような文言があったので、腹が立って登録をやめた。

スマホに通知を飛ばせるという点でアプリをインストールさせるのが効果的なのは理解するが、会員登録には

  • メールアドレスの入力
  • パスワードマネージャによるパスワード生成

という作業が必要であり、これらを豆粒みたいなキーボードと1つのアプリしか同時に起動できない制約のあるスマホでやるのは面倒くさい。

そもそもスマホレジは有人レジを減らして人件費を抑えながらレジの待ち時間を減らせるwin-winの仕組みのはずなのに、どうしてそこに会員登録誘導というハードルを設けてしまうんだろう。

うたもくとgfnと酒を飲んだ

やっていきエナジーをかなり充填したのだが、2人はコードを書くことで世界に対してオンリーワンの貢献をしている一方で、僕は至って普通の職業ソフトウェアエンジニアで、ともすれば社内の事情や評価のことを考えがちだ。能力の高低以前に世界観のスケールが違う。

とは言っても彼らは会社のことなんか知らないで技術的探求に耽溺しているというわけでもない。むしろ技術的な最先端を突き進むことが会社の利益につながっていたり、逆に会社での制約を経験することで技術的な視野を広げたりしている。

レベルを上げて物理で殴れば全てが手に入るのだろうか。答えはわからない。具体例があるだけだ。ただ、こうして刺激をもらえる機会があるというのはありがたいことだ。

k8sをやってみる―Deploymentを作る―

※この記事は私の学習のメモであり、有益な知見は含まれていません。読まないでください。

k8sのクラスタを作る

チュートリアルのnginxのコンテナを立ててスケールさせて…みたいなやつは大昔に一度やった。今回はymlファイルのアレ(何て言うんでしょう?)で宣言的に管理できる状態を目指す。

チュートリアルを読むといきなりMinikubeというやつが出てくる。

https://kubernetes.io/ja/docs/tutorials/hello-minikube/

kubernetesのクラスタを作るのにkubernetes hogeとかkubectl fugaみたいなコマンドじゃなくて別の何かが必要になるのか…

https://kubernetes.io/docs/setup/

kubernetesのクラスタを作る方法を選ぶためのページがある。ローカルでの開発にはminikubeを、プロダクションにはkubeadamということにしよう。

https://minikube.sigs.k8s.io/docs/start/

minikubeを入れた。

minikube start

するとkubectlが見つかりませんと表示された。そこで

https://kubernetes.io/ja/docs/tasks/tools/install-kubectl/#curl%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%97%E3%81%A6linux%E3%81%B8kubectl%E3%81%AE%E3%83%90%E3%82%A4%E3%83%8A%E3%83%AA%E3%82%92%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB%E3%81%99%E3%82%8B

に従ってkubectlを入れた。あとでaptで入れればよかったと後悔したが、まあ良い。minikube deleteして再度minikube startするとなんとなく問題なさそうなログが出て作成が完了した。

ymlファイルを書いてなんかアプリケーションをデプロイしたい

k8sのドキュメントの中で情報を探すのに苦労したが、どうやら

https://kubernetes.io/docs/tasks/manage-kubernetes-objects/declarative-config/
https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/

この辺りを読めばいいらしい。ymlで設定ファイルを書ける機能はkubernetesの(というかkubectlの?)標準機能としてありDeclarative Managementと呼ばれていて、kustomizeはその拡張?のようなものだろうか。

そもそもどうやるとアプリケーションをデプロイできるのかというのを忘れてしまっているので、チュートリアルの内容をDeclarative Managementの作法で進めてみる。

チュートリアルによるとまずはDeploymentを作るらしい。

https://kubernetes.io/docs/tasks/manage-kubernetes-objects/declarative-config/#how-to-create-objects

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  minReadySeconds: 5
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

というファイルを作って同じディレクトリで kubectl apply -f . してみるとDeploymentが作られた。metadataとかselectorとか無くても動かんかw?と思って削ってみたらダメだった。これがホントの最小構成らしい。

次はこうして立てたコンテナに外からアクセスできるようにしたい。チュートリアルの方はしばらくデバッグ用と思われる kubectl proxy を使いながら基本的な操作の説明をするようだ。

サーバーゼニ節約&kubernetes入門

ふと毎月のサブスク費用を確認したらAWSとさくらインターネットで月額5000円くらいかかっていて、いくらなんでも辛いのでこれを圧縮する。

原因は必要以上に多くのサーバーを稼働していること。現在稼働しているのは3つ。

さくらインターネット 2GB

  • 1738円/月
  • 2017年から借りており、中途半端な技術的挑戦の残骸が最も多い
  • 金額に対するスペックが良い

積載物

AWS EC2 t2.micro

  • 1544円/月

積載物

AWS EC2 t4g.micro

  • 1076円/月
  • AWS謹製のGravitonプロセッサなので安くて高性能。ただしArm。

積載物

  • gotosocialインスタンス

移行計画

どうしたものか…

とりあえずEC2は新世代ほど高コスパの原則があり、t2.microはt4g.microに移行すべき。自分の学習を考えるとさくらはやめてEC2に揃えたい。全部t4g.microに相乗りを狙ってみようか。

そしてどうせならkubernetesに全部載せてみたい。複数のアプリケーションを相乗りさせるときのトラフィック管理をこれまではjwilder/nginx-proxyでやっていたが、もうちょっとナウいやつに移行して監視とかも統一的にやりたい。