現時点では本番環境でのみ発生する Web サイトのバグに対処しようとしています。その環境を停止することはできないため、できるだけ近いコピーを作成しようとしています。サイトは Kentico 11 ベースで、Amazon EC2 t2 インスタンス上の Windows Server 2019 Datacenter で実行され、RDS SQL Server Web Edition インスタンスによってバックアップされています。テスト環境を作成するには、データベースのバックアップ ダンプを作成し、インスタンス上の別のデータベースに復元し、EC2 の AMI を作成して、それを使用して新しい EC2 インスタンスを起動します。
このプロセスは過去に何十回も機能しましたが、今回は、そして今日までに 4 回実行しましたが、新しいインスタンスの Web サイトは、一般的な 404 ステータス (つまり、Kentico からではなく、IIS 自体によって返される最小限の 404 ページ) 以外は何も返しません。奇妙なことに、コピーへのこれらの要求は、IIS 要求ログに記録されていません。IP アドレスやデータベース接続文字列などの詳細を除いて、実稼働インスタンスとコピーの間に違いは見当たりません。違いが生じる理由も想像できません。AMI を作成したのは、新しいインスタンスを起動するほんの数分前です。丸一日かけて再試行し、指がかじかんでしまうまで Google 検索をしました... コピーが期待どおりに機能しない理由や、それを実現するための方法について、何かアイデアや提案はありますか?
編集: IIS が応答していなかった場合、HTTP 要求に何が応答していたのか疑問に思い、応答ヘッダーを確認しました。これには次の内容が含まれています: Server: Microsoft-HTTPAPI/2.0。次の内容を見つけました:https://docs.microsoft.com/en-us/windows/win32/http/http-api-スタートページこれでは謎が深まるばかりです。IIS の前に何が、そしてどうやって現れるのでしょうか? また、このインスタンスは稼働中のサイトに基づく AMI から起動されているので、この変更はどのようにして起こったのでしょうか?
編集: よりわかりやすくするためにタイトルを更新しました
答え1
いろいろ調べてみたところネットスタットそしてタスクリストそして、システムプロセスはポート80と443のリクエストに応答するものだったので、もっと早く考えるべきだったのですが、ローカルホストコピーされた本番サーバー上のリクエスト。驚いたことに、同じものでした。404が返されましたMicrosoft-HTTPAPI/2.0。ついにIIS ポート バインディングのホスト名に関連している可能性があると考えました。
案の定、コピー先のサーバー名ではなくコピーホストの DNS 名と一致するようにこれらのバインドを編集すると、要求は IIS によって処理され、Web サービスに関してはすべて正常に戻りました。
管理経験がほとんどない開発者が、管理側の謎を解こうとしなければならないという、もう一つの教訓的な話です。