Azure Stack環境でカスタムLinuxイメージ(オンプレミスで作っておいたLinux OSのVHDファイル)から仮想マシンを起動しようとしたとき、仮想マシンの作成自体はうまくいくものの起動状態にならなかった場合、WALinuxAgentのバージョンが古いことが問題の可能性があります。 たとえpublic Azure環境では起動できるVHDファイルだったとしてもAzure Stack環境では動かない可能性あるらしく、ドキュメントにも記載があります。
WALinuxAgentのバージョン2.2.2以上が必要です。かつ、2.2.12 や 2.2.13など特定のいくつかのバージョンは動かないとあります。WALinuxAgent 2.2.2のリリースは2017年1月なので古いといえば古いバージョンですが、念の為うまくいかないときはチェックするといいかもしれません。
これであっているか自信ないのですがとりあえずメモしておきます。
Microsoft Azure Stack*1にAzure CLIで接続したい場合、managementAPIのエンドポイントを指定してcloudを登録します。名前は自由なので、複数Azure Stack環境がある場合などは適宜わかりやすい名前をつけましょう。
$ az cloud register -n AzureStackExample --endpoint-resource-manager "https://management.azurestack.example.com" --suffix-storage-endpoint azurestack.example.com
とりあえず上の2つのエンドポイントだけでよさそうですが、他にも指定できるパラメーターはあるようです。上の例はAzure Stackのユーザー環境を登録している想定で、下のドキュメントの手順1-bに相当します。また、Azure Stack環境の場合は、VPN接続が〜というあたりのドキュメントは無視してよさそうです。
次にここで登録したcloudを指定して接続先を切り替えます。
$ az cloud set -n AzureStackExample Switched active cloud to 'AzureStackExample'. Active subscription switched to 'XXXX (UUID)'.
これでログインできてコマンド実行できるはずですが、1つ忘れてはいけないことがあります。Azure Stack側で提供しているARM Rest APIのバージョンは古いらしく、コマンドを実行するとエラーになることがあります。そのため下記コマンドをまず実行しておく必要があります。
$ az cloud update --profile 2017-03-09-profile
なおこのコマンドは現在Activeなcloudに対して処理が行われます。現在利用可能なcloudの一覧は次のコマンドでリストできます。
$ az cloud list Name Profile IsActive --------------------- ------------------ ---------- AzureCloud latest AzureChinaCloud latest AzureUSGovernment latest AzureGermanCloud latest AzureStackExample 2017-03-09-profile True
AzureStackExample以外はデフォルトで利用可能なものです。そのため、例えばAzure Germanyを利用したい場合はazure cloud set -n AzureGermanCloudと実行するだけでよいです。
あとはログインです。次のコマンドを実行して、Azure Stack環境にログインする際の認証情報でログインすればOKなはずです。
$ az login To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code XXXXXXXXXXXX to authenticate. CloudName IsDefault Name State TenantId ------------------ ----------- ----- ------- ---------- AzureStackExample True NNNN Enabled UUID
*1:Azure Stack Development Kitではなく、ポータルやAPIエンドポイントをインターネットに公開できる方
MVPグローバルサミットに参加している最中に新元号対応が気になったのでマイクロソフトのエンジニアに聞いてみたら、publicなissueで議論しようということだったので立ててみました。するとあっという間に回答が来たので、日本語で簡単にまとめてみようと思います。
なお、ここでの新元号対応は、新元号が追加された後、どんなライブラリが更新されたら.NET Coreにおいて新元号が適用されるかという話であり、だれがいつそのライブラリを更新するかという話ではありません。
.NET Coreは国際化対応の一貫として日本の元号にも対応しています。具体的にはSystem.Globalization.JapaneseCalendarが日本の元号に対応しているカレンダーになります。元号という概念は、ロケールによらずeraという概念で管理しているのですが、そもそも.NET Coreが対応しているロケールのうちこのeraを複数持っているのはJapaneseCalendarとそれに依存いているJapaneseLunisolarCalendar (太陰暦) となっています。従って、.NET Coreのライフサイクルの間に追加されるイベントも、現時点での日本の元号でしか発生しないということになります。
さて、.NET Coreで新元号が対応可能になるトリガーはWindowsとUnix(LinuxとMacOS)でことなります。これは、カレンダーの実装がプラットフォームごとにことなるものに依存しているためです。Windowsの場合は、.NET Frameworkと同じくレジストリに依存しています。つまりレジストリが更新されれば、そのOS上で動く.NET Coreのアプリは新元号に対応することになります。原理的には、ビルドしたときのマシンが対応していなくとも、もしくは対応する前にビルドした古いバイナリでも、レジストリに追加されたマシンで実行すれば新元号に対応するはずです。
https://msdn.microsoft.com/ja-jp/library/windows/desktop/dd317805%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396msdn.microsoft.com
また、レジストリの追加に関してはすでにテストケース対応済とコメントされています。
一方、Unixの場合、元号を含んだ国際化の情報はlib-icuというライブラリに依存いています。
従って、新元号に対応したICU ライブラリに更新すれば、.NET Coreアプリも対応することになります。対応したライブラリがリリースされたら.NET Coreでもテストを追加するとコメントされています。
.NET Coreには一応、Windowsではレジストリからの取得に、UnixではICUライブラリからの取得に失敗した場合のフォールバックとして、ソースコード中にハードコードされた元号情報が含まれています。
一応と書いたのは、これはあくまで何か想定しないことが起きた時のためのもので、コメントによるとこのハードコードされた情報が利用されることは基本的に想定していないということです。従って、この情報が使われるユースケースは考えなくていいわけなんですが、もし使われることがあるとすると、フレームワーク依存とself-containedで挙動が変わることが想定されます。フレームワーク依存型の場合、実行する環境の.NET Coreランタイムのハードコーティング部分が新元号対応済であれば、このフォールバックが働いた場合でも新元号に対応します。一方、self-containedの場合、ラインタイムもアプリと一緒に含まれているため、新しい元号に対応していない状態でビルドしたアプリは、このフォールバックの仕組みが働く限り永遠に新しい新元号に対応することはありません。
.NET Coreに新元号対応を期待する場合、Windowsであればレジストリの更新、UnixであればICUライブラリの更新が行われることが前提条件となります。
