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

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

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

Определения

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

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

Предпочесть декларативный по сравнению с императивными инструментами

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

Использование собственных и отраслевых инструментов

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

Использование подходящего средства для задачи

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

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

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

Поддержка нескольких сред

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

Используйте правильный баланс при инкапсулирующей функциональности

Strategize and standardize on the use of modules. Как и параметры и переменные, модули могут повторять развертывания инфраструктуры. Будьте думая, однако, о том, как вы используете их. Стандартизованная стратегия абстракции помогает гарантировать, что модули создаются для удовлетворения конкретных согласованных целей. Инкапсулировать сложные конфигурации или сочетания ресурсов с помощью модулей. Избегайте модулей, если вы используете только конфигурацию ресурса по умолчанию. Кроме того, будьте разумны в разработке новых модулей. Используйте поддерживаемые модули с открытым кодом, если это необходимо, например, нечувствительные сценарии.

Инструкции по документу вручную

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

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

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

Использование многоуровневого подхода для конвейеров IaC

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

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

Обрабатывать код IaC и приложения одинаково

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

Использование централизованных стандартов и ресурсов

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

Принудительное обеспечение безопасности в коде IaC

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

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

Внедрение неизменяемой модели развертывания

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

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

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

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

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

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

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

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

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

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

Пример

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

Дополнительные ссылки

• Что такое инфраструктура как код (IaC)?
• Корпоративная инфраструктура в качестве кода с помощью Bicep и Реестр контейнеров Azure
• Обнаружение неправильных конфигураций в IaC
• Рекомендации по проектированию цепочки поставок разработки рабочей нагрузки
• Рекомендации по стандартизации средств и процессов
• Рекомендации по защите жизненного цикла разработки
• Рекомендации по использованию методов безопасного развертывания
• Шаблон меток развертывания
• шаблоны Azure Resource Manager (шаблоны ARM);
• Bicep
• Конвейеры Azure
• GitHub Actions
• Terraform

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

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