コンテナ管理
Citrix Hypervisorは、VM内での次のコンテナタイプの使用をサポートしています：
- Linux VMでホストされているLinuxベースのDockerコンテナ
- Windows Server 2016 VM上のWindows Serverコンテナ
Citrix Hypervisorには、Dockerコンテナの展開を拡張する次の新機能があります：
-
Debian 8、RHEL/CentOS/OEL 7のコンテナ管理
仮想マシンでコンテナ管理が有効な場合、Citrix Hypervisorは仮想マシンで実行されている任意のDockerコンテナを認識します。
詳しくは、「Dockerについて」を参照してください。
Citrix Hypervisorには、Citrix Hypervisor上のWindows Serverコンテナの展開を拡張する次の新機能があります：
- Windows Server 2016 Technology Preview上のWindows Serverコンテナのコンテナ管理のプレビュー
詳しくは、「Windows Serverコンテナとは」を参照してください。
Container Management Supplemental Pack
注：
Container Management Supplemental Packは非推奨であり、将来のリリースで削除される予定です。
Container Management Supplemental Packでは、次のものが提供されます。
監視および可視性： Dockerのホスティングに使用されている仮想マシンと、仮想マシン上の実行中のコンテナを確認できるようになります。
診断：転送されるネットワークポートや発信元のDockerイメージ名などの基本的なコンテナ情報にアクセスできます。この機能は、インフラストラクチャおよびアプリケーションレイヤーに影響を与える可能性がある場所の問題を迅速に調査するのに役立ちます。
パフォーマンス：その仮想マシンで実行されているコンテナの詳細情報を確認できます。オペレーティングシステムから提供される情報に応じて、コンテナで実行されているプロセスおよびアプリケーションと、消費されたCPUリソースに関する情報が提供されます。
アプリケーションの制御：を使用して、アプリケーションコンテナを開始、停止、および一時停止（オペレーティングシステムでサポートされている場合）して、問題のあるアプリケーションを迅速に終了できます。
注：
では、を使用したサプリメンタルパックのインストールがサポートされています。を使用したサプリメンタルパックのインストール方法について詳しくは、ドキュメントを参照してください。xe CLIを使用してインストールする場合は、『 Supplemental Packs and the DDK Guide』を参照してください。
Dockerについて
Dockerは、開発者およびシステム管理者が配布アプリケーションを構築、出荷、および実行するためのオープンプラットフォームです。Dockerコンテナは、アプリケーションとその依存関係のみで構成されます。これは、ホストオペレーティングシステムのユーザースペースで分離されたプロセスとして実行され、ほかのコンテナとカーネルおよび基本ファイルシステムを共有します。詳しくは、「https://www.docker.com/whatisdocker」を参照してください。
注：
コンテナ管理機能はDocker環境を補足しますが、代わりになるものではありません。仮想マシンの個々のDocker Engineインスタンスは、利用可能な多くのDocker管理ツールの1つによって管理できます。
Linux VMでのコンテナの管理
Linux VMでDockerコンテナを実行するには、最初にLinux VMをコンテナ管理用に準備します。この機能は、Debian 8およびRHEL/CentOS/OEL 7の仮想マシンでのみサポートされます。
Linuxゲストを手動で準備するには、次の手順に従います：
-
仮想マシンにLinux向けCitrix VM Toolsがインストールされ、ネットワークの要件とセキュリティの説明どおりに仮想マシンネットワークが構成されていることを確認します。
-
仮想マシン内にDocker、Ncat、およびSSHDをインストールします。
RHEL/CentOS/OEL 7の場合：
yum install docker nmap openssh-server <!--NeedCopy--> -
docker.serviceの自動起動を有効にします。
systemctl enable docker.service <!--NeedCopy--> -
docker.serviceを起動します。
systemctl start docker.service <!--NeedCopy-->コンテナ管理には非ルートユーザーを使用します。Dockerへのアクセスを提供するために、ユーザーを「docker」グループに追加します。
-
コンテナ管理用に仮想マシンを準備します。プール内のいずれかのホストのコントロールドメイン（dom0）で次のコマンドを実行します：
xscontainer-prepare-vm -v vm_uuid -u username <!--NeedCopy-->ここで、
vm_uuidは準備する仮想マシンで、usernameはコンテナ管理で管理アクセスに使用する仮想マシンのユーザー名です。
準備スクリプトにより、プロセスがガイドされ、この仮想マシンのコンテナ管理が自動的に有効になります。
注：
プール間でコンテナ管理された仮想マシンを移行すると、コンテナ管理は仮想マシンに対する動作を停止します。これは、コンテナ管理がプール固有のキーを使用して実装されているため起こります。コンテナ管理機能を再度有効にするには、
xscontainer-prepare-vmコマンドを再実行します。このコマンドの実行後でも、移行前のプールが仮想マシンにアクセスし続けることがあります。
Dockerコンテナコンソールおよびログへのアクセス
Linux仮想マシンの場合、ではユーザーがDockerコンテナで実行されているアプリケーションを管理し、監視するためにコンテナコンソールにアクセスし、ログを表示することができます。を使用してコンテナコンソールとログにアクセスするには、以下の手順に従います。
-
［リソース］ ペインでコンテナを選択します。
-
［コンテナの全般プロパティ］ で ［コンソールの表示］ をクリックし、コンテナコンソールを開きます。コンソールログを表示するには、［ログを表示］ をクリックします。これにより、を実行しているマシンでSSHクライアントが開きます。
-
確認メッセージが表示されたら、仮想マシンのユーザー名とパスワードを使用してSSHクライアントにログインします。
注：
公開/秘密SSHキーを構成することで、認証プロセスを自動化できます。詳しくは、以降のセクションを参照してください。
認証プロセスの自動化（オプション）
コンテナコンソールとログにアクセスする場合、仮想マシンのログイン資格情報を入力してSSH接続を認証する必要があります。ただし、この認証プロセスを自動化して、手動による資格情報の入力を省略できます。自動認証プロセスを構成するには、以下の手順に従います：
-
公開/秘密キーのペアを生成します。
-
コンテナを実行している仮想マシンのユーザーディレクトリに公開SSHキーを追加します。
RHEL/CentOS/Oracle Linux 7およびDebian 8で実行されているコンテナの場合、
~/.ssh/authorized_keysに公開キーを手動で追加します。 -
を実行しているマシンの
%userprofile%ディレクトリに秘密SSHキーを追加し、キーの名前をContainerManagement.ppkに変更します。
Linuxベースのオペレーティングシステムでの認証
のコンテナ管理では、コンテナ管理仮想マシンでの認証のために、プール固有の4096ビットの秘密/公開RSAキーペアが使用されます。秘密キーは、コントロールドメイン（dom0）に格納されます。各公開キーは、クラウド構成ドライブまたは~user/.ssh/authorized_keysファイルを使用して、準備中にコンテナ管理仮想マシンに登録されます。すべての秘密/公開キーペアと同様に、公開キーによってすべてのコンテナ管理仮想マシンにパスワードなしでアクセスできるため、公開キーを安全に保持する必要があります。これには、現在管理されている仮想マシンと過去に管理されていた仮想マシンの両方が含まれます。
のコンテナ管理では、仮想マシン内で実行されているCitrix VM Toolsによって提案されたIPアドレスを使用して、コンテナ管理仮想マシンへのアクセスが試行されます。最初の接続後に、によってコンテナ管理仮想マシンの公開キーが格納され、以降の接続時にキーが一致するかどうかが検証されます。提案されたIPを使用してコンテナ管理仮想マシンのみにアクセスできることを確認します（IPソースガードなどの手段を使用）。ネットワークトポロジがこれを保証できない場合、管理者が、仮想マシンへの最初の接続時にコンテナ管理で取得したSSHホストキーを確認することをお勧めします。
このキーには、次のコマンドを使用してアクセスできます：
xe vm-parm-get-uuid=vm_uuid param-name=other-config /
param-key=xscontainer-sshhostkey
ここで、vm_uuidは仮想マシンのUUIDです。
注
コンテナ管理とDockerを使用する場合は、次の点に注意してください。
- コンテナの名前を変更しても、コンテナ管理ビューのアップデートはトリガーされません。つまり、では、現在の（名前変更/一時停止/一時停止解除された）コンテナの状態が表示されない場合があります。根本的な原因は、ビューがDockerイベント通知によってのみ更新されることです。回避策として、同じ仮想マシン上の無関係なコンテナで操作（開始や停止など）を実行することで、更新をトリガーできます。
Windows Serverコンテナとは
Windows Serverコンテナは、Windows Server 2016ゲストオペレーティングシステムの一部です。これらにより、プロセスが独自の名前空間に分離されて、Windowsアプリケーションをカプセル化できます。コンテナ管理は、Windows Server 2016ゲストオペレーティングシステムでWindows Serverコンテナの監視と管理をサポートします。
Windows Serverコンテナの管理
注：
TLSサーバー証明書は特定のIPアドレスにバインドされるため、TLS通信用の1つまたは複数の静的IPアドレスを使用してWindows Server 2016仮想マシンを構成する必要があります。
コンテナ管理用にWindows Serverコンテナを準備するには、次の手順に従います。
-
仮想マシンにWindows向けCitrix VM Toolsがインストールされ、ネットワークの要件とセキュリティの説明どおりに仮想マシンネットワークが構成されていることを確認します。
-
Microsoft社のドキュメントの説明に従って、仮想マシン内にWindows Serverコンテナのサポートをインストールします。Windows ServerコンテナはHyper-Vコンテナではありません。
-
以下の内容の「
daemon.json」という名称のファイルをフォルダー「C:\ProgramData\docker\config」に作成します：{ "hosts": ["tcp://0.0.0.0:2376", "npipe://"], "tlsverify": true, "tlscacert": "C:\ProgramData\docker\certs.d\ca.pem", "tlscert": "C:\ProgramData\docker\certs.d\server-cert.pem", "tlskey": "C:\ProgramData\docker\certs.d\server-key.pem" } <!--NeedCopy--> -
コンテナ管理用に仮想マシンを準備します。プール内のいずれかのホストのコントロールドメイン（dom0）で次のいずれかのコマンドを実行します：
オプション1（シングルユーザーVMの場合）：を使用して、この仮想マシンのTLS証明書を生成します。
重要：
このオプションは、単一ユーザーのみが仮想マシンにアクセスできる場合にのみ安全です。TLSサーバーとクライアントキーは、仮想CDを使用して仮想マシンに挿入されます。この情報は、準備中に悪意のあるユーザーによってコピーされる危険があります。
xscontainer-prepare-vm -v vm_uuid -u root --mode tls --generate-certs <!--NeedCopy-->ここで、vm-uuidは準備する仮想マシンです。画面の指示に従って、Windows Serverコンテナの準備プロセスを完了します。これには、dom0および仮想マシンとの相互通信が含まれます。
オプション2：外部で生成されたTLS証明書を使用してを構成します。
xscontainer-prepare-vm -v vm_uuid -u root --mode tls \ --client-cert client_cert --client-key client_key --ca-cert ca_cert <!--NeedCopy-->ここで、vm_uuidは準備する仮想マシンで、client_certはTLSクライアント証明書で、client_keyはTLSクライアントキーで、ca_certはCA証明書です。
Windowsサーバーコンテナの認証
では、Windows Serverコンテナの監視および制御にTLSが使用されます。このインスタンスでは、はTLSクライアントとして動作し、Windows Server仮想マシンはTLSサーバーとして動作します。キーはDom0と仮想マシンの両方に格納されます。
重要：
- クライアントキーは、仮想マシン上のDockerにパスワードなしでアクセスできるため、安全に保持する必要があります
- サーバーキーによって仮想マシンへの監視接続が認証されるため、サーバーキーを安全に保持する必要があります。
のコンテナ管理で–generate-certsオプションを使用してTLS証明書とキーが生成されると、特定のプールおよび仮想マシン用に一時的なCA、サーバー、クライアントの証明書が生成されます。証明書ではsha256ハッシュが使用されます。また、証明書は最大で2×365日間有効で、その日数が過ぎると準備を繰り返す必要があります。TLS接続は、常にAES128-SHA暗号を使用して確立されます。
ネットワークの要件とセキュリティ
重要：
コンテナ管理を機能させるために、ネットワークの分離に関するセキュリティ要件を緩和する必要がある場合があります。
仮想化環境の最大限のセキュリティを実現するために、仮想マシンからの管理ネットワーク（コントロールドメインを使用）を分離して、管理者がネットワークをパーティション化することをお勧めします。
コンテナ管理を有効にするには、これらの2つのネットワーク間のルートが必要ですが、これにより、管理ネットワーク（つまり、dom0）を攻撃する不正な仮想マシンのリスクが増大します。仮想マシンと管理ネットワークの間のトラフィックを許可するリスクを軽減するために、信頼できるソースのみが2つのネットワーク間の接続を開始できるようにファイアウォールルールを構成することをお勧めします。
次の場合、この機能を実稼働環境で使用しないでください。
- ここで推奨されるネットワーク構成がリスクプロファイルと一致しない場合
- 特定の使用シナリオで十分にこのルートを確保するために必要なネットワークまたはファイアウォールの専門知識が不足している場合
ネットワークのパーティション化とファイアウォール
そのほかの仮想マシンと同様に、必要な分離を実現するため、コンテナ管理仮想マシンをの管理ネットワークに直接接続しないでください。
コンテナ管理を機能させるには、のコントロールドメイン（dom0）から管理されている仮想マシンに到達できる必要があります。Linuxベースのオペレーティングシステムのコンテナを監視するには、ネットワーキングトポロジおよびファイアウォールが、dom0からコンテナ管理仮想マシンへのアウトバウンドSSH接続を許可する必要があります。Windows Serverコンテナを監視するには、ネットワーキングトポロジおよびファイアウォールが、dom0からコンテナ管理仮想マシンへのアウトバウンドDocker TLS（宛先TCPポート2376）接続を許可する必要があります。
仮想マシンと管理ネットワークの間のトラフィックを許可するリスクを軽減するために、すべてのトラフィックが外部のステートフルなファイアウォールを通過する必要があります。このファイアウォールは、特定のビジネスおよびセキュリティの要件に従って、専門家が手動で設定および構成する必要があります。
次のセクションで構成例を示します。
ネットワーク間の接続を保護するため、次のようにします。
- 管理ネットワーク（dom0など）と仮想マシンネットワーク（コンテナ管理仮想マシンなど）の間のすべての接続を無効化します。
次のように、コンテナ管理を有効化するための例外を追加します。
-
Linuxベースのオペレーティングシステムを監視するには、dom0でコンテナ管理仮想マシンへのアウトバウンドSSH（TCPポート22）接続（NEWとESTABLISHEDの両方）を許可します。
-
Windows Serverコンテナを監視するには、dom0でコンテナ管理仮想マシンへのアウトバウンドDocker TLS（TCPポート2376）接続（NEWとESTABLISHEDの両方）を許可します。
-
dom0によって開始された（ESTABLISHED）SSHおよびDocker TLSの接続に対するコンテナ管理仮想マシンの応答を許可します。