Azureにおける最古参の部類のサービスであるCloud ServicesがついにClassic扱いになり、代わりにAzure Resource Manager（ARM）対応版の Cloud Services (extended support) のPreviewが始まりました。というわけでちょっと8年ぶりぐらいにCloud Servicesを触ってみたいと思います。
概要
もともとAzure Cloud ServicesはAzure Service Manager（ASM）という古い（当初の）管理形態で提供されていて、ARMが出た後もうまくARMでラッピングはしてますが根本的には変わらずな状態で提供されていました。ASMもそろそろ終わりが見えてきたのでCloud Servicesはどうなるのかと思っていましたがまさかこのような対応になるとは…
さてそのCloud Services (extended support)ですが、詳細はこちらを参照。
- Build regionally resilient cloud services using the Azure Resource Manager
- Azure Cloud Services (延長サポート) のドキュメント | Microsoft Docs
歴戦のCloud Services猛者なら上記ドキュメントのFAQと前提条件をおさえておけば大丈夫でしょう。
Classicとの違い
主にFAQなどに書かれている内容ですが、軽く抜粋しておきます。
- リソースの種類
- Cloud Services (classic) –> microsoft.classiccompute/domainnames
- Cloud Services (extended support) –> microsoft.compute/cloudservices
- VNETが必要
- classicの時は内部的にVNETが展開されたり隠ぺいされてたので見えませんでしたが、extended supportでは明示的にVNETを作るか既存のものを指定する必要があります。（別リソースグループでも問題ないのはいいですね）
- ただLoad BalancerやNSG、ルートテーブルは同じリージョン、同じリソースグループでないとダメぽい。
- 展開するサブネットはCloud Services (extended support)専用にしましょう。他のサービスと同様。
- リモートデスクトップ用プラグインは使えないのでサービス構成ファイル（.cscfg）とサービス定義ファイル（.csdef）から削除します（リモートデスクトップはポータルから構成できる）。
- ExtraSmall/Small～やA5～A11などのVMサイズはStandard_A0～といったVMサイズ名に変更する必要があります。
- スロット（Production/Staging)などHosted Servicesの論理概念がなくなったので別extended supportを作ってVIPとしてタグ付けするような感じらしい
- 同様に論理的なHosted Servicesが無くなったので空のCloud Servicesを作るといったことはできない様子。
- 割り当て解除状態な停止は未サポート。（Stopped-Allocatedのみサポート）
- AZや複数クラスター、リージョンに跨ってスケーリングや展開は不可。
- 価格に違いは特にないけど、extended supportに必要なKey VaultとパブリックIPアドレスが別途必要になるのでそちらの料金が増える。
- 証明書の管理はKey Vaultに代わります。Key Vaultで証明書管理してCloud Servicesからは今までと同じように拇印を参照すればいいぽい。Cloud Serviesで直接管理していたのがKey Vault管理になっただけですね。（Key Vaultが同じリージョンにないとダメ）
あとKey Vault側はアクセスポリシーでVMのデプロイやARMテンプレートのデプロイから参照できるようにチェックしておく必要があります。
事前準備
さて実際にさわっていきたいと思います。Cloud Services (classic)を知っている前提＋手元にCloud Servicesなプロジェクトがあるものとします（なかったらVisual Studioで適当に作りましょう）。
最初に Cloud Services (extended support) を使う前にサブスクリプションにプロバイダーを登録します。（Previewだし）
登録するには以下のようにAzure PowerShellで。
> Register-AzProviderFeature -FeatureName CloudServices -ProviderNamespace Microsoft.Compute
FeatureName ProviderName RegistrationState
———– ———— —————–
CloudServices Microsoft.Compute Registering
10分ぐらい経てば登録完了すると思います。
> Get-AzProviderFeature | Where-Object {$_.FeatureName -eq “CloudServices”}
FeatureName ProviderName RegistrationState
———– ———— —————–
CloudServices Microsoft.Compute Registered
あと必要になるVNETを作っておきます。
サービス定義・サービス構成ファイル（.cscfg/.csdef）の修正
使えないプラグイン消したり、VNETの指定をしたりします。
例：
<NetworkConfiguration>
<VirtualNetworkSite name=”cstestvnet”/>
<AddressAssignments>
<InstanceAddress roleName=”WebRole1″>
<Subnets>
<Subnet name=”websubnet”/>
</Subnets>
</InstanceAddress>
<InstanceAddress roleName=”WorkerRole1″>
<Subnets>
<Subnet name=”workersubnet”/>
</Subnets>
</InstanceAddress>
</AddressAssignments>
</NetworkConfiguration>
デプロイ
ポータルからデプロイする場合は Cloud Services (extended support) を選択します。
必要項目を入力していきます。この時にデプロイするCSPKGや.cscfg/.csdefファイルも指定します。構成のところはネットワーク周りやスワップ対象（別extended support）を指定します。
なおClassicに比べてまぁまぁデプロイが速い（WebRoleの起動が速い）気がします。余計なことしなくて済むようになったからか？
デプロイ後、パブリックIPアドレスとLoad Balancerもいっしょに追加されます。
懐かしい感じでデプロイされました。
DNS名は既定で付くのかと思ったらつかなかったですね。構成ミスったのかな。まぁPublic IPアドレスに設定すればいいだけなので。（ただextended supportがデプロイして使われてる間は構成できないけど）
バグっぽい気がしないでもない。ただこの辺りは普通のVNETなので融通が利きますね。
それ以外はほぼClassicと変わりません。ARM対応ということはARMテンプレートからもデプロイが可能ということになります。Visual Studioからの直接デプロイはドキュメント的にはできるようですが、extended supportなテンプレートが見当たらなかったのでそのうち更新されてできるようになると思います。
まとめ
ARM対応になったことでこれまで以上に今のAzureらしい管理ができるようになりました。VNETが完全にARM対応したことで、かなり制限がなくなって構成できるようになったと思います。試してないけど。Cloud Services対応アプリそのものが今の時流には合わない部分が多いかもしれませんが、クラシックなCloud Servicesからの移行先としては申し分ないかと思います。おそらく一番コストがかからない。
また、まだ提供されていませんがIn-Place Upgradeもできるようになるようなので、そうなるとさらに手間なくextended supportに移行できそうですね。言葉を濁しながらService Fabricへ…とかWeb AppsとFunctionsへ…みたいなこと言わなくてもとりあえず何とかなる！（白目）
とはいえ例えば数年以上塩漬けしたアプリの移行としては他にも選択肢があるので、いい機会と思ってランタイムや開発環境なども含めて適切にアプリやサービスを新しくするのも検討すると良いと思います。（バズワードに追従しなさいということではなく）
Azure商用利用開始から来週で11周年。過去を振り返りつつ、なかなか面白いUpdateだなと思いました。
ブチザッキ 