Онбординг — один из важных аспектов, требующих особого внимания при масштабировании компании. А теперь представьте, что у вас есть универсальный инструмент, который помогает закрывать целый класс задач команды разработки: настраивает локальное окружение проекта одной кнопкой,  унифицирует окружение для всех разработчиков на разных ОС, обеспечивает безопасность инфраструктуры, упрощает CI и многое другое.

Всё это — девконтейнеры! Да, мы начинаем программировать прямо в контейнере. И всё это бесплатно и без необходимости развёртывания новых сущностей в вашей организации. О такой кнопке «сделать хорошо» мы и поговорим в этой статье по мотивам моего доклада для DevOps Conf. 

Привет, Хабр! Я — Владимир Лила, любопытный DevOps. И я всегда переживал о том, что у нас нет механизма, чтобы хорошо описать инфраструктурой как код локальное состояние машины разработчика. Сегодня такой инструмент есть, и он уже не в бете. Я не буду вам рассказывать про альфа-штуки, он абсолютно адекватно поддерживается и работает. Об этом сегодня мы и будем говорить. 

Начнём с ключевых сложностей

С чем мы сталкиваемся в первую очередь?

  • Онбординг с устаревшей информацией

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

  • Настройка окружения в несколько дней

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

  • Операционные системы: «Ой, у тебя Мак/Винда/Linux? Мы на таком не работаем»

А если у вас ещё и Mac, и скомпилировано под x86, то удачи! Многие привыкли работать на своём крутом оборудовании.

  • «А мы тут добавили очередь/кэш/эластик/обновили базу...» 

Ситуация: возвращаетесь из отпуска, у вас всё было настроено, но вы в активной развивающейся команде. Вы пришли, поставили базу, обновили, добавили кэшей, еще чего-то. Вам нужно обновлять ваше локальное окружение, чтобы догнать вашу команду. Естественно, никакой доки это нет.

  • У вас много проектов, и в них нужна разная настройка версий ЯП и т. д.

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

  • Настройка для тестировщиков, аналитиков, дизайнеров

Для них развернуть локальное окружение — это совсем больно. Приходится выделять отдельные стенды под такие задачи.

Короткая историческая справка Open Source до Docker: 11 лет назад (2014)

Выглядело это следующим образом: есть документация о том, как установить этот замечательный продукт — UpInstall, какую операционную систему использовать, какие пакеты устанавливать, и парочка костылей в виде скриптов, чтобы «облегчить жизнь», которые все усложняли. Затем пришёл Docker и всё изменилось.

Теперь, с приходом Docker гигиенический минимум у нас такой:

  • Готовое демо продукта saas, чтобы можно было сразу понять, как всё выглядит на деле, а не на картинках.

  • Собранный docker image.

  • Развернуть на потестить в одну команду (docker-compose).

  • Автоматика на GitHub CI + боты. 

  • Облачная IDE (GitHub workspaces). 

Но если посмотреть на ситуацию с разработкой, когда вы приходите в какую-то опенсорс-утилиту и у вас есть один вечер на то, чтобы поправить в ней баг, то вы до сих пор читаете Contribution Guide, устанавливаете то, что там сказано (нужные версии ЯП, библиотек, env, системные пакеты). Кажется, что революции докера тут не произошло. Сейчас про нее расскажу. 

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

Но не так много сделано для того, чтобы изначально правильно все настроить в IDE, чтобы сразу вам подсказывало, как всё делать и именно это я и предлагаю исправить! Спойлер: позже это будет в нашей IDE. 

Что такое Dev Container

Банальность — это разработка внутри Docker-контейнера, ничего нового.

Docker даёт нам изоляцию и повторяемость. Если вы один раз настроили правильно вашу среду, то у всех разработчиков она одинаковая. Мы просто складываем всё, что нам нужно (весь environment, весь tooling) в контейнер и подключаем IDE к контейнеру.

У нас был старый мир, где на хосте всё на свете — SDK, языки программирования, все наши пакетные менеджеры, 10 Python. В новом мире на хосте мы оставляем только Docker и IDE, которая умеет к этому Docker подключаться. Всё остальное находится внутри контейнера. 

Важно отметить, что когда я говорю о DevContainer, я не говорю о расширении в VS Code или каком-то конкретном тулинге — я говорю о спеке. Есть коротенькая спека на официальном сайте, которую вы можете посмотреть. Её поддерживает и активно развивает Microsoft, потому что Microsoft занимается разработкой своих редакторов кода.

Что приятно, нет никакого вендор лока — это открытая спека, которую любые IDE могут себе втянуть и начать работать по ней.

Но есть нюансы. Например, в JetBrains это работало только в Ultimate. Во всех Microsoft везде работает идеально. В Cursor это тоже отлично работает, как и в наших форках — и JetBrains, и VS Code.

В GigaIDE Desktop пока не работает на последней версии, которую можно установить.

Составляющие Dev Container

Что из себя представляет спека? На самом деле, в ней много всего: 

  • Файл манифеста devcontainer.json 

Это основной файл, о котором будем говорить. Он должен лежать в папке .devcontainer/devcontainer.json, чтобы вся магия сработала. Про магию чуть дальше. 

  • Предсобранные контейнеры

Microsoft не просто написал спеку, а положил её на красивый сайт — и на этом всё. Также они построили целую фабрику по билду актуальных образов для разработки. Это не те образы Python, которые мы знаем в Docker Hub, а те, в которых удобно и приятно разрабатывать.

  • Dev Container Features 

Краеугольный камень того, почему это не просто Docker-образы, а что-то большее. Это красивый способ установки софта в такие image. Про него сегодня будет очень много. 

  • Template 

Это про возможность развернуть более одного контейнера. Когда вы разрабатываете, вам, наверное, нужны БД, кэши, очереди и так далее. Это все про Templates.

  • Collections

Просто список авторов на официальном сайте, которые что-то делают в рамках DevContainers. Если вам чего-то не хватает официального — можете найти там то, что нужно. 

Перед тем, как поговорим дальше про Dev Container, немного разберёмся в способах их организации.

Способы организации

Существует два способа, как можно организовать локальное хранение DevContainers. 

Здесь более понятна аналогия с venv в Python, когда у вас лежит venv где-то в home-директории и вы с помощью неё открываете любые проекты. Например, мне как девопсу это очень удобно для Ansible.

Таких контейнеров может быть множество. Это можно использовать как замену всяким тулам по переключению языков программирования (NVM, Volta, pyenv). 

Второй способ — когда вы храните Dev Container в Git, синхронизируете с командой и получаете все преимущества того, что один что-то поменял в файлике, и у всех обновленное окружение автоматически настроилось.

Упакуем репозиторий в Dev Container

Пройдёмся по стартер-гайду и посмотрим, насколько сложно пустые проекты запаковать в Dev Container и что для этого нужно. Делать будем на примере VS Code. 

Расширение Dev Container не предустанавливается вместе с VS Code, потому что это проприетарный код — его даже на GitHub нет. Он очень сильно завязан на облака Microsoft (не выкладывается в Open Source), но вы можете его установить.

После установки расширения (оно так и называется — Dev Containers), у нас появляется возможность создать наш конфигурационный файл (слева — пустая папка).

Когда мы переходим сюда, нас спрашивают, мы хотим положить это в home-директорию либо в текущую директорию, синхронизировать его с Git и этим всем заниматься. Конечно, мы будем его синхронизировать с Git. 

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

Есть официальные (с галочкой) образы, которые предсобраны. Python, естественно, здесь не единственный пример. Вы можете указать любой образ с Docker Hub, с вашего Nexus, откуда угодно. Это просто указательный image. 

Говоря о том, что сейчас собирается, отмечу, что сборка идёт в разных итерациях. Это может быть Python с Anaconda, Python без Anaconda, Node.js классический, с TypeScript и так далее. 

После того, как мы выбрали image, нам предстоит выбрать тег. 

На теге остановимся чуть подробнее. Тегирование очень важно для того, чтобы понимать, что перед вами.

Python 3 не очень хорошо объясняет, с чем конкретно мы имеем дело, а вот такое тегирование “3.13-bookworm” чуть лучше показывает, что у нас, как минимум, Debian. Мы даже знаем, какой версии, и при этом знаем, какой язык программирования перед нами. Это хороший пример тегирования.

Microsoft собирает всё таким образом, что вы можете управлять готовностью продукта как к новой версии ОС, так и к новой версии ЯП. Если будете собирать свои image для локальной работы в вашей организации, это хороший пример тегирования. 

После такого несложного гайда мы увидим один файлик (манифест) и в нем два поля. 

Самое важное, почему я здесь привёл полное окно — у нас появилась всплывашка (справа внизу), которая говорит о том, что она обнаружила Dev Container и предлагает прямо сейчас пойти и в него переоткрыться. Что это значит? Когда мы нажмем на «Reopen in Container», у нас спулится image, который мы указали с майкрософтовского хаба, наша файловая система в него смонтируется и VS Code перезагрузится внутри него. 

Слева снизу две стрелочки выделены цветом. Там будет просто надпись «Python 3», что мы находимся внутри контейнеров. 

В продуктах JetBrains это выглядит абсолютно идентично.

Открываем какой-то репозиторий, переоткрываемся, и мы в контейнере. 

IDE выглядит абсолютно так же.

Здесь хочется отметить, что обычно image любят собирать с тегом latest. Это очень плохо для паттерна, когда вы разрабатываете локально: если вы укажете image latest в devcontainers.json, то у IDE не будет никаких шансов понять, что что-то изменилось.

Условно, у вас есть где-то CI, которая билдит этот образ каждую неделю, устраняет уязвимости, а разработчики об этом ни сном, ни духом. У них локальный образ есть, никаких изменений в файле нет. Поэтому лучше использовать конкретные timestamps или любые расширенные именования для того, чтобы вы приходили в этот файл и изменяли его. Тогда человеку, вставшему на этот commit, IDE скажет об изменении окружения и попросит спулить новый Docker образ. Она его будет каждый раз этим окошком утомлять, он однажды всё-таки нажмёт да и будет на актуальной версии окружения. Поэтому тег latest здесь не подходит. 

Когда мы получили единую операционную систему, единый environment, можно сконфигурировать саму IDE.

Конфигурируем IDE для кастомизации под проект

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

Рассмотрим сначала на примере VS-кода.

Сеттинги и раньше можно было положить прямо в проекты, они бы подтянулись. Но раньше в проект нельзя было положить extensions. Можно было положить requirement extensions и качать или не качать. Есть кнопка, которая один раз всплывает — потом не найдёте. Поставите вы их или не поставите, никто не проконтролирует. А самая большая проблема — когда вы начинаете много с чем работать, весь vscode превращается в какую-то помойку. У вас очень много расширений для всего, и они конфликтуют с друг другом. Решением этого стали профили, но до этого приходилось дикой магией заниматься.

Здесь же ситуация вообще другая. После инициализации вы получаете чистый VS Code, который точно установит эти extensions. Все настройки могут быть очень тонко связаны с этими extensions, и вы получаете повторяемую среду, которая нормально протестирована и работает. Нет конфликта между расширениями, и нет лишнего мусора.

Как это выглядит:

В локальном VS Code можно оставить темы, шрифты, настройки быстрых клавиш, к которым вы привыкли, удобства и так далее. А всю суть и задачу по тому, что конкретно будем делать, уже засунуть в расширение DevContainer, который будет отображаться в отдельной вкладке.

Самое приятное здесь — экономия времени. Кто-то один, кто лучше погружён в детали локальной настройки, может это сделать и поддерживать, а все остальные будут этим пользоваться. В случае чего можно откатиться на предыдущий коммит и всё работает.

В случае с JetBrains ситуация аналогичная.

У нас есть плагины и сеттинги. Здесь ещё нужно указать бэкенд, потому что у различных IDE он разный, просто у Rider — Rider, у WebStorm — WebStorm. Из приятного — vscode и jetbrains  между собой не конфликтуют по конфигурации 

Если у вас разработчики разрабатывают во всех ide, сделайте большой конфиг для всех IDE. Может быть, даже будут какие-то готовые решения для этого позже (как получилось с линтерами).

В файле манифеста, помимо того, о чем уже рассказал, можно также указать всё, что имеет отношение к запуску Docker-контейнера:

  • forwardPorts 

  • mount 

  • postCreateCommand 

  • containerEnv 

  • hostRequirements

Важным здесь является только hostRequirements, он выделяется. Это некоторые лимиты хоста, и вы, возможно, подумаете, что это физическое ограничение на объём ресурсов, запуск с меньшими из которых будет недоступен (типа реквестов в k8s). Но на деле это не так, и локальный запуск игнорирует эту настройку. Она сделана для того, чтобы если вы стартуете такой image в облаке, он прочитал и понял, какой инстанс в облаке вам подойдёт. 

Теперь, когда у нас одинаковое IDE и одинаковое окружение, мы можем притащить в наш Python кучу софта.

Dev Container Features: способ установки нужного софта

Для разработки нам нужно много софта (источник):

  • CLI для s3, helm, k8s, vault, terraform, redis etc. 

  • Глобальные пакеты от nodejs/python (ncu, prisma, nest, etc.) 

  • Apt пакеты (curl, jq, ncdu, ping, nmap, htop, etc.) 

  • Да много чего ещё! 

Поскольку мы до сих пор работаем с Docker-контейнером, можем притащить софт, просто дополнив Docker-файл. То есть в какой-то файл from Python положить всё, что нужно. Но это будет очень сильно разрастаться, выглядит не очень поддерживаемо и «лапшично».

Но можно сделать это в том же файле — в контейнере JSON определяем раздел features. По названию фич можно примерно понять, что они делают.

 Рассмотрим пример:

Пакеты устанавливают то, что сказано, всё понятно сразу же. 

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

Там может быть переносимость на разные аппаратные архитектуры (ARM, x86). Можно поддерживать разные дистрибутивы внутри фичи. Понятно, что АРТ-пакетами CentOS не поддержишь, но можно использовать другую фичу или сделать её как common. Можно их переносить между разными базовыми образами. 

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

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

Но как это вообще работает? 

Давайте посмотрим внутрь фичи и попробуем написать свою. Язык программирования в Docker-файле у нас по умолчанию только Bash.

Всё, что нам нужно знать для фичей, это два файла:

  • devcontainer-feature.json — файл манифеста, который описывает, что это такое, как оно себя ведёт, параметры и дефолты. 

  • install.sh — описывает поведение того, что нужно сделать.

Выглядеть это может в простом варианте так:

Это моя фича, когда я писал скачивание Terraform-утилит с зеркала в России. Здесь в зависимости от нужной аппаратной архитектуры скачиваем необходимое, распаковываем, устанавливаем и удаляем изначальный архив. Это, по сути, весь install.sh, а использование такое:

Я решил передавать форматы через запятую, чтобы была полная инфраструктура как код — никаких latest, никакой самодеятельности. Чтобы начать — достаточно форкнуть офицальный репозиторий стартер гайда.

В репозитории уже готово всё, включая скрипты workflow по сборке, по push. Но можно этим не заморачиваться и фичу положить локально — всё будет собираться прямо в вашем репозитории рядом с файликом Dev Container.

Посмотрим на содержимое файлов.

Здесь два файла devcontainer-feature.json и install.sh, автосгенерированный README и .tgz. Архив, по сути, это «собранное» состояние фичи, готовое к распространению. Чтобы собрать такой архив, вам не нужно самостоятельно набирать команды в терминале, для этого существует DevContainer CLI. 

NPM-пакет на TypeScript он уже лежит в Open Source. Он же используется внутри VS Code и взаимодействует со всеми командами, которые связаны с DevContainer. Это и их билд — вы можете сбилдить этот контейнер и получить на выходе готовый обычный image, и работа с фичами. То есть он умеет её собирать, распаковывать и так далее.

Очень приятно, что ребята подумали о людях с ARM и дают возможность прокинуть известный тег platform, который позволяет собрать сразу image под нужную архитектуру и тут же его запушить.

Заглянем под капот Dev Container в фиче, что в image.

Мы видим для каждой из фичей install.sh, просто распакованный в виде слоя. Там будет каша из того, что нужно сделать, он просто выполнится. 

Здесь есть важный момент — одну и ту же фичу использовать дважды не получится. Они пересекутся по именам и последняя просто перезатрёт первую. Поэтому при её проектировании и использовании думайте о том, чтобы передать в неё все параметры один раз. 

Здесь появляется следующий момент. 

Раньше, когда мы запускались, у нас получалась очень простая схема. Мы просто спуливали image, монтировали файловую систему. Всё запускалось отлично, быстро работало со скоростью пуллинга образа.

Теперь же у нас ситуация другая. Мы спуливаем, но после этого у нас начинают отрабатывать фичи. Их имплементацию мы можем, конечно, посмотреть, потому что они Open Source, но они могут куда-то ходить, чего-то делать, в них могут быть какие-то уязвимости. Поэтому в целом сборка затягивается, локальный старт становится дорогим и сложным. 

Есть смысл в том, чтобы отделить эту красоту инфраструктуры как код, вынести в отдельный репозиторий, прикрутить к нему CI, а на выходе получать уже image с определённой датой и его использовать у себя в проекте, тоже в devcontainers.json. Тогда у вас снова старт будет со скоростью спуливания, вместо того, чтобы греть свой ноутбук сборкой утилит. Плюс в некоторых инструментах я указал latest, поэтому то, что мы сбилдим, от раза к разу будет изменяться. Это плохо. Здесь тоже latest лучше не использовать.

Предсобранные Dev Containers. Microsoft заботится

Теперь поговорим о том, как выглядят предсобранные Dev Containers, которые как раз Microsoft собирает. Пример заботы — файл Python, на котором я делал все примеры. Это файл devcontainer.json для Python, который лежит на GitHub.

В третьей строчке видно, что используется некий dockerfile. Я его чуть позже покажу, когда о безопасности будем говорить. А сейчас хочу обратить внимание, что поверх этого dockerfile просто накладываются фичи. Первая — это common, которые, как можно понять, тут настраивают юзеры. Они настраивают ему Zsh, и на этом всё. 

Дальше есть две фичи в позиции none. Python здесь в позиции none, потому что мы и так берём Python. Ещё у нас есть в операционке Python. Если вы Python туда фичой привезёте, там будет переизбыток Python.

Также устанавливается Git. 

По сути, так выглядят все предсобранные Dev Containers — что-то базовое, поверх накинутые фичи, и готово.

Здесь есть момент заботы. Customization, vscode, setting указывают на правильный интерпретатор Python для VS Code. Так происходит, потому что у нас есть Python в ОС и есть Python в образе, который мы установили. Это два разных Python, у них два разных пути. Если этого не указать, то VS Code может начать по venv обращаться не к тому Python, который мы ожидаем.

Больше одного контейнера: кеши, базы, очереди, и не только

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

Уже готовые наборы взаимодействия нескольких приложений (https://containers.dev/features):

  • Python + Postgres 

  • C# (.NET) + MS SQL 

  • Node.js + Mongo DB 

  • И любые вариации

Выглядит это так: в той же всплывашке, где мы выбирали image, были те же Python + Postgres, Python + Mongo и так далее. Я взял Python + Postgres.

Есть изменения — вместо двух полей стало четыре, одно из которых теперь отвечает за то, где у нас лежит docker-compose файл, в котором описывается все наше окружение. Совершенно обычный compose, ничего нового.

Важное указание здесь в шестой строчке — "service":"app" — это указание на имя контейнера в docker-compose. 

Нужно указать, кто из всех контейнеров — наш DevContainer, к которому будем обращаться. Потому что в файле devcontainer.json  есть ещё и  фичи (в 10 строчке описываются). Их нужно применять к какому-то конкретному контейнеру. И будет не здорово применить их к базе данных.

workspaceFolder — это куда монтировать директорию, с которой будем работать. 

Здесь есть очень приятный момент.

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

Советы из жизни в Dev Container: решаем общую боль

Эти советы мы выработали, когда внедряли Dev Container у себя в команде. Расскажу, где споткнулись и как полечили. 

Dotfiles

Первое, обо что вы спотыкаетесь, когда начинаете работать, это dotfiles (файлы, начинающиеся с точки, и содержащие в себе конфигурацию тулов и оболочки).

Dotfiles как воздух — пока мы их не видим, всё работает замечательно. Как только вы переключаетесь в Dev Container, у вас там Git не коммитит, ssh не подключается и так далее. Всё становится очень грустно, и возникает вопрос, как решить эту проблему. 

Есть утилита stow, которая делает очень простую штуку. 

Вы находитесь в папке .dotfiles, где лежат все ваши dotfiles (мы так договорились). Если утилиту stow запустить, находясь в этой папке, она сделает симлинки наверх на один уровень. Выглядит это следующим образом:

Я сейчас в home-директории, все симлинки и из dotfiles приехали в мою home-директорию. Это даёт ряд преимуществ. Во-первых, можно внутри dotfiles организовывать git-репозиторий, коммитить там, версионирование и т.д.. Во-вторых, это позволяет сделать магию. 

Мы устанавливаем эту утилиту через apt-пакет, потом через mounts указываем, что эту директорию мы смонтируем внутрь контейнера, а postCreate командой указываем, откуда и куда нужно развернуть симлинки.

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

Алиасы

Я любил писать алиасы в основном в rc-файлы (bashrc, zshrc и пр.), просто так привычка сложилась. Очень хорошо выделить в отдельный файлик, назвать его .bash_aliases, потому что основные оболочки будут пытаться его вычитать. Если выложить его отдельно, то какая бы оболочка у вас не была в контейнере, с большой вероятностью она просто вычитает, и вы получите свои алиасы внутри контейнера, у вас все будет работать хорошо. Нужно лишь точно сохранять имя файла.

Важно: через симлинки не нужно подключать rsa ключи для  ssh, потому что они чувствительны к правам доступа. Например, даже здесь ssh мы монтируем в отдельной директории. 

Но я думаю, что папка ssh у всех есть, так что здесь не должно быть проблем. Но, если что, опять же с помощью preCreateCommand её можно сделать. 

В следующей части мы рассмотрим вопросы, связанные с безопасностью, виртуализацией на Windows и Mac, удалённой разработкой, местом на диске и т.д.. Если хотите узнать больше — подписывайтесь на мой Telegram-канал.

А в ожидании второй главы вы можете ознакомиться с материалами профессиональной  конференции по интеграции процессов разработки, тестирования и эксплуатации DevOpsConf 2026!

Команда DevOpsConf в этом году честно признала: формат «послушал — вдохновился — пошёл применять» больше не тянет. Индустрия изменилась. И мероприятия тоже должны. Поэтому DevOpsConf 2026 прошёл в новом формате — «конференция развития».

Вместо классической разбивки «зал про ИБ», «зал про Kubernetes», «зал про мониторинг» появились стримы развития — срежиссированные тематические маршруты по конференции. Они направлены не на ознакомление с вопросом, а на решение проблемы.

Один стрим развития — одна тема, которая раскрывается последовательно через разнообразные форматы (мастер-классы, игры, дискуссии и т.д.). При этом доклады никуда не ушли! А чтобы узнать подробнее, переходите на официальный сайт мероприятия.