Центр развертывания службы приложений Azure — что делает «Отключение» и как «повторно подключиться»?

Существуют разные модели развертывания службы приложений в Azure. Они эксклюзивны. Если вы используете один, вам следует игнорировать другие.

Модели развертывания службы приложений:

1. sFTP.
2. Continuous deployment from a code repo.
3. Local Git.
4. Continuous deployment of a Docker image.
5. ZIP deploy.
6. Run from package.

Итак, если развертывание выполняется через Azure DevOps Pipeline, обычно используется #5 - ZIP deploy.

В вашем случае вы публикуете образ Docker только через конвейер Azure DevOps. Но развертывание работает с использованием "4 - Continuous deployment of a Docker image.

«Источник: Azure Repos» — для #2 - Continuous deployment from a code repo.

Они взаимоисключающие. Не следует ожидать повторного появления Disconnect (#2) после развертывания с использованием #4 или #5.

Моё субъективное мнение:

• sFTP — древнее решение, которое не стоит обсуждать. Вам необходимо управлять SFTP-соединением. Это не атомно.

• Continuous deployment from a code repo не предназначен для производственного использования. Он развертывает каждое изменение кода без каких-либо тестов или подготовки инфраструктуры.

• Развертывание Local Git аналогично Continuous deployment from a code repo

• Continuous deployment for a Docker image — хорошее решение для подхода на основе Docker. Однако вы можете рассмотреть возможность использования контейнерных приложений вместо служб приложений для Docker.

• ZIP deploy — приемлемая модель, которую можно и нужно использовать из конвейера CI/CD. Наиболее часто используемый подход.

• Run from package может быть лучшим подходом из-за преимуществ. Преимущества:

  • Атомное развертывание
  • Более быстрое развертывание
  • Уменьшен холодный запуск приложений на основе JavaScript.

Ресурс приложения не должен знать, как он развернут. Поэтому для производства следует использовать только подходы Docker-based, ZIP Deploy и Run from package.

Кроме того, этап развертывания должен быть частью конвейера CI/CD. Вышеупомянутые подходы можно использовать в конвейере (например, Azure Pipelines, GitHub Actions и т. д.).

Ссылки:

• ZIP deploy - Развертывание файлов в Службе приложений
• Local Git - Локальное развертывание Git в Службе приложений Azure
• Continuous deployment for a Docker image - Перенос специального программного обеспечения в Службу приложений Azure с помощью специального контейнера
• sFTP - Разверните свое приложение в Службе приложений Azure с помощью FTP/S
• Continuous deployment from a code repo - Непрерывное развертывание в Службе приложений Azure
• Run from package - Запускайте свое приложение в Службе приложений Azure прямо из ZIP-пакета

В вашем конвейере yaml он только входит в ACR, создает образ и отправляет его в ACR, но еще не связан со службой приложений.

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

Пример Ямла:

    - task: Docker@2
      displayName: Build and push an image to container registry
      inputs:
        containerRegistry: '$(dockerRegistryServiceConnection)'
        repository: '$(imageRepository)'
        command: 'buildAndPush'
        Dockerfile: '**/Dockerfile'
        tags: '$(tag)'

    - task: AzureWebAppContainer@1
      inputs:
        azureSubscription: 'ARMConn6'
        appName: 'wadeapp3'
        containers: '$(containerRegistry)/$(imageRepository):$(tag)'

Нажмите view log на странице обзора службы приложений, и вы перейдете к сведениям о центре развертывания, но, как упоминал @VladDX, not registry settings content но к содержимому репозитория.

Если использовать Azure Cli, например az webapp create --name Dev-App \ --plan Dev-AppServicePlan \ --resource-group chat-Dev \ --deployment-container-image-name devcontainerregistry.azurecr.io/chat-node:latest, в центре развертывания, это будет: