blog.katsumikobayashi.com を開設しました

ふと思い立って本名ドメインを検索してみたところ、空いていたので取りました。年間1500円程度なので取って損はないでしょう。

このブログは自宅のマシン上でホストされていて、3台の物理マシンで構成される proxmox cluster 上の k8s cluster へのデプロイ基盤が整えられています。Astro のビルドを経て最終的に静的なファイルが全て docker image に梱包された状態でデプロイされています。おいおいS3に画像を移し替えたりしても良いけど、今は良いかな。

hostnamehardware役割
huajiaoRyzen 5 2600メインコンピュート
rosemaryGmktec nucbox g2冗長化
parsleyGmktec nucbox g3冗長化
  • OS
    • proxmox ve
      • talos
      • nixos
    • vm と lxc の使い分けについて
      • nixos の場合
      • それ以外
  • ネットワーク
    • cloudflare warp
    • local dns
    • ddns
    • nginx reverse proxy
    • cilium
  • k8s cluster について
    • flux
    • cilium
  • ブログのデプロイ基盤について
    • obsidian
      • self-hosted live sync
    • pvc mount
    • gitops
      • flux
    • preview について
    • github actions runner
    • terraform & ansible (& nixos)

ポイント

cloudflare に載せる

自宅サーバーを始めた当初は生IPにポート開放してたんですが、今ではそんな危険な状態は考えられません。セキュリティには一層気をつけなければならない時代ですし、便利ですから、zero trust ネットワークを利用するのが良いと思います。オブジェクトストレージのR2、cache、ドメインの registrar など自宅サーバーをやる上で非常に有用なサービスが数多く存在します。1

macos の cloudflare one client が上手く動かない

数少ない cloudflare で困ってるポイントとして、macOS の cloudflare one client が上手く route を追加してくれないという問題があります。これを回避するためにスクリプトを組んで適用していますが、本当はこれ無して動いてくれるのが一番嬉しいです。

https://github.com/TakabayaP/dotfiles/blob/main/modules/darwin/warp-homecloud-route.nix

ansible は避ける

vm を作成したあとのソフトのインストールなどで ansible を利用していたんですが、扱いづらく特定の用途にのみ絞り基本的には NixOS を利用しています。

  • 羃等性の担保が難しい
    • ansible は要はシェルスクリプトなので、羃等性の担保は自分でやる必要があります
  • 行数が膨らむ
    • 丁寧なコードを書いているとすぐ行数が膨らみます
  • 再現性が低い
    • 羃等性が保証されておらず、完璧なコードは書けないためです
    • ローカルで試しづらいことも難しさの要因です
  • テストしづらい
    • 基本 lint のみなので、実行してみてやっぱダメだった→直すの繰り返しになります
    • AI Agent との相性が悪いです
  • 遅い
    • 行数が長くなると、当然遅くなります

claude code に丸投げしてたんですが、ローカルでテストしづらく結局実機適用して落ちたら直しての繰り返しになるので改善を回すのに非常に時間がかかるようになってしまいました。現在は proxmox の機能のうち terraform での操作に対応していない部分(NFSサーバーなど)のみを ansible で管理しています。

現在は nixOS をメインで使っています。nixOS LXC は権限周りに多少問題はあるものの、思ったよりも上手く動いてくれています。VMはいわずもがなです。nixOS の注意点としては、デプロイ用の self-hosted github actions runnner を用意することになるんですが、ここに nixOS のビルド成果物がめちゃくちゃ溜まります。自動クリーンアップなどの対策を取っていたのですが、結局ビルドサーバーを建ててそちらに全て任せることにしました。nixOS を proxmox で使う上での tips も色々あるので、また別でまとめます。

obsidian self-hosted livesync がかなり良い

obsidian は公式の sync 以外にも couchDB をセルフホストしてリアルタイムで sync することができる plugin が存在します。さらに、obsidian client app 経由のみならず、ヘッドレスでファイルを同期できる livesync-bridge も存在するので、md ファイルをリアルタイムにあらゆる場所に同期することができます。

これにより現在は

  • obsidian client app
    • macOS / iOS / linux でファイルを同期&編集
  • couchDB
    • self-hosted livesync の master data
  • livesync-bridge
    • サーバー上の任意の場所にファイルを同期
    • これをビルド時に参照したり、hermes agent が触れるところに置いたりすることでリアルタイムでドキュメントが同期される環境を構築しています

obsidian self-hosted livesync x astro dev server は変更検知されない

素直に実現すると、livesync bridge によるNFS越しの変更を astro の dev server が検知できないのでリアルタイムプレビューになりません。まずは persisted volume としてビルド時に見せること、そしてワークアラウンドとして変更検知を自作しています。

脚注

  1. tailscale は使った経験は無いので比較はできません。 ↩︎