IT・技術研修ならCTC教育サービス

サイト内検索 企業情報 サイトマップ

研修コース検索

コラム

Hyper-V の部屋

CTC 教育サービス

 [IT研修]注目キーワード   Python  UiPath(RPA)  最新技術動向  Microsoft Azure  Docker  Kubernetes 

第23回 Windows Server 2016の新機能、コンテナーを理解する (小塚大介) 2016年6月

前回の記事では、Windows Server コンテナーとHyper-V コンテナーを動かす環境の構築方法を紹介したので、今回はこれらのコンテナーの動きについて解説していきます。

この記事では、コンテナー ホスト/Windows Server コンテナー/Hyper-V コンテナーの3つの環境に対して、それぞれに接続した3つのPowerShellウィンドウを同時に起動しています。 また、この後のスクリーンショットをわかりやすくするため、PowerShellウィンドウの背景色を
コンテナー ホストは紺
Windows Server コンテナーは赤
Hyper-V コンテナーは緑
に設定しています。

fig01

プロセスの関係を理解する

最初に、作成済みの2種類のコンテナーを起動します。先の記事のとおりStart-Containerコマンドを使って起動し、Get-Containerコマンドを実行してStateがRunningであることを確認してください。

fig02

既に起動しているコンテナー ホストを入れると3つの環境が起動していることになります。

次に、それぞれ別なPowerShellウィンドウでEnter-PSSessionコマンドを実行して、コンテナー ホストとWindows Server コンテナー、Hyper-V コンテナー に接続します。

fig03

3つのPowerShellウィンドウそれぞれでGet-Processコマンドを実行してプロセスの一覧を実行します。

fig04

この結果で最初に注目しておきたいのはWindows Server コンテナーで表示されたプロセスの一部のID, SI (Session ID), ProcessNameがコンテナー ホストに表示されているものと一致している点です。以下のスクリーンショットの例ではWindows Server コンテナーに表示されているCExecSVCというプロセスはIDが5376、SIが2と表示されていますが、コンテナー ホストのプロセス一覧にも全く同じものが表示されています。

fig05

さらによく見ると、コンテナー ホストでSIが2と表示されるプロセスはWindows Server コンテナーと同じものが表示されていることが確認できます。コンテナー ホスト と Windows Server コンテナー の両方で Get-Process | Where SI -eq 2 などと実行してフィルタしてみると見えてくるのですが、この結果、Windows Server コンテナー上で実行したプロセスがコンテナー ホスト上で実行されていることを意味します。

fig06

一方、Hyper-V コンテナーで表示されるプロセスの一覧とコンテナー ホストで表示されるプロセスの一覧には全く共通点はありません。これはHyper-V コンテナーがHyper-Vの機能によってコンテナー ホストと完全に分離されているからです。コンテナーとして作成し、起動し、利用しているものの、動作の仕組みとしては仮想マシンに近くなっています。

ちなみに、Hyper-Vで仮想マシンを実行した場合、Hyper-Vホストでは実行中の仮想マシンと同じ数のvmwp.exe (Virtual Machine Worker Process) が動くのですが、Hyper-Vコンテナーを実行するとコンテナー ホストでvmwp.exeが動いていることが確認でき、Hyper-V コンテナーとHyper-V仮想マシンの動作原理が似ていることが理解できると思います。

fig07

プロセスの実行について確認するため、もう少し操作してみましょう。

最初にコンテナー ホストのPowerShellで再度プロセス一覧を表示します。もしくはTask ManagerのDetailsタブを見て、Ping.exeのプロセスが表示されていないことを確認しておきます。

fig08 fig09

次に Windows Server コンテナー に接続したPowerShellで

Ping bing.com -t と入力して実行し、明示的に停止するまでPingを繰り返します。

fig10

この状態でコンテナー ホストでプロセスの一覧を確認するとPing.exeが実行されていることが確認できます。

fig11 fig12

Windows Server コンテナーで実行しているPingをCtrlキー+Cで停止すると、コンテナー ホストでもPingプロセスが停止され一覧から消えることが確認できます。コンテナー ホスト側のプロセス一覧をTask Managerで確認している場合はPING.EXEの実行と停止のタイミングがWindows Server コンテナーでPingを実行するタイミングと完全に一致していることがわかると思います。

一方でHyper-V コンテナーでPingを実行した場合はコンテナー ホストのプロセス一覧にPingは表示されないことが確認できると思います。

コンテナーのネットワーク環境を理解する

次にコンテナーのネットワークについて確認していきます。それぞれのPowerShellでipconfigを実行してそれぞれのIPアドレスを表示します。

fig13

先の記事で、仮想スイッチを作成するときに、

New-VMSwitch -Name "Virtual Switch" -SwitchType NAT -NATSubnetAddress 172.16.0.0/12

とコマンドを入力して実行したので、各コンテナーにはDHCPにより172.16.0.0/12のサブネットからIPが自動付与されていることがわかります。また、各コンテナーで表示されるデフォルトゲートウェイのIPアドレスとコンテナー ホストに付与されているIPアドレスが同じことから、コンテナー ホストでNATが動作していると推測できます。

コンテナー ホスト上でNATの設定を確認するにはGet-NetNatコマンドを利用することができます。このコマンドでは先の仮想スイッチの作成時に指定したサブネット情報などが表示されます。

fig14

NATの動きをもう少し確認してみましょう。

Windows Server コンテナーかHyper-V コンテナーのどちらか、または両方でPing bing.com -tと実行します。その状態でコンテナー ホストでGet-NetNatSessionコマンドを実行します。すると、コンテナー ホスト上でNATが動作してIPアドレスやPortの変換を行っていることが理解できると思います。

fig15

コンテナーでIISなどを実行する場合、外部からIISにアクセスするためにはコンテナー ホストでNATのポートマッピングなどの設定をする必要があります。この方法は次の記事で紹介します。

これまでの手順ではNATタイプの仮想スイッチを作成していましたが、Hyper-V仮想マシンと同じ、通常の仮想スイッチも利用することができます。たとえば、Hyper-Vマネージャーで作成したスイッチに対してもコンテナーは接続できます。

fig16

設定方法に特別なことはなく、New-Containerコマンドの -SwitchNameオプションで事前にHyper-Vマネージャーで作成しておいた任意のスイッチ名を指定するだけです。

fig17

この場合コンテナーはNAT経由ではなく直接ネットワークに接続することになります。

fig18

ここまで見てきたように、コンテナーのネットワークは、仮想マシンと同じような動作をするので、それぞれのコンテナーがIPアドレスを必要としています。これからコンテナーを利用したアプリケーションの展開が一般化してくると、NATタイプの仮想スイッチを利用しないとIPアドレスの枯渇が発生するかもしれませんし、SDNとコンテナーネットワークの連携などが必要になってくることも考えられます。

ファイルシステムの動作を確認する

最後にファイルシステムの動作を確認しておきましょう。Hyper-V コンテナーが完全に分離されていて他に影響しないことは予想できると思いますが、Windows Server コンテナーがどのような動きになるのかに注目です。

まずはWindows Server コンテナーに接続しているPowerShellで New-Item -Path c:\ -Name WSConFolder -ItemType Directory と実行してCドライブの直下にWSConFolderというフォルダーを作成します。

fig19

続けてDir c:\と実行してCドライブ直下のディレクトリ情報を表示してフォルダーが作成できていることを確認します。

fig20

コンテナー ホストでCドライブ直下の状態を確認しましょう。これはPowerShellでもExploreで確認しても構いません。コンテナーで作成したWSConFolderがコンテナー ホストからは見えないことを確認します。

fig21

当たり前かもしれませんが、コンテナーの中で書きこんだフォルダーやレジストリはコンテナー ホストや他のコンテナーには影響しません。

ここまで見てきた通り、Windows Server コンテナーとHyper-V コンテナーはコンテナー同士やコンテナー ホストに影響を与えず独立した環境としてアプリケーションを実行することが可能です。しかも、仮想マシンと違ってコンテナー ホストや コンテナーイメージを共通のものとして利用することで、各コンテナーに必要なリソースを可能な限り最小化しています。さらにHyper-V コンテナー は、プロセスを実行する場所という意味でも仮想マシンに近い分離レベルを実現し、ほぼ完全にコンテナー ホストから切り離されていることが理解できたと思います。

次回はこれらの実際の利用シーンを想定したコンテナーの利用方法などを紹介していく予定です。

 


 

 [IT研修]注目キーワード   Python  UiPath(RPA)  最新技術動向  Microsoft Azure  Docker  Kubernetes