У меня есть веб-приложение ASP.NET (.NET Framework 4.7.2.), развернутое в AWS/ECS, и мы заметили, что Application_Start запускался не один, не два, а три раза! Возможно другие сталкиваются с этой проблемой.
Мы решили 1 из 2 дополнительных перезапусков. Первое происходит из-за того, что точка входа в докер Microsoft СервисМонитор первый способ действий — остановить службу w3svc, изменить applicationHost.config (через appcmd.exe), чтобы внедрить переменные среды на уровне докера (те, которые предоставляются через директивы ENV в файле докера или через параметры командной строки запуска докера) в раздел переменной среды DefaultAppPool, а затем перезапускает службу.
Обычно это не было бы проблемой, но если ваши приложения настроены на автоматический запуск с preloadEnabled=true, то происходит то, что служба запускается один раз, автоматически, с контейнером, только для того, чтобы ServiceMonitor пришел и остановил ее, измените настройки и перезапустите его снова. Таким образом, первоначальный запуск, инициированный системой, обречен и не должен происходить в первую очередь. В нем нет всех ожидаемых переменных среды, и он действительно работает только потому, что приложение настроено на автоматический запуск. Мы обошли это, установив для режима запуска w3svc значение «Вручную». Это предотвращает первоначальный обреченный запуск Application_Start, так что, по крайней мере, в локальном док-контейнере мы получаем только один запуск приложения, инициированный после того, как ServiceMonitor применил правильные настройки.
В ECS все немного иначе. В дополнение к дополнительному запуску, запускаемому ServiceeMonitor, мы также получаем еще один (3-й) запуск, запускаемый некоторыми другими настройками, которые применяются во время выполнения, предположительно, средой ECS. Мой главный вопрос: кто-нибудь знает, каковы могут быть эти изменения настроек, инициированные ECS? Применяет ли ECS как-то переменные среды или вносит другие изменения в IIS по умолчанию? Это происходит только в ECS и не происходит, когда один и тот же образ Docker запускается локально на рабочем столе Docker.
Какими бы ни были эти изменения настроек, они особенно разрушительны, потому что они не запускают обычную повторную обработку перекрывающихся процессов, которая запускает новый, отдельный процесс, который разогревается перед заменой старого. Эти изменения параметров запускают перезапуск внутри процесса, который вы бы получили, например, если бы вы изменили файл web.config. Я думаю, что это заменяет AppDomain в уже запущенном процессе. Это плохо для нас, потому что мы используем низкоуровневые библиотеки трассировки SignalFx, которые подключаются к CLR, и это вызывает нарушение общего доступа, которое приводит к сбою процесса, когда новый AppDomain пытается загрузить независимые от домена сборки с другими разрешениями. Все эти дополнительные циклы запуска приложений не только создают дополнительную нагрузку на систему, поскольку она выполняет все три задачи (включая гидратацию кэша из баз данных, настройку подписок на разделы Azure и т. привести к исключениям OutOfMemory, особенно в докере, где контейнеры имеют жесткий лимит памяти.
