FreeBSD 11－最低5年間サポートへ至る経緯は
FreeBSDプロジェクトはFreeBSD 11からセキュリティサポートおよびパッケージ提供のサポート期間を最低でも5年間は保持する「新しいサポートモデル」への移行に取り組んでいます。新しいサポートモデルの提案にはいくつかの背景があります。
要点を簡単にまとめると次のとおりです。
- 1年まはた2年という現在のサポート期間はエンタープライズ用途では短い
- リリース数の増加はプロジェクトの作業負荷を高くする
- ブランチ（9系、10系、11系と言ったまとまり）が最終的にどの程度サポートされることになるのかが不透明では長期の運用計画が立てにくい
サポートするリリースバージョンが増えると、セキュリティチームがセキュリティアドバイザリ発行時に確認すべき対象が増えますし、パッケージを提供するためのビルド数も増えます。プロジェクトとして動ける人的リソースも機械的リソースも有限です。電気代だってかかります。プロジェクトが持続可能で、かつ、ユーザが最大限に利益を得られるモデルが必要なのは明らかです。
ここでひとつ視点を変えてみましょう。リリースバージョンではなく、X.0がリリースされてからそのブランチのサポートが終了するまでを1つの区切りとして考えるようにします。こうするとFreeBSD 5.0以降、プロジェクトはだいたい次のタイムラインでリリースとサポートを繰り返してきたことがわかります。
- だいたい2年から3年おきにメジャーアップグレードバージョンをリリース（X.0をリリース）
- X.0をリリースしてからそのX系のサポートが終了するまでだいたい5年から6年ほどサポートを提供
このように、FreeBSDプロジェクトはこれまで実質的にブランチベースで5年～6年ほどサポートを提供してきたことになります。リリースバージョンごとのサポートは1、2年ですが、ブランチでみれば5年です。現在プロジェクトが考えている新しいサポートモデルは、これまでのサポートモデルをブランチ視点で整理し直すと言った内容になっています。
具体的には次のような「新しいサポートモデル」を検討しています。
- 2年ごとにメジャーアップグレードバージョン（X.0）をリリースする
- ブランチごとに最新のリリースバージョンをサポートする（古いバージョンから新しいバージョンへの移行期間は3ヶ月間を予定）
- ブランチのサポート期間を最低でも5年間とする
- FreeBSD 11.0-RELEASEからの実施を目指している。モデルを10系へバックポートする可能性もある
サポート期間が明確に5年間になりますので、これまでよりも余裕をもった運用計画の立案が可能になります。たとえば今年の7月にFreeBSD 11.0-REELASEのリリースが予定されています[1]。エッジサーバでもNASストレージでもなんでも良いのですが、8月からFreeBSD 11をベースとしたシステムの構築と運用を始めたとします。この場合、たとえば次のような運用計画を立案できるでしょう。
- 2015年7月 機材調達／または仮想化プラットフォーム調達
- 2015年8月 FreeBSD 11.0-RELEASEベースのシステム構築および運用開始
- 2016年8月 FreeBSD 11.1-RELEASEへのアップグレード実施
- 2017年8月 FreeBSD 11.2-RELEASEへのアップグレード実施
- 2018年8月 FreeBSD 11.3-RELEASEへのアップグレード実施
- 2019年7月 機材調達／または仮想化プラットフォーム調達
- 2019年8月 FreeBSD 13.0-RELEASEベースのシステム構築、現行システムからのデータの移行、運用開始
だいたい2年ごとにメジャーアップグレードバージョンのリリースが予定されていますので、4年後には2つ先のメジャーアップグレードバージョンがリリースされていることになります。4年間運用してから新しい環境への移行、移行時には1年間の猶予期間を設けて旧システムも並列して運用しておいたほうがなにかと安心でしょう。
システムの運用者や構築者の視点から見ると、日常的に次のような作業をすることになります。
- 週に1回、パッケージを最新の状態へアップデート
- 月に1回、システムを最新のセキュリティパッチへアップデート
- 年に1回、システムを次のマイナーアップグレードバージョンへアップデート
- 4年に1回、新しいプラットフォームの調達と新しいシステムの構築
これまで同様にバージョン番号は残りますが、今後は個々のバージョン番号にはそれほど意味がなく、ブランチにおいて常に最新のバージョンを使い続けると言った方向に利用方法が変わります。それでは手間が増えるではないかと感じるかもしれませんが、新しく導入された次の2つのおかげで、管理の手間はとても簡単です。
- パッケージのアップデート pkg(8)
- システムのアップデート freebsd-update(8)
システムとサードパーティ製アプリケーションの双方を最新版へアップグレードし続けることはセキュリティの面からも重要です。そして10以降、その作業はとても簡単なものになりました。運用者のやることは、発表されるセキュリティアドバイザリの内容の吟味や、アップデート後の動作確認といったところがメインになります。アップグレード作業そのものはコマンドを実行すれば数分で終わるような内容です。
これがFreeBSD 11以降のFreeBSDの一般的な管理方法と言うことになります。同じことはFreeBSD 10でもできますので、すでにこうした管理体制に切り替えたところもあるでしょう。cron(8)を活用すれば責任や問題の発生する部分だけを担当者が手動で作業するようにして、ほかは全自動化しておくこともできます。
カスタマイズしたカーネルを使っている場合には、FreeBSD 12以降に同じようなことができるようになるかもしれません。FreeBSDカーネルにはある程度のドライバや機能が最初から組み込まれていますが、プロジェクトではこの方針を転換し、多くのドライバや機能をカーネルモジュールとして後からロードする仕組みに変更する方向で話を進めています。軽いカーネル、起動時に必要に応じてカーネルモジュールがロードされる仕組みに変えようと言うことです。これは組込み機器やモバイルデバイスからHPCまで多種多様なデバイスでFreeBSDが最適な動作を提供するために必要になるのですが、その話は追々別のタイミングで実施しましょう。
こうなると、カスタムカーネルを作成する必要がなくなり、利用したい機能のカーネルモジュールやカスタムしたカーネルモジュールを読み込ませるようにすれば済む話になります。毎回カーネルを再構築すると言った手間は不要になります。
告知
「The Design and Implementation of the FreeBSD Operating System (2nd Edition)」の読書会をやります。興味のある方、参加のご検討よろしくお願いいたします。
