Поменять слоты в Azure devops (angular+api), как изменить конфигурацию Angular для целевого слота?
Конфигурация приложения Angular — сложная часть. Во время нашего задания публикации в конвейере Azure Yaml мы выполняем замену «маркера», чтобы соответствовать целевой среде в этой конфигурации на токенизированном артефакте.
Позже мы развернем этот токенизированный артефакт (токены уже заменены) в конкретной среде:
- task: AzureWebApp@1
inputs:
azureSubscription: 'xxxx'
appType: 'webApp'
appName: [depends on $(environment)]
package: '$(Pipeline.Workspace)/xxx'
Таким образом, у нас может быть определенная конфигурация для DEV, TEST и STAGING (staging — это производственный слот).
В какой-то момент нам нужно поменять STAGING на PROD. В результате у нас есть приложение Angular в PROD, но со значениями для STAGING, что неверно, и здесь мы застряли на том, что делать. Я хотел бы получить совет о том, как лучше продолжать.
Некоторые идеи:
Во время развертывания STAGING создайте также файлы PROD, используя другое имя (например, main.*.js.PROD). Затем, после обмена PROD, переименуйте файлы, но..
- Файлы могут использоваться и, следовательно, не могут быть переименованы.
- Во время переименования добавляется небольшое время простоя (я даже не уверен, есть ли способ для yaml переименовывать уже развернутые файлы).
Когда запускается развертывание в PROD, сначала развертывайте в STAGING с переменными PROD, затем выполняйте своп, но...
- У него будет более длительное время развертывания, потому что сначала нужно будет развернуть STAGING, даже если он уже развернут.
- Он использует мало преимуществ слотов.
- Переменные PROD останутся в STAGING после подкачки.
Не переключайтесь с STAGING на PROD, но...
- У него будет самое долгое время развертывания.
- Он не будет использовать преимущества слотов.
Редактировать: Спасибо за совет @prawin, добавлю еще:
- Обеспечьте динамическую настройку со стороны сервера
- Выглядит многообещающе, так как внешний интерфейс делит хост с серверной частью. Но все же, что в случае отвязки от бэкенд части? Это означает, что URL-адрес серверной части также необходимо будет где-то настроить в зависимости от среды..
После некоторого чтения, проб и ошибок, у меня есть еще несколько:
Разверните только изменяемый файл с помощью FTP или API Kudu.
Сгенерируйте и скопируйте конфигурацию PROD в STAGING, затем выполните задачу подкачки. Мне этот вариант больше всего нравится.
Есть ли что-то еще, чтобы рассмотреть? Каков "стандартный" способ выполнить это?
@Prawin, спасибо за это предложение, мы также рассмотрим. Насколько я понимаю, вместо того, чтобы иметь настройки Angular в виде статических сгенерированных файлов, мы могли бы добраться до настроек слота. Для этого мы должны создать некий сервис, способный прочитать его и предоставить приложению Angular. Сильно хорошо звучит.
@Prawin, это отличное предложение; ты должен сделать это ответом
Ответы 1
После тестирования различных подходов мы нашли следующий способ:
- Создайте специальный файл PROD на этапе сборки. Этот файл будет помещен как отдельный артефакт. Идея состоит в том, чтобы иметь артефакты «сборка» и «угловая конфигурация PROD», например:
- publish: $(Build.artifactstagingdirectory)/Config
displayName: 'Publish config'
artifact: ConfigPROD
- publish: $(Build.artifactstagingdirectory)/Build
displayName: 'Publish build'
artifact: BUILD
- После развертывания артефакта BUILD в STAGING загрузите артефакт ConfigPROD в STAGING с помощью FTP. Это перезапишет существующую (STAGING) конфигурацию.
- task: DownloadPipelineArtifact@2
displayName: 'Download config artifact'
inputs:
buildType: 'specific'
project: [your devops project name]
definition: [your build definition name]
artifactName: 'ConfigPROD'
path: '$(Pipeline.Workspace)/config'
- task: FtpUpload@2
displayName: 'Deploy configPROD'
inputs:
credentialsOption: 'inputs'
serverUrl: [your ftp server url]
username: [your ftp username]
password: [your ftp password]
rootDirectory: '$(Pipeline.Workspace)/config'
filePatterns: '**'
remoteDirectory: [your remote directory]
clean: false
cleanContents: false
- Поменять STAGING на PROD
- task: AzureAppServiceManage@0
displayName: 'Swap STAGING and PROD'
inputs:
azureSubscription: [your azure subscription]
Action: 'Swap Slots'
WebAppName: [your app name]
ResourceGroupName: [your rg name]
SourceSlot: 'staging'
Если вам интересно, как найти учетные данные ftp в Azure, вот путь: [AzurePortal]/[AppServicePage]/Центр развертывания/Учетные данные для развертывания
[ваш удаленный каталог] можно проверить с помощью Kudu или консоли в «Дополнительных инструментах». В этом случае Angular wwwroot находится внутри сайт/wwwroot, поэтому мой удаленный каталог — «/сайт/wwwroot/wwwroot».
Не серебряная пуля, но работает на 100% и нет абсолютно никаких дополнительных простоев.
Спасибо за предложения
Отличная идея! Мило
Вместо того, чтобы иметь main.js в качестве статического js, возможно ли динамически серверировать его с сервера? Если да, то вы можете использовать «Настройки слота развертывания», чтобы убедиться, что настройки, специфичные для среды, не меняются местами при выполнении замены. Вы можете узнать больше о "Настройки слота развертывания" здесь docs.microsoft.com/en-us/azure/app-service/…