WikiDer > Инфраструктура как код

Infrastructure as code

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

Обзор

IaC вырос в ответ на трудности, связанные с служебные вычисления и веб-фреймворки второго поколения. В 2006 году запуск Веб-сервисы AmazonЭластичное вычислительное облако и версия 1.0 Рубин на рельсах всего за несколько месяцев до[2] создавал на предприятии широко распространенные проблемы масштабирования, которые ранее возникали только в крупных многонациональных компаниях.[3] Идея IaC родилась с появлением новых инструментов для работы в этой постоянно растущей области. Мысль о моделировании инфраструктуры с помощью кода, а затем о возможности проектирования, реализации и развертывания инфраструктуры приложений с использованием известных передовых методов работы с программным обеспечением привлекла как разработчиков программного обеспечения, так и администраторов ИТ-инфраструктуры. Возможность обрабатывать инфраструктуру как код и использовать те же инструменты, что и любой другой программный проект, позволит разработчикам быстро развертывать приложения.[4]

Добавленная стоимость и преимущества

Ценность IaC можно разделить на три измеримые категории: стоимость, скорость и риск.[нужна цитата] Снижение затрат направлено на то, чтобы помочь предприятию не только финансово, но и с точки зрения людей и усилий, а это означает, что, удалив ручной компонент, люди могут переориентировать свои усилия на другие задачи предприятия.[нужна цитата] Автоматизация инфраструктуры обеспечивает ускорение за счет более быстрого выполнения при настройке инфраструктуры и нацелена на обеспечение прозрачности, чтобы помочь другим командам в рамках предприятия работать быстрее и эффективнее. Автоматизация устраняет риск, связанный с человеческой ошибкой, такой как неправильная настройка вручную; удаление этого может сократить время простоя и повысить надежность. Эти результаты и атрибуты помогают предприятию продвигаться к внедрению культуры DevOps, комбинированная работа разработка и операции.[5]

Типы подходов

Обычно есть два подхода к IaC: декларативный (функциональный) vs. императив (процедурный). Разница между декларативным и императивным подходами по сути 'Какие' против 'как' . Декларативный подход фокусируется на том, какой должна быть конечная целевая конфигурация; то императив сосредотачивается на том, как инфраструктура должна быть изменена, чтобы соответствовать этому.[6] Декларативный подход определяет желаемое состояние, и система выполняет то, что должно произойти для достижения этого желаемого состояния. Императив определяет конкретные команды, которые необходимо выполнить в соответствующем порядке, чтобы получить желаемый результат. [7]

Методы

Есть два метода IaC: 'толкать' и 'тянуть' . Основное различие заключается в способе настройки серверов. В методе извлечения настраиваемый сервер извлекает свою конфигурацию с управляющего сервера. В методе push управляющий сервер отправляет конфигурацию в целевую систему.[8]

Инструменты

Есть много инструментов, которые реализуют возможности автоматизации инфраструктуры и используют IaC. В общих чертах, любой фреймворк или инструмент, который выполняет изменения или конфигурирует инфраструктуру декларативно или императивно на основе программного подхода, можно рассматривать как IaC.[9] Традиционно для реализации IaC использовались средства автоматизации сервера (жизненного цикла) и управления конфигурацией. Теперь предприятия также используют инструменты автоматизации непрерывной настройки или автономные инфраструктуры IaC, такие как Microsoft PowerShell DSC.[10] или же AWS CloudFormation.[11]

Автоматизация непрерывной настройки

Все автоматизация непрерывной конфигурации (CCA) инструменты можно рассматривать как расширение традиционных фреймворков IaC. Они используют IaC для изменения, настройки и автоматизации инфраструктуры, а также обеспечивают прозрачность, эффективность и гибкость в управлении инфраструктурой.[3] Эти дополнительные атрибуты обеспечивают безопасность и соответствие требованиям на уровне предприятия.

Контент сообщества

Важным аспектом при рассмотрении инструментов CCA, если они имеют открытый исходный код, является контент сообщества. В качестве Gartner утверждает, что ценность инструментов CCA «зависит от контента и поддержки, предоставляемых сообществом пользователей, так же как и от коммерческой зрелости и производительности инструментов автоматизации».[3] Продавцы любят Кукольный и Повар, те, кто существует довольно долго, создали свои собственные сообщества. Шеф-повар Репозиторий сообщества Chef и Puppet имеет PuppetForge.[12] Другие поставщики полагаются на соседние сообщества и используют другие инфраструктуры IaC, такие как PowerShell DSC.[10] Появляются новые поставщики, которые ориентируются не на контент, а на модели, использующие интеллектуальные возможности продукта для доставки контента. Эти визуальные объектно-ориентированные системы хорошо работают для разработчиков, но они особенно полезны для производственно-ориентированных DevOps и компонентов операций, которые ценят модели, а не сценарии для контента. По мере того, как область продолжает развиваться и меняться, контент на основе сообщества будет становиться все более важным для того, как используются инструменты IaC, если только они не ориентированы на модели и не ориентированы на объекты.

Известные инструменты CCA включают:

ИнструментВыпущеноМетодПодходНаписано вКомментарии
ПоварПовар (2009)ТянутьДекларативный и императивныйРубин-
ВыдраИнедоТолкатьДекларативный и императивный-Ориентированный на Windows
КукольныйМарионетка (2005)ТянутьДекларативный и императивныйC ++ & Clojure с 4.0, Рубин-
SaltStackSaltStackТолкай и тяниДекларативный и императивныйPython-
CFEngineNorthern.techТянутьДекларативнаяC-
TerraformHashiCorp (2014)ТолкатьДекларативнаяИдти-
Ansible / Ансибл ТауэрКрасная шляпа (2012)ТолкатьДекларативный и императивныйPython-

Другие инструменты включают AWS CloudFormation, cdist, StackStorm, Жужу, и Pulumi.

Отношение к DevOps

IaC может быть ключевым атрибутом внедрения передовых практик в DevOps - Разработчики более активно участвуют в определении конфигурации, а оперативные группы раньше вовлекаются в процесс разработки.[13] Инструменты, использующие IaC, обеспечивают видимость состояния и конфигурации серверов и, в конечном итоге, обеспечивают видимость для пользователей внутри предприятия, стремясь объединить команды для максимизации их усилий.[14] Автоматизация в целом направлена ​​на устранение путаницы и подверженности ошибкам аспектов ручных процессов, чтобы сделать их более эффективными и продуктивными. Обеспечение гибкости создания более совершенного программного обеспечения и приложений с меньшим временем простоя и в целом рентабельным способом для компании. IaC предназначен для уменьшения сложности, которая снижает эффективность ручной настройки. Автоматизация и совместная работа считаются центральными элементами DevOps; Инструменты автоматизации инфраструктуры часто входят в состав Набор инструментов DevOps.[15]

Отношение к безопасности

Отчет об угрозах в облаке за 2020 год, выпущенный Unit 42 (подразделение анализа угроз поставщика кибербезопасности). Palo Alto Networks) выявил около 200 000 потенциальных уязвимостей в инфраструктуре в виде шаблонов кода.[16]

Смотрите также

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

  1. ^ Виттиг, Андреас; Виттиг, Майкл (2016). Amazon Web Services в действии. Manning Press. п. 93. ISBN 978-1-61729-288-0.
  2. ^ Бауэр, Джозеф Л .; Кристенсен, Клейтон М. "Подрывные технологии: ловя волну". Harvard Business Review.
  3. ^ а б c Флетчер, Колин; Косгроув, Терренс (26 августа 2015 г.). Инновации в средствах автоматизации непрерывного конфигурирования. Gartner (Отчет).
  4. ^ Райли, Крис (12 ноября 2015 г.). "Версия вашей инфраструктуры". DevOps.com.
  5. ^ Филлипс, Эндрю (14 мая 2015 г.). «Переход от автоматизации инфраструктуры к истинному DevOps». DevOps.com.
  6. ^ «Декларативные против императивных моделей управления конфигурацией: что на самом деле лучше?». Scriptrock.com. Получено 14 декабря 2015.
  7. ^ Лошвиц, Мартин (14 ноября 2014 г.). «Выбор между ведущими менеджерами конфигурации с открытым исходным кодом». Сеть администрирования и безопасность. Лоуренс, Канзас США: Linux New Media USA LLC.
  8. ^ Венеция, Пол (21 ноября 2013 г.). «Марионетка против шеф-повара против Ансибля против соли». networkworld.com. Сетевой мир. Получено 14 декабря 2015.
  9. ^ Тенденции рынка Garner: DevOps - не рынок, а философия, ориентированная на инструменты, которая поддерживает цепочку создания стоимости непрерывной доставки (отчет). Gartner. 18 февраля 2015 г.
  10. ^ а б Чаганти, Равикантх (5 января 2016 г.). «DevOps, инфраструктура как код и PowerShell DSC: введение». Журнал PowerShell. Журнал PowerShell. Получено 11 января 2016.
  11. ^ https://aws.amazon.com/about-aws/whats-new/2011/02/25/introduction-aws-cloudformation/
  12. ^ Осетр, Фил (28 октября 2012 г.). "Марионетка или повар?".
  13. ^ Рамос, Мартин (4 ноября 2015 г.). «Непрерывная интеграция: инфраструктура как код в DevOps». easydynamics.com. Архивировано из оригинал 6 февраля 2016 г.. Получено 29 января 2016.
  14. ^ Инфраструктура как код: разжигание огня для более быстрой доставки приложений (отчет). Форрестер. Март 2015 г.
  15. ^ Wurster, Laurie F .; Колвилл, Ронни Дж .; Рост, Кэмерон; Трипати, Сомендра; Растоги, Адити. Анализ новых технологий: DevOps - это культурный сдвиг, а не технология (отчет). Gartner.
  16. ^ «Отчет об облачных угрозах указывает на необходимость последовательной разработки DevSecOps». Информационная неделя. Получено 24 февраля 2020.