Azure Automationで平日のみジョブ実行させるスケジュール作成

 

Azure Automationのスケジュール設定を試してみました。

今回はRunbookを朝8時に実行する事を想定してスケジュール作成してみました。

    • スケジュール設定内容
      • 毎日実行する
      • 平日のみ実行する
      • 平日のみ実行する(祝日も考慮してスケジュール作成する)

作成したスケジュールをRunbookと関連付けする事で平日のみAzure VMを自動起動停止させるという事が可能になります。

スケジュールの作成はAzure Portalを利用して実施しています。

1.Azure Automation アカウントのRunbookを毎日朝8時に実行する

今回の設定順序はこちらの通りになります。

      • スケジュールを作成する
      • スケジュールをRunbookにリンクする

まず最初に、毎朝8時に実行するスケジュールを作成します。

Automation アカウントの共有リソースにスケジュールというメニューがあります。こちらを選択すると下記画面が表示されます。スケジュールの追加を選択します。

新しいスケジュールの作成画面が表示されます。以下の内容で設定し作成を選択します。

      • 名前:毎日朝8時に実行(任意設定)
      • 開始時:10月6日 8:00(開始日を10月6日からと想定)
      • タイムゾーン:Japan
      • 繰り返し:定期的
      • 間隔:1日
      • 有効期限の設定:いいえ 

これでスケジュールの作成は終了です。次にスケジュールをRunbookにリンクします。

定期実行するRunbookを選択すると下記画面が表示されますので、スケジュールへのリンクを選択します。

Runbookのスケジュール設定画面が表示されますので、スケジュールを選択します。

スケジュールの画面が表示されますので、先ほど作成したスケジュールを選択します。

 

スケジュールのところに選択したスケジュールが表示される事を確認したらOKを選択します。

これでRunbookへのスケジュール関連付けが完了です。Runbookがスケジュール実行されます。

Azure AutomationアカウントでRunbookでのAzure VM再起動(実行時間制限)についてこちらで記載しております。 

Azure Automation Runbookで実行時間制限

—–

2.Azure Automationアカウントで平日朝8時に実行するスケジュールを作成

先ほどと同様に、Automation アカウント メニューのスケジュールで、スケジュールの追加を選択します。

新しいスケジュールの作成画面で以下のように設定します。

      • 名前:平日朝8時に実行(任意設定)
      • 開始時:10月6日 8:00(開始日を10月6日からと想定)
      • タイムゾーン:Japan
      • 繰り返し:定期的
      • 間隔:1週
      • 設定曜日:月曜日、火曜日、水曜日、木曜日、金曜日
      • 有効期限の設定:いいえ

間隔を週間とする事で曜日指定が出来るようになりますので、実行する曜日を選択します。これで特定曜日に実行が可能になります。

3.Azure Automationで月間スケジュールを作成(平日(祝日除く)の朝8時に実行)

祝日も考慮して、平日のみ実行のスケジュール作成する場合は月間スケジュールを作成します。

新しいスケジュールの作成画面で以下のように設定します。

      • 名前:2020年11月の平日朝8時に実行(任意設定)
      • 開始時:11月1日 8:00
      • タイムゾーン:Japan
      • 繰り返し:定期的
      • 間隔:1月
      • 毎月の特定曜日:月の日付
      • 月の指定した日に実行:カレンダーで実行日を指定(平日を指定(祝日除く))
      • 有効期限の設定:はい (11月30日23:59)

間隔を月とする事で月で実行日指定が出来るようになります。有効期間を1月分(11月1日~11月30日)実行とする事で、11月の平日のみ実行といった設定が出来ます。

App Service PlanをPower Shellでプラン変更

 

App Service Planのプラン変更をPower Shellを使って試してみました。

App Service(Web Apps)は停止しても課金は止まらずApp Service Planの方を停止する必要があります。ですがAzure VMと違いApp Service Planには停止がありません。

課金を止めようとするとApp Service Planを削除するか無償のプランに変更する必要があります。(削除するとWeb Appsも削除されます。)

また、App Service Planですが、Basicレベルでは手動でのスケールアウト、Standardプラン以上は自動のスケールアウトをサポートしています。ただ自動でスケールアップ、ダウンは出来ません。

課金を停止する場合やBasicプランでスケールアウトさせる場合は手動で設定変更する事になります。

今回は、Azure VMの自動シャットダウンと同じ事が出来ないかという事で、App Service Planのプラン変更をPower Shellを使って試してみました。

    • 今回実施した内容
      • App Service Planプラン変更を行うPower Shellを作る
      • AutomationアカウントのRunbookに設定する

1.Set-AzAppServicePlanを使ってApp Service Planプラン変更する

今回、App Service Planの設定変更を以下の方法でやってみました。

      • Get-AzAppServicePlanで現在のApp Service Planの設定を取得
      • 変更するプラン内容の情報を指定
      • Set-AzAppServicePlanでApp Service Planの設定変更

無償プランに変更するだけなら、Set-AzAppServicePlanだけで可能なのですが、スケールアップダウンと一緒にスケールアウト等も出来るようにしたかったのでこういう形にしています。

    • Power Shellで指定する内容
      • 設定変更対象のApp Service Plan
        • リソースグループ名
        • App Service Plan名
      • App Service Planの設定値
        • Name:F1、B1~3、S1~3、P1v2~P3V2等
        • Tier:Free、Basic、Standard、PremiumV2等
        • Family:F、B、S、Pv2等
        • Capacity;インスタンス数(プランにより上限が異なります)

App Service Planの設定値ですが、例えば無料プランの場合は以下のように指定します。

        • Name : F1
        • Tier : Free
        • Size : F1
        • Family : F
        • Capacity : 1

設定値の確認を入れている為、何度か同じコマンドを実行しています。環境に合わせて適時変更して下さい。

今回作成したPower ShellはGitHubにアップロードしてございます。

https://github.com/Tama-negi/Li-akb-branch-office/tree/PowerShell_Azure/AppServicePlan_Change_20200816

#App Service Plan変更するPower Shell

#設定変更対象のAppServicePlan
$ResourceGroupName = “リソースグループ名”
$AppServicePlanName = “AppServicePlan名”

#AppServicePlan変更後の設定値
$Name = “F1”
$Tier = “Free”
$Size = $Name
$Family = “F”
$Capacity = 1

#現在のAppServicePlanの情報取得
$AppservicePlanConf = Get-AzAppServicePlan -ResourceGroupName $ResourceGroupName -Name $AppServicePlanName

#現在の情報表示
Write-Host “変更前の設定情報: $($AppServicePlanName)”
$AppservicePlanConf
$AppservicePlanConf.Sku

$AppservicePlanConf.Sku.Name = $Name
$AppservicePlanConf.Sku.Tier = $Tier
$AppservicePlanConf.Sku.Size = $Size
$AppservicePlanConf.Sku.Family = $Family
$AppservicePlanConf.Sku.Capacity = $Capacity

$AppservicePlanConf | Set-AzAppServicePlan

#設定変更後AppServicePlanの情報取得
$AppservicePlanConfAfter = Get-AzAppServicePlan -ResourceGroupName $ResourceGroupName -Name $AppServicePlanName

#設定変更後の情報表示
Write-Host “変更後の設定情報: $($AppServicePlanName)”
$AppservicePlanConfAfter
$AppservicePlanConfAfter.Sku

 

2.AutomationアカウントのRunbookを使って、App Service(Web Apps) の自動シャットダウンっぽい事をやってみる

Freeプランへの変更をAutomationアカウントのRunbookを使って実施します。

AutomationアカウントでRunbookを選択します。下記画面が表示されますので、Runbookの作成を選択します。

Runbookの作成画面が表示されるので、Runbookの種類はPower Shellを選択して作成します。

Power Shell Runbookの編集画面が表示されます。

先ほどのPower ShellでFreeプランとして貼り付けます。(Runbook用に認証部分のみ追加しています。)保存をクリックした後に、テストウィンドウを選択します。

#App Service Plan変更するPower Shell

#認証
$Conn = Get-AutomationConnection -Name AzureRunAsConnection
Connect-AzAccount -ServicePrincipal -Tenant $Conn.TenantID `
-ApplicationId $Conn.ApplicationID -CertificateThumbprint $Conn.CertificateThumbprint

#設定変更対象のAppServicePlan
$ResourceGroupName = “リソースグループ名”
$AppServicePlanName = “AppServicePlan名”

#AppServicePlan変更後の設定値
$Name = “F1”
$Tier = “Free”
$Size = $Name
$Family = “F”
$Capacity = 1

—以下は先ほどのPower Shellと同じなので省略—

テストの画面が表示されますので、開始をクリックします。

しばらくすると開始します。正しく動作して完了すると、下記画面が表示されます。Freeプランへの変更が出来ている事が確認できます。

編集画面に戻り公開をクリックします。Runbookの発行が表示されますのではいを選択します。(Runbookを実際に利用する為には保存ではなく公開する必要があります。。)

 

 これで、Runbookが作成され利用できる状態になりました。。

後はスケジュールと関連づけすれば、定時にAppServicePlanの変更(自動シャットダウン)が出来ます。

なお、Automationアカウントの作成やスケジュール作成はこちらで試しております。

Automationアカウント初期作成時のモジュール

Azure Automation Runbookで実行時間制限

 

3.App Service Plan変更時の注意点。

プラン変更できないパターンもあります。

例えばカスタムドメイン等を利用していると、Freeプランへの変更がエラーになります。

プラン変更時にはそのTierでしか使えないサービスを利用しているかどうか確認が必要になります。

今回のPower Shellを使った場合は、同じTierで一番安価なプランを選択する等の設定が必要そうです。

Azure Automation Runbookで実行時間制限

 

Azure Automationに、RunbookというPowerShell、PowerShell ワークフローをスケジュールに合わせて実行する事が出来る機能があります。

このRunbookを使うと、Azure VMの再起動をスケジュール実行させるなどが簡単に設定できます。

しかし、Runbookスケジュール実行させる場合、Runbookの障害で実行時間が遅延し予期せぬ時間帯に実行されるケースがあります。
予期せぬ時間帯にRunbookが実行される事象を防ぐためには、Rubbook内で実行時間を制限することが1つの対策となります。

今回は下記サイトを参考にAzure VMの起動Runbookで時間制限を試してみました。またその前段としてRunbookのスケジュール設定も併せて試してみました。

https://docs.microsoft.com/ja-jp/azure/automation/automation-runbook-execution

Automationアカウント作成やAzure VMの起動停止についてはこちらの記事に記載しております。

Automationアカウント初期作成時のモジュール

Power ShellでAzure VM起動/停止と一緒にディスクタイプを変更する

----

1 .Azure PortalでAutomationアカウントのRunbookスケジュール設定をしてみる

Runbookのスケジュール設定は以下の2つの手順になります。

      • Automationアカウントでのスケジュール作成
      • Runbookへのスケジュール割り当て

まず最初にスケジュール作成を行います。

スケジュールのメニューを選択すると下記画面が表示されますので、スケジュールの追加を選択します。

新しいスケジュールのポップアップが表示されますので、設定を行います。保存すればスケジュール作成は完了です。

次に、Runbookへのスケジュール割り当てを行います。

スケジュールの割り当てを行うRunbookを選択すると下記画面が表示されますので、スケジュールへのリンクをクリックします。

Runbookのスケジュール作成画面が表示されますので、スケジュールを選択します。

作成したスケジュールを選択すれば、スケジュール設定は完了です。

平日のみ実行するスケジュール作成についてはこちらの記事に記載しています。

Azure Automationで平日のみ実行するスケジュール作成

.Azure VM起動 Runbookの実行時間を制限する

今回は1つの例としてサーバ再起動のRunbookを作成してみました。9時から18時の間はRunbookが実行されないような設定にしています。

AddHours(9)で日本時間に合わせて、9時間追加してます。
$JST.Hour -lt 9で9時より前(8時59分以前)、$JST.Hour -gt 18で18時より後(18時01分以降)を指定しています。
8時59分時以前もしくは、18時01分以降なら実行という設定、つまり9時から18時の間は実行されないという設定が実現できます。

#Runbookサーバ再起動

Import-Module Az.Compute

#再起動対象の仮想マシンが属する、リソースグループ名
$rgName =“リソースグループ名”

#再起動する仮想マシン名
$vmName =“仮想マシン名”

# 認証

$Conn = Get-AutomationConnection -Name AzureRunAsConnection
Connect-AzAccount -ServicePrincipal -Tenant $Conn.TenantID `
-ApplicationId $Conn.ApplicationID -CertificateThumbprint $Conn.CertificateThumbprint

# 時間指定
  $JST = (Get-Date).AddHours(9)
        if(($JST.Hour -lt 9) -or ($JST.Hour -gt 18)){
         Write-Output(“Proceed”)

# 実行する処理
        ReStart-AzVM -ResourceGroupName $rgName -Name $vmName

    }
    else
    {
        Write-Output(“Don’t proceed”)
    }

※なお、AutomationアカウントのソリューションにVM起動停止のソリューションが存在します。

 

Automationアカウント初期作成時のモジュール

 

AzureでAutomationアカウントを新規作成した場合、モジュール(Runbook上でPower Shell等を動作させる為のモジュール)は既定のバージョンになります。
この既定のバージョンが非常に古いバージョンになっています。その為RunBookが動かないケースがあります。

実際に、モジュールにAzureRM.Profile は存在していても、モジュールの既定のバージョン (1.0.3)であったため、Connect-AzureRmAccounが使えないケースがありました。

また、Automationアカウント初期作成時にはAZモジュールが入ってません。

今回は、Automationアカウントを新規作成、モジュール更新、AZモジュールのインストールを試してみました。

1.Azure Portalを使ってAutomationアカウントを作成する

まず最初にAzure Portalを使ってAutomationアカウントを作成してみます。

Automationアカウントのメニューを選択すると下記画面が表示されるので、追加をクリックします。

下記画面が表示されるので、名前、リソースグループ、場所を選択し作成します。

これで、Automationアカウントの作成は完了です。

2.Automationアカウントのモジュール更新ボタンは使用できない

Automationアカウントのモジュールを確認してみます。モジュールを選択すると下記の通り利用可能なモジュールが表示されます。

実際にバージョンを確認すると古いバージョンになっている事が分かります。(最終更新日は新しいのですが、実際のモジュールバージョンは古いものになります)

Automationアカウントのメニューでモジュール更新ボタンをクリックすると以下のメッセージが表示されます。
しかし、残念な事に実際に更新ボタンをクリックすると、更新機能は廃止されましたというメッセージが表示され更新が出来ません。

3.Automationアカウントのモジュールの更新を確認する(Update-AutomationAzureModulesForAccount を使う)

モジュールの更新に関する詳細情報をクリックすると、以下のURLが表示されます。

https://docs.microsoft.com/ja-jp/azure/automation/automation-update-azure-modules

実際の更新手順を確認すると、RunBookにモジュールアップデートを行うPower Shellを作成して行うようです。

4.Automationアカウントのモジュールの更新してみた

実際にAutomationアカウントのモジュール更新をやってみます。

1) 以下サイトで、”Update-AutomationAzureModulesForAccount.ps1″ をクリックする。

https://github.com/Microsoft/AzureAutomation-Account-Modules-Update

2) RAWボタンをクリックし、PowerShellスクリプトをコピーします。

3)テキストエディタ等にペーストし、”Update-AutomationAzureModulesForAccount.ps1″ として保存します。

4)Automation アカウントを開き、[Runbook] から [Runbook のインポート] をクリックします。

5)ファイルの選択にて先ほどの “Update-AutomationAzureModulesForAccount.ps1” を選択します。
Runbookの種類は、PowerShellを選択し、[作成] をクリックします。

6)インポート後、編集を選択し、編集画面にて、そのまま公開をクリックします。

7)作成したRunbook にて [開始] をクリックします。

8)実行すると、右側にRunBookの開始、パラメータが表示されます。
“RESOURCEGROUPNAME” に対象 Automation アカウントのリソースグループ名を入力します。
“AUTOMATIONACCOUNTNAME” に対象 Automation アカウント名を入力します。

9)入力が終わったら、[OK] にて実行します。

10)ジョブが正常終了したら、 モジュールが更新されてます。(初回は結構時間がかかります。)

これで更新作業は完了です。ただ更新されないモジュールもあるようです。この編は個別にダウンロードして対応する必要がありそうです。

5.Automationアカウント初期作成時にはAzモジュールが入っていない

モジュールの画面を見ると、Automationアカウントで最初に入っているのは、AzureRMモジュールが入っておりAZモジュールは入っていません。

AZモジュールを使う場合は追加が必要になります。

なお、1つのAutomationアカウントでAzモジュールとAzureRMモジュールの併用して利用する事は出来ないそうです。

Azモジュールの追加をします。モジュールギャラリーを選択し、検索ボックスにAzと入力するとAz関連のモジュールが表示されます。

Az.Accountsを選択すると下記画面が表示れますので、インポートクリックします。

これでモジュールのインポート作業は完了です。

Az系のモジュールについては、依存関係の都合上Az.Accountsを一番最初にインポートする必要がありそうです。