Купертино представила container machines - постоянные Linux-среды для macOS, которые обещают закрыть хронический разрыв между разработкой и продакшеном
Apple показала на WWDC инструмент, которого многие разработчики ждали давно. Container machines - это полноценные Linux-машины прямо внутри macOS, работающие как лёгкие виртуальные среды. Пишешь на Mac, деплоишь в Linux - и больше никаких неприятных сюрпризов на стыке двух систем.
Проблема, которую наконец заметили
Ситуация до боли знакома всем, кто разрабатывает серверные приложения. Рабочая машина - macOS, сервер - почти всегда Linux. Несмотря на общее Unix-прошлое, между системами хватает расхождений: библиотеки ведут себя иначе, пути отличаются, поведение демонов расходится. Docker и Podman давно закрывали этот пробел, но Apple решила предложить собственный путь - нативный и глубже интегрированный. ЧМ-2026 Португалия - Узбекистан
Container machines вошли в состав проекта Container, который компания впервые показала ещё год назад. Теперь вышла версия 1.0. В основе - стандарт Open Container Initiative, код написан на Swift, открыт на GitHub под лицензией Apache 2.0. Всё честно.
Как это устроено
Инструмент запускает и обычные контейнеры, и контейнерные машины внутри лёгких виртуальных машин. Изоляция между Linux-средой и основной macOS при этом жёстче, чем в классическом Docker. Команда container machine run открывает терминал прямо внутри Linux. Можно запустить и одиночную команду - она выполнится в Linux, а пользователь останется в оболочке Mac.
По умолчанию домашняя папка macOS монтируется с правами чтения и записи - файлы и код доступны сразу с обеих сторон. Удобно. Но есть нюанс: вредоносный пакет внутри Linux теоретически дотянется до ключей в .ssh. Поведение регулируется параметром --home-mount, самый параноидальный вариант - отключить общий доступ полностью.
С памятью своя история. По умолчанию машина получает половину ОЗУ, но расходует только то, что нужно. На практике: при 32 ГБ выделенной памяти реальное потребление после запуска PostgreSQL составило около 1 ГБ. Проблема в другом - занятый объём не возвращается macOS, пока машина живёт. Освободить можно только перезапуском.
Ограничения и конкуренция
Без шероховатостей не обошлось. Команда container machine create требует, чтобы в образе был /sbin/init - многие контейнерные образы под одно приложение этого компонента не содержат. Придётся собирать собственный образ через Dockerfile. Графические Linux-приложения пока тоже не поддерживаются нативно - в отличие от WSL в Windows, где X11 и Wayland работают из коробки. Apple предлагает обходной путь через XQuartz, но это уже танцы с бубном.
На рынке у Apple серьёзные конкуренты: Docker, OrbStack, Colima, UTM и удалённые серверы по SSH давно решают ту же задачу. Убедить разработчиков переключиться непросто. Первые практические тесты показывают: система работает быстро и ощущается лёгкой. Отладка Swift пока хромает - точки останова не срабатывают, тогда как .NET отлаживается корректно.
Пока инструмент больше напоминает экспериментальный проект для энтузиастов, чем готовый системный компонент: он живёт на GitHub, а не встроен в macOS напрямую, и поддерживает только macOS 26. Но направление выбрано верно. Если Apple доработает интеграцию и закроет дыры с памятью и отладкой - container machines вполне могут стать стандартом для Mac-разработчиков, которым не хочется тащить сторонние инструменты.
