気が付いていなかったのですが、Azure Container Service のオーケストレータとして Kubernetes を選ぶと、Windows が選択できるようになっていたらしいです。もう 2 か月ぐらい前というのが驚きです。
まだ Public Preview になってないだろと思っていたら、ちゃんとドキュメントもありました。確か Swarm が Private Preview だったはずなんですが、いったいどこに行ってしまったのやら。
Windows Server Containers が使えるコンテナサービスを待望している人間としては、これは試しておかないといけないと思ったので、実際にクラスタを作成して試します。
Kubernetes クラスタを作成
Azure Portal から ACS を作成する際に Kubernetes を選ぶのは必須です。
例によって Japan East は VM が高いので、少し安い Japan West を選んでおきました。
次に Kubernetes のマスター向け設定を行います。マスターは Linux で動作するので SSH の公開鍵が必要です。そして Kubernetes が Azure のリソースを操作するために必要なサービスプリンシパルも設定します。
サービスプリンシパルは Azure CLI 2.0 を使うと簡単に作れます。*1
最後はエージェントの設定なので、ここで Windows を選びます。Windows を選ぶと RDP で接続するための認証情報を入力する必要があるので、適当に埋めておきます。
VM のサイズは中途半端にけちると苦労するので、デフォルトのままにしておきました。これでデプロイすると、Windows Server Containers 対応の Kubernetes が上がってきます。
Kubernetes への接続
Kubernetes への接続を行うためには kubectl と認証情報のダウンロードが必要らしいです。幸い Azure CLI 2.0 を使うと簡単にダウンロード出来るので、ドキュメントを紹介しておきます。
手元の PC には Azure CLI 2.0 を入れていなかったので、手動で kubectl をダウンロードして認証情報も SCP で拾ってきました。kubectl は単一の実行ファイルなので楽ですね。
kubectl と認証情報の設定が終わったので、接続テストとしてノードの情報を確認しておきました。
マスターとエージェントの情報が返ってきたので、認証情報に問題がないことが確認できました。
最初からコマンドで全て操作するのはしんどいので、Kubernetes のダッシュボードを使います。kubectl の proxy コマンドを使うとダッシュボードへの接続が行えます。
kubectl proxy
表示されたアドレスにブラウザでアクセスすると、Kubernetes のダッシュボードが表示されます。
Azure Container Service のドキュメントでは YAML ベースでデプロイを行っていましたが、折角なのでダッシュボードを使って試します。
アプリケーションをデプロイ
Kubernetes の用語については説明を省きますが、基本的に画面の指示通りに進めていけば問題ないです。
ナビゲーションからノードを選択すると稼働中のインスタンスとメトリックを確認できます。ECS はメトリックの表示に対応していなかったですが、Kubernetes はちゃんと確認することが出来て良いですね。
それはともかく、まずはアプリケーションをデプロイしてみます。デプロイするのは前回 AppVeyor で作成した ASP.NET MVC アプリケーションのイメージです。
JSON / YAML のアップロードも出来ますが、UI でポチポチ設定してみます。
重要な設定としてはサービスを外部にして、ターゲットポートを 80 に設定することです。
外部にしないと外からアクセス出来なくなりますし、作成したイメージは 80 でリクエストを待機しているので、ターゲットポートを間違えると繋がりません。
実際に配備を行うと、最初は例によってイメージの pull で時間がかかりました。これは ACS で使われている Windows Server 2016 のイメージが古いのが最大の原因だと思われます。
使われている Windows Server 2016 と Docker のバージョンは AppVeyor と比べて古いものだったので、公式らしく最新に追従する姿勢を見せてほしいところです。
ワークロードを選択すると、一度にステータスの確認が出来るので便利です。サービスを含め全てが緑色になればデプロイ完了なので、外部エンドポイントが表示されるようになります。
この外部エンドポイントは Azure Load Balancer を指しています。Load Balancer と Public IP Address は Kubernetes によって自動的に作成されていました。
外部エンドポイントにアクセスすると、前回作成した ASP.NET MVC アプリケーションが表示されました。
前に試した ECS よりも Kubernetes の方が Windows Server Containers への対応が進んでいる印象を受けました。まだ対応自体はプレビューですが、ダッシュボードから操作が行えるのは好印象です。
そろそろ Azure Container Service も Managed Disk を使って、いい感じにリソースを整理して欲しい気持ちでいっぱいです。あとベースイメージのバージョンアップは必須だと思います。
