Ох с чего бы начать…

Предисловие

Я очень надеюсь, что мои приключения ниже — это демонстрация моей тупости, и всё дело в том, что я просто “держу этот ваш Docker Desktop неправильно”. Если вы знаете решения моих проблем, пожалуйста, дайте знать!

compose is not a docker command.

Живу я спокойно со своим Docker Desktop и горя вроде бы не знаю. Контейнеры работают, docker compose прекрасно поднимается и опускается. Но однажды при попытке выполнить docker compose, я получаю сообщение docker: 'compose' is not a docker command. Внезапно оказывается, что тот docker compose, который v2, который плагин, куда-то исчез и больше недоступен. Вместо него у меня остался только docker-compose который через дефис, который v1, который legacy, и который я не хочу пользоваться.

Эта проблема случалась у меня дважды на личном ноутбуке, и недавно случилась в третий раз, уже на рабочем. Каждый раз она случалась в достаточно неожиданный момент времени, и я не мог отследить причину. Возможно, это происходило после обновления MacOS. Возможно, при brew upgrade. Возможно, при обновлении самого Docker Desktop. Я так и не понял…

Ну окей, ну пропал compose и пропал, давайте назад поставим! А как? Документация говорит, что он идёт вместе с Docker Desktop. Но Docker Desktop то у меня никуда не делся и даже утверждает, что compose на месте! Что делать? В документации такой кейс не описан вовсе.

/Applications/Docker.app/Contents/MacOS/uninstall.

Если compose поставляется с Docker Desktop, то давайте попробуем переустановить Docker Desktop! Каждый раз я прихожу к этой идее, но каждый раз всё меньше в неё верю.

Для того, чтобы переустановить, Docker Desktop нужно сначала удалить, логично? В целом, мне нравится подход MacOS к установке и удалению ПО. Тут есть несколько типов приложений:

• те, что вы устанавливаете через App Store и можете удалить тоже через App Store;
• те, что вы установили перетаскиванием в /Applications и можете удалить перетащив их оттуда в корзину;
• те, что вы установили с помощью пакетного менеджера и можете с его же помощью удалить.

Красота же! Да? Только вот Docker Desktop это одно из немногих приложений, с которыми всё не так просто. Хоть вы устанавливаете его просто перетащив в /Applications, удалить его так просто уже не получится. При первом запуске он пишет столько всего в кучу разных мест, что после удаления самого приложения у вас останутся и контейнеры, и образы, и конфиги, и файл сокета, и много чего ещё!

В документации рекомендуется начать процесс удаления с Troubleshoot > Uninstall в приложении. И я помню, что я так делал! Но забавно, что в последней версии весь раздел Troubleshoot исчез… Его просто нет, как и той самой кнопки Uninstall. Может он переехал куда-то, но я, хоть убей, не могу найти кнопку, на которую нужно нажать по тексту в документации!

Ладно, чёрт с вашим Troubleshoot. Давайте пропустим этот шаг. Пишут, что можно из терминала запустить команду /Applications/Docker.app/Contents/MacOS/uninstall и эффект будет тот же. Только вот эта команда падает с ошибкой Error: unlinkat /Users/mchernigin/Library/Containers/com.docker.docker/.com.apple.containermanagerd.metadata.plist: operation not permitted… Хмм… Так ты от рута запусти, прав же не хватает! А вот и нет: от рута всё то же. И сам я удалить этот файл почему-то не могу даже с sudo. Так может и забить на этот файл? Может. Но только я не понимаю, упал ли скрипт на середине или он сделал всё кроме удаления этого файла? Ответа я так и не нашёл.

Что мы имеем. В документации 2 способа удалить Docker Desktop — первого не существует, а второй не работает. Что будем делать? Не будем следовать документации. Давайте удалим вообще все папки, которые хотя бы похожи на артефакты существования Docker. И вы не поверите, как же много в интернете статей на эту тему. А самое главное, что в каждой свой набор директорий для удаления! Я всё же выбрал одну, самую полную, как мне показалось, и поудалял всё что в ней упоминалось.

Фух… Осталось поставить назад и теперь то docker compose ко мне вернётся! Эта мысль была слишком наивной. Установив Docker Desktop заново, я вернулся ровно в ту же точку, что в начале этого акта: работает только legacy docker-compose. Значит, что где-то всё-таки остались какие-то файлы… Или дело вовсе не в остатках файлов, а в версии самого Docker Desktop… Но я ведь не какую-то beta скачиваю, это же стабильны релиз, который сотни раз был протестирован уже… Да?

Homebrew?

У вас может сложиться впечатление, что нужно остановиться с Docker Desktop и поставить Docker из Homebrew, ведь он там есть! Но с версией из Homebrew проблем ни чуть не меньше. Как пишется в ответе на вопрос 10 летней давности, в Homebrew находится другая версия docker, которая требует VirtualBox, и вообще рекомендуют всё-таки использовать Docker Desktop. Да и на самом сайте docker.com нет никаких упоминаний других методов установки.

Я всё же пытался когда-то запустить Docker из Homebrew, но у меня не вышло… По-моему были проблемы как раз с docker-compose опять.

< Тут я сдался >

Ничего не происходит.

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

Казалось бы, инструкции всё те же — скачиваете Docker Desktop, запускаете, прокликиваете Далее и готово. Но тут случается то, к чему я не был готов, а если точнее — не случается ничего. У обоих аналитиков при запуске Docker Desktop не происходит абсолютно ничего! Чистые маки, на которых никогда не было раньше Docker, официальный сайт и стабильная версия — и ничего. Точнее какой-то процесс у них запускается, но демон — нет, как и само окно приложения. Иконка в трее тоже не появляется. И ждать не помогло. По крайней мере, дольше 5 минут мы ждать не стали.

В чём же было дело? Я всё ещё без понятия. Это ещё один какой-то абсолютно непонятный кейс неработоспособности Docker Desktop. Так ещё и у 2-ух людей подряд! Так что мы с ними отказались от Docker.

Нет так нет.

Это уже стадия принятия. Принятия того, что с Docker Desktop кашу не сваришь, и пора бы пойти пробовать альтернативы. И благо они есть. Самая популярная такая альтернатива — это Podman. И именно на него я пересел сам и подсадил аналитиков в своей команде. Почему? Потому что Podman работает.

Если посмотреть на установку — её можно сделать через Homebrew! Просто brew install podman podman-compose и готово! Ну почти. На самом деле, нужно сделать ещё одно действие: создать и запустить виртуальную машину, в которой будут запускаться контейнеры. Но и это делается очень просто: podman machine init && podman machine start. Теперь у нас есть рабочий podman и podman compose!

Что касается удаления, то действия так же достаточно прозрачны и, в отличии от Docker Desktop, симметричны установке: podman machine rm и brew uninstall podman podman-compose. Ну красота же!

Казалось бы, ничего особенного не произошло, ПО просто работает так, как должно, но после Docker Desktop — это неописуемое счастье!

Что такое спецификация?

Это, можно сказать, уже не относится у сути повествования, но всё равно интересное замечание.

У нас в одном из проектов был docker-compose.yml с таким healthcheck у etcd test: ["CMD-SHELL", "etcdctl", "endpoint", "health"]. И он прекрасно работал с docker-compose, но внезапно перестал с podman-compose.

Опущу свои поиски причины, сразу к сути… Выяснилось, что CMD-SHELL по спецификации самого же docker-compose ожидает лишь одну строку после. В отличии от CMD. То есть

• [“CMD”, “etcdctl”, “endpoint”, “health”] — правильно;
• [“CMD-SHELL”, “etcdctl endpoint health”] — правильно;
• [“CMD-SHELL”, “etcdctl”, “endpoint”, “health”] — неправильно.

В podman-compose была проверка на то, что при CMD-SHELL после идёт ровно 1 строка, и по понятным причинам, в нашем случае, эта проверка не проходила и podman-compose ругался. А вот docker-compose не проверял это правило своей же спеки и просто выполнял первую строку после CMD-SHELL, игнорирую остальные аргументы. То есть у нас ещё был нерабочий healthcheck, который вместо доступности etcd, проверял наличие утилиты etcdctl! Вот это да…

Как так вышло?

Мне сложно сказать, почему у Docker Desktop так много проблем… Но мне хочется предположить, что дело в том он пытается быть одним большим приложением, которое делает всё само и как бы говорит пользователю “не лезь, я сам разберусь”. Только вот разобраться у него не получается и вечно что-то отваливается.

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

Не будьте как Docker Desktop. Будьте как Podman.