Ubuntu 16.04で10年間運用していたブログをFreeBSDへ移行

(crocidb.com)

1 ポイント投稿者 GN⁺ 3 시간 전 | 1件のコメント | WhatsAppで共有

Ubuntu 16.04 LTS ベースの DigitalOcean VPS はサポート終了とセキュリティ負担を抱えていたが、終了時点まで1491日のアップタイムを維持していた
新サーバーはドイツの Hetzner VPS と FreeBSD 14.3 へ移行し、従来の月額13ドルのサーバーより高性能な構成を月額6ユーロ未満で利用している
Jails と Bastille によりサイトごとの分離環境を構築し、Caddy Jail が SSL とリバースプロキシを担当して各 nginx Jail へ転送する
負荷テストでは、新しい FreeBSD サーバーは 10,000 同時接続向けに kern.ipc.somaxconn を調整した後、リクエスト処理量が 3〜11 倍高い結果となった
移行には ネットワーキング と FreeBSD 設定の学習が必要だったが、設定の一元化とドキュメント品質のおかげで、想定より簡単に構成できた

移行の背景

既存のブログは DigitalOcean VPS で10年以上運用されており、ニューヨークのデータセンターにある Ubuntu 16.04 LTS を使っていた
- Ubuntu 16.04 LTS は少なくとも5年前からサポート終了状態で、apt パッケージリポジトリの更新も受けられなかった
- 古いシステムはセキュリティ上不利で、過去には別の WordPress ブログが古い VPS 上でカジノ・ギャンブルリンク挿入攻撃を受けたことがあった
既存サーバーはブログ以外にもいくつかのサイトを配信していたが、その大半は 静的サイト だった
- 最も人気のあるブログでも通常は月に数千ページビュー程度で、Hacker News でいくつかの記事がバズった場合を除けばトラフィックは多くなかった
- サーバーは nginx/1.10.3 で静的ファイルを配信し、サイトごとの設定は /etc/nginx/sites-available に置かれていた
- ブログは Hugo で生成されており、従来のデプロイ手順はローカルで執筆 → リポジトリへコミット・プッシュ → サーバーへ SSH 接続 → リポジトリを pull → hugo 実行という流れだった
既存 VPS は当初テストやプログラミング用途にも使われていたため、古いソフトウェアが多く残っていた
- それでも正常に動作しており、終了時点の アップタイムは1491日、約4年間再起動なしで運用されていた
新サーバーはドイツの Hetzner VPS へ移し、従来より高性能でありながら月額費用は半分以下になった
- 従来の DigitalOcean サーバーは RAM 2GB、vCPU 1個、ディスク 50GB、月間トラフィック 2TB、月額13ドルだった
- Hetzner の最安サーバーでも従来よりメモリと CPU が2倍で、ストレージはやや少ないもののトラフィックは10倍だった
- 最終的に選んだ Hetzner 構成は、月額6ユーロ未満でさらに強力なスペックだった

FreeBSD を選んだ理由

FreeBSD は、新しいシステムを実運用環境で試してみたくて選ばれた
- 統合設計、安定性、セキュリティ、Jails が利点として挙げられる
Jails は FreeBSD に25年以上含まれている仮想化・コンテナ化機能である
- ホストシステムへアクセスできない「ミニシステム」をサンドボックスのように動かせる
- Docker のようなコンテナソリューションがプログラムのパッケージング向きで、一時的・不変的な性格を持つのに対し、Jails は同じカーネルを共有するサブシステムやミニ VM に近いものとして扱える
ZFS もサーバー向けファイルシステムとして魅力的な選択肢だった
- データ完全性とスナップショット機能があり、Linux 側の Btrfs と似た面がある
- ZFS は Btrfs よりはるかに成熟していると評価されており、頻繁にスナップショットを取れば VPS 事業者の有料スナップショット・バックアップシステムへの依存を減らせる
目標とした構成は、各サイトごとに1つの Jail を置き、それぞれの Jail に必要なビルドツールと nginx を入れる方式だった
- メイン Web サーバー用の Jail は外部と接続するリバースプロキシを担当する
- 特定の Jail が侵害された場合、その Jail を削除して新しく作り直せる構造を意図していた

FreeBSD のインストールと Bastille の導入

Hetzner の VM 作成画面では標準 OS イメージが限られており、BSD はすぐには表示されなかった
- FreeBSD 公式 YouTube チャンネルの Hetzner インストール動画を参考にした
- Hetzner は FreeBSD の ISO イメージを提供しているが、VM 作成後にコンソールの ISO Images タブでマウントする必要があった
- インストールには FreeBSD 14.3 ISO を使用し、公式動画の手順に沿ってシステムを構成した
Bastille は Jails 管理を簡単にするために選ばれた
- 手動で Jail を作成するのに必要な複数の手順を bastille コマンドで処理できる
- 例として bastille list、bastille create、bastille console などがある
- インストールと有効化は Bastille 入門ドキュメントに従って行った

pkg install bastille
sysrc bastille_enable="YES"

ネットワークとリバースプロキシ構成

全体スタックは、1つの Caddy Jail がすべてのドメインと SSL 証明書を処理し、サイトごとの Jail へトラフィックをリバースプロキシする構成である
- 各サイト Jail には、そのサイトをビルドして配信するのに必要なツールだけを含める
- 同じネットワーク内の複数の仮想マシンに近い構造と見なせる
内部仮想ネットワークインターフェースは bastille0 として作成した

sudo sysrc cloned_interfaces+="lo1"
sudo sysrc ifconfig_lo1_name="bastille0"
sudo service netif cloneup
sudo sysrc ifconfig_bastille0="inet 10.0.0.1 netmask 255.255.255.0"

ループバックインターフェースを複製して bastille0 という名前を付け、10.0.0.1/24 ネットワークを割り当てた
Jail はこのネットワークインターフェース上で動作する
外部からの HTTP・HTTPS リクエストは PF(Packet Filter) ルールで Caddy Jail に転送される
- /etc/pf.conf には外部インターフェース vtnet0、内部インターフェース bastille0、tailscale1 が設定されていた
- 80、443 番ポートのトラフィックは Caddy サーバーとなる 10.0.0.5 へリダイレクトされる

ext_if = "vtnet0"
int_if = "bastille0"
vpn_if = "tailscale1"
set skip on $int_if
set skip on $vpn_if
nat on $ext_if from 10.0.0.0/24 to any -> ($ext_if)
rdr pass on $ext_if proto tcp from any to any port {80, 443} -> 10.0.0.5
block all
pass out quick on $ext_if keep state

PF とゲートウェイは次のコマンドで有効化した

sysrc pf_enable="YES"
service pf start
sysrc gateway_enable="YES"

Caddy とサイトごとの Jail 構成

既存サーバーでは nginx を長年使っていたが、新構成では SSL 証明書管理を自動化するため Caddy を選んだ
- 従来の nginx 環境では certbot で証明書を定期更新する必要があり、更新を逃したことが何度もあった
Caddy Jail を作成する前に、FreeBSD リリースを Bastille にブートストラップした

bastille bootstrap 14.3-RELEASE

Caddy Jail は 10.0.0.5 の IP で作成した

bastille create caddy 14.3-RELEASE 10.0.0.5 bastille0
bastille start caddy

Jail 名は caddy、リリースは 14.3-RELEASE、インターフェースは bastille0 である
bastille list で実行状態を確認でき、bastille console caddy で Jail 内のシェルに入れる
Caddy のインストールとサービス有効化は Jail 内で行った

pkg install caddy
sysrc caddy_enable="YES"
service caddy start

Caddy の設定ファイルは Jail 内の /usr/local/etc/caddy/Caddyfile にある
- ホスト側から設定ファイルを管理するため、ホストディレクトリを Jail 内へマウントできる
- 例では nullfs と読み取り専用 ro オプションでマウントし、Caddy が設定を変更できないようにしている

bastille mount caddy /usr/local/etc/my-caddy-config /usr/local/etc/caddy nullfs ro 0 0

サイトとブログのデプロイ

最初のデプロイ対象は es.cro.to で、サイトリポジトリは GitHub リポジトリで管理されている
- ホストの /usr/local/www/escroto にリポジトリを置き、サイト Jail にはそのディレクトリを読み取り専用でマウントした
- すべてのサイトはホストの /usr/local/www 配下に置く方針で整理した
escroto Jail は nginx Bastille テンプレートで作成した

bastille bootstrap https://github.com/bastillebsd/templates
bastille create escroto 14.3-RELEASE 10.0.0.11 bastille0
bastille template escroto www/nginx

IP は 10.0.0.11 に指定した
nginx のデフォルトページは FreeBSD の慣例どおり /usr/local/www/nginx から配信される
ホストのサイトディレクトリは Jail に読み取り専用でマウントされた

bastille mount escroto /usr/local/www/escroto /usr/local/www/escroto nullfs ro 0 0

リポジトリの .git ディレクトリが Web 公開されないよう、デプロイスクリプトを使用した

rm -fr /usr/local/www/nginx/*
cp -R /usr/local/www/escroto/* /usr/local/www/nginx/
rm -fr /usr/local/www/nginx/.git

新バージョンのデプロイは、ホストでリポジトリを更新した後に Jail 内のデプロイスクリプトを実行する方式である

cd /usr/local/www/escroto
git pull
bastille cmd escroto /root/deploy.sh

Caddy 設定では cro.to を es.cro.to へ恒久的にリダイレクトし、es.cro.to を 10.0.0.11 にプロキシしている

cro.to {
    redir https://es.cro.to{uri} permanent
}
es.cro.to {
    reverse_proxy 10.0.0.11
}

ブログは Hugo を使用し、GitHub リポジトリで管理されている
- リポジトリはホストの /usr/local/www/blog にクローンされた
- blog Jail は escroto と同様に作成され、IP は 10.0.0.12 に指定された

bastille create blog 14.3-RELEASE 10.0.0.12 bastille0
bastille template blog www/nginx
bastille mount blog /usr/local/www/blog /usr/local/www/blog nullfs ro 0 0

Hugo は blog Jail 内にインストールした

bastille pkg blog update
bastille pkg blog install gohugo

ブログのデプロイスクリプトは nginx の Web ルートを空にし、Hugo の出力を /usr/local/www/nginx に生成する

rm -fr /usr/local/www/nginx/*
cd /usr/local/www/blog
hugo -d /usr/local/www/nginx

DNS を切り替える前は、既存ドメインの代わりに crocidb.cro.to を新しいブログサーバーへ向けてテストした

crocidb.cro.to {
    reverse_proxy 10.0.0.12
}

ベンチマークと負荷テスト

DNS レコードを変更する前に、既存サーバー crocidb.com と新サーバー crocidb.cro.to の負荷処理能力を比較した
- ブログ訪問者は主に北米、次いで欧州と南米から来るため、新しいドイツサーバーでは一部ユーザーのレイテンシが少し長くなる可能性があった
- 主な関心は、静的サイト配信の速さと大きな負荷への耐性だった
GTMetrix、Pingdom、WebPageTest などの無料オンラインツールも使ったが、両サーバーの差はほとんどレイテンシ程度だった
HTTP 負荷ベンチマークツールとして wrk と hey を使った
- 両ツールは大量の同時リクエストを生成し、リクエストレイテンシ、エラーレスポンス、1秒あたりの転送量などを収集する
同じ Hetzner 上の別 VPS から wrk を実行したところ、新サーバーが大きく上回った

wrk -t4 -c100 -d30s --latency https://crocidb.com/

オプションは 4 スレッド、100 同時接続、30 秒実行だった
旧サーバーは平均レイテンシ 89.63ms、毎秒リクエスト数 833.41、転送量 8.29MB/s だった
新サーバーは平均レイテンシ 6.75ms、毎秒リクエスト数 12260.10、転送量 130.80MB/s だった
テストマシンが新サーバーと同じデータセンターにあったため、公平な比較ではなかった
Proton VPN を使って複数地域から wrk を回す方法も試したが、結果は期待ほど良くなかった
- 旧サーバー平均は毎秒約 300 リクエスト、新サーバー平均は毎秒約 800 リクエストだった
- 最終的には一般向け VPN の代わりに、複数地域の実際の VPS を用意する方式へ切り替えた

Vultr VPS を使った地域別テスト

サーバーを置いている DigitalOcean・Hetzner と異なるインフラを使うため、Vultr が選ばれた
- 地域は手作業の負担を考慮し、London、São Paulo、Silicon Valley、Tokyo の4か所に絞った
- 各地域で最安の Fedora VM を作成し、テストを実行した
最終テストツールとしては hey の方が適していると判断した

./hey_linux_amd64 -n 1000000 -c 10000 -t 10 -z 5m -h2 https://crocidb.com/ > crocidb.com.log
./hey_linux_amd64 -n 1000000 -c 10000 -t 10 -z 5m -h2 https://crocidb.cro.to/ > crocidb.cro.to.log

設定は合計 1,000,000 リクエスト、同時リクエスト 10,000、タイムアウト 10 秒、総実行時間 5 分、HTTP/2 使用だった
現実的なブログトラフィックを大きく超える負荷だった
初回実行では、新しい FreeBSD サーバーは 10,000 同時接続 に耐えられず序盤で失敗した
- netstat -Lan でソケットキューサイズを確認すると、すべて 128 になっていた
- 既定値 kern.ipc.somaxconn が 128 だったため、次のように引き上げた

sysctl kern.ipc.somaxconn=16384

São Paulo のテストでは両サーバーとも相当数のエラーを返したが、FreeBSD サーバーは想定した 1,000,000 リクエストに対応し、Ubuntu サーバーは 20,000 リクエストすら返せなかった
- 旧 Ubuntu サーバーは全体リクエストの約 7% しか完了しなかった
- 新 FreeBSD サーバーは約 94% を完了した
- Tokyo では新サーバーの成功率がやや低かったが、大きく懸念するほどではないと判断した
毎秒リクエスト数ベースで、新サーバーは旧サーバーより最低 3倍、最大 11倍 優れていた
- レイテンシのパーセンタイルでは、新サーバーは約 90% 地点までより線形に増加し、予測しやすかった
- 高負荷下でも、世界のほとんどの地域でブログのメインページ内容を 3.5秒未満 で取得できる結果だった
Tokyo の結果は深く分析していない
- hey のリクエスト段階別分析では、日本向けトラフィックがより遅い可能性が示された
- 2つ目のドメインの DNS dial-up・lookup 値が異常に低く見え、CNAME レコードの影響の可能性があった
- resp wait と resp read の値も不自然に高かったが、成功したリクエストのみを集計していたため、旧サーバーが序盤に素早く応答した後は新規リクエストを事実上さばけなくなっていた可能性がある

最終移行と主な教訓

ベンチマークでは答えられない点も多かったが、結果に満足して DNS レコードを新サーバーへ切り替えた
- このブログは以後、FreeBSD ベースの Hetzner サーバーで正式運用されている
FreeBSD でサイトホスティング用マシンを構成する作業は、何時間もの試行、修正、ビルド、失敗を経たが、想像していたほど複雑ではなかった
- 要件を満たす Web ホスティングサービスを使う選択肢もあり、例として OpenBSD Amsterdam が挙げられている
- Proxmox によるコンテナと管理ダッシュボードの利用も可能だった
- FreeBSD 側の代替案として Sylve も言及されている
- 自力で構築する道を選んだことで多くを学べたため、満足のいく選択だった
既存の Ubuntu サーバー も非常に堅牢だった
- 10年間にわたりサイト負荷をよく処理し、最後の4年間は再起動なしで稼働した
- 設定に大きな労力をかけなくても安定して動いていた
FreeBSD の設定 は予想以上に容易で、システム設定を1か所に集約する方式とオンラインドキュメントの質が優れていた
自分でブログホスティング用マシンを構築するには、ゲーム開発者が通常知っている範囲を超える ネットワーキング知識 が必要だった
- 異なるシステムを学ぶ過程は楽しく、次は OpenBSD や NetBSD を試してみるかもしれない
- ブログトラフィックの大半が AI システムのクローリング由来であることを考えると、この一連の作業の実用性は限定的だと締めくくられている

1件のコメント

GN⁺ 3 시간 전

Hacker Newsのコメント

私が犯した最大のミスは 高い稼働時間 だった
arjie.com が Hetzner VPS 上で 10年以上動き続けていたせいで、Hetzner がその基盤マシンを停止しようとしたとき、10代の頃の自分が何を設定していたのかまったく分からなかった
バックアップはあるが、サイトはもう10年間ダウンしたままだ
今は移動できるように作って、実際に何度か移して動作確認するようにしている
- 「最大のミスは高い稼働時間」というのはその通りだ
  昔はマシンの稼働時間が名誉の勲章のように扱われていた時代も覚えている
  年を取っただけで特に賢くなったわけではないが、今は サービス稼働時間 を見るようにしている
  昔から MX のような DNS レコードはその目的に近かったし、古いクラスタはかなり難解だったが、split brain のような教訓が残ったおかげで、今でも Proxmox の 2ノードクラスタがなぜ壊れるのか、なぜ追加の witness が推奨されるのかを説明し続けることになる
  VMware が昔 2ノード HA クラスタの問題を大きな応急処置で覆い隠したのも間違っていたし、その方式がまだ残っているなら今でも間違っている可能性が高い
  高い稼働時間はパッチを当てていないという意味であり、パッチ当てはみんな大好きだからね
- 日本の 伊勢神宮 を思い出す
  20年ごとに完全に解体して建て直すが、最近読んだ Dan Wang の Breakneck では、こうした再建の慣行が時とともに失われる知識を保存すると説明していた
  Wang は伊勢神宮と Notre Dame を対比していて、Notre Dame の屋根の再建がかなり難しい理由の一つは知識の喪失かもしれないと見ている
  その二つの建築物に十分詳しいわけではないので公平な比較かは分からないが、原則そのものは気に入っている
  本の中では小さな比喩にすぎないが、全体としてとてもおすすめだ
- VM での 高い稼働時間 にはあまり意味がない
  再起動は数秒で終わるし、アップグレードも新しいインスタンスに DNS を切り替えるだけで無停止で可能だ
  簡単に複製できない物理マシンは話が別だ
- 大きな Ansible プレイブックのリポジトリ に設定を入れ始めた
  すべてを Ansible で完全管理する必要はなく、主に初期設定だけをそこに置いていて、今でも手作業で管理していることが多い
- 個人プロジェクトでも時々 Architectural Decision Records を残している
  少し大げさに感じるが、思ったより頻繁に役に立つ
個人用/趣味用はだいたい Caddy フロント + Docker Compose の組み合わせで運用している
単純なウェブサイトなら Caddy がコンテンツを直接配信し、「ウェブアプリ」ならほぼ全部をコンテナ化して、Caddy が TLS 終端と Docker 配下のアプリへのリバースプロキシを担当する
たいてい ~/apps/appname という構成で、各アプリのディレクトリに Docker Compose ファイルとマウントされたデータディレクトリを置いている
compose down のあと (s)ftp でデータを取り出して長期保管したり、サイト/サービスを移したりできる
一時期は専用サーバーで複数の VM を回していたが OVH の個別 VPS に移し、OVH でメールを動かすならメールホスティングを許可しない local zone VM は避ける必要がある
環境によって違うかもしれない
- あるプロジェクトで Traefik を使い始めたが、nginx proxy manager より良いアップグレードだった
  NPM も素晴らしいし Web GUI も悪くないが、Traefik は Docker Compose ファイルに望む動作を書くだけで済む
- 私のホーム環境も似たようなものだ
  ただし Unraid がコンテナを動かしていて、そのうちの一つが他のサービスをリバースプロキシするよう設計された nginx 系のツールだ
- 私もほぼ同じやり方だ
  Debian から Flatcar のようなコンテナ優先で不変なシステム/OS に切り替えるか考えている
  FreeBSD には興味深い技術的利点があるが、好き嫌いは別として多くのオープンソースソフトウェアの前提は Docker であり、全部を FreeBSD jail に移す時間もやる気もない
数週間前に私も同じことをした
サーバーは 2015年ごろから更新されておらず、その時代の Ghost ブログと node 0.10 が入っていた
私はもっと荒っぽく処理して、バックアップだけ取ったあと Hermes エージェント（Gemini 3.1 Pro）に任せた
必要なアップグレードとパッチを全部当てて、最新の対応項目への移行まで進めた
その後、サーバーの強化や不要サービスの削除もかなり進み、AI支援 がなければたぶん先延ばしし続けていたと思う
- AI なしでもアップデート自体はとても簡単にできる
  本当の問題は何かが壊れるリスクで、それは バックアップ が和らげてくれる
個人サーバーで FreeBSD を使ったのは楽しかった
何かクールで、クリーンで、シンプルで、「パンクロック」っぽい感じがあった
でも主な痛点のせいでやめた。PM2 が FreeBSD でバグっていてプロセス管理に使っていたこと、代わりに rc.d でデーモンを動かそうとしたがログ設定が難しすぎたこと、ファイアウォールは ICMP をどう扱うかのようなセキュリティのベストプラクティスまで合わせようとすると自分で設定すべきことが多すぎて、UFW のデフォルトのようなテンプレートが恋しかったことだ
- FreeBSD にもそういうデフォルトテンプレートは含まれている
  PF ではなく 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 を supervision 用に使っていたのか気になる
  rc.d デーモンのログは、Unix 流に単純なメッセージなら logger(1) を使い、ファイルへリダイレクトしたうえで newsyslog(8) にサイズ管理させればよい
  ファイアウォールについては The Book of PF[0] を勧めたい
  FreeBSD の PF は OpenBSD の pf と構文差があるが、ファイアウォールがどう動くかの感覚をつかみ、どんなルールを書くべきか理解するには十分だ
  [0]: https://nostarch.com/book-of-pf-4e
- PM2 はどの OS で使っても常にバグがあった
  最初はすごく便利だが、同時に使っていて不快なソフトウェアでもあり、デプロイ時の 環境変数の更新 が意図通りに動いたことは一度もなかった
- 私の主な痛点は停電後に踏ん張れないことだった
  電源が落ちると、再起動後にファイルシステムを手動で fsck するよう求められる
少し話は違うが、今 サポート期間 が最も長い無料の Linux ディストリビューションは何なのか気になる
しばらく小さな VM には CentOS 7 を使っていたが、セキュリティアップデートが非常に長く提供され、アップデートで何かが壊れるリスクも最小だった
少し調べた感じでは、今は Alma/Rocky Linux が最もよさそうで、10年サポートが提供されている
ただ、ちゃんと保守されているのかは気になる
- 私も 10年以上、長期的な安定性と心の平穏を期待してサーバーで CentOS を動かしていた
  だがそんなに長い期間が経つとエコシステムは大きく drift し、OS の上でアプリケーションを最新の状態で動かし続けるのがどんどん難しくなる
  glibc、Python/Apache の組み合わせ、GCC のようなインフラパッケージが、最新のアプリケーションスタックと徐々に噛み合わなくなる
  その後のバージョンアップも苦痛だった。変なパッケージの混在で自分を袋小路に追い込んだからだけでなく、アップグレード経路自体が常にベストエフォート程度だったからだ
  6 から 7 への移行で諦めた気がするし、結局自分に必要だったのは Fedora だったと気づいた
  1年または半年ごとの更新ならディストリビューションのパッケージと戦う必要がなく、構成は最新に保たれて動作し、メジャーディストリビューションのアップグレードもスムーズで、ダウンタイムも最小だ
  もう二度と「サーバーディストリビューション」には戻る気がない
- Alma はもう RHEL ソース互換ではないので、少し余地がある
  例えば 権限昇格の脆弱性 を修正するカーネルアップデートをより早く出せる
  Rocky は RHEL から下りてくるのを待つ間、エクスプロイト緩和を提供するオプションのセキュリティリポジトリで対応していた
  最近の出来事だけ見れば、どちらもかなりよく保守されているように見える
- 個人サーバーで ローリングリリースのディストリ を使わない理由がよく分からない
  すべてのサービスはコンテナで動かし、ベース OS は必要なだけ頻繁に自動更新させればよい
  私は openSUSE MicroOS を選び、ほぼ毎日更新と再起動をしているので、サーバーが健全だとかなり自信を持てる
  原子的アップデートなので、何か壊れてもすぐ対処したくなければ Cockpit のロールバックボタンを押して、時間があるときに見ればよい
- ホスティングしているものがアップグレードサイクルより長生きしない方に賭けているわけだ
  結局アップグレードが来たとき、かなり痛い目に遭う可能性が高い
  長い時間の後にすべてが変わった状態で大ジャンプするより、小さなバージョンジャンプを頻繁に行う方がいいと思う
- 完全無料が欲しい、あるいは台数が多いなら Alma と Rocky が合っている
  Red Hat に登録してもよければ RHEL もあり、登録アカウントごとに 10台までアップデートへのアクセスを無料で提供している
  RHEL は間違いなく主要ディストリビューションの中で最も安定しており、Alma と Rocky は本質的に RHEL のダウンストリームクローンだ
私も同じ船に乗っている
「あまりにも」長く放置した古いサーバーが2台あり、今では更新しようと触るのが怖い
ただ、Linux ディストリが年齢確認/証明まわりでやっている騒動を見ると、いっそ離れようかとも思っている
Artix も試したが、先週の再起動後に壊れ、前回のカーネルアップデートで何か問題が起きていたようで rescue ISO まで持ち出す羽目になった
そこでその機材は Devuan に替えたが、まだ判断保留だ
大きな不満はないが、まだ burn-in の段階だ
ノートPCには Arch を入れているが、コミュニティが検閲問題で少し敵対的に感じられ、週末に時間ができたら消して別のものを入れようと思っている
ソフトウェアに 政治的ドラマ は求めていない
興味深いことに、今回は新しいノートPCを買って Windows を一度も起動せず、そのまま Linux を入れた最初のケースで、すべてが「ただ動いた」
これから Linux を楽しもうというタイミングで、大手プレイヤーたちが AI everywhere、年齢証明/確認、デフォルト有効のテレメトリのようなプライバシー侵食の段階を受け入れているのは悲しい
そういう方面との関わりはただ「nope」でいくつもりだ
- 昔 Ubuntu サーバーを10年放置していたのに、20分で苦痛なく更新できたことがある
  そのサーバーは今でも最新 LTS で動き続けている
  Ubuntu 4 から始まったのか 6 からだったのかも覚えていないが、ずっと問題なかった
  もしかすると遅いアップグレードがアーリーアダプターの苦しみを避けさせてくれたのかもしれない
  今は Debian をずっと多く使っている
  サプライチェーン攻撃が多い状況では Debian Stable は本当に宝石のようで、より新しいバージョンが必要で別途対処しなければならないパッケージがいくつかあっても、古風で質実なエンジニアリング精神が好きだ
- 年齢確認/証明については誤って誘導されている気がする
- 前回の カーネルアップデート が原因で再起動後に壊れたのは、だいたい Arch/Artix の問題だ
  その二つは最新の流れを最も早く取り込む側であり、安定性が常に最優先というわけではない
  ただし、ローリングディストリが常にすべての最新版だけを提供しなければならないという意味ではない
  ここ数か月 Void Linux を使っているが、ローリングディストリでありながら LTS カーネルを使い、メインラインも選べて、保守者たちは素早い更新よりも安定したアプリのバージョンに重点を置いている
- 私のサーバー/VM はたいてい FreeBSD か Alpine を動かしている
  必要なところでは Debian も少し使っている。たとえば Proxmox、Alpine をサポートしない VPS、会社関係の機材などだ
  Chimera を動かすテストシステムも数台あるが、安定版が出るまではあまり依存するつもりはない
  AerynOS も少し試している
- FreeBSD のサポート期間がもっと長ければと思う
  リリースのサポート寿命が1年未満なので、アップグレードの窓を逃すと、その後のアップグレードは Debian Stable のような他のディストリより難しくなる
サーバー用途は Debian と Ubuntu に移ったが、若かった2000年代半ばには FreeBSD に夢中だった
実際に役立つことをするより、設定や構築に多くの時間を使っていた
当時は BSD 系を提供する専用サーバーや VPS を見つけるのが難しく、Panix.com のような所に落ち着いていた気がする
その前には、ニュージャージーの NAC だったと思う 15MinuteServers という会社が BSD を提供していた記憶もある
もうただの思い出話になっているな
- 今では私のプロバイダーではインストールがかなり簡単だ
  Hetzner と OVH で FreeBSD を使っており、以前は Vultr も使ったことがある
- OVH には FreeBSD テンプレート がある
  そして大半の KVM VM/VPS プロバイダーはコンソールアクセスとユーザー ISO のマウントを許可しているので、好きなものをインストールできる
fastfetch が実際より多くメモリを使っていると報告するのは、おそらく ZFS ARC のせいだろう
Linux のページキャッシュと同じようにいつでも回収でき、ツールごとに名前の付け方が違う: https://www.linuxatemyram.com/
誰かが Docker を初めて説明してくれたとき、「ああ、jail のこと？」と答えたのを覚えている
記事で説明されている通り、完全に同じではない
kqueue も大きな勝利だった
FreeBSD 開発者たちには本当に感謝している
最初の会社を15年間 FreeBSD の上で運営し、その稼働時間と回復力には驚かされた
私にも更新が怖い Ubuntu 16.04 サーバーがある
現在の稼働時間は1281日で、ここまで来ると再起動するのが申し訳なくなる
- ファイルシステムを別のマシンに dd でコピーして、qemu のようなエミュレータで起動して 予行演習 してみるといい
  自動起動するものの中に外部へ接続するものがあれば注意が必要だ
- 何がそんなに怖いのか分からない
  バックアップはあるんじゃないのか？
  Debian/Ubuntu システムは定期的な自動更新と再起動をするよう簡単に設定でき、手動メンテナンスはより大きなバージョンアップ時だけに残せる
- 私の最も古いサーバーは 8.04 にある

Ubuntu 16.04で10年間運用していたブログをFreeBSDへ移行

移行の背景

FreeBSD を選んだ理由

FreeBSD のインストールと Bastille の導入

ネットワークとリバースプロキシ構成

Caddy とサイトごとの Jail 構成

サイトとブログのデプロイ

ベンチマークと負荷テスト

Vultr VPS を使った地域別テスト

最終移行と主な教訓

関連記事

1件のコメント

Hacker Newsのコメント