コンテナをベアメタルでホストすべきでない場合

　なぜ今までベアメタルでコンテナを動作させなかったのだろう。このアプローチが不可能を可能にするなら利用しない手はないだろう。

　仮想マシンではなく、ベアメタルサーバでコンテナエンジンをホストする場合、以下の問題点が考えられる。

• 物理サーバのアップグレードが難しい。ベアメタルサーバを新しいサーバに置き換える場合、新しいサーバではコンテナ環境を最初から作り直さなければならない。だが、コンテナ環境を仮想マシンイメージに含めていれば、イメージを新しいサーバに移すだけで済む
• ほとんどのクラウドでは仮想マシンの使用が求められる。Rackspaceの「OnMetal」や、Oracleの「Bare Metal Cloud Service」など、ベアメタルクラウドホストも幾つかある。だが全体的に見て、ほとんどのパブリッククラウドプロバイダーは仮想マシンしか提供していない。そのようなベンダーのプラットフォームを使用してコンテナを実行する場合は、仮想マシンを使用しなくてはならない
• コンテナプラットフォームがサポートしないハードウェアとソフトウェアの構成がある。現状では、VMwareのような仮想マシンプラットフォームやカーネルベースの仮想マシンを使用すれば、ほぼ全種類のOSをホストできる。また、ほぼ全ての種類のOSまたはサーバで仮想化プラットフォームを実行できる。だが、Dockerは制限が多い。ベアメタルでDockerをホストする場合、「Linux」サーバとMicrosoftの特定の「Microsoft Windows」サーバでしか動作しない。つまり、Dockerが現在サポートしていないMicrosoftの「Windows Server 2012」などをベアメタルサーバが実行しており、そのサーバでDockerをホストする場合、Windowsホスト上に仮想マシンをインストールする必要がある
• WindowsホストでLinuxコンテナを実行できない（逆も同様）。上記の問題点に関連するが、LinuxコンテナはLinuxホストでしか動作しない。これはWindowsについても同様だ。従って、ベアメタルWindowsサーバがあっても、Linux対応のアプリケーションをホストするためにDockerコンテナを動作させる場合は、Linuxの仮想マシンをWindowsサーバにインストールし、その仮想マシンをDockerホスティングの環境として使う必要がある
• ベアメタルサーバにはロールバック機能がない。最新の仮想化プラットフォームの大半には、仮想マシンのスナップショットを取得後に障害が発生した場合、そのスナップショットまでロールバックできる優れた機能が備わっている。ベアメタルサーバにはこれができない。技術的にはOSやファイルシステムに組み込まれたロールバック機能を使用できる可能性はあるが、仮想マシンイメージのロールバックほどシームレスではない。コンテナでのスナップショットとロールバックの考え方は実際には意味がない。コンテナはその性質上短期的なもので、ロールバック先がない。結果的に、シンプルなシステムロールバックを利用する唯一の方法は、仮想マシン上でコンテナをホストすることしかない

結論

　コンテナをベアメタルサーバで動作させるか、仮想サーバで動作させるかを決めるのは難しい。最適なアプローチを判断するには、さまざまな長所と短所に重みを付ける必要があるだろう。

　だが、良い知らせもある。どこでコンテナをホストするとしても、アプリケーションの単純な移植性、スケーラビリティ、アジリティなど、コンテナ化の持つ主な特徴全ての長所を利用できることだ。