【第3回】Linuxパッケージ管理の完全理解！AlmaLinuxを支える dnf / yum / apt の神髄

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
「Linuxエンジニアになるための基礎」連載、第3回へようこそ。前回は grep や awk などのテキスト処理コマンドを駆使して、数GBのログから真実を導き出すプロのトラブルシューティング技術を学びました。

今回は、サーバー構築の根幹を担う「パッケージ管理システム（dnf / yum / apt）」について、圧倒的な情報密度で徹底解剖します。Webサーバー（NginxやApache）、データベース、プログラミング言語など、システムに必要なソフトウェアを安全かつ効率的にインストール・管理する技術です。

---

第1章：パッケージ管理システムの基礎と「依存関係地獄」の克服

そもそも「パッケージ」とは何でしょうか？
簡単に言えば、実行ファイル（バイナリ）、設定ファイルの雛形、マニュアル（manページ）、そして「このソフトを動かすために必要な他のソフトウェアのリスト」を1つのファイル（.rpm や .deb）にまとめたアーカイブのことです。

1-1. パッケージ管理が解決する「依存関係（Dependency）」問題

現代のソフトウェアは単独では動きません。例えば PHP をインストールしようとすると、内部で libxml2 や openssl などの共通ライブラリを要求します。さらに libxml2 は別のライブラリを要求します。これを手作業で解決していくと、永遠に終わらない「依存関係地獄（Dependency Hell）」に陥ります。

この問題を全自動で解決し、「PHPをインストールして」と命令するだけで、芋づる式に必要なライブラリ群をインターネット上の倉庫（リポジトリ）からダウンロードし、正しい順序でインストールしてくれるシステム。それがパッケージマネージャ（DNF, APTなど）の最大の役割です。

1-2. ローカル管理（RPM）と高次管理（DNF）の2層構造

RHEL系（AlmaLinux / Rocky Linux）におけるパッケージ管理は、歴史的に2つのレイヤーで構成されています。

レイヤー	コマンド	役割と特徴
低次（バックエンド）	rpm	ローカルにある個別の .rpm ファイルをインストール・アンインストールする。依存関係の自動解決は行わないため、ライブラリ不足だとエラーで止まる。
高次（フロントエンド）	dnf (旧: yum)	インターネット上のリポジトリにアクセスし、依存関係を計算・自動解決してから、裏側で rpm コマンドを呼び出してインストールを実行する。

普段の業務では高次の dnf を使いますが、RPMデータベース（/var/lib/rpm/）が破損した際の復旧などでは、低次の rpm コマンドの知識が必要になります。

---

第2章：YUMからDNFへ。そしてAlmaLinux 10の「DNF5」革命

長年、CentOSやRHELの代名詞と言えば yum (Yellowdog Updater, Modified) でした。しかし、YUMはPython 2系で書かれており、膨大なメタデータの処理時に大量のメモリを消費し、動作が遅いという致命的な弱点を抱えていました。

2-1. DNF (Dandified YUM) の誕生（AlmaLinux 8/9世代）

このYUMの課題を克服するために、RHEL 8以降（AlmaLinux 8/9を含む）では DNF が標準採用されました。
DNFは、内部の依存関係解決エンジンにC/C++で書かれた libdnf と hawkey（高速なSATソルバー）を採用しています。これにより、YUM時代とは比較にならないほど高速かつ正確に、メモリ消費を抑えながらパッケージを計算できるようになりました。
※AlmaLinux 9でも yum と打つと動作しますが、実体は /usr/bin/dnf へのシンボリックリンクです。

2-2. プロの先読み：AlmaLinux 10で到来する「DNF5」

次世代のAlmaLinux 10（RHEL 10ベース）では、さらなる革新である DNF5 が標準となります。
DNF5は、Pythonへの依存を完全に断ち切り、システム全体がC++で再構築されています。メタデータのダウンロード速度の飛躍的な向上、ディスクフットプリントの劇的な削減が図られており、クラウドネイティブ・コンテナ時代に特化した超軽量なパッケージマネージャへと進化しています。プロのエンジニアは常に次のOSの動向（Technology Preview）をウォッチしておく必要があります。

---

第3章：プロの実践 dnf コマンド完全攻略（検索・導入・削除）

それでは、実際の AlmaLinux 9 環境を想定して、インフラエンジニアが日常的に叩く必須の dnf コマンド群を見ていきましょう。

3-1. パッケージの検索と情報の確認

インストールを行う前に、目的のソフトウェアがリポジトリに存在するか、どのバージョンが提供されているかを必ず確認します。

# パッケージ名や説明文からキーワード検索を行う
dnf search nginx

# インストールされるパッケージの詳細情報（バージョン、リポジトリ、サイズ）を確認する
dnf info nginx

# 【プロの技】特定のコマンドが含まれているパッケージを逆引き検索する
# （例：「semanageコマンドを使いたいが、どのパッケージに入っているか分からない」場合）
dnf provides "*bin/semanage"

3-2. パッケージのインストールと更新

依存関係を自動解決してインストールを行います。

# Nginxをインストール（途中で y/N の確認プロンプトが出る）
dnf install nginx

# -y オプション：確認プロンプトをすべて「y (yes)」として自動的に進める（Ansibleやスクリプトで必須）
dnf install -y nginx

# システム全体（インストール済みの全パッケージ）を最新のセキュリティパッチにアップデート
dnf upgrade -y

3-3. 安全なアンインストールと孤児パッケージの掃除

不要になったソフトウェアを削除する際、初心者は単に dnf remove を行いますが、それだけでは「インストール時に一緒に引き込まれた依存ライブラリ」がゴミ（孤児パッケージ）としてシステムに取り残されてしまいます。

# Nginx本体を削除
dnf remove -y nginx

# 【プロの技】他のどのソフトからも依存されなくなった不要なライブラリを一掃する
dnf autoremove -y

プロのエンジニアは、ディスク容量の節約と攻撃表面（Attack Surface）の最小化のため、定期的に dnf autoremove を実行し、システムをクリーンな状態に保ちます。

---

第4章：インシデント対策！dnf history による時空操作（ロールバック）

本番環境でシステムのアップデート（dnf upgrade）を実行した直後、特定のミドルウェアが新しいライブラリのバージョンと競合し、システムがダウンしてしまったとします。
「さっきのアップデートを取り消して、5分前の状態に戻したい！」
こんな絶望的な状況を救うのが、DNFの最強機能 dnf history です。

4-1. 操作履歴の確認と状態の復元（Undo）

DNFは、インストールやアップデートなどのトランザクション（操作履歴）をすべてローカルのデータベースに記録しています。

# dnfの操作履歴を一覧表示する
dnf history

# 【出力例】
# ID     | コマンドライン             | 日時             | アクション | 変更
# -------------------------------------------------------------------------------
# 45     | upgrade -y                 | 2026-08-22 10:00 | Upgrade    | 120
# 44     | install -y mariadb-server  | 2026-08-21 15:30 | Install    |   5

上記の例で、ID: 45 のアップグレードによってシステムが壊れたとします。この場合、undo コマンドを用いて、このIDの操作を「なかったこと」にしてロールバック（切り戻し）を行います。

# ID:45 の操作（upgrade）を完全に元に戻す（古いバージョンのRPMを再適用する）
dnf history undo 45 -y

---

第5章：リポジトリの管理とサードパーティリポジトリ（EPEL / Remi）

AlmaLinuxの標準リポジトリには、システムの安定性を最優先するため、最新バージョンのソフトウェアや、マイナーなツールは含まれていません。現場の要件を満たすためには、信頼できるサードパーティ（外部）リポジトリを追加する必要があります。

5-1. リポジトリ設定ファイルの構造

リポジトリの設定ファイルは /etc/yum.repos.d/ ディレクトリ以下に .repo という拡張子で保存されています。

# /etc/yum.repos.d/almalinux-appstream.repo の中身（抜粋）
[appstream]
name=AlmaLinux $releasever - AppStream
mirrorlist=https://mirrors.almalinux.org/mirrorlist/$releasever/appstream
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-AlmaLinux-9

ここで重要なのは enabled=1（有効）と gpgcheck=1（改ざん防止の電子署名チェックを有効化）の設定です。セキュリティ上、gpgcheck を無効にすることは絶対に避けてください。

5-2. プロ必須の外部リポジトリ：EPEL と Remi

インフラ構築において、追加がほぼ必須となる2大リポジトリが存在します。

1. EPEL (Extra Packages for Enterprise Linux): Fedoraプロジェクトが提供する高品質な追加パッケージ群。標準にはない便利ツール（htop, jq, fail2ban など）が含まれる。
2. Remi’s RPM repository: 最新バージョンの PHP や関連モジュールを提供することに特化したリポジトリ。Web系エンジニアには必須。

# 1. EPELリポジトリのインストール（これ自体が標準リポジトリにパッケージとして存在します）
dnf install -y epel-release

# 2. Remiリポジトリの追加（RPMパッケージをURLから直接インストール）
dnf install -y https://rpms.remirepo.net/enterprise/remi-release-9.rpm

5-3. 外部リポジトリの安全な運用（有効・無効のコントロール）

外部リポジトリを追加したまま dnf upgrade を実行すると、標準パッケージが意図せず外部の新しいバージョンで上書き（汚染）される危険性があります。プロは enabled=0 でリポジトリを普段は無効化しておき、必要な時だけコマンドラインから呼び出します。

# Remiリポジトリは普段無効にしておき、PHPをインストールする瞬間だけ有効化（--enablerepo）する
dnf install -y php php-fpm --enablerepo=remi-php83

---

第6章：複数バージョンの共存を叶える「AppStream (モジュール)」

RHEL 8世代（AlmaLinux 8/9/10）から導入されたパッケージ管理の目玉機能が「AppStream（アプリケーション・ストリーム）」です。
従来のOSでは、OSのライフサイクル（10年）と、Web技術（Node.jsやPostgreSQLなど）の進化スピードが合わず、「OS標準のパッケージが古すぎて使い物にならない」という問題がありました。

6-1. モジュール（ストリーム）の概念

AppStreamでは、特定のソフトウェアに対して「複数の異なるバージョン」をOS公式として同時に提供し、ユーザーが使いたいストリーム（バージョン）を選択できるようになりました。

# Node.js の利用可能なストリーム（バージョン）をリストアップ
dnf module list nodejs

# 【出力イメージ】
# Name      Stream    Profiles                                Summary
# nodejs    18        common [d], development, minimal, s2i   Javascript runtime
# nodejs    20        common [d], development, minimal, s2i   Javascript runtime

6-2. 特定バージョンの有効化とインストール

新しいプロジェクト要件で「Node.jsのバージョン20」が指定された場合、ストリームを有効化してインストールします。

# Node.jsのバージョン20のストリームを有効化する
dnf module enable -y nodejs:20

# ストリームに従ってインストールを実行
dnf install -y nodejs

このAppStream機構により、OSのコア部分は安定した古いライブラリを保ちながら、ユーザー領域のアプリケーション空間にだけ最新の言語ランタイムを提供することが可能になりました。

---

第7章：Ubuntu/Debian系エンジニアとの対話（aptとの比較）

プロのインフラエンジニアであれば、AlmaLinux（RHEL系）だけでなく、クラウドやAI分野でシェアを伸ばしているUbuntu（Debian系）のサーバーを触る機会も必ず訪れます。Debian系では apt (Advanced Package Tool) が採用されています。

構造や哲学は非常に似ているため、以下の対応表（翻訳テーブル）を頭に入れておけば、どちらの環境でも迷うことなく戦うことができます。

目的・操作	AlmaLinux (RHEL系) : dnf	Ubuntu (Debian系) : apt
ローカルパッケージ操作	rpm -ivh package.rpm	dpkg -i package.deb
リポジトリ情報の最新化	(自動実行、手動なら dnf makecache)	apt update (※Debian系では必ず事前実行が必要)
パッケージの検索	dnf search [名前]	apt search [名前]
インストール	dnf install [名前]	apt install [名前]
システム全体の更新	dnf upgrade	apt upgrade
不要依存の削除	dnf autoremove	apt autoremove
履歴管理（ロールバック）	dnf history undo	(標準機能としては存在しない。/var/log/apt/history.log を確認)

---

総まとめ：パッケージ管理はインフラの治安維持である

第3回「パッケージ管理の完全理解」、いかがだったでしょうか。
数千からなるソフトウェアコンポーネントが複雑に絡み合うLinuxシステムにおいて、依存関係を自動解決し、整合性を保ち続けるパッケージマネージャ（DNF）は、まさに「OSの治安維持部隊」です。

• ソースコードからの野良ビルドを避け、必ずOS標準のパッケージ管理機構（RPM/DNF）の管理下に置くこと。
• 外部リポジトリ（EPEL/Remi）を導入する際は、無計画に有効化せず --enablerepo でスコープを絞ること。
• AppStreamを活用し、OSの安定性とアプリケーションの最新要件を両立させること。
• 障害発生時には、焦らず dnf history undo で確実な切り戻しを行うこと。

これらの運用ルールを徹底することで、「いつ、誰が、何をインストールしたか分からない」という属人的で不安定なシステムから脱却し、AnsibleなどのIaC（Infrastructure as Code）ツールを用いた自動化の土台を築くことができます。

次回、第4回は「ユーザー・グループ管理とアクセス制御の鉄則」です。システムを守るためのアカウント管理、sudo権限の最小化など、セキュリティに直結する重要テーマに切り込んでいきます。お楽しみに！リナックス先生でした！