Windows 上のコンテナー プラットフォーム ツール

  • [アーティクル]

Windows コンテナー プラットフォームは拡大し続けています。 Docker はコンテナーの最初の段階でした。現在は、他のコンテナー プラットフォーム ツールを構築しています。

この記事では、Windows および Linux のコンテナー プラットフォームと各コンテナー プラットフォーム ツールについて説明します。

Windows と Linux のコンテナー プラットフォーム

Linux 環境では、Docker などのコンテナー管理ツールは、より細かいコンテナー ツールセットである runc と containerd に基づいて構築されています。

Linux 上の Docker アーキテクチャ

runc は、OCI コンテナー ランタイム仕様に従ってコンテナーを作成および実行するための Linux コマンドライン ツールです。

containerd は、コンテナー イメージのダウンロードと展開からコンテナーの実行と監視まで、コンテナーのライフ サイクルを管理するデーモンです。

Windows では、別のアプローチを採用しました。 Windows コンテナーをサポートするために Docker を使い始めたときに、HCS (ホスト コンピューティング サービス) 上に直接構築しました。 このブログ投稿には、HCS を構築した理由と、このアプローチを最初にコンテナーに採用した理由に関する情報が詳しく書かれています。

Windows 上の初期の Docker エンジン アーキテクチャ

この時点でも、Docker から HCS が直接呼び出されています。 ただし、その後は、コンテナー管理ツールが拡張されて Windows コンテナーと Windows コンテナー ホストが含まれ、Linux 上で containerd と runc を呼び出す方法で containerd と runhcs を呼び出すことができるようになりました。

runhcs

runhcs は runc のフォークです。 runc と同様に、runhcs は Open Container Initiative (OCI) 形式に従ってパッケージ化されたアプリケーションを実行するためのコマンド ライン クライアントであり、Open Container Initiative 仕様に準拠した実装です。

runc と runhcs の機能上の違いは次のとおりです。

  • runhcs は Windows 上で動作します。 コンテナーを作成および管理するために HCS と通信します。

  • runhcs では、さまざまな種類のコンテナーを実行できます。

    • Windows と Linux の Hyper-V による分離
    • Windows プロセス コンテナー (コンテナー イメージはコンテナー ホストと一致する必要があります)

使用法:

runhcs run [ -b bundle ] <container-id>

<container-id> は、開始するコンテナー インスタンスの名前です。 この名前は、コンテナー ホスト上で一意である必要があります。

バンドル ディレクトリ (-b bundle を使用) は省略可能です。 runc と同様に、コンテナーはバンドルを使用して構成されます。 コンテナーのバンドルは、コンテナーの OCI 仕様ファイル "config.json" のあるディレクトリです。 "バンドル" の既定値は現在のディレクトリです。

正常に実行するには、OCI 仕様ファイル "config.json" に 2 つのフィールドが必要です。

  • コンテナーのスクラッチ領域のパス
  • コンテナーのレイヤー ディレクトリのパス

runhcs で使用できるコンテナー コマンドは次のとおりです。

  • コンテナーを作成して実行するためのツール

    • run コンテナーを作成して実行します
    • create コンテナーを作成します

  • コンテナーで実行されているプロセスを管理するためのツール:

    • start 作成されたコンテナー内でユーザー定義プロセスを実行します
    • exec コンテナー内で新しいプロセスを実行します
    • pause pause を使用して、コンテナー内のすべてのプロセスを一時停止します
    • resume 以前に一時停止されたすべてのプロセスを再開します
    • ps ps を使用して、コンテナー内で実行されているプロセスを表示します

  • コンテナーの状態を管理するためのツール

    • state コンテナーの状態を出力します
    • kill 指定されたシグナル (既定値: SIGTERM) をコンテナーの init プロセスに送信します
    • delete デタッチされたコンテナーでよく使用されているコンテナーが保持するすべてのリソースを削除します

マルチコンテナーと見なすことができる唯一のコマンドは、list です。 指定されたルートで runhcs によって開始された実行中または一時停止中のコンテナーを一覧表示します。

HCS

GitHub には、HCS とのインターフェイスとして使用できる 2 つのラッパーがあります。 HCS は C API であるため、ラッパーを使用すると、高水準言語から HCS を簡単に呼び出すことができます。

  • hcsshim - HCSShim は Go で記述されており、runhcs のベースです。 AppVeyor から最新のものを入手するか、自分で構築してください。
  • dotnet-computevirtualization - dotnet-computevirtualization は、HCS の C# ラッパーです。

HCS を (直接またはラッパー経由で) 使用する場合、または HCS に Rust/Haskell/InsertYourLanguage ラッパーを作成する場合は、コメントを残してください。

HCS の詳細については、John Stark の DockerCon プレゼンテーションを参照してください。

containerd/cri

重要

CRI サポートは、サーバー 2019 以降と Windows 10 1809 以降でのみ使用できます。

OCI 仕様では 1 つのコンテナーが定義されていますが、CRI (コンテナー ランタイム インターフェイス) には、コンテナーをポッドという共有サンドボックス環境のワークロードとして記述されています。 ポッドには、1 つ以上のコンテナー ワークロードを含めることができます。 ポッドを使用すると、Kubernetes や Service Fabric Mesh などのコンテナー オーケストレーターによって、同じホスト上にある、メモリや vNET などの共有リソースを持つグループ化されたワークロードを処理できるようになります。

containerd/cri を使用すると、ポッドの次の互換性マトリクスが有効になります。

ホスト OS Container OS 分離 ポッドのサポート
  • Windows Server 2019/1809
  • Windows 10 1809
 Linux hyperv あり - 真のマルチコンテナー ポッドをサポートします。
Windows Server 2019/1809 process* または hyperv あり - 各ワークロード コンテナー OS がユーティリティ VM OS と一致する場合、真のマルチコンテナー ポッドをサポートします。
Windows Server 2016、
Windows Server 1709、
Windows Server 1803		 hyperv 部分的 - コンテナー OS がユーティリティ VM OS と一致する場合、ユーティリティ VM ごとに 1 つのプロセス分離コンテナーをサポートできるポッド サンドボックスをサポートします。

* Windows 10 ホストでは Hyper-V による分離のみサポートしています

CRI 仕様へのリンク:

Containerd ベースのコンテナー環境

runHCS と containerd はどちらも任意の Windows システム サーバー 2016 以降で管理できますが、ポッド (コンテナーのグループ) をサポートするには、Windows のコンテナー ツールに重大な変更を加える必要がありました。 CRI サポートは、Windows Server 2019 以降と Windows 10 1809 以降で使用できます。