#azure #azure-appservice
#azure-веб-приложение-служба #azure-веб-приложения #azure-служба приложений
Вопрос:
У меня есть веб-приложение Dotnet 6, работающее в службе приложений Azure на базе Windows. По мере роста трафика я принял рекомендацию «расширить» службу приложений до двух экземпляров. Мои развертывания выполняются с помощью простого действия GitHub и профиля публикации.
Я заметил, что, попав в конечную точку корневого API, в которой я возвращаю сборку и сервер запущенного API, на каждом из двух серверов выполняется другая версия кода. При следующей сборке и развертывании только один сервер отражает более новую версию.
- name: Azure WebApp uses: azure/webapps-deploy@v2.2.3 with: publish-profile: ${{ secrets.AZUREWEBAPPPUBLISHPROFILE }} app-name: esferas-app slot-name: staging package: ./artifacts/web Я чего-то не понимаю? Я не смог найти ничего, что просматривало бы документацию по действиям Azure или GitHub для чего-либо специального, необходимого для масштабирования при развертывании.
Комментарии:
1. Вы случайно не попали в конечную точку промежуточного слота вместо того, чтобы попасть в другой экземпляр?
2. Как вы проводите тестирование? Вы убиваете один сервер и позволяете балансировщику нагрузки перенести вас на другой?
3. @PeterBons — Он воспроизводится с обоими слотами; у постановки было две разные версии, а у производственного слота было две разные версии.
4. @misha130 — У меня есть конечная точка /api, которая возвращает имя приложения, имя сервера, среду и скомпилированную версию, добавленную во время сборки CI. Я могу перейти к этой конечной точке и несколько раз нажать «обновить», чтобы просмотреть различные экземпляры и версии, для которых я балансирую нагрузку.
5. Похоже, это может быть связано с файлами cookie с привязкой к ARR или настройками приложения для конкретного слота (привязка слота), инициализацией приложения или локальным кэшем (если включено). 1. Инициализация приложения гарантирует, что экземпляры вашего приложения полностью запустятся до того, как они будут добавлены для начала обслуживания запросов. 2.В веб-приложениях Azure по умолчанию включен файл cookie с привязкой к ARR, этот файл cookie связывает запрос клиента с определенным сервером. 3.Если автоматическая подкачка включена с пользовательским прогревом, инициируйте инициализацию приложения, отправив HTTP-запрос в корневой каталог приложения («/») в каждом экземпляре исходного слота.