コンテナは移植可能ではあるが、手当たり次第にコンテナを1つの環境から別の環境へと移植すればコンテナ化されたアプリケーションに問題を生じさせることもある。そうした問題は、コンテナの仕組みに直接的に起因する。

　Windows Server 2016では、「Windows Serverコンテナ」と「Hyper-Vコンテナ」という異なる2種類のコンテナを作成できる。いずれの場合も、Windowsコンテナはコンテナホストによって実行される。ホストはコンテナが置かれる物理マシンまたは仮想マシンを指す。

　コンテナホストは仮想ホストと同じようなものと考えがちだが、実は大きな違いがある。仮想マシン（VM）は完全な自己完結型で、自前のOSやハードウェア設定などを持つ。これに対してコンテナには自前のOSは内蔵されていない。

　コンテナOSイメージはそれぞれのコンテナのOSとして機能し、一般的に、複数のコンテナが共通のコンテナOSイメージを共有する。このアプローチの利点として、一連のVMをホスティングしている仮想ホストのように、複数のサーバOSを実行することによってホストリソースを浪費せずに済む。コンテナOSイメージは複数のコンテナによって共有できるため、OSイメージは読み込みのみに対応する。

　コンテナは主に、コンテナイメージとサンドボックスの2つのコンポーネントで構成される。イメージは一般的に、仮想化されたアプリケーションを保存する。例えば1つのコンテナにはアプリケーションのバイナリとレジストリキーなどが保存されている。イメージは読み込みしかできない。レジストリの更新など書き込み操作はコンテナのサンドボックスに対して行われる。

　コンテナは移植を想定した設計になっているが、移植性に影響を及ぼす要素が幾つかある。その1つがコンテナOSイメージの依存関係だ。例えばWindows Server 2016をOSイメージのベースとするWindows Serverコンテナを作成したとする。災害が起きてそのWindowsコンテナを、クラウドベースコンテナホストでホスティングされたパブリッククラウドに移したとしても、恐らくLinuxホスト上でそのコンテナを機能させることはできない。WindowsとLinuxは両方ともDockerコンテナをサポートしているが、その根底にあるカーネルの違いはあまりに大きい。

　クラウドベースのWindows Serverコンテナホストでコンテナを正しく実行するためには、そのコンテナのOSイメージのコピーなど、依存関係にあるイメージを必要とする。

　幸いなことに、コンテナOSイメージは標準化が進む傾向にある。Windows Server 2016環境ではコンテナイメージパッケージプロバイダーをインストールし、それを使ってコンテナOSイメージを生成できる。Windows Server CoreベースのOSイメージを作成したい場合は、Dockerのインストールと設定が済んでいることを前提として、以下の3行のコマンドを入力する。

Install-PackageProvider ContainerImage -Force
Install-ContainerImage -Name WindowsServerCore
Restart-Service Docker

データを移行する際の注意点

　コンテナの移植性に関する最大級の課題としてコンテナデータボリュームの移行が挙げられる。コンテナデータボリュームではコンテナデータディレクトリの作成や、既存のデータディレクトリの追加ができる。データボリュームを複数のコンテナ間で共有することも可能だ。

　大切なのは、データボリュームはコンテナの外に存在するという認識だ。たとえそれを使っているコンテナを削除したとしても、データボリュームは残る。

　コンテナが実行中または一時停止中であれば、移行するには一般的にDockerエクスポートコマンドを使う。もし実行していないコンテナであれば、Docker保存コマンドを利用する。両コマンドともコンテナをファイルに保存して、別のホストへ移植できる状態にする。問題は、データボリュームがコンテナの外にあることから、エクスポートされたファイルに含まれないという点だ。

　現時点でデータボリュームを扱う最善の方法は、バックアップしておいて、コンテナを移行した後に復旧することだ。

　Windowsコンテナは、コンテナ化されたアプリケーションをクラウドや代替ホストに移植できることから、災害復旧のための優れたツールになり得る。だが、依存関係が崩れることを防ぐため、あるいはデータボリュームを失うことを防ぐためには慎重さが求められる。