feat: write about personal infra

Author: Stealthmate

_experience/personal-infra.markdown

@@ -1,14 +1,102 @@
 ---
 layout: experience
-title: 自家製私用 Kubernetes 上での QoL 向上ツールの開発・運用 (TODO)
+title: 自家製私用 Kubernetes 上での QoL 向上ツールの開発・運用
 toc: true
 date: 2023-09-01
 custom:
   period: 2023 年 〜 現在
+  tags:
+    - Kubernetes
+    - Terraform
+    - Hashicorp Vault
+    - PKI
+    - PostgreSQL
+    - Rust
+    - Grafana
 ---
 
-TODO
+## 事の発端
 
-関連記事:
+2023 年 9 月。仕事で Kubernetes を日常的に扱い始めて 1 年程経った頃だったかな。Kubernetes を触るのが楽しくて仕方がない！みたいな気持ちを持ちつつも、仕事ではむしろ刺激が足りないなと思い始めました。
 
-- [How I almost lost access to my Vault](https://stealthmate.github.io/blog/2025/04/20/how-i-almost-lost-access-to-my-vault.html)
+Prometheus や Grafana, ArgoCD などという、Kubernetes 界隈での定番物をよく触っていたものの、あくまでも最低限必要なことができるための設定しかしておらず、またチームで Kubernetes に興味を持っていたのは大体私だけでした。それが辛かったというわけではありませんが、例えば CircleCI の限界を感じて代替案を調べて [Tekton](https://tekton.dev/) や [Argo Workflows](https://argoproj.github.io/workflows/) に出会ったときに、めっちゃ面白そうなのにうちのチームじゃ導入できないなーと諦めざるを得なかったのは悲しかったです。
+
+一方で、同じぐらいの時期に家のエアコンの性能に嫌気が差して、大家さんに交換してもらうためのデータを集めようという発想を持ってしまいました。 Arduino でも買って、温度計を作って、エアコンがある部屋とない部屋両方に一つずつ温度計をおいて、データを全部クラウドに集めれば、それを持って大家さんに「したがって、エアコンを交換していただきである。 Q.E.D.」と主張できる！なんて若々しいことを考えていました。（2025/09 執筆現在、大家さんにはエアコンのことを一切話していません。）
+
+この 2 つの心理がたまたま同じタイミングに来たおかげで生まれたのが「自分でお金を払ってクラスタを借りてその上で色々置いてみよう！」という発想でした。以降、今 (2025/09) までの 2 年間はずっとそのクラスタを維持しています。
+
+## 自家製 Kubernetes クラスタの構想
+
+自分で Kubernetes を運用する、ましてやそこに Arduino などからデータを送り込んだり自分の PC からアクセスしたりするとなると、やはり考えることはそこそこ多かったです。[私が 3 年間セキュリティ部門にいた]({{ baseurl }}/basic-history/#hist-ly-sec-eng)こともあり、セキュリティには特に敏感でした。大昔に凡人の趣味サイトがいたずらハッカーキッズに乗っ取られたことも見たことがありますし、会社が億単位をかけるようなセキュリティ施策も日頃から見ていたので、おそらく普通の人よりも警戒心が強かったんじゃないかなと思います。
+
+他方で、別観点の悩みも途中から現れました。レンタルサーバーは文字通りお金がかかるので、基本的には無駄遣いをしたくないですよね。ましてや趣味で常時稼働する Kubernetes を立てるとなると最初からそこそこの金額になるので、規模もあまり大きくはできない。つまり、以下に少ないリソースで以下に多くのことを実現できるかの勝負が始まります。
+
+ここまでは当たり前のことですが、私の場合はさらにもう一つの制約をつけたかったです。お金よりも大事なのは自分の時間なので、手動でのオペレーションを極力したくなかったです。そのための施策として基本的に Terraform を限界まで使いまくることにしました。理想は、クラスタごと間違って削除してもワンコマンドで復旧できるぐらいのスタンスでした（実際そこまでやろうとすると現実性が薄れますが・・・）。
+
+話をまとめると、大体以下の 3 つがポイントになります。
+
+1. セキュリティはマジで意識する。
+2. 一つのクラスタで、極力少ないノードで、極力すべて完結できるように組む。
+3. 万が一クラスタが飛んでも、簡単な CLI コマンドで復旧できるようにする。
+
+## クラスタの現状と主なおもしろポイント
+
+2025/09 現在、クラスタは低スペックな worker ノード 2 つだけで回っています。なお「低スペック」というのは、文系大学生が使うノートパソコンと同じかちょっと下ぐらいだと思ってください。そのクラスタに載っている OSS 系のものは大体この辺りです。
+
+- [HashiCorp Vault](https://www.hashicorp.com/en/products/vault)
+- [ArgoCD](https://argo-cd.readthedocs.io/en/stable/)
+- [Argo Workflows](https://argoproj.github.io/workflows/)
+- PostgreSQL ([postgres-operator](https://github.com/zalando/postgres-operator)で管理)
+- [Prometheus](https://prometheus.io/)
+- [Grafana](https://grafana.com/)
+- [Fluent Bit](https://fluentbit.io/)
+- [Ingress NGINX](https://github.com/kubernetes/ingress-nginx)
+- [Envoy](https://www.envoyproxy.io/)
+- [cert-manager](https://cert-manager.io/)
+
+これに加えて自分で作ったサービスたちもいくつかあります。もちろんですが、全て自分で管理しています。
+
+以下おもしろポイントをいくつか紹介します。
+
+### 「Vault の運用は重いぞ」というアドバイスを無視した話。
+
+Secret 管理は面倒です。元々仕事でも十分に面倒だったのですが、趣味となるともっと面倒です。面倒だからどうにか楽にできないかと色々調べていた結果、 HashiCorp Vault というものに出会いました。それと同時に、 [Vault は運用が重いから安易に導入すべきでない](https://www.reddit.com/r/devops/comments/1mqtq7p/hashicorp_vault_is_it_worth_it/) という意見も知りました（リンクは新しいですが、当時でも同じようなことが言われていました）。
+
+普通の人ならこういう意見を見たら考えを改めると思いますが、私は馬鹿なのでやっぱり Vault で頑張ることにしました。しかもそれを Kubernetes 上にデプロイするという、いかにもイカれた発想です。
+
+ところが、最初はだいぶ辛かったんですが最終的には上手くいきました。 Kubernetes 上に Vault を立て、保存先はクラウドプロバイダが提供してくれてる Object Storage にして、 Kubernetes 上の他のサービスも Vault が使えるように [External Secrets Operator](https://external-secrets.io/latest/) を導入し service account の整備をして、 Vault 上の設定も Terraform に起こして IaC として保存したら今はだいぶ楽です。
+
+どれぐらい楽かというと、この前私の馬鹿さ故に Vault が落ちて起動できなくなった事件が起きたとき、設定を object storage から直接消したにも関わらず Terraform のワンコマンドで復帰できたぐらいです。幸いにもこの事件の武勇伝はちゃんとブログに残してあるので、興味ある人はぜひ読んでみてください。
+
+[How I almost lost access to my Vault](https://stealthmate.github.io/blog/2025/04/20/how-i-almost-lost-access-to-my-vault.html)
+
+### VPN の代わりに自家製 PKI を運用してみた話。あと SSO。
+
+kubectl 経由でクラスタにアクセスするのはまぁ大したことないですが、私の場合は携帯からアクセスしたかったです。なぜなら、当時は喫煙者で、タバコをやめるために喫煙打刻なる活動をして喫煙のデータを取りたかったからです。（詳細はここでは省きますが、半年こういうことやったらタバコをやめることができました！）
+
+話を戻そう。任意の場所から携帯経由でアクセスするとなると、実質ウェブサイトを公開しないといけないので、そうしようか非常に悩みました。上述の通りセキュリティには敏感だったのでなおさらです。厳重なる一人議論の末、最終的には以下の 2 つの施策を実施することに決めました。
+
+1. 大手クラウドプロバイダと自分のサイトを [OAuth2](https://auth0.com/resources/ebooks/oauth-openid-connect-professional-guide) で繋げて、ログインできるアカウントを限定する。
+2. 万が一アカウントが乗っ取られたときのために、 [mTLS](https://en.wikipedia.org/wiki/Mutual_authentication) で更に L4 での認証をかける。
+
+これだけで一つの記事が書ける（いつか書いてみたい）ので具体的なことは割愛しますが、どれだけ神経質になってたのかはこれで伝わると信じています。
+
+ところが、 mTLS を使うには証明書の発行と管理が必要です。結論から言うと、どうせ趣味だからここはガチでやろうと思い、HashiCorp Vault を使いつつ自分専用の CA を作りました。定期的に証明書を発行し、携帯や PC に取り入れ、サーバー側ではその証明書をチェックして許可されたものだけを通す、という仕組みを今も使っています。
+
+### Kubernetes に PostgreSQL を置いてみた話。キャッシュとして。
+
+喫煙データ、体重データ、部屋の温度データなど、色んなデータを集め始めると当然保存先が必要になりますよね。ところが私が PostgreSQL を使っている理由は全く違います。
+
+データを集めるだけならわざわざデータベースに入れなくても良いんです。ましてや私が扱っているような規模だったら CSV とか JSON とかに吐き出して Object Storage に打ち込めばそれで良いんです。なぜなら「ちゃんとした」データベースを運用するのはそこそこハードルが高いですが、ファイルを吐き出したり読み込んだりするのは誰でもどんなツールでもできるからです。実際一時期私もそうしていました。
+
+じゃなぜ PostgreSQL を導入したのか？理由は相変わらず馬鹿げています。Grafana でデータを出すとき、もう一つの選択肢がファイルから読み込むための API を作ることだったからです。 API を作るのは別にやろうと思えばできますが、それをやるぐらいなら PostgreSQL を入れて SQL でクエリーを書いた方が楽だよなーと思いました。
+
+つまりですよ。元データ（いわゆる [Single Source of Truth](https://en.wikipedia.org/wiki/Single_source_of_truth)）は object storage や自分のパソコンで保管しているファイルです。そのファイルにあるデータを Grafana で出すために、定期的に PosgreSQL に同期させるようにしています。この運用なら最悪 PosgreSQL が落ちても何も困ることないです。もう一回立てれば良いだけ。
+
+理屈はこれぐらいにして、実際のデプロイは思ったより面白かったです。世の中は私の頭より 10 年先の未来を生きているので、 PostgreSQL を Kubernetes 上で運用するためのツールはずっと前からありました。[postgres-operator](https://github.com/zalando/postgres-operator) というものです。これがあれば YAML 一つで PostgreSQL のデプロイだけではなく、 Object Storage でのバックアップや復旧方法まで定義・管理できます。本当にすごいです。
+
+## 最後に
+
+この記事は主に自分の能力を（採用担当者等）にアピールするために書いているので、細かいことは結構割愛しています（それでも長ぇんだよ！と言いたくなるのは分かります・・・）。実際には飲み会 5 回分のネタがあると思うので、追加で気になることがあれば面接か飲み会（か飲み面接）で聞いてください。
+
+ただ、こうやって書き出してみると意外と書ける内容が多いなーとも気づけたので、今後もうちょっと詳しい内容もどこかに書き残しておこうかなと思いました。