현재 프로덕션 환경에서만 나타나는 웹 사이트 버그를 해결하려고 노력 중입니다. 그 환경을 무너뜨릴 수는 없기 때문에 최대한 가까운 카피를 만들려고 노력하고 있어요. 이 사이트는 RDS SQL Server Web Edition 인스턴스의 지원을 받는 Amazon EC2 t2 인스턴스의 Windows Server 2019 Datacenter에서 실행되는 Kentico 11 기반입니다. 테스트 환경을 생성하기 위해 데이터베이스의 백업 덤프를 만들고 인스턴스의 다른 데이터베이스로 복원한 다음 EC2의 AMI를 생성하고 이를 사용하여 새 EC2 인스턴스를 시작합니다.
이 프로세스는 과거에 수십 번 작동했지만 이번에는 오늘까지 4번 수행했습니다. 새 인스턴스의 웹 사이트는 일반 404 상태(즉, 최소 404 페이지) 외에는 아무것도 반환하지 않습니다. Kentico가 아닌 IIS 자체에서 반환됨) 이상하게도 이러한 복사본 요청은 IIS 요청 로그에 기록되지 않습니다. IP 주소 및 데이터베이스 연결 문자열과 같은 세부 정보를 제외하고 프로덕션 인스턴스와 복사본 사이에 다른 점을 볼 수 없으며 차이가 있는 이유를 상상할 수 없습니다. 새 인스턴스를 시작하기 불과 몇 분 전에 AMI를 생성했습니다. 하루 종일 다시 시도하고 손가락이 마비될 때까지 인터넷 검색을 했습니다... 복사가 예상대로 작동하지 않는 이유나 복사 방법에 대한 아이디어나 제안이 있는 사람이 있습니까?
편집: IIS가 아닌 경우 HTTP 요청에 응답하는 것이 무엇인지 궁금해서 다음을 포함하는 응답 헤더를 살펴보았습니다 Server: Microsoft-HTTPAPI/2.0. 나는 이것을 찾았다:https://docs.microsoft.com/en-us/windows/win32/http/http-api-start-page정말 미스터리가 깊어질 뿐입니다. IIS 앞에 무엇이 있고 어떻게 됩니까? 그리고 이 인스턴스는 작업 사이트 기반의 AMI에서 시작되는데, 이러한 변화는 어떻게 이루어졌나요?
편집: 더 명확하게 하기 위해 제목을 업데이트했습니다.
답변1
여기저기 파헤친 후에netstat그리고작업 목록그리고체계프로세스는 포트 80과 443의 요청에 응답하는 것이었습니다. 더 일찍 생각했어야 했던 생각이 있었고, 프로세스를 만들 때 무슨 일이 일어나는지 살펴보았습니다.로컬호스트복사 중인 프로덕션 서버에 대한 요청입니다. 놀랍게도 그것은 똑같았습니다. 404가 자신을 식별하는 무언가에 의해 반환되었습니다 Microsoft-HTTPAPI/2.0.마지막으로IIS 포트 바인딩의 호스트 이름과 관련이 있을 수 있다는 생각이 머릿속에 들어왔습니다.
물론 복사되는 서버의 이름이 아닌 복사 호스트의 DNS 이름과 일치하도록 해당 바인딩을 편집했을 때 요청은 IIS에서 처리되고 웹 서비스까지 모든 것이 정상으로 돌아왔습니다.
관리 경험이 거의 없는 개발자가 관리 측 미스터리를 해결하려고 노력해야 한다는 또 다른 경고 이야기입니다.