Шаблон Azure ARM для непрерывного добавления ресурсов

Я хотел бы прояснить следующий пробел в шаблонах Azure ARM:
Давайте предположим, что у меня есть основной шаблон со следующим:

App Service plan creation
Azure SQL server creation
SQL elastic pool creation (using previously created Azure SQL server)

Этот шаблон будет использоваться для первоначального создания моей облачной инфраструктуры.

Затем я добавлю дочерний (вложенный или связанный) шаблон к моему основному шаблону.
Дочерний шаблон будет содержать создание AppService Web App+SQL:

Web App creation (using App Service Plan defined in master template)
Azure SQL database creation (using Azure SQL server defined in master template)
Adding Azure SQL database to elastic pool (defined in master template)

Я опущу несколько деталей, таких как первоначальное создание хранилища ключей Azure, а также создание и хранение в этом хранилище необходимых учетных данных, таких как имя пользователя и пароль администратора SQL или сертификаты SSL для моего веб-приложения.

Итак, что я хочу получить в конце выполнения развертывания шаблона:
first template deployment

  • Создание базовой инфраструктуры (план службы приложений для веб-приложений, SQL-сервер добавлен в эластичный пул)
  • Один экземпляр службы приложений (веб-приложение + SQL), использующий ранее созданный план службы приложений и эластичный пул (где будет размещена моя база данных SQL).

second template deployment

  • Один (второй) экземпляр службы приложений (веб-приложение + SQL) будет создан с использованием существующей инфраструктуры.

N-template deployment

  • Будет развернут один (N-экземпляр) службы приложений (веб-приложение + SQL) ‹...>

Вопросы:

  • Должен ли я использовать вложенные или связанные шаблоны? В чем конкретно разница в моем случае?
  • Правильно ли мое общее решение или мне следует изменить его\найти другой подход?

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


person Sergey    schedule 02.02.2018    source источник


Ответы (1)


Шаблон Nested\Linked можно использовать взаимозаменяемо. Это то же самое. Можно возразить, что вложенные шаблоны — это встроенные шаблоны, а связанные на самом деле связаны, но это не имеет большого значения, и то, и другое — одно и то же (они реализованы в шаблоне немного по-разному, но результат тот же). Дочерние шаблоны (и именно так вы хотите их назвать).

Что касается собственно вопросов:

  1. Почему вы вообще хотите использовать дочерние шаблоны? Я не вижу варианта использования для них.
  2. Я не вижу ничего плохого в этом подходе, кроме использования дочерних шаблонов просто ради их использования.

Если вы хотите, чтобы ваш подход был «модульным» (отсюда использование дочерних шаблонов), вы также можете использовать разделение конфигурации и реализации для достижения результата (СУХОЙ метод).

person 4c74356b41    schedule 02.02.2018
comment
Звучит весьма двусмысленно. Можно поточнее про шаблоны? Потому что мне нужно сначала создать свою облачную инфраструктуру, а затем постоянно развертывать веб-приложения, поэтому я не могу защитить свои исходные ресурсы, поскольку они вообще не созданы. Предлагаемый DRY-подход означает, что я должен разделить свои шаблоны — один для инфраструктуры, а второй — для непрерывного развертывания, чтобы он отличался от статья — разбить решение на компоненты и повторно использовать шаблоны ‹...›. - person Sergey; 02.02.2018
comment
ну, видите ли, ваш вопрос близок к плохому. потому что не может быть реального ответа на ваш вопрос. это вопрос предпочтений. I can't protect my initial resources as they aren't created at all. вам не нужно их защищать. Просто используйте инкрементный режим (который в любом случае используется по умолчанию). Если вам нужно развернуть веб-приложения только после развертывания исходного шаблона, создайте отдельный шаблон только для веб-приложений и используйте его для развертывания новых веб-приложений. - person 4c74356b41; 02.02.2018
comment
Конечно, я понимаю. Спасибо. - person Sergey; 02.02.2018