Ubuntuイメージの選び方と互換性の確認

作成前に対応条件をそろえる

OS、ランタイム、DB、ネイティブ拡張、監視、バックアップの対応条件を一覧にします。製品としてサポートされる条件と、自分たちで試しただけの条件を分けます。提供元が必要な地域でそのイメージとCPUを用意しているかも確認します。

Ubuntu 24.04 LTSの具体例では、標準Python 3.12、PHP 8.3、PostgreSQL 16が導入されています。パッチ版は更新で変わります。古いメジャー版向けソフトがそのまま対応するとは限りません。LTSの保守期間と、アプリの対応を両方確認します。

届いたOSとCPUを確認する

VPS内で読み取り用コマンドを実行し、ディストリビューション、稼働カーネル、パッケージとマシンのアーキテクチャを記録します。

cat /etc/os-release
uname -r
dpkg --print-architecture
uname -m

表を横にスクロールすると、残りの項目を確認できます。

クラウド専用カーネルもあるため、カーネル文字列だけでUbuntu版や保守範囲は分かりません。amd64専用バイナリに対してarm64を選ぶ前に、Arm版または明示的に対応する代替を確認します。

初期構成の完了を確認する

cloud-initは鍵、ユーザー、ネットワークの初期設定に使われます。まず存在を確認し、ない場合は提供元の構成方法を調べます。存在しないこと自体が障害ではありません。

if command -v cloud-init >/dev/null 2>&1; then
    cloud-init status --long
else
    printf '%s\n' 'cloud-initがありません。提供元の初期構成方法を確認してください。'
fi

runningは処理中です。SSHが通ってもerrorやdegradedなら調査します。導入されている場合は関連ログを確認します。

sudo tail -n 50 /var/log/cloud-init.log
sudo tail -n 50 /var/log/cloud-init-output.log

初期スクリプトが秘密情報を出すことがあるため、共有前に伏せてください。エラーを隠すためにcloud-init cleanやネットワークファイルの置換をしません。完了してもアプリ、DB、バックアップの正常動作は別に確認します。

インストール候補を調べる

パッケージ情報を更新し、必要なソフトウェアの候補と提供リポジトリを記録します。ここでのupdateは索引更新で、アプリ自体をインストールする操作ではありません。

sudo apt update
apt-cache policy python3 php postgresql
apt-cache policy python3.12 php8.3 postgresql-16

Installed: (none)は未導入、Candidate: (none)は現在の取得元に候補がない状態です。無関係なリポジトリを追加する前に、名前、CPU、Ubuntuのコンポーネントを確認します。

phpやpostgresqlのメタパッケージに加え、選ばれる版付きパッケージも調べます。導入済みならpython3 --versionやphp --versionで実体を確認し、DBサーバーはクライアントツールと区別します。

互換性の判断を具体例で試す

仮にアプリがPython 3.10のみ対応し、ネイティブ拡張がamd64向けだけなら、標準のUbuntu 24.04 arm64は2つの条件を満たしません。標準Pythonは3.12で、CPUも異なります。これは特定製品の説明ではない仮定です。

amd64に変えてもPythonは変わりません。仮想環境は作成に使ったインタープリターのパッケージを分離するもので、3.12を3.10にはしません。UbuntuのシステムPythonを置き換えず、アプリ更新または保守計画のある別ランタイム／コンテナを検討します。古いUbuntuにも残り保守期間があります。

拡張の実行経路、DB操作、定期処理、バックアップ復元を検証環境で試し、アプリのビルドと版を記録します。インストール成功やトップページ表示だけでは不十分です。

コンテナと各層の保守を整理する

コンテナもホストのカーネル、保存先、ネットワークに依存します。対象CPUの対応イメージを確認し、エミュレーションを黙ってネイティブ実行の代わりにしません。性能とサポートの前提が変わります。

永続データはボリュームなどへ保存し、破棄可能なコンテナと独立して復元します。リリースやダイジェストを固定しつつ更新も計画してください。脆弱なイメージの永久固定は適切な保守になりません。

Ubuntuの標準保守とUbuntu Pro、外部リポジトリ、バイナリ、コンテナの保守は同じではありません。誰がどの層を更新するかを記録します。

通常の更新とOSアップグレードを分ける

索引更新後、保留パッケージと失敗サービスを確認します。次は情報確認であり、ディストリビューションのアップグレードはしません。

apt list --upgradable
systemctl --failed
if [ -f /var/run/reboot-required ]; then cat /var/run/reboot-required; fi

適切な時間にパッケージ更新を実施して動作を再確認します。サービスの再起動が起こる場合があります。再起動要求マーカーがないことも、全てが最新である証明にはなりません。

OS版の更新はコピーや新規VMで試し、ランタイム、リポジトリ、DB更新、拡張を再確認します。最後のデータ同期と戻し方には変更後の書き込みも含めます。更新前のスナップショットには後の注文データはありません。

再現できる記録を残す

表を横にスクロールすると、残りの項目を確認できます。

秘密情報は別管理にし、機密でない設定をバージョン管理します。重要な依存が変われば別環境で再構築します。Oracleでの試験VM作成や、HTTPS公開の手順へ進んでください。