Infrastructure as Code: Плюсы, Минусы и Будущее
Infrastructure as Code — ключевой элемент наиболее эффективных инженерных сетапов. То, как сейчас DevOps-инженеры взаимодействуют со своей инфраструктурой — это несомненно большой скачок вперед. Но тем не менее спорные моменты с определением и лучшими практиками IaC до сих пор есть. Эта статья стремится четко описать IaC, его преимущества и важные ограничения.
Infrastructure as Code, или сокращенно IaC, — это фундаментальный сдвиг не только для Ops в том, как они подходят к провизионированию и обслуживанию инфраструктуры, но и в разработке программного обеспечения в целом. Несмотря на то, что за последние несколько лет IaC де-факто зарекомендовал себя как отраслевой стандарт, многие до сих пор спорят о его определении, лучших практиках и ограничениях.
В этой статье вы познакомитесь с эволюцией этого подхода к инфраструктуре рабочих процессов и связанных с ним технологий. Мы объясним, откуда появился IaC, перспективы его развития, его преимущества и его главные ограничения.
От железа к облаку
Еще помните железный век IT, когда вам нужно было покупать собственные серверы и компьютеры? И я уже не помню. Сейчас кажется совершенно безумным, что рост инфраструктуры мог быть ограничен циклом покупки оборудования. Поскольку доставка нового сервера занимала несколько недель, необходимость быстрой установки и настройки на нем операционной системы не стояла так остро. Люди просто вставляли диск в сервер и следовали по пунктам. Через несколько дней он становился доступен для разработчиков. Просто безумие.
С одновременным запуском и повсеместным внедрением AWS EC2 и Ruby on Rails 1.0 в 2006 году многие корпоративные группы столкнулись с проблемами масштабирования, которые ранее возникали только в крупных транснациональных организациях. Облачные вычисления и возможность без усилий запускать новые инстансы виртуальных машин принесли инженерам и предприятиям не только хорошую выгоду, но и дополнительные хлопоты. Теперь им приходилось следить за обслуживаемыми серверами, число которых постоянно росло.
Площадь инфраструктуры средней инженерной организации стала расти по мере того, как небольшое количество больших машин заменялось большим количеством меньших. В какой-то момент стало гораздо больше вещей, которые Ops требовалось провизионировать и поддерживать, и эта инфраструктура имела тенденцию быть циклической. Мы можем масштабироваться, чтобы справиться с пиковой нагрузкой днем, а ночью уменьшать масштаб, чтобы сэкономить на расходах, потому что они не фиксированы. В отличие от необходимости мириться с постоянным устареванием нашего оборудования, мы теперь платим за вычислительные ресурсы почасово. Таким образом, чтобы извлечь максимальную выгоду при использовании облачного сетапа, имеет смысл задействовать только ту инфраструктуру, которая вам необходима.
Чтобы максимально эффективно использовать эту гибкость, нам потребовалась новая парадигма. Создавать тысячу тикетов каждое утро, чтобы набрать максимальную мощность, и еще тысячу тикетов ночью, чтобы снова замедлиться, при этом вручную управлять всем этим, очевидно, становится довольно сложной задачей. Возникает вопрос, как начать операционализировать этот сетап, чтобы он был надежным, устойчивым и исключал ошибки, вызванные человеческим фактором?
Infrastructure as Code
Infrastructure as Code был рожден для решения этих задач максимально систематизированным образом. IaC — это процесс управления и провизионирования датацентров и серверов с помощью машиночитаемых файлов определений, созданный как альтернатива физическому конфигурированию оборудования и оперируемым человеком инструментам. Теперь, вместо того, чтобы запускать сотню различных файлов конфигурации, IaC позволяет нам просто запускать скрипт, который каждое утро поднимает тысячу дополнительных машин, а вечером автоматически сокращает инфраструктуру до приемлемого вечернего масштаба.
С момента запуска AWS Cloudformation в 2009 году IaC быстро стал неотъемлемой практикой DevOps, незаменимой в жизненном цикле конкурентоспособной доставки программного обеспечения. Он позволяет командам инженеров быстро создавать и версионировать инфраструктуру тем же способом, что и обычный код, и отслеживать эти версии во избежание несогласованности между средами. Обычно команды осуществляют это следующим образом:
Разработчики определяют и пишут инфраструктурные спецификации (infrastructure specs) на специфичном для предметной области языке
Созданные файлы отправляются в API управления, мастер-сервер или репозиторий кода
Затем инструмент IaC, такой как Pulumi, выполняет все действия, которые нужны для создания и настройки необходимых вычислительных ресурсов
И вуаля, ваша инфраструктура внезапно начинает работать на вас, а не наоборот.
Традиционно существует два подхода к IaC, декларативный или императивный, и два возможных метода, push и pull. Декларативный подход описывает конечную цель и определяет требуемое состояние ваших ресурсов. Этот подход отвечает на вопрос о том, что нужно создать, например, «Мне нужны две виртуальные машины». Императивный подход отвечает на вопрос о том, как нужно изменить инфраструктуру для достижения конкретной цели, обычно выдавая последовательность различных команд. Ansible playbooks — отличный пример императивного подхода. Разница между методом push и pull заключается в том, каким образом серверам сообщается информация о конфигурации. В pull режиме каждый сервер будет пулить свою конфигурацию из мастер-сервера, а в push режиме мастер-сервер сам распушивает конфигурацию по целевой системе.
В течение последних десяти лет набор инструментов IaC постоянно эволюционировал, и, вероятно, потребовалась бы целая статья, чтобы дать исчерпывающий обзор всех различных вариантов реализации этого подхода в ее конкретной инфраструктуре. Однако мы составили краткую хронологию основных инструментов, перечисленных по дате релиза:
Что я узнал, протестировав 200 000 строк инфраструктурного кода
Подход IaC (Infrastructure as Code) состоит не только из кода, который хранится в репозитории, но еще людей и процессов, которые этот код окружают. Можно ли переиспользовать подходы из разработки ПО в управление и описание инфраструктуры? Будет не лишним держать в голове эту идею, пока будете читать статью.
Infrastructure as bash history
Предположим приходите вы на новый проект, а вам говорят: «у нас Infrastructure as Code«. В реальности оказывается, Infrastructure as bash history или например Documentation as bash history. Это вполне реальная ситуация, например, подобный случай описывал Денис Лысенко в выступление Как заменить всю инфраструктуру и начать спать спокойно, он рассказал как из bash history они получили стройную инфраструктуру на проекте.
При некотором желании, можно сказать, что Infrastructure as bash history это как код:
Infrastructure as Code
Даже такой странный случай как Infrastructure as bash history можно притянуть за уши к Infrastructure as Code, но когда мы захотим сделать что-нибудь посложнее чем старый добрый LAMPовый сервер, мы прийдем к тому, что этот код необходимо как-то модифицировать, изменять, дорабатывать. Далее хотелось мы будем рассматривать параллели между Infrastructure as Code и разработкой ПО.
На проекте по разработке СХД, была подзадача периодически настраивать SDS: выпускаем новый релиз — его необходимо раскатать, для дальнейшего тестирования. Задача предельно простая:
Для описанной логики более чем достаточно bash, особенно на ранних стадиях проекта, когда он только стартует. Это не плохо что вы используете bash, но со временем появляются запросы развернуть нечто похожее, но чуть-чуть отличающиеся. Первое что приходит в голову: copy-paste. И вот у нас уже два очень похожих скрипта, которые делают почти тоже самое. Со временем кол-во скриптов выросло, и мы столкнулись с тем, что есть некая бизнес логика развертывания инсталляции, которую необходимо синхронизировать между разными скриптами, это достаточно сложно.
Оказывается, есть такая практика D.R.Y. (Do not Repeat Yourself). Идея в том, чтобы переиспользовать существующий код. Звучит просто, но пришли к этому не сразу. В нашем случае это была банальная идея: отделить конфиги от скриптов. Т.е. бизнес логика как разворачивается инсталляция отдельно, конфиги отдельно.
S.O.L.I.D. for CFM
Со временем проект рос и естественным продолжением стало появление Ansible. Основная причина появления его это наличие экспертизы в команде и что bash не предназначен для сложной логики. Ansible тоже стал содержать сложную логику. Для того что бы сложная логика не превращалась в хаос, в разработке ПО существуют принципы организации кода S.O.L.I.D. Так же, например, Григория Петров в докладе «Зачем айтишнику личный бренд» затронул вопрос, что человек, так устроен, что ему проще оперировать какими-то социальными сущностями, в разработке ПО это объекты. Если объединить эти две идеи продолжить развивать их, то можно заметить, что в описании инфраструктуры тоже можно использовать S.O.L.I.D. что бы в дальнейшем было проще поддерживать и модифицировать эту логику.
The Single Responsibility Principle
Каждый класс выполняет лишь одну задачу.
Не надо смешивать код и делать монолитные божественные макаронные монстры. Инфраструктура должна состоять из простых кирпичиков. Оказывается, что если раздробить Ansible playbook на небольшие кусочки, читай Ansible роли, то их проще поддерживать.
The Open Closed Principle
Изначально мы разворачивали тестовую инфраструктуру на виртуальных машинах, но за счет того, что бизнес логика разворачивания была отдельно от реализации, мы без проблем добавили раскатку на bare-metall.
The Liskov Substitution Principle
Принцип подстановки Барбары Лисков. объекты в программе должны быть заменяемыми на экземпляры их подтипов без изменения правильности выполнения программы
Если посмотреть шире, то не особенность какого-то конкретного проекта, что там можно применить S.O.L.I.D., оно в целом про CFM, например, на другом проекте необходимо разворачивать коробочное Java приложение поверх различных Java, серверов приложений, баз данных, OS, итд. На это примере я буду рассматривать дальнейшие принципы S.O.L.I.D.
В нашем случае в рамках инфраструктурной команды есть договоренность, что если мы установили роль imbjava или oraclejava, то у нас есть бинарный исполняемый файл java. Это нужно т.к. вышестоящее роли зависят от этого поведения, они ожидают наличие java. В тоже время это нам позволяет заменять одну реализацию/версию java на другую при этом не изменяя логику развертывания приложения.
Проблема здесь кроется в том, что в Ansible нельзя реализовать такое, как следствие в рамках команды появляются какие-то договоренности.
The Interface Segregation Principle
Принцип разделения интерфейса «много интерфейсов, специально предназначенных для клиентов, лучше, чем один интерфейс общего назначения.
Изначально мы пробовали складывать всю вариативность разворачивания приложения в один Ansible playbook, но это было сложно поддерживать, а подход, когда у нас специфицирован интерфейс наружу (клиент ожидает 443 порт) то под конкретную реализацию можно компоновать инфраструктуру из отдельных кирпичиков.
The Dependency Inversion Principle
Принцип инверсии зависимостей. Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.
Здесь пример будет основан на антипаттерне.
Т.е. высокоуровневая логика развертывания приложения, зависимостями протекала на нижележащие уровни гипервизора, и это означало проблемы при переиспользование этой логики. Не надо так.
Interaction
Инфраструктура как код — это не только про код, но ещё и про отношения между кодом и человеком, про взаимодействия между разработчиками инфраструктуры.
Bus factor
Предположим, что у вас на проекте есть Вася. Вася всё знает про вашу инфраструктуру, что будет если Вася вдруг пропадет? Это вполне реальная ситуация, ведь его может сбить автобус. Иногда такое случается. Если такое случится и знание о коде, его структуре, как он работает, явках и паролях, не распределены в команде, то можно столкнуться с рядом неприятных ситуаций. Что бы минимизировать эти риски и распределить знание в рамках команды можно использовать различные подходы
Pair Devopsing
Это не как в шутке, что админы пили пиво, пароли меняли, а аналог парного программирования. Т.е. два инженера садятся за один компьютер, одну клавиатуру и начинают вместе настраивать вашу инфраструктуру: сервер настраивать, Ansible роль писать, итд. Звучит красиво, но у нас не сработало. Но вот частные случаи этой практики работали. Пришел новый сотрудник, его наставник вместе с ним берет реальную задачу, работает — передает знание.
Другой частный случай, это incident call. Во время проблемы собирается группа дежурных и причастных, назначается один ведущий, который расшаривает свой экран и озвучивает ход мысли. Другие участники следуют за мыслью ведущего, подсматривают трюки из консоли, проверяют что не пропустил строчку в логе, узнают новое об системе. Такой подход скорее работал, чем нет.
Code Review
Субьективно, более эффективно распространение знаний об инфраструктуре и том как она устроена проходило при помощи code review:
Изюминкой здесь было, то что ревьюверы выбирались по очереди, по графику, т.е. с некоторой долей вероятности ты залезешь в новый участок инфраструктуры.
Code Style
Со временем стали появляться склоки во время ревью, т.к. у ревьюверов был свой стиль и ротируемости ревьюверов стакивала их с разными стилями: 2 пробела или 4, camelCase или snake_case. Внедрить это получилось не сразу.
Green Build Master
Время идет, и пришли к тому что нельзя пускать в мастер коммиты, которые не проходят некие тесты. Вуаля! мы изобрели Green Build Master который уже давным-давно практикуется в разработке ПО:
Принятие этого решения было весьма болезненным, т.к. вызвало множество споров, но оно того стоило, т.к. на ревью стали приходить запросы на слияние без разногласий по стилю и со временем кол-во проблемных мест стало уменьшаться.
IaC Testing
Кроме проверки стиля можно использовать и другие вещи, например, проверять что ваша инфраструктура действительно может развернуться. Или проверять что изменения в инфраструктуре не приведут к потере денег. Зачем это может понадобиться? Вопрос сложный и философский, ответить лучше байкой, что как-то был auto-scaler на Powershell который, не проверял пограничные условия => создалось больше ВМ чем надо => клиент потратил денег больше чем планировал. Приятного мало, но эту ошибку вполне реально было бы отловить на более ранних стадиях.
Можно спросить, а зачем делать сложную инфраструктуру еще сложнее? Тесты для инфраструктуры, так же, как и для кода, это не про упрощение, а про знание как ваша инфраструктура должна работать.
IaC Testing Pyramid
IaC Testing: Static Analysis
Если сразу разворачивать всю инфраструктуру и проверять, что она работает, то может оказаться, что это занимает уйму времени и требует кучу времени. Поэтому в основе должно быть что-то быстро работающее, его много, и оно покрывают множество примтивных мест.
Bash is tricky
Вот рассмотрим банальный пример. выбрать все файлы в текущей директории и скопировать в другое место. Первое что приходит в голову:
А что если в имени файла пробел есть? Ну ок, мы же умные, умеем пользоваться кавычками:
Молодцы? нет! Что если в директории нет ничего, т.е. глобинг не сработает.
Static analysis tools
Проблему из предыдущего шага можно было отловить когда мы забыли кавычки, для это в природе существует множество средство Shellcheck, вообще их много, и скорей всего вы сможете найти под свою IDE линтер для вашего стэка.
IaC Testing: Unit Tests
Как мы убедились из предыдущего примера, линтеры не всемогущие и не могут указать на все проблемные места. Дальше по аналогии с тестированием в разработке ПО можно вспомнить про unit tests. Тут сразу на ум приходят shunit, junit, rspec, pytest. Но что делать с ansible, chef, saltstack и иже с ними?
В самом начале мы говорили про S.O.L.I.D. и то что наша инфраструктура должна состоять из маленьких кирпичиков. Пришло их время.
IaC Testing: Unit Testing tools
Вопрос, а что такое тесты для CFM? можно банально запускать скрипт, а можно использовать готовые решения для этого:
Что выбрать? вопрос сложный и не однозначный, вот пример изменения в проектах на github за 2018-2019 года:
IaC Testing frameworks
Возникает как это все собрать вместе и запустить? Можно взять и сделать всё самому при наличии достаточного кол-во инженеров. А можно взять готовые решения, правда их не очень-то и много:
Пример изменения в проектах на github за 2018-2019 года:
Molecule vs. Testkitchen
Для 25-35 ролей это работало 40-70 минут, что было долго.
Следующим шагом стал переход на jenkins / docker / ansible / molecule. Идиологически все тоже самое
Линтовка для 40 ролей и тесты для десятка стали занимать порядка 15 минут.
Что выбрать зависит от множества факторов, как то используемый стэк, экспертиза в команде итд. тут каждый решает сам как закрывать вопрос Unit тестирования
IaC Testing: Integration Tests
На следующей ступени пирамиды тестирования инфраструктуры появлются интеграционные тесты. Они похожи на Unit тесты:
Грубо говоря, мы не проверяем работоспособность отдельного элемента системы как в unit тестах, мы проверяем как сервер сконфигурирован в целом.
IaC Testing: End to End Tests
На вершине пирамиды нас встречают End to End тесты. Т.е. мы не проверяем работоспособность отдельного сервера, отдельного скрипта, отдельного кирпичика нашей инфраструктуры. Мы проверяем что множество серверов, объединенных воедино, наша инфраструктура работает, как мы этого ожидаем. К сожалению готовых коробочных решений, мне не доводилось видеть, наверно т.к. инфраструктура зачастую уникальная и ее сложно шаблонизировать и сделать фрэймворк для ее тестирования. Как итог все создают свои собственные решению. Спрос есть, а вот ответа нет. Поэтому, расскажу что есть, чтобы натолкнуть других на здравые мысли или ткнуть меня носом, что всё давно изобретено до нас.
Проект с богатой историей. Используется в больших организациях и вероятно каждый из вас косвенно пересекался. Приложение поддерживает множество баз данных, интеграций итд итп. Знание о том, как инфраструктура может выглядеть это множество docker-compose файлов, а знание того, какие тесты в каком окружение запускать — это jenkins.
Эта схема достаточно долго работала, пока в рамках исследования мы не попробовали это перенести в Openshift. Контейнеры остались теже, а вот среда запуска сменилась (привет D.R.Y. опять).
Мысль исследования пошла дальше, и в openshift нашлась такая штука APB (Ansible Playbook Bundle), которая позволяет в контейнер запаковать знание как разворачивать инфраструктуру. Т.е. есть воспроизводимая, тестируемая точка знания, как развернуть инфраструктуру.
Всё это звучало хорошо, пока не уткнулись в гетерогенную инфраструктуру: нам для тестов нужна Windows. В итоге знание о том что, где как развернуть, и протестировать сидит в jenkins.
Conclusion
Infrastructure as Code это
DevSecOps — когда «инфраструктура как код» встречается с «безопасностью как код»
Если вы, как и я, отвечаете за успешный запуск критически важных приложений, помогающих бизнесу быть на передовой в цифровой трансформации, то, несомненно, поймете, о чем пойдет речь в этой статье. Для руководства такой миссией, помимо навыков проектирования архитектуры, требуются также навыки менторинга и управления инженерными ресурсами, а также контроль работы бизнес-аналитиков, выявляющих требования. Эти навыки в значительной степени детерминированы и управляемы по сравнению с другими, необходимыми для обеспечения надежной и безопасной работы приложений. Из-за этого разработчиков часто противопоставляют администраторам инфраструктуры и специалистам по информационной безопасности, считая их «последней миле» на пути к запуску приложения. Но у администраторов и «безопасников» возникают следующие проблемы:
Инфраструктура. Планирование мощностей и провиженинг инфраструктуры по своей сути сложный и длительный процесс. Он требует времени, чтобы убедиться в доступности необходимых и достаточных вычислительных ресурсов, систем хранения данных, пропускной способности сети еще до того, как будет написана первая строчка кода. Необходимо прогнозировать увеличение нагрузки и резервировать соответствующие ресурсы, что приводит к их избыточному выделению только для того, чтобы избежать их нехватки в будущем, когда они потребуются. Это контрастирует с работой разработчиков, для которых скорость, гибкость и реакция на изменения являются фундаментальными принципами. Если вы используете локальные датацентры (aka On-Prem), то поймете меня.
Безопасность. Из-за традиционного разделения разработки и эксплуатации, у разработчиков есть только ограниченная высокоуровневая информация об инфраструктуре, на которой будет работать их приложение. И «проверка безопасности» часто откладывается на поздние этапы разработки, хотя по-прежнему рассматривается как обязательное условие для запуска в продакшн. Это, как известно, вызывает серьезные трения между разработчиками и специалистами по информационной безопасности, поскольку очень часто требования по безопасности могут повлечь за собой значительные изменения в архитектуре и дизайне приложения, вызывая задержки и недовольство архитекторов и разработчиков.
В обеих вышеуказанных проблемах прослеживается общая черта — отсутствие прозрачности, общения и сотрудничества между разработчиками, администраторами и специалистами по информационной безопасности. Понять причины проблем нетрудно, поскольку эти группы исторически работают изолированно. Но можно посмотреть на эту проблему с другой стороны — неспособность видеть межфункциональные проблемы. Например, с точки зрения разработчика, он разрабатывает критически важную функциональность для бизнеса. Однако для специалистов по эксплуатации и безопасности потенциальные сбои в работе приложения превосходят любую бизнес-ценность, которую оно может принести. И до тех пор, пока не появится работающий механизм, обеспечивающий кросс-функциональное видение, ситуация останется прежней. К счастью, такой подход появился естественным образом, и сегодня, как мы увидим ниже, он жив и процветает.
Инфраструктура как код (infrastructure as code)
«Инфраструктура как код» (Infrastructure-as-code) или «программируемая инфраструктура» — это практика провиженинга и управления ресурсами датацентра с помощью инструментов, которые описывают ресурсы (вычислительные, системы хранения данных, сеть), в форме машиночитаемых файлов. Для описания используются языки, похожие на языки программирования высокого уровня, с помощью которых разработчики могут автоматизировать настройку, развертывание, управление инфраструктурой, используя современные практики разработки программного обеспечения. Преимущества такого подхода невозможно переоценить, поскольку благодаря контролю версий появляется независимость, контроль, иммутабельность, повторяемость и трассируемость. Это первая практика, которая появилась для облегчения понимания межфункциональных проблем между разработчиками и администраторами инфраструктуры. С развитием этой практики стали проявляться два фундаментальных сдвига:
У разработчиков появляется мощный инструмент для работы с аппаратными ресурсами, хоть и виртуальными, с помощью знакомого им простого интерфейса: API и библиотек. Внезапно развертывание и эксплуатация становятся просто продолжением процесса разработки. Полезным побочным эффектом становится то, что разработчики теперь понимают требования к уровню обслуживания, такие как высокая доступность, масштабируемость, надежность и отказоустойчивость.
Администраторы инфраструктуры получают четкое представление о динамике разработки программного обеспечения, скорости и гибкости, которые становятся все более привычными. И они сами приобретают навыки разработки, внося свой вклад в программируемую инфраструктуру. Уходят проблемы нехватки и избыточности выделенных ресурсов, а также конфликты при изменениях, что позволяет им плотно взаимодействовать с разработчиками в достижении «эластичности» и «эфемерности» программируемого инфраструктурного облака.
Слияние двух вышеупомянутых трендов известно как «DevOps», ознаменовавшее появление «инфраструктуры как кода»:
Безопасность как код (security as code)
Успех практики «инфраструктура как код» послужил примером для привлечения специалистов по информационной безопасности к обсуждению требований безопасности на ранних этапах разработки. Основным требованием для практики «безопасность как код» является возможность реализации программного управления безопасностью, автоматизации определения требований к безопасности, возможность оценки и обеспечения безопасности до и после запуска приложений, а также на протяжении всего жизненного цикла разработки. К безопасности инфраструктуры и приложений предъявляются определенные фундаментальные требования, такие как видимость, прозрачность и повторяемость средств управления безопасностью. Сложность состоит в том, чтобы реализовать все это без ущерба для скорости разработки, которая нужна разработчикам, особенно с учетом наличия в их арсенале платформ автоматизации инфраструктуры и DevOps.
Как и в случае с программируемой инфраструктурой, описанной в предыдущем разделе, здесь также происходят два фундаментальных сдвига в мышлении:
Специалисты по информационной безопасности теперь считают, что можно ожидать от разработчиков следования практикам безопасного программирования и использования наглядного и автоматизированного способа анализа безопасности кода. Теперь уязвимости кода выявляются на ранних этапах. Также специалистам по информационной безопасности становится проще предоставлять разработчикам платформы с усиленной безопасностью («security hardened») и полностью пропатченные («fully patched»), на основе которых разработчики будут создавать приложения.
Разработчики понимают, что обеспечение безопасности приложений должно быть «сдвинуто влево» и это безусловный критерий для продвижения приложения по дальнейшим этапам жизненного цикла (Dev, QA, Staging, Production).
Конвергенция двух вышеупомянутых сдвигов известна как «SecOps» — «безопасность как код» (security as code):
Собираем все вместе —- «DevSecOps»
На основе вышеизложенного должно быть очевидно, что напрашивается объединение подходов «инфраструктура как код» и «безопасность как код». Как показано на рисунке ниже, эти практики естественным образом сливаются для гармоничного взаимодействия между различными ролями и используемыми системами.
Можно выделить несколько фундаментальных принципов DevSecOps:
Обеспечьте гибкость и скорость, инвестируя в hardened-инструменты, охватывающие весь жизненный цикл приложений и ресурсов: разработка-тестирование-развертывание-мониторинг.
Подвергайте все сомнению, обеспечивая прозрачность на каждом этапе CI / CD-конвейера.
Сделайте безопасность фундаментальным и безусловным критерием приемки на раннем этапе процесса разработки. Другими словами, «сдвиньте безопасность влево».
Относитесь ко всему с подозрением, включая код, конфигурацию, артефакты, инфраструктуру, и установите оценку безопасности в качестве требования для продвижения по конвейеру.
Как можно чаще прогоняйте приложение через Dev, QA, Staging и Production.
И, наконец, автоматизируйте, автоматизируйте и автоматизируйте.
Решения для этого можно разработать и собственными силами, но выгоднее использовать готовые продуманные решения. Есть несколько работоспособных платформ с открытым исходным кодом, создание аналогов которых может потребовать серьезных ресурсов, знаний и опыта.
Основные характеристики платформы оркестрации, ориентированной на DevSecOps
На рынке существует множество решений для компаний, заинтересованных во внедрении DevSecOps-практик. При выборе любой такой платформы необходимо учитывать следующие критерии:
Программный интерфейс с открытым API. Красивый пользовательский интерфейс — это здорово, но с его помощью невозможно сделать серьезную интеграцию со сторонними продуктами.
Возможность интегрироваться и взаимодействовать с существующей ИТ-экосистемой. В enterprise-мире много легаси-систем и есть большая вероятность, что это будут критически важные системы для бизнеса.
Должна быть возможность развертывания в различных конфигурациях инфраструктуры без привязки к облакам.
Обеспечение безопасности приложений до их развертывания в рабочей среде.
Установка базового уровня безопасности (baseline) и постоянный мониторинг отклонений от него.
Поддержка оценки безопасности как на определенный момент времени, так и на основе мониторинга и событий. Это очень важно для отслеживания таких метрик, как MTTD (Mean-time-to-detect, среднее время обнаружения) и MTTR (Mean-time-to-recover, среднее время восстановления) для постоянного улучшения процессов.
Сбор всей необходимой информации о проблеме и предложение способов ее устранения — зачем говорить о проблеме, если мы не знаем, как ее решить?
Обеспечение информированности о работе конвейера через отправку уведомлений.
Поддержка механизмов реагирования на инциденты через интеграцию с другими системами, чтобы анализ «первопричин» проводился сразу же, а не через несколько дней после инцидента, повлиявшего на бизнес.
Материал подготовлен в рамках курса «Внедрение и работа в DevSecOps». Если вам интересно узнать подробнее о формате обучения и программе, познакомиться с преподавателем курса — приглашаем на день открытых дверей онлайн. Регистрация здесь.
