AlmaLinuxの選択理由とCentOSの廃止による影響
AlmaLinuxは、RHEL（Red Hat Enterprise Linux）やCentOSとバイナリレベルで完全な互換性を持つLinuxディストリビューションです。CentOSは多くの企業や開発者にとって信頼性の高いオペレーティングシステムでしたが、2020年12月にCentOSの安定版リリースが廃止され、CentOS Streamに移行することが発表されました。CentOS StreamはRHELの次のバージョンの開発を進めるためのローリングリリース型のディストリビューションであり、安定版として利用するのが難しいと感じるユーザーが多いです。
そのため、CentOSの代替として、安定性と信頼性を維持しつつ、RHELと互換性のあるAlmaLinuxが選ばれることが増えています。AlmaLinuxは、CentOSからの移行を容易にするために設計されており、既存のCentOS環境で動作しているアプリケーションやツールをそのまま利用できることが大きなメリットです。
AlmaLinuxのインストール方法
前提条件: DockerとSSHの準備
この記事では、Ubuntu 24.04がインストールされたサーバーにDockerを使用してAlmaLinuxのコンテナを作成する方法を説明します。サーバーはCPUアーキテクチャがarm64のクラウドサービス上にあり、SSH接続を使用して操作を行います。最初に、サーバーのCPUアーキテクチャを確認するために以下のコマンドを実行します。
uname -m
これは、現在のシステムがどのCPUアーキテクチャ（例えば、x86_64やarm64）を使用しているかを確認するためのコマンドです。
Dockerイメージの取得とコンテナの作成
1. Dockerイメージの取得
まず、AlmaLinuxのDockerイメージをDocker Hubから取得する必要があります。これは、AlmaLinuxのオペレーティングシステムを含むイメージファイルであり、このイメージを使用してコンテナを作成します。以下のコマンドを実行してイメージを取得します。
docker pull almalinux:latest
このコマンドは、Dockerのレジストリから最新のAlmaLinuxイメージをダウンロードします。latestタグは、最新の安定版イメージを指定していることを意味します。
補足説明:
このステップは、コンテナを作成するために必要なベースイメージをローカルに保存する作業です。次のステップで、このイメージを元にしてコンテナを作成しますが、既に手元にイメージがあれば、このステップをスキップできます。
2. コンテナの作成と起動
次に、ダウンロードしたAlmaLinuxイメージを使用してコンテナを作成し、起動します。以下のコマンドを使用します。
docker run -d -p 8888:80 --name alma イメージID
ここで使用するオプションを簡単に説明します。
-dオプションは、コンテナをバックグラウンドで実行するためのものです。-p 8888:80は、ホストのポート8888をコンテナのポート80にマッピングします。これにより、ホストの8888ポートにアクセスすることで、コンテナ内のWebサーバーにアクセスできます。--name almaは、コンテナに「alma」という名前を付けます。これにより、後で簡単にこのコンテナを特定できます。
エラー発生時の対処
コマンドを実行してもコンテナが起動しない場合があります。例えば、次のような不具合が起こることがあります。
- コンテナが起動しない。
- エラーの内容が表示されず、原因が不明。
このような場合は、以下のコマンドを使って起動に失敗したコンテナを削除し、再度コンテナを作成します。
docker rm コンテナID
コンテナIDは、docker ps -aコマンドで確認できます。
再度、次のコマンドを試します。
docker run -d -p 8888:80 --name alma イメージID /sbin/init
この時、/sbin/initを指定することで、コンテナ内でシステムの初期化プロセスが実行され、より正常に動作する可能性があります。
補足説明:
コンテナが起動しない場合、考えられる原因は多岐にわたります。例えば、使用しているCPUアーキテクチャが適切でない場合や、イメージ自体に問題がある場合などです。このガイドでは、/sbin/initを使用して問題を回避する方法を説明していますが、他にも様々なアプローチが考えられます。
3. コンテナ内でのコマンド実行
コンテナが無事に起動したら、以下のコマンドでコンテナに入ります。
docker exec -it alma bash
ここから、コンテナ内でsystemctlコマンドを使用してサービスの管理を行おうとするかもしれません。しかし、次のようなエラーが発生する可能性があります。
System has not been booted with systemd as init system (PID 1). Can’t operate.
Failed to connect to bus: Host is down
このエラーは、コンテナがsystemdを使用して起動していないために発生します。通常、コンテナは軽量化されているため、systemdのような完全な初期化システムが含まれていません。これを解決するためには、--privilegedオプションを使ってコンテナを起動し、ホストシステムのデバイスにアクセスできるようにする必要があります。
systemdのエラー解決とコンテナの再起動
1. systemdのエラーとその解決策
前のステップで、コンテナ内でsystemctlを使おうとした際に発生したエラーについて、もう少し詳しく説明します。このエラーは、コンテナがsystemd（Linuxの初期化システム）を使用していないために起こります。
System has not been booted with systemd as init system (PID 1). Can’t operate.
Failed to connect to bus: Host is down
このエラーは、コンテナがsystemdを使用せずに起動しているため、systemctlコマンドが正しく動作しないことを示しています。systemdをインストールしても、このエラーは消えません。これは、コンテナの設計上、systemdが完全にサポートされていないためです。
2. コンテナの停止と削除
エラーを解決するために、まず現在のコンテナを停止し、削除する必要があります。以下のコマンドを使います。
docker stop alma
docker rm alma
docker stop almaは、指定されたコンテナ名（この場合は「alma」）を停止します。docker rm almaは、停止したコンテナを削除します。
これで、新しい設定でコンテナを再作成する準備が整います。
3. 特権モードでのコンテナ再起動
次に、コンテナを--privilegedオプションを使用して再起動します。このオプションを使用すると、コンテナはホスト上のすべてのデバイスにアクセスできるようになります。これにより、systemdが適切に動作するようになります。
docker run -d --privileged -p 8888:80 --name alma イメージID /sbin/init
--privilegedオプションは、コンテナがホストシステムのリソースやデバイスにアクセスできるようにするため、systemdなどのサービスが正しく動作します。
補足説明:
通常のコンテナはホストシステムの制限されたリソースにのみアクセスできるよう設計されていますが、--privilegedオプションを付けることで、コンテナがホストのほとんどのリソースにアクセスできるようになります。これはセキュリティ上のリスクも伴うため、必要な場合にのみ使用することが推奨されます。
4. コンテナ内での再試行
コンテナが再起動したら、再度コンテナに入り、先ほどエラーが発生したコマンドを再試行します。
docker exec -it alma bash
systemctl
今度はエラーが発生せず、正常に動作するはずです。systemctlコマンドでサービスの管理や状態の確認ができるようになります。
systemctl status
これで、サービスが正しく起動しているかどうかを確認できます。
特権モードとエラーの原因
Dockerの特権モード（--privileged オプション）を使うと、コンテナがホストOSのリソースやデバイスに広範囲にアクセスできるようになります。これは非常に便利ですが、同時にエラーの原因となることがあります。以下は、特権モードを使用する際に注意すべき点と、エラーの原因になりうる要因です。
1. セキュリティ設定による影響
UbuntuなどのLinuxディストリビューションは、セキュリティが強化されているため、特権モードが正しく動作しない場合があります。この場合、ホストOSの設定を見直す必要があるかもしれません。
2. システムリソースの競合
特権モードを使用すると、コンテナがホストシステムの多くのリソースにアクセスするため、リソースが競合してエラーが発生することがあります。特にメモリやCPUの使用率が高い場合には注意が必要です。
3. systemdの完全サポート
通常、コンテナ内には軽量な初期化システムしか含まれていませんが、特権モードを使用しても、systemdのようなフル機能の初期化システムが正しく動作しないことがあります。この場合、ホスト側での追加設定が必要になることがあります。
ここがポイント
特権モードを使用する理由と、そのリスクを理解することは非常に重要です。以下に、特権モードに関する重要なポイントをまとめました。
特権モードの必要性
特権モードは、コンテナ内でシステムの初期化や特定のハードウェアへのアクセスが必要な場合に使用します。しかし、セキュリティリスクが伴うため、必要最低限の使用に留めるべきです。この記事では、システム管理を行うために特権モードを使用していますが、通常の用途では推奨されません。
エラーが発生した場合の対処法
エラーが発生した場合、まずはホストOSの設定やリソースの競合を確認しましょう。具体的には、dmesg や journalctl コマンドを使用して、システムログを確認すると、原因を特定する手助けになります。特定の環境によっては、このガイドの範囲外でのトラブルシューティングが必要になる場合もあります。
Ubuntu特有の設定
Ubuntuのようにセキュリティが強化されているOSでは、特権モードが適切に動作しないことがあります。このような場合は、システム管理者に相談するか、別の方法で問題を解決する必要があるかもしれません。
特権モードとは？
特権モードは、DockerコンテナにホストOSと同等の権限を与えるモードです。これにより、通常はコンテナ内からアクセスできないホストOSの深い部分にもアクセスできるようになります。以下のような場合に特権モードが必要です。
- 特別なソフトウェアの実行: 一部のソフトウェアは、ホストOSのリソースに直接アクセスする必要があります。
- デバイスへの直接アクセス: GPUやネットワークカードなど、特定のハードウェアに直接アクセスする必要がある場合。
- コンテナ内でDockerを動かす: Dockerをコンテナ内で実行する、いわゆるDocker-in-Dockerの設定が必要な場合。
特権モードの注意点
特権モードを使用する際には、以下の点に注意してください。
- セキュリティリスク: 特権モードは非常に強力である一方、ホストOS全体が危険にさらされる可能性があります。本当に必要な場合にのみ、短時間だけ使用することをお勧めします。
- リソースの消費: 特権モードを使用するコンテナは、ホストOSのリソースを大量に消費することがあります。リソースを確認しながら運用することが重要です。
- エラーの発生: 特権モードを使用すると、システムリソースやセキュリティ設定により予期しないエラーが発生することがあります。
特権モードを使わない方法
特権モードを使わずに必要な機能を実現する方法もあります。
- ボリュームマウント: ホストのファイルシステムをコンテナにマウントすることで、必要なファイルを共有できます。
- capabilitiesの設定:
--cap-add=NET_ADMINのように、コンテナに与える権限を細かく設定することで、必要な機能を確保しつつセキュリティリスクを減らせます。 - マルチステージビルド: 不要なファイルを削除し、イメージサイズを小さくすることで、より効率的に運用できます。
AlmaLinuxがWordPressなどのCMSのコンテナであまり使われない理由
- Debian系ディストリビューションの人気
WordPressを含む多くのオープンソースソフトウェアは、Debian系（特にUbuntu）が圧倒的に普及しています。Debian系のパッケージマネージャ（apt）やディストリビューション自体の使いやすさから、多くの開発者やホスティングプロバイダーがDebian系を好んで使用しています。 - サポートとコミュニティ
UbuntuやDebianは巨大なユーザーコミュニティを持ち、多くのサポート情報やリソースがオンラインで簡単に見つかります。これにより、初心者から上級者まで多くの人がこれらのディストリビューションを選びます。 - コンテナのベースイメージ
多くのDockerイメージやコンテナは、最小限のリソースで動作することを目的としています。Debian系のイメージは軽量で、システム全体のフットプリントを抑えるために選ばれることが多いです。 - 互換性の問題
Debian系とRed Hat系（AlmaLinuxやCentOSなど）のディストリビューションでは、ソフトウェアの管理方法やシステム構成が異なるため、互換性の問題が生じることがあります。特に、WordPressのようなアプリケーションはDebian系で広くテストされているため、Debian系が選ばれることが多いです。 - 商用サポートとエンタープライズ用途
AlmaLinuxはRed Hat系のディストリビューションとして、企業向けの商用サポートが重要な環境での使用が多いです。一方、WordPressなどのCMSはエンタープライズ用途ではなく、一般ユーザーや小規模サイト向けに使われることが多いため、Debian系が好まれる傾向があります。
AlmaLinuxでしか実現できない、またはAlmaLinuxが特に適しているコンテナが存在する理由
- 安定性とエンタープライズ向けの信頼性
AlmaLinuxは、Red Hat Enterprise Linux (RHEL) 互換のディストリビューションであり、エンタープライズ環境での信頼性と安定性を重視しています。そのため、特にミッションクリティカルな環境や、長期間安定して運用する必要があるシステムに適しています。 - ソフトウェア互換性とサポート
一部のエンタープライズソフトウェアやライブラリは、RHELベースのディストリビューションでの動作を前提に開発されています。これにより、AlmaLinuxがそのようなソフトウェアを使用する環境で最適な選択肢となります。 - セキュリティとアップデート管理
AlmaLinuxは、Security-Enhanced Linux (SELinux) をデフォルトで使用しています。SELinuxは、システム全体のセキュリティを強化するための強力なツールで、セキュリティを重視する環境では、AlmaLinuxの使用が推奨される場合があります。また、AlmaLinuxは長期的なサポートと安定したアップデートが提供されるため、特に長期間の運用が必要なプロジェクトに適しています。 - 特定のネットワーク設定やカーネルオプション
特にネットワークに依存するアプリケーションやサービスでは、AlmaLinuxのネットワーク設定やカーネルオプションが、より安定した動作を提供することがあります。SoftEther VPNの例のように、Ubuntuのネットワークスタックにバグや特定の問題がある場合、AlmaLinuxがより適している場合があります。実際に確認しました。 - カーネルバージョンやモジュールの対応
特定のハードウェアサポートやカーネルモジュールが、RHELベースのカーネルバージョンに依存している場合があります。このような場合、AlmaLinuxを使用することで、ハードウェアとの互換性やパフォーマンスが向上することがあります。
