従来、移植性はアプリケーションレベルで実現してきた。つまり全てのホスト環境にほぼ共通した構成で実行できるアプリケーションを設計することで、開発者が移植性を実現していた。

　こうした状況では、適切なプログラミング言語を選ぶことが重要になる。Javaなど一部の言語は、コードに大きな変更を加える必要なく、任意の種類の環境を簡単にサポートできる。だが、.NETのようなフレームワークでは複数の種類のOSをサポートするのはかなり難しい。

　また、アプリケーションの移植性を高めるには、特定のOS機能やツールに依存しない構成を設計することが重要だとされている。例えばアプリケーションの構成をWindowsレジストリに保存しているとしたら、Linuxに移植するのは難しくなる。構成をプレーンなテキストファイルに保存する方が移植性は高いといえる。

　仮想マシン（VM）は、ある程度の移植性を実現する1つの手段になる。例えばVMを使用すると、Linuxでしか実行できないアプリケーションをWindowsサーバでホストすることができる。この種のソリューションは、ホスト環境をクロスプラットフォーム対応にできる移植性を実現するが、ある程度の制限が残っている。WindowsベースやLinuxベースの物理サーバを使用できるため、ホスティングインフラレベルでの柔軟性は実現できる。だが同時に、アプリケーションを導入するには、特定の種類のゲストOSを使用することが求められる。

コンテナによって実現する高度な移植性

　「Docker」などのコンテナプラットフォームの進化により、アプリケーション自体を変更したりVMに頼ったりすることなく、アプリケーションの高度な移植性を実現できるようになった。コンテナを利用すれば、1種類のホスト環境向けに作成したアプリケーションをほぼ全ての環境に導入できる。大抵の場合、アプリケーションの構成に変更を加える必要はない。

　コンテナは「いったん作成すればどこでも実行できる」のがその理由だ。コンテナを利用する場合、コードをコンパイルしてコンテナイメージに配置する。このイメージは、コンテナをサポートするデーモンがインストールされたあらゆる種類の環境に導入できる。これが機能するのは、アプリケーションのバイナリと構成ファイル一式がコンテナ内に格納されるためだ。そのためアプリケーションはコンテナ外の環境変化の影響を受けない。

コンテナの移植性の制限事項

　ただしコンテナプラットフォームがあれば、アプリケーションの移植性が制限を受けないというわけではない。コンテナでも、永続ストレージやコンテナ自体の移植性に関する制限事項など、一定の制限を受ける。

　コンテナをある環境から別の環境に移動する際、コンテナ内のアプリケーションが利用する永続ストレージ構成の変更が必要になる場合がある。これは、コンテナ向けに永続ストレージを実装する方法が複数あり、ある環境におけるストレージの設定が、別の環境を念頭において設計されたコンテナではうまく機能しない可能性があるためだ。もちろん、コンテナ内に格納されたアプリケーションがステートレスの場合やストレージを必要としない場合は、こうした制限は受けない。

　コンテナは、同じ種類のコンテナプラットフォーム間では移植性が高い。だがDockerなど、1種類のプラットフォーム向けにコンテナを構築すると、「Linux LXC」（Linux Containers）のような別のプラットフォームで実行できなくなる。また、最新バージョンのDocker向けに設計したコンテナは、旧バージョンのDockerでは機能しないことがある。他のテクノロジーと同様、Dockerも旧バージョンとの互換性の影響を受ける。

LinuxとWindowsの壁を乗り越える

　あるOSファミリー（Windowsなど）から別のOSファミリー（Linuxなど）にコンテナを移植することも簡単ではない。VMと比べた場合、コンテナの移植性の大きな問題点は、伝統的にホストが限定される点にある。つまりLinuxのコンテナアプリケーションにはLinuxホストが、WindowsのコンテナアプリケーションにはWindowsホストがそれぞれ必要になる。

　この点では、コンテナはVMマシンよりも移植性が低い。LinuxベースのVMはWindowsホストで実行でき、WindowsベースのVMもLinuxホストで実行できる。さらにコンテナは、LinuxとWindows以外のプラットフォームは全くサポートしない。そのため、例えば「Docker化」されたアプリケーションをAppleの「macOS」に導入するネイティブな方法はない。macOSのホストシステムとDockerコンテナの間の仲介としてLinuxベースのVMを機能させることで、この問題は解決できる。だがリソース使用率は高くなり、管理の負担が増えることになる。

　ただし最近、Dockerに関してはこの状況が変化している。2017年春、Dockerは「LinuxKit」を発表した。LinuxKitは全ての開発者がコンテナ内に「Linuxサブシステム」を作成できるようにするツールセットだ。このLinuxサブシステムは、コンテナが別の種類のOSで実行されていても、コンテナ内で実行される小さなLinuxベースのOSを提供し、Dockerアプリケーションを実行できるようにする。このアプローチにはVMの必要はない。

　LinuxKitにより、Dockerは少なくともLinuxアプリケーションに関しては最大限に移植性を高めることに成功した。Linuxコンテナアプリケーションは、LinuxKitを使ってパッケージ化される。このパッケージは、ある環境から別の環境に移行するときに構成に特別な変更を加えずに、どのような種類のホストOSでも実行できる。

　ただ注意点が2つある。まずLinuxKitはDockerフレームワークとしか連携しない。LXCなど、他の種類のコンテナプラットフォームはLinux専用のままだ。次に、LinuxKitが適用されるのはLinuxアプリケーションのみだ。依然として、WindowsのコンテナアプリケーションをLinuxホストで実行する方法はない。

結論

　コンテナの移植性には一定の制限がある。だがコンテナプラットフォーム、特にDockerにより、アプリケーションをあるホストプラットフォームから別のプラットフォームへ移植することがかなり簡単になった。LinuxKitがリリースされたことで移行はさらに容易になる。このツールによってLinuxのコンテナアプリケーションに完全な移植性がもたらされる。