コンテナの実態と課題を整理
「コンテナ」の“誇大広告”にだまされないために確認すべきチェックポイント(1/2 ページ)
コンテナは数多くのメリットをもたらすが、制約も少なからずある。コンテナの可能性を正しく引き出すために、把握しておくべき制限事項を紹介する。
刺激的な宣伝は実情よりも先行するのが常だ。コンテナ化も過大視や誇大広告と無縁ではいられない。
開発者とDevOps(運用と開発の融合)チームは、コンテナのイメージとサーバランタイムに関わる問題を考慮する必要がある。コンテナは、どこでも実行でき、何でもカプセル化できるわけではない。
コンテナは、OSカーネルの特定領域にマッピングするため、コンテナとOSが本質的に結び付くことになる。そのためコンテナを別のOSへ移植する場合は、面倒で余分な作業が必要になる。例えばMicrosoftの「Windows」では、「Docker」形式のコンテナを利用できる。Red Hatの「Red Hat Enterprise Linux」(RHEL)でも同じ形式のコンテナを利用できる。だがWindows環境のコンテナ(Windowsコンテナ)が自動的にRHELで実行されるようにはならない。同じように、RHELコンテナは技術的に見ると別のLinuxホストで動作する可能性はある。だがシステム呼び出しなど、OSに当然存在するはずのものが見つからない、といった問題が発生する可能性は高い。
併せて読みたいお薦め記事
Windows環境で使えるコンテナ
そもそも「コンテナ」とは何か
クロスプラットフォームの制約
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)のようなクラウドサービスだったとしても、それは変わらない。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[ゾーホージャパン株式会社] サイバー攻撃からネットワークを守る上で確実に押さえておきたいポイントとは? -
事例
[アルプス システム インテグレーション株式会社] 中小企業でも安心して活用できる「手ごろなSOCサービス」とは? -
製品資料
[株式会社シーイーシー] 脱VMwareに成功した企業は何をどう実践した? 事例に学ぶ戦略立案&実装のコツ -
製品資料
[株式会社オービックビジネスコンサルタント] ランサムウェア攻撃を“二重の防御構造”で防ぐ、クラウド型基幹システムの実力 -
製品資料
[株式会社オービックビジネスコンサルタント] 動画で知るランサムウェア被害企業のリアル、会計データが無事だった理由とは
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
2
鹿島建設のDXを阻む「10年前のAWS」 安全性と自由度を両立したモダナイズ
-
3
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
4
NECの「BluStellar」に必要なデータ保護と活用のための技術とは
-
5
慶應義塾が「Notion」を選んだ理由 AI導入の盲点になる“情報のサイロ化”
-
6
「Excel管理」では限界――製造現場の改善が進まない“隠れた原因”
-
7
LINEヤフーはなぜ「社内の管理者」すら信用しないインフラを作ったのか
-
8
「ノートPC派」は損をしている? Dellと考える“自作PC”のメリット
-
9
「また同じ説明か」 消費者の半数が離脱するAIチャットbotの“記憶喪失”
-
10
「企業におけるAI導入検討度とIT投資優先度」に関するアンケート
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
DX/AI投資の壁を突破、現代の最高財務責任者が直面する課題と克服のヒント
-
3
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
4
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
5
システムの保守がモダン化を阻む? 「変えない判断」から脱却する方法とは
-
6
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
7
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
8
“あのファイル転送”で暗躍するノーウェアランサム
-
9
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー