はじめに
Azure Web Apps(Linux / PHP)で動かしているサイトを別サイトへ移行することになり、旧サイトにアクセスしたら新サイトへ転送する設定を検証しました。
PHP on Linux のWeb Appsはnginxで動いているため、nginxの設定でリダイレクトを書く方法を採用しました。ポータル操作とaz cliの両方の手順をまとめます。切り戻しも簡単でした。
結論
- nginxの設定ファイルを
/home/site/wwwroot/に置き、スタートアップコマンドで起動時にnginxの設定場所へコピーする - 切り戻しはスタートアップコマンドを空にして保存するだけ(再起動でnginx設定は標準に戻る)
前提
- Azure Web Apps(Linux、ランタイム PHP 8.3)
- 旧サイト:
app-old、新サイト:app-new(名前は例です) - リダイレクト先は
https://app-new.azurewebsites.net
仕組み
nginxが実際に読む設定は /etc/nginx/sites-available/default で、これはコンテナイメージ内にあります。再起動のたびに標準の状態に戻るため、直接編集しても永続化されません。
そこで次の2段構えにします。
| やること | 役割 |
|---|---|
設定ファイルを /home/site/wwwroot/ に置く |
永続領域に原本を保管 |
| スタートアップコマンドを設定する | 起動のたびに原本をnginxの場所へコピーして反映 |
リダイレクト用の設定ファイルの中身は、どちらの手順でも同じです。
server {
listen 8080;
listen [::]:8080;
server_name _;
return 301 https://app-new.azurewebsites.net$request_uri;
}
-
listen 8080;は変えないでください。PHP on Linuxの標準イメージは8080で待ち受けるため、変更すると起動に失敗します -
$request_uriを付けることで、/about?id=1のようなパスとクエリが新サイトに引き継がれます。トップへ固定で飛ばす場合はreturn 301 https://app-new.azurewebsites.net/;にします
手順A: ポータルで実施する
A-1. 標準のnginx設定を控える(任意)
旧サイトのKudu(後述)で「SSH — Application」を開き、標準設定を別名で控えておきます。
cp /etc/nginx/sites-available/default /home/site/wwwroot/default.orig
cat /home/site/wwwroot/default.orig
リダイレクト用ファイルは default という名前で置くので、別名(default.orig)で保存して衝突を避けます。
A-2. リダイレクト用の設定ファイルを置く
旧サイトのKuduを開きます。
- Azureポータルで旧サイトを開く
- 左メニュー「開発ツール」→「高度なツール」→「移動」
最近のKudu画面には、以前の「Debug console」というメニューがありません。代わりに左メニューの SSH と File Manager を使います。
方法1: SSH — Application でコマンド実行(確実)
左メニュー「SSH」→「Application」を開き、次を実行します。
cd /home/site/wwwroot
cat > default <<'EOF'
server {
listen 8080;
listen [::]:8080;
server_name _;
return 301 https://app-new.azurewebsites.net$request_uri;
}
EOF
cat default
**「SSH — Kudu」ではなく「SSH — Application」**を選びます(Kudu側は別コンテナです)。
方法2: File Manager でファイル作成
site → wwwroot に default(拡張子なし)を作成し、上のnginx設定を貼り付けて保存します。保存後は cat default などで中身を確認すると安心です。
A-3. スタートアップコマンドを設定する
- 旧サイト → 「設定」→「構成」→「全般設定」タブ
- 「スタートアップ コマンド」に次を入力
cp /home/site/wwwroot/default /etc/nginx/sites-available/default && service nginx reload
- 「保存」(再起動の確認が出るので承認)
ポータルで保存するだけで再起動されます。 再起動だけでは設定は反映されず、このスタートアップコマンドが必須です(wwwroot の default は、コピーされない限りnginxに読まれないため)。
手順B: az cli で実施する
Cloud Shell(Bash)で実行する想定です。
B-0. 対象を確認する
誤って別のサブスクリプションやリソースグループを操作しないよう、変数は先頭でまとめて設定し、echo で確認します。
az account show --query name -o tsv # 操作対象のサブスクリプションを確認
RG=<リソースグループ名>
OLD=<旧サイトのアプリ名>
NEW=<新サイトのアプリ名>
echo "RG=$RG OLD=$OLD NEW=$NEW"
B-1. 標準のnginx設定を控える(任意)
az webapp ssh でアプリのコンテナに入ります。
az webapp ssh -g $RG -n $OLD
コンテナ内で次を実行します。
cp /etc/nginx/sites-available/default /home/site/wwwroot/default.orig
cat /home/site/wwwroot/default.orig
exit
B-2. リダイレクト用の設定ファイルを作ってデプロイする
mkdir -p ~/redirect && cd ~/redirect
cat > default <<'EOF'
server {
listen 8080;
listen [::]:8080;
server_name _;
return 301 https://NEWHOST$request_uri;
}
EOF
sed -i "s|NEWHOST|$NEW.azurewebsites.net|" default
cat default # NEWHOST が実ホスト名に置換されているか確認
zip -r ../redirect.zip .
cd ..
az webapp deploy -g $RG -n $OLD --src-path redirect.zip --type zip --clean false
重要:
az webapp deploy --type zipは、既定ではデプロイ先を事前にクリーンにします。設定ファイルだけを入れたzipをそのまま流すと、旧サイトのPHPファイルが消えるおそれがあります。既存サイトを残す場合は--clean falseを付けるか、サイト本体を含めたzipをデプロイしてください。また、
zip -r ../redirect.zip .は、カレントディレクトリの中身をzipの直下に入れる書き方です。これによりdefaultがwwwroot直下に展開されます。
B-3. スタートアップコマンドを設定して再起動する
az webapp config set -g $RG -n $OLD \
--startup-file "cp /home/site/wwwroot/default /etc/nginx/sites-available/default && service nginx reload"
az webapp restart -g $RG -n $OLD
設定値の確認は次のとおりです。
az webapp config show -g $RG -n $OLD --query appCommandLine -o tsv
動作確認
再起動後、1〜2分待ってから確認します。
# 301 と Location ヘッダーを確認
curl -sI https://$OLD.azurewebsites.net/
# パスとクエリが維持されるか
curl -sI "https://$OLD.azurewebsites.net/about?id=1"
# → Location: https://<新サイトのホスト名>/about?id=1
# リダイレクトを追って新サイトに到達するか
curl -sL https://$OLD.azurewebsites.net/
HTTP/1.1 301 と Location ヘッダーが返り、最終的に新サイトの内容が表示されれば成功です。
切り戻し
スタートアップコマンドを空にして保存します。
- ポータル: 「構成」→「全般設定」→「スタートアップ コマンド」を空にして保存
- az cli:
az webapp config set -g $RG -n $OLD --startup-file ""
az webapp restart -g $RG -n $OLD
保存(または再起動)でコンテナが作り直され、cp で上書きしたnginx設定は標準に戻ります。wwwroot の default は残しても使われません。実際に、元のサイトの表示に戻ることを確認できました。
注意点
- ループ防止: 新サイトが旧サイトと同じアプリで動いていると、リダイレクトが無限ループします
- 301と302: 移転確定なら301、移行期間中の暫定なら302にすると切り戻しやすくなります(301はブラウザや検索エンジンにキャッシュされやすいです)
- zipデプロイとの関係: ポータルのKuduで直接作ったファイルは、次回のzipデプロイ(クリーン有効時)で消える可能性があります。本番運用では、設定ファイルをデプロイ物に含めてリポジトリで管理するほうが追跡しやすいです
-
未検証の項目: 今回の検証は
azurewebsites.netドメインで行いました。次の点は確認していません- 旧ドメイン(カスタムドメイン)でアクセスされる場合。旧サイト側にドメインと証明書を残さないと、リダイレクト以前に証明書エラーになると考えられます
- Web Appsのヘルスチェックを有効にしている場合。
/が301を返すと異常判定される可能性があります
検証環境で詰まった点(おまけ)
- 検証用に新規作成した環境で、App Serviceプラン(B1)が「クォータ不足」で作成できないことがありました。リージョンを変える(今回は japanwest で成功)か、SKUを変えて回避できます
- 既存の環境変数が残った状態でスクリプトを流すと、意図しないリソースグループを指すことがあります。変数は先頭でまとめて設定し、
echoで中身を確認してから実行するのが安全です