自宅サーバの使いみち (2025-Q1)
自宅サーバや VPS の用途を紹介する。
自分用サーバ
私の家にはサーバがある。
設置しているものだけでも19インチラックが2つ、NAS が4台 (うち1台は運用停止中)、ネットワーク機器は4台、汎用のノードが3台である。 実は画面外にデスクトップ PC が3台あり、ラックマウントでも設置していないネットワーク機器が2台と汎用ノードの芽 (CPU と M/B 抜き) が1台あるが、今回は関係ないのでさておこう。
薄々気付いてはいたが、一般のご家庭にしては些か数が多いようだ。 計算機リソースが多いというのは言ってみれば家が広いようなもので、「そんなに家が広くて何になるの」などと言う人はそういない。 リソースというのはあればあるだけ自由度が高まる便利なもので、その嬉しさを問うなど愚問である。
とはいえ、では具体的にその自由度を何に使っているかとなると、これは環境の差や個性の出るところであろう。 私のサーバ環境もゆったりと変化を続けている。 定点観測というわけでもないが、折角なので現状の記録と紹介を兼ねつつ「サーバなんて何に使っているの？」というよくある問いへの今のところの答えを置いておくことにした。
概略
物理ノード
まずサーバや自分用サービスといってもすべてを自宅に置いているわけではなく、要件次第で適宜使い分けることになる。 分類するうえで一番上に来るのが、「物理ノードを誰がどこで管理しているか」だろう。 概ね以下の通りである。
- 自宅 (汎用×4, NAS×4 (うち2休眠))
- 自宅に計算機の実機があり、その上でサービスを動かしている。
- 基本的に OS は Proxmox VE (Debian ベースの distro) を使い、その上で仮想マシンや LXC コンテナを立ててサービスを動かして使っている。
- 実家 (NAS×1)
- 実家に計算機の実機があり、その上でサービスを動かしている。
- 今のところ箱型の NAS 製品が部屋にそのまま置いてあり、それをストレージとして使ったり、上に仮想マシンやコンテナを立てて更に別のサービスを動かしたりして使っている。
- VPS (×2)
- VPS 業者が計算機を持っており、その基盤上で仮想化された汎用コンピュータを動かし、その上にサービスを乗せている。
- 基本的に OS は GNU/Linux (というか Debian) を使い、その上で Docker Compose を使ってサービスを立てて使っている。
- SaaS
- 業者が特定の目的にのみ使えるサービスを提供しており、それをそのまま使っている。物理的な計算機の実態は重要ではない。
- 主にメール関係、ドメイン関係、オブジェクトストレージ、リバースプロキシの一部機能などを使っている。
自宅サーバクラスタ
汎用ノード
Proxmox VE でクラスタを組んでいる。 今のところ3台構成だが、ノードもストレージもそのうち増やす予定がある。
vCPU (仮想コア) は 16+24+32=72 コア、メモリは (32 GB ×4枚)×3台=384 GB (=375.63 GiB)、ストレージは NVMe で各 1 TiB以上、 NAS で 42 TB (冗長化後) のうち一部をクラスタから利用可能にしている。 CPU は幸運にも全てPコアだ。 AMD 万歳！
利用率がスクショ時点で CPU 1%, メモリ 15% とスカスカのように見えるが、メモリは余れば ZFS というファイルシステムのキャッシュとして使われるので I/O の高速化に貢献し、 CPU も後述のビルドサーバを動かしているときには使えるだけ使うことになるので、無駄にはなっていない。 それでもビルドサーバ用途だと vCPU がメモリに対して少なすぎてバランスは悪いかもしれないが、現状で一般のご家庭向け CPU には 32 vCPU 以上の製品がない (ないといったらない！) ので仕方ない。 今はとりあえずメモリを 48 GB ×4 ×3 にする嬉しさが少ないことに感謝するのみだ。あれ高いんだよな……。
ちなみに、とある VPS の 64 vCPUs, 192 GB memory, 960 GB storage のプランが 1920 USD/mo. (≒ 月額¥288,000) なので、自宅インフラに350万円かけたとしてもこの性能なら1年で元がとれる。 電気代を高めに計算しても13〜15ヶ月あれば十分なくらいだ。 つまり VPS を2年以上借りている人は今すぐ自宅にサーバを持つべきである (錯乱)。
NAS
冗長化
HDD は壊れるものである。 そして遅い。 冗長化は (場合によっては) これら2つを解決できる。 ならばやるしかなかろう。
というわけで、すべての NAS で冗長化をしている。 メインの NAS では負荷と性能を考えて mirror VDEVs (ZFS 版の RAID10 みたいなもの) を、サブとオフサイトの NAS では1ドライブや2ドライブの冗長化 (Synology の NAS なので SHR-1 や SHR-2) を使っている。
とはいえ「RAID is not a backup」と古事記にも書いてあるように、 NAS のシステムが壊れたり誤操作で「正常に」破壊したりなどすればドライブを並べた程度の冗長化では対処できないこともある。 当然バックアップも必要だ。
バックアップ
バックアップによるデータの保全には 3-2-1 ルール (バックアップには3つのコピー、2つの媒体、1つのオフサイトを用意すること) というユーゴスラビアのようなならわしがある。
これを弊宅で実践しようとすると、こうなる。
- 3つのコピー
- 自宅 メイン
- 自宅 サブ
- 実家
- 2つの媒体
- メインとサブで HDD を共有しない
- 1つのオフサイト
- 実家
2つの媒体というのは本来であれば記録媒体を変えたいところで、たとえば HDD のホットストレージに対して磁気テープ (LTO とか) でバックアップを用意するようなことがしたい。 したいが、 LTO というのはどうやら一般のご家庭で動かすにはあまりにうるさいようなのと、 LTO 規格が LTO 8 以降で「ドライブは1世代前のテープまで書き込めて、2世代前のテープまで読み出せる」という気の利いた互換性保証をやめてしまった (読み出しも1世代前までになってしまった) というのが残念で、自宅への導入は却下した。
オフサイトバックアップについても怪しいところがあり、南海トラフとまで言わずとも関東で大地震でも起きたら自宅も実家も間違いなく同時にやられるような位置関係にあるので、かなりアテにならない。 とはいえ北海道に引っ越す気もないし、クラウドストレージは結構高いし (特に長期間となるとなおさら)、仕方ないので合格点ではあるだろうということで妥協している。 自宅が燃えても助かるならひとまず良しとしようではないか。
ちなみに何故 NAS がそんなに沢山あるかというと、こういうことだ:
- 4ベイの NAS (1) を自宅メインとして調達
- ベイが足りなくなった
- 8ベイの NAS (2) を自宅メインとして調達
- 4ベイのものを自宅サブに
- 実家用に8ベイの NAS (3) を調達
- 8ベイで普段使いには事足りるが、構成変更や他所からの HDD の持ち込みなどでベイがもっと欲しくなった
- 36ベイの NAS (4) を自宅メインとして調達
- 8ベイのもの (2) を自宅サブに
- 4ベイの NAS (1) の使い道がなくなったので休眠させる
- 36ベイの NAS (4) と同じ OS で効率的にレプリケーションするために、12ベイの NAS (5) を自宅サブとして調達
- 36ベイのやつ (4) がクソうるせえ！！！！！！！ 運用停止
- 12ベイのもの (5) を自宅メインへ、8ベイのもの (2) を自宅サブへ
ここから得られる教訓は簡単だ。 NAS は段階的に乗り替えてベイを増やしていくよりも最初の一発からベイが多いものにしておくべきである。ただし騒音レベルは事前に確認しておくこと。
NAS 上のサービス
NAS といってもこれは計算機の役割の名前にすぎず、実際に何が動いて何をしているかというと割とバリエーションがある。 素朴にリモートストレージとして使うなら SMB (CIFS)、NFS、iSCSI のサーバあたりを動かすのが鉄板だ。 私は主に SMB、たまに NFS を使っている。
NFS では認証まわりをセットアップするのが面倒で、かといって NAS 側に任せるとストレージとしての実装と認証の実装が分離できなくなるのが嫌だったので、雑に user / password で認証できる SMB を使うことが多い (なお盗聴耐性があるのかは知らない)。 iSCSI は Proxmox VE 側の問題のせいで使いづらくて仕方がないので今のところスルーしている。 本当は使いたいのだが。 rsync は PC との同期や NAS 間での同期で使ったりするが、こちらも通信路の暗号化はしたいので rsync サーバを立てるのではなく SSH でやっている。
近年の NAS はコンテナや仮想マシンを動かせる製品も多く、察するに NAS とは Network Almighty Server とかそんな感じの言葉の略なのだろう (いいえ)。 General Purpose Unit (いいえ) であるところの GPU を彷彿とさせる命名だ。 さておきコンテナや仮想マシンの機能は使えるには使えるが、たまにパフォーマンスやネットワークまわりで問題が発生して解決が手間だったりするので、あまりヘビーに使おうと思わない方がいいというのが個人的な経験からの考えである。 ゆえに今のところ NAS 上でリモートストレージとして必要な機能以外は動かしていない。
自宅サーバと VPS で動かしているもの
更に VPS から自宅へと移動する願望や新規追加を検討しているアプリもあるが、とりあえず現状を書く。
以下で挙げているものは単一項目でも実際には複数インスタンスを動かしていることがあるが、今回それは重要ではないので記載はしない。
SaaS を使っているもの
- VPS
- 固定 IPv4/v6 アドレスが安く、可用性が自宅サーバよりも高いため。
- 自宅に固定アドレスを持ってくることも不可能ではないが、リスクやコストが釣り合わない。複数回線を引いてこられるならアリだが、賃貸だとそれも面倒。
- レジストラ、 DNS
- ドメイン名の取得ついでに DNS もインターネット向けにはそのまま使っている。
- 複数サービスを利用し、止められても全てのドメインが同時に死なないように、そして猶予があれば別レジストラへすぐに移管できるようにしている。とはいえ止められると結構つらいが。
- SimpleLogin
- メールのエイリアスサービス。
- 自分で立てたり手作業でどうにかすることも不可能ではなさそうだが、単なる中継サービスなので楽をするために SaaS を使っている。
- これを止められても DNS 設定を変えることで中継を解除して自前メールサーバ等で受け取れるようにしてある。
- メールサーバ
- 自分で立てたものもあるが、そちらが止まったときに備えて SaaS も使っている。
- 複数サービスを利用し、どちらかを止められても諸々のサービスへのログインが阻害されないよう冗長化している。
- Cloudflare Tunnel
- リバースプロキシのようなもの。ロードバランサでもあるが、そちらは今のところ必要としていない。
- 固定 IP アドレスがなくとも IPv4/v6 両方で外部から名前解決してアクセスできるようになる超便利サービスだが、 HTTPS 通信であっても一旦 Cloudflare 側で終端する都合、通信内容は (認証情報含め) すべて Cloudflare に筒抜けになる。 Cloudflare をどこまで信用するかはさておき、意識しておくべきではある。
- 私の場合、最重要の情報は Cloudflare を通したくないので、 VPN を経由したり IPv6 の非固定アドレスで直接接続しないとアクセスできないようにしてある。
- 一応 self-hosting できる競合実装があるらしいので、そのうち試してみたい。
アプリケーション紹介
自宅と VPS で動かしている具体的なサービスを紹介する。 これが「自宅サーバを何に使っているのか」への直接的な回答になる。
多目的
Redmine
かなり最強の存在。 人生のかなりの部分を管理している。 私が自分用に動かしているサーバアプリケーションで最も有用に感じるものがこれである。
Redmine のコア部分はチケット管理システムだと思っているが、他にも Wiki やら工数管理やらカレンダーやらソフトウェア開発に必要そうな機能がいろいろあり、総合的にはプロジェクト管理のためのソフトウェアということになるだろう。
ところで人生というやつは、目標があり、問題があり、複数の文脈があり、こなすべき作業があり、経緯と状態があり、時として締切がある。 つまりチケットによるプロジェクト管理というやつは、適切に運用すれば割と素朴に人生に適用できるはずなのだ。 脳内に巣喰う無数のタスクを全て計算機に追い出して記憶と記録と管理を任せられるのなら、もちろんそうするのが楽ということになる。
管理されているものの例
未だ正解構成には到達していないが、例として以下のような「プロジェクト」を用意している。 例として挙げるだけなので詳細を確認せずともよいが、タスクに限らず、とにかく状態があり行動や変化のログを記録したくなるようなものは何でも追加しているということが伝われば良い。
- braindump: 脳から一旦吐き出して外界に存在させるべき何か。
- ブログのネタ、勉強メモなどをトピックごとに起票し、所望の形に吐き出すか諦めたらクローズ。
- シリーズ購入管理: 書籍のシリーズなど、購入済のものや新刊の状況を継続的に追跡する必要のあるものを管理する。
- シリーズごとに起票し、完結した全巻を入手するか追うのをやめたらクローズ。
- 人のおすすめ: 人がおすすめしているのを見たもの、またはおすすめされたもの。
- おすすめされたものを実際に堪能するか、あるいはスルーすることに決めたらクローズ。
- 旅行: 日を跨ぐような、あるいはそれに相当する入念な準備や計画が必要になるような長期の外出の管理。
- 個々の旅行ごとにサブプロジェクトを作成する。
- 荷物や手続の準備、行きたい場所やしたい行動などを適宜起票し、準備が完了したり所望の場所に到達したり行動を行ったり諦めたらクローズ。
- 生活: 趣味や娯楽でない方の諸々のタスクを管理する。契約などの管理もする。
- サブプロジェクト「人生の裏」: 非公開の個人情報やプライバシーが主題になるような生活案件。
- サブプロジェクト「住居」: 住居に関連する事項。
- サブプロジェクト「引越202x」: 202x年に行う予定の引越に関連する事項。
- 契約は後述の設備・備品チケットと同じようなステータスで管理できる。
- 設備・備品管理: 言わずもがな。
- 保証期間、保証書、外箱などの管理が必要だったり、手入れや特別な破棄手順が必要ななものについて、入手・利用・破棄の全体を追跡する。
- 設備・備品チケットは他のチケットと少々異なり、以下のようなステータスを持つ。
- 新規: 入手する目処が立った。
- 運用準備: 運用を開始するための作業をしている。
- 運用中: 運用中・稼動中。
- 運用休止中: 一時的に運用をやめている。
- 運用終了準備: 運用終了のための処置や廃棄作業中。
- 運用不可/障害: 故障状態、修理中、紛失などで運用が一時的に不可能な状態。
- 運用終了: 運用終了・廃棄完了。
- これの運用についてはちょっと悩んでいるところもある: バグ #529: [Redmine] 設備・備品管理の方法を再検討 (2024-10) - 人生管理運用 - Nopmine
- 趣味・娯楽: 言わずもがな。
- サブプロジェクト「コンテンツ鑑賞」: 積んでいるアニメ、本、ノベルゲームなど。
- 実はこの用途が一番最初に Redmine を使い始めたときの目的だった。
- サブプロジェクト「人生管理運用」: この Redmine そのものの運用方法に関する思考。
- サブプロジェクト「コンテンツ鑑賞」: 積んでいるアニメ、本、ノベルゲームなど。
タスク管理はつらいのか？
タスク管理システムで労役を思い出してつらくなる人もいるかもしれない。 ひとつここで明確にしておきたいのは、私はこのシステムを「自分の行動を指示させるための行動管理機構」として使っておらず、「なんらかの形で人生に発生する行動や情報を適切な形式で記録できるメモ」として使っているということである。 この文脈で私が「管理」というとき、それは「必要な情報にアクセスしたり更新しやすい状態が維持されている」という意味で言っており、「行動を外部から規定する」という意味で言っていない。 私がリマインダーを見て何らかの行動をするのは、「この時期に確認すべきだと過去の私が思っていたのだからそうなのだろう」と思って今の自分が改めてそうすると決めたからであって、「システムに行動を指示されたからそうしよう」と考えるからではないのである。
私の運用する人生用 Redmine はあくまで「私が何をすべきか今自分で考えるための参考情報が記録された、過去の行動と思考を蓄積したデータベース」であって、決して「将来の自分を規定する計画書」ではなく、ゆえに不備があっても (たとえば期日の入力を忘れても) それ自体が即座に重大な問題になったりなどはしない。 すべての義務的行動は、その行動自体が義務として課せられたゆえに義務なのであって、 Redmine 上にチケットが起票されたゆえに義務になるのではない。 ゆえに Redmine をこの用途で使うこと自体に特段のつらさは感じていないし、感じてしまうならそれはある種の責任転嫁である。
基幹インフラ
CoreDNS
DNS サーバ。 宅内のローカルなドメイン名を解決するために使っている。
自分向けのサービスやサーバは必ずしも全世界に向けて公開すべきとも限らないため、自宅のネットワーク内でのみ名前を解決できるならその方が良い。 そのため一旦宅内の CoreDNS サーバで名前解決を試み、駄目だったときに ISP の DNS などにフォールバックするようにしている。 サーバ群以外のデスクトップ PC や無線端末などは、後述の AdGuard Home を経由して CoreDNS を使うようにしてある。
解決すべき名前と IP アドレス等は、後述の NetBox に登録した情報から自動生成している。
AdGuard Home
ブロックリスト機能などがあり広告ブロックに使える DNS サーバ。 スマートフォン、タブレット、PC、ゲーム機や IoT ガジェット等の、システムの中枢にいないエンドユーザ的な端末から使っている。
広告ブロックの是非についてここでは語らないが、無視できない割合のクエリがブロックされており、かつそれらが少なくとも私が直接認めたり望んだものではなかったという事実は確かに可視化されている。
Step CA
自宅ネットワーク用の HTTPS 証明書発行サーバ。
HTTP 通信が暗号化されておらず盗聴可能であることは周知の事実である。 とはいえ基本的に「信頼できる」ネットワーク内であればこれは問題にならない。
問題になるのはそのようなネットワークが「信頼」できなくなった場合で、たとえばこれは信頼しきれないメーカーの IoT 機器が自宅のネットワークに参加したりとか、強めの権限を持っている仮想マシンがクラックされたりとかである。 このようなリスクは避けられず事故はいつか起きる (しかもしばらくそれに気付けない) ものとして備えるべきで、つまり宅内であっても可能なところは (特にユーザ名とパスワードが行き来するところは) 暗号化しておいて、「信頼」をそもそも最小限しか必要としない仕組みを構築しておくべきということだ。
NetBird
VPN ソリューション。 外出先で携帯端末などから自宅内ネットワークに参加するために、自宅サーバに出口ノードを用意している。
わかる人向けに言うと、 Tailscale の競合で self-hosting をサポートしているのが NetBird である。 私はまだ self-hosting はしていないが。
どうせ裏は WireGuard のようなので、シングルユーザ向けでいいからもうちょっとシンプルなものはないかなと思っている。
NAS
ネットワークストレージ。 日頃利用するデータ、サーバが利用するデータ、過去に作成したものや購入したもの、バックアップなどなど、あらゆるものを溜め込む場所。
自宅のメインで TrueNAS を、自宅のサブと実家で Synology の NAS を使っている。
インフラ管理
NetBox
データセンター管理ソフト。 拠点、ラック、デバイスといった物理的な器具や空間、仮想マシンや IP アドレスや VLAN などといったリソース、また電源や通信線などの配線に至るまで、データセンターで管理する必要のある様々なリソースを一括管理できる。
自宅サーバクラスタを管理していると、設定や意思決定が各所に散っていき、矛盾が生じやすくなる。 たとえば管理が粗雑だと、どこかにあったメモの設定と、管理用のスクリプトが適用しようとする設定と、実際に動いているマシンの設定が、ぜんぶ食い違っているなどということがありうる。 これを防ぐために有用なのが Single Source of Truth という概念で、簡単に言えば、すべての情報を一箇所に綺麗に整理して集約してしまえば、他の場所に置いたものなど全部無視してそもそも矛盾など起きえない状態にできるはずという発想である。 実際にやろうとすると注意深い設計と徹底した自動化が必要なので言うほど簡単なことではないが、目指すだけなら損はない。
NetBox は API アクセスができるので、必要な情報を抜き出して使うようなスクリプトが書きやすい。 たとえば私の場合、 CoreDNS に食わせるドメイン名と IP アドレスのリストなどを NetBox から取得してスクリプトで生成している。
本当はもっといろいろできそうなのだが、インフラ管理の自動化も道半ばなのでとりあえず「何か矛盾があっても最優先の記録場所を確認すれば理想状態は書いてある」という状態になっているだけでも、メモを書き散らかすよりだいぶマシだということでありがたがっている。
Grafana
時系列データなどの可視化ツール。 後述の Prometheus で収集し Thanos に蓄積したメトリクスをグラフ等として可視化できる。
メトリクス (監視対象の状態) 自体はいろいろ収集しているが、ダッシュボードに表示しているのは今のところ自宅全体の消費電力とサーバラックの消費電力、ルータ関係のメトリクス (通信量など) のみである。 昔はコンセントタップ単位の消費電力や温湿度なども監視していたが、機材故障や Bluetooth まわりでの接続品質の悪さなど諸事情あって監視を中断した。
後述するが自宅全体の消費電力の監視には自作の house-exporter を、サーバラックの消費電力やルータの監視は SNMP exporter を使っている。
Prometheus
メトリクスを収集するサーバ。 これ単体では収集したデータの確認程度の基礎的な可視化しかできず、人間向けに見せるには先述の Grafana 等で可視化する。
Grafana のダッシュボードには追加していないが、諸々のサービスのメトリクスも収集だけはしている。
データストアとして後述の Thanos と協調させている。
Thanos
Prometheus で収集したメトリクスを蓄積したり Grafana 等のクライアントへ配信する、 Prometheus 互換な API を提供できるサーバ。
本来は大規模なメトリクス収集のためのものだが、私は単に「長期間データを蓄積できる」という性質だけを求めて使っている。 (一方 Prometheus では一定期間でデータが消えていくような用法が基本になっているらしい。)
データは後述の MinIO サーバに蓄積している。
SNMP exporter
SNMP (Simple Network Management Protocol) というプロトコルでデバイスやサーバからメトリクスを引き出して Prometheus 向けに提供する中継サーバ。
設定の管理や生成が手間なので正直あまり好きではないが、その手間の責任は SNMP exporter のみならず各種デバイス側にある割合も (全てではないが) 多いため、 SNMP exporter 自体については何ともいえない。 面倒ではあるが、なんだかんだで便利なので結局使っている。
house-exporter (自作)
諸々のメトリクスを自力で取得して Prometheus 向けに提供する、自作の中継サーバソフトウェア。
スマートメーター (電力計) から Bルートサービス を使って家庭の電力情報を取得する機能と、 Bluetooth で SwitchBot の温湿度計プラス から温度と湿度を取得する機能がある。 SwitchBot の Plug Mini というスマートプラグから Bluetooth 経由で消費電力情報を取得する機能もあるが、この製品はリコールされており、もちろん (?) 手元の4台も全て早々に壊れたので、今はその機能は使っていない。 もう使うこともないだろう。
スマートメーターとは Wi-SUN という無線規格で通信する必要があり、その上のレイヤーのプロトコルも ECHONET Lite という独自のものになるため、規格と仕様を読みながら最低限の部分を自前で実装した (参考: doc/specs.md · 257cefdbcd2e644d1b06086059411bd5673859ab · NOP Thread / house-exporter · GitLab)。
SwitchBot の温湿度計プラスのメトリクスは BLE (Bluetooth Low Energy) で広報されているためそこまで実装量は必要なかったが、相対湿度から体積湿度を算出するためにちょっとした計算が必要なのでサーバ側でやっている。 ただ、この BLE での通信がかなり頻繁に失敗して原因も解明しきれないため、保守が面倒で今はこの機能を使っていない。 (これを動かしている Raspberry Pi がオープンフレームとはいえ金属製のサーバラックに設置してあるのは間違いなく通信状況を悪化させている一要因ではあるが、それだけではないはず……。)
行動管理補助
Radicale
スケジュールや連絡先 (アドレス帳) などの同期サーバ。
一般的にスマホや PC のスケジュール同期は CalDAV プロトコルや iCalendar 形式のファイルによって、また連絡先の同期は CardDAV プロトコルによって行われる。 Radicale は CalDAV と CardDAV のサーバであり、これらのプロトコルを使うクライアントに情報を提供したり、データの追加・削除・編集を受け付けたりする。
神経質でない人は Google や Apple (あるいは Microsoft？) のアプリとサーバを使ってこういった情報を同期するものと思うが、私はそういった企業のサービスにできるだけ依存しない生活をこころがけているため自前で用意している。 可用性だけ考えれば圧倒的にそういったデカ・テックのサーバの方が安定しているため、このスタイルを他人におすすめすることはないが……これは利便性ではなく思想と実践の問題である。
Tracks
文脈ごとにタスクを分類できる TODO 管理アプリ。
重いタスクや長期間に及ぶタスク、また単純なタスクでないような何かについては先述のとおり Redmine で管理しているが、 Tracks では逆に「未着手」と「完了」しか状態を持たないようなシンプルなタスクを蓄積・消化するのに使う。 つまり「進行中」を気にする必要がなく、遂行に際しての履歴やメモを残す必要もなく、後から思い返すこともないような雑事を管理している。 たとえば「石鹸を買う」とかのチケットを Redmine で定期的に立てては閉じるなどしても (特に一人暮らしでは) 得るものが小さいが、そういったものに Tracks が使いやすい。
「Redmine で hogehoge に関するチケットを立てる」などのようなタスクを立てられるので、その点でも Redmine を補完する存在である。
単なるタスクリストであれば同期されたメモにリストを作って追加や削除をしていくだけでも運用できるにはできるのでクリティカルではないが、やはり当然ながら専用のアプリケーションの方が使い勝手は良い。
検索可能性 (ググラビリティ) の低さが尋常でない名前なのでたまに困る。
情報蓄積、メモ
linkding
シンプルな UI の web ブックマーク管理ソフト。
必要十分な機能の揃った、無難で良いもの。
Shaarli
シンプルな UI の web ブックマーク管理ソフト。
機能や使い勝手に大きな不満はなかったが、データ保存方式が結構ロックでスケーラビリティとか長期間利用となると若干不安要素があったので、 linkding に乗り替えることにした。
BookStack
リッチテキストエディタと markdown エディタどちらも使える Wiki システム。 長期間残す前提の記録などのために立てた。
permalink 機能が使えるのが良いと思って使ってみたが、ページの permalink 取得が一手間必要で面倒だったり、セクションの ID が markdown 編集で維持されなかったりなど、肝心のところで私の望むレベルに達していないところがあるのが悩ましい。 そのうち別実装を試すことになるだろう (これより良いものが見付かるかは不明だが)。
PdfDing
linkding にインスパイアされた、 PDF ドキュメントの蓄積・管理アプリ。 PdfDing 側に PDF ビューア機能と既読管理機能があり、 PC で途中まで読んでスマホで簡単に (記憶を頼りにスクロールなどすることなく) 続きから読むなどの複数デバイスでの利用が便利。
ｲﾝﾀﾈｯﾂで手に入れた文書や電子書籍、取扱説明書などを突っ込んで管理している。 まだスキャナを持っていないためできないが、自炊などした場合にも役立つことだろう。
後述の Paperless-ngx とは用途を分けており、基本的に通して読むもの、あるいは読む必要はないが何かの際に参照したくなるかもしれない文書の管理に使っている。
Paperless-ngx
紙の文書を電子化したものを管理することを主眼に置いたアプリ。 最初から電子データしかないものももちろん管理できる。
こちらは PdfDing と用途を分けており、 PDF データと同時に元となった紙媒体も保管しておく必要のある文書や、領収書、納品書、契約書といった、いざというとき探し出すためにしっかり整理されている必要のある文書に使っている。
ByteStash
スニペット (コード等の断片で、小さく使い回しのききやすいもの) を管理するためのアプリ。 単なるメモよりもソースコード的なものの管理に特化している。
SNS で流れてきた面白いコード片を記録したり、別の端末に設定を流し込むためのデータなどを置いたりするのに使っている。
NocoDB
どう表現したものか難しいが、表のようなものであればそれっぽく管理できるというデータベースのアプリ。
巷では Airtable と競合する自由ソフトウェアなどと言われている。 機能的に釣り合っているかは知らないが、大して使い込んでいない今の時点での感想としては、リッチな RDB (Relational Database) といったところ。
タペストリーの管理をしたくて立ててみたが、手持ちのものの入力が手間なのでどうしたものか……。 応用はききそうなので、諸々の管理における最後の砦として活躍してくれそうだと思っている。
NocoDB がなくとも Wiki などに表を作って管理することは不可能ではないが、その場合スキーマに柔軟性がなく変更に弱く入力も面倒でビューの追加も難しいなど圧倒的に不便なものになるので、使い勝手はネイティブなデータベースに及ぶべくもない。
Monica
人間関係について整理して記録しておけるアプリ。 "Open source personal CRM" (CRM: Customer Relationship Management, 顧客関係管理) を謳っている。
たとえば知り合ったが頻繁に顔を合わせるほどではないような関係の人とか、あるいは友人であってもいつが誕生日であるとか前回会ったとき何をしたとか、そういった人間関係についての記録を整理しておくことができる。 特にハンドルネームから実名を思い出せないときに有用だ。
が、新しく人と知り合うことがない陰キャひきこもり生活を送っているため正直あまり使っていない。 どうせ記憶から溢れるほどの人と関われないので。 ……などといいつつ、同僚の名前を思い出すにも一呼吸必要なくらいには人の情報を覚えるのが苦手なので、やはり念の為ということで立ててある。
ファイル同期
Nextcloud
ファイルの同期と共有をはじめとした様々な機能を「アプリ」として追加できるプラットフォーム。 とはいえ最もベーシックな使い方は Dropbox や OneDrive のようなファイル共有である。
もともとは Dropbox のようなものだったが、「アプリ」を追加できる機能が充実しており、結構なんでもある。 ただし私は過去に Nextcloud のバージョンアップを雑にやって失敗しデータを吹き飛ばしかけた (というか、吹き飛ばしてバックアップからどうにかした) 過去があり、リスクを分散したいので、できるだけ Nextcloud サーバに依存しないインフラ整備をこころがけている。 私が Nextcloud 上で動かしている (ファイル管理と Nextcloud システム自体の関連以外の) アプリは以下の2つだけである。
- PhoneTrack
- 端末等の位置情報を追跡したり、その記録を閲覧できる。
- 遠めの外出や旅行において利用している。
- Notes
- markdown ファイルをメモとして編集・管理できる。
- Notes 上でのメモはそのまま Nextcloud 内に markdown ファイルとして保存される。
- 逆に PC 等から markdown ファイルを編集して同期すると、 Notes 上でも編集がメモに反映されている。
また、 Android のクライアントには写真や動画などを自動で Nextcloud サーバにアップロードしてくれる機能があり、これも活用している。
どうでも良いが、 Google で検索すると公式サイトよりも上位に日本の代理店 (たぶん) が「Nextcloud公式サイト」というタイトルで出てくる () のはどうかと思う。 †公式† サイトでは無償の Community 版への導線もなく、あたかも契約しないとサーバアプリを使えない製品であるかのように案内されているが、そんなことは全くないので諸氏には安心して本物の公式サイトにアクセスしてほしい。
Syncthing
プライベートなファイル同期のためのアプリ。 スマホや PC でファイルを同期できる。 実はサーバを立てずとも使える。
Nextcloud と違うのは、 Nextcloud ではサーバが必須で web UI 上からひととおりのファイル操作 (ファイルやフォルダの作成、削除、閲覧、編集など) や選択的な同期とダウンロードができるのに対して、 Syncthing はまとまった単位での同期に特化しておりビューアやファイル操作機能などがなく、サーバも立てる必要がない点。 敢えてサーバを立てているのは、 Android の Syncthing クライアントに問題があっても同期する端末の追加・削除・設定変更といった基本的な操作が外出先でできるようにしておきたいというのが主な理由。
通信、通知
Mailu
メールサーバを実用的に運用するのに必要なひととおりの機能を備えたソフトウェアパッケージ。 ひとくちにメールサーバといっても実は数多くのコンポーネントがあり、その設定は複雑怪奇、しかも迂闊な設定で動かすとセキュリティに問題を抱えて大惨事になりかねない。 そういった問題に陥らないよう真っ当な設定を web UI 等から管理できるようにしようというもの。
これは VPS 上に立てている (立てざるを得ない) ため自宅サーバではないのだが、一応自前管理ということで紹介する。
メールサーバを自前で持つというのは、商業的な理由での機能制限や追加の課金を受けないということを意味する。
- 無制限の個数のドメインを使える
- 無制限の個数のアカウント (メールアドレス) を使える
- 無制限の個数のエイリアスを使える
- 無制限にメールを送受信できる
- 迷惑メールフィルタのカスタマイズをいくらでもできる
- etc.
ついでに、アプリパスワード (メーラ (MUA) 用に管理画面のログインパスワードとは別のパスワードを発行するセキュリティ機能) に対応しているのも嬉しい。
無論、可用性を非常に高く維持したいとか、迷惑メールとして弾かれては絶対に困るとか、とんでもない大量送信を考えているとか、そういった事情があるなら既存の有償サービスを用いる方が良い。 だが事業で使っているわけでもない個人のメールアドレスにそこまでシビアな要求はないし、どうしてもそこまでシビアな条件が必要になったらそのときは別のメールサービスを併用したって良い。 有償のメールサービスを使っていたとて、待ち望んでいたメールが迷惑判定されて気付かなかったり受信もできず弾かれたりなどといったことはしょっちゅう起きている。 サーバが安定稼動していれば安心というものではないのだ。
つまり自前でメールサーバを持たない理由は保守管理とセキュリティ維持のコストくらいしかない。 保守管理については Docker ベースなこともありアップデートがかなり簡単なので、リリースノートの確認さえしっかりしておけばそうそうハマることはないはずである。 セキュリティについては、 Mailu は既存のメジャーなソフトウェアと独自の管理画面・設定生成ソフトの組み合わせという形で提供されており、後者が安全な設定の生成を担っている。 メール関係のプロトコルに関するコアの部分で独自実装はそこまでしていないはずなので、既に社会的信用のあるソフトウェアの占める割合が多く、それ以外の部分に問題があったとしてもそのソースコードの確認や修正に手を出しやすい。 結果として、すべて自前で設定を詰めて複数のコンポーネントの連携をセットアップするよりも相対的にずっと楽で安全であることが期待できる。 (もちろんメールサーバに限らず、ソフトウェアをどこまで信頼してどこまで疑うかは利用者次第だが。)
Ntfy
汎用の通知サービスのサーバ。 Android クライアントを入れれば Android スマホに「通知」を発することもできるし、同時に PC で通知を受け取ることもできる。 メールとメーラほど重い仕組みは必要ないがいろいろなデバイスで通知は受け取りたいし簡単に通知を送信したいという場合に便利。
スケジュール関係のイベントやサーバ等で発生した障害などの通知で使うつもりで立てたが、いろいろあって今のところメールで済ませがち。 最近またこちらを積極的に使っていくことを検討しているが、どうなるだろうか。
Mattermost
Slack の競合のようなもの。
チャンネルを分けたり通知を受け取ったり bot を動かしたりなどできるため、何らかの自動化と通知、あるいは日記や雑な記録スペースなどに使えないかと思ってとりあえず立てているが、現状では全然使っていない。
bot による自動化については Mattermost に乗せるよりも ActivityPub 経由とかでできる方が面白かったりしないだろうか等の雑念があるため、まだ方針を決めかねているが、 Mattermost はちょっと過剰かなという感覚がある。 単に通知を受け取るだけなら先述の Ntfy で良いしそちらの方が軽量なのだが、たとえば通知に対して特定の絵文字でリアクションを付けると返信扱いにできるなどといった簡単な双方向の交信を視野に入れると、 SNS やチャット系の実装の方が Ntfy では届かないところにまで手が届くのでどうしたものか、といったところ。
日記や生活関係のログについては……そもそも1日1文ですら書かなくなる性質なのでもちろん滞った。
コンテンツ鑑賞記録
BookWyrm
読書管理のシステムに ActivityPub プロトコルでの SNS 機能がついたサービス。 概ね 𝕏 (formerly Twitter) 連携のついた読書メーターからリコメンド系の機能を除外したようなもの。
書誌情報をデータベース系サイトから取得してくる機能もあるのだが、例のごとく日本語圏では使い物にならなかったりするので、読んだ本の情報をいちいち入力していくことになるのは正直それなりに面倒。 そんなに時間はかからないので慣れたが。
あとはノベルゲームも広義ノベルということで、それらも管理している。 オーディオブックがありならノベルゲームもありだろう。
Ryot
アニメや映画の鑑賞やゲームプレイをはじめとした、任意の行動の記録のためのサービス。
私は専らアニメと映画とゲームの記録に使っている。
コンテンツ管理
Navidrome
音楽サーバ。 プレイリスト管理もできるので、どちらかというとそれを目当てに使っている。
昔は PC にローカルに音楽ライブラリを持って MPD (Music Player Daemon) を立てて使っていたが、これだと同期に一手間必要なのと、音楽ライブラリのコピーを PC ごとに持っておく必要があり無駄があった。 特にスマホだと音楽を全て端末に持っておきたくはないが、それでもプレイリストは編集したいことがあった。 (これは外出時にスマホではなく WALKMAN で音楽を聴いていたせいでもある。)
そこで音楽サーバを立てて NAS 上の音楽ライブラリを利用させ、プレイリストもサーバ側で持つことで、同期の手間を解消しつつスマホ等からもプレイリストを編集できるようにした。
そのうちプレイリストをダウンロードしてきて WALKMAN 向けに変換するスクリプトを書こうと思っているが、まだ手をつけていない。
開発
Forgejo
Git サーバに、プロジェクト管理に便利な諸々の機能と web UI を付けたサーバアプリ。 GitHub や GitLab のようなもの。 Gitea の fork であると言えばわかる人にはわかるかもしれない。
私はソフトウェアを書くときは基本的に公開して問題ないように作るのでリポジトリも GitLab や GitHub に投げがちだが、個人的な情報や機微情報を含むようなもの、あるいは自分で作ったわけではないものは公開せず自前インフラ内に抱え込みたい。 そういったものを管理しつつ web UI 等から閲覧できるようにするために Forgejo を使っている。
また、単に秘密にするだけでなく自前インフラの CI (Continuous Integration) (後述の Woodpecker CI) を利用したいリポジトリも置いている。
Woodpecker CI
CI (Continuous Integration) サーバ。 git サーバに push されたコミット等に対して自動でビルドやテスト等を実行して、問題がないか確認するソフトウェア。
GitHub などを見るとコミットにチェックマークが付いていたり×マークが付いていたりするが、あれを判定するためのものである。 ビルドやテストといってもいろいろな環境や設定や確認事項がありうるため、それら複数の構成のビルドやタスクをクリーンな環境ですべて実行してくれるのが便利。 これを開発機でやろうとすると、限られた CPU とメモリ資源で同じ環境を使い回して実行することになりがちなので、効率が悪かったり手間がかかったりする。
実は自宅にサーバを持とうと決めた一番の理由がこの CI サーバである。 確認する設定の組み合わせを十分に増やすと無料で使える枠をすぐに食い尽くしてしまうため、心行くまでテストするには自前で CI インフラを持つしかなかった。 そして CPU もメモリもあればあるだけテストの並列実行数を増やせるので、サーバは多ければ多いほど良い。 CI を走らせていない間は別のことにリソースも使えるし。
SNS
Mastodon
各々が自前でサーバを立てて通信しあうことで成立する SNS プロトコルである ActivityPub の、マイクロブログ系実装のひとつ。 Misskey なども同じ ActivityPub プロトコルに対応しているので、 Misskey のアカウントをフォローすることもできる。
BookWyrm も ActivityPub に対応しているので、たとえば Mastodon 上のアカウントから BookWyrm 上のアカウントをフォローすると、BookWyrm 側で投稿した読んだ本や感想などが Mastodon 側アカウントのタイムライン上に流れてくるようになる。
𝕏 (formerly Twitter) をはじめとするプロプライエタリなサービス (Threads や mixi2 なども含む) に依存したくないので、手元でサーバを動かせる自由ソフトウェア実装ということで使っている。 Bluesky は……主張している特性に実装が追い付いていない印象があるので、規格や思想はさておきメジャーな開発陣への信頼が微妙 (存在しないものを喧伝しないで、実装できてから言ってくれ)。
外部公開用
web サイト
このサイト (waf.nopth.ink) を含むいくつかの静的なウェブサイトも自宅サーバにホストしている。 web ページスペースというやつは基本的に面倒な管理方法を要求されたり機能に制限があったりして面倒だし、かといってわざわざ VPS 上のお高い計算リソースを使うほど可用性が重要でもないので、自宅に立てるのが丁度良い。
Shlink
短縮リンクサービス。
基本的に使っていないが、何か URL を人に口頭や映像で共有したいとき短い方が良いという場合に備えて用意している。
サーバクラスタ内部向け機能
MinIO
Amazon S3 互換のオブジェクトストレージ。 データ (特に多いのは動画や画像等のメディアだがそれに限らない) を保存する先のオンラインストレージとして、いろいろなアプリケーションが対応している。
自宅のありあまる (そんなに余っていないが) ストレージを使えば、転送量課金などを恐れる必要はないし少なからぬ割合の通信が宅内で済むことが多いので、 SaaS を使うよりも経済的である。
Apt-Cacher NG
Debian のパッケージ配布サーバなどのキャッシュプロキシとして使えるサーバ。
宅内に仮想マシンやコンテナを含めて数十もの Debian 環境があり、それらが各々インターネット上のミラーサーバに接続するのはあまり行儀が良くないので、一度キャッシュプロキシを通ったものはそれ以降宅内からリクエストされてもミラーサーバの帯域を使わずに済むようにしている。
CNCF Distribution
Docker レジストリのキャッシュプロキシサーバ。
docker.io のレジストリはレート制限が厳しく、またインターネット側のサービスやインターネット接続自体に問題がある場合でも諸々の Docker を利用したサービスは起動できるようにしておきたいので、宅内でキャッシュしている。
Proxmox Backup Server
Proxmox VE との連携が強力な、バックアップ管理サービス。
優れた差分バックアップや自動的なクリーンアップなどが使えて便利。 Proxmox VE 上で動かしているサーバのバックアップは基本的にこれで十分。
おしまい
紹介パートは良いとして、最後に教訓を再掲しよう。
- VPS を2年以上借りている人は今すぐ自宅にサーバを持つべきである。
- NAS は最初からベイが多いものにしておくべきである。ただし騒音レベルは事前に確認しておくこと。
「サーバをそんなに積んで何に使っているの？」の次は「ストレージをそんなに積んで何を置いてるの？」に答える必要があるかもしれない…… なんでや計算機リソースはあればあるほどいいだろ！ (錯乱)