что такое devops для чайников

С чего начать DevOps?

Понятие DevOps знакомо многим, но в своей практике я часто наблюдаю такую ситуацию, когда соискатель на должность DevOps-инженера в нашу компанию не может ответить на вопрос “А что же такое DevOps?”. В данной статье я хочу упорядочить и структурировать знания и основные понятия DevOps. Ещё раз обозначить какие процессы там существуют, для чего они и с чего начать внедрение DevOps у себя в проекте.

Философия

На текущий момент нет чёткого определения DevOps и каждый трактует его хоть и во многом схожим образом, но всё же по-своему. Если открыть любую статью, то там будет написано, что DevOps — это, прежде всего, философия, а уже только потом практика. Для тех, кто только начал заниматься данным направлением, это может показаться не очень очевидным, но по мере получения опыта смысл сказанного становится более понятным.

В своей практике мы встречаем несколько различных определений DevOps. Достаточно распространённым является то, в котором DevOps представляет собой использование специальных инструментов для построения CI/CD для деплоя новых версий приложения.

Основная проблема такого понимания в том, что оно не даёт ответа на вопрос для чего и как это делается. В действительности попытки применить в проекте DevOps именно в такой трактовке приводят к серьёзным проблемам. Мы не раз сталкивались с этим, когда только начинали предлагать нашим клиентам DevOps как услугу.

Например, если в проект с таким замечательным набором ПО для деплоя как FileZilla и бэкапами в качестве системы контроля версий добавить DevOps в обозначенной выше формулировке, и при этом не донести до разработчиков философскую составляющую, то это с высокой вероятностью приведёт к тому, что они продолжат править код прямо на production-сервере, особенно в случае обнаружения критических ошибок. Бывало и такое, что для этих целей нас даже просили поставить SSH-сервер в Docker-контейнеры.

Со временем мы пришли к пониманию того, что большинство возникающих проблем являются вызовом, скорее, с точки зрения культуры, чем технологий и перестали внедрять DevOps без предварительной идеологической подготовки сотрудников клиента.

Теперь давайте представим себе традиционную модель процесса создания ПО. В ней разработка и эксплуатация — это два разных, не всегда тесно связанных между собой отдела. При этом, их цели и задачи являются диаметрально противоположными. Первые нацелены на более частые релизы приложения. Желательно, сразу после внедрения новых фич, функционала или исправления ошибок. Но они сильно зависят от сотрудников отдела эксплуатации, для которых каждый релиз — это боль, т.к. требует внесения изменений в работающую инфраструктуру, что несёт определённые риски для её стабильности. А к этому критерию могут быть привязаны и их KPI. Поэтому при таком подходе эксплуатация будет стараться производить деплой новых версий ПО как можно реже, например, задавая окна для релиза раз в определённый период.

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

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

Как видите, для того, чтобы Dev’ы и Ops’ы в описанной традиционной модели могли не только дружно уживаться, но и вместе создавать большие и сложные проекты, требуется дополнительная философская составляющая, направленная на активное взаимодействие и интеграцию команд разработки и эксплуатации, с целью повышения скорости выпуска и качества новых версий разрабатываемого ПО. Именно такую философию называют DevOps.

Давайте посмотрим из чего она состоит:

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

Что касается теории, то кроме первого базового элемента, а именно понимания тех самых принципов DevOps, приведённых выше, имеются и другие. Следующим из которых является коллективное владение продуктом (shared ownership):

Говоря другими словами — совместное владение различного рода информацией и знаниями о разрабатываемом продукте. Это важнейшая составляющая культуры DevOps, т.к. является тем самым “склеивающим раствором” между разработкой и эксплуатацией, поскольку первые начинают думать не только над тем, как будет выглядеть тот или иной функционал для конечного пользователя, но и, понимая как всё это будет работать, выбирать более правильные методы реализации, учитывая особенности работы системного ПО. Ops’ы, обладая соответствующей информацией, со своей стороны тоже смогут выбирать и предлагать более качественные, оптимальные и удобные решения с точки зрения разработки проекта. Это касается всего, что позволило бы максимально учесть все нюансы будущего приложения, от проектирования инфраструктуры и до выбора конкретных программных элементов, таких как, например, БД.

Такое вовлечение в общий процесс различных участников проекта позволяет каждому из них рассматривать проблему с разных точек зрения и наладить максимально тесное взаимодействие:

Это повысит командный дух и решение даже самых сложных задач станет интересным и увлекательным занятием.

Ещё одной значимой составляющей в философии DevOps является культура, направленная на совершенствование имеющихся процессов:

Не надо бояться экспериментировать и пробовать новые методологии и практики. Единственное, эти эксперименты должны быть контролируемыми, а все изменения хорошо прорабатываться перед внедрением. Данный момент ещё будет затронут далее в статье.

Процессы

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

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

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

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

Continuous Integration

Каким бы по размерам не был продукт и на какой бы стадии его разработки вы не находились, вам потребуется иметь дело с системой контроля версий.
Вы можете выбрать любую из них даже такую:

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

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

Современные системы контроля версий предоставляют механизм ветвлений в качестве базы для непрерывной интеграции. Работа с различными ветками, их слияние между собой или в master, является пультом для управления Continuous integration в проекте.

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

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

При выстраивании CI нужно учесть:

Continuous Testing

После того как ваш код написан и до того, как будет доставлен в production — он должен быть тщательно протестирован. Казалось бы, это очевидно, но на деле об этом заботятся далеко не все. Часто ограничиваются проведением только unit-тестов, а некоторые вообще тестируют на конечных пользователях в продуктовой среде и сейчас я имею в виду не A/B тестирование))

Помимо Dev и Ops одной из составляющих DevOps, правда, не такой явной, является QA. И обеспечение качества тоже должно быть частью общего Continuous!

В правильно сбалансированных проектах роль тестирования настолько велика, что влияет не только на Continuous Integration и Continuous Deployment, но и определяет вид всей инфраструктуры. При этом разработка всего необходимого для выстраивания этого процесса может занимать чуть ли ни половину от всех временных затрат на внедрение DevOps.

В прошлом году на IT-Nights я выступал с докладом, где рассказывал про микросервисную архитектуру. В нём я приводил схему, которую мы придумали и внедрили в рамках реализации одного из проектов:

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

Да, процесс сложный, иногда очень нудный и не всегда интересный. Его даже можно игнорировать до определённого момента. Но главное не пропустить точку невозврата, потому что в конечном итоге это необходимое условие для предоставления качественного сервиса и, как следствие, успешного развития проекта.

Continuous Deployment

Что хотелось бы получить от этого процесса:

Т.е. и к этому процессу предъявляются требования автоматизации и непрерывности. Так мы получаем Continuous Deployment.

Непосредственная реализация деплоя зависит от среды назначения и не обязательно должна производиться в Kubernetes. Помимо того, это может быть и одиноко стоящий bare-metal server, и кластер на железе, и даже пакетный репозиторий. И, очевидно, что выбор инструментария для решения этой задачи будет зависеть от того, куда именно потребуется делать деплой.

Если говорить именно о разработке и доставке сервиса, то придётся познакомиться с такими понятиями как stateless и stateful, а также столкнуться со множеством проблем, основными из которых будут:

Вообще тема Zero downtime и откат версии приложения в совокупности с БД — это действительно непростой процесс, который всегда надо чётко контролировать. В рамках данной публикации всё это рассказать будет не реально, но у нас по этой теме есть несколько статей на Habr’e (вот и вот), а также в прошлом году я делал доклад на Стачку “Rest API сервер от кода до деплоя”, там освещаются основные аспекты и те моменты, на которые стоит обратить внимание при построении деплоя с нулевым простоем совместно с прямыми и обратными миграциями БД. На эту тему я так же планирую позже написать статью.

И, кстати, Continuous Deployment тоже должен быть обёрнут в тесты. Т.е. проверка качества должна происходить не только перед доставкой кода, но и даже после этого. Разумеется, это будут разные типы тестирования.

Continuous Infrastructure

Теперь давайте поговорим о том, где будет работать всё то, что мы закодим и задеплоим — об инфраструктуре. Так же как и для остальных процессов в общей методологии DevOps, для инфраструктуры тоже есть свой Continuous — Continuous Infrastructure.

Одним из ключевых составляющих которой является Infrastructure as Code. Т.е. это описание инфраструктуры, необходимой для работы проекта в виде кода. Который, как и код самого приложения хранится в репозитории и версионируется. Для него точно также должны быть определены механизмы ветвления, версионирования, сборки и тестирования (например, с помощью Molecule, если речь идёт об Ansible). Т.е. процесс по своему виду очень напоминает Continuous Integration.

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

Если вы сомневаетесь относительно необходимости наличия данного процесса в общем стеке, будучи уверенным в том, что “да я и вручную очень быстро web-сервера настраиваю”, то помните про Disaster Recovery и попробуйте ответить себе на два вопроса:

Continuous Monitoring

И завершающим процессом во всей этой цепочке является Continuous Monitoring. Основным назначением которого является поддержание в актуальном состоянии конфигурации мониторинга различных элементов проекта, от инфраструктуры и до приложений, входящих в его состав. Причём отслеживание и мониторинг всех необходимых метрик должен производиться автоматически. Для этого придётся постараться всем, в том числе и программистам, которые часто просто не понимают необходимость реализации в коде механизмов, позволяющих получить метрики конкретного сервиса и им достаточно простого принципа “процесс запущен, значит всё хорошо”.

Оптимизация процессов

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

Когда возникает какая-то идея по улучшению того или иного процесса — часто приходится иметь дело с дилеммой: а как распространить эти улучшения на остальные аналогичные элементы системы, стоит ли это вообще делать и если да, то когда следует остановиться?

С какими проблемами можно столкнуться:

И это действительно очень хороший философский вопрос, на который не существует однозначного ответа. Но, как правило, истина где-то посередине или почти посередине.

Инструменты

Поскольку доступный сейчас инструментарий для организации CI/CD и реализации DevOps очень обширен, схож между собой по функционалу и может отличаться наличием лишь некоторых фич и удобством их реализации, выбор конкретных решений основан, скорее, на степени знакомства команды с тем или иным ПО.

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

DevOps-минимум

Понятно, что реализация всех описанных процессов в рамках даже небольшого проекта может быть делом весьма продолжительным и сложным. Поэтому многие команды задаются логичным вопросом: “С чего начать DevOps? Какой минимум необходим? И какие элементы нужны в первую очередь?”.

Реализовав множество проектов различной сложности по внедрению DevOps, на основе полученного опыта наша команда может ответить на этот вопрос так:

Такой выбор объясняется следующим образом. Как описывалось ранее, для того, чтобы появившийся DevOps ни только не умер, но и мог развиваться, ему нужна очень прочная и хорошо усвоенная философская составляющая. Т.е. потребуется очень чёткое понимание смысла и назначения внедряемой методологии. Поэтому все пункты из блока “философия” в полном составе попадают в наш DevOps-минимум.

Что касается процессов, то тут уже не всё из обозначенного выше имеет критическое значение на начальных этапах появления DevOps. Здесь нам никак не обойтись без двух “continuous”: Integration и Deployment. В первую очередь потому, что без этого DevOps так останется просто теорией и не будет иметь никакого практического смысла.

При этом благодаря наличию у остальных элементов этого блока определённой схожести с CI и CD, их отложенная реализация уже с учётом полученного на предыдущих этапах опыта и понимания нюансов, может быть проведена более оптимально.

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

Заключение

В конце хотелось бы ещё раз подчеркнуть основные мысли, которые я попытался донести в данной статье. Первое с чего необходимо начать внедрение DevOps — это понимание и принятие принципов и философии данной методологии всеми участниками команды. Пока это не так, не стоит набрасываться на практическую реализацию, как бы ни был велик соблазн или поджимали сроки. В конечном итоге такой подход сделает только хуже. Следует помнить об MVP не только в отношении продукта, но и процессов. Не все из них необходимы сразу. А при правильном подходе их внедрение на более поздних этапах может быть даже более эффективным. Главное — это держать руку на пульсе развития DevOps в своём проекте и контролировать процессы.

Источник

Руководство для чайников: создание цепочек DevOps с помощью инструментов с открытым исходным кодом

Создание первой цепочки DevOps за пять шагов для новичков.

DevOps стал панацеей для слишком медленных, разобщенных и прочих проблемных процессов разработки. Но нужны минимальные познания в DevOps. Здесь будет рассмотрены такие понятия, как цепочка DevOps и как создать ее за пять шагов. Это не полное руководство, а только “рыба”, которую можно расширять. Начнем с истории.

Мое знакомство с DevOps

Когда-то я работал с облаками в Citi Group и разрабатывал веб-приложение IaaS, чтобы управлять облачной инфраструктурой Citi, но мне всегда было интересно, как можно оптимизировать цепочку разработки и улучшить культуру среди разработчиков. Грег Лавендер, наш техдиректор по облачной архитектуре и инфраструктуре, посоветовал мне книгу Проект «Феникс». Она прекрасно объясняет принципы DevOps, при этом читается, как роман.

В таблице на обороте показано, как часто компании выкатывают новые версии:

Как Amazon, Google и Netflix успевают столько выкатывать? А все просто: они поняли, как создать почти идеальную цепочку DevOps.

У нас в Citi все было совсем не так, пока мы не перешли на DevOps. Тогда у моей команды были разные среды, но поставку на сервер разработки мы делали вручную. У всех разработчиков был доступ только к одному серверу разработки на базе IBM WebSphere Application Server Community Edition. При одновременной попытке поставки сервер “падал”, а нам приходилось каждый раз “болезненно” договариваться между собой. А еще у нас было недостаточное покрытие кода тестами, трудоемкий ручной процесс поставки и никакой возможности отслеживать поставку кода по некоторой задаче или требованию клиента.

Было понятно, что нужно срочно что-то делать, и я нашел коллегу-единомышленника. Мы решили вместе создать первую цепочку DevOps — он настроил виртуальную машину и сервер приложений Tomcat, а я занялся Jenkins, интеграцией с Atlassian Jira и BitBucket, а также и покрытием кода тестами. Проект был успешным: мы полностью автоматизировали цепочку разработки, добились почти 100% бесперебойной работы сервера разработки, могли отслеживать и улучшать покрытие кода тестами, а ветку Git можно было привязать к поставке и задаче Jira. И почти все инструменты, которыми мы строили цепочку DevOps, были открытым исходным кодом.

По факту, цепочка была упрощенной, ведь мы даже не применяли расширенные конфигурации с помощью Jenkins или Ansible. Но у нас все получилось. Возможно, это следствие принципа Парето (он же правило 80/20).

Краткое описание цепочки DevOps и CI/CD

У DevOps есть разные определения. DevOps, как и Agile, включает в себя разные дисциплины. Но большинство согласятся с следующим определением: DevOps — это метод, или жизненный цикл, разработки ПО, главный принцип которого — создание культуры, где разработчики и другие сотрудники “на одной волне”, ручной труд автоматизирован, каждый занимаются тем, что лучше всего умеет, возрастает частота поставок, повышается продуктивность работы, увеличивается гибкость.

И хотя одних только инструментов недостаточно для создания среды DevOps, без них не обойтись. Самым важным из них является непрерывная интеграция и непрерывная поставка (CI/CD). В цепочке для каждого окружения есть разные этапы (например, DEV (разработка), INT (интеграция), TST (тестирование), QA (контроль качества), UAT (приемочное тестирование пользователями), STG (подготовка), PROD (использование)), ручные задачи автоматизированы, разработчики могут делать качественный код, делают его поставку и могут легко перестраиваться.

Данная заметка описывает, как за пять шагов создать цепочку DevOps, как показано на картинке ниже, с помощью инструментов с открытым исходным кодом.

Шаг 1: Платформа CI/CD

Первым делом вам нужен инструмент CI/CD. Jenkins — это открытый инструмент CI/CD написанный на Java с лицензией MIT, с которого началась популяризация движения DevOps и который де-факто стал стандартом для CI\CD.

А что такое Jenkins? Представьте, что у вас есть волшебный пульт управления для самых разных сервисов и инструментов. Сам по себе инструмент CI/CD, типа Jenkins, бесполезен, но с разными инструментами и сервисами он становится всемогущим.

Кроме Jenkins есть множество других открытых инструментов, выбирайте любой.

Вот как выглядит процесс DevOps с инструментом CI/CD

У вас в localhost есть инструмент CI/CD, но делать пока особо нечего. Перейдем к следующему шагу.

Шаг 2: управление версиями

Лучший (и, пожалуй, самый простой) способ проверить магию инструмента CI/CD — интегрировать его с инструментом контроля версий (source control management, SCM). Зачем нужен контроль версий? Допустим вы делаете приложение. Вы пишете его на Java, Python, C++, Go, Ruby, JavaScript или на любом другом языке, коих вагон и маленькая тележка. То, что вы пишете, называется исходным кодом. Поначалу, особенно если вы работаете в одиночку, можно сохранять все в локальный каталог. Но когда проект разрастается и к нему присоединяется больше людей, вам нужен способ делиться изменениями в коде, но при этом избежать конфликтов при слияниях изменений. А еще вам нужно как-то восстанавливать предыдущие версии без использования резервных копий и применения метода copy-paste для файлов с кодом.

И тут без SCM никуда. SCM сохраняет код в репозиториях, управляет его версиями и координирует его среди разработчиков.

Инструментов SCM немало, но стандартом де-факто заслуженно стал Git. Я советую использовать именно его, но есть и другие варианты.

Вот как выглядит пайплайн DevOps после добавления SCM.

Инструмент CI/CD может автоматизировать загрузку и выгрузку исходного кода и совместную работу в команде. Неплохо? Но как теперь из этого сделать рабочее приложение, любимое миллиардами пользователей?

Шаг 3: инструмент автоматизации сборки

Все идет как надо. Вы можете выгружать код и фиксировать изменения в системе контроля версий, а также пригласить друзей поработать с вами. Но приложения у вас пока нет. Чтобы это было веб-приложение, его нужно скомпилировать и поместить в пакет для поставки или запустить как исполняемый файл. (Интерпретируемый язык программирования, вроде JavaScript или PHP, компилировать не надо.)

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

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

Вроде, все нормально. Но куда теперь все это выкатить?

Шаг 4: сервер веб-приложений

Итак, у вас есть запакованный файл, который можно исполнять или выкатывать. Чтобы приложение действительно приносило пользу, у него должен быть какой-то сервис или интерфейс, но вам нужно где-то это все разместить.

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

Есть несколько открытых серверов веб-приложений.

У нас уже получился почти рабочая цепочка DevOps. Отличная работа!

В принципе, здесь можно остановиться, дальше вы справитесь сами, но стоит еще рассказать о качестве кода.

Шаг 5: Тестовое покрытие

Тестирование отнимает много времени и сил, но лучше сразу найти ошибки и улучшить код, чтобы порадовать конечных пользователей. Для этой цели есть много открытых инструментов, которые не только протестируют код, а еще и посоветуют, как его улучшить. Большинство инструментов CI/CD могут подключаться к этим инструментам и автоматизировать процесс.

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

Фреймворки тестирования

Инструменты с подсказками по качеству

Большинство этих инструментов и фреймворков написаны для Java, Python и JavaScript, потому что C++ и C# — проприетарные (хотя у GCC открытый исходный код).

Инструменты тестового покрытия мы применили, и теперь пайплайн DevOps должен выглядеть, как на рисунке в начале руководства.

Дополнительные шаги

Контейнеры

Как я уже говорил, сервер приложений можно разместить на виртуальной машине или сервере, но контейнеры более популярны.

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

Для контейнеров обычно берут Docker и Kubernetes, хотя есть и другие варианты.

Почитайте статьи о Docker и Kubernetes на Opensource.com:

Инструменты автоматизации промежуточного ПО

Наша цепочка DevOps ориентирована на совместную сборку и поставку приложения, но с инструментами DevOps можно делать и другие интересные штуки. Например, использовать инструменты «инфраструктура как код» (IaC), которые еще называются инструментами автоматизации промежуточного ПО. Эти инструменты помогают автоматизировать установку, управление и другие задачи для промежуточного ПО. Например, инструмент автоматизации может брать приложения (сервер веб-приложений, базу данных, инструменты мониторинга) с правильными конфигурациями и выкатывать их на сервер приложений.

Вот несколько вариантов открытых инструментов автоматизации промежуточного ПО:

Подробности в статьях на Opensource.com:

И что теперь?

Это только верхушка айсберга. Цепочка DevOps может гораздо больше. Начните с инструмента CI/CD и узнайте, что еще можно автоматизировать, чтобы упростить себе работу. Не забудьте про открытые инструменты коммуникации для эффективной совместной работы.

Вот еще несколько хороших статей о DevOps для начинающих:

А еще можно интегрировать DevOps с открытыми инструментами для agile:

Источник