Привет, Хабр! На связи — любопытный DevOps Владимир Лила, и это вторая часть материала о девконтейнерах по мотивам моего доклада для DevOps Conf. Этот материал посвящён одновременно практике организации работы команды и инструменту, реализующему эту практику.

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

Небольшой спойлер: в этой статье вас ждёт небольшой полезный подарок!

Безопасность

Я обещал показать Python’овский Docker-файл. Он выглядит следующим образом:

На третьей строчке стоит FROM python. Это Docker-хабовский FROM python, к которому мы привыкли уже. 

А вот дальше — интереснее. Несмотря на то, что сейчас все сканируют на все возможные  уязвимости сами базовые образы, в шестой строке видно, что ребята удалили некоторые пакеты, потому что это такая-то уязвимость. Это навело меня на интересную мысль: можно организовывать процесс управления локальным окружением с участием безопасников и, возможно, команды платформы, если вы в крупной компании и у вас есть свои платформы. То есть можно предподготавливать образ, который будет устраивать всех.

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

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

Также у них появляется возможность мониторить, что за image используются, где, кем, откуда, туда вшивать какие-то метрики и так далее. Конечно, они могут в свою CLI вшить, какой метод вы подёргали, но тут в рантайме можно хоть в Кроне запускать подобное. Все паттерны, шаблоны, гайды туда вшиваются и отдаются команде разработки — возьмите и будет вам хорошо. Они же могут договариваться с ИБ для того, чтобы это всё ещё было безопасно, и встраивать свои пайплайны в это. 

Есть ещё классные идеи работы с Dev Containers. 

Например, есть видео о том, как ребята разрабатывали embedded девайсы на «плюсах». Им было очень сложно строить именно этот билд-сервер. Они его засунули в DevContainer и прямо в нём теперь разрабатывают. А раньше у них была одна машина, на которой они дышать боялись.

Мне очень понравилось использовать Dev Container для Ansible, который мы с командой используем как локально, также и  запускаем его на CI, просто потому что хочется быть на 100% уверенным, что это будет одно и то же окружение. Пускай оно весит больше, чем нужно для CI, но эта уверенность очень дорогого стоит. 

Если у вас есть Open Source проекты, добавьте туда Dev Container. Очень классно, когда приходишь в Open Source проект и там есть Dev Container — ты просто стартуешь и начинаешь разрабатывать, не занимаясь настройкой окружения. 

Я много говорил про x86, ARM, страдания с Mac и так далее.

Dev Container помогут вам с ARM в любом варианте. В том числе, когда вы, например, не готовы к ARM, но при этом по каким-то обстоятельствам вам нужно запуститься на ARM. Или у вас пришёл разработчик с Mac и упёрся лбом и сказал, что никак иначе, вы можете собрать ему Dev Container в x86, отдать, он его через Rosetta запустит. У него даже бинари x86 будут работать, ему не надо будет каждый отдельный бинарь пытаться как-то запустить в режиме эмуляции. 

В другом случае, когда вы готовы к ARM, можно собрать Dev Container на CI через схему, двумя образами (тег –platform как в докере), залить их в свой registry и каждый будет пользоваться нативной версией девконтейнера под свою аппаратную архитектуру.

Если вы перейдёте уже к Cloud IDE для разработки в браузере и так далее, то машины на ARM могут быть (а могут не быть) дешевле, и на этом можно сэкономить. Так что здесь Dev Containers отлично помогают. 

У меня есть небольшой подарочек

Нет нормального Dev Container для Ansible, поэтому мы сделали свой. Он готов к тестам, Molecule, Docker и т.д.. Замечательно работает, сами пользуемся. В команде его выкристаллизовали. В нём как раз есть фича, про которую я сегодня рассказывал, утилиты HashiCorp ставятся в России. 

А минусы будут?

Конечно, есть минусы. И речь здесь пойдёт о виртуализации на Windows и MacOS.

Мы знаем, что на Маке и Винде у Docker работает через виртуалки — как там с перформансом вообще? 

Я взял проект Jellyfin (сам им пользуюсь). Это популярный медиасервер вроде Plex, написанный на .NET 8.

Попробуем на моей старой железке выполнить dotnet clean, dotnet build, то есть просто побилдим и посмотрим, насколько сильно просядем. 

Запускаем. 

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

Я склонировал репозиторий внутрь Windows и запускал его внутри Windows нативно и в Dev Container. Так делать не стоит, если вы работаете на Винде. Просто переместите этот репозиторий внутрь WSL, и внезапно фактически ничего не потеряете. 

Тут уже можно говорить про какую-то погрешность и так далее, но результаты совершенно другие. Поэтому не работайте с DevContainers из Windows окружения из-за разницы NTFS и линуксовых файловых систем. Производительность просто в трубу улетает, так делать не надо. 

Теперь пойдём на Mac. Возьмём стандартный Docker-desktop, Mac M3 Pro, 18 гигов, мощная машинка. Занимаемся абсолютно тем же самым, commit один и тот же. Настройки Docker-desktop стандартные, никакого legacy, никакой беты.

Всё как предлагается, так и берём. Пробуем запускаться и видим такие результаты:

Они тоже не очень хорошие, мне не нравятся. Но прелесть заключается в том, что не Docker-десктопом единым, есть замечательная штука OrbStack. 

Если кто не знает про OrbStack, искренне всем советую перейти на него, потому что когда я перешёл, вообще забыл, что вентилятор и нагрев существуют. 

Я очень долго думал. Там было прогонов 40, я больше часа потратил на этот слайд. Я бился, бился, но это стабильно. Поэтому OrbStack — это магия вне Хогвартса. Я не признаю магию, но, тем не менее, пользуюсь.

Удалённая разработка

Если мы в том же самом проекте на Docker Hub нажмём точку (нужно быть авторизованным и нажать буквально клавишу точки на клавиатуре), появится окошко создания — Workspace.

Здесь у ребят даже два Dev Containers. Но после того, как мы перейдём и спросим конкретику, нам предложат из host requirements (даже написано, что это взято оттуда), какой instance нам подойдёт для нашей разработки. 

Уточнение: 20 часов на одно ядро — бесплатно, то есть в зависимости от количества ядер у вас будет сколько-то бесплатного времени. У нас есть аналоги.

GigaIDE сделали VS Code — также есть бесплатный тариф, его можно использовать.

Я вывел только средние результаты: что вам дали, так и компилируется. Дадут что-то мощное — будет быстро, не дадут — будет долго. Но есть ещё одна проблема.

Место на диске пропадает быстро

При подготовке этого материала мой компьютер в итоге выглядел так. 

Почти половину занимали данные от Docker. Ничего страшного в этом нет. Во-первых, я слишком много с этим игрался. Во-вторых, скорее всего, у вас будет 1 образ для разработки всего.

Ещё у нас есть замечательная команда Docker system prune -af, которая просто вычистит это всё. Плюс, в самом «управляйке» Docker’ом можно зарезать сверху, чтобы он больше какого-то объёма не занимал, если для вас это важно. Также вычистить всё из Docker гораздо проще с локального компьютера. 

Есть ещё некоторые проблемы с эмуляцией x86, но я тестирую очень специфичные образы, кластера Elastic на локальной машине, в пять конейнеров. Я не удивлён, что они существуют и что-то из этого выпадает, но опять же есть какие-то решения — включить Rosetta, выключить Rosetta и т.д. Что-то из этого помогает, но пока есть вопросы.

Давайте подытожим — плюсы

• Онбординг сводится к строке: поставьте Docker и IDE и запустите проект в контейнере. Тестировщики и аналитики в восторге. 

Онбординг у нас теперь одна кнопка — установи Docker и установи IDE с поддержкой Docker, вот и весь онбординг. Он не протухнет на веки больше. 

• Изменение инфраструктуры одним разработчиком — работает у всех. 

Это куча экономии на поддержку и актуализацию всей инфраструктуры. 

• Не хватает ресурсов — запускайте Dev Container удалённо. 

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

• Платформисты могут использовать Dev Container для решения своих задач. 

Безопасники и платформисты могут вмешиваться в процесс, выстраивать красоту и делать для вас в безопасности тулинг, а вы его будете использовать просто как кнопку.

• Переключение проектов за единицу. 

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

• Уже готово к ARM и может помочь на первых порах для заезда. 

Готово к RAM в любых вариантах — и в случае, когда вы к нему готовы, и в случае, когда вы не готовы. 

• Self hosted и отсутствие вендорлока. 

Никакого вендорлока, никаких подниманий, абсолютно ничего нового. Это те же самые Docker images. 

• Общий знаменатель между операционными системами. 

Самое классное — где бы вы ни работали, вы будете работать в едином environment. Больше никаких cmd-скриптов только для windows, cross-env пакетов для npm (кто знает, меня поймет). У вас единые инструкции, никаких «если у тебя Винда», «если у тебя Винда 98» и так далее. Всё едино — один раз написали и поддерживаете.

Если хотите узнать больше — подписывайтесь на мой Telegram-канал.

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

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

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

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