Azure AutomationのギャラリーにあるグラフィカルRunbookをサービスプリンシパルに対応させてみる
この記事の続き。 asazure.hatenablog.jp
Automation Account --> Runbooks --> Browse Gallery と辿ったら出てくるこの2つです。
手順
先にAutomation Accountのアセットに、サービスプリンシパルの情報でCredentialを、テナントIDの情報でVariablesを作っておきましょう。前記事にも書きましたが AppIdが「User name」、パスワードは「Password」です。
- Runbookをインポートして作成
- Edit
- エディタ上の「Input and Output」をクリック
- 「AzureConnectionAssetName」は使わないので削除
- 「Add Input」から、サービスプリンシパル用のCredential名を指定するためのInputを定義(String)。
- OKでブレードを閉じながらグラフィカルエディタまで戻る
- 最上段の「Get Run as Connection」を削除
- 左メニューの「CMDLETS」から「Get-AutomationPSCredential」を探して「Add Canvas」。検索するのが早いが階層としては「Orchestrator.AssetManagement.Cmdlets」の中にある
- 「Get-AutomationPSCredential」と下の「Connect to Azure」をドラッグアンドドロップでつなぐ。
- 「Get-AutomationPSCredential」をクリックし、「Parameters」を開く
- 「NAME」を開き、「Runbook input」から先に作ったサービスプリンシパル用Credential名のInputを選択 --> OK
- 「Connect to Azure」をクリック、「Parameters」を開いて以下のように編集
- 「Parameter Sets」から「ServicePrincipal」を選択
- 「Credential」は「Data Source」に「Activity Output」を選択、下のボックスで「Get-AutomationPSCredential」
- 「Serviceprincipal」は「Data Sourceに「Constant value」を指定して「True」を選択
- 「Tenantid」は「Variable asset」を選択してテナントIDの入ったVariablesを選択
修正は以上です。保存時にエラーが出たときには、戻ってみると指定したはずの項目が指定されていなかったりしますので、改めて指定するか、何度やってもダメならブラウザをリロードしたり、コマンドレットを消して置き直すなどしてみましょう。
サービスプリンシパル(パスワード)でAzure AutomationのRunbookを実行する
「仮想マシンの定期的な起動・停止」みたいな定期作業をAzure AutomationのRunbookで実行したいという話は良くあると思います。 が、サービスプリンシパル(パスワードの方)を使ったブログ記事やサンプルが意外と見つからなかったので書いておきます。
※ 証明書を使う方法は公式ドキュメントにあったはず
サービスプリンシパルについて
そもそも何？という話は真壁先生のスライドをどうぞ。
www.slideshare.net
簡単な作りは他はこちらの記事を。作成にはAzure ADにしかるべき権限が必要なので、無い場合は作ってもらいましょう。
Automation Accountの作成
公式ドキュメントをどうぞ。こちらも「Azure実行アカウントの作成」を行うにはAzure ADに権限が必要です。
アセットの登録
スクリプト内で使う資格情報やテナントIDなどはAutomation Accountのアセットとして登録します。今回のスクリプトでは、サービスプリンシパルを「Credentials」に、テナントIDを「Variables」に登録しました。
サービスプリンシパルのAppIdをCredentialの「User name」に、パスワードを「Password」に登録します。テナントIDはVariableにStringとして登録しましょう。
仮想マシン起動・停止のサンプルスクリプト
こんな感じです。PowerShell WorkflowタイプのRunbookとして使えます。
パラメーターはそれぞれ以下のようになります。実行時やタイマーにセットしておきましょう。
- CredentialName : アセットに登録したサービスプリンシパルのCredential名
- ResourceGroup : 操作対象のリソースグループ名
- Action : 「Stop」もしくは「Start」
workflow Stop-Start-AzureVM { Param ( [Parameter(Mandatory=$true)][ValidateNotNullOrEmpty()] [String] $credentialName, [Parameter(Mandatory=$true)][ValidateNotNullOrEmpty()] [String] $ResourceGroup, [Parameter(Mandatory=$true)][ValidateSet("Start","Stop")] [String] $Action ) $credential = Get-AutomationPSCredential -Name $credentialName $tennantId = Get-AutomationVariable -Name 'tennantId' Login-AzureRmAccount -Credential $credential -Tenantid $tennantId -ServicePrincipal $AzureVMs = Get-AzureRmVM -ResourceGroup $ResourceGroup if($Action -eq "Stop") { Write-Output "Stopping VMs"; foreach -parallel ($AzureVM in $AzureVMs) { $AzureVM | Stop-AzureRmVM -Force } } else { Write-Output "Starting VMs"; foreach -parallel ($AzureVM in $AzureVMs) { $AzureVM | Start-AzureRmVM } } }
Azure Database for MySQL / PostgreSQL がGAしましたね
Azure Database for MySQL / PostgreSQL がGAとのアナウンス。お待ちしてました。
併せて、セキュリティとコンプライアンスのアナウンスも。
Securing Azure Database for MySQL and Azure Database for PostgreSQL | Blog | Microsoft Azure
SLAはSQL Databaseと同じく99.99%。なのですが、SLAのページを見るとMonthly uptime percentageが「< 99.9%」となってます(SQL DBと違う)。
(追記：2018年4月10日) いま見たら99.99%と表記されていました。
SLA for Azure Database for MySQL
GA価格は5月1日から適用、それまでは50%オフとのこと。コア数で比べるとRDS for MySQLのSingle-AZと同じくらいの金額ですかね。ベンチマークを取るとまたちょっと違った特性があるようなので、単純な比較はちょっと難しいかな？という印象でした。
サーバーをデプロイした後にPricing tier変更はまだできないようです。東日本、西日本ともハードウェアはGen4で、Memory Optimizedもまだ選べませんでした。
(追記： 2018年4月10日) こちらも東日本、西日本ともGen5、Memory Optiomizedとも選べるようになっていました。またストレージも最大2TB(6,144 IOPS)まで指定できるようになっていました。
ARMテンプレートのリファレンスはこちら。これも今後の充実に期待ですね。
docs.microsoft.com docs.microsoft.com
基本的なメトリックはAzure Monitorで取得出来ます。
ログはCLIでダウンロードする方式です。
そしてClearDBはMarketplaceから削除されたようです。これまでお世話になりました。
ClearDB removal from the Azure Marketplace
(追記： ARMのテンプレートを作っておきました)
Hyper-Vの.vhdファイルからAzure仮想マシンのイメージを作成する(ポータルのGUIで)
たぶんもうちょっと前からあった機能だとは思いますが、ポータルのGUIから仮想マシンのイメージが作れたので記録しておきます。
「日本語版DVDからインストールしたWindows Server 2016が欲しい」というリクエストがあったのでやってみたらできました。
ここで紹介する手順は、いわゆる「仮想マシンのひな形」としての「イメージ」を作る手順なので、仮想マシンをそのままコピーする手順ではありません。そちらのケースは、今のところ.vhd経由だとGUIでは完結しないので、どうしてもと言うことであればAzure Site Recoveryをつかうとか別のアプローチになると思います。
Hyper-V 仮想マシン側の準備
基本的には公式ドキュメントにあるとおりに準備を進めて、Azure用の.vhdファイルを作ります。
Hyper-V仮想マシンが第2世代の場合はこのあたりで第1世代に変換しておくのが良いと思います。
.vhdxから.vhdへの変換や固定サイズ化などは、Hyper-VマネージャのGUIでもできます。
ちなみに、一部の仮想マシンシリーズではNested Virtualizationをサポートしているので、Azure仮想マシン上でHyper-Vを立ち上げてこのあたりの作業を進められるようになりました。Dv3やEv3シリーズあたりがそれです。
Azure Storageへのアップロードには、Azure Storage Explorerも使えます。「ページBLOB」としてアップロードしましょう。
「イメージ」の作成
アップロードが終わったらイメージの作成です。「イメージ」ブレードを開きます。
「追加」をクリックします。
名前などを適宜付けていきます。「ストレージBLOB」で、アップロードした.vhdを指定します。
「作成」を押してしばらくすると、仮想マシンのイメージが出来上がります。
仮想マシンの作成
「イメージ」ブレードからイメージを開いて「VMの作成」をクリックします。
あとはいつも通りに仮想マシンを作るだけです。
ここまで。
気付かないうちにポータルもどんどん便利になりますね。
Azureクラシックポータルが終息
既報の通り、クラシックポータルが2018/1/8をもって終息していました。URLにアクセスすると現行ポータルにリダイレクトされるようになっていました。 https://manage.windowsazure.com/
▼クラシックポータル終息のアナウンス
Azure portal update for classic portal users
移行ガイド的なドキュメントが12月に公開されていたようなので参考まで。
念のためですが、クラシックリソース(クラシックVMやクラシックVNet)については引き続き現行のAzureポータルからアクセスできます。
クラシックポータルにはずいぶんとお世話になりましたので、ちょっと寂しいですね。
Azure仮想マシンのメンテナンスを見守ったメモ
(2018年1月25日 追記)
Azure公式ドキュメントにFAQが記載されていました。オフィシャルな情報としてはこちらをご覧下さいませ。「Accelerated maintenance」なんて名前が付いたんですね。
(追記終わり)
年始からバタバタしてますね。
CPU の脆弱性から Azure のお客様を保護するために (2018/1/25 補足情報の更新) – Japan Azure Technical Support Engineers' Blog
背景等を含め、こちらの記事で分かり易く説明されています。
この記事ではメンテナンスの立ち会いがてらに、実際のところどんな感じだったかのメモを残しておこうと思います。
メンテナンス対象となっているVMをまとめて確認したい
「サービス正常性 → 計画済みメンテナンス → 影響を受けるリソース」で、いまのアカウントで管理している全サブスクリプションの情報がまとめて一覧で見られます。メンテナンスが終わったリストは残念ながら見あたりませんでした。
(2018年1月6日 追記)
メンテナンス期間に突入したせいか、「サービス正常性 → 計画済みメンテナンス → 影響を受けるリソース」と辿ると、メンテ完了したVMも表示されるようになっていました。
(追記終わり)
(2018年1月5日 11時21分 追記)
メンテナンス完了 → ホスト障害 → メンテナンス終わってないホストに着地 → またメンテナンス対象に
という流れで再度メンテナンス対象になるケースを見かけました。やはり推奨されているとおり、Azure Monitor や Instance Metadata でこまめに見ておくのが良さそうです。
(追記終わり)
(2018年1月9日 14時06分 追記)
「サービス正常性 → 計画済みメンテナンス」から今回の告知自体が消えていました。今日の午前中に「COMPLETED: Required Maintenance for Azure Platform impacting Virtual Machines」という件名のメールが届いていたので、一連のメンテナンスが完了したと考えていいんでしょうね(本文内には「REGION(S): Australia East」と書いてありますが…)。
(追記終わり)
各VMのメンテナンスウィンドウを確認したい
仮想マシン一覧のブレード(Virtual Machine)で列を追加できます。今回のようにプラットフォーム側でスケジュールを設定された場合は、「メンテナンス - 自動スケジュールされたウィンドウ」列に表示されます。ここが空欄であれば実施済みと判断して良さそうに思います。セルフサービス期間には「メンテナンス」列に「完了」と出ていたんですが、セルフサービス期間を過ぎると何故か消えてしまうようです。
(2018年1月4日 20時57分 追記)
と思ったら、いま見た感じだと「完了」はちゃんと表示されるようになっていて、逆に「メンテナンス - 自動スケジュールされたウィンドウ」列が無くなっていました。列の追加からも消えてしまいました。
(追記終わり)
メンテナンスがいつ頃行われたのか確認したい
「メンテナンス - 自動スケジュールされたウィンドウ」欄が空欄になっているがちょっと不安、という場合には、仮想マシンの「リソース正常性」から「履歴の表示」でメンテナンス(による再起動)が実施されたかどうかを確認することができます。メッセージにはいくつかのパターンがあるようです。
おそらく前者はホスト移動無しでパッチ適用した場合、後者はホスト更新のため自動再デプロイされた場合のメッセージかなと思います。
セルフサービス期間を過ぎているがなんとか手動でやりたい
公式情報によると 「Azure インフラストラクチャの大部分は、本脆弱性に対応するため更新済みとなります」 ということで、割り当て解除・開始や再デプロイ、(主に)v3系へのサイズ変更なんかでメンテナンス済みのホストに移動する可能性はあるかなと思います。
といっても、相当な勢いでメンテナンスが進んでいるようなので、あまりジタバタしない方が良さそうには思います。今日のお昼頃に手動で再デプロイしてみた仮想マシンではこんな感じのログになっていまして、正常にアクセス可能になるまで結構な時間がかかりました。
ゲストOSへのパッチ適用は必要？
必要なはずです。詳しくは各ベンダーやディストリビューションの情報を確認しましょう。
Azure以外のクラウドは？
AWSで年末からずっとメンテナンスが走っていたのもこの件だったんでしょうね。公式なリリースはこちら。あと数時間で基盤側のアップデートが終わるので、ユーザー側でもOSパッチを当てるようにとのこと。Amazon Linuxはパッチ提供済みなので yum update kernel で適用されるそうです。
Processor Speculative Execution Research Disclosure
Google Cloud Platform については、基盤側は対応済みなのでゲストOS側のパッチを当てるようにとのこと。影響があるのはGCE、GKE、Cloud Dataflow、Cloud Dataproc。
Google Online Security Blog: Today's CPU vulnerability: what you need to know
クラウドではありませんが、VMwareについてはパッチが提供されているようですね。
(2018年1月5日 追記)
IBM Cloud からもリリースがありました。1/5から1/8の間にパッチ適用、インスタンスの再起動あり、バックアップ推奨。タイミングはメンテナンスチケットで通知されるとのこと。
We're taking action to secure our cloud against recent security vulnerabilities - IBM Cloud Blog
(追記終わり)
性能が落ちるという情報があるが大丈夫？
(2018年1月24日 追記)
日本マイクロソフトから記事が出ていましたので、まずはこちらをご覧頂くのが良さそうです。
Windows システム上の Spectre および Meltdown に対する緩和策のパフォーマンスへの影響について – 日本のセキュリティチーム
(追記終わり)
AWSのフォーラムで話題になっていたようですね。実際に、身近なEC2でも特にParavirtualizedなインスタンスでは比較的大きめな影響が出ていたようです。
Degraded performance after forced reboot due to AWS instance maintenance
Azureについては、ネットワークに影響が出る可能性があるかも、ということで、これは後ほど実測してみようかと思います。
CPU の脆弱性から Azure のお客様を保護するために (2018/1/25 補足情報の更新) – Japan Azure Technical Support Engineers' Blog
(2018年1月5日 追記)
と言うわけで実測してみました。
まずはUbuntuでUnixBenchを実行した結果です。誤差程度といいますか、東日本のAシリーズはむしろ新しいハードウェアに乗って性能アップしちゃったのかもしれません。Bシリーズについては、ちょっと性能が出すぎてしまっている感があるので参考程度に。
| リージョン | インスタンスタイプ | スコア (メンテ前) |
スコア (メンテ後) |
前後比 |
|---|---|---|---|---|
| 東日本 | Standard A1 (1 vcpu, 1.75 GB memory) | 742 | 799 | 108% |
| 東日本 | Standard_A1_v2 (1 vcpu, 2 GB memory) | 785 | 820 | 105% |
| 東日本 | Standard F1s (1 vcpu, 2 GB memory) | 1,770 | 1,676 | 95% |
| 西日本 | Standard B1ms (1 vcpu, 2 GB memory) | 1,015 | 1,890 | 186% |
| 米国西部2 | Standard F2s_v2 (2 vcpus, 4 GB memory) | 2,877 | 2,914 | 101% |
続いてネットワークのパフォーマンス。公式ドキュメントの案内通り、NTttcp で測定しました。
見た感じ、アナウンス通り少しパフォーマンスが落ちているように見えますね。SR-IOVを有効にした場合で以前と同程度という結果でした。Dシリーズ(Dv2、Dv3)だけの結果なので偏りがあるかもしれませんが、ご参考まで。
(2018年1月5日 訂正)
Windows Updateの影響を考慮してなかったので、改めて測定し直しました。
結果、プラットフォームのメンテナンス前後ではパフォーマンスは変わらず、Windows Update を適用すると少し落ちて、SR-IOVを有効にすると回復する、といった結果になりました。
最後に、ストレージのベンチマークを簡単に(2018年1月5日 追記)。L4sにアタッチしたデータディスク(P30)を CrystalDiskMark のデフォルト設定で計測しました。結果としてはアップデートの影響は無く、スペック通りの性能が出ていました。
▼Azureメンテナンス前(2017年12月 計測)
▼Azureメンテナンス後、Windows Update未適用(2018年1月5日 計測)
▼Azureメンテナンス後、Windows Update適用(2018年1月5日 計測)
(2018年1月6日 追記)
AzureのホストメンテナンスというよりWindows Updateの話になりますが、KB4056892でRAMDISKのパフォーマンスが落ちるということでL4sにiSCSIでアタッチして簡単に試してみました。数パーセントから銃数パーセントの低下といったところですかね。
▼KB4056892 適用前
▼KB4056892 適用後
(追記ここまで)
