ハクソク

世界を動かす技術を、日本語で。

10年間Ubuntu 16.04で運営していたブログをFreeBSDに移行しました

4日前原文(crocidb.com)

概要

  • Digital OceanからHetzner VPSへの移行体験談
  • Ubuntu 16.04からFreeBSDへのシステム刷新
  • FreeBSD JailsとBastilleによるサイト分離運用
  • Caddy導入によるSSL自動化と運用効率化
  • サイト移行とベンチマーク結果の紹介

10年越しVPS運用からFreeBSD Jailsへの刷新記録

  • Digital Ocean VPS で10年以上運用していたブログの移行体験
  • Ubuntu 16.04 LTS （5年以上サポート終了）で稼働、セキュリティリスク増大
  • Hetzner VPS （ドイツ拠点）への移行決断、料金半減・性能大幅向上
    • 旧サーバ: 2GB RAM, 1 vCPU, 50GBディスク, 2TB/月トラフィック, $13/月
    • 新サーバ: 4GB RAM, 2 vCPU, 40GBディスク, 20TB/月トラフィック, €6/月
  • サイトは主に 静的サイト、nginxで運用、Hugoで生成
  • 旧VPSは約4年間（1491日）無停止稼働実績

FreeBSD選択の動機と特徴

  • 新しい技術への挑戦 としてFreeBSDを選択
  • FreeBSD Jails ：25年以上前から存在する軽量な仮想化・サンドボックス機能
    • Dockerのような「パッケージ型」ではなく、 サブシステム型 の分離運用
    • システムごとに 独立した環境 を構築可能
  • ZFSファイルシステム 採用
    • Btrfsと比較して成熟度・信頼性が高い
    • 独自でスナップショット・バックアップ運用が可能
  • サイトごとにJailを分離、メインWebサーバ（Caddy）がリバースプロキシとして機能
    • 1つのJailが侵害されても復旧が容易

Hetzner VPSでのFreeBSDセットアップ

  • Hetznerの標準イメージ一覧にはFreeBSDが表示されないが、 ISOイメージ から導入可能
    • FreeBSD公式YouTubeチャンネルのガイドを参考にインストール
    • FreeBSD 14.3-RELEASEを選択
  • Bastille を利用してJailsの管理を効率化
    • pkg install bastilleでインストール
    • bastille createで簡単にJailを作成・管理

FreeBSD JailsとBastilleによるスタック構成

  • CaddyサーバJail ：全サイトのリバースプロキシ・SSL証明書自動管理
    • nginxと異なり、 SSL証明書の自動更新 が標準機能
    • 設定ファイルはホスト側と nullfsマウント で共有・管理
  • 各サイトごとに 独立したJail を構築
    • 必要なビルドツール（例: Hugo）を個別インストール
    • 内部ネットワーク（bastille0）上で通信
  • PF（Packet Filter） によるファイアウォール・NAT・リダイレクト設定
    • 内部Jailからの外部アクセスや、HTTP/HTTPSトラフィックの振り分けを制御

Caddy Jailの構築手順（抜粋）

  • bastille bootstrap 14.3-RELEASEでベースイメージ取得
  • bastille create caddy 14.3-RELEASE 10.0.0.5 bastille0でJail作成
  • bastille console caddyでJail内シェルにアクセス
  • pkg install caddyでCaddyサーバをインストール・起動
  • 設定ファイルのマウント例：
    • bastille mount caddy /usr/local/etc/my-caddy-config /usr/local/etc/caddy nullfs ro 0 0

まとめと今後

  • FreeBSD Jails と Bastille の組み合わせで安全かつ効率的なサイト運用を実現
  • Caddyサーバ によるSSL自動化でメンテナンス負担を大幅軽減
  • サイトごとに 分離された環境 でセキュリティと復旧性を強化
  • 今後は各Jailの運用詳細や、パフォーマンスベンチマークの結果も紹介予定

Hackerたちの意見

実験して学ぶことを恐れない人が大好き！自分はソフトウェアエンジニアリングの正式な教育を受けてないけど（他のエンジニアリングは学んだ）、やってみて失敗することで一番学んだよ。

└

正式な教育では、こういう学び方はあまり重視されないよね。大学のコンピュータサイエンスの授業では、データ構造やアルゴリズム、プログラミング言語、チューリングマシン、有限オートマトンとか、計算可能性との関係に焦点を当てるし。もし大学生でOpenBSDの管理方法とか、自分のブログをホストする方法、VSCodeの使い方を学びたいなら、それは全部課外活動って感じだね。

ちょっと脱線するけど、今サポート期間が一番長い無料のLinuxディストリビューションって何？しばらくCentOS 7を小さいVMで使ってたんだけど、セキュリティアップデートが長い間あったからね。アップデートで壊れるリスクも少なかったし。ちなみに、少し調べた結果、今のところAlma/Rocky Linuxがベストな選択かも。10年のサポートがあるけど、ちゃんとメンテされてるのかな？

└

おそらくDebianかUbuntuだね。で、なんでそんなに気にするの？自分はDebianの安定版（純粋なものと一部バックポートしたもの）やUbuntu（非LTSとLTS）をそのままアップグレードしてきたけど、何年も壊れたことはほとんどないよ。壊れた時は、ググってアップグレードガイドを読まなかった自分を叩いてた。一般的にはアップグレードする前に2～3週間待つことが多いかな。大勢が使い始める前に見逃された問題をキャッチする時間を与えてるんだ。

└

完全に無料がいいならAlmaやRocky、たくさんのマシンがあるならRHELでもいいよ。RHELは登録すれば、登録アカウントごとに10台のマシンが無料でアップデートにアクセスできるからね。RHELは間違いなく最も安定したメジャーディストリビューションだよ。AlmaとRockyは基本的にRHELのダウンストリームクローンだね。

└

Archみたいなローリングリリースを使えば、永遠にサポートされるよ。

└

でも、ちゃんとメンテされてるのかな？AlmaはもうRHELのソース互換性がないから、特権昇格の修正を新しいカーネルアップデートで早く出せる可能性がある。Rockyは、RHELがダウンストリームするまでの間、脆弱性に対する緩和策を提供するためのオプションのセキュリティリポジトリを追加した。最近の出来事から判断する限り、かなりしっかりメンテされてると思うよ。

└

あなたは、ホストしているものがアップグレードサイクルより長く生きないと賭けているんだね。アップグレードが来たとき、たぶん面倒になるから。私は、長い時間の後に大きな変化があるよりも、もっと小さなバージョンアップを頻繁にしたいな。

└

Debian LTS/Extended LTS

└

NixOSが一番いいと思う。リリース間の切り替えが簡単で、異なるリリースのソフトウェアを動かしたり、ロールバックもできるからね。もう10年以上、いくつかのサーバーでNixOSを使ってるけど、再インストールやアップグレード、何の問題もなかったよ。

└

しばらくの間（10年以上）、CentOSをサーバーで使ってたけど、長期の安定性と安心感を求めてたからね。でも、そんな長い期間だとエコシステムのドリフトが大きくなって、アプリケーションを最新の状態に保つのがどんどん難しくなってきた（glibcやpython/Apacheの組み合わせ、GCCなどの「インフラ」パッケージが最新のアプリケーションスタックと徐々に互換性がなくなっていく）。それで、バージョンアップが苦痛だって気づいた。奇妙なパッケージの混乱で自分を変な状況に追い込んでしまっただけじゃなく、アップグレードの道筋がいつも最善を尽くすものだったから。6から7への移行のときに諦めたと思う。必要だったのはFedoraだけだって気づいた。年に1回か半年に1回のアップデートで、ディストリビューションのパッケージと戦う必要がなくなるから、すべてが最新の状態で動いて、メジャーアップグレードもスムーズで、ダウンタイムも最小限。もう「サーバーディストリビューション」に戻るつもりはないよ。

サーバーのニーズでDebian（それからUbuntu）に切り替えたけど、2000年代中頃にFreeBSDに夢中だったのを覚えてる。実際に役立つことをするよりも、設定や構成に時間をかけてたな。BSDを使った専用サーバーやVPSを見つけるのが難しかったから、Panix.comか何かに落ち着いた気がする。それ以前は、NJにあった15MinuteServers（NAC？）って会社が提供してたのを覚えてるけど、今はただ懐かしい思い出を語ってるだけだね。

└

OVHにはFreeBSDのテンプレートがあるよ。ほとんどのKVM VM/VPSプロバイダーは、コンソールアクセスを許可して、好きなISOをマウントしてインストールできる。

自分も同じ状況だよ。古いサーバーが2台あって、放置しすぎちゃったから、今はアップデートするのが怖い。最近のLinuxディストリビューションの年齢確認や証明に関するゴタゴタを見て、完全に手を引こうか考えてる。Artixを試してみたけど、先週再起動したら壊れちゃって（どうやら以前のカーネルアップデートで何かがうまくいかなかったみたい）、リカバリーISOを引っ張り出さなきゃいけなかったから、もう面倒になっちゃった。そこのマシンはDevuanに切り替えたけど、まだ様子見中。大きな不満はないけど、まだ慣らし運転中だよ。:) ノートパソコンではArchを使ってるけど、コミュニティの検閲がちょっと敵対的だから、自由な週末を待って別のものに入れ替えようと思ってる。ソフトウェアに政治的なドラマは要らないからね。面白いタイミングだよ。新しいノートパソコンを買って、Windowsを立ち上げることもせずにLinuxを即インストールしたのは初めて。しかも、すべてが「そのまま動いた」。Linuxを試すのが楽しみなのに、大手がプライバシーを侵害するステップを進めてるのは悲しいね（AIがどこにでも…年齢確認…デフォルトでテレメトリー…）。もう関わりたくないな。

└

私のサーバーやVMは、通常FreeBSDかAlpineを使ってるよ。必要な時にDebianも使うけど（Proxmoxとか、AlpineをサポートしていないVPS、企業のやつとかね）。それから、Chimeraを動かしているテストシステムもいくつかあるけど、あまり頼りすぎるのは安定版が出てからにするつもり。AerynOSでもちょっと実験してるよ。

└

でも、Linuxディストリビューションが年齢確認や証明周りでやってることを見ると… だまされてるよ。

└

参考までに、昔、Ubuntuサーバーを10年間放置してたことがあるんだけど、20分であっさりアップデートできたんだ。そのサーバーは今でも動いてて、最新のLTSになってるよ。最初はUbuntu 4か6から始めた気がするけど、ずっと楽に使えてた。もしかしたら、ゆっくりアップグレードしたおかげで早期採用者の苦労を避けられたのかもね。今はDebianをもっと使ってる。サプライチェーン攻撃が増えてるから、Debian Stableは本当に貴重に感じるよ。もちろん、最新のバージョンが必要なパッケージは別で扱わないといけないけど、昔ながらの無駄のないエンジニアリングの精神が好きなんだ。

└

FreeBSDのサポート期間がもっと長ければいいな。リリースのサポートライフは1年未満で、アップグレードのウィンドウを逃すと、後からのアップグレードがDebian Stableみたいな他のディストリビューションより難しくなるんだよね。

私も16.04を動かしているサーバーがあって、アップデートするのが怖いんだ。今、稼働時間が1281日なんだけど… もう再起動するのが申し訳ない気がする。

└

私の一番古いサーバーは8.04だよ。

└

ddでファイルシステムを別のマシンにコピーして、qemuみたいなエミュレーターで起動して試運転してみて。自動起動するものがあったら注意してね。

自分のサーバーでFreeBSDを試してみたのは楽しかったよ。クールで、クリーンで、シンプルで、ちょっと「パンクロック」な感じがある。でも、主な問題点があって諦めちゃった。 - PM2がFreeBSDでバグってて、プロセス管理に使ってたんだけど - 代替手段としてrc.dを使ってデーモンを動かそうとしたけど、ログをうまく取るのが難しかった。 - ファイアウォールの設定が、セキュリティのベストプラクティスに合わせるのが大変だった（例えば、ICMPはどうするかとか）。UFWのデフォルトが入ったテンプレートみたいなのがあればよかったな。

└
  • PM2はFreeBSDでバグが多かったから、プロセス管理に使ってた。監視のため？ > - rc.dを使ってデーモンを動かす代替案は、ログをうまく取るのがすごく難しかった。Unixのやり方はlogger(1)を使うことだよ。シンプルなメッセージが欲しいだけなら、newsyslog(8)を使ってファイルサイズを管理するためにリダイレクトするのがいい。 > ファイアウォールは、すべてのベストセキュリティプラクティスに従って正しく設定するのに自己設定が多すぎた（つまり、ICMPはどうするの？）。UFWのデフォルトがあるテンプレートがあればよかったな。『The Book of PF』をおすすめするよ。[0]。FreeBSDはOpenBSDのpfとは文法が違うけど、ファイアウォールがどう動くかの理解には十分だと思う。
└

UFWのデフォルトがあるテンプレートがあればよかったな。 FreeBSDにはこれが含まれてるよ！IPFWを使って実装されてる。rc.confのfirewall_typeキーをチェックしてみて：https://cgit.freebsd.org/src/tree/libexec/rc/rc.conf?id=8e08... すごく簡単な単一マシン用ファイアウォールなら、firewall_type=clientかfirewall_type=workstationを設定すればいいよ。後者の場合、firewall_myservicesとfirewall_allowservicesでどのポートが有効か、誰（他のネットワーク/IP）がアクセスできるかを制御するんだ。すごくシンプルなNATゲートウェイなら、firewall_type=simpleにして、firewall_simple_(iif|inet|oif|onet)(_ipv6)?でISP側と内部側のインターフェース名やIPv4、IPv6のネットワーク範囲を設定すればいい。もっと詳しいことや各オプションが実際に何をするのかを知りたいなら、これが実装されてる/etc/rc.firewallをチェックしてみて：https://cgit.freebsd.org/src/tree/libexec/rc/rc.firewall?id=...

└

pm2は、OSに関係なく使うたびにバグがあった。最初はすごく便利なんだけど、同時に使いづらいソフトウェアだよ。デプロイ時に環境変数を更新するのは、一度も意図通りに動いたことがない。

個人的には、ほとんどの個人用や趣味の使用でDockerの前にCaddyを使ってる。普通のウェブサイトなら、Caddyにコンテンツを直接提供させるし… 「ウェブアプリ」なら、ほとんどのものをコンテナ化して、CaddyをTLS終端やDockerで動いているアプリへのリバースプロキシとして使ってる。大体は~/apps/appnameで、各appnameにはdocker-composeファイルがあって、データディレクトリがappnameの下にマウントされてる。コンポーズをダウンして、データをハードアーカイブ用に（s）ftpで出したり、サイトやサービスを移動させたりできる。専用サーバーでいくつかのVMを動かしてたけど、OVHの別々のVPSに切り替えた。OVHの唯一の注意点は、メールを運用したいなら、メールホスティングを許可していないローカルゾーンのVMを避けることだね。人によって違うかも。

└

これが私のやり方に近いかな。DebianからFlatcarみたいなコンテナファーストの不変システム/OSに切り替えようか考えてる。FreeBSDには興味深い技術的なメリットがあると思うけど、好き嫌いに関わらず、Dockerは多くのオープンソースソフトウェアのデフォルトになってるし、FreeBSDのジェイルにすべてを移行する時間も気力もないんだよね。

└

私のホームセットアップもこんな感じだけど、コンテナを動かしてるのはUnraidで、その中の一つは他のサービスのリバースプロキシ用に特化したnginxのやつだよ。

一番の失敗は、長い稼働時間だった。arjie.comはHetznerのVPSで10年以上稼働してたから、マシンをサンセットしようとしたときには、ティーンエイジャーの自分が何を設定したのか全く分からなかった。バックアップはあるけど、サイトは10年間も動いてない…最近は、動くように物を作るようにしてるし、ちょっといじったから、ちゃんと動くのは分かってる。

└

確かに、VMにとっては高い稼働率はあまり意味がないよね。再起動は数秒で終わるし、アップグレードもダウンタイムなしで、DNSを新しいインスタンスに切り替えるだけで済むから。物理マシンの場合は、簡単にコピーできないから話が変わるけど。

└

大きなAnsibleプレイブックのリポジトリに物を入れ始めたよ。完全にAnsibleに管理させる必要はないし、基本的にはセットアップをそこで設定してる。手作業で管理することもまだたくさんあるけどね。

└

「私が犯した最大のミスは高い稼働率だった」その通り。機械の稼働率が名誉の証だった時代を覚えてるよ。でも、年を取ってあまり賢くなってない今は、サービスの稼働率を重視してる。昔も似たようなことはあったから、MXやその類のDNSレコードが存在する理由もわかる。昔のクラスターはかなりエソテリックだったけど、教訓は得られたし（スプリットブレインとかね）、だからこそ今でも子供たちと、なぜ2ノードのProxmoxクラスターがダメなのか、追加の「ウィットネス」を推奨する理由を議論してる。VMwareが数年前に2ノードのHAクラスターの問題を大雑把に扱ったことは気にしないよ。彼らは当時間違ってたし、今も多分間違ってる。あのナンセンスはまだ根付いてるだろうから。ちょっと脱線しちゃったけど、高い稼働率はパッチ適用なしを意味するよね。みんなパッチ適用が好きだし。

└

これ、日本の伊勢神宮を思い出させるな。20年ごとに完全に解体して再建されるんだよね。最近Dan Wangの『Breakneck』を読んだから、これが頭に浮かんだ。彼は、この再建の習慣が、時間と共に失われるはずだった知識を保存するって主張してる。伊勢神宮とノートルダムを対比させていて、ノートルダムの屋根を再建するのはかなり難しいらしい、知識の喪失も一因かもしれないね。どちらの構造物にも詳しくないから、これが公平な比較かどうかは判断できないけど、この原則は好きだな。（追記: これは本の中のちょっとした比喩で、全体的にはすごくおすすめだよ。）

└

時々、個人プロジェクトのためにアーキテクチャ決定記録を残すことがあるんだ。ちょっとバカみたいだけど、意外と役に立つことが多いんだよね。

初めて誰かにDockerを説明されたとき、「ああ、ジェイルのこと？」って言ったのを覚えてる。でも、記事が説明してるようにはちょっと違うんだよね。:) kqueueも大きな勝利だった。FreeBSDの開発者たちには本当に感謝してる。15年間、FreeBSDで初めての会社を運営して、素晴らしい稼働率と耐障害性を得たよ。

おお、すごいね。数週間前に同じことをやったよ。サーバーは2015年から更新されてなくて、その時のGhostでブログを運営して、node 0.10がインストールされてた。私のやり方はちょっと荒っぽかったけどね。バックアップを取ってから、Hermesエージェント（Gemini 3.1 Pro）を放ったんだ。必要なものをすべてアップグレードして、パッチを当てて、最新の同等品にすべてを移行した。その後、サーバーの強化をかなり行って、使ってないサービスのデブロートもしたよ。AIのサポートがなかったら、これを先延ばしにしてたかもね。

└

AIなしでも簡単にアップデートできるよ。ただ、何か壊れるリスクがあるのが問題で、それをバックアップが軽減してくれるんだ。