bucket-sort logo bucket-sort

プログラミングとインフラエンジニアリングの覚え書き

Amazon Linux 2023のOS更新まわりの挙動を整理しておく

AWS , Linux bucket-sort

Amazon Linux 2023 の OS 更新の挙動について、従来の Amazon Linux 2 と違う部分があり、少し混乱したので整理しておきます。

dnf update で何が行われるか

dnf update（または yum update）を実行すると、 システムにインストールされているすべてのパッケージのうち、更新可能なものが最新のバージョンに更新されます。

更新対象となるのは：

  • インストール済みのすべてのパッケージ

    • 例：bash、openssl、httpd、php、kernel など

  • セキュリティアップデート

  • バグ修正

  • マイナーバージョンアップ

一方で、以下は更新されません。

  • インストールされていないパッケージ

  • 大幅なメジャーバージョンアップ

    • 例：php:7.4 → php:8.0 のような移行は別パッケージとして提供されることが多い

実行時の大まかな流れは以下の通りです：

  1. リポジトリから最新のパッケージ情報を取得
  2. インストール済みパッケージと比較
  3. 依存関係を解決
  4. ダウンロードおよびインストール

Amazon Linux 2023 における update と upgrade の違い

Amazon Linux 2023 では、

  • dnf update
  • dnf upgrade --releasever=...

の動作に重要な違いがあります。

dnf update の挙動

dnf update

これは現在のリリースバージョン（releasever）の範囲内でのみ更新が行われます。

つまり：

  • セキュリティ修正
  • バグフィックス

といった小規模なアップデートのみが対象となり、 OS のリリースバージョン（snapshot）は更新されません。

たとえば、2023.3.20240506 を使用している場合、 その snapshot 内での修正にとどまります。

dnf upgrade –releasever の挙動

dnf upgrade --releasever=2023.5.20240903

こちらは明示的に snapshot バージョンを指定し、 そのバージョンに切り替えながらパッケージを更新します。

つまり：

  • OS のベースバージョン自体が更新される
  • glibc やカーネル、ツールチェインなどの更新が含まれる

といった、より広範な変更が適用されます。

Amazon Linux 2023 は snapshot モデルを採用しており、 この方法でのみリリースバージョン間の更新が可能です。

両者のまとめ

コマンド 更新内容 OSリリースは変わるか
dnf update 同一 snapshot 内の更新 ❌ 変わらない
dnf upgrade --releasever=... 新 snapshot へ切り替え ✅ 変わる

現在のリリースバージョンは以下で確認できます。

cat /etc/system-release

または：

dnf config-manager --dump | grep releasever

Amazon Linux 2023 の前提（snapshotモデル）

Amazon Linux 2023 は、

  • ローリングリリースではない
  • 定期スナップショットモデル

を採用しています。

新しい snapshot（例：2023.4、2023.5 など）は数ヶ月ごとにリリースされ、 それぞれが固定されたパッケージセットを持っています。

同一 snapshot 内では破壊的変更が行われない前提となっており、 セキュリティパッチは snapshot ごとに Amazon から提供されます。

なお、各 snapshot のサポート期間は最低でも2年とされています。

アップグレードの必要性とリスク

観点 内容
アップグレードは必要か？ 必須ではないが推奨
リスクはあるか？ glibc や Python などの変更によりサービス影響の可能性あり
古いままのリスク サポート期間終了後は更新停止の可能性

実運用での指針

(1) snapshot を固定する

本番環境では /etc/dnf/vars/releasever を編集し、 特定の snapshot に固定しておきます。

echo "2023.5.20240903" > /etc/dnf/vars/releasever

これにより、dnf update 実行時も 同一 snapshot 内の更新のみが適用されます。

(2) ステージングで先に検証する

新しい snapshot が出た場合は、

dnf upgrade --releasever=新バージョン

をステージング環境で実行し、

  • アプリの動作確認
  • 依存関係の変化

などを確認します。

問題なければ本番へ反映します。

（※本番の前に、別リージョンや検証用環境で先行確認しておくと安心です）

(3) アップグレードサイクルを決める

四半期ごと、半年ごとなどで：

  • ステージング → 本番

のアップグレードをルーチン化しておくと、 更新タイミングの判断に迷わなくなります。

(4) immutable infrastructure の活用

可能であれば、

  • 構成済みAMI
  • CloudFormation / CDK
  • user data

などを利用し、

OSアップグレード＝新インスタンス作成

とすることで、検証と切り替えを明確に分離できます。

まとめ

snapshot モデルを前提とすると、

  • dnf update は同一 snapshot 内の更新
  • dnf upgrade --releasever はOS自体の更新

という扱いになります。

安定性を重視する場合は snapshot を固定し、 必要に応じてステージングで検証後にアップグレードする、 といった運用が現実的だと思われます。

Related Posts