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