自宅サーバの構成をひととおり書き出す
家に置いてあるサーバで何を動かしているのか、どういう方針で組んでいるのかをまとめた。
家にサーバを置いている。用途が増えるたびに構成が変わっていくので、いまどうなっているかと、 なぜそうしているかを一度書き出しておく。
何が載っているか
物理は 2 台で、その上に仮想マシンとコンテナが載っている。だいたい次のような役割で分けている。
| 層 | 置いているもの |
|---|---|
| ハイパーバイザ | 仮想マシンとコンテナの土台、バックアップ |
| サービス | ゲームサーバ、監視、リバースプロキシ |
| 外向き | CDN 経由の公開、証明書 |
置き場所を分けている理由は単純で、止まったときに巻き添えになる範囲を小さくしたいから。 バックアップと監視まで同じ箱に載せると、その箱が落ちたときに何が起きたか分からなくなる。
方針
組み方については、だいたいこの 3 つを守っている。
- 手で触らない。設定はリポジトリに置いて、そこから流し込む
- 復旧を先に用意する。壊れない仕組みより、壊れたあと戻せることを優先する
- 障害のときに使う経路を、平時の仕組みに依存させない1
とくに 1 つめは、自分ひとりで運用している以上いちばん効く。手で直した設定は、 半年後の自分には「なぜそうなっているか分からない設定」になる。
流し込みの形
設定は宣言として書いて、まとめて適用する。たとえばコンテナの定義はこんな見た目になる。
services: example: image: registry.example.com/example restart: unless-stopped volumes: - ./data:/var/lib/example適用そのものは CI から走らせていて、手元から本番へ直接つなぐことはしない。 つなげてしまうと、「今日の手元の状態」が本番に混ざる。
これから書くこと
- ストレージとバックアップの取り回し
- 監視をどこまで作るか(作りすぎると誰も見ない)
- ゲームサーバの運用
このシリーズでは、構成そのものより なぜその形にしたか を残していく。
脚注
-
復旧の手順が、普段の自動化の成功を前提にしていると、肝心なときに使えない。 ↩