Create a gist now

Instantly share code, notes, and snippets.

Docker в продакшене.

С интересом ознакомился на днях с негативным опытом использования Docker в продакшене. Несмотря на то, что автор позиционирует себя, как матерого разработчика и девопса, легко отвечающего на вопросы типа "сколько шариков для пинг-понга могут взвесить в Сан-Франциско настройщики фортепиано, если шарики нельзя помечать", он не провел предварительного исследования, а спроектировав решение, сумел наткнуться на все известные минусы Docker. Видно, что его ограниченность одной убунчей, на которую он лазит по ssh со своего макбука, серьезно мешает ему в работе.

Укажу на то, что резануло глаз сразу.

"My first encounter with docker goes back to early 2015. Docker was experimented with to find out whether it could benefit us. At the time it wasn’t possible to run a container [in the background] and there wasn’t any command to see what was running, debug or ssh into the container."

В это время уже существовало средство, которое работало нормально. Это systemd (systemd-nspawn). Лично я использовал systemd-nspawn как раз для контейнеров. Другое дело, что ни в убунче, ни даже в Debian оно не работало еще толком. Даже в RHEL7 / CentOS 7 одно время требовалось использовать тестовые сборки systemd, где, правда, вы бонусом заодно получите и systemd-networkd.

Docker Issue: Breaking changes and regressions

Только не в RHEL. А вот в Убунче такое запросто.

The most tricky regressions we had to debug were network related. Docker is entirely abstracting the host networking. It’s a big mess of port redirection, DNS tricks and virtual networks.

Именно поэтому нужно использовать systemd-networkd вместе с flannel из CoreOS (как делал я), Weave или иным "poor-man SDN". У Weave были какие-то страшные проблемы с производительностью в дефолтной конфигурации, но на FOSDEM 2016 их представитель уверял, что это все в прошлом.

The most requested and most lacking feature in Docker is a command to clean older images (older than X days or not used for X days, whatever).

Эту претензию я вообще не понял. Автор хочет современную версию tmpwatch, написанную на Golang? Кстати, в Spotify ее переписали на bash, но это несовременно, конечно.

Docker has various storage drivers. The only one (allegedly) wildly supported is AUFS.

А вот это интересно. Изначально, Docker разрабатывался так, чтобы использовать лишь технологии, доступные в Ubuntu. К сожалению, разработчики почему-то выбрали тупиковое решение - AUFS. Ее почти сразу же запланировали на вынос из Ubuntu, поэтому такая технологическая близорукость разработчиков Docker удивительна вдвойне.

К счастью, в широко известной в узких кругах компании Red Hat работают специалисты с более широким кругозором, которые протянули руку помощи, предложив замену на базе devicemapper. Это, кстати, было фичей Fedora 17.

Опять же - автору стоило бы осмотреться вокруг. Идем дальше.

Bonus: The worldwide docker outage On 02 June 2016, at approximately 9am (London Time). New repository keys are pushed to the docker public repository. As a direct consequence, any run of “apt-get update” (or equivalent) on a system configured with the broken repo will fail with an error “Error https://apt.dockerproject.org/ Hash Sum mismatch”. This issue is worldwide. It affects ALL systems on the planet configured with the docker repository. It is confirmed on all Debian and ubuntu versions, independent of OS and docker versions.

Давайте начистоту. Использовать "Рапидшару" (место, куда кто угодно может закачивать неизвестно какие файлы) для продакшена это просто плохо. И для тестового окружения мало чем лучше. И для окружения разработки, кстати, тоже! Я бы предложил разворачивать контейнер из репозитория в указанную директорию с помощью штатного пакетного менеджера, а там уже запускать контейнер с помощью systemd-nspawn. Например, вот так я создавал и запускал контейнер с CouchDB. В Debian и Ubuntu все делается не сложнее.

Это сразу снимает все претензии автора к Docker Registry и егo API. Просто автору стоит использовать пакетные менеджеры (в Mac OS X их официально нет, поэтому автор и не в курсе, как оно в других системах).

Дальше автор подводит итог, описывая текущее положение с Docker в компании, где он работает. Тут я тоже удивился ряду заявлений:

For some reasons, Erlang applications and docker didn’t go along.

Возможно в Docker оно и работает как-то не так, но если не считать "Docker" синонимом "контейнер", а использовать тот же systemd-nspawn, то все работает прекрасно. Запускается EPMD, Erlang-приложения, работает socket-активация. Правда для лучшего коннекта без единого разрыва мы пропатчили ряд популярных Erlang-приложений на совместимость c systemd:

Обратите внимание на даты, когда были открыты PR. Тем не менее, никаких проблем c Erlang нет даже без этих патчей, и Erlang-приложения в контейнерах работают без поломок.

Docker is meant to be stateless. Containers have no permanent disk storage, whatever happens is ephemeral and is gone when the container stops.

Это просто заблуждение. В вышеприведенном примере с CouchDB, у приложения есть место для хранения файлов, видимое (или невидимое - по желанию) оператором машины-хоста. Запускать MySQL в контейнере можно. Не знаю, почему в Docker это сложно - думаю, что автор что-то пропустил опять в инструкции.

...Moreover. Docker is locking away processes and files through its abstraction, they are unreachable as if they didn’t exist. It prevents from doing any sort of recovery if something goes wrong.

... и вдогонку к предыдущему, в вышеуказанном примере с контейнером с CouchDB все его файлы, это просто файлы на файловой системе машины-хоста. Минуc еще одна проблема.

На HackerNews автора уже ругают, и даже написали опровержение, которое уже тоже обсуждают, но разве можно пропустить такой момент, чтобы подтолкнуть падающего?

@alisatl
alisatl commented Nov 7, 2016

Здорово, Петь, так его в топку. Буду у тебя по докерам консультироваться. Даешь пость по Кубернетис теперь!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment