Поделиться через

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

  • Статья

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

OE:05 Подготовьте ресурсы и их конфигурации с помощью стандартизованного подхода "инфраструктура как код" (IaC). Как и в случае с другим кодом, проектируйте IaC с согласованными стилями, соответствующей модульной структурой и обеспечением качества. По возможности предпочитайте декларативный подход.

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

Определения

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

Ключевые стратегии проектирования

Как описано в руководствах по цепочке поставок и стандартизации средств и процессов , необходимо иметь строгую политику развертывания изменений инфраструктуры (включая изменения конфигурации) только с помощью кода. IaC следует развертывать с помощью конвейеров непрерывной интеграции и непрерывной поставки (CI/CD). Внедрение этих политик обеспечивает согласованность процессов для всех развертываний IaC, минимизирует риск смещения конфигурации в средах и обеспечивает согласованность инфраструктуры в средах. Кроме того, следует стандартизировать средства и процессы разработки и развертывания IaC в руководстве по стилю. Рекомендации для руководства по стилю:

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

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

Примечание

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

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

Аналогичным образом для применения требуемой конфигурации состояния (DSC) для различных типов инфраструктуры могут потребоваться разные средства. Например, существуют специальные средства, такие как Ansible для управления DSC для виртуальных машин, тогда как Flux — это хороший инструмент для управления DSC в кластерах Kubernetes. Службы PaaS (платформа как услуга) могут предоставлять различные средства для управления конфигурацией (например, Конфигурация приложений Azure), которые можно обрабатывать с помощью IaC. Службы SaaS (программное обеспечение как услуга) могут быть более ограничены, так как они более жестко контролируются платформой.

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

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

Примечание

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

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

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

Задокументируйте стандарты для обработки потерянных ресурсов. В зависимости от средств, используемых для управления конфигурацией, и их ограничений, могут возникнуть случаи, когда определенный ресурс больше не требуется для вашей рабочей нагрузки и средства IaC не могут автоматически удалить ресурс. Например, предположим, что вы переходите с виртуальных машин на службу PaaS для какой-то функции, а инструменты IaC не имеют логики для удаления устаревших ресурсов. Эти ресурсы могут стать потерянными, если команда рабочей нагрузки не помнит удалить их вручную. Для обработки этих сценариев стандартизируйте стратегию поиска потерянных ресурсов и их удаления. Кроме того, необходимо подумать о том, как обеспечить актуальность шаблонов. Изучите ограничения инструментов IaC, чтобы понять, что может потребоваться спланировать в таких ситуациях.

Другие стратегии IaC

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

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

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

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

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

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

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

Изменяемая и неизменяемая инфраструктура

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

Рекомендации

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

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

Увеличенное время для изменений конфигурации: Развертывание инфраструктуры с помощью инструкций командной строки или непосредственно на портале не требует времени написания кода и (или) тестирования артефактов. Сократите время развертывания, следуя рекомендациям, таким как проверки кода и методы контроля качества.

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

Упрощение azure

Шаблоны azure Resource Manager (шаблоны ARM) и Bicep — это собственные средства Azure для развертывания инфраструктуры с помощью декларативного синтаксиса. Шаблоны ARM написаны на языке JSON, а Bicep — это язык, зависящий от предметной области. Их можно легко интегрировать в конвейеры Azure или GitHub Actions конвейеры CI/CD.

Terraform — это еще одно декларативное средство IaC, которое полностью поддерживается в Azure. Его можно использовать для развертывания инфраструктуры и управления ими, а также для интеграции в конвейер CI/CD.

Для обнаружения неправильных конфигураций в IaC можно использовать Microsoft Defender для облака.

Пример

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

Контрольный список эффективности операций

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

Контрольный список эффективности операций