はじめに
Application Gatewayを実際に構築する上でハマったことを紹介していきます。
実際に構築して初めて気づいたことです。仕様上回避できず不便でした。
リスナーの変更
リスナーの作成時に問題になることとして、HTTPとHTTPSの切り替えができない点です。
これによって当然ダウンタイムも発生すしますし、切り替え時にリスナー名が変更されるというちょっとした問題発生します。
名前については切り替え後に一旦削除して再度同じ名前でリスナーを作成することで一応解消できます。
リスナーの削除
リスナーが1つの場合には削除できないことにも注意です。削除して再作成は出来ません。
エラーページの表示
リスナーでエラーページを表示させることが可能です。
URLを指定することでApplication Gatewayにダウンロードしてきて表示させます。参照しているわけではないということに注意です。
その為、いくつか気を付ける点があります。
- エラーページ（HTML）を変更して直後に反映されるものではない
- 変更をポーリングしているわけではないので勝手に変更が反映されることはない
- 同じURLでは変更されないく変更する場合にはファイル名たディレクトリ名を変更してURLを書き換える必要がある
ここら辺は意外とハマりました。対策としてはパイプラインなどを利用して保存するディレクトリを日時なとにしておくと良いと思います。
ルールの設定
ルールを設定する場合には、作成時の注意があります。
パスベースで設定する場合としない場合の注意点です。
パスベースで設定しない場合には、作成後にはパスベースで設定できません。
パスベース設定あり
パスベース設定なし
パスベース設定が追加された場合には、新しいルールを作成し適用する必要があります。
関連付けられているルール
関連付けられているルールの数の整合性が取れていないことがあります。
開いてみると2つしか関連付けられているルールがありません。
結局、原因はわかりませんでした。
設定変更はすべて瞬断
Application Gatewayは、すべての設定変更において瞬断が起こるそうです。気にならない程度でセッションが切れるなどだと思います。
証明書の更新などでも発生します。そのため、とてもシビアな環境では計画メンテナンスで停止してから作業を行う必要があると思います。
まとめ
Application Gatewayを少しだけ触っても、技術的なこととは異なるところでハマるポイントがあったりします。
これはApplication Gatewayに限ったことではないですが、作法がいろいろな所に存在するので作業はドキュメントは正ですが、実際に触ってみて検証し試してみることも大事だと思います。