Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

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

Обзор [ править ]

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

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

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

Типы подходов [ править ]

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

Методы [ править ]

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

Инструменты [ править ]

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

Автоматизация непрерывной конфигурации [ править ]

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

Контент сообщества [ править ]

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

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

Другие инструменты включают AWS CloudFormation , cdist , StackStorm , Juju и 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. ^ Бауэр, Джозеф L .; Кристенсен, Клейтон М. «Прорывные технологии: ловя волну». Harvard Business Review .
  3. ^ a b c Флетчер, Колин; Косгроув, Терренс (26 августа 2015 г.). Инновации в средствах автоматизации непрерывного конфигурирования . Gartner (Отчет).
  4. Райли, Крис (12 ноября 2015 г.). «Версия вашей инфраструктуры» . DevOps.com .
  5. Филлипс, Эндрю (14 мая 2015 г.). «Переход от автоматизации инфраструктуры к истинному DevOps» . DevOps.com .
  6. ^ "Декларативные против императивных моделей для управления конфигурацией: что на самом деле лучше?" . Scriptrock.com . Проверено 14 декабря 2015 года .
  7. ^ Loschwitz, Мартин (14 ноября 2014). «Выбор между ведущими менеджерами конфигурации с открытым исходным кодом» . Сеть администрирования и безопасность . Лоуренс, Канзас США: Linux New Media USA LLC.
  8. Рианна Венеция, Пол (21 ноября 2013 г.). «Марионетка против шеф-повара против Ансибля против соли» . networkworld.com . Сетевой мир . Проверено 14 декабря 2015 года .
  9. ^ Тенденции рынка Garner: DevOps - не рынок, а философия, ориентированная на инструменты, которая поддерживает цепочку создания стоимости непрерывной доставки (отчет). Gartner. 18 февраля 2015.
  10. ^ a b Чаганти, Равикантх (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. Sturgeon, Phil (28 октября 2012 г.). "Марионетка или повар?" .
  13. Рианна Рамос, Мартин (4 ноября 2015 г.). «Непрерывная интеграция: инфраструктура как код в DevOps» . easydynamics.com . Архивировано из оригинала на 6 февраля 2016 года . Проверено 29 января +2016 .
  14. ^ Инфраструктура как код: разжигание огня для более быстрой доставки приложений (отчет). Форрестер. Март 2015 г.
  15. ^ Wurster, Лори Ф .; Колвилл, Ронни Дж .; Рост, Кэмерон; Трипати, Сомендра; Растоги, Адити. Анализ новых технологий: DevOps - это культурный сдвиг, а не технология (отчет). Gartner.
  16. ^ «Отчет об угрозах облака показывает необходимость согласованного DevSecOps» . Информационная неделя . Проверено 24 февраля 2020 года .