はじめに
Part1では、以下の内容を記載しました。
- Application Gatewayとは
- v2への移行方法
- 移行用スクリプトの注意/制限
途中、発表されたAzure Bastionに興味を惹かれ間があいてしまいましたが、Part2では、スクリプトに必要なパラメータを確認して、
実際にスクリプトを動かしてみます。
最後に、実際に移行する際はどのような流れになるか考えてみます。
目次
スクリプト実行準備
まずは、スクリプトを以下からダウンロードします。
スクリプトの使い方は以下にあるため、それに従います。
スクリプトの実行の仕方として、Azモジュールをインストールしているかいないかで以下の2つの方法があるようです。
- Azモジュール無し⇒Install-Scriptオプションを使う。
- Azモジュールあり⇒スクリプトを直接実行する。
本記事は2の直接実行する方法で進めます。また、ダウンロードしたバージョンは1.0.3でした。
スクリプトを直接実行する場合には、以下3つのコマンドを実行すればOKです。サブスクリプションを2つ以上持つアカウントの場合には、Select-AzSubscriptionで切り替えるのを忘れずに。
Import-Module Az Connect-AzAccount AzureAppGwMigration.ps1 ` -resourceId <v1AppGWのリソースID> ` -subnetAddressRange <v2AppGW用サブネットレンジ>` -appgwName <v2AppGW名>` -sslCertificates <カンマ区切りのSSL証明書オブジェクト>` -trustedRootCertificates <カンマ区切りの信頼されたルート証明書オブジェクト>` -privateIpAddress <v2AppGWのプライベートIPアドレス>` -publicIpResourceName <v2AppGWのパブリックIPアドレスリソースID>` -validateMigration -enableAutoScale
次に、スクリプトの引数について準備が必要です。
- v1AppGWのリソースID(必須)
リソースIDは、Azure内の「どのサブスクリプションの、どのリソースグループの、どのリソース」を表す識別子です。 これはリソースのプロパティから取得できます。
- v2AppGW用サブネットレンジ(必須)
新しくv2AppGWを作成するサブネットのアドレス帯をCIDR形式で指定しましょう。 スクリプトが作ってくれるので、先にサブネットを作成しておく必要はありません。 今回は10.10.2.0/24にします。
- v2ApPGW名(オプション)
v2AppGWの名前です。指定しない場合、"元の名前_v2"になります。kkv2AppGWにします。
- カンマ区切りのSSL証明書オブジェクト(オプション)
HTTPSリスナーを持たない場合はこのオプションは不要です。
v1AppGWで使用している証明書のうち、v2AppGWにも使用したいすべての証明書について、スクリプト実行前に以下のコマンドを実行してオブジェクトを作成する必要があります。証明書は再登録ということですね。
$password = ConvertTo-SecureString <pfxファイルのパスワード> -AsPlainText -Force $mySslCert1 = New-AzApplicationGatewaySslCertificate -Name <証明書名> ` -CertificateFile <ローカルPC上の証明書ファイルのパス> ` -Password $password
証明書1つに付き1回なので、2つあれば$mySslCert2に変更してもう1度実行が必要です。 複数ある場合は、引数指定時に$mySslCert1,$mySslCert2とカンマ区切りにします。 テスト用のAppGWでは1つ登録しています。
- カンマ区切りの信頼されたルート証明書オブジェクト(オプション)
これは、HTTP設定でエンドツーエンドのSSLを実装していなければ不要です。
先ほどと同じように、証明書をアップロードするための作業です。 テスト用AppGWでは使用していません。 オブジェクト作成にあたり、コマンドが以下に変わります。
New-AzApplicationGatewayTrustedRootCertificate -Name <証明書名> ` -CertificateFile <ローカルPC上の証明書ファイルのパス>
- v2AppGWのプライベートIPアドレス(オプション)
新しいサブネット内から、割当てるIPアドレスを指定します。 指定しない場合は自動で割当てされます。 今回は10.10.2.10にします。
- v2AppGWのパブリックIPアドレスリソースID(オプション)
v2AppGWに既存のパブリックIPアドレスリソース(Standard)を割当てる場合は、 プロパティからリソースIDを取得して指定します。 新規で作成する場合は指定不要です。v2AppGW名-IPという名前で作成してくれます。 今回は新規で作成します。
- その他(オプション)
あとの2つはオプションです。validateMigrationを使うと設定値のチェックをしてくれ、 enableAutoScaleを使うと文字通りオートスケールを有効にしてくれます。 どちらも使用してみます。
ということで、一部マスクしていますが、私の環境で移行するために実行するコマンドはこれです。 これを実行します。
Import-Module Az Connect-AzAccount $password = ConvertTo-SecureString '1qaz"WSX3edc' -AsPlainText -Force $mySslCert1 = New-AzApplicationGatewaySslCertificate ` -Name "selfsign" ` -CertificateFile "C:\Users\kkusaya\Desktop\appgw\server.pfx" ` -Password $password .\C:\Users\kkusaya\Desktop\appgw\AzureAppGwMigration.ps1 ` -resourceId /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/kkAppGW/providers/Microsoft.Network/applicationGateways/kkAppGW ` -subnetAddressRange 10.10.2.0/24 ` -appgwName kkv2AppGW ` -sslCertificates $mySslCert1 ` -privateIpAddress 10.10.2.10 ` -validateMigration -enableAutoScale
v1AppGWの設定値確認
実行前にv1AppGWについて、全体的なパラメータを確認しておきます。 スクリプトによる移行の動きを見たかったので、設定自体は適当です。。。
〇概要
〇構成
〇WAF
〇バックエンドプール
〇HTTP設定
〇フロントエンドIP
〇リスナー
〇ルール
スクリプト実行
ではいよいよ、作成したコマンドを実行します。 ImportしてConnectして、証明書オブジェクトを作成して、いざ実行！
おー、いい感じに動いてそうだしいけるか？と思ったところで失敗しました。
エラー内容を見てみると、「新しく作成されるサブネット(kkvwAppGWSubnet)に適用されているNSG(kkAppGW)に、インターネットからのポート番号65200から65535の通信を許可してないから」失敗しています。
調べてみたところ、v2AppGWの仕様でした。 v1のときは65503から65534が必要でしたが、v2になり必要ポートが増えたようです。
このエラーからすると、v2AppGWのサブネットには、v1AppGWのサブネットに利用しているNSGをそのまま、スクリプトが割当ててくれるようです。また、エラーが生じた場合には作成したリソースのクリーンアップもしてくれているみたいで助かります。
v1AppGWで使用しているNSGに許可ルールを入れリトライします。
気を取り直して2回目、今度は成功しました！ 時間としては5分ほど。AppGWのデプロイとしては非常に速いです。さすがv2。
これ以降はGetした結果みたいのがずらっと続くので、省略します。
v2AppGWの設定値確認
移行されたAppGWの設定値を確認していきます。
〇概要
タグが付与されました。
〇構成
v2のオートスケールになっています。最小インスタンスは2台のようです。
〇WAF
〇バックエンドプール
バックエンドプールへのVM接続は、自分で行う必要がありますね。
〇HTTP設定
〇フロントエンドIP
〇リスナー
〇ルール
タグが付いたこと、バックエンドにVMが追加されないこと以外は、名前もそのままに移行ができました。 サブネットやパブリックIPアドレスの名前を決めたい場合は自分で作成しておけばそれを使えるので、移行用スクリプトとして便利だと思います。
想定される移行の流れ
実際に移行作業をする場合、どのような流れになるか考えます。
AppGWは以下の図のように、異なるAppGWで共通の仮想マシンをバックエンドプールに追加する構成が取れるため、 新旧AppGWの並行稼働が可能です。
それを利用し、2台のAppGWを稼働させたままDNSなど向き先を切り替え、トラフィックがv2AppGWへ切り替わるのを待つのがよいかと思います。
流れとしては以下のようになります。
- v1AppGW用サブネットにNSGを使用している場合、65200から65535までを許可しておく。(スクリプトでv2用サブネットを作成する場合)
- スクリプトでv2AppGWを構成する。
- v2AppGWのバックエンドプールに、v1AppGWのバックエンドプールと同じサーバを追加する。
- DNS名やTraffic Managerなどの向き先を、v1AppGWからv2AppGWに切り替える。
- しばらくしてからv1AppGW停止/削除
v1AppGWをいきなり削除するのが不安な場合には、一旦停止で様子を見るのがいいかもしれません。 AppGWはPowerShellであれば停止が可能です。 ただし、再起動後はAppGWのIPアドレスが変わるため、Aレコードを使用している場合は変更が必要です。
コマンドは以下
Stop-AzApplicationGateway -ApplicationGateway <PSApplicationGateway>
終わりに
2回にわたり、提供されている移行スクリプトの仕様確認および実行をしました。
手動移行しかない中、設定値の引継ぎを自動で実施してくれるのはとても便利です。 現状の仕様による制限(プライベートのみ不可など)はありますが、移行を考える際は有効活用しましょう。
何よりも設定変更をしたとき、v2だと5分とかからず終わるのがすごくよいです。 v1だと平気で20分くらい待たされますからね。。。
AppGWの仕様変更やスクリプト改修により変わる部分はあるかもしれませんが、大きくは変わらないと思うので、移行を考える際に本記事が参考になれば嬉しいです。
