Шаблон DevOps

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

Контекст и проблема

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

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

Решение

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

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

Использование конвейера выпуска DevOps помогает:

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

Проблемы и рекомендации

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

• Доступны ли функции, конечные точки, службы и другие ресурсы в целевых местах развертывания?
• Хранятся ли артефакты конфигурации в местах, доступных между облаками?
• Будут ли параметры развертывания работать во всех целевых средах?
• Доступны ли свойства для конкретных ресурсов во всех целевых облаках?

Дополнительные сведения см. в статье Разработка шаблонов Azure Resource Manager для обеспечения согласованности облака.

Кроме того, при выборе способа реализации этого шаблона следует учитывать следующие моменты:

Масштабируемость

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

Наличие

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

• Цель времени восстановления (RTO) указывает, как долго можно обойтись без системы.

• Цель точки восстановления (RPO) указывает, сколько данных вы можете позволить себе потерять, если нарушение службы влияет на систему.

На практике RTO и RPO подразумевают избыточность и резервное копирование. В глобальном облаке Azure доступность не является вопросом аппаратного восстановления — это часть Azure, а скорее обеспечение поддержания состояния систем DevOps. В Azure Stack Hub может потребоваться восстановление оборудования.

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

Управляемость

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

Развертывание рабочих сред и сред разработки и тестирования в отдельных группах ресурсов в Azure или Azure Stack Hub. Затем можно следить за ресурсами каждой среды и объединить затраты на выставление счетов по группам ресурсов. Вы также можете удалить ресурсы как набор, который полезен для тестовых развертываний.

Когда следует использовать этот шаблон

Используйте этот шаблон, если:

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

Этот шаблон не рекомендуется:

• Если вы не можете автоматизировать задачи, связанные с инфраструктурой, выделением ресурсов, настройкой, управлением идентификацией и безопасностью.
• Если у команд нет доступа к гибридным облачным ресурсам для реализации подхода непрерывной интеграции и непрерывной разработки (CI/CD).

Дальнейшие действия

Дополнительные сведения о разделах, представленных в этой статье:

• Узнайте больше об Azure DevOps и связанных инструментах, включая Azure Repos и Azure Pipelines, в документации по Azure DevOps.
• Ознакомьтесь с семейством продуктов и решений Azure Stack, чтобы узнать больше о всем портфеле продуктов и решений.

Когда вы будете готовы протестировать пример решения, перейдите к руководству по развертыванию гибридного решения CI/CDDevOps. Руководство по развертыванию содержит пошаговые инструкции по развертыванию и тестированию компонентов. Вы узнаете, как развернуть приложение в Azure и Azure Stack Hub с помощью конвейера гибридной непрерывной интеграции и непрерывной доставки (CI/CD).