Лучшие практики развертывания

Каждая команда разработчиков имеет уникальные требования, что может затруднить реализацию эффективного процесса развертывания в любом облачном сервисе. Эта статья знакомит с тремя основными компонентами развертывания в Azure App Service: источники развертывания, конвейеры сборки и механизмы развертывания. В этой статье также рассматриваются некоторые лучшие практики и советы для определённых языковых стеков.

Компоненты развертывания

Этот раздел описывает три основные компонента для развертывания в App Service.

Источник развертывания

Источник развертывания — это место, где находится код вашего приложения. Для производственных приложений источником развертывания обычно является репозиторий, размещенный на платформе контроля версий, такой как GitHub, Bitbucket или Azure Repos. Для сценариев разработки и тестирования источником развертывания может быть проект на вашем локальном компьютере.

Конвейер сборки

После того как вы выберете источник развертывания, следующим шагом будет выбор build pipeline. Конвейер сборки читает ваш исходный код из источника развёртывания и выполняет ряд шагов, чтобы привести приложение в состояние готовности к запуску.

Шаги могут включать компиляцию кода, минимизацию HTML и JavaScript, запуск тестов и упаковку компонентов. Конкретные команды, выполняемые конвейером сборки, зависят от вашего языкового стека. Вы можете выполнять эти операции на сервере сборки, например, Azure Pipelines, или локально.

Механизм развертывания

Механизм развертывания — это действие, используемое для размещения вашей собранной программы в каталоге /home/site/wwwroot вашего веб-приложения. Каталог /wwwroot является общей точкой подключения для всех экземпляров вашего веб-приложения. Когда механизм развертывания помещает ваше приложение в этот каталог, ваши экземпляры получают уведомление для синхронизации новых файлов.

Служба приложений поддерживает следующие механизмы развертывания:

• Конечные точки Kudu: Kudu — это инструмент с открытым исходным кодом, повышающий продуктивность разработчиков, который работает как отдельный процесс в Windows App Service. Он работает как второй контейнер в Linux App Service. Kudu выполняет непрерывные развертывания и предоставляет конечные точки HTTP для развертывания, такие как zipdeploy/.
• FTP и WebDeploy: Используя ваши учетные данные сайта или пользователя, вы можете загружать файлы через FTP или WebDeploy. Эти механизмы не проходят через Kudu.

Инструменты развертывания, такие как Azure Pipelines, Jenkins и плагины редактора, используют один из этих механизмов развертывания.

Используйте слоты развертывания

По возможности, при внедрении новой производственной сборки используйте слоты развертывания. С планом уровня Standard App Service или лучше вы можете развернуть свое приложение в промежуточной среде, проверить свои изменения и провести основные тесты. Когда будете готовы, поменяйте местами промежуточные и производственные слоты. Операция обмена разогревает необходимые экземпляры рабочих процессов, чтобы соответствовать вашему производственному масштабу, что исключает время простоя.

Непрерывно разворачивать код

Если у вашего проекта есть ветки, предназначенные для тестирования, контроля качества и промежуточных версий, каждая из этих веток должна непрерывно развертываться на промежуточный слот. Этот подход известен как Gitflow design. Данный дизайн позволяет вашим заинтересованным сторонам легко оценивать и тестировать внедренную ветку.

Непрерывный деплоймент никогда не должен быть включен для вашего производственного слота. Вместо этого ваш рабочий ветвь (обычно основная) должна быть развернута на непроизводственном слоте. Когда вы будете готовы выпустить базовую ветку, переместите ее в рабочий слот. При переключении в режим эксплуатации вместо развертывания в эксплуатацию предотвращаются простои, и у вас есть возможность откатить изменения, снова переключив режим.

Непрерывно развертывать контейнеры

Для пользовательских контейнеров из Docker или других контейнерных реестров разверните образ в промежуточный слот и замените на рабочий, чтобы предотвратить простой работы. Автоматизация является более сложной, чем развертывание кода. Вам нужно загрузить образ в реестр контейнеров и обновить тег образа на веб-приложении.

Для каждой ветки, которую вы хотите развернуть в слоте, настройте автоматизацию для выполнения этих задач при каждом коммите в ветку.

1. Создайте и отметьте образ. Как часть процесса сборки, отметьте изображение идентификатором коммита git, временной меткой или другой идентифицирующей информацией. Лучше не использовать стандартный тег latest. В противном случае трудно отследить, какой код в настоящее время развернут, что затрудняет отладку.
2. Отправьте изображение с тегом. После того как образ создан и помечен, конвейер отправляет его в реестр контейнеров. На следующем этапе слот развертывания извлекает отмеченное изображение из реестра контейнеров.
3. Обновите слот развертывания с новым тегом изображения. При обновлении этого свойства сайт автоматически перезапускается и извлекает новый образ контейнера.

Эта статья содержит примеры для распространенных фреймворков автоматизации.

Использование Azure DevOps

Служба App Service имеет встроенную непрерывную доставку для контейнеров через Центр развертывания. Перейдите к своему приложению в портале 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-адрес реестра и пароль реестра. Для получения дополнительной информации см. Как войти в Azure CLI на Circle CI.

Учет языковых особенностей

Имейте в виду следующие соображения для реализаций на Java, Node и .NET.

Ява

Используйте API Kudu zipdeploy для развертывания JAR-приложений. Используйте wardeploy для приложений WAR. Если вы используете Jenkins, вы можете использовать эти API напрямую на этапе развертывания. Для получения дополнительной информации см. Deploy to Azure App Service with Jenkins.

Узел

По умолчанию Kudu выполняет этапы сборки вашего Node-приложения (npm install). Если вы используете сервис сборки, такой как Azure DevOps, сборка Kudu не требуется. Чтобы отключить сборку Kudu, создайте параметр приложения SCM_DO_BUILD_DURING_DEPLOYMENT со значением false.

.СЕТЬ

По умолчанию Kudu выполняет шаги сборки для вашего приложения .NET (dotnet build). Если вы используете сервис сборки, такой как Azure DevOps, сборка Kudu не требуется. Чтобы отключить сборку Kudu, создайте параметр приложения SCM_DO_BUILD_DURING_DEPLOYMENT со значением false.

Другие соображения по развертыванию

Другие соображения включают локальный кэш и высокую загрузку процессора или памяти.

локальный кэш

Контент Azure App Service хранится в Azure Storage и представляется в устойчивом виде в качестве общего ресурса. Однако некоторым приложениям просто нужно высокопроизводительное, только для чтения хранилище контента, которое они могут использовать с высокой доступностью. Эти приложения могут выиграть от использования локального кэша. Для получения дополнительной информации см. обзор локального кеширования Azure App Service.

Чтобы избежать простоя, всегда используйте локальный кэш с слотами развертывания. Для получения информации о совместном использовании этих функций, смотрите Рекомендуемые практики.

Высокая загрузка ЦП или памяти

Если ваш план App Service использует более 90% доступного ЦП или памяти, базовой виртуальной машине может быть трудно обрабатывать ваше развертывание. В случае возникновения этой ситуации временно увеличьте количество экземпляров, чтобы выполнить развертывание. После завершения развертывания вы можете вернуть количество экземпляров к его предыдущему значению.

Чтобы получить дополнительную информацию, посетите App Service Diagnostics, чтобы узнать о практических рекомендациях, применимых к вашему ресурсу.

1. Перейдите в свое веб-приложение в портале Azure.

2. Выберите Диагностика и решение проблем в левой навигации, чтобы открыть App Service Diagnostics.

3. Выберите Доступность и производительность или изучите другие варианты, такие как Анализ высокого использования ЦП.

   Просмотрите текущее состояние вашего приложения с учётом этих лучших практик.

Вы также можете использовать эту ссылку, чтобы напрямую открыть диагностику App Service для вашего ресурса: https://portal.azure.com/?websitesextension_ext=asd.featurePath%3Ddetectors%2FParentAvailabilityAndPerformance#@microsoft.onmicrosoft.com/resource/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{siteName}/troubleshoot.

Связанный контент

• Справочник переменных среды и настроек приложения