Comments 484
> Директива depends_on, которая вроде как за это отвечает — бесполезна
wait-for.sh упомянуть бы

Коллеги неоднократно упоминали wait-for.sh в контексте статей про Докер, здесь на Хабре. Например, хотя бы тут
К сожалению, это неидеальное решение, т.к. контейнер получается запущен и ждет остальные (т.е. как минимум — кушает ресурсы).

понятно, что это костыль, который, если не путаю, даже в доке упоминается
но по ресурсам это дешевле, чем если контейнер рестартуется

Ну так есть ещё health check с помощью которого можно явно проверять статус контейнера и переходить к запуску следующего.

Не работает. Точнее не так — это функционирует только в момент docker-compose up, если мы говорим про отдельные докер-хосты (пример). Либо в случае кубернетеса — там вообще отдельная и другая история.


Обычно же шибко вумные коллеги говорят, что если вам нужен порядок запуска контейнеров, то вы что-то делаете не так.

Обычно же шибко вумные коллеги говорят, что если вам нужен порядок запуска контейнеров, то вы что-то делаете не так.

А как должно быть? Многие веб-приложения, например, не запустятся, если в момент запуска недоступен SQL сервер или Redis, так как им для старта нужно прочитать какие-нибудь конфигурационные переменные из базы данных или еще откуда-нибудь.


Что предлагают умные коллеги? Стартовать сервис по первому обращению к порту? Но docker из коробки такую функциональность вроде бы не предоставляет.

Многие веб-приложения, например, не запустятся, если в момент запуска недоступен SQL сервер или Redis, так как им для старта нужно прочитать какие-нибудь конфигурационные переменные из базы данных или еще откуда-нибудь.

Вариантов-то немного.


  1. обеспечивать отказоустойчивость базы (если в этом случае БД упала, то у вас проблемы посерьезнее того, что приклад "не алё")
  2. падать — рестартовать контейнер (может быть "дорого", если там в контейнере какой-нибудь jvm, который долго стартует)
  3. кидать exception, обрабатывать его и retry попытки доступа к БД.

К тому же, обычно бест пректис — выносить БД наружу, не держать ее на том же хосте, что и приложение-клиент (могу подробнее обосновать, если не очевидно почему).

Мы вроде бы сейчас говорим о первоначальном запуске. Из моего опыта, многие продукты или даже фреймворки ожидают, что в момент старта приложения БД готова отвечать на запросы.


Неспроста ведь всякие wait-for.sh появились — докер ломает подобные предположения, или получается, что в зависимости от времени суток и тому подобных факторов, конфигурация либо стартует, либо нет.

А можете пояснить — чем принципиально на Ваш взгляд отличается wait-for.sh от try/except/retry в самом приложении?

По идее ничем. Но большинство уже написаного до докера софта не ждет, что именно в момент старта база будет недоступна. Так-то да, специально для докера можно в код инициализации добавить ожидание базы данных.


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


Или мы о каких-то разных вещах говорим?

Во-первых приложение не должно заморачиваться вещами как докер и его особенности. try/except/retry при отсутствии базы не всегда может быть хорошим решением, если база упала то может лучше остановиться и громко кричать о помощи.
Во-вторых, wait-for это костыль, который по идее должен быть частью docker-compose, но видимо они понадеялись на healthcheck.

healthcheck у меня почему-то не решал проблему. Правда никак не могу вспомнить почему именно. Скорее всего, как обычно, кривая реализация и еще более кривая документация в Docker.


Прошу прощения за голословные обвинения, но экспериментировал с healthcheck год назад, восстанавливать ту конфигурацию и пытаться воспроизвести проблему ради комментария, считаю не заслуживающей усилий ситуацией.


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

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

несомненно. А еще, если мне память не изменяет, то докер не перестартует контейнер в failed state. Только если тащить внешние модули вроде https://hub.docker.com/r/willfarrell/autoheal/ или https://github.com/containrrr/watchtower (но последняя больше для авто-обновлений)


Минус уже поставили

Это хабр. :-(

странно, но у меня хелс чек отрабатывает в сворме. во всяком случае в jave (actuator). пришлось заставить разраба написать нормальные хелсы
согласен со всеми пунктами, особенно в редхате после установки докера что то происходит с iptalbes правилами, проброшенные порты не доступны снаружи.

вы еще не упомянули docker own registry. Который весьма криво работает с tls.
вы еще не упомянули docker own registry. Который весьма криво работает с tls.

криво, но я его никогда всерьез и не рассматривал как конечное, целевое решение. Нужен docker registry — либо используешь SaaS (docker hub, который постоянно взламывают, quay, облачные — в google, amazon, azure, яндекс, либо gitlab registry), либо разворачиваешь что-нибудь вроде JFrog Artifactory.

если база упала то может лучше остановиться и громко кричать о помощи.

Вообще-то я про это же и говорю. Что это зависит от конкретных требований и ситуации.

Критика, мне кажется, обоснована. Но каковы альтернативы?
Мы живем в такую эпоху, кто первый тот срывает банк.
Кто успел захватить рынок или нишу будет иметь время и ресурсы потом довести продукт до ума или будет сметен очередной волной.
На данный момент со всеми костылями и недостатками Docker остается практически безальтернативным лидером в быстрой и удобной виртуализации как при разработке так и при развертывании решений в цепочках CI/CD и деплое.
Во всяком случае я не вижу серьезных конкурентов.
Рынок и время все расставит по местам.
на самом деле в том же lxc можно делать абсолютно всё тоже самое, и да неизменяемый и да всё остальное… просто требуется чуть больше телодвижений. но народ ленив.
использовать докер и называть это рациональностью это как те псевдобизнесмены которые пытаясь сэкономить покупают дешёвое гавнооборудование которое сдыхает на следующий день и не тянет возложенные задачи и в итоге тратят больше?

Нет, не так. Просто нужно ставить задачи, которые докер способен эффективно (как плане человеко-часов, так и в плане вычресурсов) решить. Я вот сейчас понятия не имею есть ли вообще докер на нодах нашего кластера, главное что он разворачивает образы с помощью докера построенные. Попробовал несколько других тулс для билдинга стандартных образов — уступают, как минимум в поддержке Dockerfiles.

Мне кажется Podman это альтернатива не докеру а скорее конкурент К8?
PS: для продакшн — рискованно брать недостаточно обкатанное решение. Специально сходил проверил первая альфа вышла чуть более года назад podman.io/releases/2018/06/04/podman-alpha-v0.6.1.html. Для боевых систем всегда выбирается стэк проверенный временем. Как я уже сказал в первом комменте, возможно со временем что-то вытеснит докер с его сегодняшних позиций. Podman выглфдит неплохо, но надо подождать когда первая волна энтузиастов его доведет до ума и докажет его превосходства и эффективность. Например, у меня нет времени на тестирование подобных альтернатив. Меня докер устраивает для моих небольших задач. И большая часть успеха кроется в огромном количестве доступной информации и примеров. Podman и поэтому я не уверен как скоро я начну (если вообще когда-нибудь начну) его использовать и/или тестировать. Се ля ви.
Спасибо, надо будет видимо покопать немного и в эту сторону тоже.

Это именно альтернатива докеру и есть, т.е. он предоставляет пользователю знакомый интерфейс для запуска контейнеров в cri-o. В kubernetes тоже есть нативная поддержка cri-o

на самом деле в том же lxc можно делать абсолютно всё тоже самое

"Э — экосистема".


Можно "в том же lxc" на винде собрать образ, который залить в AWS SageMaker в качестве кастомного training algorithm?

Я так понял, что SageMaker сделан поверх EC2. И причем тут докер? Или, пожалуйста, разверните свою мысль.

Я так понял, что SageMaker сделан поверх EC2. И причем тут докер?

Докер при том, что это штатный способ задания алгоритмов в SageMaker — через указание образа в ECR. Так что скорее вопрос "при чем тут EC2".

Да, тут как с демократией. Она — худший способ управления государством, за исключением всех других способов, которые ещё хуже.

Почему? Та же автократия хорошо работает. Эффективно. Только вот цена достаточно высока. И все хорошо, пока цели конкретного индивидуума совпадают с глобальными целями (хотя так везде)...

podman и buildah например. Чем не достойные конкуренты? Podman еще и поддерживает rootless контейнеры, для половины задач их хватает, +1 к безопасности. Не надо устанавливать никакой сервис и заморачиваться его статусом. docker-compose заменить podman-pod. Как-то собирался написать свой podman-compose (существующий на гитхабе не работает) чтобы можно было запускать podman pod с существующим конфигом от docker-compose.
К тому же не надо особо учить новый интерфейс, так как podman почти один в один повторяет функции докера. Просто «s/docker/podman/» и скорее всего все будет работать как обычно.
Вот только с нетворкингом не так удобно, так как нет команды «podman network» и приходится конфигурить CNI сети скриптами. Но тоже очень просто, обычный JSON или YAML.
Я думаю для большинства задач для разработчика podman вполне заменяет docker. А на серверах все равно будет kubernetes какой-нибудь.

Я не нашёл упоминаний может ли он работать с удалёнными машинами. Ну и "конфигурить CNI сети скриптами" я не очень даже понимаю что значит — эти виртуальные сети, в которых docker-compose резолвит сервисі?

Да, но есть возможность указать нужные сети через конфигурационный файл. См. default-address-pools и github.com

Спасибо. Ждал этого коммента ) Действительно впилили эту фичу. Спустя… Очень долгое время.

Автор не в полной мере осознает масштаб проблем.
Однажды меня попросили "быстренько посмотреть один из серверов, туда что-то докер не встаёт. Надо поставить, и нужно через пару часов уже раскатать там микросервисный проект — ведь докер ровно для этого и сделан, чтобы легко разворачивать весь ворох сервисов с нуля".
На хосте оказался e2k

Для общего развития, а что такое e2k? Гугл ничего подходящего по теме не находит

У меня целых три предположения:


  1. до появления BitTorrent было пиринговое приложение для пиратства музыки и фильмов, которое называлось eDonkey. Кажется какая-то разновидность то ли приложения, то ли протокола, называлась e2k.
  2. Эльбрус 2000, как уже отписались
  3. Возможно какая-то разновидность Ethernet-карты?

Но вообще, уж слишком таинственный комментарий.

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

Действительно, интересный вопрос. Т.к. коллеги умудряются использовать кубернетес оставляя от него только по сути scheduler (сеть плоская как в букинге, поды прибиты руками к нодам, вся персистенция через host volume etc.). И оно даже как-то работает :-o :-o :-o Правда, ценность такого решения не очень понятна (разве что разработчикам удобно YAML писать....)

Да, сначала придумывал костыли. Комбинировал сети и старательно составлял докерфайлы, чтобы внутри каждого контейнера был свой пользователь, прописывал права на хостовой машине, упорно дорабатывая то, что создатели докера не додумались автоматизировать.
Потом розовые очки спали, я перестал пихать квадратный объект в круглое отверстие и осознал, что для моих крайне скромных задач хватает комбинации chroot, virtualbox и отдельно поднятых VPS, благо у многих хостеров есть для этого API и можно автоматизировать их создание и настройку. Docker по-прежнему использую, чтобы быстро что-нибудь проверить или воспользоваться какой-нибудь софтиной, не мусоря в системе, но в основном предпочитаю поднимать отдельные виртуальные машины. Кубернетес для меня — что микроскоп для забивания гвоздей, не те масштабы, поэтому более примитивных и устаревших средств хватает с избытком.

Очередная иллюстрация на темы


  • "кубернетис не нужин" (с) (по крайней мере не для всех)
  • "подбирайте инструменты по задачам" (не наоборот)
  • "преждевременная оптимизация — зло"

Без издевки — очень понимаю, мои апплодисменты. Все правильно говорите.

так да! я за это и топил. но «модно стильно молодежно» это ж… сами понимаете, модно, стильно и молодежно
Практически все перечисленные проблемы решает Openshift или любой другой полноценный оркестратор.

Не всегда допустимо тащить оркестратор. Ну, например, зачем мне оркестратор, если есть один, два или три узла с докером?
Вообще я столкнулся с тем, что вся эта оркестрация именно в реализации кубернетеса достаточно жручая штука и оправдана либо на масштабе, либо если есть особые требования (например, отказоустойчивость, или разработчики хотят отлаживаться и писать YAML манифесты для обеспечения идентичности промышленной или разработческой сред)

Практически все проблемы решает замена на lxc/lxd Там даже сеть нормальную завезли и ей удобно управлять.

Докер и LXC — это всего-лишь два инструмента, которые решают две разные задачи

И тот и тот и контейнеры. То что докер заворачивает приложение внутри себя я в курсе. Проблема начинается когда у вашего приложения требуется запускать более одного процесса. Классический пример nginx + uwsgi сервис. В случае lxc я запущу один контейнер который будет их содержать. В случае же docker мне потребуется два контейнера и надо будет их еще как-то связать. Плюс если сервис захочет что-то хранить надо будет делать отдельный том. Проще говоря количество телодвижений при использовании docker на порядок больше и требуются специальные оркестровщики, где в случае lxc можно обойтись командами.

Это сделано намеренно. Контейнеры в linux в т.ч. и LXC, имеют ряд проблем или особенностей (называйте как хотите). Основная причина в том, что если вы убиваете родительский процесс в контейнере, это не означает, что все дочерние процессы завершились правильно, некоторые из них могут продолжать использовать сетевые интерфейсы и блокировать хранилище, в итоге мы имеем повисший в непонятном состоянии контейнер.


Подход "по процессу на контейнер" позволяет избежать данной проблемы и получить всегда гарантированное состояние. Кроме того это позволяет container engine сделить за каждым процессом отдельно, автоматически собирать логи и метрики с него.

Подход "по процессу на контейнер" позволяет избежать данной проблемы и получить всегда гарантированное состояние. Кроме того это позволяет container engine сделить за каждым процессом отдельно, автоматически собирать логи и метрики с него.

Зачастую это не работает. Приходится мириться с тем, что процесс внутри контейнера форкается и плодит потомков. Еще хуже — если там разнородные процессы под управлением супервизора. В результате — типовая проблема, что появляются процессы-зомбяки. Решается вроде как засовыванием init в контейнер. Но это костыль. Очередной. Впрочем, неудивительно.

Про init и дочерние процессы в docker аж целая проблема была. Ее разве побороли?

Ну, "окончательного решения init вопроса" разработчики не придумали. Есть какие-то разрозненные практики. Начиная от запихивания supervisor (фу), кончая появлением специального --init ключа у docker run.


Да. Еще стоит упомянуть, что коллеги умудрялись с матами и приседаниями запускать полноценный systemd в докере, но вряд ли оно того стоит. Преимущество такого подхода очевидно — ты просто пишешь свой приклад, пишешь юнит файл и оно вместе работает везде — что на выделенной ВМ, что в докере.

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

В итоге на основную идею докера один контейнер, одно приложение положен большой болт.


Так что, выдумки все это.
А что же там написано? Мы сделали это просто так? Везде именно так задвигают использование docker
И что? Я иногда встречал бредовые высказывания, что когда апп умеет в треды и создает потомков, то крику поднимается, что нельзя такое, только один процесс без детей. Я считаю, что если нужно два процесса, так тому и быть.
Тогда docker должен уметь обрабатывать такое из коробки. И без костылей. Ну и собственно где?
Какие костыли? один баш скрипт. Ведь один вход на запуск. а этот скрипт может что угодно запускать и как угодно.
Это и есть костыль. Я обязательно должен с собой тащить дополнительную прокладку. Если вы не понимаете почему это плохо, то посмотрите в скрипты запуска sysvinit и unit файл systemd. Знаете в чем разница? Первый регламентирован весьма условно и он будет разный в разных дистрибутивах. Во втором случае он всегда одинаковый во всех дистрибутивах. Более того разработчик приложения наконец-то может сам сопровождать unit файл.
А напрямую запустить нужный процесс не? Обязательно баш-скрипт тащить?
Тогда дети процесса не умрут :) Фишка в том что идея запустить напрямую процесс, приводит к невозможности завершить процессы детей, если процесс упал через segfault и не отправил им sigterm.
Так не надо писать так, чтоб приходилось плодить детей. Нитки же (threads) есть.
Вот и всё.
Ну, может Сысоеву принципиально пофиг на докеризацию ) или он не считает init в докере костылем.
Но, имхо fork вместо нитки — само по себе костыль.
А докер разве не про облегчение жизни разработчикам? Если да то с чего такие драконовские ограничения.
Ограничения в голове у людей. Если что-то не нравится можно переделать, сделать по своему, а то ишь, понапридумывали бредовых правил про один контейнер один процесс.
Просто она не работает :) Если бы она работала нормально, вопросов бы не было.
Докер прежде всего про облегчение жизни эксплуатационщикам. Не знаю кто сказал что он жизнь разработчикам облегчает.
Ну т.е. есть унифицированный способ деплоить сетевые приложения без загаживания хостовой системы. Отлично.
Ограничение проистекает из необходимости корректно определять состояние контейнера по состоянию порожденного в нем корневого процесса.
И это вполне разумное ограничение — контейнер под задачу. умерла — убить/перезапустить в соответствии с полиси.
А если вам в контейнере нужен init — вы что-то делаете не так.
Угу он при этом отлично гадит в фаервол хостовой системы. То как там сделана сеть делает меня печальной пандой. Примеры когда это не работает тут уже приводили. Далее может происходить задача умерла, дети не умерли. Убили контейнер в итоге сломали задачу, так-как она по новой не стартует.

Как-то топят за него больше разработчики, чем эксплуатационщики. Унифицированній способ разворачивать сетевые приложения без загаживания своей машины :)

Обычный пример: php-fpm+nginx, которые должны шарить public директорию и второй без первого просто не имеет смысл (по крайней мере в рамках конкретной системы даже для локальной разработки или отладки), неотделим от него.

"Обычный контейнер с init системой" включает в себя tty, ssh-сервер, что-то для управления сетью, что-то для сбора логов...


А тут всего две программы запускаются, помимо самой init системы.

tty у вас всегда есть. Логи и управление сетью а так же ssh это вообще опциональные вещи.

А тут всего две программы запускаются, помимо самой init системы.

И? Идея докера берем приложение берем окружение запускаем. Когда вот такое как у вас то там нужно настроить супервизор или написать bash скрипт которые это все будут запускать. И да придется добавить логгирование, так-как в стандартный поток может писать только одна программа.
tty у вас всегда есть

Но не всегда на нём висит getty или там login...


И? Идея докера берем приложение берем окружение запускаем

А в чём отличие в случае наличия init?

Но не всегда на нём висит getty или там login...

Это совершенно не обязательно

А в чём отличие в случае наличия init?

В том что внутри контейнера еще потребуется настроить приложение и дополнительно делать init так чтобы он пробрасывал вывод приложения в докер.
Обычный пример: php-fpm+nginx

Ну, раз они плодят детей — значит это плохо докеризуемое решение, и не стОит его докеризовывать.
P.S. Дякую тобi боже що у мене Спрiнг

Нут не про детей даже речь, тут про то, что это два разных процесса, которые должны работать исключительно в паре и шарить между собой некоторые файлы.

Ну тогда это просто значит, что докер не нужен вообще никому.

Потому что ситуация, когда у вас два приложения, связанные между собой — это первое, вот совсем самое первое, что появляется, если вы начинаете думать о безопасности (о реальной безопасности, а не рекламной).

Ибо «основное» приложение (которое мы часто меняем и в котором могу быть ошибки) должно быть отделено от логгера (задача которого — меняться редко, быть надёжным, как скала, и обеспечить доставку логов даже после того, как основное приложение скомпроментируют).

Если же вы умеете писать приложения так, что они ошибок не содержат и в защите не нуждаются… нафига тогда вам контейнеризация вообще?
При чем тут логгеры?
Если у вас два приложения, связанных — вяжете их по сети. Условный веб-сервер в одном контейнере, логгер — в другом, БД — в третьем.
Если вам надо запихнуть в один контейнер больше одного приложения — you doing it wrong. Всё. Точка.
Если вам надо плодить детей форком — you doing it wrong.
Один контейнер — один процесс.

Вот интересно, авторы докера в официальной документации указывают на то, что несколько процессов не значит "you doing it wrong", а вы указываете. Вы более компетенты чем они в этом вопросе?

Один процесс, который не плодит потомков — он или работает, или упал. Состояние контейнера с ним отследить сильно проще. А перезапуском упавшего контейнера докер занимается сам.

Или попал в вечный цикл или блокировку. Процесс есть? Есть. Работает? Ну, вроде как да. Сервис клиенту оказывается? Да фиг там был. Получается, все равно хелсчеками обмазываться.

Это очень упрощенно и работает для очень простых процессов ИМХО.

А в чём проблема запустить php-fpm и nginx в разных контейнерах?
Они всё также могут смотреть в одну директорию и общаться друг с другом через tcp/unix-сокет

Это первый путь в ад, если php-fpm, например, нужно писать в этот каталог, а nginx читать — опять начнется свистопляска с правами. В принципе, это все решаемо, но это время и усилия на это.

Чем процесс запущенный в Docker отличается от запуска такого же процесса в системе? — ничем. Чтобы не было проблем с правами достаточно запустить контейнеры с одинаковыми uid/gid. Docker это давно умеет.


По факту я бы советовал рассматривать Docker не как альтернативу LXC, а скорее как альтернативу Systemd.
Обе системы запускают и следят за процессами, то что процесс работает в контейнере — в каком-то смысле второстепенно.

Вот Вы думаете, что вот берешь и просто меняешь uid/gid. В том и дело, что нет — иногда это влечет полную перенастройку и пересборку оригинального контейнера, т.к. там в docker-entrypoint всякая дичь и софт, который через пакетный менеджер ставится, не всегда ожидает, что он будет запущен, скажем, не от рута.
Дьявол в деталях, как обычно.


Обе системы запускают и следят за процессами, то что процесс работает в контейнере — в каком-то смысле второстепенно.

Только альтернатива какая-то куцая. Докер умеет перезапускать упавшие контейнеры? Умеет. А вот те, который не упали, но хелсчек failed? Нет. Зависимости между контейнерами есть? Нет, нету. Ну, и сравнения, значит, нет.

в docker-entrypoint всякая дичь и софт, который через пакетный менеджер ставится, не всегда ожидает, что он будет запущен, скажем, не от рута.

Это вообще антипатерн, здесь я с вами согласен. Но это проблема не Docker как системы оркестрации контейнеров, а это проблема образов, которые вы используете.


Возможно я смотрю на Docker со своей башни (Kubernetes) где всё хорошо и не замечаю проблем у простых пользователей, которые просто пытаются использовать готовые образы из Docker Hub'а, простите меня за данное допущение.

Все ок, извинения приняты. Спасибо за понимание.
Просто действительно — если собирать из готовых блоков (те же пакеты helm), то ± все уже понятно.


А если нужно в кубер закатить что-то, что еще никто не делал, то тут возникают нюансы.

А меня на самом деле пугает более простая вещь — сколько информации нужно знать, сколько опыта нужно иметь чтобы решить какие-то простые задачи не выстрелив себе в ногу. А подход "хай работает, потом допилим", о котором говорилось выше, совсем не располагает к глубокому изучению таких вот продуктов

Проблема в настройке взаимодействия этих самых контейнеров.


Простой контейнер можно при желании запросто запустить в нескольких экземплярах. А вот для двух зависимых контейнеров эти самые зависимости придётся настраивать.

Если честно не знаю как это организованно в docker, но в Kubernetes есть специальная абстракция — Pod, можно сказать это наименьшая единица для запуска workload в кластере. Описать два разных контейнера в одном Pod'е не составляет никакого труда (это всего несколько строк в одном yaml-файле).


Да, работа с Kubernetes ломает привычные принципы и требует определённого уровня сноровки, но научившись "правильно" работать с контейнерами, поверьте, многое становится проще и понятнее.

Ну, значит в Kubernetes эту проблему решили.


Но не будете же вы ставить Kubernetes каждому разработчику? Значит, для разработки нужен отдельный контейнер, с как можно более простым запуском.

Почему нет? Разработчик и сам может это сделать.
Времена когда для запуска Kubernetes требовалось потратить половину рабочего дня давно прошли.


Теперь же локальный Kubernetes-кластер можно запустить всего в одну-две команды.

Описать два разных контейнера в одном Pod'е не составляет никакого труда (это всего несколько строк в одном yaml-файле)

Лписать не проблема, проблема чтобы это описание заставило их корректно работать.

Несколько вариантов, не понятно какой лучше. В первом случае заменить сервер приложения php-fpm на RoadRunner, Swoole, nginx-unit. Он требует хлопот со стройны разработчиков. Второй связан с эквилибристикой со стороны девопса. Когда содержимое директории public копируется из контейнера сервера приложений с помощью docker cp.

Если верить Гуглу и Гитхабу, то второй гораздо популярнее для k8s. Относительно недавно вроде появился вариант монтировать volume на ingress-nginx 0.25.1, "пхп" трафик стандартно отправлять прямо на fpm, а статику с помощью сниппетов докрутить на том, в которій вторім способом скопировать. Естественно том кластерній должен быть. Вроде костыль большой, но возможность запускать fpm голым подкупает

В некоторых компаниях это основной подход. Там в одном контейнере может быть вэб сервер, сервер приложения и база данных, может быть что-то ещё. С их точки зрения всё замечательно. И даже запуск сотни процессов в одном контейнере (слова технического директора).
Да. Еще стоит упомянуть, что коллеги умудрялись с матами и приседаниями запускать полноценный systemd в докере, но вряд ли оно того стоит. Преимущество такого подхода очевидно — ты просто пишешь свой приклад, пишешь юнит файл и оно вместе работает везде — что на выделенной ВМ, что в докере.
Кстати, полноценный systemd в podman можно запустить без матов и без приседаний — это штатная возможность: How to run systemd in a container
Через init и я умею. А без него? Я как бы намекаю, что сама идея докера внутри только приложение такой оберткой нивелируется.

Идея докера — в упаковке всего окружения приложения вместе с ним. Если в окружении должен быть запущен какой-то дополнительный демон — как это нарушает исходную идею?

Банально тем, что это превращается из окружения в полноценный контейнер.
процесс внутри контейнера форкается и плодит потомков

Это не должно быть проблемой, так как в данном случае процесс который форкается как правило без проблем отрабатывает SIGTERM и мочит всех своих потомков.


Кстати, это один из пунктов 12factor app.

А по факту у вас случается segfault в родителе и SIGTERM не отправляются :)
Ага теперь мы кладем в docker любой веб сервер или uwsgi сервис и наблюдаем в нем дочерние процессы. Что-то не помогло. Плюс наблюдаем кучу костылей в виде запихивания в docker супервизоров. Проще говоря идея докера благополучно провалилась. При этом если мы возьмем lxc/lxd там сразу из коробки запускается systemd который за все следит и при остановке все гарантировано пристреливает.

Ну в Kubernetes эта идея вполне живёт и процветает.


Каждый pod может состоять из нескольких контейнеров работающих в одном сетевом пространстве. Внутри каждого такого контейнера работает отдельный процесс и пишет логи в обычный /dev/stdout и /dev/stderr.


Каждый такой контейнер может быть запущен из отдельного docker image, логи можно посмотреть из любого места: kubectl logs myapp -c nginx.
Это может быть по началу непривычно, но на мой взгляд, очень удобно.

Угу в итоге Kubernetes через pod реализует один контейнер lxc/lxd и требует своей установки и его изучения. При этом lxc/lxd контейнер kubernetes не требует. Как и не требует совершать дополнительные телодвижения для расшаривания совместных ресурсов.

Единственный плюс тут только наличие интерфейса и упаковки вашего приложения в докер. Но только в случае если ваше приложение нормально туда пакуется.

А как же иммутабельность, автоскейлинг, декларативность, автоматический сбор логов/метрик, возможность создания абстракций для повторяющихся частей вашего деплоймента?

Это прям очень надо когда у вас ОДИН nginx ОДИН uwsi и ОДНА база данных. И два сервера.

Не нужно, потому я и говорю что LXC и docker — это два разных инструмента

Это проблемы docker никак не убирает. Если у вас возникает проблема с докером в таком окружении это порождает заметно большие проблемы.
Классический пример nginx + uwsgi сервис

Ну для этого в общем то и придумали оркестраторы.
Опять же его классическое решение это два контейнера, один с nginx, второй с приложением и все это завернуто в единый pod (если в терминах K8s).
При том, что скорее всего nginx-ов там надо меньше чем приложений и их вполне можно разделить и управлять ими отдельно (если позволяют условия задачи).
Бонусом получается целостная система управления, переносимость, скейлинг там всякий, раскатка апдейтов и т.п.
Если все это не нужно, то речь скорее всего о маленькой задачке, которую можно кроме docker\lxc решить еще кучей способов на любой вкус и городить тут оркестратор нет смысла, да и контейнеры вероятно тоже. Правда такие задачки попадаются крайне редко (в моей практике) и обычно уже есть оркестратор для чего-то более серьезного.
Это классический пример забивания гвоздей микроскопом. Проблема как раз в том что везде кладут докер. Когда возникают проблемы прикатывают K8s. Или начинают городить из докера обычный контейнер.

Не знаю насчёт uwsgi на 100%, но близкий к ней fastcgi скорее предполагает один nginx (мастер) процесс на один же master fcgi (если опустить скейлинг). Плюс очень часто шаринг дисковых ресурсов, включая те, которые в образ положить нельзя в принципе. И управлять ими надо чаще всего синхронно в плане запуска и конфигурирования. В кубике придумали ещё один уровень абстракции — поды, как бы эмулирующие физическую машину с абстрактным init. Но называть это классическим решением как-то язык не поднимается, классическое исключительно в рамках k8s

Насколько понимаю обычно uwsgi и код приложения идет в одном контейнере, nginx если есть — в другом. Просто uwsgi и сам по себе может быть веб сервером. Вся статика на CDN.
Зачем nginx и uwsgi шарить какие-то ресурсы?

Есть "полустатика", файлы, загружаемые пользователями. Ну и CDN есть далеко не у всех

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

Вот как раз на одном сервере окнтейнеры очень полезны могу быть, если нужно запускать много разных проектов одновременно

Всё так, кроме одного: Docker в Windows работает нативно через Windows Containers, хотя не понятно зачем нужен Docker если есть PS и Windows Containers.
Я использую Docker for Windows, и у меня он создает Hyper-V виртуальную машину с Linux и уже в ней контейнеры. Удобно, хотя иногда внешние диски могут отваливаться.

Я так понимаю, что Docker под виндовс испытал несколько итераций. И я уже попросту потерялся в них.
Касательно Hyper-V есть неприятный нюанс, что вроде как Docker for Windows несовместим с другими средствами виртуализации — вроде VirtualBox или vmware.

вроде как Docker for Windows несовместим с другими средствами

Да. Докер, винда, виртуалбокс — выберите любые два. Все три одновременно запустить не выйдет.


P.S. Я в курсе про существование Docker Toolbox. Оно а) объявлено устаревшим/неподдерживаемым б) в некоторых моментах ведёт себя несовместимым с Docker Desktop образом.

Де-факто — нет, на форуме уже есть огромная нить из сообщений о том что VirtualBox 6 отказывает запускаться с HyperV.

Ну и лично у меня так и не получилось их запустить.

Дело не в докере, а в Hyper-V, он действительно был не совместим с другими системами виртуализации, так как монополизировал доступ к аппаратным расширениям процессора, но есть пара но:


  1. Какой вообще смысл использовать дырявый и тормозной VirtualBox, когда MS бесплатно дает возможность использовать enterprise-level Hyper-V? (При этом давно есть возможность в VB включить тип виртуализации Hyper-V)
  2. В свежих версиях Windows появился слой абстракции — Virtual Machine Platform, позволяющий использовать виртуализацию для контейнеров, при этом не включая Hyper-V и не блокируя другие гипервизоры. Если я правильно понимаю, поддержка этой платформы другими гипервизорами уберет все конфликты.
enterprise-level Hyper-V

Я бы поспорил насчет enterprise level. Типичный кейс с 2012 сервером. Используем его в качестве ноды виртуализации. Пускай, на нем 16ГиБ ОЗУ. Забиваем его виртуалками на 14ГиБ (остается 2ГиБ под систему). Работаем так месяц. Потом возникает необходимость выключить одну из ВМ. Пытаемся запустить — нет памяти. WTF!? Изначально ведь памяти хватало. Берем и психуем — ребутаем вообще всю ноду виртуализации. Все виртуалки опять на свежеперезагруженной ноде запускаются на ура. Поясню, что я никогда не использовал динамическое выделение памяти под ВМ — только руками прибивал объем. Получается, вЕнда течет? Вот тебе и продакшен реди.


Я уж не говорю про особенности перевода в русскоязычной версии, когда внезапно VLAN становится адаптером беспроводной сети (WAT???)

собенности перевода в русскоязычной версии, когда внезапно VLAN становится адаптером беспроводной сети (WAT???)

Я когда-то очень очень давно в студенческие времена переводил кое-что для XX. Правда под NDA, но по-моему, любая NDA имеет срок давности, а та NDA даже явно его имела. Прошло столько лет, что уже не вспомнить. Ну и потом, сам факт того, что я сейчас пишу, наверняка под NDA не попадает.


Так вот, не боги горшки обжигают. XX заказывает перевод у какой-нибудь солидной европейской компании. Европейская компания может заказать субподряд еще одной компании. В конце-концов эта цепочка заканчивается на бедных российских студентах. Хотя мне тогда деньги казались астрономическими.


Ну и делали мы перевод хорошо, я считаю. Проблема была в том, что какие-то сложные термины мы не могли правильно перевести в принципе, т.к. для этого нужен был серьезный экспириенс работы с продуктами. Поэтому иногда приходилось импровизировать и придумывать перевод гадая, что мог бы значить оригинальный термин. Углубляться все-таки боюсь, т.к. NDA какая-никакая была, хотя уже наверное давно всеми утеряна и потеряла актуальность, да и самой компании скорее всего уже давно не существует.


Так что неудивительно, что кто-то спутал VLAN и WLAN. Возможно также что где-то была опечатка, а переводчик пропустил, т.к. скорее всего в лучшем случае является профессиональным переводчиком, но не профессиональным сисадмином или программистом.

Ну, для этого предназначено бета-тестирование на фокус-группе пользователей. Но уж точно такого в релизе быть не должно — СТЫДНО.

Почему течёт? Набивает кеши как и любая другая ос.
У операционной системы подход простой: видишь пустую память — забей её кешами, что логично для всех сценариев — дабы пользователю запускать приложения быстрее и не читать их с диска, кроме того случая, что пользователь жук пытается выжать последние крохи из и без того пустого пула.


По-поводу венды 2012 для виртуализации ну тоже сомнительно, есть же бесплатный безгуевый Hyper-V Server который построен на Core версии и не стоит денег совсем. Свежий, бесплатный, Core (читай даже без гуи и требований к ресурсам), что еще нужно?


Что касается не венды, попробуйте забить память на линуксе и там не то, что все остальное продолжит работать, там всё встанет на пол часа пока ООМ-киллео не сможет наконец пробраться повыше: https://www.opennet.ru/opennews/art.shtml?num=51231

На всякий случай поясню.


  1. это не кэши. Т.к. есть вполне понятные методики для их сброса. И они не помогали. Это раз. Два — в любой нормально операционке кэш сбрасывается, когда есть запрос на ОЗУ. Три — это сервер. Там другая профиль нагрузки. Не быстрее запускать foreground приложения, а обеспечивать стабильную работу сервисов.
  2. Насчет Core — тогда еще его не было. Это раз. Два — чем 2012 плох для виртуализации? Три — чем конкретно поможет Core, если Вы сами говорите, что дело в кэше? Ну, и добавлю, что Hyper-V server достаточно специфическая штука и одмины, умеющие только в ГУЙ, его не осилят (ага, запусти оснастку на другом сервере и подцепись к Hyper-V Server — тот еще квест).

Короче, аргументы какие-то сомнительные. Прям совсем. А я рассказал о вполне конкретном кейсе.


Что касается не венды, попробуйте забить память на линуксе и там не то, что все остальное продолжит работать, там всё встанет на пол часа пока ООМ-киллео не сможет наконец пробраться повыше

overcommit и своп настраивать не нужно, да? Мы же все знаем, что дефолтные настройки практически везде никакого отношения к реальной работе не имеют (и на это есть масса причин).

ага, запусти оснастку на другом сервере и подцепись к Hyper-V Server — тот еще квест

Э-э-э, а квест-то в чём заключается?..

И в чем противоречие?
Идея контейнеров — использовать ядро хоста, если вы пускаете на венде линуксовые программы то каким образом они будут использовать вендовое ядро хоста?
Нативные контейнеры только для приложений под Windows, тогда и контейнеры будут легкие, нативные и на хостовом ядре.

До сих пор не научился нативно не в linux-kind операционных системах.

И при этом только для линуксов не заимплеменчен резолвинг host.docker.internal. Мой личный pet hate.

Категорически присоединяюсь! Я с этим делом недавно совсем дошел до ручки — сделал промежуточный контейнер, который пробует getent hosts host.docker.internal, а если не получается — берет default gateway, и NAT-ит на полученный IP весь диапазон портов через iptables. :-)

Спасибо за пост, хоть буду знать, что я не один такой немодный
В первую очередь докер решают проблему надежного атомарного УДАЛЕНИЯ СОФТА с тачки, а во вторую очередь — все остальное. Любой передеплой включает в себя удаление старой версии софта с машины, и вот это вот докер и сделал максимально удобным — не надо думать о мусоре, который раскидает инсталлятор по системе на пару с криворуки «коллегами»
всё же это побочная фича докера.
основная — независимость от окружения другого софта и простой юзерспейс.

К сожалению, независимость эта условная. Как на хосте ядро, скажем, версии 4.4.0, так оно и будет в контейнере — то же самое 4.4.0.

На самом деле нет. Если самому собирать пакеты и устанавливать их в стандартное место (например, /opt/), то никаких проблем вычистить старые версии софта нет.
А докер, на минуточку, создаёт проблему очистки неиспользуемых образов. Т.е. действительно хост-система не загадывается ошметками софта в контейнерах, но политику очистки образов все равно нужно продумывать. Проблема особо актуальна для docker registry, которые содержат мастер-образа для разливки софта на целевые машины

Не помню, но чем-то не понравилось — то ли удаляло слишком много лишнего, то ли наоборот — приходилось руками дочищать (совсем условно — то, что некий объект — образ или вольюм — сейчас не используется, не означает, что его можно брать и удалять)

Ну конечно всё это можно, но если есть более удобный инструмент, улучшающий и многие другие аспекты процесса разработки и доставки, почему им не пользоваться? Большинство проблем, описанных в статье — это сетевое и «архитектурное». Но так оно и решается совсем другими способами.

Для задачи удаления старой версии софта докер делает слишком много. Достаточно вменяемого пакетного менеджера. А ещё лучше если софт просто лежит в одной папке, а не размазывается по файловой системе ровным слоем.

1) Пакетные менеджеры как правило очень осторожны. Особенно в части каталогов/файлов с конфигами и данными.


2) "Иногда" положить весь софт, да с зависмостями, в одну папку очень сложно.

Ну так данные-то при передеплое удалять как раз и не требуется. А если удалить нужно — у тех пакетных менеджеров что я видел есть для этого особая команда.


А вот по поводу зависимостей вы правы.

Смотря что иметь в виду под передеплоем. На локальной машине разработчика передеплой нередко означает полный сброс всего. А особая команда типа apt purge не всегда удаляет все следы установки и использования. Хорошо если просто "утечка диска", а не переиспользование старых конфигов созданных в например, /etc/*.d/

Как пакетный менеджер docker относительно хорош.


Слои — очень спасают, когда изменяешь образ, а он жирный, но не хочется перекачивать все.
Другой вопрос, что хотелось бы, чтобы слои были полностью независимы, тогда — было бы существенно интереснее и переиспользование диска было бы лучше. Тупая реализация сломала бы объединение слоев в цепочку, но в принципе никто не мешал бы сделать "умные реализацию".


Про теги говорил — никто никаких гарантий не дает. Если есть контроль над скачиванием образа, то удобно все пушить в :latest — неверный релиз не попадет. Но для всех прочих целей рекомендуется тегать артефакты четко — по git sha, по дате + версия или по git tag. Т.к. тот же кубернетес может легко скачать в рамках одной версии деплоймента разные версии образов, после чего инженер утонет в отладке что же это происходит.


Про docker hub сказал. Обидно, что он захардкожен и его по простому нельзя отключить. Можно добавлять свои registry, но это выглядит как костыль, т.к. все равно в имени образа зашита ссылка и просто безболезненно с одного домена на другой не переехать.


Еще изначально в докере нет средств проверки целостности образа (хотя есть вроде DTR и Notary, но это появилось позже) и HA для докер регистри (ну, действительно — зачем?)


Просто вымораживает путаница entrypoint vs command. И два типа синтаксиса их (через exec и через shell — хорошее описание тут). Мы для себя выработали такую практику: в энтрипойнт помещается то, что пользователь образа менять не будет (только в исключительных ситуациях), в command — аргументы. Везде по возможности используем exec-style описания (перечисление аргументов в квадратных скобках) — он более предсказуем.


Есть еще тонкости, но это уже по мелочи.

Для компилируемых языков вроде golang или виртуальных машин вроде java — паковка в контейнер докера выглядит избыточной.

Утверждение «не все есть гвоздь, когда в руках молоток» — считаю хорошим уровнем освоения «молотка» как инструмента.

Хотя бы отчасти — да.


  1. Не нужно тащить демона докера — следовательно — нет лишней абстракции и проблем типа "демон упал и утащил за собой все контейнеры"
  2. Решена проблема с безопасностью. Можно каждому юзеру показывать только его контейнеры. Да, кэш образов у каждого юзера свой. В этом есть свои плюсы и минусы.
  3. Более нативная интеграция с остальной системой — с тем же systemd.

Мы пока с коллегами присматриваемся в рамках профильных телеграм чатов. Пока нюансов много всплывает. Та же сборка через buildah — неидеальна. Мягко говоря

Многие пункты это не хейт, а скорее здравый смысл :)
Безопасность, правда, никто и не обещал – от докера нужна лишь изоляция между приложениями.


А контейнеры без оркестрации в продакшене это воистину мазохизм. Если у вас один хост на хецтнере и полтора сервиса с SLO 50% – ничего не мешает катить ансиблом, а запускать системд, сам так вполне успешно делал. Докер лишь кирпичик в инфраструктуре, а не серебряная пуля, и вроде бы хайп давно прошёл (сейчас как раз по кубернетису угорают, но и он в эксплуатации сложен, пусть и крут).

  1. без глубокого знания докера — эффективно пользоваться кубернетесом не получится. Т.к. сейчас все нынешние дистрибутивы k8s основаны на докере
  2. В силу п.1, безопасность докера = безопасность кубернетеса. Рваться будет по самому слабому звену. Что и наблюдаем.
  3. на роль оркестрации подходит puppet/salt/chef. Как бы и раньше как-то оркестрировали и ничего. ОК. Сейчас еще есть Nomad и Mesos. К сожалению, они на порядок менее популярные, чем куберенетес. Но жизнь в них теплится.
  4. касательно угара по докеру и кубернетесу — это то, что если власть в психбольнице получают психи. То бишь разработчики. Им удобно. А то что необходимо правильно написать софт, чтобы запихать его в кубернетес, они не понимайт или не осиливают. В кубернетесе действительно много классного (если не заглядывать в его код ))) и он реально облегчае некоторые моменты разработки. Но дисциплина разработки должна быть на уровне… иначе — хаос.
nomad прекрасен. C моей точки зрения он имеет один минус — в нем нельзя организовать внутренние сети, с опцией шифрованния, как в swarm.
UFO landed and left these words here

Из таких интересных пересечений по именам — minio. Клиент к этому s3 хранилищу внезапно называется mc. Прям как всем известный mc (midnignt commander).
Еще я видел алиас mc на meteor create.
Чем люди думают, когда так делают, для меня неведомо

да это же просто гошный бинарь, обзывайте как хотите:


# mv ./mc mcli

и проблема решена

да несомненно. Я сделаю. Только почему разрабы заранее это не предусмотрели?
Опен-сурс такой опен-сурс.

Почему бы и нет. Я не думаю, что mc настолько популярен за пределами бывшего СССР, где почему-то были популярны двухпанельные менеджеры типа nc и FAR.


Я например, никогда Midnight Commander не использовал, и вообще редко видел людей, его использовавших. Мне командная строка кажется намного более удобной, и крайне редко, при разборе большого количества фотографий, например, я запускаю какой-нибудь GUI файловый менеджер типа Thunar.


Ни на одном сервере, к которому я имею отношение, Midnight Commander нет и не было. И никто никогда не спрашивал о нем и не просил установить.

Во FreeBSD `mc` много лет был интерфейсом к тулзе управления лентами, а Midnight Commander был `midc`. Переименовали уже где-то около 2006. Источник такой же — та тулза пришла на много лет раньше…

Мало букв в алфавите, что делать :)

Network host mode убивает одну из главных возможностей докера для разработки: запуск кучи приложений на "одном" порту без вмешательства в код/конфиги приложения.

Для разработки, когда изоляция более важна, чем производительность — да.
Для production, когда все равно нельзя допускать выполнение недоверенного кода + ВСЕ равно настраивать софтину в контейнеру + важно быстродействие — ценность бриджа преувеличена.

Если продакшен — это один инстанс каждого приложения большой системы с использованием его собственных (читай — не унифицированных) механизмов масштабирования и балансировки, то может и преувеличена. Я крайне редко вывожу прямо на хост что-то кроме роутеров/балансировщиков.

Контейнеры для компилируемых языков имеют право на жизнь тоже:


  • нет необходимости ставить билд окружения на локальную машину
  • инкапсуляция: вот на днях переписал один сервис с PHP на. Go. Кроме git репозитории исходников и Dockerfile этого сервиса никаких изменений не потребовалось в системе. Есть образ, есть его API (тут в совокупности и API приложения и соглашения докера, близкие к 12f) и на чём он написан не волнует "никого" кроме интерпретатора Dockerfile. Да, есть другие способы добиться подобного, но Докер, имхо, предлагает самый простой, удобный и универсальный на сегодняшний день. Реальная альтернатива, по-моему, сейчас только сборка apt/rpm/… пакетов (порог входа низким точно не назовёшь, есть подозрение, что универсальной тулзы просто нет, нужно разбираться с каждым языком, фреймворком, транслятором, возможно дистром ОС, systemd и т. д. и т. п. ). Плюс какой-то ansible освоить чтобы с багем поменьше дела иметь, плюс придумать свою систему оркестрации "виртуальными" "машинами" и "сетями" если не для изоляции, то хоть для совместного использования ресурсов типа портов.

Почему не рассматриваете подготовку образов операционной системы со всем необходимым? AMI — в терминологии Амазона. Прекрасно осуществляется Packer'ом от HashiCorp


Ах, да, извините, забыл, что у Вас мощностей-то и нет… 1.5 сервера, как я понял, из нижних постов и все. Тогда да — там особо не развернешься.

Было для VMware. Докер удобнее оказался. Вернее удобным оказался запуск докера в VMware машинах.

А если не секрет — операционную систему внутри виртуалки какую используете?
Я бы рекомендовал смотреть в сторону облегченных дистрибутивов вроде coreos / photonos


Действительно — они атомарно обновляются, содержат минимальный набор драйверов (т.к. "железо" в виртуалках стандартизировано), следовательно, идеально подходят под запуск контейнеров.

Использовали обычные серверные Ubuntu/Debian, Как хорошо знакомы админам.

Дополнительно никак не могу не отметить наличие инструментария вроде fpm, который радикально снижает порог входа в сборку своих пакетов, нативных для конкретного дистрибутива.

Внесу свои 6 копеек.
Я тоже недолюбливаю докер, хотя, начал использовать его до того, как это стало мейнстримом.
И мои мысли о тех преимуществах, про которые рассказывают следующие:
1. Безопасность — разработчику плевать, это не то, ради чего он рад пользоваться докером. admin/admin глубоко в коде и прочие радости. Пока разраба не пнут — не пофиксит
2. Изоляция процессов — посмотрите на свой проект, сколько там контейнеров? 5? nginx, java, redis, postgres, logstash? Запусти это всё просто на хосте и ок. Что тут изолировать? Другое дело, если вы — public ci cluster. Может быть.
3. Удобство запуска — НЕТ. Да, выполнить docker run легко. Но прилага на дефолтах. Только «на посмотреть». Когда надо сконфигурить — поехали тонна переменных окружений, монтирование папок, конфиг-файлов и т.д. А entry-points под это дело писать на 2000 строк — то ещё удовольствие.
4. Сетка — стало только сложнее. А когда речь идёт о траблшуте, почему порт из контейнера внутри hyper-v на хост систему не пробросился — почему-то теряются даже сеньоры.

И вот мы подобрались к тому, из-за чего контейнеры стали популярны:
5. Запаковать all-in-one. Современный разработчик — это модный чувак, который сидит под вендой, тыкает пальцем в кнопочку в ide, нихрена не понимает как устроена его ОС, не умеет в линукс, не умеет упаковывать и распространять дистрибутив своей же программы (tar.gz/npm/deb/rpm/gem/whatever). Но при этом разрабатывает, конечно-же, под линукс. И как же ему бедненькому всё что он локально сделал запустить? Правильно, используя stack overflow наустанавливать не пойми чего, скопировать всё подряд и через 30 баш скриптов запустить без особого понимания в докере. Зато работает. А потом на прод.
Docker — это современная package management система.

Ну и, пожалуй, есть ещё один удобный пункт — который близок к 5ому:
6. создание окружения для сборки. Собрал себе в контейнере всё, что нужно, компиляторы, тулы, и т.д. — и собирай себе на здоровье. Кстати, это же можно было делать и в chroot, но да — docker удобнее будет.

Альтернативы: разобраться в пакетной системе. Например, deb трекает каждый файл при установке и гарантировано удалит это за собой во время удаления. Есть жизненный цикл пакета — pre/post-install/rm, pre/post-configure и т.д.

Однако, текущие пакетные системы тоже имеет проблемы, например, нельзя или очень сложно иметь сразу несколько версий пакетов в системе. И тут на сцену выходят следующие ребята, которые решают и это: nix, guix, flatpack, snap, chef habitat.
Изоляция процессов — посмотрите на свой проект, сколько там контейнеров? 5? nginx, java, redis, postgres, logstash? Запусти это всё просто на хосте и ок. Что тут изолировать? Другое дело, если вы — public ci cluster. Может быть.

Маленький пример. Тот же гитлаб, который активно продвигает использование контейнеров для CI, на публичных сборщиках (=раннерах) использует полноценные ВМ с предустановленным docker'ом, а не, скажем, большой кубернетес кластер. А почему? Потому что если IaaS платформа или облако предоставляет виртуалки, то они не сильно дороже в плане трудоемкости создания (мы не про деньги говорим, а про удобство), а изоляция сильно лучше, чем у контейнеров.
Возможно, есть публичные сборочные конвейеры, которые бегут исключительно в контейнерах. Но это какая-то прям стремная история тогда

Изоляция процессов — посмотрите на свой проект, сколько там контейнеров? 5? nginx, java, redis, postgres, logstash? Запусти это всё просто на хосте и ок. Что тут изолировать?

Контейнеризация по типу openvz/lxc/lxd решает этот вопрос. Плюс дает хорошую переносимость. Дополнительно можно сложить пачку легких сервисов на большой и толстый сервак. Я так делал еще в openvz задолго до появления docker. Так-как ставить под почтарь, dns и т.п. сервисы отдельные серваки жирно. А сопровождать их все на одном физическом хосте муторно. Распиливание их по контейнерам приводило к существенному упрощению администрирования.

Мы OpenVZ похоронили очень давно. И перекрестились.
LXD/LXC — да, но пугает, что это в первую очередь убунтовский проект. Остальные компании, то ли мне так показалось, то ли так оно и есть, но не поддержали этот вариант контейнеризации.

Это было в те годы когда OpenVZ было стильно модно молодежно. Ну LXD/LXC да такое, но все же лучше треша в виде docker
Наверное в вашей среде очень крутые разработчики. В моей — они не то, что с докерами мало знакомы, так и вообще про эксплуатацию мало понимают. Админы, в свою очередь, часто мало понимают нюансы работы / настройки конкретного софта. Докер в данном случае является связующим звеном между админами и разработчиками. Благодаря ему центр тяжести ответственности по эксплуатации смещается в сторону разработчиков и они начинают больше думать головой. Нет уже всех этих «а у меня работает», так как воспроизвести прод среду становится кардинально проще. Админ же в свою очередь получает своего рода преднастроенный софт, что значительно упрощает его обслуживание. Про скалабилити и не говорю.
> они начинают больше думать головой
они начинают больше копипастить со stackoverflow в стиле
apt-get install 200 пакетов которые я хз зачем

или
chmod 777 -R /usr # потому что без этого, почему-то не работает


И мой любимчик:
chown 775 /home/app
Devops, он на то и devops, что бы быть посередине между разрабами и админами и не допускать кривое написание докеров. Чаще — писать их самому. Никто же не говорит, что писать докера должны разрабы, мало в них понимающие.

И раскажите, чем преступен chown 775 /home/app в пределах докера, который не запускается под рутом? И не имеет смонтированых шаред волюмов с хоста на запись.

Если мы выделяем devops в отдельного человека, то мы вместо слома барьеров — создаем новые (девы перекидывают код девопсу, а он перекидывает дальше на админов). Более неверного толкования я в принципе не видел.

Девопс один раз собирает «правильный» докер/под из проекта, настраивает CI/CD, пушит всё это хозяйство прямо в проект, проводит базовое обучение как с этим жить и говорит «далее уже ваша проблема как доставить мне стабильный докер для лайва» и это уже становится ответственностью цикла разработки. Тут ключевое, что бы девопс понимал как работу девелоперов, так и эксплуатацию, тем самым определяя требования к софту.

Я понимаю, что pure devops — идёт дальше вплоть до деплоймента в лайв самими разработчиками. Но не везде это возможно.
настраивает CI/CD

это билд инженер или релиз инженер, а не девопс.


Девопс один раз собирает «правильный» докер/под из проекта

В зависимости от темпов разработки и скорости внеения изменений — правильного может и не быть (хотя в каждый момент времени мы можем к этому стремиться).


говорит «далее уже ваша проблема как доставить мне стабильный докер для лайва»

Там еще бездна того, что нужно сделать. Логирование, мониторинг, пр. пр. пр.


Тут ключевое, что бы девопс понимал как работу девелоперов, так и эксплуатацию, тем самым определяя требования к софту.

Опять выделяете это в отдельного человека. :-( На самом деле вопрос что такое DevOps и является ли DevOps каким-то человеком — очень холиварный.


Тут ключевое, что бы девопс понимал как работу девелоперов, так и эксплуатацию, тем самым определяя требования к софту.

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


Но не везде это возможно.

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

Билд инженер, релиз инженер… Кто эти люди? Может потому и нелюбовь в докерам и оркестрации у некоторых, так как эти веяния у кого-то хлеб стали отнимать, «стандартизируя» всю эту работу и выветривая волшебную пыль этих специализаций?

Извините, но Вы же не отрицаете необходимость специалистов по DBA, сетевых инженеров и пр.? Просто иначе мы имеем очень интересных кадавров в инфраструктуре.


Будущее за Т-shaped persons. Это те, которые имеют какую-то глубокую специализацию. А еще имеют широкий кругозор. Если что — переквалифицироваться такому специалисту будет не очень сложно.

Всё зависит от размера организации. Даже далеко не во всех банках есть такие люди. Что уж говорить про относительно небольшие компании. Для них подобная «стандартизация» процессов — благо, так как повышается мобильность с точки зрения передачи знаний и уменьшения издержек на таких выделенных специалистов. Как бы не был сложен K8S, но перенять настроенный кластер другому опытному K8S специалисту будет на порядки проще, чем унаследовать самопальное хозяйство, обвешенное всяким башем и прочей knowhow магией каждой конкретной организации.

Как будто уже выработаны нормальные практики деплоя в k8s, его развертывания, поддержки. Вот же все свои велосипеды пилят. Те же флантовцы, например — werf; booking.com — shipper etc.


Не могу еще не упомянуть разговор на ЛинкМиАп про кубернетес: Докер, Кубер два апдейта.


OpenShift как инкарнация энтерпрайз кубернетеса тоже навязывает свои подходы ко всему вышеописанному, причем… кхм… не всегда оптимальные.

Изоляция процессов — посмотрите на свой проект, сколько там контейнеров? 5? nginx, java, redis, postgres, logstash? Запусти это всё просто на хосте и ок. Что тут изолировать?

Допустим под 20. Но, главное, хочется:


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

Да, можно понаписать башскриптов, можно ещё что-то, но докера (плюс элементов экосистемы) достаточно.


Когда надо сконфигурить — поехали тонна переменных окружений, монтирование папок, конфиг-файлов и т.д.

Не зависит особо от докера. Да, можно ручками зайти на прод и отредактировать конфиг, но если придерживаться IaC из расшариваемых между инстансами папок, то всё равно придётся всё это делать. Для начала на баше.


Сетка — стало только сложнее.

В чём-то сложнее, в чём-то проще. Уровень конфигугирирования сетки инстанса системы переместился с конфигов элементов системы на общий конфиг системы. Грубо, 49 запущенных на хосте nginx слушают порт 8080 и только один слушает 80, роутя запросы на эти 49 и автоматически подхватывая новые. Можно ли подобное сделать на условном баше? Наверное можно, но боюсь представить сколько отдельных скриптов и строк это будет. Не говоря о том, насколько этот код будет поддерживаемым.


Современный разработчик — это модный чувак, который сидит под вендой, тыкает пальцем в кнопочку в ide, нихрена не понимает как устроена его ОС, не умеет в линукс, не умеет упаковывать и распространять дистрибутив своей же программы (tar.gz/npm/deb/rpm/gem/whatever).

Или только в XP может что-то сделать по старой памяти, а начиная с Висты не понимает даже как меню "Пуск" открыть — все попытки приводят к вываливанию какой хрени на весь экран, собственно почему и ушёл с винды в момент выхода окончательной версии Висты. А упаковкой и распространениеми последующим развёртыванием deb пакетов своей программы сыт по горло, особенно когда на целевом хосте (включая как свой собственный ноутбук, так и "кластер" из нескольких ) нужно запустить три версии своей "программы" (набора пары десятков своих программ на самом деле, половина из которых почти одинаковые обёртки над чужими). Немного помогали виртуалки, но бизнес против — дорого выделять максимальные ресурсы для каждого приложения. А вертикальное автомасштабирование той же RAM для виртуалок простым никак не назовешь.


Докер и его непосредственная экосистема (docker-compose прежде всего, плюс, увы подыхающий, docker swarm mode (уж простите, я отличаю его от изначального docker swarm, использование которого в продакшене когда-то инициировал, как и переход на docker swarm mode через неделю после его первого релиза), k8s пока не касаюсь, только его осваиваю и далеко не уверен, что єто проще) сильно упростил работу разработчиков именно в плане решения вопросов типа:


  • как перенести настроенную локально систему из нескольких приложений, состоящей прежде всего из "демонов" на другие хосты, от локальных машин других разработчиков до продакшена с минимальными отличиями
  • как запустить одновременно несколько инстансов этой системы, может одной версии (горизонтальное масштабирование и/или мультитенант), а может разных (dev/QA окружения) на одном или нескольких хостах в связке без особых конфликтов

Альтернативы есть, конечно, но как-то они разработчика превращают в мэйнтейнера и эксплуатационщика по соотношению времени разработки к полному времени. И после внедрения в продакшен докера, даже если есть специально обученные эксплуатационщики (их обучение докеру — отдельный разговор, уже не так актуальный как лет 5 назад) затраты времени разработчика (по крайней мере ведущего с де-факто ролью архитектора) на пакетирование, доставку, разворачивание и эксплуатацию снизились, наверное, на порядок. С 50% до 5. Именно потому что


это современная package management система

пускай и требующая обёрток из баша

В чём-то сложнее, в чём-то проще. Уровень конфигугирирования сетки инстанса системы переместился с конфигов элементов системы на общий конфиг системы. Грубо, 49 запущенных на хосте nginx слушают порт 8080 и только один слушает 80, роутя запросы на эти 49 и автоматически подхватывая новые. Можно ли подобное сделать на условном баше? Наверное можно, но боюсь представить сколько отдельных скриптов и строк это будет. Не говоря о том, насколько этот код будет поддерживаемым.

Лукавите. Этот nginx должен быть специальным образом собран, чтобы он динамически изменял свою конфигурацию в зависимости от запущенных контейнеров. Он это умеет со скрипом, либо приходится сразу ударяться в lua программирование. Есть, конечно, сборка от jwilder. Но какая-то она не production ready. А для тестовых сред очень хорошо себя показал хипстерский traefik


Альтернативы есть, конечно, но как-то они разработчика превращают в мэйнтейнера и эксплуатационщика по соотношению времени разработки к полному времени

Вообще-то в этом и суть явлений DevOps/SRE. Если разрабы не могут сделать конфетку, то пускай они занимаются эксплуатацией, фиксацией багов и их исправлением… И через несколько итераций, внезапно, качество кода вырастет. Потому что если разработка и эксплуатация отделены, то как это не называй, но получится фигня, т.к. ответственность будет размазана.

Лукавите. Этот nginx должен быть специальным образом собран, чтобы он динамически изменял свою конфигурацию в зависимости от запущенных контейнеров.

На самом деле никакой специальный nginx конечно же не нужен, хватит consul + consul-template
Этот nginx должен быть специальным образом собран, чтобы он динамически изменял свою конфигурацию в зависимости от запущенных контейнеров. Он это умеет со скрипом, либо приходится сразу ударяться в lua программирование.

nginx вполне стандартный, специально не надо собирать бинарники nginx, та же сборка от jwilder может біть задеплоена как один контейнер и как два, один из которых стандартный nginx, а второй — абстрактный генератор файлов на базе потока событий от докера.И вполне продакшен реди он было года 3 назад ещё.


Вообще-то в этом и суть явлений DevOps/SRE

Про SRE ничего сказать не могу, даже что знаю только понаслышке не могу сказать. Но вот DevOps явно не про то, чтобы рядовые разработчики занимались эксплуаатацией.

Но вот DevOps явно не про то, чтобы рядовые разработчики занимались эксплуаатацией.

Несомненно — все это хайповое в разработке (agile, devops, xp etc.) — требует высококвалифицированных и высокомотивированных сотрудников, иначе ничего не получится. В стандартном укладке мира, когда вотерфольная разработка и кодеры ничего не умеют — да, их подпускать к продакшену даже на расстояние пушечного выстрела нельзя.


nginx вполне стандартный, специально не надо собирать бинарники nginx

Сам бинарник nginx — конечно, не обязательно пересобирать (но если нужны функции не включенные в базовый — ну, сорян, придется пересобирать), речь больше про то, что придется пересобрать образ и сдобрить nginx всякими дополнительными программными компонентами сбоку (как выше коллега советует — consul + consul-template), чтобы обеспечить это самое динамическое изменение конфигурации.
Очень странно, что это приходится разжевывать. Как будто я недостаточно подробно комментирую изначально, что возможно наводит на неверные мысли?

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

Я немного не про "льзя или нельзя подпускать". Как по мне, то культура DevOps состоит в том, прежде всего, что разработка и эксплуатация работают в тесном контакте, понимая проблемы друг друга и помогая друг другу. Когда все (или самые опытные и т. п. ) разработчики напрямую занимаются эксплуатацией для меня это лишь крайний случай DevOps. Не факт, что идеальный.


речь больше про то, что придется пересобрать образ и сдобрить nginx всякими дополнительными программными компонентами сбоку

Я про то, что дополнительные компоненты сбоку нужны, да, но сам образ nginx может быть стандартным. От компонентов лишь требуется отслеживать изменения на хосте/кластере, подсовывать ему новые конфиги и заставлять их перечитывать.

Небольшое уточнение.


а начиная с Висты не понимает даже как меню "Пуск" открыть — все попытки приводят к вываливанию какой хрени на весь экран

Что-то вы напутали, непонятная хрень на весь экран вываливалась в "восьмёрке". Потом в 8.1 добавили возможность эту хрень закрыть, а в "десятке" вернули что-то похожее на нормальный "Пуск" (по крайней мере, кнопка выключения снова на месте).

Может быть, давно это было. Но что-то в Висте буквально после 0 минут работы заставило начать серъёзно рассматривать альтернативы.

Из того что я помню — там настройку разрешения экрана запихнули в "Персонализацию" (позже в "семерке" вытащили обратно), да и вообще панель управления перетасовали до неузнаваемости. Ну и первое появление UAC, конечно же.

Грубо, 49 запущенных на хосте nginx слушают порт 8080 и только один слушает 80, роутя запросы на эти 49 и автоматически подхватывая новые.

Откройте для себя unix сокеты. Да nginx их умеет, там можно хоть 100500 nginx использовать.

затем, что проблема с 49 nginx на одном порте 8080 надуманна. В любом случае, придется их как-то различать — хотя бы по именам или по instance id, а ценности в этом сильно больше, чем распихивать их по разным парам ip:port, нет.


Кстати, у меня docker-compose scale в какой-то момент стрельнул. У меня было докеризированное приложение, которое обсчитывало на видеокарте некий массив данных. Если делаешь docker-compose scale — все инстансы запускаются с одинаковыми переменными. И либо городить систему, по которой приложение будет узнавать свой инстанс айди, либо пойти по более простому пути (что я и сделал) — просто три блока описания service, каждым со своим уникальным набором переменных (изменяля CUDA_VISIBLE_DEVICES). Так что… Шило на мыло.

Мне их зачем различать? :) Прелесть докера и его экосистемы, что он довольно хорошо прячет под капотом эти различия.

> Допустим под 20
сколько РАЗЛИЧНЫХ контейнеров ранается в проекте. Возможно, у вас действительно 20. Но если у вас кластер эластика на 15 машин — считайте это за 1.

>унифицированные интерфейсы конфигурирования
нет. Переменные окружения? У всех всё по-разному, а некоторые аппы, пока файл не положишь — не заработают. Либо приложение можно удобно конфигурировать, либо нет. Докер тут никак не помогает. И если завтра дедлайн, а конфигурить через файл — будешь монтировать файл.

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

> Да, можно понаписать башскриптов
Не так. «нужно понаписать пачку башскриптов». Entrypoint более-менее непростого контейнера видели? Init перед entrypoint-ом и прочее весёлости. там много скриптов получается. Благо, это не всегда плохо.

> Грубо, 49 запущенных на хосте nginx слушают порт 8080 и только один слушает 80
Это тоже не про докер.
>Entrypoint более-менее непростого контейнера видели? Init перед entrypoint-ом и прочее весёлости. там много скриптов получается. Благо, это не всегда плохо.

Ну так и софт надо писать с пониманием, что он будет запускаться в контейнере. Хотя бы конфиг из env variables должен уметь читать. Тогда и не надо будет колхозить энтрипойнты. Докер — не серебряная пуля для всех проектов, особенно легаси. Но при правильном применении — чрезвычайно мощный инструмент, упрощающий весь процесс.
сколько РАЗЛИЧНЫХ контейнеров ранается в проекте.

под 20 различных образов


нет

Я имею в виду docker-compose.yaml и ко прежде всего.


Это тоже не про докер.

Докер предоставил самый удобный DX(UX?) для этого из тех, что я встречал за 10+ лет работы с ним.

Впервые я посмотрел в сторону докера, когда нужно было
5. [...] современная package management система.
6. создание окружения для сборки.
Если бы были альтернативы и материалы по ним, а также доступный интерфейс, пересел бы.

Пока что
Альтернативы: разобраться в пакетной системе. Например, deb трекает каждый файл при установке и гарантировано удалит это за собой во время удаления. Есть жизненный цикл пакета — pre/post-install/rm, pre/post-configure и т.д.
слишком сложно. К тому же есть ли гарантии, что после перехода на Arch (тем более Windows) или что-либо ещё все deb-пакеты не превратятся в тыквы?

Однако, текущие пакетные системы тоже имеет проблемы, например, нельзя или очень сложно иметь сразу несколько версий пакетов в системе.
Это фатальный недостаток. Особенно это касается изоляции конфигов зависимых программ в зависимости от используемой версии.

И тут на сцену выходят следующие ребята, которые решают и это: nix, guix, flatpack, snap, chef habitat.
Слишком сложно.
Есть ли road map по этим технологиям? Глядишь, найдётся более специализированный инструмент под решение этих задач.
Если бы были альтернативы и материалы по ним, а также доступный интерфейс, пересел бы.

Vagrant? Packer? Можно дистрибьютировать целыми виртуалками — это удобно, когда есть именно, что IaaS какой бы он ни был в организации.


К тому же есть ли гарантии, что после перехода на Arch (тем более Windows) или что-либо ещё все deb-пакеты не превратятся в тыквы?

Действительно — пакетный менеджер привязан к конкретному дистрибутиву Linux. Поэтому после перехода на Arch (а зачем на него переходить вообще? Убунтоводы негодуэ) все пакеты превратятся в тыкву и их придется пересобирать именно под Arch. Под винду вообще сложный вопрос — там есть даже с запуском докера есть нюансы (т.е. условный имидж из докер хаба требует особых настроек для запуска).


Есть ли road map по этим технологиям? Глядишь, найдётся более специализированный инструмент под решение этих задач.

Не видел, но точно так же не видел роадмапа по docker. По k8s — там хотя бы kep есть и комитет, который принимает стратегию развития.

Можно дистрибьютировать целыми виртуалками — это удобно

Не знаю как сейчас и в технологиях, и в реальных практиках в средней руки компаниях, но лет 5 назад дистрибуция и эксплуаатация виртуалками (WMware тогда очень мождно было) или их деклкартивными описаниями (а-ля вагрант) была заметно неудобнее чем довольно сырой тогда докер, а уж после появляения нативной кластеризации года 3 назад, сравнивать просто перестало иметь смысл для меня. Виртуалки заняли место исключительно как платформа для кластера илм, stateful сервисов, которые в кластер не рискнули переносить, типа СУБД.

Я в любом случае предлагаю не зацикливаться на чем-то одном, а использовать весь арсенал технических средств. Как Вы правильно заметили, сейчас засосывать СУБД в кубернетес выглядит как а) опасно б) излишне.

К тому же есть ли гарантии, что после перехода на Arch (тем более Windows) или что-либо ещё все deb-пакеты не превратятся в тыквы?
Удивляет вот это «тем более». Как раз в Windows (и ChromeOS) deb-пакеты использвать можно легко. А вот в Arch — нельзя.

Да, старая история: совместимость GNU/Linux'а с чем угодно лучше, чем с собой… амбиции разработчиков мешают договориться…

Это фатальный недостаток.
Это обсуждать бессмысленно. Основная идея при разработке пакетных менеджеров была: избавиться от дублирования версий. Так-то, сделать несколько deb-пакетов с разными версиями программы — несложно. Скажем можно же поставить 5-10 разных версий GCC «впараллель». Но это именно нужно на этапе разработки программы и её пакета делать.

Особенно это касается изоляции конфигов зависимых программ в зависимости от используемой версии.
Невозможно одновременно бороться с дублированием и заниматься «изоляцией». Ваш К.О.

Есть ли road map по этим технологиям?
Это ж конкурирующие технологии от разных разработчиков! Как у них может быть общий roadmap???
Скажем можно же поставить 5-10 разных версий GCC «впараллель». Но это именно нужно на этапе разработки программы и её пакета делать.

Добавлю, что как только задачи выходят из стандартного десктопа на убунте (подставить свой дистрибутив) и стандартного сервера с одним, максимум — несколькими разнородными сервисами — все равно приходишь к необходимости пакетировать софт самостоятельно. Мы на позапрошлой работе пакетировали и nginx, и ядро, и mysql, и php — т.к. были свои патчи и нужно было ставить неколько версий в параллель. Были и свои внутренние разработки, которые тоже были опакечены ради более легкой установки.

И вот мы подобрались к тому, из-за чего контейнеры стали популярны

Не могу сказать за всех модных разработчиков, скажу за себя. Меня так-то вполне дилетантом можно назвать, знаю всего два языка, в этих всех докерах-кубернетесах не шарю (и у меня есть более интересные и приоритетные вещи в списке для изучения). И На docker hype train я не особо успел, но вот на днях была такая тема, которая меня немножко впечатлила.


Накорябал я там что-то на одном из этих двух языков, что обсчитывает одну штуку работы за пару часов. А обсчитать надо было пару штук. Ну, короче, мне коллега сказал, что если я в докер всё заверну, то он мне поможет это эффективно запустить. Докерфайл я таки осилил написать, завернул, он там чё-то понажимал какие-то кнопки, мезос какой-то, амазоновский ASG, и считалка моя запустилась во всех двуста копиях на AWS. И результат я получил не через две недели, а через те же два часа (ну, почти, на самом деле чуть побольше — некоторые задания были больше других).


И вот это вот круто, это клёво, это мне понравилось. Как это делать не докером (или, обобщая, не контейнерами), я не знаю. Да, я мог бы завернуть всё в deb, но это всё закончилось бы эмуляцией контейнера, потому что в deb пошли бы все зависимости, так как какая там версия хаскеля на машине, которая будет выполнять мою задачу, я не знаю, а если бы и знал, то зависеть бы от этого не хотел.

Тьфу, пока отвлёкся, время редактирования вышло. «Обсчитать надо было пару сотен штук», конечно же.

Ну, здесь понадобилось два человека — раз.
Два — если считалка сама умела параллелиться и как-то в распределенное режиме получать input, а потом давать результат, то неясно чем там докер поможет.
Легко (относительно) можно было запаковать все в AMI и поднять нужноеколичество инстансов EC2. Естественно, что без полного обследованич кода ничего нельзя сказать наверняка.
Возможно вся фишка была в оркестраторе типа Мезоса, но он тоже из однопоточного приложения, которое не умеет в несколько реплик, cloud-native конфетку не сделает.


В любом случае, спасибо за отзыв — очень интересный опыт описали. Т.с. взгляд со стороны.

Два — если считалка сама умела параллелиться и как-то в распределенное режиме получать input, а потом давать результат, то неясно чем там докер поможет.

Тем, что 200-ядерную машину найти чуть тяжелее, а если таки найти, то там всё упрётся в сеть и чтение данных из S3.


Ну и тут нет никакого общего состояния между считалками, каждая считалка просто тупо обсчитывает свою порцию данных, и всё, так что представляется логичным решать разные проблемы на разных уровнях абстракции.

Не могли бы вы выложить этот эксперимент куда-то не гитхаб?
И еще вопросик — во сколько вам это обошлось?
Порой счета от амазона бьют по карману.

Это было сделано для решения некоторой рабочей задачи, что имеет преимущества и недостатки.


Не могли бы вы выложить этот эксперимент куда-то не гитхаб?

Тут, увы, недостаток: это всё закрыто, от исходников до схемы данных, так что, к сожалению, нет.


И еще вопросик — во сколько вам это обошлось?

А это преимущество: понятия не имею, компания платит. Спросил у знатока в амазоновских вещах, он говорит, что не больше баксов 20. Там, типа, дешёвые spot instances, все дела.

1) Языков с нормальной компиляцией в wasm нет, rust разве что. Большинство через llvm и emscripten. Тот ещё костыль.
2) WebAssembly создавался для браузеров(слово web названии какбы намекает) для пропуска этапа парсинга и оптимизации js кода, а также для поддержки других языков программирования. Производительность не была главной целью, даже многопоточность недавно завезли. В общем, такой код сильно уступает в производительности нативной реализации.
3) Wasi совершенно не готов. До сих пор идут обсуждения основного api. Сборка возможна только для сишного кода и скоро можно будет на расте.

Т.е. для серверов wasm не готов. И вряд ли будет в ближайшем будущем.
На мой взгляд, Wasi — это попытка создать эдакий jvm для раста и ещё парочки яп. Т.е. кроссплатформенность — один раз собрать для кучи платформ. Но как показывает java, такое не особо работает. В теории можно, но как только проект вырастает больше hello world'a начинают появлятся платформоспецифичные хаки. Или использование приложения удобно только под Windows, под Linux тоже можно запустить, но выглядит слишком инордно и вызывает дискомфорт.
Думаю, статья утратила свою актуальность (в том числе выше перечисленные аргументы по сетям и прочему), потому как в 2019 мало кто деплоит Docker на production. Docker (вместе с docker-compose) нужен для рабочего окружения разработчиков, CI и пр. Production ready это k8s (или его «мини» версии, типа mikrocube или k3s) с runC вместо Docker.

Как будто проблемы разработчиков никто не должен решать (вот та же история с перекрытием сетей — думаете, что она не пьет кровь девам?). А они зачастую не в состоянии это сделать, т.к. у них фокус не на админстве.


CI и пр. Production ready это k8s (или его «мини» версии, типа mikrocube или k3s)

Повторюсь, что не всегда и не везде кубернетес нужен. Есть куча компаний, которые с радостью его "продадут" вам как клиенту, т.к. это является основой их бизнеса.


За упоминание k3s — жирный плюсик. Спасибо

Rancher/k3s, есть разные «кубер для людей» дистры, которые не намного сложнее чем тот же docker swarm. Который умер, конечно же.
Когда сетапы с контейнерами становятся настолько сложными, что возникают проблемы которые вы описываете, это время выбирать нужную оркестрацию.
Для обычных тасков на компе podman хватает за глаза.
А с какими проблемами настройки сетей вы сталкивались в k8s? Если речь идёт про классические приложения (например, Django), то я склоняюсь к тому, что без k8s или его урезанных версий на проде нормально не настроить те же сети. А если хочется больше автоматизации, можно (и нужно имхо) брать managed k8s у того же Google или DO.

K8s и сети — это одна сплошная проблема. Начиная от вопросов выбора — какой cni мы хотим. И как мы хотим его настроить.
К тому же, я больше говорил про проблемы разработчиков с докером на их машинах. Согласитесь — вряд ли разработчики будут тащить полноценный кубернетес к себе на ноутбук или рабочую станцию (разве что в урезанном виде а-ля minikube или k3s).


По поводу того, что лучший кубернетес — тот, который ты не хостишь, т.е. в идеале — managed от Гугла — полностью согласен.
Единственное, что действительно похоже (некоторые коллеги озвучивали такое мнение), что сложность k8s именно что избыточна и создана специально, чтобы все переезжали в облако к Гуглу. Почему мы уверены, что это так — потому что есть оркестраторы намного проще (вроде связки nomad + consul).

У меня есть еще пара соображений.


  1. Отвратительная документация. Возможно, это моя идиосинкразия, но когда только учился готовить Docker, пришлось прочитать кучу информации не с сайта docker, потому что документация на официальном сайте сухая и бесполезная. Она очень плохо объясняет даже простые вещи и написана нечитаемым образом. Из нее очень сложно сложить цельную картину. Для этого требуется читать сторонние источники и много экспериментировать.
  2. Миллиард багов. Например, лично из моего опыта: пару дней билдил конфигурацию для клиента, у которого Mac. Он мне возвращал со словами: «У меня не работает». В итоге, после долгой и нервной отладки и долгого гуглинга, всплыло наконец, что в Docker для Mac при каких-то условиях на каких-то версиях docker может свалиться интерпретатор Python. При этом далеко не всегда эти баги правятся и не всегда есть возможность оперативно установить исправленную версию… В которой могут быть свои баги и несовместимости.

А уж это залезание docker'а кривыми руками в сеть просто… Очень неудобно.

Отвратительная документация.

Как думаете — это сделано умышленно? Или само так получилось? Дело в том, что есть сертификация по docker. Получается можно заплатить денег и вас ему научат :-o :-o :-o А раз так, то с капиталистической точки зрения нужно делать продукт достаточно хорошим, но не более. Чтобы новички быстро в него въезжали (цель достигнута), а профессионалы могли рубить капусту (вроде как тоже).

На самом деле есть вполне бесплатный Katacoda — для любителей сразу потрогать ручками

В общем хотел было стать модным. Читал читал про докер. Уже вроде как занес руки над клавиатурой. И так и остался со своими VirtualBox-ми. Брат жив. :)) Никаких костылей не изобретаю. Если нужно. То под Виндой или Линухом разворачиваю все и живу спокойно.Правда у меня и виртуалок всего 5-6 штук по десятку юзеров на них.
Я вот считаю докер (как и любые другие прослойки) костылём. Мы собираем свои программы в пакеты установки для Линукса. Стараемся, что бы всё разворачивалось и удалялось максимально прозрачно насколько это физически возможно. Да, разработка ведется в Windows (Delphi + FPC/Lazarus), но это никак не мешает и софт и пакеты собирать. Чем меньше зависимостей — тем лучше. Наш путь такой.
Тоже считаю докер костылём, но не костылём для поставки/инсталляции, а костылём изначально недостаточной изоляции процессов в операционных системах.
Я раньше собирал в deb-пакет одно наше приложение. Перешел на докер. Во-первых словил проблемы с libssl, который немножко разных версий на разных дистрибутивах, и собранное на одном компе не может запуститься на другом. Наверное, это можно решить, но неудобненько как-то. Во-вторых, обновление софта через Докер оказалось быстрее — пока deb пакет удалится, пока свежий поставится, пока подтянет зависимости, если они появились… А вот вытянуть свежий образ, остановить контейнер, создать новый контейнер, запустить — работает просто прелестно, даунтайм близок к нулю.

Главное не ставьте Docker под Ubuntu через snap — словите непонятных багов, честно, сами встречали такое.
Автору спасибо и за эту публикацию и за самоотверженный труд в его Tg-каналах. Лично мне помог избежать многих граблей и смог объяснить все заданные вопросы на пальцах.
Я не думаю, что описанные особенности сети ведут к массовым проблемам. Скорее всего, они становятся проблемными в каком-то ограниченном количестве специфических случаев. В своем опыте еще ни сталкивался с такими кейсами. Хотя, может потому, что опыт использования Docker пока небольшой.
Я уже год немножко оператор проксей и VPN для обхода блокировок.
И после парочки итераций я пришел к докеру.

Почему? Потому что мне хочется единообразного цикла доставки и управления помянутыми проксями и впнами на различных хостах для различных пользователей.
У меня есть Docker Hub как источник образов, и подготовка хоста заключается в одной команде.
apt-get -y install docker.io python python-flask && docker pull [тут образы]

всё.

Но есть существенное отличие от энтерпрайзных сценариев — у меня контейнеры автономные (не требуют зависимостей в виде других контейнеров).

Единственное что пришлось «допилить напильником» — свою примитивную систему менеджмента конфигураций и управления запуском контейнеров. Потому что держать в голове подробности не хочется, а кубернетес для моих целей слишком монструозен.
Один основной питоновский скрипт и 3 утилитных к нему. Скоро на гитхабе.

Живу так больше года.

Очень ждем! Круто будет посмотреть. Мы в свое время использовали для тестового стенда прекрасный образ https://github.com/kylemanna/docker-openvpn


А еще мне пришлость forticlient закатать в docker, т.к. там был нюанс с тем, что он радикально портил route на моей машине.


Единственный недостаток, что vpn в docker требует privileged режима или определенного cap NET_ADMIN.

для моих целей хватает Shadowsocks, которому замечательно в докере живется.
для десктопных клиентов — pptpd на хосте.
да, знаю, что obsolete, зато вездеходно и настраивается неквалифицированными пользователями.
Кошмар — это как раз OpenVPN — скачай клиента, заморочься с УЦ, экспортируй профиль, обломайся, если в ядре нет tun/tap.
Блондинке-гуманитарию попробуйте это всё объяснить.
Shadowsocks — отличный mobile-first VPN для обеих платформ с легким конфигом и небольшим потреблением ресурсов.
держать в голове подробности не хочется, а кубернетес для моих целей слишком монструозен

Не смотрели в сторону Nomad?

Нет. Судя по нагугленному, ему еще и консул требуется, для меня это избыточно опять же.
Соглашусь. По моему опыту написать yml файл протестировать его развертку, затем стабильность работы и в итоге переодически ловить баги из-за того что в репозиториях что-то изменилось и билд уже не торт, занимает дольше времени, чем топорно вручную поставить линух, настроить его и закатать в vdi образ и потом клонировать сколько нужно раз.
По-крайней мере там где я работал раньше крутилось 30 инстансов в AWS и я не трогал их по пол года и больше. И были среди них два микросервисных докера напиханные bash-костылями. А для стабильной работы контейнеры каждую ночь пересобирались.

Конечно в подходе «сломалось — выкинь и сделай новое» тоже есть рациональное зерно. Но ИМХО поднять простецкий LAMP в виртуалбоксе гораздо быстрее и удобнее чем ковыряться с докером в девелопе. Хотя второй создан как раз для быстрого развертывания среды.

Конечно у меня нет опыта работы в проектах с сотнями и тысячами серверов, там правила и условия, но и докер частенько используется в проектах с общим количеством машин не больше 10.
На той же vmware можно построить гораздо более стабильную и отказоустойчивую систему нежели модный кубернетес, который поверху тех же виртуальных серверов и ставится, которые абсолютно так же падают.

И из-за этого действительно бомбит, потому что когда приходишь на собеседование и тебя начинают гонять по «брендовым» словечкам аля контейнеры, кубернетес, эластиксерч, флуентд, а ты им говоришь, ребята, у меня тут пару серверов было, я набросал пару скриптов на баше, накинул забикс и все это нормально работало, то на тебя смотрят как на идиота, который не постиг ит-дзена и ничего не умеет.
ого что в репозиториях что-то изменилось


Во первых форкаем чужие докера к себе, во вторых не используем :latest. Неумение готовить — проблема обучения, а не инструмента.

Виртуалки не заменяют докера, как и докера не заменяют виртуалки. Эти 2 технологии хорошо дополняют достоинства друг друга.

Под репозиторием я имел ввиду не только репозитории докера. В овер 90% docker-compose файлов установка nginxов и mysqlей идет на лету во время билда. Это вполне готовые семплы или рабочие контейнеры, которые даже на гитхабе много звезд имеют.
Делов-то, форкнуть epel репозиторий.


Виртуальный сервер из образа с каким-нибудь ansibleом можно развернуть также автоматически как и контейнер.
Из неоспоримых плюсов можно назвать только скорость непосредственного билда и лёгкость контейнера.
Правда, когда говорят о производительности контейнеров, почему-то сравнивают 5 физических машин, по сервису на каждую, против 5 контейнеров. А если все эти сервисы положить на один хост, то получится гораздо более производительная система, чем с 5 раздельными контейнерами.
Потом говорят про то что контейнеры легко удалять и создавать, так это потому что они без падений дольше месяца не работают, за ними постоянно нужно следить.
Чтобы работать с контейнерами нужны более квалифицированные и админы и программисты, чем при работе с виртуальными серверами. И это факт, доказательством которому может служить повсеместный виртуалбокс, который как игрушку ставят. Как можно упрощать инфраструктуру усложняя её?


Когда ковырялся с кубернетес, он мне на лопатки два ноутбука с 4мя виртуальными машинами клал при запуске "hello world" на nginx кластере из 2х контейнеров. По старинке на LAMP на этих буках можно онлайн магазин с тысячами просмотров в день развернуть и еще ресурсы останутся.
Контейнеризацию выгодно продвигать только облачным провайдерам, потому что легко и быстро перебрасывать и перераспределять свободные ресурсы и, соответсвенно, перепродавать. Чем они и занимаются.
В общем я пока что до этого либо не дорос, либо наоборот, консервативный старпёр.

Потом говорят про то что контейнеры легко удалять и создавать, так это потому что они без падений дольше месяца не работают, за ними постоянно нужно следить

Это работа оркестраторов, типа к8 и пр. Сами все переподнимут.
Чтобы работать с контейнерами нужны более квалифицированные и админы и программисты, чем при работе с виртуальными серверами.

Это сомнительное утверждение. Что не отнять у докера, так это популяризация контейнеров в среде девелоперов. Обычные программисты спокойно им пользуются без всяких проблем, уж точно не «квалифицированные админы». Последние нужны уже для оркестрации и продакшена.
Когда ковырялся с кубернетес, он мне на лопатки два ноутбука с 4мя виртуальными машинами клал

Зачем вы добавили виртуалки? Они как-раз и сожрали все ваши ресурсы.
Контейнеризацию выгодно продвигать только облачным провайдерам, потому что легко и быстро перебрасывать и перераспределять свободные ресурсы и, соответсвенно, перепродавать. Чем они и занимаются.

Это выгодно не столько провайдерам, как их клиентам. Отказоустойчивый кубер в облаке, где крутятся их микросервисы — и ничего больше не надо знать. Сам все переподнимет, перескейлит, и т.д. и т.п. Экономия на нескольких работниках в компании.

Отказоустойчивый кубер — да, но толку от него, если приложение не соответствует лучшим практикам написания для cloud native среды
Кубер — не магическая палочка или серебряная пуля, которая автомагически решит проблемы бизнеса
Несомненно — кубер даёт новые возможности. Например, экономию денег на спот инстансах (появляется возможность использовать их, а не обычные вм). Возможность проводить хаос инжиниринг. И пр. Но какой ценой?

Простой пример — коллеги разрабатывают сайт для небольшой компании. Нагрузку сайта (стандартно — БД + nginx + php-fpm) прекрасно держит одна VPS. Ну, ок — хотим немного отказоустойчивости — cloudflare + второй инстанс. Они пробовали разрабатывать на кубернетесе — не зашло. Слишком сложно и дорого (брали GKE, причем я не участвовал в выборе, конфигурировании среды).


Второе. Кубернетес выдвигает определенные требования к приложениям. Определенный способ упаковки, декомпозиция по контейнерам, эндпойнты для healthcheck/readiness и многое другое. В целом, это все не очень плохо, тем более, когда смотрим на далекую перспективу. Но для какой-то простой штуки (не знаю, прототип телеграм бота, например) все это может оказаться излишним, а, следовательно, на начальных стадиях внести оверпрайс в разработку.


Условно — отказоустойчивый сервис по обработке данных я и без k8s на консуле (etcd/zookeeper) + питоне на трех нодах запущу. И это будет проще и дешевле.

Вебсайты прекрасно лягут на кубер, он для их и написан в первую очередь. То, что товарищи не смогли разбить по сервисам в докере очень странно. Я думаю по первым трем результатам в гугле можно найти примеры на БД + nginx + php-fpm.
То что дорого — верю. Но платить зарплату админам которые над этим всем сейчас работают тоже дорого. Может даже еще дороже.
Если писать приложение правильно с самого начала, используя контейнеры, то проблем быть не должно. Если это перевод существующего монолита, то это конечно много дополнительной работы. Многие на этом и зарабатывают, помогая перейти на контейнеры.
Но в конце концов решает бизнес — насколько надо отказоустойчивость и скейлинг приложению.
То, что товарищи не смогли разбить по сервисам в докере очень странно. Я думаю по первым трем результатам в гугле можно найти примеры на БД + nginx + php-fpm.

Откуда такой вывод, что ребята не осилили декомпозицию? Я такого не писал.


Но в конце концов решает бизнес — насколько надо отказоустойчивость и скейлинг приложению.

Именно так.


Если писать приложение правильно с самого начала, используя контейнеры, то проблем быть не должно. Если это перевод существующего монолита, то это конечно много дополнительной работы. Многие на этом и зарабатывают, помогая перейти на контейнеры.

Вы же наверняка слышали рекомендации, что не стоит начинать с микросервисов, т.к. зачастую получается самая ужасная вещь — распределенный монолит. А лучше начать — с монолита, который решает какую-то задачу, а потом начать его потихонечку распиливать на микросервисы. По-моему, так даже великий Фаулер завещал.

Ну монолит монолиту рознь. Зависит от апликухи, но по нынешним временам например замоноличивать фронт с API и всяким BL — расстрельная статья. Дробить же API на 100500 контейнеров под каждый метод — та же статья.
Может раньше так и было лучше. Если уже все накатано и народ уже мыслит микросервисами, то не вижу никаких проблем сразу их и писать. Особенно в вебе, где все уже жевано-пережевано.
  1. не умеет средний разработчик в декомпозицию. Если он родит не монолит, то родит "100500 контейнеров под каждый метод — та же статья", как выше пишет usego
  2. web'ом задачи не ограничиваются. Есть хадупы, (потоковая) обработка данных, телефония и много чего еще интересного.
не умеет средний разработчик в декомпозицию. Если он родит не монолит, то родит «100500 контейнеров под каждый метод — та же статья», как выше пишет usego
Для этого есть Software Architect. Средний разработчик и не обязан уметь.

А вот если не веб, тогда уже интереснее, да. Хотя здесь большинство просто тупо переходит на амазон/гугл/ажур и пользуется облачными сервисами.
Хотя здесь большинство просто тупо переходит на амазон/гугл/ажур и пользуется облачными сервисами.

Не все могут. По различным причинам. Начиная от специфики российского бизнеса. И кончая ограниченным бюджетом и кругозором.

Насчет бюджета — я часто слышу мысль, что держать спецов по определенным технологиям гораздо дороже чем платить Амазону за менеджмент этих технологий. Так что не все однозначно (с)

Для простого сайта без резервировнаия/масштабирования k8s сожрёт слишком много человеко часов. docker-compose вполне справится, сочетая плюсы контейнеризации с отсутствием минусов конфигурирования огромной системы оркестрации.

ansible прекрасно заменяет docker-compose.
Единственное, чего не умеет ansible — это тушить контейнеры по лейблам, но решить это запросом к docker api и фильтром json не проблема.

Может и справится, но чем он лучше будет в этом качестве? И можно ли с ним делать такие вещи как docker-compose logs --follow?

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

Я имею в виду что эта команда предполагает что человек смотрит на вывод в терминале. А дело оркестратора — задеплоить и свалить с сервера, а не быть залоченным с --follow.
После этого вы можете вручную зайти и смотреть с --follow. Ну или попросить ансибл сделать docker-compose logs в файл и принести вам этот файл.

У нас немного разные представления об оркестраторе. Мне вот docker-compose как оркестратор как не нравится тем, что слишком рано сваливает с сервера в отличии от того же docker swarm mode, а ansible вообще как оркестратор не воспринимаю.

не нравится тем, что слишком рано сваливает с сервера в отличии

Разверните, пожалуйста, мысль. Какой Вам функционал нужен?

Да вот теже логи агрегированные со всей системы или отдельного его сервиса

Ну, выглядит будто Вам не docker-compose logs нужен (тем более, что он отловит только логи, сгенерированные ТОЛЬКО в рамках конкретного "проекта" — по сути из одного docker-compose.yaml), а трейсинг, сопоставление и агрегация в единой панели. Да и завсегда может быть какой-то внешний по отношению к компоуз-файлу сервис, который тоже захочется помониторить. В общем — эта задача не решена. Да и не решаема она без сборки какого-то единого централизованного хранилища логов, но это выглядит так, что про локальную разработку (вообще без интернета, подсоединения к рабочим серверам и пр.) придется забыть.
А если разрабатывать конкретный модуль и все его зависимости мокать, то разницы между docker logs & docker-compose logs нет. Ну, потому что проверяемый элемен один


Единственное для чего я вижу пользу от docker-compose logs или docker-compose up (желательно еще с ключом --abort-on-container-exit, но это тоже палка о двух концах) — использование в пайплайне CI/CD, чтобы сразу получать лог запуска для последующего сохранения в артефакты и изучения. Но вообще-то для этого есть и более удобные средства, так-то.

а трейсинг, сопоставление и агрегация в единой панели.

Да, это было бы идеально, если при этом не надо инвестировать кучу человеко-часов и всё работало бы локально. Но простой docker-compose log хорошее решение.


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

Мы предпочитаем поднимать локально всё приложение, а совсем внешние зависимости типа сторонних API просто не иницализировать локально, если нет тестовых доступов. При этом локально могут быть подняты несколько версий одного приложения, например, мастер ветка и фичи.


Полноценные моки, да с конфигугрированием потребуют много времени, а пользы ощутимой не видится.

Вы серьезно пользуетесь это функцией?
Ну, это, как минимум, означает, что Вы пользуетесь docker-compose up -d, т.к. если бы Вы запускали набор контейнеров без -d, то лог запуска был бы перед глазами — это раз.
Два — ансибл у Вас не отнимает возможность выполнить команду docker logs -f .., если очень хочется. Выгода компоуза тут преувеличена.

Ещё интересный момент, что уже появилось поколение людей, которые знают компоуз, разбираются в его ключах запуска, директивах, но абсолютно беспомощны перед лицом "голого" докер-клиента. Занятно, не так ли?

Нормально. Вот уже (лет 30 назад точно) появилось поколение людей, которые используют PRINTF(3), но абсолютно беспомощны перед лицом "голого" ядра, без stdlib, не говоря о загрузке на голом железе, когда и ядра нет. Занято?

Серьёзно. И да, предпочитаю запускать docker-compose up -d, Как я понимаю природу ansible он плохо справится как с docker-compose up, так и с docker-compose logs --follow


docker logs очень неудобен когда хочется иметь агрегированный лог

С docker-compose up вроде никаких проблем. Особенно если вы используете ансибл вместо docker-compose — тогда просто запускаете контейнеры в своем порядке. По-моему именно это gecube и имел в виду.
docker-compose logs --follow это вообще отладочная функция, расчитанная на интеракции с человеком.

docker-compose up (без -d) не делает exit/return после поднятия контейнера, ansible не рассчитан (могу ошибаться) на такой режим.


А наличие отладочных функций очень упрощает отладку многопроцессных приложений.

Ошибаетесь.
Ансибл прекрасно работает в режиме "наплодил контейнеров и ушел с сервера".
Вот возьмите и попробуйте наконец-то. Чего обсуждать?
Или боитесь, что вдруг понравится?


Мы пришли к ансиблу по следующим соображениям:


  1. Зачастую недостаточно сделать docker-compose up -d
    А нужно сделать ещё кучу действий, чтобы запустить контейнер (мы не про микросервисную архитектуру, а скорее про использование докера как такого пакетноно менеджера)
  2. Зачем на удаленной машине лишний компонент в виде docker-compose? Ну, и если локально на удаленной машине делать docker-compose up, то, как выше уже заметили — у вас уже две проблемы: запуск контейнеров и доставка описания контейнеров в виде docker-compose.yaml на эту удалённую машину
  3. В теории compose умеет цепляться к удалённому демону. Но это костыли и риски ИБ: кто его знает как там написан docker демон.
  4. Отсутствие шаблонизации в compose. Зачастую нужно, чтобы одни и те же параметры присутствовали в разных контейнерах (например, бд и бекенд). Или возможно нужно запустить 10к контейнеров из одного образа с разными параметрами. На ансибле эти задачи решаются на раз-два. В компоузе — ихх решить тоже можно, но через копи-паст и боль.
Ансибл прекрасно работает в режиме "наплодил контейнеров и ушел с сервера".

Я о противоположном режиме: наплодил контейнеров и мониторит их.


Вот возьмите и попробуйте наконец-то. Чего обсуждать?

Пробовал. Не понравилось для управления докером. Развернуть докер на новом хосте — нормально. Оптимальным для меня оказался ansible для разворчивания докера в swam режиме и оркестрация через docker посредством docker-compose.yaml. Даже если "кластер" из одной машины, включая мою рабочую. Увы, принято решение на кубик переходить. И, более того, это моя задача обеспечить переход. Вот курю сейчас маны кубика, хелма, хелмфайла и т. п. Причём последние исключительно из-за того, что в кубике нет даже той шаблонизации что есть в docker-compose (интерполяции env в т.ч. из env файлов)


Мы пришли к ансиблу по следующим соображениям:
наплодил контейнеров и мониторит их.

docker-compose их не мониторит. Если Вы думаете по-другому, то, извините, но ошибаетесь. Вообще с мониторингом работы контейнеров в docker в целом плохо. Смотрите статью и комментарии.


Причём последние исключительно из-за того, что в кубике нет даже той шаблонизации что есть в docker-compose (интерполяции env в т.ч. из env файлов)

А она там и не нужна. К тому же в kubectl завезли шаблонизатор от гугла — kustomize. Он не идеален, но решает часть проблем.
Некоторые (как коллеги в телеграм каналах https://t.me/ru_devops https://t.me/kubernetes_ru) — тоже используют ансибл для деплоя в куб (почему нет!?)

docker-compose их не мониторит. Если Вы думаете по-другому, то, извините, но ошибаетесь

вывод логов с follow — минимальный мониторинг.


А она там и не нужна.

Кому как. Например, я не нашёл простых способов деплоить приложение в разные окружения с разными настройками, зависящими от окружения с которого запускают деплой. Например, версия образа по git branch/tag/hash.


К тому же в kubectl завезли шаблонизатор от гугла — kustomize.

Kustomize introduces a template-free way to customize application configuration


Это не шаблонизатор, а попытка решить задачи, традиционно решаемые через шаблонизатор, без шаблонизатора.


тоже используют ансибл для деплоя в куб (почему нет!?)

Когда в руках молоток…? :) А если серьёзно, то в таких дискуссиях ожидаю получить не вопрос "почему нет?", а ответы на вопрос "чем лучше стандарта де-факто или хотя бы нашего текущего решения и какой ценой (дополнительно к полному переобучению команды и новой зависимости в стэке, пускай и взамен старой) это достигается?"

Когда в руках молоток…? :) А если серьёзно, то в таких дискуссиях ожидаю получить не вопрос "почему нет?", а ответы на вопрос "чем лучше стандарта де-факто или хотя бы нашего текущего решения и какой ценой (дополнительно к полному переобучению команды и новой зависимости в стэке, пускай и взамен старой) это достигается?"

Я позволю себе быть немножко смелым и постулировать следующую вещь: если Ваш кластер сам по лучшим рекомендациям GitOps не забирает свое состояние из репозитория (тыц, кстати, не самый плохой подход), то Вам ПРИДЕТСЯ при обновлении софта ПУШИТЬ изменения в кластер через кубернетес-апи. А это, извините, Вы можете делать своим любимым инструментом — что хельмом, что ансиблом, что напрямую применять манифесты YAML через вызов kubectl -f apply. Разницы нет.


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

Посмотрите аргументацию почему так, а не иначе:
https://github.com/kubernetes-sigs/kustomize/issues/388
Ну, в крайнем случае патч-файлы или манифесты куба можно на лету генерить (опять отдельный шаблонизатор тащить — будь то envsubst, jinja, gomplate или что еще)...


Либо использовать другие техническая средства вроде jsonnet.

Изучал я все эти аргументации. Основное в них "kustomize supports the best practice of storing one's entire configuration in a version control system." (причём supports это мягко сказано, forces точнее будет). А это то, что мне не нужно, мне нужно обратное: иметь в репозитории шаблон, в который при деплоее генерировать конечные значения в соотвествии с целью деплоя. Этот "крайние случаи" — основа нашего CI/CD и дев/тест флоу.


то Вам ПРИДЕТСЯ при обновлении софта ПУШИТЬ изменения в кластер через кубернетес-апи. А это, извините, Вы можете делать своим любимым инструментом — что хельмом, что ансиблом, что напрямую применять манифесты YAML через вызов kubectl -f apply. Разницы нет.

Вроде речь шла о docker-compose. Но в целом понятно — разницы нет.

Обычные программисты спокойно им пользуются без всяких проблем, уж точно не «квалифицированные админы».

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

Пользуются докером, а не кластером к8с. Это слегка разные вещи.
Такие вещи делаются не руками, а оркестраторами или системами конфигурации как ансибл и т.д. Если он создает с нуля, то он работает уже не как программист, а как девопс :)

А с :latest отдельная история была, когда на сервере два года gitlab крутился созданный из latest, а после переустановки хостовой ос на более новую (а вместе с ней и докера и докер-композа, а про совместимость в статье уже было написано), пришлось создавать новый контейнер. Вот тогда пришлось знатно поснашаться, чтобы узнать что же за latest версия была два года назад и потом узнать что в репозитории, оказывается, самой старой версии всего пол года. А все что до этого сожжено в адском пламени.
Да, конечно, это не прямой косяк докера, косяк докера в том, что пока на эти, и многие другие, грабли не наступишь — ничего дурного не заподозришь.

Могу посочувствовать. Чтобы не попадать в такую историю достаточно сохранять id образа и сам образ (т.к. спустя столь продолжительное время его могут попросту удалить). Есть ещё подход — бежать так же быстро, как и окружающие, и своевременно обновляться, но это прям очень ресурсоемко.
В любом случае, признаю — я тоже задним умом силен, а не передним, но катастрофы проще предотвращать, чем ликвидировать последствия.

Как-то мне надо было привязать сервис в докере на один IP на интерфейсе (из нескольких). Не host mode, не определенный порт, а именно все порты на один IP. Единственное что нашел — это проброс 0-65535 портов на определенный IP. Какое же мое удивление было обнаружить, что вместо того чтобы использовать range в iptables, docker создает там 65535 правил!
Как-то несерьезно даже.
Некоторые выводы в статье конечно не очень в тему, например про dockerhub. Он задумывался как github только для контейнеров, чем он и является. И хорошо свою функцию исполняет. Вы же не жалуетесь что на github много мусора и вообще это помойка?

Да, хотел привести пример github'а, который тоже превратился в помойку.
Но на самом деле есть разница. Docker Hub мог бы модерироваться Docker Inc по примеру магазинов приложений (Apple Store, Google Play) или репозиториев ПО (любой серьезный репозиторий любого серьезного дистрибутива). Но нет. В docker hub даже не всегда можно понять ИЗ ЧЕГО получен образ и какова его история изменения. А в гитхабе никто ничего не гарантирует. Вообще.

В dockerhub есть официальные образы, от компаний или сообществ — типа PostgreSQL, Apache т.д. Если нужно что-то официальное, то это к ним.
Все остальное делают сами люди, в том числе и я. И уже чего точно не надо, так это модерации а-ля гугл в андроиде. Это прямой путь отвратить от себя всех разработчиков)) Если бы модерировали гитхаб от всяких хелловордов, он бы никогда не стал бы гитхабом.
В dockerhub есть официальные образы, от компаний или сообществ — типа PostgreSQL, Apache т.д. Если нужно что-то официальное, то это к ним.

тем не менее — даже официальные образы имеют определенные родовые болячки и требуют доработки напильником. Например, самое очевидное — разброд в том, каким образом передавать настройки приложения. Какие-то образа ждут переменных окружения, какие-то — файла конфигурации. Другой вопрос, что да — докерхаб позволяет взять готовый образ и протестировать какую-то гипотезу быстро. Относительно быстро, учитывая время необходимое для того, чтобы разобраться как с конкретным образом работать. Но в production это пускать… Такое себе. А собирать все образы под себя — просто умрешь от объема работы.

Какой объём работы? Если у вас уже есть скриптование для инсталяции серверов / виртуалок (надеюсь оно есть??), то всё это в докера переводится на раз два. Команды ведь те же плюс минус.
то всё это в докера переводится на раз два

Нет. Нужно учитывать специфику докера. volume, init, права пользователей, отсутствие systemd и пр. пр. Поэтому — не раз-два.

Ну ок, да, софт надо готовить к докеризации и оркестрации. Но стрёмный дремучий монолит не делает докер плохим. Это монолит плохой и нуждается в рефакторинге независимо от докеризации. Докеризация — это не только про packaging, это про подход к разработке софта, что бы получать от всего этого максимум пользы.

Так докер не про микросервисы, а контейнеры. Как бы немного ортогональные вещи.
А для написания современного софта совершенно неглупые люди придумали 12FA.

Смешались в кучу кони, люди. Ладно, нам оно помогает делать процесс эффективней и прозрачней, как бы это ни называлось. За статью спасибо, но в реальной жизни таких проблем просто нет, при правильном подходе к работе. Даже перечитал ещё раз пункты, что бы не соврать. Ну одно это чего стоит:

В теории можно задать максимальный размер и параметры ротации, но кто это делает? Только честно


Да все это и делают. 3 строчки в конфиге. Потому что те, кто с этим реально работал, на эти грабли наступали уже N лет назад и давно приняли на вооружение как best practice. Так же и с остальным.

Ну, вот смотрите честно — из коробки никаких лимитов нет (мы же помним, что дефолтные настройки почему-то всегда оторваны от жизни). Соответственно, я почти наверняка уверен, что каждый пользователь докера сталкивался с переполнением диска от логов.
Можно написать целый талмуд с рекомендациями (от "ограничивает размер логов" и "используйте другой драйвер логов" до "выделяйте под докер отдельный том (раздел)) — только толку? Как стреляли люди себе по ногам — так и будут.
Что интересно — единого свода таких эксплуатационных рекомендаций (по сути — best practice) я не видел. Может плохо искал. Поэтому каждый ходит по граблям самостоятельно. Иногда это весело. Иногда не очень