コンテナの実態と課題を整理「コンテナ」の“誇大広告”にだまされないために確認すべきチェックポイント (1/2)

コンテナは数多くのメリットをもたらすが、制約も少なからずある。コンテナの可能性を正しく引き出すために、把握しておくべき制限事項を紹介する。

[Kurt Marko，TechTarget]

コンテナを有効活用するために知っておくべきこととは

　刺激的な宣伝は実情よりも先行するのが常だ。コンテナ化も過大視や誇大広告と無縁ではいられない。

　開発者とDevOps（運用と開発の融合）チームは、コンテナのイメージとサーバランタイムに関わる問題を考慮する必要がある。コンテナは、どこでも実行でき、何でもカプセル化できるわけではない。

　コンテナは、OSカーネルの特定領域にマッピングするため、コンテナとOSが本質的に結び付くことになる。そのためコンテナを別のOSへ移植する場合は、面倒で余分な作業が必要になる。例えばMicrosoftの「Windows」では、「Docker」形式のコンテナを利用できる。Red Hatの「Red Hat Enterprise Linux」（RHEL）でも同じ形式のコンテナを利用できる。だがWindows環境のコンテナ（Windowsコンテナ）が自動的にRHELで実行されるようにはならない。同じように、RHELコンテナは技術的に見ると別のLinuxホストで動作する可能性はある。だがシステム呼び出しなど、OSに当然存在するはずのものが見つからない、といった問題が発生する可能性は高い。

併せて読みたいお薦め記事

Windows環境で使えるコンテナ

• Windows Server 2016の新機能をチェックする――コンテナ編
• 「Hyper-Vコンテナ」と「Windows Serverコンテナ」の違いは？

そもそも「コンテナ」とは何か

• ハイパーバイザーとの違いは？　「コンテナ技術」を活用する5つのメリット／デメリット
• 1回で分かる：仮想化とは違うコンテナ技術「Docker」って何？

クロスプラットフォームの制約

　Dockerは「Linux」のコンテナ技術「LXC」（Linux Containers）の拡張機能として開発された。LXCは、アプリケーションとその依存関係（ライブラリやパス名など）を1つの実行可能イメージにバンドルするための標準形式を定義する。Dockerは、アプリケーションに公開する実行環境が、複数のDockerコンテナランタイム（実行環境）間で同じであることを保証する。LXCは独立したアプリケーションサンドボックスを確立するが、Dockerとは違ってシステム固有の詳細は抽象化しない。具体的にはネットワークやストレージの構成や、ライブラリ／ログファイルの場所のパスなどは抽象化の対象外だ。

　Dockerイメージは、互換性のある全てのランタイムでそのまま実行できる。DockerがLinuxシステムでしか利用できなかったときは、これで十分だった。

　Dockerの中核要素である「Docker Engine」は、WindowsとApple製OSにも移植された。その結果、OS固有のコンテナホスティングの制約が浮き彫りになった。

　Linux、Windows、Appleの「macOS」でネイティブに実行し、ユーザーからのコマンドを受け付ける「Dockerクライアント」は、ローカルの「Dockerデーモン」（サーバ）へ接続する。Dockerデーモンはホスト型ハイパーバイザーの仮想マシン（VM）として実行し、Windowsなど他のOSでLinuxベースのコンテナをホストするのに必要な機能を提供する。ホスト型ハイパーバイザーにはOracleの「Oracle VM Virtualbox」などがある。

　コンテナ化したアプリケーションはLinuxホストで実行する。そのためMicrosoftの「.NET Framework」など、ホストOSのネイティブのライブラリや他の機能は利用できない。Windowsカーネルを必要とするアプリケーションは、Windowsコンテナを使用してDocker互換システムでコンテナ化できる。本稿執筆時点では、Microsoftの「Windows Server 2016」または「Windows 10」でWindowsコンテナが利用可能になる。Windowsコンテナは、VMによる助けがなければLinuxまたはmacOSでは実行できない。

Linux環境からの移植

　Dockerは、Linuxカーネルの機能をベースにしているが、特定のディストリビューションのパッケージ全体をベースにしているのではない。Linuxカーネル開発の中核となる考え方は、新しいバージョンに旧バージョンとの互換性を持たせる、というものだ。コンテナ化したアプリケーションが、Docker Engineとの互換性がある限り、どのLinuxディストリビューションをコンテナホストに選んだとしても適切に動作する。

　コンテナは可搬性が高く、あるホストで構築し、動作するコンテナは、全く別のホストでも基本的には同じように動作する。そのホストがAmazon Web Services（AWS）の「Amazon EC2 Container Service」（ECS）のようなクラウドサービスだったとしても、それは変わらない。