Планирование сред

Завершено

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

В этом уроке вы узнаете о преимуществах согласованного использования кода для всех развертываний и конфигурации. Затем вы рассмотрите уровни управления и автоматизации, которые могут применяться к каждой из сред. Кроме того, вы можете учитывать ход выполнения изменений на каждом этапе процесса развертывания, а также элементы управления и типы управления, необходимые для поддержки выбранной стратегии развертывания.

Определение инфраструктуры как кода

Развертывание и конфигурация Azure охватывают гораздо больше приложений, виртуальных машин, служб хранилища и сети. Например, каждый из следующих элементов является формой конфигурации с соответствующими ресурсами Azure:

• Упорядочение ресурсов путем создания групп ресурсов, подписок и групп управления.
• Управление настройкой других ресурсов путем определения и применения определений, инициатив и назначений Политика Azure.
• Назначение ролей для разрешения пользователям, группам и удостоверениям рабочей нагрузки для доступа к ресурсам Azure.
• Настройка мониторинга, в том числе оповещений, для наблюдения за ресурсами Azure и обеспечения того, что они ведут себя так, как вы ожидаете.

При первом запуске определения инфраструктуры как кода вы можете не знать обо всех элементах, которые можно определить в шаблонах или определениях. Но по мере автоматизации рекомендуется определить все, что касается вашей среды в виде кода. Это позволяет использовать согласованный, проверенный и утвержденный процесс для всей конфигурации Azure. Так как код версии отслеживается в репозитории Git, вы можете просмотреть, как среда Azure изменилась с течением времени. Репозиторий Git можно использовать для отслеживания истории каждого изменения.

Например, предположим, что необходимо настроить оповещения Azure Monitor. Сначала можно подумать, что использование автоматизации для развертывания оповещений не имеет смысла. Но оповещения являются важной частью конфигурации Azure. Если оповещение создано неправильно, вы можете пропустить уведомления о критических проблемах в рабочей среде. Определив оповещения в коде:

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

Среды

При автоматическом развертывании инфраструктуры полезно вывести список сред, которые планируется использовать. Многие организации имеют различные типы среды, каждый из которых имеет разные характеристики. Например:

• В некоторых средах выполняется рабочий код, в то время как другие выполняют непроизводственные версии одного и того же кода, возможно, с различными конфигурациями.
• Некоторые среды существуют долго и никогда не предназначены для удаления. Другие являются временными: создаются автоматически и уничтожаются, когда они больше не используются.
• Некоторые среды используются командой разработчиков инфраструктуры или программного обеспечения. Другие используются вашей командой безопасности или даже вашей командой продаж, когда она должна продемонстрировать продукт потенциальным клиентам.

Рассмотрим среды, которые может использовать ваша компания по производству игрушек для своего веб-сайта:

При внесении и фиксации изменений в приложении или инфраструктуре конвейер развертывает изменения в последовательности непроизводственных сред: разработки, тестирования и промежуточного хранения. Вы также можете выполнить действия по утверждению вручную в определенных точках, чтобы определенные участники группы могли проверить конфигурацию или просмотреть журнал конвейера до продолжения развертывания. Затем конвейер в конечном итоге развертывает изменения в рабочей среде.

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

Ваша команда разработчиков также имеет собственные наборы сред. В ней есть песочницы для участников группы разработчиков, которые будут использоваться при изучении новых функций или экспериментах со службами Azure. Команда разработчиков также создает среды проверки запросов на вытягивание для каждого запроса GitHub на вытягивание, которые проверяет и объединяет.

Управляемые среды

В некоторых из этих сред имеет смысл требовать формального процесса для проверки и применения изменений. Среды этого типа называются управляемыми средами. Рабочая среда всегда должна контролироваться. Рекомендуется применять элементы управления к некоторым непроизводственных средам. Таким образом, вы можете убедиться, что все ограничения, которые налагают элементы управления, хорошо понятны и протестированы перед развертыванием в рабочей среде.

Неконтролируемые среды,напротив, не имеют большого количества или каких-либо формальных элементов управления в принципе. Они могут иметь тот же код и аналогичную конфигурацию в других средах, но они позволяют выполнять дополнительные эксперименты и нерегламентированные изменения конфигурации. В неконтролируемой среде пользователям может быть разрешено изменять конфигурацию с помощью портала Azure или путем непосредственного запуска команд Azure CLI/Azure PowerShell. Они также могут создавать ресурсы без использования утвержденного процесса организации. Изменения, внесенные в неконтролируемых средах, должны быть записаны в коде, прежде чем они смогут быть применены к управляемым средам, таким как рабочая среда.

Примечание.

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

После обсуждений с командой вы укажете, какие среды контролируются, а какие — нет. Вы также решаете, кто владеет каждой средой.

Имя среды	Description	Ответственный	Время существования	Уровень управления
Разработка	Интегрирует изменения нескольких разработчиков в одну среду.	Отдел сопровождения	Долгосрочные	Управляется
Тест	Среда для выполнения ручных и автоматических тестов на наличие изменений.	Отдел сопровождения	Долгосрочные	Управляется
Промежуточная	Последняя непроизводственная среда, в которой изменения развертываются перед рабочей средой с конфигурацией, аналогичной рабочей среде.	Отдел сопровождения	Долгосрочные	Управляется
Производственный экземпляр	Запускает рабочие нагрузки в рабочей среде.	Отдел сопровождения	Долгосрочные	Управляется
Демонстрация	Используется отделом продаж для демонстрации продукта новым клиентам.	Отдел продаж	Долгосрочные	Неуправляемые
Тестирование производительности	Динамически создается как дубликат рабочей среды для выполнения тестов производительности и нагрузочных тестов, а затем удаляется после завершения тестов.	Тестовая команда	Краткосрочные	Неуправляемые
тест на проникновение;	Динамически создается как дубликат рабочей среды для выполнения тестов на проникновение и нагрузочных тестов, а затем удаляется после завершения тестов.	Отдел безопасности	Краткосрочные	Неуправляемые
Проверки на запросов на вытягивание	Динамически создается для каждого запроса на вытягивание, создаваемого членом группы для изменения приложения или инфраструктуры. Среда удаляется при закрытии запроса на вытягивание.	Группа разработчиков	Краткосрочные	Неуправляемые
Песочницы для разработки	Создаются участниками группы разработчиков для экспериментов или изучения, а затем удаляются, если больше не нужны.	Группа разработчиков	Краткосрочные	Неуправляемые

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

Совет

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

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

В рамках схем обучения мы постепенно представили некоторые из этих концепций. Часто рекомендуется добавлять эти элементы в процесс развертывания как можно раньше.

Изоляция каждой среды

Важно разделить каждую из сред и сделать их автономными по возможности. Использование выделенных подписок Azure для каждой среды может помочь, но вам по-прежнему необходимо соблюдать осторожность, чтобы сохранять разделение сред.

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

Проверки и шлюзы

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

Проверки инфраструктуры часто включают в себя:

• Проверки кода.
• Развертывание встроенного кода в временных средах и выполнение автоматических или ручных тестов в средах.
• Анализ кода.
• Предварительная проверка.
• Ручное тестирование.
• Утверждение вручную.
• Автоматическое функциональное тестирование.
• Автоматическое тестирование состояния.
• Ожидание сигналов о работоспособности из предыдущей среды перед переходом к следующей среде.

Некоторые из этих проверок можно выполнять несколько раз в процессе развертывания, например для каждой управляемой среды.

Совет

При разработке процесса развертывания перечислите все необходимые действия независимо от того, какими бы мелкими и очевидными они бы ни были. Будьте так подробны, насколько это возможно. Вы можете сначала не автоматизировать все, но, следование этой методике, поможет вам создать схему для процессов автоматического развертывания в будущем.

Шлюз — это автоматическая или ручная проверка, которая должна быть успешной для продолжения развертывания.

Ручное вмешательство

Рекомендуется автоматизировать как можно больше проверок во время процессов проверки кода и развертывания. Однако организации может потребоваться ручное утверждение для развертывания в рабочей или других управляемых средах.

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

• Четко определите, кто может утвердить развертывание. Используйте группы Microsoft Entra для определения утверждающих, а не для указания отдельных пользователей. Список утверждающих лиц можно легко изменить в будущем.
• Создайте процесс для экстренных развертываний. Запланируйте, кто может утвердить развертывание, если обычные утверждающие не доступны. Аварийное развертывание может произойти ночью или в период отпуска.
• Ограничьте вмешательство человека только утверждением или отклонением развертывания. Избегайте необходимости выполнять какие-либо операции развертывания, если не существует шага, который невозможно автоматизировать.

Система управления

Azure предоставляет средства и возможности для управления средой, в том числе:

• Политика Azure для обнаружения ресурсов, настроенных способами, которые не соответствуют требованиям вашей организации. Это также может помочь предотвратить создание или перенастройку ресурсов таким образом, чтобы они не соответствовали требованиям.
• Блокировки для предотвращения изменений или удаления важных ресурсов.
• Группы управления помогают упорядочивать подписки Azure и настраивать управление доступом на основе ролей и политики последовательно в разных средах.
• Azure Monitor для записи метрик и журналов из ресурсов, представления их на панелях мониторинга и автоматического оповещения при отклонении от ожидаемых значений.

При создании недвижимости Azure рассмотрите возможность использования целевых зон Azure. С помощью целевой зоны можно выполнить сборку системы управления в среде с самого начала. Многие целевые зоны включают предварительно созданные файлы Bicep и Terraform для настройки среды. Ссылка на дополнительные сведения приведена в сводке.