Ubuntu Server 22.04 LTS から 24.04 LTS への更新は基本非推奨 – クリーンインストールを推奨する理由

Ubuntu Server 22.04 LTS から 24.04 LTS へインプレースアップグレードすることは可能です。標準的には do-release-upgrade を使います。ただし、サーバー管理では、私はこの方法を基本的には推奨しません。

サーバー用途では、OS を長く継ぎ足すより、24.04 をクリーンインストールして設定とデータを移行する方が、状態を把握しやすく、再現性も高くなります。この記事では、なぜクリーンインストールを優先するのか、例外的に更新する場合は何を確認するのかを扱います。

この記事で確認すること

インプレースアップグレードを基本非推奨にする理由
クリーンインストールを選ぶ判断軸
do-release-upgrade を使う場合の確認点
切り替え前後に確認するサービス

参考
書籍

参考書籍

Advanced Ubuntu Administration and Management Best Practices

Ubuntu Server の運用項目を体系的に確認したい場合の参考書籍です。価格や在庫はリンク先で確認してください。

Amazon で見る

このリンクは Amazon アソシエイトリンクです。

結論: 基本的にはクリーンインストール推奨

サーバー用途では、22.04 から 24.04 へそのまま更新するより、24.04 を新規にインストールし、必要な設定とデータだけを移行する方が運用しやすいです。

更新中の判断が多く、設定ファイル差分の扱いを誤るとサービスへ影響しやすい
古いパッケージ、不要な依存関係、過去の設定が残りやすい
同じ状態を別ホストで再現しにくい
障害時に、OS 更新由来かアプリケーション由来かを切り分けにくい
構成管理を使っている場合、新規環境に再適用する方が状態を説明しやすい

インプレースアップグレードが向いていない理由

デスクトップ環境であれば、利用者の設定やアプリケーションを維持したまま更新したい理由があります。一方でサーバーは、構成、設定、データ、役割を分けて管理する対象です。OS 本体を長期間継ぎ足すほど、現在の状態が読みづらくなります。

観点	インプレースアップグレードの問題
時間	パッケージ数や環境により長時間かかる
状態管理	過去のパッケージや設定が残りやすい
再現性	同じ結果を別ホストで再現しにくい
障害時対応	途中失敗時の復旧判断が難しい
構成管理	正本と実機状態がずれやすい

推奨する進め方

基本方針は、既存サーバーをそのまま 24.04 へ上げるのではなく、24.04 の新規環境を作り、必要な設定とデータだけを移行することです。

Ubuntu Server 24.04 LTS をクリーンインストールする
ネットワーク、ユーザー、SSH、時刻同期、ファイアウォールなどの基本設定を適用する
アプリケーションを新規に構築する
データ、証明書、必要な設定ファイルだけを移行する
新旧環境で動作確認してから切り替える
旧環境は一定期間保持し、問題がなければ廃止する

それでも do-release-upgrade を使う場合

検証環境、停止を許容できる小規模環境、またはクリーンインストールが現実的でない環境では、do-release-upgrade を使うこともあります。その場合も、推奨手順ではなく例外的な更新手段として扱います。

sudo apt update
sudo apt full-upgrade -y
sudo reboot

事前確認

更新前に、OS、カーネル、稼働サービス、外部リポジトリ、保留パッケージを確認します。

lsb_release -a
uname -a
systemctl --failed
apt-mark showhold
find /etc/apt/sources.list.d -type f -maxdepth 1 -print

外部リポジトリと追加パッケージ

外部リポジトリや手動追加パッケージは、リリース更新時のトラブル要因になりやすいです。更新先の 24.04 に対応しているかを事前に確認します。

grep -R "^deb " /etc/apt/sources.list /etc/apt/sources.list.d
apt list --installed | grep -E 'docker|kubernetes|zabbix|postgresql|mariadb|nginx|apache2'

直前の再起動と状態確認

更新前に一度再起動し、起動後の状態が正常か確認します。再起動後に壊れる状態を抱えたままリリース更新へ進まないようにします。

sudo reboot
systemctl --failed
journalctl -p warning -b --no-pager

SSH 経由で実施する場合

SSH 経由のリリース更新では、ネットワーク断や SSH 設定変更で接続を失うリスクがあります。コンソール手段を確保し、作業中のセッションを安易に閉じないようにします。

who
ip addr
ip route
ss -tlnp | grep ':22'

リリースアップグレード

実施する場合は do-release-upgrade を使います。実行中の設定ファイル差分では、現在の設定を残すのか、パッケージ側の新しい設定を採用するのかを慎重に判断します。

sudo do-release-upgrade

更新後の確認

更新後は、OS バージョンだけでなく、サービス、ログ、ネットワーク、アプリケーションの動作を確認します。

lsb_release -a
uname -a
systemctl --failed
journalctl -p warning -b --no-pager
apt autoremove --dry-run

確認すべきサービス

対象	確認内容
SSH	公開鍵認証、接続元制限、sshd 設定
Web	Apache / Nginx、TLS、リバースプロキシ
DB	MariaDB / PostgreSQL の起動とログ
DNS / DHCP	名前解決、リース配布、ゾーン読み込み
監視	agent、exporter、通知経路

推奨しない進め方

バックアップなしで do-release-upgrade を実行する
外部リポジトリの対応状況を確認しない
設定ファイル差分を意味が分からないまま上書きする
SSH だけに依存して物理コンソールや仮想コンソールを用意しない
更新後のサービス確認を OS バージョン確認だけで済ませる

まとめ

Ubuntu Server 22.04 LTS から 24.04 LTS への更新は可能ですが、サーバー用途ではクリーンインストールして設定とデータを移行する方が、状態を把握しやすく、再現性も高くなります。

やむを得ず do-release-upgrade を使う場合は、バックアップ、外部リポジトリ、保留パッケージ、SSH 接続、更新後のサービス確認を事前に決めてから実施します。

Ubuntu Server 22.04 LTS から 24.04 LTS への更新は基本非推奨 – クリーンインストールを推奨する理由

Ubuntu Server 22.04 LTS から 24.04 LTS への更新は基本非推奨 – クリーンインストールを推奨する理由

結論: 基本的にはクリーンインストール推奨

インプレースアップグレードが向いていない理由

推奨する進め方

それでも do-release-upgrade を使う場合

事前確認

外部リポジトリと追加パッケージ

直前の再起動と状態確認

SSH 経由で実施する場合

リリースアップグレード

更新後の確認

確認すべきサービス

推奨しない進め方

まとめ

関連記事

コメントを残す コメントをキャンセル

コメントを残すコメントをキャンセル