Рекомендации по безопасному развертыванию

Статья
11/15/2023

Применяется к этой контрольной рекомендации по операционному превосходству в Azure Well-Architected Framework:

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

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

Основные стратегии проектирования

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

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

В следующих разделах приведены подробные рекомендации по каждому из этих пунктов.

Обеспечение безопасности и согласованности развертываний

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

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

Внедрение прогрессивной модели воздействия

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

Другая распространенная модель развертывания — это синий зеленый подход. В этой модели развертываются два идентичных набора или пулов инфраструктуры рабочей нагрузки. Оба пула могут обрабатывать полную рабочую нагрузку. Первый (синий) пул запускает текущую версию развертывания, где находятся все пользователи. Второй (зеленый) пул обновляется с помощью новой функции и внутреннего тестирования. После внутреннего тестирования подмножество рабочего трафика направляется из синего пула в зеленый пул. Как и в случае с канарными развертываниями, развертывание постепенно выполняется по мере перемещения трафика в зеленый пул в последовательно больших волнах развертывания. После завершения развертывания пул обновлений становится синим и зеленый пул готов к следующему развертыванию. Два пула логически отделены друг от друга для защиты от сбоев. Вы можете развернуть вариант сине-зеленой модели в рабочей нагрузке, которая использует шаблон конструктора меток развертывания, развернув по одной метке одновременно.

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

Разработка надежных моделей работоспособности рабочей нагрузки

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

Реализация механизмов обнаружения сбоев

Если развертывание вызывает проблему в одной из групп развертывания, развертывание должно немедленно остановиться. Расследование причины проблемы и серьезности последствий должно выполняться сразу после получения оповещения. Восстановление из проблемы может включать:

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

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

Создание протоколов для развертываний в чрезвычайных ситуациях

Реализуйте управление версиями в артефактах сборки, чтобы обеспечить откат и откат при необходимости.
Используйте поток выпуска или структуру ветвления на основе магистралей, которая обеспечивает тесно синхронизированную совместную работу в команде разработчиков, а не структуру ветвления на основе среды или Gitflow.
Автоматизируйте максимальное количество SDP. Подробные рекомендации по автоматизации IaC и непрерывной интеграции приложений и непрерывной доставки (CI/CD) см . в рекомендациях по реализации автоматизации.
Используйте методики CI для регулярной интеграции изменений кода в репозитории. Методы CI помогут выявить конфликты интеграции и снизить вероятность крупных, рискованных слияний. Дополнительные сведения см. в руководстве по непрерывной интеграции.
Используйте флаги компонентов для выборочного включения или отключения новых функций или изменений в рабочей среде. Флаги функций помогут вам управлять воздействием нового кода и быстро откатить развертывание при возникновении проблем.
Разверните изменения в промежуточных средах, которые отражают рабочую среду. Среды практики позволяют протестировать изменения в управляемом параметре перед развертыванием в динамической среде.
Установите проверки предварительного развертывания, включая проверку кода, проверки безопасности и проверки соответствия требованиям, чтобы обеспечить безопасность развертывания изменений.
Реализуйте выключатели для автоматического остановки трафика в службу, в которой возникают проблемы. Это может помочь предотвратить дальнейшее ухудшение состояния системы.

Протоколы SDP для аварийного реагирования

Установите предписные протоколы, определяющие способ настройки SDP для исправления или для чрезвычайных проблем, таких как нарушение безопасности или уязвимость. Например, протоколы SDP для экстренного реагирования могут включать:

Ускорение этапа продвижения и утверждения.
Ускорение тестирования дыма и интеграции.
Сокращение времени выпечки.

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

Упрощение функций Azure

Azure Pipelines и GitHub Actions поддерживают многоэтапные развертывания с помощью шлюзов утверждения, которые помогут вам разработать прогрессивное развертывание для развертываний.
Используйте промежуточные слоты службы приложение Azure, чтобы легко переключаться между версиями кода. Промежуточные слоты полезны для тестирования в промежуточных средах и могут использоваться для развертывания синим зеленым цветом.
Храните флаги функций веб-приложения и управляйте ими в Конфигурация приложений Azure. С помощью этой службы можно создавать, изменять и развертывать функции в единой плоскости управления.
Развертывание приложений рабочей нагрузки на виртуальной машине с помощью приложений виртуальных машин.
Используйте подсистемы балансировки нагрузки Azure для реализации стратегий развертывания и предоставления работоспособности приложений рабочей нагрузки с помощью собственных ресурсов.
Используйте расширение "Работоспособности приложений", чтобы сообщить о работоспособности приложений из экземпляра масштабируемого набора виртуальных машин. Расширение проверяет конечную точку локального приложения и обновляет состояние работоспособности на основе ответов TCP/HTTP(S), полученных от приложения.
Используйте Azure Logic Apps для создания новой версии приложения при каждом обновлении. Azure поддерживает журнал версий приложений и может вернуть или повысить уровень до любой предыдущей версии.
Многие службы базы данных Azure предоставляют функции восстановления на определенный момент времени, которые помогут вам откатить. К службам, поддерживающим восстановление на определенный момент времени, относятся:

Пример

Пример использования этой модели развертывания см. в руководстве по архитектуре кластеров Служба Azure Kubernetes (AKS).

Ссылки на ресурсы сообщества

Контрольный список операционных знаний

Ознакомьтесь с полным набором рекомендаций.