前提の確認
ご質問の意図から、少し書き換えさせていただくと、
- Docker エンジンに、
ubuntu
の Docker イメージを使い、その中で Apache 等を動かす
- Docker エンジンに、
ubuntu
の Docker イメージを使わず、 Docker エンジン上で Apache 等を動かす
このような理解であっていますでしょうか。
Docker イメージと、 OS(ディストリビューション)の考え方
まずはじめに、 Docker では、OS を起動しているかのように「見えます」が、
ゲスト OS の起動では ありません 。
(Docker コンテナの起動とは、ハードウェア仮想化による仮想マシン起動ではないからです。)
たとえば、コマンド docker run -itd ubuntu:20.04
の実行とは、
「Ubuntu 20.04」の Linux ディストリビューション用のファイルシステム
(/ 以下の /bin 、/sbinなどのディレクトリ階層やファイル)を準備し、
そこを /
ディレクトリと認識したプロセス(特に指定しなければ /bin/bash
)を実行するものです。
ですから、 docker run ... <LinuxディストリビューションのDockerイメージ>
コマンドの実行とは、
OS のインストールでもなく、OS の起動でもないため、注意が必要になります。
コンテナとアプリケーションの考え方
Docker の存在意義とは、様々な環境を問わず「アプリケーションを簡単に開発・共有(移動)・実行」するためです。そのための Docker コンテナや Docker イメージなり、各種のコマンド体系やツール群が用意されています。
これらをふまえ、以下は一般的な Docker なりコンテナの考え方として書きます。
方法1. Ubuntu などの Docker イメージに、Apache などミドルウェアを設定すること
方法2. Ubuntu などの Docker イメージを使わず、Apache の httpd Docker イメージ を設定すること
Docker の考え方であれば「方法2」が望ましいです。
アプリケーションコンテナ
Apache をはじめとし、あらかじめ、有名どころのミドルウェアは公式 Docker イメージが提供されています。公式 Docker イメージは Docker コミュニティを通して保守・メンテナンスされています。そのため、自分でミドルウェアを管理しなくてもよく、何かしらイメージに問題が起こる場合には、対象となるイメージを差し替えて対処することもできます。
また、「方法2」では「アプリケーションコンテナ」という考えに基づいて開発・運用できます。これは「1つのコンテナに1つの機能」を持たせる考えです。
この考えであれば、例えば「Apache」用のコンテナと「MySQL」用のコンテナを分けます。分けることにより、アプリケーションをスケールアウトしやすくしたり、開発やメンテナンス時にシステム全体を停止したり更新しなくても、差し替えたり差し戻したりをやりやすくします。
システムコンテナ
もう1つは「方法1」にあるように「システムコンテナ」という考えに基づくものです。1つのコンテナ上に複数のアプリケーションやミドルウェアをセットアップする方法です。たとえば、Ubuntu の Docker コンテナの中に Apahce も MySQL も入れます。
こちらの場合は、Docker の利点である素早い開発・共有・実行がしづらくなったり、スケールしづらくなります。
なにより、システムコンテナは、通常の仮想サーバ的な開発・運用と変わりません。
そうなりますと、通常の仮想サーバよりも Docker が入ることによる手間が増えるのに、Docker の利点も活かせず、何のために Docker を入れるのか分からなくなります。
つまり、「方法1」のように、技術的にはシステムコンテナ的な利用もできますが、Docker で本来実現したかったこと・目指している使い方(アプリケーションコンテナ)とは異なります。
何らかの制約があって、コンテナをシステムコンテナとして使う必要があるのであれば、他のコンテナ技術を検討すべきでり、Docker は選択から外すべきでしょう。
代替案
それ以外の方法として、
方法3. リモートサーバ上では Docker を使わず、通常のサーバのようにセットアップする
というのもあります。リモートサーバの用途にもよりますが、プロダクション前提であれば、おそらく運用フローや運用担当者が変わる場合もあるでしょう。そのような場合、Docker を使うための、導入の手間(手順書作成、追加の運用フロー検討や検証)が発生します。また、運用に慣れていない場合は、トラブル発生時に復旧まで時間がかかってしまうことも予想されます。
そのようなリスクが許容出来ない場合は、無理にリモートサーバ上で Docker を使う必要はないでしょう。