У нас есть конвейер 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'
Я сам решил проблему, добавив следующие настройки приложения в развертывание ресурса (руки);
"WEBSITE_ENABLE_SYNC_UPDATE_SITE": "true",
"WEBSITE_RUN_FROM_PACKAGE": "1",
Это сохраняет текущий пакет активным, ранее это приложение- настройки мы удалили, пока пакет был еще доступен.
Это ожидается.Ваш конвейер выполняет две задачи: развертывание службы приложения, а затем развертывание вашего приложения. Если первая часть завершится успешно, она развернет службу приложения с файлами по умолчанию, если второй шаг завершится неудачно, она останется в этом состоянии.
Это должно происходить только при первом развертывании. Если вы запустите последующее развертывание, при котором первый шаг завершится успешно, существующие файлы в веб-приложении не будут перезаписаны, они останутся без изменений. Если ваш второй шаг завершился неудачно, то старые файлы все еще должны быть там, если только ваш второй шаг не завершился неудачно и не перезаписал некоторые файлы.
Если вы хотите убедиться, что у вас есть возможность вернуться к предыдущей версии, даже если файлы действительно перезаписываются, вам следует использовать слоты развертывания .