Инфраструктура как код
![]() | В этой статье есть несколько проблем. Пожалуйста, помогите улучшить его или обсудите эти проблемы на странице обсуждения . ( Узнайте, как и когда удалять эти шаблонные сообщения )
|
Инфраструктура как код ( IaC ) — это процесс управления и предоставления ресурсов компьютерного центра обработки данных с помощью машиночитаемых файлов определений, а не физической конфигурации оборудования или инструментов интерактивной настройки. [1] управляемая ИТ-инфраструктура, этим процессом, включает в себя как физическое оборудование, такое как серверы без ОС , так и виртуальные машины , а также соответствующие ресурсы конфигурации.Определения могут находиться в системе контроля версий , а не поддерживать код с помощью ручных процессов.Код в файлах определений может использовать либо сценарии, либо декларативные определения, но IaC чаще использует декларативные подходы.
Обзор [ править ]
IaC вырос как ответ на трудности, связанные с служебными вычислениями и веб-фреймворками второго поколения. В 2006 году запуск Amazon Web Services Elastic Compute Cloud и версии Ruby on Rails 1.0 всего за несколько месяцев до этого [2] создало на предприятии широко распространенные трудности масштабирования, с которыми раньше сталкивались только крупные транснациональные компании. [3] С появлением новых инструментов для работы в этой постоянно растущей области родилась идея IaC. Мысль о моделировании инфраструктуры с помощью кода, а затем о возможности проектирования, реализации и развертывания инфраструктуры приложений с использованием известных лучших практик программного обеспечения понравилась как разработчикам программного обеспечения, так и администраторам ИТ-инфраструктуры. Возможность рассматривать инфраструктуру как код и использовать те же инструменты, что и любой другой программный проект, позволит разработчикам быстро развертывать приложения. [4]
Преимущества [ править ]
Ценность IaC можно разбить на три измеримые категории: стоимость, скорость и риск. [ нужна ссылка ] Снижение затрат направлено на то, чтобы помочь предприятию не только финансово, но и с точки зрения людей и усилий. Это означает, что, устранив ручной компонент, люди могут переориентировать свои усилия на другие задачи предприятия. [ нужна ссылка ] Автоматизация инфраструктуры обеспечивает ускорение выполнения задач при настройке инфраструктуры и направлена на обеспечение прозрачности, чтобы помочь другим командам на предприятии работать быстрее и эффективнее. Автоматизация устраняет риск, связанный с человеческим фактором, например, с неправильной конфигурацией вручную; удаление этого может сократить время простоя и повысить надежность. Эти результаты и атрибуты помогают предприятию перейти к внедрению культуры DevOps , комбинированной работы по разработке и эксплуатации . [5]
Типы подходов [ править ]
Обычно существует два подхода к IaC: декларативный (функциональный) и императивный (процедурный). Разница между декларативным и императивным подходом по существу заключается в том, «что» и «как» . Декларативный подход фокусируется на том, какой должна быть конечная целевая конфигурация; императив сосредоточен на том, как инфраструктура , чтобы удовлетворить эту потребность. должна быть изменена [6] Декларативный подход определяет желаемое состояние, и система выполняет то, что должно произойти для достижения этого желаемого состояния. Императив определяет конкретные команды, которые необходимо выполнить в соответствующем порядке, чтобы получить желаемый результат. [7]
Методы [ править ]
Существует два метода IaC: push и pull . Основное отличие заключается в способе настройки серверов. В методе извлечения настраиваемый сервер будет получать свою конфигурацию с управляющего сервера. При использовании метода push управляющий сервер отправляет конфигурацию в целевую систему. [8]
Инструменты [ править ]
Существует множество инструментов, реализующих возможности автоматизации инфраструктуры и использующих IaC. В широком смысле, любая структура или инструмент, который выполняет изменения или настраивает инфраструктуру декларативно или императивно на основе программного подхода, может считаться IaC. [9] Традиционно автоматизации (жизненного цикла) и управления конфигурацией для реализации IaC использовались инструменты сервера. Теперь предприятия также используют инструменты автоматизации непрерывной настройки или автономные инфраструктуры IaC, такие как PowerShell DSC от Microsoft. [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 включают:
Инструмент | Выпущено | Метод | Подход | Написано в | Комментарии |
---|---|---|---|---|---|
CFEngine | Northern.tech (1993) | Тянуть | Декларативный | С | - |
Кукольный | Марионетка (2005) | Толкай и тяни | Декларативный и императивный | C++ и Clojure начиная с версии 4.0, Ruby | - |
Шеф-повар | Шеф-повар (2009) | Тянуть | Декларативный и императивный | Руби | - |
Соляной стек | СолтСтек (2011) | Толкай и тяни | Декларативный и императивный | Питон | - |
Ансибль / Ансибль Башня | Красная шляпа (2012) | Толкай и тяни | Декларативный и императивный | Питон | - |
Терраформировать | ХашиКорп (2014) | Толкать | Декларативный и императивный | Идти | - |
Выдра | Инедо (2015) | Толкать | Декларативный и императивный | - | ориентированный на Windows |
бирманский | Кисть (2018) | Толкать | Декларативный и императивный | Идти |
Другие инструменты включают AWS CloudFormation , cdist , StackStorm , Juju и Step CI.
Отношения [ править ]
Отношения с DevOps [ править ]
IaC может стать ключевым атрибутом внедрения лучших практик в DevOps . Разработчики начинают более активно участвовать в определении конфигурации, а команды эксплуатации начинают участвовать в процессе разработки на более раннем этапе. [13] Инструменты, использующие IaC, обеспечивают прозрачность состояния и конфигурации серверов и, в конечном итоге, обеспечивают прозрачность для пользователей внутри предприятия, стремясь объединить команды для максимизации их усилий. [14] Автоматизация в целом направлена на то, чтобы устранить путаницу и склонность к ошибкам в ручных процессах и сделать их более эффективными и производительными. Позволяет создавать лучшее программное обеспечение и приложения с гибкостью, меньшим временем простоя и в целом экономически эффективным способом для компании. IaC предназначен для снижения сложности, которая снижает эффективность ручной настройки. Автоматизация и совместная работа считаются центральными моментами DevOps; Инструменты автоматизации инфраструктуры часто включаются в качестве компонентов цепочки инструментов DevOps . [15]
Отношение к безопасности [ править ]
В отчете об облачных угрозах за 2020 год, опубликованном Unit 42 (подразделением анализа угроз поставщика кибербезопасности Palo Alto Networks ), было выявлено около 200 000 потенциальных уязвимостей в инфраструктуре в качестве шаблонов кода. [16]
См. также [ править ]
Ссылки [ править ]
- ^ Виттиг, Андреас; Виттиг, Майкл (2016). Веб-сервисы Amazon в действии . Мэннинг Пресс. п. 93. ИСБН 978-1-61729-288-0 .
- ^ Бауэр, Джозеф Л.; Кристенсен, Клейтон М. «Прорывные технологии: ловля волны». Гарвардское деловое обозрение .
- ^ Jump up to: а б с Флетчер, Колин; Косгроув, Терренс (26 августа 2015 г.). Innovation Insight для инструментов автоматизации непрерывной настройки . Гартнер (отчет). [ мертвая ссылка ]
- ^ Райли, Крис (12 ноября 2015 г.). «Версия вашей инфраструктуры» . DevOps.com .
- ^ Филлипс, Эндрю (14 мая 2015 г.). «Переход от автоматизации инфраструктуры к истинному DevOps» . DevOps.com .
- ^ «Декларативная и императивная модели управления конфигурациями: что действительно лучше?» . Scriptrock.com . Архивировано из оригинала 31 марта 2015 года . Проверено 14 декабря 2015 г.
- ^ Лошвиц, Мартин (14 ноября 2014 г.). «Выбор между ведущими менеджерами конфигураций с открытым исходным кодом» . Администрирование сети и безопасности . Лоуренс, Канзас, США: Linux New Media USA LLC.
- ^ Венеция, Пол (21 ноября 2013 г.). «Марионетка против Шефа против Ансибла против Солт» . Сетевой мир . Сетевой мир. Архивировано из оригинала 18 июля 2018 года . Проверено 14 декабря 2015 г.
- ^ Тенденции рынка Garner: DevOps — не рынок, а инструментально-ориентированная философия, которая поддерживает непрерывную цепочку создания стоимости (отчет). Гартнер. 18 февраля 2015 г.
- ^ Jump up to: а б Чаганти, Равикант (5 января 2016 г.). «DevOps, инфраструктура как код и PowerShell DSC: введение» . Журнал PowerShell . Журнал PowerShell . Проверено 11 января 2016 г.
- ^ «Представляем AWS CloudFormation» .
- ^ Стерджен, Фил (28 октября 2012 г.). «Марионетка или шеф-повар?» .
- ^ Рамос, Мартин (4 ноября 2015 г.). «Непрерывная интеграция: инфраструктура как код в DevOps» . easydynamics.com . Архивировано из оригинала 6 февраля 2016 года . Проверено 29 января 2016 г.
- ^ Инфраструктура как код: разжигаем огонь по ускорению доставки приложений (отчет). Форрестер. Март 2015.
- ^ Вурстер, Лори Ф.; Колвилл, Ронни Дж.; Высота, Кэмерон; Трипати, Сомендра; Растоги, Адити. Анализ новых технологий: DevOps — это культурный сдвиг, а не технология (отчет). Гартнер.
- ^ «Отчет об облачных угрозах показывает необходимость последовательного DevSecOps» . Информационная неделя . 13 февраля 2020 г. Проверено 24 февраля 2020 г.