Azure Database for MariaDBに接続してみた

 

Azure Database for MariaDBへの接続を試してみました。

Azure Database for MariaDBへの接続には、MySQL Workbenchを利用しています。

大きな作業手順としては、以下の通りになります。

1)Azure Database for MariaDBでクライアントから接続許可設定を行う。

2)MySQL Workbenchで、Azure Database for MariaDBへの接続用の設定を行う。

3)MySQL WorkbenchでSSL接続用の設定を行う。

Azure Database for MariaDBの作成はこちらの記事を参考頂ければと。

Azure Database for MariaDBを作ってみた

1 .Azure Database for MariaDBで接続用の設定を行う。

デプロイ直後は、ネットワークの接続が許可されていません。

最初に接続のセキュリティでクライアントIPの許可設定を行います。

1)Azure Database for MariaDBのメニューで接続のセキュリティを選択します。

2)クライアントIPの追加を選択します。選択すると現在アクセス中のグローバルIPからのアクセス許可が追加されますので保存します。(今回はテスト接続なので、アクセス中のIPのみ許可しています。)

これでアクセス許可の設定は完了です。

※接続元にIPは環境に合わせて設定下さい。

2 .MySQL WorkbenchでAzure Database for MariaDBへの接続設定をしてみる

マイクロソフト様のサイトに詳細な解説がありますので、こちらを参考に進めます。

https://docs.microsoft.com/ja-jp/azure/mariadb/connect-workbench

※今回はMySQL Workbenchはインストール済みである前提とします。

1)MySQL Workbenchを起動します。

2)MySQL Connectionsの横にある、+ボタンをクリックし新規コネクションを追加します。

3)選択すると下記画面が表示されますので、Connection Name、ホスト名、UserNameを入力します。

なお、ホスト名、UserNameについては、Azure Database for MariaDBのメニュープロパティにサーバ名、サーバ管理者ログイン名の記載がありますので、こちらを選択します。

入力が完了したら、OKで保存します。

※SSLの設定が終わってから接続確認しますので、今回はそのまま保存します。

3.MySQL WorkbenchでSSL接続設定をしてみた

こちらについても、マイクロソフト様のサイトに詳細な解説があります。こちらを参考に進めます。

https://docs.microsoft.com/ja-jp/azure/mysql/howto-configure-ssl

なお、前回作成時に、SSL強制を有効にしていますので、その手順は今回飛ばしてます。

1)マイクロソフト様のサイトから、SSL接続に必要な証明書をダウンロードします。

証明書のダウンロードは下記サイトから実施します。(保存時のファイル名はBaltimoreCyberTrustRoot.crt.pemとします。)

https://www.digicert.com/CACerts/BaltimoreCyberTrustRoot.crt.pem

2)先ほど作成したMySQL Workbenchのコネクションを選択し、右クリックをするとEdit Connectionという項目が表示されますので、こちらを選択しますj。

3)設定画面が表示されますので、SSLのタブを選択します。

4)下記画面が表示されますので、以下の通り選択し、OKを押します。

      • Use SSLはRequireを選択します。
      • SSL CA Fileで先ほどダウンロードしたファイル選択する。

4.MySQL Workbenchを使ってAzure Database for MariaDBへ接続してみた

最後に接続確認を行います。

1)MySQL Workbenchで先ほど作成したコネクション設定をダブルクリックします。

2)パスワード画面が表示されますので、入力しOKをクリックします。

3)無事接続が完了すると、下記画面が表示されます。

※途中でWarnning等が表示される場合がありますが、そのまま進めばOKなようです。

Azure Database for MariaDBを作ってみた

 

Azure Database for MariaDBのデプロイをAzure PortalとAzure Resource Manager(ARM)テンプレートの2つパターンで実施してみました。

ARMテンプレートでは、少し利用しやすいように直してみました。

    • デフォルト値の設定を追加しています。
    • Power Shellを使ってデプロイする場合に、ARMテンプレートのパラメータをCSVから読み込むようにしてみた。

ARMテンプレートを使ってデプロイするにあたっては、以下の3つのファイルを作成しています。

    • Azure Database for MariaDBを定義するARMテンプレート(JSONファイル)
    • Azure Database for MariaDBプランのパラメータを指定するCSV
    • ARMテンプレートをデプロイするPower Shell

作成したものは GitHub上にも公開しております。

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

1 .Azure Portal上でAzure Database for MariaDBを新規作成する

Azure Portalを利用して、Azure Database for MariaDBを作成してみました。

手順はマイクロソフト様のサイトに記載されていますので、その通り実施してみました。

https://docs.microsoft.com/en-us/azure/mariadb/quickstart-create-mariadb-server-database-using-azure-portal

Azure Portalを利用して作成する場合、以下の内容を選択します。実際に利用するリソースに合わせて設定します。

    • リソースグループ
    • サーバ名
    • データソース(新規に作成する場合はなしを選択します。バックアップからリカバリする際にはバックアップを選択します。)
    • 場所(リージョン)
    • バージョン(MariaDBのバージョンを選択します。2020年5月現在では10.2か10.3になります。)
    • コンピューティングとストレージ(価格レベルです。MariaDBを利用する為のリソースになります。)
    • 管理者ユーザー名(MariaDBにアクセスする管理者ユーザーになります。)
    • パスワード(管理者ユーザーのパスワードになります。)
    • タグ

1)すべてのサービスでMariaと入力します。Azure Database for MariaDBが表示されますので選択します。

2)下記画面が表示されますので、+追加をクリックします。

3)基本設定の画面が表示されますので、適時入力します。

コンピューティングとリソースにあるサーバの構成をクリックします。なお、場所(リージョン)を変更すると、サーバの構成が初期値に戻るので要注意です。

5)価格レベルやvCore、ストレージ容量を選択します。

今回は下記記載の設定で作ってみました。(一番お安い構成にしています。)

    • 価格レベルはBasicを選択
    • vCore:1
    • ストレージ:5GB
    • 自動拡張:いいえ
    • バックアップ保持期間:7日間

一度作成しまうと、後からBasicから汎用目的への変更はできません。注意が必要となります。

6)OKを選択すると、基本のページに戻ります。

タグを設定しない場合はそのまま確認および作成を選択します。

7)確認画面が表示されますので、問題がなければそのまま作成します。

完了すると、Azure Database for MariaDBが作成されます。

 

2 .Azure Database for MariaDBのAzure Resource Manager(ARM)テンプレート

マイクロソフト様のサイトを参考にし、Azure Database for MariaDBのARMテンプレートを作成してみました。

https://docs.microsoft.com/en-us/azure/mariadb/quickstart-create-mariadb-server-database-arm-template?tabs=azure-portal

サンプルを使いやすくする為に、少しだけシンプルにしてみました。

    • デフォルト値を設定しています。今回はAzure Portalを利用して作成した場合の値をデフォルト値としています。
    • パラメータをAzure Portalを利用して作成した場合+SSLの有効化指定の設定のみに変更(サンプルからvirtualNetwork関連の情報を抜きました。)
    • コンピューティング世代(SkuFamily)が現時点ではGen5のみなので、variablesで固定値にしています。

Azure Database for MariaDBのARMテンプレートはこういう形になりました。

{

    “$schema”: “https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#”,
    “contentVersion”: “1.0.0.0”,
    “parameters”: {
        “serverName”: {
            “type”: “string”,
            “minLength”:3,
            “maxLength”:63
        },
        “administratorLogin”: {
            “type”: “string”,
            “minLength”:1,
            “maxLength”:16
        },
        “administratorLoginPassword”: {
            “type”: “securestring”
        },
        “location”: {
            “type”: “string”,
            “defaultValue”: “japaneast”
        },
        “skuCapacity”: {
            “type”: “int”,
            “defaultValue”: 1
        },
        “skuName”: {
            “type”: “string”,
            “defaultValue”: “B_Gen5_1”
        },
        “skuSizeMB”: {
            “type”: “int”,
            “defaultValue”: 5120
        },
        “skuTier”: {
            “type”: “string”,
            “defaultValue”: “Basic”,
            “allowedValues”: [
                “Basic”,
                “GeneralPurpose”,
                “MemoryOptimize”
            ]
        },
        “version”: {
            “type”: “string”,
            “defaultValue”: “10.3”,
            “allowedValues”: [
                “10.2”,
                “10.3”
            ]
        },
        “backupRetentionDays”: {
            “type”: “int”,
            “defaultValue”: 7
        },
        “geoRedundantBackup”: {
            “type”: “string”,
            “defaultValue”: “Disabled”,
           “allowedValues”: [
                “Disabled”,
                “Enabled”
            ]
        },
        “storageAutoGrow”: {
            “type”: “string”,
            “defaultValue”: “Disabled”,
           “allowedValues”: [
                “Disabled”,
                “Enabled”
            ]
        },
        “sslEnforcement”: {
            “type”: “string”,
            “defaultValue”: “Disabled”,
            “allowedValues”: [
                “Disabled”,
                “Enabled”
            ]
        },
        “infrastructureEncryption”: {
            “type”: “string”,
            “defaultValue”: “Disabled”,
            “allowedValues”: [
                “Disabled”,
                “Enabled”
            ]
        }
    },
    “variables”: {
        “skuFamily”:”Gen5″
    },    
    “resources”: [
        {
            “apiVersion”: “2018-06-01-preview”,
            “kind”: “”,
            “location”: “[parameters(‘location’)]”,
            “name”: “[parameters(‘serverName’)]”,
            “properties”: {
                “version”: “[parameters(‘version’)]”,
                “administratorLogin”: “[parameters(‘administratorLogin’)]”,
                “administratorLoginPassword”: “[parameters(‘administratorLoginPassword’)]”,
                “storageProfile”: {
                    “storageMB”: “[parameters(‘skuSizeMB’)]”,
                    “backupRetentionDays”: “[parameters(‘backupRetentionDays’)]”,
                    “geoRedundantBackup”: “[parameters(‘geoRedundantBackup’)]”,
                    “storageAutoGrow”: “[parameters(‘storageAutoGrow’)]”
                },
                “sslEnforcemen”: “[parameters(‘sslEnforcement’)]”,
                “infrastructureEncryption”: “[parameters(‘infrastructureEncryption’)]”
            },
            “sku”: {
                “name”: “[parameters(‘skuName’)]”,
                “tier”: “[parameters(‘skuTier’)]”,
                “capacity”: “[parameters(‘skuCapacity’)]”,
                “size”: “[parameters(‘skuSizeMB’)]”,
                “family”: “[variables(‘skuFamily’)]”
            },
            “tags”: {},
            “type”: “Microsoft.DBforMariaDB/servers”
        }
    ]
}

 

3.Azure Database for MariaDBのパラメータ設定CSV作成する

Azure Database for MariaDB を作成する為にCSVから読み込むパラメータは以下の通りになります。リソースグループ名はデプロイ先のリソースグループ名になります。

    • リソースグループ(ResourceGroupName)
    • DBサーバ名(serverName)(小文字のみです)
    • 管理者ユーザ名(AppServicePlanName)
    • 管理者ユーザーパスワード(administratorLoginPassword)
    • リージョン名(location)
    • SKU名(skuName)
    • ストレージサイズ(skuSizeMB)
    • 価格レベル(skuTier)
    • MariaDBのバージョン(version)
    • バックアップ保存日数(backupRetentionDays)
    • バックアップ冗長(geoRedundantBackup)
    • ストレージの自動拡張(storageAutoGrow)
    • SSKの強制(sslEnforcement)
    • DB暗号化(infrastructureEncryption)

CSVのサンプルは以下のようになりました。(CSVが長くなっためPart1、Part2、Part3の3行に分割しています。)

#Part1
ResourceGroupName,location,serverName,administratorLogin,administratorLoginPassword,skuName,
RG1,japaneast,mariadb-01,mariadatabaseadmin,mariadbadminpassword,B_Gen5_1,5120,
 
#Part2
skuSizeMB,skuTier,version,backupRetentionDays,geoRedundantBackup,
5120,Basic,10.3,7,Disabled,Disabled,Enabled,Disabled
 
#Part3

storageAutoGrow,sslEnforcement,infrastructureEncryption

Disabled,Enabled,Disabled

4.Azure Database for MariaDBをARMテンプレート+Power Shellでデプロイする

ARMテンプレートのパス、CSVのパスを指定してARMテンプレートをデプロイするPower Shellを実行します。MariaDBがデプロイされます。

Azure Database for MariaDBのARMテンプレートをデプロイするPower Shellはこんな感じになりました。

#Azure Database for MariaDB ARMTemplate Deploy

 
#基本設定
#serverName DBサーバ名
#administratorLogin 管理者ユーザー名
#administratorLoginPassword 管理者ユーザーパスワード
#location リージョン名
#skuName SKU名(skuTier略称(B,GP,MO)+Gen5+vCore数)
#skuSizeMB ストレージサイズ
#skuTier 価格レベル(Basic,GeneralPurpose,MemoryOptimize))
#version MariaDBのバージョン(10.2,10.3))
#backupRetentionDays バックアップ保存日数(最低7日)
#geoRedundantBackup バックアップでGeo冗長を利用するか
#storageAutoGrow ストレージの自動拡張
#sslEnforcement MariaDBへアクセスする際にSSLを強制するか
#infrastructureEncryption DB暗号化

$TemplateFilePath = “ARMテンプレートファイルのパス”
$ImportCSVPath = “CSVファイルのパス”

# Inclued Configure Entries
$csv = Import-Csv -path $ImportCSVPath 

# Template Deploy
foreach( $c in $csv ){

$secureadminpass = ConvertTo-SecureString $c.administratorLoginPassword -AsPlainText -Force

New-AzResourceGroupDeployment `
  -ResourceGroupName $c.ResourceGroupName `
  -TemplateFile $TemplateFilePath `
  -serverName $c.serverName `
  -administratorLogin $c.administratorLogin `
  -administratorLoginPassword $secureadminpass `
  -location $c.location `
  -skuName $c.skuName `
  -skuSizeMB $c.skuSizeMB `
  -skuTier $c.skuTier `
  -version $c.version `
  -backupRetentionDays $c.backupRetentionDays `
  -geoRedundantBackup $c.geoRedundantBackup `
  -storageAutoGrow $c.storageAutoGrow `
  -sslEnforcement $c.sslEnforcement `
  -infrastructureEncryption $c.infrastructureEncryption `
}

デプロイが成功すると、Power Shellの実行ログにProvisioningState : Succeededと表示され、実際にPortal上で確認するとPortalを利用した場合と同じ設定通り出来ている事が確認できます。

なお、接続方法については、以下の記事に記載しておりますので、こちらも参考ください。

Azure Database for MariaDBに接続してみた

 

Linux のAzure Web Appsをデプロイしてみた

 

Linux のWeb Apps のデプロイをAzure PortalとAzure Resource Manager(ARM)テンプレートの2つパターンで実施してみました。

ARMテンプレート利用時には、以下の点に対応してみました。

    • 既存のApp Serviceプランを利用するか、新規に作成するかを選べるようにしてみました。
    • Power Shellを使ってデプロイする場合に、ARMテンプレートのパラメータをCSVから読み込むようにして再利用しやすいようにしています。

※ARMテンプレートをWindowsと共通にしたかったのですが、linuxFxVersionという項目があり無理でした。

ARMテンプレートを使ってデプロイするにあたっては、以下の3つのファイルを作成しています。

    • Web Apps(Linux用) を定義するARMテンプレート(JSONファイル)
    • Web Apps(Linux用) プランのパラメータを指定するCSV
    • ARMテンプレートをデプロイするPower Shell

作成したものは GitHub上にも公開しております。

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

 

App Serviceプラン単体での作成は、前回実施していますのでこちらの記事も併せて参考にして頂ければと。

Azure App Service プランを単体で作ってみた

 

1 .Azure Portal上でLinuxのWeb Appsを新規作成する

Azure Portalを利用して、Linux のApp Service を作成します。

Azure Portal上のすべてのサービスでApp Serviceと入力すると、App Serviceのメニューが表示されれますのでこれを選択します。

+追加をクリックします。

一般的な使い方で指定するのは、以下の内容になるかと思います。実際に利用するリソースに合わせて設定します。

    • リソースグループ
    • 名前
    • 公開(Dockerコンテナを利用するか(今回はコードを選択))
    • ランタイムスタック(使用する開発言語(これを選ぶとオペレーティングシステムも自動選択されます)
    • オペレーティングシステム
    • 地域(ロケーション)
    • AppServiceプラン名
    • Application Insightsの利用可否(利用できる組み合わせには制限があり、LinuxとPHPの構成では利用不可です。)
    • タグ

リソースグループ、Web Apps名、公開(コンテナの利用等)、ランタイムスタック、地域(ロケーション)やApp Serviceプラン名を選択し、次へクリックします。オペレーティングシステムはWeb Apps利用時に選択されるランタイムスタックにより自動的に選択されます。

次に監視の設定を実施します。利用できる組み合わせには制限があり、LinuxとPHPの構成では利用不可な為、”いいえ”のままにします。

次にタグの設定を実施します。必要に応じて適時付与します。

設定したら、確認および作成をクリックします。確認画面が表示されますので、作成をクリックします。

完了するとLinuxのWeb Apps が作成されます。

 

2 .LinuxのWeb AppsのAzure Resource Manager(ARM)テンプレート

マイクロソフト様が公開されているサイトを参考にし、Web AppsのARMテンプレートを作成してみました。

https://github.com/Azure/azure-quickstart-templates/tree/master/101-webapp-basic-linux

以下の点を修正しています。

    • Conditionを利用して、既存のApp Serviceプランを利用するかどうかを選ぶようにしてみました。パラメータにnewOrExistingを追加しています。newを指定した場合は新規にApp Serviceプランが作成され、existingを指定すると既存のものを利用します。
    • App Serviceプラン部分は前回記事で作成のものを利用しています。

結果、Web AppsのARMテンプレートはこういう形になりました。Linux用のARMテンプレートなので、Kind(linux)やreserved(true)を固定値で設定する事も可能です。

{

  “$schema”: “https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#”,
  “contentVersion”: “1.0.0.0”,
  “parameters”: {
    “webAppName”: {
        “type”: “string”,
        “defaultValue” : “AzureLinuxApp”,
        “metadata”: {},
        “minLength”: 2
    },
    “appServicePlanName”:{
        “type”: “string”,
        “defaultValue” :”[concat(‘AppServicePlan-‘, parameters(‘webAppName’))]”,
        “metadata”: {}
    },
    “sku”: {
        “defaultValue”: “Basic”,
        “type”: “string”,
        “allowedValues”: [
            “Basic”,
            “Standard”,
            “PremiumV2”
        ]
    },
    “skucode”: {
        “defaultValue”: “B1”,
        “type”: “string”,
        “allowedValues”: [
            “B1″,”B2″,”B3”,
            “S1″,”S2″,”S3”,
            “P1v2″,”P2v2″,”P3v2”
        ]
    },
    “reserved”: {
            “defaultValue”: “true”,
            “type”: “bool”,
            “metadata”: {}
    },
    “kind”: {
            “type”: “string”,
            “allowedValues”: [
                “linux”,
                “app”
                ]
     },
    “linuxFxVersion” : {
        “type”: “string”,
        “defaultValue” : “PHP|7.3”,
        “metadata”: {}
    },
    “location”: {
      “type”: “string”,
      “defaultValue”: “[resourceGroup().location]”,
      “metadata”: {
      }
    },
    “newOrExisting”: {
        “type”: “string”,
        “allowedValues”: [
            “new”,
            “existing”
            ]
    }
  },
  “variables”: {},
   “resources”: [
        {
    “condition”: “[equals(parameters(‘newOrExisting’), ‘new’)]”,
    “apiVersion”: “2018-11-01”,
            “type”: “Microsoft.Web/serverfarms”,
            “name”: “[parameters(‘AppServicePlanName’)]”,
            “location”: “[parameters(‘location’)]”,
            “kind”: “[parameters(‘kind’)]”,
            “tags”: {},
            “properties”: {
                “name”: “[parameters(‘AppServicePlanName’)]”,
                “reserved”: “[parameters(‘reserved’)]”
            },
            “sku”: {
                “Tier”: “[parameters(‘sku’)]”,
                “Name”: “[parameters(‘skuCode’)]”
            }
        },
        {
      “type”: “Microsoft.Web/sites”,
      “apiVersion”: “2018-11-01”,
      “name”: “[parameters(‘webAppName’)]”,
      “location”: “[parameters(‘location’)]”,
      “kind”: “linux,app”,
      “dependsOn”: [
        “[resourceId(‘Microsoft.Web/serverfarms’, parameters(‘appServicePlanName’))]”
      ],
      “properties”: {
        “serverFarmId”: “[resourceId(‘Microsoft.Web/serverfarms’, parameters(‘appServicePlanName’))]”,
        “siteConfig”: {
            “linuxFxVersion”: “[parameters(‘linuxFxVersion’)]”
          }
      }
    }
  ]
}

 

3.LinuxのWeb Appsのパラメータ設定CSV作成する

Web Apps を作成する為にCSVから読み込むパラメータは以下の通りになります。リソースグループ名はデプロイ先のリソースグループ名になります。

    • リソースグループ(ResourceGroupName)
    • Web Apps名(webAppName)
    • App Serviceプラン名(AppServicePlanName)
    • オペレーティングシステム(reserved,Kind)
    • 地域(location)
    • App Serviceプランの価格レベル(sku,skucode)
    • ランタイムスタック(RuntimeStackVersion)
    • 新規作成か既存利用か(newOrExisting)

上記を踏まえてCSVをサンプルで作成以下のようになります。(RuntimeStackVersionで改行を入れてますので実施に利用時は抜いてください。)

#新規作成の場合
ResourceGroupName,location,webAppName,AppServicePlanName,sku,skucode,reserved,kind,
RuntimeStackVersion,newOrExisting

RG1,japaneast,wbapps-01,app-service-plan-001,Basic,B1,true,linux,PHP|7.3,new
 
#既存作成の場合(事前に作成した、app-service-plan-001を利用する場合)
ResourceGroupName,location,webAppName,AppServicePlanName,sku,skucode,reserved,kind,
RuntimeStackVersion,newOrExisting

RG1,japaneast,wbapps-01,app-service-plan-001,Basic,B1,true,linux,PHP|7.3,existing

4.LinuxのWeb AppsをARMテンプレート+Power Shellでデプロイする

ARMテンプレートのパス、CSVのパスを指定してARMテンプレートをデプロイするPower Shellを実行します。

ARMテンプレートをデプロイするPower Shellは下記のようになりました。

#Web Apps Template For Linux Deploy
#基本設定
#webAppName Web Apps名
#AppServicePlanName AppServicePlan名
#location リージョン名
#sku プラン名(Basic,Standard,PremiumV2)、
#skucode インスタンス名(B1等)
#kind (linux)
#linuxFxVersion(RuntimeStackVersion)(ランタイムスタック)
#newOrExisting(新規作成 Or 既存利用)

$TemplateFilePath = “ARMテンプレートのパス”
$ImportCSVPath = “CSVファイルのパス”

# Inclued Configure Entries
$csv = Import-Csv -path $ImportCSVPath 

# Template Deploy
foreach( $c in $csv ){

# Bool Value
[Bool]$boolValue = [System.Convert]::ToBoolean($c.reserved)

New-AzResourceGroupDeployment `
  -ResourceGroupName $c.ResourceGroupName `
  -TemplateFile $TemplateFilePath `
  -webAppName $c.webAppName `
  -AppServicePlanName $c.AppServicePlanName `
  -location $c.location `
  -sku $c.sku `
  -skucode $c.skucode `
  -reserved $boolValue `
  -kind $c.kind `
  -linuxFxVersion $c.RuntimeStackVersion `
  -newOrExisting $c.newOrExisting `
}

デプロイが成功すると、Power Shellの実行ログにProvisioningState : Succeededと表示され、実際にPortal上で確認すると設定通り出来ている事が確認できます。

 

Azure App Service プランを単体で作ってみた

 

App Service プランを単体での作成をやってみました。Azure Portalで作成した後、ARMテンプレートでもやってみました。

App Service プラン自体は、App Service作成時にも作れますが、今回は勉強を兼ねて事前に作成してみました。

App Service プランは、App Service利用する為のリソース利用料になります。

https://azure.microsoft.com/ja-jp/pricing/details/app-service/plans/

App Serviceを作成時にリソースとして指定されるもので、機能やリソースによって価格が決まります。

https://azure.microsoft.com/ja-jp/pricing/details/app-service/windows/

 

ARMテンプレートを使ってデプロイするにあたっては、以下の3つのファイルを作成しています。ARMテンプレートを使った場合は、複数のコンテナーを一括でデプロイできるようにパラメータをCSVから読み込むようにしています。

    • App Service プランを定義するARMテンプレート(JSONファイル)
    • App Service プランのパラメータを指定するCSV
    • ARMテンプレートをデプロイするPower Shell

作成したものは GitHub上にも公開しております。

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

1 .Azure Portal上でApp Service プランを新規作成する

Azure Portalを利用して、App Service プランを作成します。

Azure Portal上のすべてのサービスでApp Service Planと入力すると、App Service プランのメニューが表示されれますのでこれを選択します。

App Service プランに移動しますので、+追加をクリックします。

一般的な使い方で指定するのは、以下の内容になるかと思います。実際に利用するリソースに合わせて設定します。

    • リソースグループ
    • 名前
    • オペレーティングシステム
    • 地域(ロケーション)
    • 価格レベル
    • タグ

まず、リソースグループ、名前、オペレーティングシステム、価格レベルを選択し、次へクリックします。オペレーティングシステムはApp Service利用時に選択するフレームワークにより選択します。.Net環境を利用するのであればWindows、PHPならばLinuxという感じです。現時点ではコンテナの場合はLinuxの方が選べるロケーションが多いようです。

次にタグの設定を必要に応じて実施します。

設定したら、確認および作成をクリックします。確認画面が表示されますので、作成をクリックします。App Service プランが作成されます。

.App Service プランのAzure Resource Manager(ARM)テンプレート

マイクロソフト様が公開されているサイトを参考にし、App ServiceプランのARMテンプレートを作成してみました。

https://docs.microsoft.com/ja-jp/azure/templates/microsoft.web/serverfarms

以下の点を修正しています。

    • skuやskucodeのデフォルト値はBasic前提にしてます。Isolatedも使わなかったので抜いてます。利用環境に合わせて適時修正下さい。
    • reservedとkindはパラメータで指定するようにしています。

結果、App ServiceプランのARMテンプレートはこういう形になりました。

{
    “$schema”: “http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#”,
    “contentVersion”: “1.0.0.0”,
    “parameters”: {
        “AppServicePlanName”: {
            “type”: “string”
        },
        “location”: {
            “defaultValue”: “[resourceGroup().location]”,
            “type”: “string”
        },
        “sku”: {
            “defaultValue”: “Basic”,
            “type”: “string”,
            “allowedValues”: [
                “Basic”,
                “Standard”,
                “PremiumV2”
                ]
        },
        “skucode”: {
            “defaultValue”: “B1”,
            “type”: “string”,
            “allowedValues”: [
                “B1″,”B2″,”B3”,
                “S1″,”S2″,”S3”,
                “P1v2″,”P2v2″,”P3v2”
                ]
        },
        “reserved”: {
            “defaultValue”: “true”,
            “type”: “bool”,
            “metadata”: {}
        },
        “kind”: {
            “type”: “string”,
            “allowedValues”: [
                “linux”,
                “app”
                ]
        }
     },
    “variables”: {},
    “resources”: [
        {
            “apiVersion”: “2018-11-01”,
            “type”: “Microsoft.Web/serverfarms”,
            “name”: “[parameters(‘AppServicePlanName’)]”,
            “location”: “[parameters(‘location’)]”,
            “kind”: “[parameters(‘kind’)]”,
            “tags”: {},
            “properties”: {
                “name”: “[parameters(‘AppServicePlanName’)]”,
                “reserved”: “[parameters(‘reserved’)]”
            },
            “sku”: {
                “Tier”: “[parameters(‘sku’)]”,
                “Name”: “[parameters(‘skuCode’)]”
            }
        }
    ]
}

 

3.App Serviceプランのパラメータ設定CSV作成する

App Serviceプランを作成する為にCSVから読み込むパラメータは以下の通りになります。リソースグループ名はデプロイ先のリソースグループ名になります。

    • リソースグループ(ResourceGroupName)
    • 名前(AppServicePlanName)
    • オペレーティングシステム(reserved,Kind)
    • 地域(location)
    • 価格レベル(sku,skucode)
    • タグ(今回は未指定)

オペレーティングシステムの組み合わせは下記の通りになります。Windowsの場合は指定がappになります。また同じリソースグループにWindowsとLinuxのデプロイはエラーになります。(現時点でのAzureでの仕様になります。)

    • Linuxの場合は、reservedをtrue、kindをlinuxに指定します。
    • Windowsの場合は、reservedをfalse、kindをappに指定します。

上記を踏まえてCSVをサンプルで作成以下のようになります。

RG1にLinux(B1)、RG2にWindows(S1)でデプロイする想定にしています。

ResourceGroupName,location,AppServicePlanName,sku,skucode,reserved,kind,
RG1,japaneast,app-service-plan-001,Basic,B1,true,linux,
RG2,japaneast,app-service-plan-002,Standard,S1,false,app,

4.App ServiceプランをARMテンプレート+Power Shellでデプロイする

ARMテンプレートのパス、CSVのパスを指定してデプロイを実施します。

reservedについては、bool形式である為StriingからBoolに変換ししています。

#AppServicePlan Template Deploy

#基本設定
#Name AppServicePlan名
#location リージョン名
#sku プラン名(Basic,Standard,PremiumV2)、
#skucode インスタンス名(B1等)
#kind (linux or Win)(Winの場合はappと指定する)

$TemplateFilePath = “ARMテンプレートのパス”
$ImportCSVPath = “CSVファイルのパス”

# Inclued Configure Entries
$csv = Import-Csv -path $ImportCSVPath 

# Template Deploy
foreach( $c in $csv ){

# Bool Value
[Bool]$boolValue = [System.Convert]::ToBoolean($c.reserved)

New-AzResourceGroupDeployment `
  -ResourceGroupName $c.ResourceGroupName `
  -TemplateFile $TemplateFilePath `
  -location $c.location `
  -AppServicePlanName $c.AppServicePlanName `
  -sku $c.sku `
  -skucode $c.skucode `
  -reserved $boolValue `
  -kind $c.kind
}
 

デプロイが成功すると、Power Shellの実行ログにProvisioningState : Succeededと表示され、実際にPortal上で確認すると設定通り出来ている事が確認できます。

Azure Recovery Services コンテナーを作ってみた

 

Azure Recovery Services コンテナーはAzure Virtual Machine等のバックアップやリストアに使用されるAzure上のサービスです。

色々な機能が提供されていますので、機能内容はマイクロソフト様のサイトでご確認下さい。自分はシンプルにバックアップソフトとバックアップストレージがセットで提供されるサービスと理解しています。

https://docs.microsoft.com/ja-jp/azure/backup/backup-azure-recovery-services-vault-overview

 

今回は、Azure Recovery Services コンテナー作成を、Azure PortalとAzure Resource Manager(ARM)テンプレートを利用して実施してみました。

Azure Portalで実施した内容を踏まえて、ARMテンプレートでのデプロイをやっていみました。

ARMテンプレートを使ってデプロイするにあたっては、以下の3つのファイルを作成しています。ARMテンプレートを使った場合は、複数のコンテナーを一括でデプロイできるようにパラメータをCSVから読み込むようにしています。

    • Azure Recovery Services コンテナーを定義するARMテンプレート(JSONファイル)
    • Azure Recovery Services コンテナーのパラメータを指定するCSV
    • ARMテンプレートをデプロイするPower Shell

今回はAzure Recovery Services コンテナーの作成のみとなっております。Virtual Machineのバックアップ設定やバックアップスケジュール設定は別の機会に実施したいと思います。

作成したものは GitHub上にも公開しております。

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

1 .Azure Portal上でRecovery Services コンテナーを新規作成する

Azure Portalを利用したRecovery Services コンテナーを作成は以下の手順で実施しました。

    • Recovery Services コンテナーの作成
    • バックアップ ストレージの冗長選択(ローカル冗長ストレージ (LRS) と Geo 冗長ストレージ (GRS))
    • 論理削除(14日間保持)、物理削除(即時削除)の選択

バックアップストレージの冗長選択はバックアップ設定した後では変更不可である為最初に設定します。また、論理削除にしておくと、Recovery Services コンテナーが削除が論理的にデータ保存されている14日間出来なくなります。その為必要に応じて設定変更します。

Azure Portalを利用した作成手順はマイクロソフト様のサイトに公開されています。今回は勉強もかねて実施してみました。

https://docs.microsoft.com/ja-jp/azure/backup/backup-create-rs-vault

 

最初に、Recovery Services コンテナーの作成を行います。

Azure Portal上のすべてのサービスでRecoveryと入力すると、Recovery Services コンテナーのメニューが表示されれますのでこれを選択します。

Recovery Services コンテナーに移動しますので、+追加をクリックします。

一般的な使い方で指定するのは、以下の内容になるかと思います。実際に利用するリソースに合わせて設定します。

    • リソースグループ
    • 資格情報コンテナー名(名前ですね。)
    • リージョン
    • タグ(プレビューで追加になってました。)

まず、リソースグループ、資格情報コンテナー名、リージョンを選択し、次へクリックします。

次にタグの設定を必要に応じて実施します。

設定したら、確認および作成をクリックします。確認画面が表示されますので、作成をクリックします。Recovery Services コンテナーが作成されます。

Recovery Services コンテナーが作成されましたので、最初にやっておくべき設定を行います。

作成したRecovery Services コンテナーのメニューにあるプロパティを選択します。

バックアップ構成という項目が表示されているかと思います。ここで更新をクリックします。下記画面が表示されます。ストレージレプリケーションの種類を選択します。

デフォルトGeo冗長になっております。

別リージョンにリカバリするやDCが全部吹っ飛んでもリカバリするんだ、というような別リージョンに保管する要件が無い場合はローカル冗長(LRS)に変更します。

マイクロソフト様のサイトを見て頂ければわかりますが、料金が2倍違います。(保管場所が2重になるので、容量も2倍。という事で料金も2倍という事だと思います。。。)

https://azure.microsoft.com/ja-jp/pricing/details/backup/

設定変更した場合は、忘れずに保存します。

次に、セキュリティ設定を行います。(なお、こちらは後からでも変更可能です。)

即時物理削除したい場合は、論理削除を無効に設定します。

設定変更した場合は保存します。論理削除の保存期間は14日間固定のようで変更はできないようです。

.Recovery Services コンテナーのAzure Resource Manager(ARM)テンプレート

マイクロソフト様が公開されているARMテンプレートを参考にし、デフォルト値のみを変更しています。

https://github.com/Azure/azure-quickstart-templates/blob/master/101-recovery-services-vault-create/azuredeploy.json

https://docs.microsoft.com/ja-jp/azure/site-recovery/quickstart-create-vault-template?tabs=CLI

基本は参考通りなのですが、以下の点だけ修正しています。

    • バックアップ構成のデフォルト値をローカル冗長になるようにしています。
    • バックアップアラート部分等は設定してません。
    • TAGの設定はしていません。
    • 論理削除はデフォルトの通り有効になります。(無効にする方法が見当たりませんでした。)

skuNameと、skuTierは固定値になります。その為、Parametersの指定ではなく、variablesでの指定としています。

ARMテンプレートでは、バックアップポリシーの規定をしてませんが、Azure Portalを利用して作成した時と同様に、HourlyLogBackupとDefaultPolicyは作成されます。

Recovery Services コンテナーのARMテンプレートはこういう形になりました。

{
  “$schema”: “https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#”,
  “contentVersion”: “1.0.0.0”,
  “parameters”: {
    “vaultName”: {
      “type”: “string”,
      “metadata”: {}
   },
    “changeStorageType”: {
      “type”: “bool”,
      “defaultValue”: true ,
      “metadata”: {}
    },
    “vaultStorageType”: {
      “type”: “string”,
      “defaultValue”: “LocallyRedundant”,
      “allowedValues”: [
        “LocallyRedundant”,
        “GloballyRedundant”
      ],
      “metadata”: {}
    },
    “location”: {
      “type”: “string”,
      “defaultValue”: “[resourceGroup().location]”,
      “metadata”: {}
    }
  },
  “variables”: {
    “skuName”: “RS0”,
    “skuTier”: “Standard”
  },
 “resources”: [
   {
     “type”: “Microsoft.RecoveryServices/vaults”,
     “apiVersion”: “2018-01-10”,
     “name”: “[parameters(‘vaultName’)]”,
     “location”: “[parameters(‘location’)]”,
     “sku”: {
       “name”: “[variables(‘skuName’)]”,
       “tier”: “[variables(‘skuTier’)]”
     },
   “properties”: {}
   },
   {
     “condition”: “[parameters(‘changeStorageType’)]”,
     “type”: “Microsoft.RecoveryServices/vaults/backupstorageconfig”,
     “apiVersion”: “2018-01-10”,
     “name”: “[concat(parameters(‘vaultName’), ‘/vaultstorageconfig’)]”,
     “dependsOn”: [
         “[resourceId(‘Microsoft.RecoveryServices/vaults/’, parameters(‘vaultName’))]”
     ],
     “properties”: {
         “StorageModelType”:”[parameters(‘vaultStorageType’)]”
     }
   }
 ]
}

 

3.Azure Recovery Services コンテナーのパラメータ設定CSV作成する

Azure Recovery Services コンテナーを作成する為にCSVから読み込むパラメータは以下の通りになります。リソースグループ名はデプロイ先のリソースグループ名になります。

    • リソースグループ(ResourceGroupName)
    • リージョン(location)
    • コンテナー名(vaultName)
    • ストレージの種類の変更(changeStorageType)
    • コンテナー ストレージの種類(vaultStorageType)

ストレージの種類の変更と、コンテナーストレージの種類の組み合わせは下記の通りになります。

    • ローカル冗長の場合は、changeStorageTypeをTrue、vaultStorageTypeをLocallyRedundantに指定します。
    • Geo冗長のの場合は、changeStorageTypeをfalse、vaultStorageTypeをGloballyRedundantに指定します。

上記を踏まえてCSVをサンプルで作成以下のようになります。

RG1にローカル冗長、RG2にGeo冗長でデプロイする想定にしています。

ResourceGroupName,location,vaultName,changeStorageType,vaultStorageType
RG1,japaneast,rsc-01,true,LocallyRedundant
RG2,japanwest,rsc-02,false,GloballyRedundant

4.Azure Recovery Services コンテナーをARMテンプレート+Power Shellでデプロイする

ARMテンプレートのパス、CSVのパスを指定してデプロイを実施します。

changeStorageTypeについては、bool形式である為そのままCSVを読み込むとエラーになりました。調べた結果、明示的にBool指定が必要だという事がわかりましたので、# Bool Value行でStriingからBoolに変換しエラーにならないようにしています。

#RecoveryServicesコンテナー Template Deploy

$TemplateFilePath = “ARMテンプレートファイルのパス”
$ImportCSVPath = “パラメータを指定するCSVファイルのパス”

# Inclued Configure Entries
$csv = Import-Csv -path $ImportCSVPath 

# Template Deploy
foreach( $c in $csv ){

# Bool Value
[Bool]$boolValue = [System.Convert]::ToBoolean($c.changeStorageType)

# Deploy Command
New-AzResourceGroupDeployment `
  -ResourceGroupName $c.ResourceGroupName `
  -TemplateFile $TemplateFilePath `
  -location $c.location `
  -changeStorageType $boolValue `
  -vaultStorageType $c.vaultStorageType `
  -vaultName $c.vaultName
}

デプロイが成功すると、Power Shellの実行ログにProvisioningState : Succeededと表示され、実際にAzure Portal上で確認すると設定通り出来ている事が確認できました。

ARMテンプレートを使った場合は、論理削除の設定は有効になっています。

AzureパブリックIP作成をARMテンプレート使ってやってみた

 

AzureのパブリックIP作成を、Azure Resource Manager(ARM)テンプレート使ってやってみました。

AzureのパブリックIPはAzureの各リソース(Azure Virtual Machine等)がインターネットと通信する為に使用されます。その為仮想マシンを構築する等、Azureを利用する多くの場合に、パブリックIPが作成する事になります。

多くの場合は、インターネットにアクセスするリソース作成時に合わせて作成することも可能ですが、今回は、AzureパブリックIPを単体で作成してみました。

パブリックIPに関する詳細はマイクロソフト様のサイトで確認できます。

https://docs.microsoft.com/ja-jp/azure/virtual-network/virtual-network-ip-addresses-overview-arm#public-ip-addresses

Azure Resource Manager(ARM)テンプレートを使ってデプロイするにあたっては、以下の3つのファイルを作成しています。

    • パブリックIPを定義するARMテンプレート(JSONファイル)
    • パブリックIPのパラメータを指定するCSV
    • ARMテンプレートをデプロイするPower Shell

複数のパブリックIPを纏めてを作れるようにしてみました。

今回作成したものは GitHub上にも公開しております。

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

1 .Azure Portal上でパブリックIPを新規作成する

Azure Portal上のすべてのサービスで、パブリックIPと入力するとパブリックIPのメニューが表示されれます。追加をクリックします。

作成画面が表示されます。

一般的な使い方で指定するのは、以下の内容になるかと思います。実際に利用するリソースに合わせて設定します。

    • 名前
    • DNS 名ラベル
    • リソースグループ
    • 場所(リージョン)

IPアドレスの割り当てを動的にすると、IPアドレス変わる可能性があります。この場合にDNS名ラベルを指定しておくと名前解決をしてくれます。IPアドレス変更があってもDNS名ラベルで指定した名前で常にアクセスできます。

すべて入力した後に作成をクリックすると、作成されます。(確認画面は表示されません。)

.パブリックIPのAzure Resource Manager(ARM)テンプレート

今回は、基本的な設定で確認する為に、以下の条件で設定で作成してみました。

    • IPバージョン、SKU、アイドルタイムアウトは固定値としています
    • 固定値はARMテンプレート内のvariablesで定義してみました
      • SKU( “sku”:”Basic”)
      • IPバージョン(publicIPAddressVersion”:”IPv4″)
      • アイドルタイムアウト( “idleTimeoutInMinutes”: “4”)
    • パラメータでDNS 名ラベルを設定する

パブリックIPのARMテンプレートはこういう形になりました。

{ 

    “$schema”: “https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#”,
    “contentVersion”: “1.0.0.0”,
    “parameters”: {
        “location”: {
            “type”: “string”,
            “metadata”:{} 
        },
        “publicIPAddresses_name”: {
            “type”: “string”,
            “metadata”: {}
        },
        “domainNameLabel”: {
            “type”: “string”,
            “metadata”: {}
        },
        “publicIPAllocationMethod”: {
            “type”: “string”,
            “allowedValues”: [
                “Dynamic”,
                “Static”
            ]
        }
    },
        “variables”: {
            “sku”:“Basic”,
            “publicIPAddressVersion”:”IPv4″,
            “idleTimeoutInMinutes”: “4”
        },
    “resources”: [
        {
            “type”: “Microsoft.Network/publicIPAddresses”,
            “apiVersion”: “2020-03-01”,
            “name”: “[parameters(‘publicIPAddresses_name’)]”,
            “location”: “[parameters(‘location’)]”,
            “sku”: {
                “name”: “[variables(‘sku’)]”
            },
            “properties”: {
                “publicIPAddressVersion”: “[variables(‘publicIPAddressVersion’)]”,
                “publicIPAllocationMethod”:  “[parameters(‘publicIPAllocationMethod’)]”,
                “idleTimeoutInMinutes”: “[variables(‘idleTimeoutInMinutes’)]”,
                “dnsSettings”: {
                    “domainNameLabel”: “[parameters(‘domainNameLabel’)]”
                },
                “ipTags”: []
            }
        }
    ]
}

固定値は適時変更して作成します。

3.パブリックIP設定用のCSV作成する

パブリックIP を作成する為にCSVから読み込むパラメータは以下の通りになります。リソースグループ名はデプロイ先のリソースグループ名になります。

    • リソースグループ名(ResourceGroupName)
    • リージョン名(location)
    • パブリックIP名(vnetName)
    • DNS 名ラベル(subnet_name)
    • IP アドレスの割り当て(動的か静的か)

実際にパラメータCSVをサンプルで作成以下のようになります。

ResourceGroupName,location,publicIPAddresses_name,domainNameLabel,publicIPAllocationMethod,
RG1,japanwest,pubip-01,pubip-dnsname-01,Dynamic,
RG2,japanwest,pubip-02,pubip-dnsname-02,Static,

4. パブリックIPをARMテンプレート+Power Shellでデプロイする

ARMテンプレートのパス、CSVのパスを指定してデプロイを実施します。

#Public IP Template Deploy

$TemplateFilePath = “テンプレートファイルのパス”
$ImportCSVPath = “CSVファイルのパス”

# Inclued Configure Entries
$csv = Import-Csv -path $ImportCSVPath

# Template Deploy
foreach( $c in $csv ){

New-AzResourceGroupDeployment `
-ResourceGroupName $c.ResourceGroupName `
-TemplateFile $TemplateFilePath `
-location $c.location `
-publicIPAddresses_name $c.publicIPAddresses_name `
-domainNameLabel $c.domainNameLabel `
-publicIPAllocationMethod $c.publicIPAllocationMethod `
}

デプロイが成功すると、以下の通りにProvisioningState : Succeededと表示されます。(ログは途中省略しています。)

ResourceGroupName : RG1
OnErrorDeployment :
DeploymentName : PbulicIP作成_template_20200517
CorrelationId :
ProvisioningState : Succeeded
Timestamp : 2020/YY/MM hh:ss:mm
Mode : Incremental

===================== ========================= ==========
location String japanwest
publicIPAddresses_name String pubip-01,pubip-dnsname-01,Dynamic,
domainNameLabel String pubip-dnsname-01,Dynamic
publicIPAllocationMethod String Dynami

CSVで指定した値で作成した値で作成されている事が確認できます。

ARMテンプレートを使ってSubnet単体でデプロイしてみた

 

既存の仮想ネットワークに対して、サブネット単体でのデプロイをAzure Resource Manager(ARM)テンプレートを使って実施してみました。

パラメータをCSVから分けて読み込むようにする事で、作成先の仮想ネットワークを別にしたり、複数のサブネットを纏めてを作れるようにしてみました。

サブネットのデプロイは下記の3つのファイルで実施しています。

    • サブネットを定義するARMテンプレート(JSONファイル)
    • パラメータを指定するCSV
    • テンプレートをデプロイするPower Shell

今回作成したものは GitHub上にも公開しております。

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

仮想ネットワークの初期デプロイに関しては下記記事を参考にしていただければと。

https://www.tama-negi.com/2020/05/04/template-vnet-subnet/

Azure Resource Managerテンプレートを使って仮想ネットワークとサブネットをデプロイする(基本部分)

 

1 .Azure Portal上でサブネットを追加する

Azure Portal上でサブネットを追加するのは、仮想ネットワークのメニューになります。

メニューで仮想ネットワーク>サブネットと選びます。そうすると+サブネットが表示されますをクリックすると下記のような画面が表示されます。

名前やサブネットのアドレスレンジやNSGを選択した後にOKボタンをクリックすると、仮想ネットワークに対して、サブネットが作成されます。

今回はこの作業と同等の作業をARMテンプレートやパラメータ指定するCSVを使ってやってみます。ARMテンプレートのデプロイはAzure Portalを使用せずにPower Shellでデプロイしています。

.サブネットのAzure Resource Manager(ARM)テンプレート

今回は、基本的な設定で確認する為に、以下の条件で設定で作成してみました。

    • サービスエンドポイントの指定は行わない
    • NSGを指定する

作成したサブネット単体でのARMテンプレートのサンプルは以下のようになります。

{{

    “$schema”: “http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#”,
    “contentVersion”: “1.0.0.0”,
    “parameters”: {
        “location”: {
            “type”: “string”,
            “metadata”:{} 
        },
        “vnetName”: {
            “type”: “string”,
            “metadata”: {}
        },
        “subnet_name”: {
            “type”: “string”,
            “metadata”:{} 
        },
        “subnet_addressRange”: {
            “type”: “string”,
            “metadata”:{} 
        },
        “NSG_Name”: {
            “type”: “string”,
            “metadata”:{}
        }
    },
        “variables”: {
            “NSG_ID”:”[resourceId(‘Microsoft.Network/networkSecurityGroups’, parameters(‘NSG_Name’))]”,
            “privateEndpointNetworkPolicies”:”Enabled”,
            “privateLinkServiceNetworkPolicies”:”Enabled”
        },
        “resources”: [
        {
            “type”: “Microsoft.Network/virtualNetworks/subnets”,
            “apiVersion”: “2018-10-01”,
            “location”: “[parameters(‘location’)]”,
            “name”: “[concat(parameters(‘vnetName’) ,’/’,parameters(‘subnet_name’))]”,
            “properties”: {
                “addressPrefix”: “[parameters(‘subnet_addressRange’)]”,
                “networkSecurityGroup”: {
                                “id”: “[variables(‘NSG_ID’)]”
                                },
                            “serviceEndpoints”: [],
                            “delegations”: [],
                            “privateEndpointNetworkPolicies”: “[variables(‘privateEndpointNetworkPolicies’)]”,
                            “privateLinkServiceNetworkPolicies”: “[variables(‘privateLinkServiceNetworkPolicies’)]”
                            }
        }        
    ]
}

ARMテンプレート作成時にドはまりしました。嵌ったのは2点あります。 

1つ目は、サブネットのNameは、仮想ネットワーク名/サブネット名で作成する必要がありました。

“name”: “[concat(parameters(‘vnetName’) ,’/’,parameters(‘subnet_name’))]”,

contactを使用する事で、仮想ネットワーク名/サブネット名となるようにしています

2つ目は、depends Onで仮想ネットワークをアタッチしない点になります。

depends Onで仮想ネットワークをアタッチするようなサンプルが多く見かけたのですが、この方法で実施すると、同じ仮想ネットワークに複数のサブネットをデプロイ出来ませんでした。最後のサブネットで上書きされてしまい結果、1つのサブネットしか出来ない形になってしまいました。

3.サブネット設定用のCSV作成する

サブネット を作成する為にCSVから読み込むパラメータは以下の通りになります。リソースグループ名はデプロイ先のリソースグループ名になります。

    • リソースグループ名(ResourceGroupName)
    • リージョン名(location)
    • 仮想ネットワーク名(vnetName)
    • サブネット名(subnet_name)
    • サブネットのアドレス範囲(subnet_addressRange)
    • ネットワークセキュリティグループ名(NSG_name)

パラメータCSVのサンプルは以下のようになります。

ResourceGroupName,location,vnetName,subnet_name,subnet_addressRange,NSG_name,
デプロイ先RG名,リージョン名,仮想ネットワーク名,サブネット名,サブネットのアドレスレンジ,ネットワークセキュリティグループ名,
RG-1,japaneast,VNET-Name,Snbnet-Name,192.168.1.0/24,NSG-Name,

サブネットの設定内容に合わせてCSVを作成します。

4. サブネットをARMテンプレート+Power Shellでデプロイする

ARMテンプレートのパス、CSVのパスを指定してデプロイを実施します。

#Subnet Template Deploy

#基本設定(SubnetのNSGを指定する)

$TemplateFilePath = “テンプレートのファイルパス”
$ImportCSVPath = “CSVファイルのファイルパス”

# Inclued Configure Entries
$csv = Import-Csv -path $ImportCSVPath

# Template Deploy
 foreach( $c in $csv ){

New-AzResourceGroupDeployment `
 -ResourceGroupName $c.ResourceGroupName `
 -TemplateFile $TemplateFilePath `
 -location $c.location `
 -vnetName $c.vnetName `
 -subnet_name $c.subnet_name `
 -subnet_addressRange $c.subnet_addressRange `
 -NSG_Name $c.NSG_name `
}

デプロイが成功すると、以下の通りにProvisioningState : Succeededと表示されます。(ログは途中省略しています。)

ResourceGroupName : デプロイ先のリソースグループ名
OnErrorDeployment :
DeploymentName : Subnet作成(NSG付き)_template_20200515
CorrelationId :
ProvisioningState : Succeeded
Timestamp : 2020/YY/MM hh:ss:mm
Mode : Incremental

===================== ========================= ==========
location String リージョン名
vnetName String 仮想ネットワーク名
subnet_name String サブネット名
subnet_addressRange String サブネットアドレスレンジ
NSG_Name String NSG名 

CSVで指定した値で作成した値で作成されている事が確認できます。

※ARMテンプレート作成時にドはまりし、マイクロソフトサポート様にご教授頂きました。本当に有難うございました。

Azure Front Doorのバックエンド正常性について確認してみた

 

Azure Front Doorのバックエンド状態(正常に応答しているかどうか)の確認をしてみました。

また、Azure  Monitorの機能を利用してバックエンドの状態が異常な場合に検知するようにしてみました。Azure Monitorを使ってますのでメール送信等を行う事も標準機能で出来ます。

1.Azure Front Doorのメトリックで正常性プローブの応答率がわかる

マイクロソフト様のサイトを確認するとAzure Front Doorのメトリックで、バックエンドへの正常性プローブの応答率がわかるそうです。

https://docs.microsoft.com/ja-jp/azure/frontdoor/front-door-diagnostics

※マイクロソフト様のサイトでは、バックエンドの正常性の割合と記載されています。

実際にAzure Portal上で確認してみました。

メニューのメトリックを選択すると、下記画面が表示されます。ここでBackend Health Percentageを選択するとバックエンドプール全体での応答率(正常な割合)が表示されます。

応答率になるので、バックエンドプールに所属するバックエンドがすべて正常な場合は100%になります。

※バックエンド落としてないにも関わらず、なぜか100%になってなかったりするので、この編は調査が必要かも。という感じです。

バックエンドホスト単位で確認するには、フィルターの追加を使います。

フィルターの追加を選択すると、BackendとBackend Poolが表示されますので、Backendを選択します。そうすると、値の部分に設定しているバックエンドホスト名が表示されます。確認したいバックエンドのホスト名を選択します。

選択するとバックエンドホスト単位での応答率が確認できました。

ここの数値が低い場合は、バックエンドホストがAzure Front Doorの正常性プローブに応答を返せてないという状態になります。

2.Azure Front Doorのバックエンドの応答がない場合にAzure Monitorで検知する

Azure MonitorでAzure Front Doorのメトリック監視が実現出来ました。

まず、Azure Front Doorのメニューで、警告を選択します。表示された画面で新しいアラートルールを選択します。

そうすると、下記画面が表示されますので、条件を選択します。(Azure Monitorの設定か言った場合はリソースの所で、今回設定するFront Doorを選択します。)

   以下の画面が表示されますので、Backend Health Percentageを選択します。

そうするとシグナルロジックの構成画面が表示されます。ここで実際の設定を行います。

    • バックエンドホスト、バックエンドプールすべて監視する
    • しきい値は95%より小さい場合はアラートを発生させる
    • 15分単位での確認とする(15分単位の平均値で表あk)

上記のような設定の場合は、下記のような画面になります。

バックエンドホスト単位、バックエンドプール全体の状態どれを監視するかを選択します。

個別に設定可否を判断する場合は、ディメンションで対象を選択します。すべてを選択する場合は、選択にチェックを入れるとすべての項目が選択されます。

※注意点ですが、選択にチェックを入れるとAzure Front Door側でバックエンドやバックエンドホストを追加すると自動的に監視項目にも追加になります。

何%以下(より小さい)というしきい値を設定すると、バックエンドホスト側へのアクセスに問題がある場合、Azure Monitorで検知ができます。

上記設定が終わったら、完了をクリックします。

アクショングループや、名前等を付けて保存すれば、Azure Monitorでの監視設定が完了になります。

3.Azure Monitorで実際に送信されたメール

実際にアラートメールを送信すると、以下のような内容が記載されたメールが送信されます。

Metric name BackendHealthPercentage
Metric namespace frontdoors/フロントドア名
Dimensions

ResourceId = /subscriptions/サブスクリプションID/resourcegroups/リソースグループ名/providers/Microsoft.Network/frontdoors/フロントドア名

ApplicationEndpoint = バックエンドホスト名(1)

ApplicationEndpointPool = バックエンドホスト名(2)

Time Aggregation Average
Period Over the last 15 mins
Operator LessThan
Threshold 95
Criterion Type StaticThresholdCriterion

 

 

 

Azure Web アプリケーションファイアウォールを作ってみた

 

今回は、Azure Web アプリケーション ファイアウォールの作成を試してみました。

一般的に、Web アプリケーションファイアウォールは、悪意のある攻撃や一般的な Web 脆弱性 (SQL インジェクション、クロスサイト スクリプティングなど) から Web アプリを保護する目的で利用されます。

Web アプリケーション ファイアウォールの場合は、Azure Front DoorやAzure Application Gatewayと組み合わせて使用する事が可能です。(2020年5月10日現在 CDNもプレビューとなってました。)

https://azure.microsoft.com/ja-jp/services/web-application-firewall/

Azure Front Doorで利用する前提で作成しています。

1.Azure Portalを使って、Web アプリケーションファイアウォールを作成する

Azure Portal上で作業を実施したのですが、大まかには以下の流れになります。

    • 基本設定(適用するリソース(FrontDoor、Application Gateway、CDNの選択)デプロイするリソースグループや名前等)
    • ポリシー設定(防止か検出かの選択等)
    • 管理されているルール(適用するルールセット)
    • カスタム規則(自分でルールを作成する場合に使用)
    • 関連付け(どのFrontDoorやApplication Gatewayと関連付けを行うかの設定)
    • タグ付け

すべてのサービスでアプリケーションファイアウォールと入力すると、Web アプリケーション ファイアウォールのポリシー (WAF)が表示されますので、選択します。

追加をクリックすると下記画面が表示されます。今回はFront Door用ですので、次に対するポリシーはグローバルWAFを選択します。リソースグループや名前は自身の環境に合わせて適時設定します。

次に、ポリシー設定を行います。防止と検出を選択します。防止にすると不正なアクセスがブロックされます。検出にすると、Logが出力されるだけで、実際のアクセスはブロックされません。適時選択します。

Webアプリケーションファイアウォールログの確認は下記記事も参考にしていただければ。

 https://www.tama-negi.com/2020/04/27/azure-front-door-2/ ‎

Azure Front DoorやWeb Application Firewallのログを取得してLog Analyticsで確認する

次に適用するルールセットを選択します。通常の攻撃に対するものとBotアクセスに対するルールがあるようです。環境に合わせて適時選択します。

次にカスタム規則の設定を行います。こちらも適時実施しますが作成後実施した方が良いかと思います。

なお、カスタム規則の設定する場合は過去に実施した記事も参考頂ければと。

 https://www.tama-negi.com/2020/02/13/waf/

Azure Web アプリケーション ファイアウォールのカスタムルール設定(国別ブロック)

次に関連付けを行います。下記画面が表示されますので、フロントエンドホストの追加をクリックします。Front Doorが未作成の場合追加せずに次に進みます。

追加の場合は、以下の画面が表示されますので、FrootDoorとフロントエンドのホスト名を選択します。

 

次に、タグの画面が表示されますので、適時設定します。(ここは画面割愛します。)

最後に確認及び作成をクリックすれば、作業完了です。

2.Azure Front DoorにAzure Web アプリケーションファイアウォールを設定する

Azure Front DoorでWEB アプリケーション ファイアウォールの設定を行うのは、フロントエンドまたはドメインで実施します。フロントエンドのドメイン単位での設定になります。

Front Doorデザイナー>フロントエンドまたはドメイン>設定対象のドメインを選択すると、以下のように、WEB アプリケーション ファイアウォールという項目がありますので、こちらでポリシーを選択します。

設定して保存すれば、そのドメインへのアクセスに対してWEB アプリケーション ファイアウォールのルールが適用されます。

 

送信元IPアクセス制限をAzure Front Door+Azure Application Gatewayでやってみた

 

Azure Front DoorのバックエンドプールにAzure Application Gatewayを使用した場合に、送信元IPアクセス制限を試してみました。

実際に実施した内容は以下の2つになります。

    • Application GatewayサブネットのNetwork Security GroupでFront Doorからのアクセスのみに制限する
    • Front DoorのWeb Application Firewallポリシーのカスタム規則でIP制限を行う

Front Doorのアクセス制限はNetwork Security Groupの設定で出来ない為、Web Application Firewallポリシーのカスタム規則で実施しています。

1.Application GatewayサブネットのNetwork Security GroupでFront Doorからのアクセスのみに制限する

まず、Application Gatewayのサブネットに適用しているNetwork Security Groupの受信規則に、Service TagがAzureFrontDoor.Backendの許可設定を追加します。

実際の設定画面は下記のようになります。

その次に、上記許可ポリシーより優先順位が下に、Service TagがInternetからポート80,443のアクセス拒否するポリシーを入れます。

これにより、直接Internetから来るアクセスが拒否され、Front Door経由のアクセスのみが許可されます。

直接、Application Gatewayのドメインへのアクセスを実施すると、このサイトにアクセスできませんというメッセージが表示されます。また、Front Door経由のアクセスをすれば正常にサイトアクセスできます。

2.Web Application Firewallポリシーのカスタム規則でIP制限を行う

Front Door経由のアクセスはすべてAzureFrontDoor.BackendでプールされるIPになります。したがって、Application Gateway側ではアクセス元IPがわからない為、Network Security Groupでの設定が出来ません。

Front Door側で同様の制限を行う必要がありますが、Front Doorのアクセス制限はNetwork Security Groupの設定での制限ができません。

結果、Front Doorに設定されているWeb Application Firewallポリシーのカスタム規則でIP制限を行う事になりました。

特定のIPからのアクセスのみを許可する場合は、以下の設定になります。

    • Web Application Firewallのポリシーを防止にする
    • 特定のIPを含まない場合はトラフィックを拒否する設定をする

※防止にすると必要なアクセスがブロックされる場合もありますので注意して下さい。

Web アプリケーション ファイアウォールのポリシーのメニューで設定の中にあるポリシー設定を選択すると下記画面が表示されます。

設定で防止を選択し保存します。

次に、設定にあるカスタム規則を選択します。カスタムルースの追加を選択するとカスタムルールの追加が表示されます。

 

カスタムルール名、優先度を適時設定した後に、条件を下記設定とします。

    • 一致の種類:IPアドレス
    • 一致変数 RemoteAddr
    • 操作:次の値を含まない
    • IPアドレスまたは範囲:許可するIP
    • 結果 トラフィックを拒否する

これで許可するIPアドレス以外のアクセスをすべて拒否する設定が出来ました。

最後にカスタム規則の保存を行えば、作業が完了です。

 

Azure Web Appsの拡張機能を使わずにLet’s Encryptで証明書を発行してOpenSSLでPFX形式へ変換してみた

 

Let’s EncryptのSSL証明書作成をWeb Appsで試してみようとして調べてみた所、Web Appsの拡張機能を使う方法が多く紹介されていました。

しかし、Web AppsをLinux+PHPの構成で試していたのですが、Web Appsの拡張機能が有効になってませんでした。

どうしようか?と途方に暮れていたのですが、よく考えたらWeb AppsってUbuntuだから普通にできるのでは?と気づき試してみました。

結果、普通にUbuntuで実施する手順で証明書の作成できました。作業内容をメモとして記しておきます。

1 .Lets Encryptの証明書発行を行う

最初にAzure Portal上で自分のWeb AppsへSSHで接続します。

サーバ上でLets Encrypt証明書発行の為に、実施する手順は以下の通りです。

    • aptアップデート
    • certbotのインストール
    • certbotコマンドで証明書の発行

なお、最初にapt updateしてからでないとcertbotインストール時にエラーになりました。

#updateを実施する

[root@ホスト名 tmp]# apt -y update

#certbotをインストールします

[root@ホスト名 tmp]# apt -y install certbot

#証明書を発行する(ドメインは自分のサイトに合わせて設定します。)

[root@ホスト名 tmp]# certbot certonly –webroot -w /home/site/wwwroot -d ドメイン名

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Enter email address (used for urgent renewal and security notices) (Enter ‘c’ to
cancel):メールアドレスを入力

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server at
https://acme-v02.api.letsencrypt.org/directory
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
(A)gree/(C)ancel: A    (承諾の確認です。Yを選択します)

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let’s Encrypt project and the non-profit
organization that develops Certbot? We’d like to send you email about our work
encrypting the web, EFF news, campaigns, and ways to support digital freedom.
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
(Y)es/(N)o: N    (案内メール送信の確認です。必要ならYを選択します)

作成されたメッセージが表示されます

 

 

Let’s Encryptで発行された証明書は/etc/letsencrypt/live/ドメイン名/ 配下に生成されます。

.OpenSSLを使ってpem形式からpfx形式へ変換する

Azure 上では独自ドメインの証明書をpfx形式で扱います。そこでopensslコマンドで変換を行います。

opensslはデフォルトで入っていた為、インストールの必要はありませんでした。

#証明書が作成されているディレクトリに移動します

[root@ホスト名 tmp]# cd /etc/letsencrypt/live/ドメイン名/

#opensslコマンドでpem形式からpfx形式に変換する

[root@ホスト名 tmp]# openssl pkcs12 -export -inkey privkey.pem -in cert.pem -out 証明書名.pfx

Enter Export Password:パスワード
Verifying – Enter Export Password:パスワード

pfx形式の証明書が作成されたメッセージが表示されます

最後にできた証明書ファイルを/home配下にファイル移動し、FTPS等でサーバからダウンロードすれば作業完了です。

念のため/etc/letsencrypt/live配下やサーバ上の証明書は削除しておきましょう。

Web Appsの再起動等を実施するとcertbotのパッケージがなくなりますので、インストールから再度実施する必要があります。

 

ARMテンプレートを使って仮想ネットワークとサブネットをデプロイする(基本部分)

 

Azure仮想ネットワークとサブネットのデプロイをAzure Resource Manager(ARM)テンプレートを使って実施してみました。

仮想ネットワークのデプロイは下記の3つのファイルを使って実施してみました。

    • 仮想ネットワークを定義するARMテンプレート(JSONファイル)
    • 仮想ネットワークのパラメータを指定するCSV
    • テンプレートをデプロイするPower Shell

デプロイはPower Shellを使用し、foreachを利用する事で複数の仮想ネットワークを作れるようにしています。

仮想ネットワークを作成するARMテンプレートはマイクロソフト様サイトと、実際に作成されているARMテンプレートを参考に作成してみました。

https://docs.microsoft.com/ja-jp/azure/virtual-network/template-samples

 

今回作成したものは GitHub上に公開しています。

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

 

1 .仮想ネットワークをAzure Portalで作成してみた

ARMテンプレートを作成する前に、まず最初にAzure Portal上で作成してみました。

メニューで仮想ネットワークを選択します。下記画面が表示されますので、追加をクリックします。

 

仮想ネットワークの作成が表示されますので、名前やデプロイするリージョン等を選択します。

 

次に、アドレス空間(利用するIPの範囲)の設定になります。併せてサブネット名やサブネットのアドレス空間も指定します。

 

次に、DDos保護や、ファイアウォールの設定になりますが、通常はそのままでよいです。

 

次にタグの設定になります。適時設定を行います。

 

最後に確認画面が表示されますので、作成ボタンをクリックします。仮想ネットワークが作成されます。

今回は、これをARMテンプレート、設定ファイルを指定するCSV、テンプレートのデプロイを行うPower Shellを使う事により、Azure Portalを使わずにデプロイしてみました。

 

2 .仮想ネットワークのAzure Resource Manager(ARM)テンプレート

今回は、以下のように基本的な設定で作成しています。

    • 仮想ネットーワークと紐づくサブネットは1つとする
    • サービスエンドポイントの指定は行わない
    • TAGを1つ指定する

なおIPv6使用可否、DDoS 保護、ファイアウォール使用可否の指定が可能ですが、今回はデフォルトと同じく利用しないようにしています。

作成したARMテンプレートのサンプルは以下のようになります。

{

    “$schema”: “http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#”,
    “contentVersion”: “1.0.0.0”,
    “parameters”: {
        “vnetName”: {
        “type”: “string”,
        “defaultValue”: “VNet1”,
        “metadata”: {}
        },
        “location”: {
            “type”: “string”,
            “metadata”:{} 
        },
        “addressSpaces”: {
            “type”: “string”,
            “metadata”:{} 
        },
        “subnet_name”: {
            “type”: “string”,
            “metadata”:{} 
        },
        “subnet_addressRange”: {
            “type”: “string”,
            “metadata”:{} 
        },
        “tag_name”: {
            “type”: “string”,
            “defaultValue”: “notag”,
            “metadata”:{} 
        },
        “tag_value”: {
            “type”: “string”,
            “defaultValue”: “notag”,
            “metadata”:{} 
        }
    },
    “variables”: {},
    “resources”: [
        {
            “type”: “Microsoft.Network/VirtualNetworks”,
            “apiVersion”: “2019-09-01”,
            “name”: “[parameters(‘vnetName’)]”,
            “location”: “[parameters(‘location’)]”,
            “tags”:  {
                “[parameters(‘tag_name’)]”:”[parameters(‘tag_value’)]”
            },
            “properties”: {
                “addressSpace”: {
                    “addressPrefixes”: [
                       “[parameters(‘addressSpaces’)]”
               ]
            }
        },
      “resources”: [
        {
            “type”: “subnets”,
            “apiVersion”: “2018-10-01”,
            “location”: “[parameters(‘location’)]”,
            “name”: “[parameters(‘subnet_name’)]”,
            “dependsOn”: [
                “[parameters(‘vnetName’)]”
            ],
            “properties”: {
                “addressPrefix”: “[parameters(‘subnet_addressRange’)]”
           }
        }
      ]
    }
  ]
}

今後、1つではなく複数のサブネットやサブネット単体での作成してを想定して、サブネットは別のリソースで作成するようにしています。

 

2.仮想ネットワークの設定内容を指定するCSV

仮想ネットワーク を作成する為にCSVから読み込むパラメータは以下の通りになります。リソースグループ名はデプロイ先のリソースグループ名になります。

    • リソースグループ名(ResourceGroupName)
    • リージョン名(location)
    • 仮想ネットワーク名(vnetName)
    • 仮想ネットワークのアドレス空間(IPv4)(addressSpaces)
    • サブネット名(subnet_name)
    • サブネットのアドレス範囲(subnet_addressRange)
    • Tag(tag_name,tag_value)

作成したパラメータCSVファイルのサンプルは以下のようになります。

ResourceGroupName,location,vnetName,addressSpaces,subnet_name,subnet_addressRange,tag_name,tag_value
test-rg,japaneast,test-vnet,192.168.0.0/16,test-subnet,192.168.1.0/24,tag-name,tag-value

仮想ネットワークとサブネットの設定内容に合わせてCSVを作成します。

 

3. 仮想ネットワークをARMテンプレート+Power Shellでデプロイする

ARMテンプレートのパス、CSVのパスを指定してデプロイを実施します。

#VNET+Subnet Template Deploy

#基本設定

$TemplateFilePath = “テンプレートのファイルパス”
$ImportCSVPath = “CSVファイルのファイルパス”

# Inclued Configure Entries
$csv = Import-Csv -path $ImportCSVPath

# Template Deploy
 foreach( $c in $csv ){

New-AzResourceGroupDeployment `
 -ResourceGroupName $c.ResourceGroupName `
 -TemplateFile $TemplateFilePath `
 -location $c.location `
 -vnetName $c.vnetname `
 -addressSpaces $c.addressSpaces `
 -subnet_name $c.subnet_name `
 -subnet_addressRange $c.subnet_addressRange `
 -tag_name $c.tag_name `
 -tag_value $c.tag_value
}

 

デプロイが成功すると、以下の通りにProvisioningState : Succeededと表示されます。(ログは途中省略しています。)

DeploymentName : VNET-SUbnet作成(基本編1)_template
ResourceGroupName : test-rg
ProvisioningState : Succeeded
Timestamp : YYYY/MM/DD hh:mm:ss
Mode : Incremental
TemplateLink :
Parameters :
Name Type Value
===================== ========================= ==========
vnetName String test-vnet
location String japaneast
addressSpaces String 192.168.0.0/16
subnet_name String test-subnet
subnet_addressRange String 192.168.1.0/24
tag_name String tag-name
tag_value String tag-value

 

CSVで指定した値で作成した値で作成されている事が確認できます。

 

Azure Monitorを使ってAzure Application Gateway正常性プローブのステータス変化を検知する

 

Azure Application Gatewayのバックエンド正常性の状態変化を検知する検証を行ってみました。

今回は、Azure  Monitorの機能を利用して検知するようにしてみました。Azure Monitorを使ってますのでメール送信等を行う事も標準機能で可能です。

1.Application Gatewayのメトリックで正常性プローブの状況がわかる

Application Gatewayのメトリックでは、正常なホストの数、異常なホストの数を検知する事ができます。これはV1、V2どちらでも可能です。
このホストの数は、正常性プローブによって正常もしくは異常と判断されたバックエンドの数になります。マイクロソフト様のサイトに記載があります。

https://docs.microsoft.com/ja-jp/azure/application-gateway/application-gateway-metrics#backend-metrics

マイクロソフト様のサイトを読むと、以下のような事が言えます。

    • 正常なホストの数が0の場合は、すべてのバックエンドプールに問題が発生しており、サイトが表示されない状態
    • 異常なホストの数が1以上の場合は、1つ以上のバックエンドプールで異常が発生している状態(特定のバックエンドにあるホストが停止している状態

したがって、この状態を監視することにより、Application Gateway経由のバックエンド正常性がわかるのではないかと考えてみました。

2.すべての正常性プローブがNGになった場合に検知する

Azure MonitorでApplication Gatewayのメトリックを監視することができます。

まず、モニター>アラート>新しいアラートルールを選択します。

そうすると、下記画面が表示されますので、リソースの選択でアプリケーションゲートウェイを選択します。

    選択が終わったら、完了を押します。

ルールの作成画面に戻りますので、次に条件の項目で追加を選択してください。

そうすると、下記のようにシグナルロジックの構成が表示されます。

ここに項目が表示されるのですが、今回対象とする項目は下記2つになります。

    • Unhealthy Host Count が異常なホストの数になります
    • Healthy Host Count が正常なホストの数になります

すべて正常性プローブがNGになった場合の検出は正常なホストの数で設定をします。

Healthy Host Countを選択をすると下記のような画面が表示されます。バックエンドのサーバが1つ(ルールもHTTP用1つ)で検証していますので、以下のように1となります。

これが、0になると、正常なバックエンドがなくなる為、すべてのアクセスが停止する状態になります。ですので以下のような設定とします。

    • しきい値:Static
    • 演算子:より小さい
    • 集計の種類:平均
    • しきい値(演算子の方):1

1より小さいとなりますので、バックエンド正常性がNGだった場合(一時的な状態を含む)が検出される事になります。

評価基準は適時選択してください。最後に完了ボタンを選択します。

ルールの作成画面に戻りますので、アクショングループの選択、アラートの詳細を適時記入し、アラートルールの作成をクリックします。

これで、Azure MonitorでApplication Gatewayのバックエンド正常性がすべてNGになった場合に、アラートを発生させることができます。

3.1つでも正常性プローブに異常があった場合に検知する

1つ以上の正常性プローブがNGになった場合の検出は異常なホスト数で行います。

シグナルロジックの構成で、Unhealthy Host Countを選択します。

そうすると、下記画面が表示されます。

すべてのバックエンド正常性がOKなので、0になります。

これが0より大きい場合は、バックエンド正常性に問題が発生している事を示します。ですので、下記のように設定にします。

    • しきい値:Static
    • 演算子:より大きい
    • 集計の種類:平均
    • しきい値(演算子):0

評価基準は適時選択し完了ボタンを選択します。

ルールの作成画面に戻りますので、同様に、アクショングループの選択、アラートの詳細を適時記入し、アラートルールの作成をクリックします。

これで、Azure MonitorでApplication Gatewayのバックエンド正常性で1つでもNGになっている場合に、アラートを発生させることができます。

 

Azure Front Doorのキャッシュ期間が指定出来るようになったようです

 

Azure Froot Doorのキャッシュ期間が指定できるようになったようです。

下記マイクロソフト様サイトに記載がある通り、今まではランダムとなり指定できませんでした。

https://docs.microsoft.com/ja-jp/azure/frontdoor/front-door-caching

しかし、本日(2020年5月2日)にAzure Portal上で確認した所、キャッシュ期間という項目が追加になっていました。

いつの間にという感じなのですが、キャッシュ期間は最大365日を超える事が出来ませんとの記載がありましたので、最大1年という事のようです。(実際に入力時点の最大値は365日まででした。)

実際に設定してみた所、x-cache: TCP-HITとなったのでキャッシュ自体は有効になっているのが確認できたのですが、設定時間を経過しても同じ結果だったので、期間が有効な状況なのかはもう少し確認が必要でした。

※Front Doorデザイナー>ルーティング規則でキャッシュを有効化にするとこのメニューが表示されます。

WWWなしからWWW付きURLへのリダイレクトをAzure Front Door+Azure DNSでやってみた

 

WWW無しURL(xxxx.com)からWWW付URL(www.xxxx.com)へのリダイレクトをAzure Front DoorとAzure DNSの組み合わせで試してみました。xxxxの部分は自分の環境に合わせて読み替えてください。

Azure DNSでAzure Front Dooorのエイリアス登録、Azure Froot Doorでリダイレクトさせる事によりWWW無しURLからWWW付URLへリダイレクトさせています。

今回の検証で実施した作業は、以下の3つになります。

    • Azure DNSで、@(xxxx.com)のAレコードを作成する。
    • Azure Froot Doorでxxxx.comのフロントエンドを作成する。
    • Azure Froot Doorルーティング規則でリダイレクトの設定を作成

※www.xxxx.comの設定がすべて完了している前提とします。

1.Azure DNSで@(xxxx.com)のAレコードを作成する。

Azure DNSでxxxx.comのレコードを作成します。xxxx.comのゾーンで作業を実施します。

Azure DNS>概要>レコードセットの追加を選択します。そうすると以下の画面が表示されます。

    • 名前:空白
    • 種類:A
    • エイリアスのレコードセット:はい
    • エイリアスの種類:Azureリソース
    • Azure リソース:該当のFroot Doorを指定

を選択し保存します。そうすると、レコードセットが作成されます。

これで、xxxx.comへアクセスが来た場合、Froot Doorへアクセスするようになります。

2.Azure Front Doorのフロントエンドを作成する

xxxx.comを受けるフロントエンドを作成します。

フロントドア>Froot Doorデザイナー>フロントエンドまたはドメインで+(追加)を選択します。そうすると以下の画面が表示されます。

こちらで、カスタムホスト名に、xxxx.comを入力し追加すると、xxxx.comのフロントエンドができます。

なお、この時点でDNSのレコード存在チェックが実施されます。

3.Azure Front Doorのルーティング規則を作成する

xxxx.comをwww.xxxx.comにリダイレクトさせるルーティング規則を作成します。

フロントドア>Froot Doorデザイナー>ルーティング規則で+(追加)を選択します。そうすると以下の画面が表示されます。

 

こちらで、名前は適時設定し、フロントエンドまたはドメインで、先ほど作成したxxxx.comのフロントエンドを選択します。

またHTTP、HTTPSを両方リダイレクトする場合は、受け入れ済みプロトコルでHTTPとHTTPS選択します。

また、リダイレクト設定として以下の内容を選択/入力します。プロトコルは一致要求を選択すると、HTTPはHTTPで、HTTPSはHTTPSでリダイレクトしてくれます。

    • ルートの種類:リダイレクト
    • リダイレクトの種類:Moved(301)
    • プロトコルをリダイレクトします:一致要求
    • 送信先ホスト:置換(www.xxxx.comを入力)

入力したら、追加をクリックします。

最後にフロントドアデザイナーの保存を行い設定が完了です。保存完了後に、xxxx.comへアクセスしたら、www.xxxx.comにリダイレクトされるようになります。

※フロントドアデザイナーの保存をし忘れがちなので、注意しましょう。