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

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

2026年5月22日原文(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 JailsBastille の組み合わせで安全かつ効率的なサイト運用を実現
  • 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?)って会社が提供してたのを覚えてるけど、今はただ懐かしい思い出を語ってるだけだね。

Hacker Newsで議論の続きを見る