Уверенное развертывание
Достичь требуемого состояния развертывания с помощью прогнозируемости. |
---|
Создайте цепочку поставок рабочей нагрузки, которая позволяет согласованно достичь цели прогнозируемости во всех средах на платформах размещения рабочей нагрузки, приложениях, данных и ресурсах конфигурации. Механизм развертывания должен иметь возможность автоматизации, тестирования, мониторинга и управления версиями. Оно должно быть модульно и готово к выполнению по требованию. Он не должен быть представлен как монолитный сквозной процесс. Цепочка поставок не обязательно для ускорения выполнения, но для обеспечения согласованности и самостоятельной документации по нескольким итерациям.
Группа рабочей нагрузки отвечает за цепочку поставок, так как она связана с собственной рабочей нагрузкой.
Пример сценария
Компания Contoso Manufacturing разработала приложение на основе Java, которое используется для мониторинга и оптимизации производственных процессов. Рабочая нагрузка недавно перенесена в Azure и теперь работает в Azure Spring Apps, База данных Azure для MySQL и Центр Интернета вещей Azure.
Развертывание инфраструктуры с помощью кода
Используйте инфраструктуру как код (IaC) для определения повторяемых аспектов цепочки поставок, готовых к работе. Предпочитайте декларативные подходы по сравнению с императивными методами.
Декларативные технологии IaC разработаны с учетом автоматизации и повторного использования. Вы можете выгрузить развертывания инфраструктуры от отдельных лиц в средства и обеспечить согласованное качество.
С точки зрения инфраструктуры, при использовании меньшего количества вариантов технологий удаляет дисперсию в инструменте и упрощает обнаружение смещения конфигурации. Обслуживание также будет проще. Если вы выровняете варианты с существующим набором навыков команды, команда может легко принять их.
Задача Компании Contoso
- Локальная версия рабочей нагрузки использовала сочетание сценариев и инструкций вручную для сборки инфраструктуры и развертывания приложения в средах. В начале процесса миграции Azure команда внесла изменения в существующие императивные скрипты, чтобы нацелиться на новую платформу, чтобы они могли повторно использовать большую часть существующей базы кода автоматизации. Этот подход также был принят из-за отсутствия опыта работы с технологиями Azure и IaC, такими как Bicep.
- По мере прогресса миграции команда стала более знакомой с платформой, они убедились, что использование подхода IaC с Bicep будет лучшим решением в долгосрочной перспективе.
Применение подхода и результатов
- Не хватает знаний на месте, команда заключила контракт на работу для миграции и расширения сценариев автоматизации развертывания для рабочей нагрузки опытных подрядчиков, которые работали с командой разработчиков во время начальных этапов проекта, обеспечивая передачу знаний остальной части команды.
- Результирующая реализация Bicep обеспечивает более надежный, управляемый и эффективный способ подготовки инфраструктуры в Azure. Теперь код является более читаемым и поддерживающимся с большими средствами в VSCode. Это также полностью идемпотентно и упрощает управление состоянием, которое они никогда не смогли полностью выполнить с предыдущей или императивной версией.
Обрабатывать IaC так же, как код приложения
Следуйте рекомендациям по программному обеспечению для разработки и обслуживания IaC: модульная модерация, избегайте пользовательских или низкозначных абстракции и соблюдайте многоуровневый подход, чтобы отразить различные жизненные циклы. Формируйте базовые слои, в которых нижние слои остаются постоянными, а верхние слои изменяются по мере необходимости.
Артефакты развертывания, такие как двоичные файлы приложений, шаблоны IaC и параметры, являются частью области атаки. Применение гарантий, таких как управление секретами, управление доступом и другие принципы основы безопасности.
Артефакты испытывают тот же уровень инженерной строгости, что и код приложения. Управление качеством с помощью одноранговых проверок и тестирования дает уверенность в развертывании.
Многоуровневый подход упрощает обслуживание и создает границы, которые устанавливают четкие линии ответственности.
Добавление элементов управления безопасностью в артефакты помогает защитить систему во время процесса развертывания.
Задача Компании Contoso
- Команда проектов имела щедрый бюджет в начале усилий по миграции, поэтому они наняли очень опытных подрядчиков, которые доставлены с высоким качеством и в короткий период времени. Подрядчики использовали отдельный репозиторий для разработки, и этот репозиторий не был регулярно проверен для обеспечения безопасности, в то время как основной репозиторий кода приложения является.
- Команда готовится к выпуску крупного изменения решения, и код развертывания нуждается в значительных изменениях. Из-за нехватки ресурсов разработки последний пакет изменений выполняется двумя интернами. Когда один из старших разработчиков в команде вызывается, чтобы помочь интернам, он заметил несколько фиксаций в репозитории, которые не соответствуют стандартам разработки команды, включая секреты приложений, такие как ключи API, жестко закодированные в базе кода.
Применение подхода и результатов
- Команда решает переместить базу кода сборки и развертывания в тот же репозиторий, используемый для кода приложения, и начать применять тот же уровень инженерной строгости, что и другие области базы кода. Код будет передан в стандарты группы перед первой фиксацией, секреты приложений удаляются, а к ним применяются все остальные стандарты качества и инструменты команды.
- В результате команда обеспечила этот раздел базы кода при увеличении качества кода. Передвигаясь вперед, изменения в этой области базы кода будут соответствовать тем же стандартам и использовать те же средства, которые используются для основной базы кода приложения, включая проверки одноранговых кодов и автоматическое сканирование кода с помощью средств качества и безопасности.
Стандартизация развертываний в одном манифесте
Разработка общего манифеста развертывания, используемого во всех средах. Используйте этот манифест в качестве механизма по умолчанию для проектов greenfield, добавочных обновлений рабочей нагрузки или аварийного восстановления.
Применение этого подхода позволит удалить затраты на обслуживание нескольких ресурсов.
Если произошла авария, восстановление будет быстрым и надежным, так как можно развернуть пробный и проверенный манифест вместо создания импровизированной среды.
Задача Компании Contoso
- Contoso Manufacturing использует полностью автоматизированный конвейер для развертывания инфраструктуры, кода приложения и изменения конфигурации в среде разработки и рабочей среды. Приложение настроено для высокой доступности в одном регионе. Большинство компонентов приложения являются бессерверными, за исключением базы данных MySQL. База данных выполняет резервное копирование в зависимости от установленного RTO/RPO, а резервная копия реплицируется в дополнительный регион.
- Если в основном регионе возникает серьезный или катастрофический сбой, команда планирует создать новую среду для размещения приложения в дополнительном регионе. Во время запланированной детализации для тестирования процедур аварийного восстановления скрипты развертывания завершаются ошибкой при попытке воссоздать среду в дополнительном регионе из-за отсутствия доступности нескольких ресурсов и других ограничений службы.
Применение подхода и результатов
- Команда устраняет проблемы, с которыми они столкнулись при попытке подготовить в дополнительном регионе, заменив использование некоторых ресурсов эквивалентными номерами SKU, доступными в обоих регионах и делая некоторые параметры настраиваемыми, но допустимыми, значение можно использовать в дополнительном регионе.
- Это упражнение повысило уверенность команды в их способности восстановиться после крупных сбоев инфраструктуры.