Модульное управление шаблонами Azure Resource Manager (шаблонами ARM) позволяет сократить повторение, рекомендации по модели в разработке инфраструктуры и обеспечить согласованные стандартные развертывания.
Пример использования для реализации такого типа модульного модуля — развертывание виртуальных машин (виртуальных машин) с помощью метафоры размеров футболки. Предположим, что вы развернули десятки или сотни виртуальных машин. Эти развертывания используют шаблоны версии 1.0.0 и имеют стандартный средний размер более старой серии. Чтобы перейти к новой серии, может потребоваться краткое сбой службы, если вы просто развернули новые шаблоны. Однако, создав версию 1.5.0 и используя модульную структуру, можно развернуть новую инфраструктуру с обновленным стандартом, сохраняя старую инфраструктуру в развертываемом состоянии. При наличии старых версий инфраструктуры в группах продуктов и приложений есть известная хорошая конфигурация, которую следует использовать при обновлении до новой версии, так как у них есть время.
Слоеный торт репозиториев: пример для предприятий
Когда дело доходит до того, почему вам может потребоваться иметь сильные предпочтения в отношении того, где шаблоны идут, как они обновляются, и т. д., есть два основных соображения: ветвление и внутренний источник.
Ветвления. Этот пример сценария упрощает модели ветвления Git, поддерживающие поток Gitflow и GitHub. Дополнительные сведения о Gitflow см. в статье "Использование потока git" для автоматизации рабочего процесса ветвления Git, записи блога Джеффа Крефтмейджера. Дополнительные сведения о потоке GitHub см . в документации по GitHub.
Внутренний выбор. Во-вторых, внутренний источник, который приносит совместные методики разработки программного обеспечения с открытым исходным кодом для разработки внутри организации. В таком сценарии вы можете более уверенно предоставлять доступ к разным шаблонам и исходному коду модуля без необходимости беспокоиться о разрешениях для самих моделей развертывания. Дополнительные сведения о разработке внутреннего источника см. в статье "Введение в внутренний источник " на сайте GitHub.
Bicep — это декларативный язык для развертывания ресурсов Azure. Повторно используемый код Bicep может использовать Реестр контейнеров Azure в качестве частного реестра для размещения версий шаблонов ARM. Таким образом, используя реестр контейнеров, ваше предприятие может иметь процесс непрерывной интеграции и непрерывной доставки (CI/CD) для инфраструктуры. Интеграция и модульные тесты можно запускать в процессе CI, а реестр контейнеров может получать модули после успешного построения. Команды приложений могут продолжать использовать старые версии до тех пор, пока они не будут готовы к обновлению, или они могут обновить, чтобы воспользоваться преимуществами функций в более новых версиях шаблонов.
Помимо использования реестра контейнеров, вы можете объединить эту модель с такими же, как проверенные модули Azure. Реализация может использовать из общедоступного реестра или предпочтительнее отслеживать общедоступные репозитории и извлекать изменения в частный реестр для дальнейшего использования. Вытягивание изменений в собственный реестр контейнеров позволяет выполнять тесты с общедоступными модулями, гарантируя, что они не используются в рабочей среде, пока не будут включены методы обеспечения качества и безопасности.
Слои
Модель, предлагаемая в этом примере сценария, — это модель, которая стеков. Уровни ближе к верхней части стека имеют более частые развертывания и развертывания, которые являются более распространенными. Код Bicep предоставляет согласованные развертывания. Команды разработчиков, работающие на уровнях для их вкладов, создаются из служб и инфраструктуры, предоставляемых в приведенных ниже уровнях. Ничто в нижнем слое не должно полагаться на ресурсы выше. От уровня 0 до 3 являются глобальной библиотекой, глобальной инфраструктурой (глобально общими службами), платформой продуктов (общими службами) и приложениями.
Эта модель создает автономию с выравниванием, что означает наличие:
Распространенные инструменты для простоты предприятия. Например, все используют git для управления версиями, и все используют GitHub Actions для CI/CD. Тем не менее, мы не перенастраиваем. Например, мы не требуем, чтобы все команды использовали Bicep; они могут использовать Terraform, шаблоны ARM и другие средства.
Возможность совместного использования рекомендаций. Они могут принимать форму шаблонов ARM, золотых изображений или фрагментов кода. Рекомендации также могут быть документацией по конкретным методам. Например, как повернуть ключи в среде и как протестировать код.
Некоторые службы перемещаются вниз в стеке. Например, команда приложений может первоначально разработать шаблон для развертывания кластера Kubernetes, который позже извлекается на платформу продукта в качестве общей службы. Этот шаблон становится настолько полезным, что он будет извлечен в библиотеку примеров.
Уровень 0 — глобальная библиотека
Нижний уровень — это глобальная библиотека, которая является репозиторием полезных тидбитов, которые не развертываются в рабочей среде. С точки зрения контроля доступа доступ на чтение должен предоставляться любому пользователю в компании, которая запрашивает его. Для изменений, предложений и т. д. Ваш Облачный центр превосходства (CCoE) утверждает PR и управляет невыполненной работой, как если бы это был любой другой продукт.
Уровень 0 не должен содержать:
- Шаблоны, развернутые в рабочей среде.
- Секреты или конфигурации, относящиеся к среде.
Уровень 0 должен содержать:
- Фрагменты кода (в Python, C#и т. д.).
- Политика Azure примеры.
- Шаблоны ARM, шаблоны Bicep или файлы Terraform, которые можно использовать в качестве примеров.
Примером этой архитектуры является создание развертывания для трехуровневого приложения без каких-либо сведений о среде. Этот пример архитектуры может включать теги, сети, группы безопасности сети и т. д. Выход из определенной информации для среды полезен, так как не все может быть или должно быть помещено в модуль. Попытка сделать это может привести к чрезмерной параметризации.
Кроме того, уровень 0 может связаться с другими известными хорошими источниками примера кода, такими как реестр Terraform или модули ресурсов Azure). Если ваша организация принимает код или шаблон из любого из этих источников, рекомендуется извлечь код или шаблон в собственный уровень 0 вместо извлечения непосредственно из общедоступных источников. Опираясь на уровень 0, вы можете написать собственные тесты, настройки настройки и конфигурации безопасности. Не опираясь на общедоступные источники, вы снижаете риск полагаться на то, что может быть неожиданно удалено.
Чтобы рассматривать хороший пример кода, шаблоны и модули должны соответствовать рекомендациям по разработке, включая проверку входных данных для безопасности и требований организации. Чтобы сохранить этот уровень строгости, следует добавить политики в основную ветвь, чтобы требовать запросы на вытягивание (PR) и проверки кода для предлагаемых изменений, которые привели бы к изменениям, поступающим в основной реестр контейнеров при слиянии.
Каналы уровня 0 в Azure Pipelines или GitHub Actions для автоматического создания версий артефактов в Реестр контейнеров Azure. Вы можете создать автоматизацию для сообщений фиксации Git для реализации семантического управления версиями артефактов. Для правильной работы необходимо иметь детерминированный стандарт именования, например <service.bicep>, чтобы обеспечить поддержку автоматизации с течением времени. С помощью соответствующих политик ветви можно также добавить тесты интеграции в качестве необходимых условий для проверки кода. Это можно инструментирование с помощью таких инструментов, как Пестер.
При наличии таких политик и защиты реестр контейнеров может быть источником истины для всех модулей инфраструктуры в организации, готовых к использованию. Следует рассмотреть возможность стандартизации журналов изменений, а также индексов доступных примеров кода, чтобы обеспечить возможность обнаружения этого кода. Неизвестный код неиспользуемый!
Уровень 1 — глобальная инфраструктура: глобальные общие службы
Уровень 1 — это репозиторий для конструкций целевой зоны Azure. Хотя корпорация Майкрософт предоставляет шаблоны для развертывания целевых зон Azure, необходимо изменить определенные компоненты и предоставить файл параметров. Это аналогично тому, как вы извлеките общедоступный реестр и репозитории модулей в слой 0, как описано ранее.
Реестр контейнеров Azure является важной частью этой архитектуры. Даже если у вашей компании нет планов использовать контейнеры, необходимо развернуть реестр контейнеров для успешного управления версиями шаблонов Bicep. Реестр контейнеров обеспечивает значительную гибкость и возможность повторного использования для модулей, обеспечивая безопасность и управление доступом корпоративного уровня.
Уровень 1 должен содержать следующее:
- Назначения и определения политик, применяемые на уровне группы управления или подписки. Эти политики должны соответствовать вашим требованиям к корпоративному управлению.
- Шаблоны основной сетевой инфраструктуры, такие как ExpressRoute, виртуальные сети, виртуальная глобальная сеть и виртуальные сети (общие или концентраторы).
- DNS.
- Основной мониторинг (log analytics).
- Корпоративный реестр контейнеров.
Необходимо настроить защиту ветви, чтобы ограничить возможность принудительного отправки изменений в этот репозиторий. Ограничьте утверждение PR от других разработчиков членами CCoE или Cloud Governance. Участники этого слоя являются главным образом членами групп, которые исторически связаны с компонентами этого слоя. Например, группа сетей создает шаблоны для сети, группу операций настраивает мониторинг и т. д. Однако вы должны предоставить доступ только для чтения пользователям, запрашивающим его, так как вы хотите разрешить разработчикам из других групп предлагать изменения в основных инфраструктурах. Они могут способствовать улучшению, хотя вы не сможете объединить свои изменения без утверждения и тестирования.
Эти файлы должны использовать модули в реестре контейнеров для стандартных компонентов. Однако у вас также будет файл Bicep или ряд файлов Bicep, настроенных для реализации целевых зон Azure или аналогичной структуры управления.
Уровень 2 — платформа продукта: общие службы
Вы можете рассмотреть уровень 2, платформу продуктов в качестве общих служб для определенной линии продукта или бизнес-подразделения. Эти компоненты не являются универсальными для всей организации, но они предназначены для соответствия определенной бизнес-потребности. Это будет подходящий уровень для виртуальной сети, которая является одноранговым элементом с концентратором в глобальной инфраструктуре уровня 1. Хранилище ключей является еще одним примером компонента для этого слоя. Хранилище ключей может хранить общие секреты в учетной записи хранения или базе данных, к которой используются различные приложения в этой платформе.
Уровень 2 должен содержать:
- Назначения политик, которые применяются в подписке или группе ресурсов для соответствия требованиям к продукту.
- Шаблоны ARM для хранилищ ключей, log analytics, база данных SQL (если различные приложения в продукте используют базу данных) и Служба Azure Kubernetes.
Необходимо реализовать разрешения, ограничивающие возможность принудительного отправки изменений в этот репозиторий. Как и другие уровни, следует использовать защиту ветви, чтобы убедиться, что руководитель продукта или владелец может утвердить PR от других разработчиков. Нет фиксированных правил для доступа на чтение к платформе продукта, но как минимум разработчикам из любой из команд приложений необходимо предоставить доступ на чтение, чтобы иметь возможность предлагать изменения. Так как уровень 2 может содержать некоторую собственную архитектуру или аналогичную информацию, вы можете ограничить доступ к тем, кто использует платформу. Однако если это так, вы хотите убедиться, что вы создадите процесс сбора рекомендаций и фрагментов из этого репозитория для совместного использования с глобальной библиотекой уровня 0.
Уровень 3 . Приложение
Уровень 3, уровень приложения, включает компоненты, созданные на основе платформы продукта. Эти компоненты предоставляют функции, которые запрашивают бизнес-запросы. Например, для платформы потоковой передачи одно приложение может предоставить функцию поиска, а другое приложение предоставляет рекомендации.
Уровень 3 должен содержать следующее:
- Код приложения в C#, Python и т. д.
- Инфраструктура для отдельных компонентов (которая используется только в этом приложении): функции, Экземпляры контейнеров Azure, Центры событий.
Разрешения ограничены для отправки изменений в этот репозиторий. Следует использовать защиту ветви, чтобы разрешить участнику команды этого приложения утвердить pr, сделанный другим участником команды. Члены команды не должны утверждать свои собственные изменения. Так как этот уровень может содержать частную архитектуру, бизнес-логику или аналогичную информацию, вы можете ограничить доступ к тем, кто создает это приложение. Однако если это так, необходимо также создать процесс сбора рекомендаций и фрагментов из этого слоя для совместного использования с глобальной библиотекой уровня 0.
Общие особенности между слоями
Хотя в этой статье описываются некоторые конкретные сведения для каждого слоя, существуют также некоторые качества для всех слоев, которые следует учитывать.
Ваша инфраструктура должна работать так, как если бы это приложение. Это означает, что у вас должен быть процесс непрерывной интеграции (CI), в котором новые функции тестируются полностью, с модульными тестами, тестами дыма и тестами интеграции. Необходимо объединить только код, который передает эти тесты в основную ветвь выпуска.
Кроме того, следует убедиться, что у вас есть политики филиалов, чтобы запретить отдельным лицам обойти этот процесс, даже если это возможно. Если процесс CI рассматривается как препятствие, это означает, что у вас есть технический долг, с которыми необходимо справиться. Это не означает, что необходимо удалить политики и защиту.
Наконец, хотя у вас может не быть индекса всех репозиториев и кода в них, ваша организация должна разработать процесс для отдельных лиц, чтобы запросить доступ к репозиториям. Некоторые правила могут быть полностью автоматизированы. Например, можно реализовать правило, которое предоставляет доступ на чтение без проверки, участник, который находится в команде продуктов для любого приложения в этом продукте. Такие правила часто можно реализовать с членством в группах и назначениями ролей на основе групп в средах. Настройка такого рода доступа должна помочь упростить внутренний выбор и знания организации.
Соавторы
Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участник.
Основные авторы:
- Тим Салливан | Старший архитектор облачных решений
Другие участник:
- Гэри Мур | Программист или писатель
Следующие шаги
- Область разработки: автоматизация платформы и DevOps
- Зрелые структуры команд
- Что такое "Инфраструктура как код"?
- Azure/ResourceModules: этот репозиторий включает платформу CI для и коллекцию зрелых и курированных модулей Bicep. Платформа поддерживает Как Azure Resource Manager, так и Bicep, и ее функции можно использовать с действиями GitHub и Azure Pipelines.
- Создание частного реестра для модуля Bicep