Что думаете о Docker?

Продакшен продакшену рознь на самом деле. Мы например гоняли prod-трафик через java в докере. Но у нас был сервис типа прокси, то есть stateless, scalable и cloud-ready, без необходимости хранить сессии... - мечта девопса короче говоря. Там докер никому не мешал, зато деплой и оркестрация, релиз за 5 секунд и красота.

Ой, а кстати, что вообще делают со stateful приложениями и сервисами в дивном новом мире контейнеризации? Гоняют рядом с кластером и раскатывают по старинке условным ансиблом?

А деплой чем? Я попробовал оркестрировать ансиблом, но модули совсем не очень при каких то нестандартных вещах. Сильно смотрю сейчас на номад, да и вообще весь стек хашикорп. К8с очень велик и сложен для моих задач.

А что у вас за задачи?

Разворот витрин данных - обычные веб-сервисы. Ну и прогон их от стендов тестирования до прода. Мне проще, мои базы данных можно считать стейтлес, данные в них не меняются и загружаются 1 раз в день.

если ФС ZFS то лучше не брать докер ни при каких условиях

А что именно не так? У меня есть «игрушечный» сервер с ZFS и docker - проблем (пока) не заметил.

У меня сами по себе создаются лаерсы и снапшоты от контейнеров в отдельных разделах и zfs list начинает выглядеть 5 метровой портянкой, типа так:

# zfs list -r
NAME                                                                                      USED  AVAIL  REFER  MOUNTPOINT
rpool                                                                                    6,41G  5,24T   128K  /
rpool/ROOT                                                                               1,98G  5,24T   128K  none
rpool/ROOT/ubuntu                                                                        1,97G  5,24T   907M  /
rpool/ROOT/ubuntu/1d55ec0334d5090652b1d4be77c8bc54611955c20c60ca01e792409d7f108cd4        149K  5,24T  80,8M  legacy
rpool/ROOT/ubuntu/4f7c9ed3cd30127d1bf55f55ae646f8efecb1d9468e96de5f3356b1ca4c8a6fb        213K  5,24T  80,8M  legacy
rpool/ROOT/ubuntu/868d4ef27c8e556d256079da0c8f057ae9eb1d9343ccfe6ef589d4f158dfe7f7        176K  5,24T  80,8M  legacy
rpool/ROOT/ubuntu/884e552606fe9d84008b65fc94d2b2e04bff37bee9d963a0ea3647a57341be1e        160K  5,24T   132M  legacy
rpool/ROOT/ubuntu/9a6746fb7475874c47ffb7e9be0f94e9bc718d6148501d58357e12ba98ad1743        181K  5,24T   132M  legacy
rpool/ROOT/ubuntu/9d3b96ad79dfafc34e1bcbbe1696ca1aaeea23417d9c93e586ed5733e7392416        144K  5,24T   132M  legacy
rpool/ROOT/ubuntu/b09a842d8b65b1e70e0645a049ad474b1a59cfc163cbc96fa96833fb790e9211        149K  5,24T   132M  legacy
rpool/ROOT/ubuntu/b733445fdee81ac9388586e57dd5ff7b1d12adb536cf7c2bb8d7f1d814d4f6b3        884M  5,24T  1015M  legacy
rpool/ROOT/ubuntu/dea78a33c81fc5b59582fd5803fb673ae0436cfff259a44f80cd77c8a3f49968        293K  5,24T  88,4M  legacy
rpool/ROOT/ubuntu/e1e5ee074ad49d45b4aaa4bd50e6441bf8958347a010f3cc21aa7aef40227c88       13,1M  5,24T  1017M  legacy
rpool/ROOT/ubuntu/e1e5ee074ad49d45b4aaa4bd50e6441bf8958347a010f3cc21aa7aef40227c88-init   213K  5,24T  1015M  legacy
rpool/ROOT/ubuntu/e4f4e0f643e7c036fa5668ee5b0263576cb83364884e6346f6ca4b38f2266225       88,3M  5,24T  88,3M  legacy
rpool/ROOT/ubuntu/f0bcd41817d006eff5242c64202eabe9a0d10d8920f5f6bcca19068850866507       59,3M  5,24T   132M  legacy

...

И притом чем дольше работает контейнер, тем больше такой херни. Использовал docker-ce, а в нём в разное время gitlab, onlyoffice и collaboraonly.

Так в чем проблема-то ? :) Докер просто юзает стандартные возможности ZFS/BTRFS. https://docs.docker.com/storage/storagedriver/select-storage-driver/

Если уж так не нравится «портянка» в корне - делается отдельный том для docker и подключается на /var/lib/docker. Если с системного раздела регулярно снимаются снапшоты, то почти все нормальные люди и так создают отдельные тома для «левых» данных, типа /var, /tmp и т.п.

У меня как раз был nomad + consul + linkerd, поскольку я проиграла войну с ops-командой.

И я думаю что это была большая ошибка.

«hashicorp-стек» - это на самом деле миф, там нет никакой интеграции, даже на уровне форматов cli и конфигов. Это такой набор разрозненных и достаточно сырых утилит и если глянуть даже у самого номада cli-утилита задизайнена кое-как.

То есть если у k8s есть ресурсы есть действия и есть стандартный формат «выполнить действие с таким-то ресурсом», то у nomad будет:

nomad alloc-status

nomad job status

И вроде мелочь, но таких мелочей много.

Нет например cli-способа увеличить количество инстансов одного сервиса не зная полный конфиг сервиса. То есть я не могу сказать «job такая-то, увеличить количество инстансов на 5». Мне надо знать полный конфиг этого сервиса и задеплоить его как бы по новой. А узнать этот полный конфиг из номада можно в json-формате, который не совместим с hcl-форматом. И даже с json-форматом тоже не совместим. То есть там два json-формата: первым можно описать job для деплоя, а второй - это то что можно экспортировать из номада когда там уже всё запущено. И они разные.

hashicorp вроде как сделал плагин для номада в terraform. Вроде и то и то - их технология, но обновление плагина для поддержки новой версии номада делали больше полугода.

Я в итоге плюнула и настроила раскатку джоб из ansible, с шаблонами, переменными, поддержкой разных окружения и кластеров и т.п.

Для админа тоже там весело, логи например есть либо debug либо никаких. Интеграцию linkerd с consul для того чтобы healthcheck для сервисов работал наши админы открутили в первыую же неделю потому что нестабильно и не работает. Авторизации нет, namespaces нет, квот практически тоже нет...

Пришлось все это какими-то обертками и подпорками реализовывать.

И в общем хотели попроще а получилось что навертели вокруг якобы простого решения кучу недокументированных костылей, а сообщества которое помогло бы с ними справляться и делиться опытом нет. Так что ничего не выиграли в итоге.

Понятно что для моего простого случая мы там все запустили, нашли обходные пути и т.п., но как пошла вторая волна контейнеризации, с другим типом нагрузок и с бОльшим количеством команд-участников, проект по миграции на k8s откопали обратно. Теперь он вдруг он оказался в приоритете. И весь последний месяц пока я увольнялась каждый митинг народ кивал в мою сторону мол «а вот она же говорила» :)

И это я ещё не начала тему про port-forwarding. И какая эта боль когда у стандартного java-приложения 5 портов (main, actuator, jmx, debug и ykit) и с точки зрения nomad это все разные сервисы которым назначаются разные рандомные порты, а потом тебе надо перекурочивать систему мониторинга чтобы она училась сопоставлять healthcheck на порту таком-то и метрику потребления RAM на порту совсем другом , и что это оказывается тот же самый java процесс...

есть моар такого?

Ну я теперь на новой работе деплою на openshift, так что через пару месяцев будет :)

охохо, про openshift я бы почитал!

Букварь, пиши ещё[2] :)

Так в чем проблема-то ? :)

Проблема в том, что заканчивается место на диске. collaboraonly за сутки сожрала почти 50 гб, хз насколько нормально это. Но я решил отказаться от докера.

p.s. Сейчас у меня тоже есть раздел /var/lib/docker, но странное поведение докера так и осталось. А перевести его в режим чтобы он писал все свои данные только в файл - я не смог.

collaboraonly за сутки сожрала почти 50 гб

По-моему тут проблема с образом/контейнером, а не с docker'ом как таковым :) Надо смотреть, что именно творит ваша collaboraonly, что/куда пишет и в каких объемах.

Да возможно Вы правы, но мне надо было решить задачу и докер оказался только балластом в данной ситуации.

Спасибо за отзыв, полезно.

Изучить стоит. Штука интересная. Я применение вижу для развертывания окружения для разработки, если оно нетривиальное. Также удобно для экспериментов. Вроде в кластерах используют с кубернетесом, но я не пробовал.