После неудачного развертывания Azure наша развернутая служба AppService пуста.

У нас есть конвейер Azure DevOps, который сначала развертывает наши ресурсы с помощью ARM-шаблонов, а затем развертывает наши AppServices с помощью zip-архивов. Мы запускали конвейер несколько раз, и приложение работает правильно.

Через некоторое время после очередной попытки развертывания первый шаг развертывания (из ресурсов) завершился неудачно. Изменения в развертывании не содержат какие-либо изменения в AppService. А отказавшая часть - это , а не AppService (а вместо этого скажем, наша база данных), AppService по-прежнему становится недоступным. И вроде сбросился на глухие настройки хостинга. Кажется, что предыдущие развертывания все еще доступны в папке «/ data / SitePackages», но папка «/ site / wwwroot» содержит только файл «hostingstart.html» по умолчанию.

Из инкрементного развертывания я понял, что если AppService не изменился, он должен сохранить все свои настройки! (Таким образом, активно предыдущее развертывание.)

Это поведение по умолчанию? Можем ли мы каким-то образом сохранить работу предыдущего приложения, когда часть развертывания не удалась? Нужно ли нам выбирать другую стратегию развертывания?

Наш конвейер выглядит примерно так:

jobs:
  - deployment: 'Deploy'
    environment: '${{ parameters.environment }}' # The environment to use in Azure Devops (controls the required approvals)
    variables:
      - template: '../variables/deploy-variables.yml'
        parameters:
          environment: '${{ parameters.environment }}'
    strategy:
      runOnce:
        deploy:
          steps:
          - task: AzureResourceManagerTemplateDeployment@3
            displayName: 'Azure - Deploy resources'
            inputs:
              deploymentScope: 'Resource Group'
              azureResourceManagerConnection: '${{ parameters.azureServiceConnection }}'
              subscriptionId: '$(azureSubscriptionId)'
              action: 'Create Or Update Resource Group'
              resourceGroupName: '$(resourceGroup)'
              location: 'West Europe'
              templateLocation: 'Linked artifact'
              csmFile: '$(Pipeline.Workspace)/drop-resources/files/arm/resources/azuredeploy.json'
              csmParametersFile: '$(Pipeline.Workspace)/drop-resources/files/arm/resources/azuredeploy.parameters.json'
              deploymentMode: 'Incremental'

          - task: AzureWebApp@1
            displayName: 'Deploy Service'
            inputs:
              azureSubscription: '${{ parameters.azureServiceConnection }}'
              appName: '$(serviceName)'
              package: '$(Pipeline.Workspace)/drop-app/archives/Service.zip'
1
задан 1 March 2021 в 22:08
2 ответа

Я сам решил проблему, добавив следующие настройки приложения в развертывание ресурса (руки);

"WEBSITE_ENABLE_SYNC_UPDATE_SITE": "true",
"WEBSITE_RUN_FROM_PACKAGE": "1",

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

0
ответ дан 24 April 2021 в 00:49

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

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

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

1
ответ дан 24 April 2021 в 00:49

Теги

Похожие вопросы