Очень не люблю изобретать велосипеды. Но иногда обстоятельства складываются так, что иначе не выходит.

Эта история началась весной 2021 года.

Я много работал с Docker-контейнерами под Windows и страдал.

Страдал от того, как медленно запускается Docker Desktop.

Страдал от того, сколько он ест оперативной памяти.

Страдал от того, что постоянно что-то ломалось при обновлениях.

Страдал от того, что на Windows Server надо устанавливать Docker через какой-то особенный механизм, не работающий через proxy и не работающий на Windows Server 2016. Причём в связи с тем, что Docker Inc. передала enterprise-сервис компании Mirantis, этот способ через какое-то время вообще перестанет работать. В результате вы получаете Docker, собранный из непонятно каких исходников. Всё, что про них известно — они точно не такие, как в Docker Desktop. Вообще, для инструмента, задача которого — просто скачать один единственный пакет и установить его, в трекере задач этого проекта на удивление много багов.

Страдал от того, что Docker Desktop прекратил поддержку Windows 10 LTSC 2019, которая продолжает поддерживаться Microsoft вплоть до 2024 года (а расширенная поддержка — аж до 2029).

И я спросил себя: а почему, за что, как так? Есть ли какая-то такая фундаментальная причина, по которой софт, решающий эту задачу, обязан доставлять столько неудобств? И не нашёл её. 

А потому подошел к проблеме по принципу: если тебя что-то не устраивает, сделай это лучше.

После чего быстренько придумал название проекту и создал репозиторий.

Как это было

Работа велась в свободное время, а его было мало — отпуск, дача, основная работа, — поэтому дело двигалось крайне неспешно. В основном — в формате «думаю над тем, как можно было бы сделать».

А подумать было о чём. Ведь Docker Desktop решает несколько задач:

• Во-первых, нужно запустить сервис Docker внутри WSL. Для это нужно подготовить образ системы для WSL. Вариантов, как это можно сделать, несколько. Я остановился на следующем:

  • скачивается tar.gz с Alpine Linux,

  • импортируется в WSL,

  • устанавливаются нужные пакеты,

  • производится экспорт обратно.

  Сам Docker Desktop для сборки образов использует LinuxKit.

• Во-вторых, нужно как-то отправлять запросы от Docker-клиента, запускаемого на хост-машине, внутрь WSL. TCP для этого не подходит из соображений безопасности. AF_UNIX-сокеты под WSL2 не работают. Windows named pipes под WSL2 тоже не работают. Есть проект под названием npiperelay, но он хорош для сценария «Windows-процесс слушает named pipe, а WSL-процесс хочет к нему подключиться», а мне нужно было в обратную сторону.

  Решение получилось довольно простым: через stdin/stdout WSL. Финальная конструкция выглядит следующим образом:
  

  • На стороне Windows запускается процесс, который слушает named pipe;

  • Этот процесс запускает socat в WSL;

  • Socat подсоединяется к UNIX-сокету dockerd внутри WSL.

• В-третьих, нужно преобразовывать пути для bind-маунтов из Windows-формата в WSL-формат. Первой попыткой было использовать для этого Docker Engine SDK, но с ним обнаружился ряд проблем. Он не позволял прозрачно пробросить версию Docker-клиента, местами API не предоставляло достаточную гибкость, и вообще получалось очень много малосодержательного кода вида «перекладываем одни структурки в другие». Поэтому я спустился «на уровень ниже» и просто использовал ReverseProxy из Go.

• В-четвёртых, если почитать материалы в блоге Docker Inc., они часто пишут о том, что, среди прочего, Docker Desktop занимается пробросом сетевых портов из WSL на хост. Я думал, что это будет самой сложной в реализации частью. В Docker Desktop для неё используется VPNKit. Однако оказалось, что ничего делать не нужно, потому что в WSL2 открытые порты автоматически доступны с хост-системы.

Что случилось

Внезапно в августе 2021 Docker Inc сменила ценообразование и сказала, что компании должны платить за Docker Desktop по $60 / год с пользователя. 

Улучшилось ли при этом качество работы Docker Desktop? Я бы сказал, что нет. В качестве примера достаточно привести регресс-баг про panic.log, который оставался без починки с августа по ноябрь.

Как вы понимаете, это стало последней каплей. Ну и, кроме того, 8 марта 2022 года Docker Inc. вообще убрала возможность приобретения подписки для российских компаний, так что актуальность альтернативного решения еще больше возросла.

Итак, Stevedore

Stevedore находится здесь. Чем он отличается от Docker:

• Бесплатен;

• Имеет полностью открытые исходники под лицензией Apache 2.0;

• Поддерживает Linux- и Windows-контейнеры;

• Поддерживает клиентские и серверные редакции Windows;

• Чудовищно быстрый. Для сравнения (замеры производились на Intel Atom x7-Z8750):

  • Docker Desktop: первый запуск после установки — 78 с, повторный — 38 с;

  • Stevedore: первый запуск после установки — 12 с, повторный — 4 с.

• Низкое потребление ресурсов: 

  • Docker Desktop (WSL2) — 2GB RAM;

  • Stevedore (WSL2) — 0.5GB RAM.

• Установка через MSI-инсталлятор, пакет WinGet (winget install stevedore) или Chocolatey (choco install stevedore);

• Никакой телеметрии.

На текущий момент на разработку потрачено около 5-6 человекодней. Исходя из этого, стоит ли Docker Inc своих $60/год, можете решить сами для себя.

Видео с демонстрацией работы Stevedore:

Что в планах

•‎ Добавление поддержки Kubernetes.

P. S. Если вы ищете замену Docker Desktop под Mac, попробуйте Colima.