はじめに
こんにちは。
VM環境（Vagrant等）で CentOS 7 をベースに構築していたアプリケーション(Rails 6 + Nuxt 2)を、Docker環境へ移行しています。
CentOS 7 はすでに EOL（End of Life）を迎えているため移行は不可避ですが、その過程で以下のような疑問や懸念があり、それを調べたので備忘録として残します。
- 「CentOS 7 から Rocky Linux や AlmaLinux などの後継OSへどう移行すべきか？」
- 「Dockerのベースイメージに含まれる Linux は一体どのLinuxなのか？」
- 「OSパッケージ（ImageMagick等）の違いで問題は発生しないのか？」
- 「本番環境(Render)へデプロイした際、開発環境で差異が出ないか？」
もし同じようなレガシー環境で移行に苦戦している人の手助けになることがあれば幸いです。
CentOS 7 から Rocky Linux や AlmaLinux などの後継OSへどう移行すべきか？
まずはこれです。
そもそもなぜこの疑問を思ったのかというと、古いOSから新しいOSへシフトするわけですから、そこで何か問題が起こらないのかな？と思ったからです。
これは調べてみると、
「DockerではOS（Linux distribution）の種類を意識するのではなく、アプリケーションが必要とする実行環境（RubyやNodeなど）を中心に考える」という思考の転換が必要でした。
例えば以下のようなことです。
- Rubyのバージョンを固定する
- Nodeのバージョンを固定する
- ImageMagickのバージョンを確認する
- PostgreSQL/MySQLのバージョンを固定する
- Dockerイメージで開発・本番が同じ環境になるようにする
こういったアプリケーションが依存するライブラリのバージョンを管理することを考えるという発想です。
VMとDockerの根本的な発想の違い
VM環境（Vagrantなど）で構築する際は、まず「CentOS 7」などのベースOSを決め、
その上に各種ミドルウェア（Ruby, Node.js, PostgreSQLなど）を重ねていくアプローチが一般的でした。
しかし、Docker においては「CentOS 7 に近い環境を再現する」という発想自体が基本的に不要です。
- VMの考え方：OS（CentOS）を選定 → Ruby / Node をインストール
- Dockerの考え方：アプリケーションが主役 → Ruby環境を選定 → 必要なライブラリを追加
Docker では、「アプリが正常に動く実行環境をどう作るか」という視点に切り替えることが重要になります。
つまり、「CentOS 7 から Rocky Linux や AlmaLinux などの後継OSへどう移行すべきか？」という答えは、
「OSを移行・再現しようとするのではなく、アプリが必要とする言語やライブラリの実行環境（ベースイメージ）を中心に捉え直す」ということでした。
Dockerのベースイメージに含まれる Linux は一体どのLinuxなのか？
上記で「アプリが必要とする言語やライブラリの実行環境（ベースイメージ）を中心に捉え直す」とは分かりましたが、さらに疑問が出てきてしまいました。
（´・ω・｀）< じゃあ、Docker のベースイメージにはどの Linux が入っているんだろ？
Docker を勉強しているうちに、「ベースイメージには Linux が含まれている」ということは分かりました。
しかし、それが具体的などのLinuxなのかまでは知らなかったため調べてみると、
答えは「ベースイメージの作成者がどのOS（Linux）を採用しているか（タグの指定）」で決まるということが分かりました。
例えば Rails を例に出すと、
Ruby 公式イメージは、ほぼ Debian系(FROM ruby:3.1.3 → Debian) です。
構造的には以下のようになります。
Rails
↓
Ruby公式イメージ
↓
Debian
補足：
Ruby公式イメージのタグとOS系統の違い
- 無印(タグを指定しない)、
bullseyeやbookwormなど → Debian系 の Linux が使用されますalpineなど → Alpine Linux が使用されます（Debian系でもRed Hat系でもない独立系）
つまり、「Ruby公式イメージ ＝ 常にDebian」というわけではなく、タグの選び方によってベースとなる Linux の種類が変わるというのが正確な仕様になります。
一般的なタグを選んだ場合、Ruby公式イメージでは Debian系 がベースになります。
つまり、これまで私が使っていた Red Hat系（CentOS） とは、Docker では OSの系統が変わることになる、と分かりました。
| 系統（派閥） | 代表的なOS | 特徴・パッケージ管理コマンド |
|---|---|---|
| レッドハット（Red Hat）系 | CentOS, Rocky Linux, AlmaLinux | 企業などでよく使われる。インストールは yum や dnf コマンドを使う。 |
| デビアン（Debian）系 | Debian, Ubuntu, Linux Mint | コミュニティ主体で開発。Dockerの公式イメージで一番よく使われる。インストールは apt や apt-get コマンドを使う。 |
ここでまた疑問ができます。
（´・ω・｀）< CentOS は Red Hat系 なのに Docker に移行すると Debian系だから、差異ができちゃうな...。大丈夫なのかな？
差異による問題点は？(今回の移行で起きる変化)
実は、これはほとんど問題になりません。
なぜなら、Rails 6 等のアプリケーションが依存しているのはOS そのものではなく、その上で動く各種ライブラリやツール（Ruby, Bundler, libpq, ImageMagick, Node.js, Yarn など）だからです。
開発者が意識すべき差分は、主に Dockerfile 内でのパッケージインストールコマンドの違い のみとなります。
# CentOS（以前の書き方イメージ）
# RUN yum install -y ImageMagick
# Debian（Docker環境での書き方）
RUN apt-get update && apt-get install -y imagemagick
補足：Dockerが吸収してくれる「差異」とは？
ここで一つ注意したいのが、よく言われる「DockerがOSの違いを吸収してくれる」という言葉の意味です。
これはあくまでインフラ（土台・マシン）レベルの話です。
例えば、開発者のパソコンが Windows であろうが Mac であろうが、あるいはCentOSのサーバーであろうが、
「Dockerさえ動けば、その中で全く同じDebian環境（コンテナ）を起動できる」というのが、Dockerが吸収してくれている最大の差異です。
これによって、「ローカルでは動いたのに、本番サーバーでは動かない」というマシン環境の違いによる問題を消し去ってくれています。
一方で勘違いしてはいけないのが、
「Railsの依存関係やライブラリの違いまでDockerが自動で調整・吸収してくれるわけではない」ということです。
もしOS（Debian）の違いやライブラリの不備でDocker環境上で動かないのであれば、当然それは本番環境（Docker）でも動かない、ということになります。
よって、「 Dockerのベースイメージに含まれる Linux は一体どのLinuxなのか？」という疑問への回答は、
「ベースイメージの作成者がどの OS (Linux)を採用しているか（タグの指定）で決まり、仮に既存のOSと系統が違っていても実務上の問題はほとんど生じない」 となります。
OSパッケージ（ImageMagick等）の違いで問題は発生しないのか？
（´・ω・｀）< でも逆に言えば、ライブラリには依存しているわけだから、
OSの違いによってインストールできるOSパッケージ（ライブラリ)が違うから、そこで差異が出てこない？
もちろん影響がゼロではありません。
ImageMagick を例に出すと、
- CentOS7 → ImageMagick 6
- Debian Bookworm → 標準（apt）だとImageMagick 6系。7系にしたい場合は別途サードパーティのリポジトリなどが必要だったりする
ImageMagick 7 ではコマンド体系が convert ⇒ magick になったりするので互換性が心配になります。
しかし実はこれも大きな問題にはなりません。
理由は、これは「ライブラリのバージョン差による問題」であって「OS の問題」ではないからです。
ライブラリのバージョン差による問題であれば、Docker はこれを見事にクリアしてくれます。
-
OS側での自動選定
Dockerfile にapt-get install -y imagemagickと書くだけで、
そのDebianバージョン用にパッケージ化されているバージョンを自動的に選んでインストールしてくれます。 -
Gem（ライブラリ）側の吸収能力
Gem側が使ってるImageMagickのバージョンに対応していれば、こっちで細かくバージョン差を気にしなくても動いてくれることが多いです。
*ただしこれはGem次第なので、もし使ってるGemが古くてImageMagick 7に非対応だった場合はここで詰まる可能性はあります。
要するに、Dockerがそのバージョン用にパッケージ化されたものを入れてくれるので、
あとは使ってるGemがそのバージョンに対応しているかだけ確認すれば大丈夫、ということです。
そしてここまでのことで以下の答えが出ました。
Q. VM 環境の CentOS(Red Hat系)から Ruby 公式イメージの Debian系 を使ってDocker 環境を作っていいの？
A. 全然OK！
公式イメージは非常に良く整備されているし必要なものは全部揃っている。
もし無理に RedHat 系にしようとすると、Ruby、Node、Bundler を全部自分で入れる必要が出てくる。かなり面倒。
本番環境(Render)へデプロイした際、開発環境で差異が出ないか？
ここも気になったので調べてみたんですが、実はちょっと自分の理解が雑でした。
最初は、PaaS では Dockerを使わないデフォルトのデプロイ方式の場合、
サービス側が用意した標準OS（Ubuntu Server 環境など）の上でアプリケーションが実行される、と認識していました。
なので「RenderがUbuntuを用意してその上でアプリが動いてるんだろうな」くらいに思ってたんですが、
Render 公式ドキュメントを読むと、Dockerを使わないネイティブ環境（Ruby/Node/Pythonなどをそのまま指定するデプロイ方式）は、
Debian 12（bookworm）ベースで動いていると明記されていました。
じゃあ Ubuntu はどこに出てくるのかというと、
Renderのフォーラムでのやり取りを見る限り、
Ubuntuなのは「サーバー（VMインスタンス）そのもの」の話で、
その上で実際にRubyやNodeのアプリが動くコンテナ側はDebianになっている、という二段構えの構成のようです。
- Renderのサーバー本体（インフラ）→ Ubuntu
- Renderが用意するRuby/Node等の実行環境（アプリが動く場所）→ Debian（bookworm）
（´・ω・｀）< じゃあ、開発環境も本番環境も Debian系だから差異は出ないの？
Debian 系とは言っても、完全に同じにはならないのですが、それでもある程度は近い環境になります。
なので「開発はDocker(Debian)、本番ではUbuntuだから差異がある」というのは、前提がちょっと違いました。
実際には、本番側は元々Debian系なので、開発環境をDebian系（今回のRuby公式イメージのような）で作っておけばいい、ということになります。
じゃあもし他の Paas で、本番環境が開発環境のLinux と違っていたらどうするの？
という点に関しても、Dockerイメージさえ同じなら「本番環境だけ動かない」ということは基本的に起きません。
なぜかというと、Paas にデプロイする方法を「Docker（Dockerfileを用いたデプロイ）」に切り替えると、Paas が用意した環境を使わなくなるからです。
Docker で作った環境をそのまま本番環境で使います。
【ローカル開発環境】 PC (macOS / Windows) ──> Docker ──> [ Debian コンテナ (Rails + ImageMagick等) ]
【本番環境 (Paas が用意したもの)】 サーバー (Linux) ──> Docker ──> [ Debian コンテナ (Rails + ImageMagick等) ]
つまり、開発環境の Docker のコンテナで動くのであれば、
コンテナは、中にアプリの実行に必要なOSのファイル（今回の場合はDebianの仕組みやImageMagickなど）をすべて詰め込んだ独立した「カプセル」のようなものなので、
「手元の Docker で動いたものは、本番環境の Docker でも同じように動く」 ということです。
一点だけ注意点として、ここはAIに補足されたことなのですが、
Macが Apple Silicon（M1/M2など）の場合、
ローカルでビルドしたイメージは arm64 向けになっていて、Renderのサーバー（x86_64）だとgemのネイティブ拡張周りで例外的に動かないことがあります。
その時は、docker buildx build --platform linux/amd64 ...のようにビルド時のアーキテクチャを明示しておくと安全のようです。
まとめ
VM環境から Docker 環境へ移行する際のポイントを整理：
- CentOS 7 の再現は不要：Dockerでは OS ではなく「アプリが必要とする依存関係」を起点に設計する。
- Ruby公式イメージ（Debianベース）の利用で問題なし：無理に Red Hat 系のイメージを一から構築する必要はなく、整備された公式イメージを活用するのがベストプラクティス。
-
コマンドの違いを意識する：CentOS の
yumから、Debian（Ubuntu）のapt-getへインストール記述を変更する。 - 開発・本番環境の同一性を確保する：本番環境（Render等）でも Docker デプロイを選択することで、ホストOSに依存しない実行環境を構築できる
ここまで読んでいただきありがとうございました。
本記事はドキュメントやAI、記事を読みながら自分なりに内容をまとめたものです。
もし認識違いや補足があれば、ご指摘いただけると嬉しいです。