Member 14637786 Ответов: 1

Развертывание нескольких служб приложений в облаке azure из одного репозитория azuredevops


Привет,

Я ищу хорошее решение, которое позволило бы развернуть приложение из репозитория azure devops в облако azure, но несколько раз, например, 5 групп ресурсов с 1 приложением в каждой, и приложения на данный момент одинаковы, в будущем они могут иметь некоторые конкретные параметры развертывания. Кроме того, я хочу, чтобы все приложения были перераспределены по завершенному конвейеру сборки (в основном мастер-ветвь с новым pullrequest, который прошел успешно). Разве это возможно? Мы не хотим развертывать все приложения вручную, когда что-то новое попадает в главную ветвь. Просто запустите скрипт или что-то еще и заставьте его автоматически обновлять приложения. Какой здесь хороший подход?

Что я уже пробовал:

Я попытался найти конфигурацию шаблона azure для создания службы приложений с CI/CD, уже настроенной для отслеживания РЕПО devops для изменений главной ветви, но ничего не вышло. Это позволит достичь чего-то похожего на центр развертывания в Службе приложений на портале Azure при настройке Azure Devops CI/CD.

1 Ответов

Рейтинг:
2

Afzaal Ahmad Zeeshan

Цитата:
5 групп ресурсов с 1 приложением в каждой, и приложения на данный момент одинаковы, в будущем они могут иметь некоторые конкретные параметры развертывания.
Я рекомендую вам использовать инструменты DevOps для автоматизации этого процесса. Инфраструктура как код-это один большой термин, который приходит на ум, когда нужно позаботиться об этом подходе.

Цитата:
конфигурация шаблона azure для создания службы приложений с уже настроенным CI/CD для отслеживания РЕПО devops
Если вы хотите создать новый ресурс, то шаблоны Azure Resource Manager будут работать. Если вы хотите обновить существующее веб-приложение, то это может быть не очень хорошим решением. Поскольку перераспределение решений-это не то, что вы ищете.

Я написал сообщение в блоге, чтобы обсудить эту тему и то, как она может помочь вам написать многоразовые определения инфраструктуры, читайте это здесь[^].
Цитата:
Просто запустите скрипт или что-то еще и заставьте его автоматически обновлять приложения. Какой здесь хороший подход?
Это зависит от того, как вы развертываете приложение. Является ли приложение образом Docker? Если это так, вы можете использовать веб-крючки для запуска обновления на производстве.

В других случаях, таких как monolith, вы можете использовать инструменты DevOps, такие как GitLab Auto DevOps или Azure DevOps release pipelines для обновления приложения в облаке.

Ознакомьтесь с этой документацией, она дает обзор этого сценария: Конвейеры выпуска - конвейеры Azure | Microsoft Docs[^]


Member 14637786

Мой артефакт приложения теперь просто ZIP. Никакого докера. Кроме того, на данный момент нет шаблона ARM, я просто создал ресурсы вручную с помощью PowerShell. Пример сценария, которого я хочу достичь, таков:
1. у меня есть одно РЕПО Azure DevOps
2. У меня есть шаблон рукоятки для развертывания приложения, которая будет начальной конфигурации. Сейчас все так и есть:
- создать группу ресурсов
- создать учетную запись хранения
- создать план
- создание службы приложений
И ofc параметры будут отличаться для каждого развернутого экземпляра, для разных групп ресурсов и т. д.
3. А теперь я хочу развернуть свое приложение в недавно созданной облачной структуре на основе шаблона ARM.
4. Этот сценарий будет выполняться несколько раз для каждого вновь созданного приложения в своей собственной группе и т. д. В принципе каждый клиент имеет свой собственный экземпляр
5. Теперь я хочу, чтобы все развернутые приложения обновились до более новой версии, если она доступна в главной ветви. Это может быть вызвано, например, вручную на данный момент, но я не хочу развертывать каждое приложение по одному, потому что, когда я развертываю около 50 приложений, это займет слишком много времени, очевидно, чтобы просто обновить их до более новой версии. Было бы неплохо, если бы существующее приложение в облаке могло просто отслеживать, есть ли новый релиз на Azure DevOps.

У меня действительно нет большого опыта в этом, чтобы выбрать правильный подход.