Рекомендации по развертыванию
Каждая группа разработчиков имеет уникальные требования, которые могут усложнить реализацию эффективного конвейера развертывания в любой облачной службе. В этой статье представлены три основных компонента развертывания в Службе приложений: источники развертывания, конвейеры сборки и механизмы развертывания. В этой статье также рассматриваются некоторые рекомендации и советы по конкретным стекам языков.
Компоненты развертывания
Выбор источника развертывания
Источником развертывания является расположение кода приложения. Для рабочих приложений источником развертывания обычно является репозиторий, размещенный в системе управления версиями, например GitHub, BitBucket или Azure Repos. Для сценариев разработки и тестирования источником развертывания может быть проект на локальном компьютере.
Конвейер сборки
После выбора источника развертывания следующим шагом будет выбор конвейера сборки. Конвейер сборки считывает исходный код из источника развертывания и выполняет ряд действий (например, компиляция кода, минификация HTML и JavaScript, выполнение тестов и упаковка компонентов), чтобы получить приложение в виде, готовом к запуску. Конкретные команды, выполняемые конвейером сборки, зависят от вашего стека языков. Эти операции могут выполняться как на сервере сборки, например Azure Pipelines, так и локально.
Механизм развертывания
Механизм развертывания — это действие, которое служит для помещения созданного приложения в каталог /home/site/wwwroot веб-приложения. Каталог /wwwroot — это смонтированный каталог хранилища, который совместно используется всеми экземплярами веб-приложения. Когда механизм развертывания помещает приложение в этот каталог, экземпляры получают уведомления для синхронизации новых файлов. Служба приложений поддерживает следующие механизмы развертывания.
- Конечные точки KUDU. KUDU — это средство повышения производительности разработчика с открытым исходным кодом, которое запускается как отдельный процесс в службе приложений Windows, а также как второй контейнер в службе приложений Linux. Kudu обрабатывает непрерывные развертывания и предоставляет конечные точки HTTP для развертывания, например zipdeploy/.
- FTP и WebDeploy. Указав учетные данные сайта или пользователя, можно отправлять файлы через FTP или WebDeploy. Эти механизмы не проходят через Kudu.
Такие средства развертывания, как Azure Pipelines, Jenkins и подключаемые модули редактора, используют один из этих механизмов развертывания.
Использование слотов развертывания
Везде, где это возможно, при развертывании новой рабочей сборки используйте слоты развертывания. При использовании плана службы приложений уровня Standard или выше можно развернуть приложение в промежуточной среде, провести проверку изменений и тесты состояния. Когда вы будете готовы, вы можете переключить промежуточные и рабочие слоты. Операция переключения разогревает необходимые рабочие экземпляры в соответствии с масштабом рабочей среды, тем самым устраняя простои.
Непрерывное развертывание кода
Если в проекте определены ветви для тестирования, контроля качества и промежуточного хранения, то каждая из этих ветвей должна непрерывно развертываться на промежуточном слоте (такая конструкция называется Gitflow). Это позволяет заинтересованным лицам легко оценивать и тестировать развернутую ветвь.
Непрерывное развертывание не должно включаться для рабочего слота. Вместо этого рабочая ветвь (часто основной) следует развернуть в непроизводном слоте. Когда вы будете готовы освободить базовая ветвь, замените его на рабочий слот. Переключение на рабочую среду (вместо развертывания в рабочей среде) позволяет исключить простои и дает возможность откатывать изменения путем повторного переключения.
Непрерывное развертывание контейнеров
В случае пользовательских контейнеров из DOCKER или других реестров контейнеров необходимо развернуть образ на промежуточном слоте, а затем переключить его на рабочий, чтобы исключить простои. Автоматизация — более сложный способ, чем развертывание кода, так как необходимо передать образ в реестр контейнеров и обновить тег образа для веб-приложения.
Для каждой ветви, которую требуется развернуть в слот, настраивайте автоматизацию для каждой фиксации ветви.
- Сборка и пометка образа. В рамках конвейера сборки пометьте образ идентификатором фиксации Git, меткой времени или другими идентификационными данными. Лучше не использовать тег “latest”, заданный по умолчанию. В противном случае будет трудно отследить, какой код в настоящее время развернут, что сделает отладку гораздо сложнее.
- Отправка образа с тегом. После сборки и пометки образа конвейер передает его в реестр контейнеров. На следующем шаге в слот развертывания будет извлечен образ c тегом из реестра контейнеров.
- Обновите слот развертывания, указав новый тег образа. При обновлении этого свойства сайт автоматически перезапускается и извлекает новый образ контейнера.
Ниже приведены примеры распространенных платформ автоматизации.
Использование Azure DevOps.
Служба приложений имеет встроенную непрерывную доставку контейнеров через центр развертывания. Перейдите к своему приложению на портале Azure и выберите Центр развертывания в разделе Развертывание. Следуя инструкциям, выберите свой репозиторий и ветвь. Конвейер выпуска и сборка DevOps будут настроены для автоматической сборки, пометки и развертывания контейнера при отправке новых фиксаций в выбранную ветвь.
Использование GitHub Actions
Можно также автоматизировать развертывание контейнера с помощью GitHub Actions. Приведенный ниже файл рабочего процесса создаст и помечает контейнер с помощью ИД фиксации, отправьте его в реестр контейнеров и обновите указанное веб-приложение с новым тегом образа.
on:
push:
branches:
- <your-branch-name>
name: Linux_Container_Node_Workflow
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
# checkout the repo
- name: 'Checkout GitHub Action'
uses: actions/checkout@main
- uses: azure/docker-login@v1
with:
login-server: contoso.azurecr.io
username: ${{ secrets.REGISTRY_USERNAME }}
password: ${{ secrets.REGISTRY_PASSWORD }}
- run: |
docker build . -t contoso.azurecr.io/nodejssampleapp:${{ github.sha }}
docker push contoso.azurecr.io/nodejssampleapp:${{ github.sha }}
- uses: azure/webapps-deploy@v2
with:
app-name: 'node-rnc'
publish-profile: ${{ secrets.azureWebAppPublishProfile }}
images: 'contoso.azurecr.io/nodejssampleapp:${{ github.sha }}'
Использование других поставщиков автоматизации
Приведенные выше действия относятся к другим служебным программам автоматизации, таким как CircleCI и Travis CI. Однако для обновления слотов развертывания с новыми тегами образов на завершающем шаге необходимо использовать Azure CLI. Чтобы использовать Azure CLI в скрипте автоматизации, создайте субъект-службу с помощью следующей команды.
az ad sp create-for-rbac --name "myServicePrincipal" --role contributor \
--scopes /subscriptions/{subscription}/resourceGroups/{resource-group} \
--sdk-auth
В скрипте войдите с помощью az login --service-principal, предоставляя сведения о субъекте. Затем можно использовать az webapp config container set для задания имени контейнера, тега, URL-адреса и пароля реестра. Ниже приведены полезные ссылки для создания процесса непрерывной интеграции контейнера.
Специфика для конкретных языков
Java
Используйте Kudu zipdeploy/ API для развертывания приложений JAR и wardeploy/ для приложений WAR. Если вы используете Jenkins, эти API можно использовать непосредственно на этапе развертывания. Дополнительные сведения см. в этой статье.
Узел
По умолчанию KUDU выполняет шаги сборки для приложения Node (npm install). Если вы используете службу сборки, например Azure DevOps, то сборка Kudu не требуется. Чтобы отключить сборку KUDU, создайте параметр приложения SCM_DO_BUILD_DURING_DEPLOYMENT со значением false.
.NET
По умолчанию KUDU выполняет шаги сборки для приложения .NET (dotnet build). Если вы используете службу сборки, например Azure DevOps, то сборка Kudu не требуется. Чтобы отключить сборку KUDU, создайте параметр приложения SCM_DO_BUILD_DURING_DEPLOYMENT со значением false.
Другие рекомендации по развертыванию
Локальный кэш
Содержимое Службы приложений Azure хранится в Службе хранилища Azure; оно доступно в долгосрочном режиме в общей папке содержимого. Однако некоторым приложениям необходимо просто высокопроизводительное хранилище содержимого только для чтения, которое может работать с высокой доступностью. Такие приложения могут получить выигрыш от использования локального кэша. Локальный кэш не рекомендуется использовать для сайтов управления контентом, таких как WordPress.
Для предотвращения простоев всегда используйте локальный кэш в сочетании со слотами развертывания. Сведения о совместном использовании этих функций см. в этом разделе.
Высокая загрузка ЦП или памяти
Если ваш план службы приложений использует более 90 % доступных ресурсов процессора или памяти, то при обработке развертывания может возникнуть проблема с базовой виртуальной машиной. В этом случае следует временно увеличить число экземпляров для выполнения развертывания. После завершения развертывания можно вернуть число экземпляров к предыдущему значению.
Дополнительные сведения о лучших методиках см. на странице Диагностика службы приложений, где можно найти практические рекомендации, относящиеся к конкретному ресурсу.
- Перейдите к своему веб-приложению на портале Azure.
- Выберите "Диагностика и решение проблем" в области навигации слева, которая открывает Служба приложений диагностику.
- Выберите Рекомендации на домашней странице.
- Выберите рекомендации по обеспечению доступности и производительности или рекомендации по оптимальной настройке , чтобы просмотреть текущее состояние приложения в отношении этих рекомендаций.
Можно также напрямую открыть диагностику службы приложений для своего ресурса по следующей ссылке: https://portal.azure.com/?websitesextension_ext=asd.featurePath%3Ddetectors%2FParentAvailabilityAndPerformance#@microsoft.onmicrosoft.com/resource/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{siteName}/troubleshoot.