しばたテックブログ

気分で書いている技術ブログです。

Insider PreviewでのDockerイメージの取得方法

Windows Docker

小ネタ、兼、備忘録です。

ちょっとWindows Server 2019 insider previewでWindows Server Containerを試す必要があり、Dockerイメージを取得するためにググったところVirtualization Blogのこんなエントリを見つけたので紹介します。

blogs.technet.microsoft.com

細かい話はこちらを見てください。

Dockerイメージのビルドバージョン

Windows Server ContainerとHyper-V Container(特にWindows Server Container)ではホストOSのバージョンとDockerイメージのOSバージョンを合わせておく必要があり、定期的に更新されるInsider previewではバージョンを合わせるのは結構面倒です。
このため上記のVirtualization Blogの内容は結構役に立つことになります。

一応補足としてバージョン間の互換性へのリンクを記載しておきます。

docs.microsoft.com

Insider previewでのDockerイメージ取得

基本的にはVirtualization Blogからの引用ですが、本エントリでは併せてServer Core Insider、Nano Server Insiderのイメージ取得コマンドも載せておきます。

# レジストリからOSビルドバージョンを取得し、バージョンタグを生成
$winver = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\'
$versiontag = "$($winver.CurrentMajorVersionNumber).$($winver.CurrentMinorVersionNumber).$($winver.CurrentBuildNumber).$($winver.UBR)"

# ホストバージョンと合わせた Windows 10 Insider Build?イメージの取得
docker pull mcr.microsoft.com/windows-insider:$versiontag

# ホストバージョンと合わせた Windows Sever Core Insider イメージの取得
docker pull mcr.microsoft.com/windowsservercore-insider:$versiontag

# ホストバージョンと合わせた Nano Server Insider イメージの取得
docker pull mcr.microsoft.com/nanoserver-insider:$versiontag

各イメージは、当初はDocker Hubにあった様ですが、いまはMicrosoft独自のレジストリであるmcr.microsoft.com*1から取得する必要があります。

このレジストリはUIが無くイメージの検索もできず詳細はよくわかりません...
ただ一部のイメージについてはDocker Hubに対応しているビルドバージョンが記載されているので参考としてリンクを貼っておきます。

ちなみに、イメージによっては名前に-insiderが付いていてもDocker Hubから取得する必要のあるイメージもありレジストリの完全移行はできていない様です。

今が過渡期なのか移行の予定がないのかははっきりしませんが、しばらくは不便な状況が続きそうなので我慢するしかないのかな、といったところです。

補足

もとのVirtualization Blogにしれっと出てるwindows-insiderイメージですが、こいつに関しては何気に情報がありません。
ざっと調べたところ山市さんのブログがヒットしましたが、こちらでもやっぱり謎の様です...

yamanxworld.blogspot.com

【2018/10/07追記】補足2

Microsoft Container Registry(mcr.microsoft.com)とwindows-insiderイメージについていくつか参考になる記事を見つけたのでリンクしておきます。

blogs.technet.microsoft.com

stefanscherer.github.io

細かい内容はリンク先で確認していただきたいのですが、ざっくり、

  • Microsoft Container Registryは新しいOSイメージ専用としている
  • windows-insiderイメージはOSの機能ほぼ全部入りのイメージで、例えばUIテストの自動化などといった自動化処理向けのイメージ

を押さえておけば良いかと思います。

*1:おそらくMicrosoft Container Registryと思われるが詳細不明。

PowerShell CoreのWindows PowerShell互換性とWindowsCompatibilityモジュールについて

PowerShell

先日リリースされたPowerShell Core 6.1の新機能一覧に、以下の様にWindows PowerShellに対する互換性について記載されています。

On Windows, the .NET team shipped the Windows Compatibility Pack for .NET Core, a set of assemblies that add a number of removed APIs back to .NET Core on Windows.

We've added the Windows Compatibility Pack to PowerShell Core 6.1 release so that any modules or scripts that use these APIs can rely on them being available.

The Windows Compatibility Pack enables PowerShell Core to use more than 1900 cmdlets that ship with Windows 10 October 2018 Update and Windows Server 2019.

Windows PowerShellに対する互換性について

この内容にあるとおりPowerShell Core 6.1にはWindows Compatibility Pack for .NET Coreのアセンブリが取り込まれており、もうすぐリリース予定のWindows 10 October 2018 Update(RS5, 1809)とWindows Server 2019においては1900以上の(Windows PowerShell向け)コマンドレットがPowerShell Coreでも利用可能になるそうです。

これらの新しいOSにおいては、これまで機能は追加されたものの一切設定がされていなかったモジュールのPSEditionパラメーターが設定され、この内容にCoreが含まれているモジュールはPowerShell Core 6.1(以降)から呼び出すことが可能です。

例としてWindows Server 2019 Insider preview build 17744の環境にPowerShell Core 6.1をインストールして

Get-Module -ListAvailable -PSEdition Desktop

を呼び出しみると下図の様にC:\Windows\system32\WindowsPowerShell\v1.0\Modules配下にあるWindows PowerShell向けの各種モジュールが利用可能になっていることが確認できます。

f:id:stknohg:20180930203209p:plain

(PSEditionの欄がCore,Desk(top)とCoreも追加されている点に注目)

このため例えばNetAdapterモジュールにあるGet-NetAdapterコマンドレットもふつうに呼び出して利用することが可能です。

f:id:stknohg:20180930203229p:plain

ちなみに、新しいOSであってもPowerShell Core 6.0ではダメですので注意してください。

f:id:stknohg:20180930203301p:plain

WindowsCompatibilityモジュールについて

新しいOSであればPowerShell CoreとWindows PowerShellの互換性が大幅に増したことはわかりましたが、残念ながら古いOSにおいてはPowerShell Core 6.1(以降)でも互換性は従来のまま変わりません。

この問題を解消するためにPowerShell TeamによってWindowsCompatibilityというモジュールが提供されています。

github.com

このモジュールはもともと前項の互換性の向上で対応しきれない部分を補完するために作られた様なのですが、古いOSにおける互換性の向上にも使うことができ、こちらの用途の方か多く使われそうな雰囲気を感じます。

【2018/11/16追記】

本日このモジュールのVer.1.0.0がGAされ、PowerShell Team Blogでより詳細な情報が発表されました。

blogs.msdn.microsoft.com

こちらの内容も参考になりますのでぜひご覧ください。

【追記ここまで】

インストール

このモジュールはPowerShell Galleryからインストール可能です。

Install-Module WindowsCompatibility -Scope CurrentUser

使い方

このモジュールの基本的な使い方は、Import-WinModuleコマンドで利用したいWindows PowerShell向けのモジュールを読み込むとそのモジュールの機能が利用可能になります。

例として先述のNetAdapterモジュールにあるGet-NetAdapterコマンドレットを使いたい場合は、

# Import-WinModuleでWindows PowerShell向けのモジュールを読み込む
Import-WinModule NetAdapter

# あとは使いたい機能を利用する
Get-NetAdapter

f:id:stknohg:20180930211039p:plain

(一部結果の表示がおかしくなっているが、プロパティの値は取得できている)

この他にWindows PowerShellのランタイム上でスクリプトブロックを実行してその結果を返すInvoke-WinCommandといった機能もあります。

# Windows PowerShell上でスクリプトブロックを実行
Invoke-WinCommand -ScriptBlock { $PSVersionTable }

f:id:stknohg:20180930211157p:plain

ほかにもまだいくつか機能はあるのですが、本エントリではこのくらいにしておきます。
細かい説明説明はQuick Start Guideを参照してください。

補足

先ほどの例でもそうでしたが、Import-WinModule使ってインポートしたモジュールは完全に互換があるわけではなく、一部表示などに問題がでる様です。
もしこの様な不具合が出た場合はInvoke-WinCommandを使う方が良いでしょう。

# 例えば表示がおかしい場合はInvoke-WinCommand内で調整して対応することが出来る
# ※対応方法はケースバイケースであるが...
Invoke-WinCommand { Get-NetAdapter | Out-String }

f:id:stknohg:20180930211834p:plain

WindowsCompatibilityモジュールの仕組み

このモジュールの仕組みについてですが、仕組みそのものは割と単純です。

ローカルホストのWindows PowerShellに対してリモートセッションをひとつ張り、PowerShell Remotingの機能を使いWindows PowerShell側の機能を利用しています。

このため、このモジュールの使用中は専用のPSSessionが一つ存在しています。

f:id:stknohg:20180930205622p:plain

そして内部処理を簡単にコードで表すと以下の様な感じになります。

# WindowsCompatibilityモジュールの基本イメージ

# ローカルホストのWindows PowerShellに対してリモートセッションを張る
$session = New-PSSession -ComputerName localhost -ConfigurationName 'Microsoft.PowerShell' -EnableNetworkAccess

# Import-WinModuleの処理イメージ
Import-Module NetAdapter -PSSession $session
Get-NetAdapter

# Invoke-WinCommandの処理イメージ
Invoke-Command -ScriptBlock { $PSVersionTable } -Session $session

最後に

ざっとこんな感じです。

PowerShell CoreのWindows PowerShellに対する互換性は日々向上していますので最新のPowerShell Coreをどんどん使っていくのが良いのではないかと思います。

Azure Cloud ShellのPowerShellがGAしました

Azure PowerShell

Ignite 2018に合わせてひっそりとGAがアナウンスされています。

azure.microsoft.com

すでにCloud ShellのBashはGAしてますので、これでCloud Shellが完全にGAしたことになります。

GAで何が変わったのか？

前に

blog.shibata.tech

でお伝えした様にCloud Shellの基盤であるコンテナはすでに統一されており、環境としてはBash、PowerShellどちらも差異のない状況でした。
このため環境および機能面でみればCloud ShellのPowerShellがGAしたからといって特に変わる点はありません。
単純コンソール左上の(PREVIEW)の表示が取れたくらいしかないと思います。

利用者目線でみればGAによって正式にサポート対象になったことが重要でしょう。
(ただCloud Shellのサポートって何だ？といわれると言葉に詰まりますが...)

AzureRMモジュールからAzモジュールへ

こちらはBash、PowerShell両方に関するはなしです。

(多分)今回のタイミングに合わせて今回のタイミングのちょっと前からCloud Shellで使用されるAzure管理用のPowerShellモジュールが、従来のAzureRM.NetcoreからAzに切り替わっていました。

www.powershellgallery.com

f:id:stknohg:20180925140705p:plain

このAzモジュールは簡単に言ってしまうと.NET Standard版のAzure PowerShell Moduleで、まだきちんとしたアナウンスがされていないため断言はできないのですが、従来のWinodws PowerShell版AzureRMモジュールと.NET Core版のAzureRM.Netcoreを統合するためのモノだと思われます。

現時点ではVer.0.2.2が最新であり、まだまだプレビュー版です。
GitHubのマイルストーンを見てもVer.1.0はかなり先になりそうな雰囲気です。

従来のモジュールに対してAzモジュールはコマンドレットの接頭語がAzであり、例えばサブスクリプションを取得するには

Get-AzSubscription (※ Get-AzureRmSubscription ではない)

を使います。
ただ、互換性を確保するために、従来の接頭語であるAzureRmがつくコマンドはエイリアスとして定義されている様です。

PS Azure:\> gal Get-AzureRmSubscription | select Name, Definition

Name                    Definition
----                    ----------
Get-AzureRmSubscription Get-AzSubscription

PS Azure:\> gal *AzureRm* | select Name, Definition

Name                                                   Definition
----                                                   ----------
Add-AzureRmAccount                                     Add-AzAccount
Add-AzureRmADGroupMember                               Add-AzADGroupMember
Add-AzureRmApiManagementApiToProduct                   Add-AzApiManagementApiToProduct
Add-AzureRmApiManagementProductToGroup                 Add-AzApiManagementProductToGroup
Add-AzureRmApiManagementRegion                         Add-AzApiManagementRegion
Add-AzureRmApiManagementUserToGroup                    Add-AzApiManagementUserToGroup

・・・(後略)・・・

このため、ふつうに使う分にはこれまでと同様なハズ...です。
(実際にどこまで互換性があるのかは検証してません。すいません...)

【訂正】切り替え時期について

ブログ公開当初、この切り替えはGAと同時かと記述してましたが、セルビアのMVPである@alexandairさんのツイートを見るに今月頭には既に切り替わっていた様です。

最後に

ざっとこんな感じです。

環境としてはGAしたものの肝心のモジュールは新しいとはいえプレビュー版でちぐはぐ感があります。
とはいえCloud Shellの環境は日々更新されますのであまり細かいことは考えない方が幸せになれそうです。