Ағылшын тілінде оқу

Бөлісу құралы:

Рекомендации по развертыванию

  • Мақала

Ескерім

Начиная с 1 июня 2024 г. только что созданные Служба приложений приложения могут создать уникальное имя узла по умолчанию, использующее соглашение <app-name>-<random-hash>.<region>.azurewebsites.netоб именовании. Существующие имена приложений остаются неизменными. Например:

myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Дополнительные сведения см. в разделе "Уникальное имя узла по умолчанию" для ресурса Служба приложений.

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

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

В этом разделе описываются три основных компонента для развертывания в Служба приложений.

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

Источник развертывания — это расположение кода приложения. Для рабочих приложений источник развертывания обычно является репозиторием, размещенным программным обеспечением управления версиями, таким как 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 и подключаемые модули редактора, используют один из этих механизмов развертывания.

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

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

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

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

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

Схема, показывающая поток между ветвями разработки, промежуточного хранения и основными ветвями и слотами, в которые они развертываются.

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

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

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

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

На схеме показан визуальный элемент использования слотов, представляющий веб-приложение, реестр контейнеров и ветви репозитория.

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

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

Служба приложений имеет встроенную непрерывную доставку контейнеров через центр развертывания. Перейдите к приложению в портал Azure. В разделе Развертывание выберите Центр развертывания. Следуя инструкциям, выберите свой репозиторий и ветвь. Этот подход настраивает конвейер сборки и выпуска DevOps для автоматической сборки, тега и развертывания контейнера при отправке новых фиксаций в выбранную ветвь.

Использование GitHub Actions

Можно также автоматизировать развертывание контейнера с помощью GitHub Actions. Файл рабочего процесса создает и тегирует контейнер с ИД фиксации, отправляет его в реестр контейнеров и обновляет указанное веб-приложение с новым тегом образа.

YAML 
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 в скрипте автоматизации, создайте субъект-службу с помощью следующей команды.

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.

Java

Используйте API Kudu zipdeploy для развертывания JAR-приложений. Используйте wardeploy для приложений WAR. Если вы используете Jenkins, эти API можно использовать непосредственно на этапе развертывания. Дополнительные сведения см. в статье "Развертывание в службе приложение Azure с помощью Jenkins".

Узел

По умолчанию 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; оно доступно в долгосрочном режиме в общей папке содержимого. Однако некоторым приложениям необходимо просто высокопроизводительное хранилище содержимого только для чтения, которое может работать с высокой доступностью. Такие приложения могут получить выигрыш от использования локального кэша. Дополнительные сведения см. в разделе приложение Azure Локальный кэш службы.

Ескерім

Локальный кэш не рекомендуется использовать для сайтов управления контентом, таких как WordPress.

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

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

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

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

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

  2. Выберите "Диагностика и решение проблем" в области навигации слева, которая открывает Служба приложений диагностику.

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

    Просмотрите текущее состояние приложения в отношении этих рекомендаций.

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

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