ASE v2 について書いたし、そろそろぶちぞう RD に後のことを任せて寝るかと思っていたら、突然 Azure Container Instances という新しいサービスが発表されました。コンテナと聞いたら寝るわけにはいかないので、例によって興味のある部分だけサクッと試しました。
まずは公式情報がいろいろと出てきているので、しっかりと目を通しておくべきです。要約すると Azure Container Instances こそ真の Container as a Service ということです。
ASE v2 よりもドキュメントが充実している気がします。しっかりと Linux と Windows に対応していますし、コンテナ間の分離にはハイパーバイザが使われているともあります。
要するに Hyper-V Container が使われているということでしょう。
何はともあれ触ってみたいという人は、Azure Cloud Shell に Container Instances 対応の Azure CLI 2.0 がインストールされているので、そこから簡単に試せます。Quick Start を読めば誰でも作れます。
一応 Azure Portal からも作れるようになってるみたいです。
そして気になる課金ですが、コンテナ作成リクエストと秒単位の課金で CPU コア数、そしてメモリ量によって決まります。ガンガン使ってガンガン捨てるような運用が容易です。
Pricing - Container Instances | Microsoft Azure
そして一番重要なポイントとしては Hyper-V Containers がおそらく使われているので、Windows Server Containers の面倒な制約を受けることなく、安全に Windows Containers を使うことが出来ることです。
まさに Windows Containers の実運用に必要なサービスが出てきたと感動しています。これからは ASP.NET アプリケーションも Dockernize して動かす時代になる、と思っています。
Azure Container Instances の特徴
最近は Windows Containers のクラスタ周りで苦しんでいたので、思いを書きすぎました。Azure Container Instances の何が素晴らしいのか、もうちょっと具体的に書きます。
- クラスタレス
- 高速なコンテナの起動
- 秒単位での課金
- ハイパーバイザで分離された実行環境
- CPU / メモリの柔軟な割り当て
- Linux / Windows に対応
どれを取っても最高ですね。要するに Hyper.sh と直接競合するサービスだと思います。
これまで Function as a Service が Serverless だと良く言われてきましたが、実際にホストするサーバーを全く意識することなく使える Container Instances や Hyper.sh こそが Serverless だと私は思っています。
喋りすぎなので、実際に Container Instances を使って Windows Server Core で動作する ASP.NET アプリケーションをデプロイしてみます。
Container を作成する
Cloud Shell とビルド済みのイメージがあれば、1 コマンドを実行するだけでデプロイ可能です。注意するポイントは --os-type で Windows を指定することです。
使用する Docker Image は AppVeyor を使って自動ビルドを行っている ASP.NET MVC アプリケーションです。本当に Windows Containers に欠けていたものは実行環境だけでした。
az container create -g ContainerInstance-RG --name aspnetapp --location westus \ --image shibayan/appveyor-aspnet-docker:master-19 --ip-address public --os-type Windows
外部からアクセスするように IP アドレスは公開を指定して実行しました。
すると以下のエラーが表示されてしまいました。エラーメッセージを読むと Windows の場合には最低でも 2 コアと 3.5GB メモリを指定する必要があるらしいです。
The resource requirments '{"requests":{"memoryInGB":1.5,"cpu":1.0}}' is invalid. Windows containers can only request 2 CPU and 3.5GB memory.
なので --cpu と --memory を追加してコマンドの実行をやり直します。
az container create -g ContainerInstance-RG --name aspnetapp --location westus \ --image shibayan/appveyor-aspnet-docker:master-19 --ip-address public --os-type Windows --cpu 2 --memory 3.5
今度はすんなりと上手くいって、すぐに確保された IP アドレスを含む情報が表示されました。
まだこの時はコンテナの作成中なので IP アドレスにアクセスしても何も返ってきません。作成が完了したかを知るためには別のコマンドを使います。
Container Status を確認
作成リクエストを投げたコンテナの状態を知るためには container show コマンドを使います。名前とリソースグループ名を指定するだけの、非常に簡単なコマンドです。
az container show -n aspnetapp -g ContainerInstance-RG
実行するとステータスなどを含む JSON が表示されるので、ProvisioningState の値が Succeeded になっていることを確認すれば OK です。
このコマンドの実行結果には docker 周りのイベントログも出てるので、以下のようなクエリを使うと簡単に見ることが出来ます。
az container show -n aspnetapp -g ContainerInstance-RG --query "containers[0].instanceView.events"
docker pull などに、どのくらい時間がかかっているかを簡単に把握できます。
関係ないですが、同じ Docker を使った App Service on Linux は簡単にログを確認する方法が用意されていないので、GA までには Azure Portal から確認できるような機能が欲しいと思ってますし、要望もしてます。
Public IP にアクセス
コンテナの作成が完了後に Public IP にブラウザからアクセスすると、少し後に見慣れた ASP.NET MVC アプリケーションのページが表示されました。
手順としてはコマンドを 2 回打ち込んだだけです。本当にたったこれだけで ASP.NET アプリが動いてます。
非常に簡単にコンテナのデプロイが行えるので、Azure Container Service を使ってクラスタから作成していた部分を全てスキップして、アプリケーションの開発をデプロイのみに集中することが出来そうです。
ただし実際に本番、運用環境で使う場合にはオーケストレーターが必要となります。何故なら作成したコンテナはイミュータブルであり、後からイメージのアップデートなどは出来ないからです。
オーケストレーションについて
Azure Container Instances 自体は Swarm や Kubernetes のようなオーケストレーション機能は持っておらず、非常に低レベルなコンテナを実行することに特化したサービスとなっています。
サンプルとして用意されている aci-connector を使うと、Kubernetes と Container Instances をシームレスに統合することが出来るようです。
個人的な認識としては Container Instances はコンテナ版 Cloud Services に近いかなと思います。各サービスの土台となるようなサービスという印象です。
まだプレビューリリースされたばかりの新しいサービスですが、今後の Microsoft と Azure が本気でコンテナに注力していることが分かりますね。私は Azure 最高の素晴らしいサービスだと思います。
