Комментарии 539
wait-for.sh упомянуть бы
Коллеги неоднократно упоминали wait-for.sh в контексте статей про Докер, здесь на Хабре. Например, хотя бы тут
К сожалению, это неидеальное решение, т.к. контейнер получается запущен и ждет остальные (т.е. как минимум — кушает ресурсы).
но по ресурсам это дешевле, чем если контейнер рестартуется
Ну так есть ещё health check с помощью которого можно явно проверять статус контейнера и переходить к запуску следующего.
Не работает. Точнее не так — это функционирует только в момент docker-compose up, если мы говорим про отдельные докер-хосты (пример). Либо в случае кубернетеса — там вообще отдельная и другая история.
Обычно же шибко вумные коллеги говорят, что если вам нужен порядок запуска контейнеров, то вы что-то делаете не так.
Многие веб-приложения, например, не запустятся, если в момент запуска недоступен SQL сервер или Redis, так как им для старта нужно прочитать какие-нибудь конфигурационные переменные из базы данных или еще откуда-нибудь.
Вариантов-то немного.
- обеспечивать отказоустойчивость базы (если в этом случае БД упала, то у вас проблемы посерьезнее того, что приклад "не алё")
- падать — рестартовать контейнер (может быть "дорого", если там в контейнере какой-нибудь jvm, который долго стартует)
- кидать exception, обрабатывать его и retry попытки доступа к БД.
К тому же, обычно бест пректис — выносить БД наружу, не держать ее на том же хосте, что и приложение-клиент (могу подробнее обосновать, если не очевидно почему).
А можете пояснить — чем принципиально на Ваш взгляд отличается wait-for.sh от try/except/retry в самом приложении?
несомненно. А еще, если мне память не изменяет, то докер не перестартует контейнер в failed state. Только если тащить внешние модули вроде https://hub.docker.com/r/willfarrell/autoheal/ или https://github.com/containrrr/watchtower (но последняя больше для авто-обновлений)
Минус уже поставили
Это хабр. :-(
Потому что в сворме. Я в первую очередь писал про standalone docker
вы еще не упомянули docker own registry. Который весьма криво работает с tls.
вы еще не упомянули docker own registry. Который весьма криво работает с tls.
криво, но я его никогда всерьез и не рассматривал как конечное, целевое решение. Нужен docker registry — либо используешь SaaS (docker hub, который постоянно взламывают, quay, облачные — в google, amazon, azure, яндекс, либо gitlab registry), либо разворачиваешь что-нибудь вроде JFrog Artifactory.
если база упала то может лучше остановиться и громко кричать о помощи.
Вообще-то я про это же и говорю. Что это зависит от конкретных требований и ситуации.
Мы живем в такую эпоху, кто первый тот срывает банк.
Кто успел захватить рынок или нишу будет иметь время и ресурсы потом довести продукт до ума или будет сметен очередной волной.
На данный момент со всеми костылями и недостатками Docker остается практически безальтернативным лидером в быстрой и удобной виртуализации как при разработке так и при развертывании решений в цепочках CI/CD и деплое.
Во всяком случае я не вижу серьезных конкурентов.
Рынок и время все расставит по местам.
Может не ленив, а рационален? :)
Нет, не так. Просто нужно ставить задачи, которые докер способен эффективно (как плане человеко-часов, так и в плане вычресурсов) решить. Я вот сейчас понятия не имею есть ли вообще докер на нодах нашего кластера, главное что он разворачивает образы с помощью докера построенные. Попробовал несколько других тулс для билдинга стандартных образов — уступают, как минимум в поддержке Dockerfiles.
посмотрите на podman
PS: для продакшн — рискованно брать недостаточно обкатанное решение. Специально сходил проверил первая альфа вышла чуть более года назад podman.io/releases/2018/06/04/podman-alpha-v0.6.1.html. Для боевых систем всегда выбирается стэк проверенный временем. Как я уже сказал в первом комменте, возможно со временем что-то вытеснит докер с его сегодняшних позиций. Podman выглфдит неплохо, но надо подождать когда первая волна энтузиастов его доведет до ума и докажет его превосходства и эффективность. Например, у меня нет времени на тестирование подобных альтернатив. Меня докер устраивает для моих небольших задач. И большая часть успеха кроется в огромном количестве доступной информации и примеров. Podman и поэтому я не уверен как скоро я начну (если вообще когда-нибудь начну) его использовать и/или тестировать. Се ля ви.
на самом деле в том же lxc можно делать абсолютно всё тоже самое
"Э — экосистема".
Можно "в том же lxc" на винде собрать образ, который залить в AWS SageMaker в качестве кастомного training algorithm?
т.к. сети в нем как будто захардкожены.
да github.com/docker/libnetwork/blob/master/ipamutils/utils.go#L10
Автор не в полной мере осознает масштаб проблем.
Однажды меня попросили "быстренько посмотреть один из серверов, туда что-то докер не встаёт. Надо поставить, и нужно через пару часов уже раскатать там микросервисный проект — ведь докер ровно для этого и сделан, чтобы легко разворачивать весь ворох сервисов с нуля".
На хосте оказался e2k
Эх, прочти я такое пару лет назад — избежал бы всех вышеописанных граблей Docker и сэкономил бы массу времени.
Действительно, интересный вопрос. Т.к. коллеги умудряются использовать кубернетес оставляя от него только по сути scheduler (сеть плоская как в букинге, поды прибиты руками к нодам, вся персистенция через host volume etc.). И оно даже как-то работает :-o :-o :-o Правда, ценность такого решения не очень понятна (разве что разработчикам удобно YAML писать....)
Потом розовые очки спали, я перестал пихать квадратный объект в круглое отверстие и осознал, что для моих крайне скромных задач хватает комбинации chroot, virtualbox и отдельно поднятых VPS, благо у многих хостеров есть для этого API и можно автоматизировать их создание и настройку. Docker по-прежнему использую, чтобы быстро что-нибудь проверить или воспользоваться какой-нибудь софтиной, не мусоря в системе, но в основном предпочитаю поднимать отдельные виртуальные машины. Кубернетес для меня — что микроскоп для забивания гвоздей, не те масштабы, поэтому более примитивных и устаревших средств хватает с избытком.
Очередная иллюстрация на темы
- "кубернетис не нужин" (с) (по крайней мере не для всех)
- "подбирайте инструменты по задачам" (не наоборот)
- "преждевременная оптимизация — зло"
Без издевки — очень понимаю, мои апплодисменты. Все правильно говорите.
Не всегда допустимо тащить оркестратор. Ну, например, зачем мне оркестратор, если есть один, два или три узла с докером?
Вообще я столкнулся с тем, что вся эта оркестрация именно в реализации кубернетеса достаточно жручая штука и оправдана либо на масштабе, либо если есть особые требования (например, отказоустойчивость, или разработчики хотят отлаживаться и писать YAML манифесты для обеспечения идентичности промышленной или разработческой сред)
Докер и LXC — это всего-лишь два инструмента, которые решают две разные задачи
Это сделано намеренно. Контейнеры в linux в т.ч. и LXC, имеют ряд проблем или особенностей (называйте как хотите). Основная причина в том, что если вы убиваете родительский процесс в контейнере, это не означает, что все дочерние процессы завершились правильно, некоторые из них могут продолжать использовать сетевые интерфейсы и блокировать хранилище, в итоге мы имеем повисший в непонятном состоянии контейнер.
Подход "по процессу на контейнер" позволяет избежать данной проблемы и получить всегда гарантированное состояние. Кроме того это позволяет container engine сделить за каждым процессом отдельно, автоматически собирать логи и метрики с него.
Подход "по процессу на контейнер" позволяет избежать данной проблемы и получить всегда гарантированное состояние. Кроме того это позволяет container engine сделить за каждым процессом отдельно, автоматически собирать логи и метрики с него.
Зачастую это не работает. Приходится мириться с тем, что процесс внутри контейнера форкается и плодит потомков. Еще хуже — если там разнородные процессы под управлением супервизора. В результате — типовая проблема, что появляются процессы-зомбяки. Решается вроде как засовыванием init в контейнер. Но это костыль. Очередной. Впрочем, неудивительно.
Ну, "окончательного решения init вопроса" разработчики не придумали. Есть какие-то разрозненные практики. Начиная от запихивания supervisor (фу), кончая появлением специального --init ключа у docker run.
Да. Еще стоит упомянуть, что коллеги умудрялись с матами и приседаниями запускать полноценный systemd в докере, но вряд ли оно того стоит. Преимущество такого подхода очевидно — ты просто пишешь свой приклад, пишешь юнит файл и оно вместе работает везде — что на выделенной ВМ, что в докере.
В итоге на основную идею докера один контейнер, одно приложение положен большой болт.
Так что, выдумки все это.
Вот и всё.
Авторам nginx это объясните, например :)
Но, имхо fork вместо нитки — само по себе костыль.
Сысоев только недавно научил свой nginx правильно определять количество ядер, доступных в це-группе.
https://github.com/kubernetes/ingress-nginx/issues/2948
и корневая причина:
https://trac.nginx.org/nginx/ticket/1151
Официальные образы nginx они сами предоставляют.
Ну т.е. есть унифицированный способ деплоить сетевые приложения без загаживания хостовой системы. Отлично.
Ограничение проистекает из необходимости корректно определять состояние контейнера по состоянию порожденного в нем корневого процесса.
И это вполне разумное ограничение — контейнер под задачу. умерла — убить/перезапустить в соответствии с полиси.
А если вам в контейнере нужен init — вы что-то делаете не так.
Как-то топят за него больше разработчики, чем эксплуатационщики. Унифицированній способ разворачивать сетевые приложения без загаживания своей машины :)
Обычный пример: php-fpm+nginx, которые должны шарить public директорию и второй без первого просто не имеет смысл (по крайней мере в рамках конкретной системы даже для локальной разработки или отладки), неотделим от него.
"Обычный контейнер с init системой" включает в себя tty, ssh-сервер, что-то для управления сетью, что-то для сбора логов...
А тут всего две программы запускаются, помимо самой init системы.
А тут всего две программы запускаются, помимо самой init системы.
И? Идея докера берем приложение берем окружение запускаем. Когда вот такое как у вас то там нужно настроить супервизор или написать bash скрипт которые это все будут запускать. И да придется добавить логгирование, так-как в стандартный поток может писать только одна программа.
Обычный пример: 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'а, простите меня за данное допущение.
Проблема в настройке взаимодействия этих самых контейнеров.
Простой контейнер можно при желании запросто запустить в нескольких экземплярах. А вот для двух зависимых контейнеров эти самые зависимости придётся настраивать.
Если честно не знаю как это организованно в docker, но в Kubernetes есть специальная абстракция — Pod, можно сказать это наименьшая единица для запуска workload в кластере. Описать два разных контейнера в одном Pod'е не составляет никакого труда (это всего несколько строк в одном yaml-файле).
Да, работа с Kubernetes ломает привычные принципы и требует определённого уровня сноровки, но научившись "правильно" работать с контейнерами, поверьте, многое становится проще и понятнее.
Ну, значит в Kubernetes эту проблему решили.
Но не будете же вы ставить Kubernetes каждому разработчику? Значит, для разработки нужен отдельный контейнер, с как можно более простым запуском.
Описать два разных контейнера в одном Pod'е не составляет никакого труда (это всего несколько строк в одном yaml-файле)
Лписать не проблема, проблема чтобы это описание заставило их корректно работать.
Если верить Гуглу и Гитхабу, то второй гораздо популярнее для k8s. Относительно недавно вроде появился вариант монтировать volume на ingress-nginx 0.25.1, "пхп" трафик стандартно отправлять прямо на fpm, а статику с помощью сниппетов докрутить на том, в которій вторім способом скопировать. Естественно том кластерній должен быть. Вроде костыль большой, но возможность запускать fpm голым подкупает
https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#decouple-applications
Limiting each container to one process is a good rule of thumb, but it is not a hard and fast rule.
Всё же написано.
Да. Еще стоит упомянуть, что коллеги умудрялись с матами и приседаниями запускать полноценный systemd в докере, но вряд ли оно того стоит. Преимущество такого подхода очевидно — ты просто пишешь свой приклад, пишешь юнит файл и оно вместе работает везде — что на выделенной ВМ, что в докере.Кстати, полноценный systemd в podman можно запустить без матов и без приседаний — это штатная возможность: How to run systemd in a container
процесс внутри контейнера форкается и плодит потомков
Это не должно быть проблемой, так как в данном случае процесс который форкается как правило без проблем отрабатывает SIGTERM и мочит всех своих потомков.
Кстати, это один из пунктов 12factor app.
Ну в Kubernetes эта идея вполне живёт и процветает.
Каждый pod может состоять из нескольких контейнеров работающих в одном сетевом пространстве. Внутри каждого такого контейнера работает отдельный процесс и пишет логи в обычный /dev/stdout и /dev/stderr.
Каждый такой контейнер может быть запущен из отдельного docker image, логи можно посмотреть из любого места: kubectl logs myapp -c nginx.
Это может быть по началу непривычно, но на мой взгляд, очень удобно.
Единственный плюс тут только наличие интерфейса и упаковки вашего приложения в докер. Но только в случае если ваше приложение нормально туда пакуется.
Классический пример nginx + uwsgi сервис
Ну для этого в общем то и придумали оркестраторы.
Опять же его классическое решение это два контейнера, один с nginx, второй с приложением и все это завернуто в единый pod (если в терминах K8s).
При том, что скорее всего nginx-ов там надо меньше чем приложений и их вполне можно разделить и управлять ими отдельно (если позволяют условия задачи).
Бонусом получается целостная система управления, переносимость, скейлинг там всякий, раскатка апдейтов и т.п.
Если все это не нужно, то речь скорее всего о маленькой задачке, которую можно кроме docker\lxc решить еще кучей способов на любой вкус и городить тут оркестратор нет смысла, да и контейнеры вероятно тоже. Правда такие задачки попадаются крайне редко (в моей практике) и обычно уже есть оркестратор для чего-то более серьезного.
Не знаю насчёт uwsgi на 100%, но близкий к ней fastcgi скорее предполагает один nginx (мастер) процесс на один же master fcgi (если опустить скейлинг). Плюс очень часто шаринг дисковых ресурсов, включая те, которые в образ положить нельзя в принципе. И управлять ими надо чаще всего синхронно в плане запуска и конфигурирования. В кубике придумали ещё один уровень абстракции — поды, как бы эмулирующие физическую машину с абстрактным init. Но называть это классическим решением как-то язык не поднимается, классическое исключительно в рамках k8s
Я так понимаю, что Docker под виндовс испытал несколько итераций. И я уже попросту потерялся в них.
Касательно Hyper-V есть неприятный нюанс, что вроде как Docker for Windows несовместим с другими средствами виртуализации — вроде VirtualBox или vmware.
вроде как Docker for Windows несовместим с другими средствами
Да. Докер, винда, виртуалбокс — выберите любые два. Все три одновременно запустить не выйдет.
P.S. Я в курсе про существование Docker Toolbox. Оно а) объявлено устаревшим/неподдерживаемым б) в некоторых моментах ведёт себя несовместимым с Docker Desktop образом.
docs.oracle.com/cd/E97728_01/F12469/html/hyperv-support.html
Дело не в докере, а в Hyper-V, он действительно был не совместим с другими системами виртуализации, так как монополизировал доступ к аппаратным расширениям процессора, но есть пара но:
- Какой вообще смысл использовать дырявый и тормозной VirtualBox, когда MS бесплатно дает возможность использовать enterprise-level Hyper-V? (При этом давно есть возможность в VB включить тип виртуализации Hyper-V)
- В свежих версиях Windows появился слой абстракции — Virtual Machine Platform, позволяющий использовать виртуализацию для контейнеров, при этом не включая Hyper-V и не блокируя другие гипервизоры. Если я правильно понимаю, поддержка этой платформы другими гипервизорами уберет все конфликты.
enterprise-level Hyper-V
Я бы поспорил насчет enterprise level. Типичный кейс с 2012 сервером. Используем его в качестве ноды виртуализации. Пускай, на нем 16ГиБ ОЗУ. Забиваем его виртуалками на 14ГиБ (остается 2ГиБ под систему). Работаем так месяц. Потом возникает необходимость выключить одну из ВМ. Пытаемся запустить — нет памяти. WTF!? Изначально ведь памяти хватало. Берем и психуем — ребутаем вообще всю ноду виртуализации. Все виртуалки опять на свежеперезагруженной ноде запускаются на ура. Поясню, что я никогда не использовал динамическое выделение памяти под ВМ — только руками прибивал объем. Получается, вЕнда течет? Вот тебе и продакшен реди.
Я уж не говорю про особенности перевода в русскоязычной версии, когда внезапно VLAN становится адаптером беспроводной сети (WAT???)
Почему течёт? Набивает кеши как и любая другая ос.
У операционной системы подход простой: видишь пустую память — забей её кешами, что логично для всех сценариев — дабы пользователю запускать приложения быстрее и не читать их с диска, кроме того случая, что пользователь жук пытается выжать последние крохи из и без того пустого пула.
По-поводу венды 2012 для виртуализации ну тоже сомнительно, есть же бесплатный безгуевый Hyper-V Server который построен на Core версии и не стоит денег совсем. Свежий, бесплатный, Core (читай даже без гуи и требований к ресурсам), что еще нужно?
Что касается не венды, попробуйте забить память на линуксе и там не то, что все остальное продолжит работать, там всё встанет на пол часа пока ООМ-киллео не сможет наконец пробраться повыше: https://www.opennet.ru/opennews/art.shtml?num=51231
На всякий случай поясню.
- это не кэши. Т.к. есть вполне понятные методики для их сброса. И они не помогали. Это раз. Два — в любой нормально операционке кэш сбрасывается, когда есть запрос на ОЗУ. Три — это сервер. Там другая профиль нагрузки. Не быстрее запускать foreground приложения, а обеспечивать стабильную работу сервисов.
- Насчет Core — тогда еще его не было. Это раз. Два — чем 2012 плох для виртуализации? Три — чем конкретно поможет Core, если Вы сами говорите, что дело в кэше? Ну, и добавлю, что Hyper-V server достаточно специфическая штука и одмины, умеющие только в ГУЙ, его не осилят (ага, запусти оснастку на другом сервере и подцепись к Hyper-V Server — тот еще квест).
Короче, аргументы какие-то сомнительные. Прям совсем. А я рассказал о вполне конкретном кейсе.
Что касается не венды, попробуйте забить память на линуксе и там не то, что все остальное продолжит работать, там всё встанет на пол часа пока ООМ-киллео не сможет наконец пробраться повыше
overcommit и своп настраивать не нужно, да? Мы же все знаем, что дефолтные настройки практически везде никакого отношения к реальной работе не имеют (и на это есть масса причин).
echo 3|sudo tee /proc/sys/vm/drop_caches, так что даже в тяжёлых случаях не произойдёт ничего особо страшного. Ну и «SysRq» интерфейс помогает принудительно призвать OOM Killer, даже по SSH.
И в чем противоречие?
Идея контейнеров — использовать ядро хоста, если вы пускаете на венде линуксовые программы то каким образом они будут использовать вендовое ядро хоста?
Нативные контейнеры только для приложений под Windows, тогда и контейнеры будут легкие, нативные и на хостовом ядре.
До сих пор не научился нативно не в linux-kind операционных системах.
И при этом только для линуксов не заимплеменчен резолвинг host.docker.internal. Мой личный pet hate.
www.smashcompany.com/technology/docker-is-a-dangerous-gamble-which-we-will-regret
основная — независимость от окружения другого софта и простой юзерспейс.
На самом деле нет. Если самому собирать пакеты и устанавливать их в стандартное место (например, /opt/), то никаких проблем вычистить старые версии софта нет.
А докер, на минуточку, создаёт проблему очистки неиспользуемых образов. Т.е. действительно хост-система не загадывается ошметками софта в контейнерах, но политику очистки образов все равно нужно продумывать. Проблема особо актуальна для docker registry, которые содержат мастер-образа для разливки софта на целевые машины
docker system prune -a?
Для задачи удаления старой версии софта докер делает слишком много. Достаточно вменяемого пакетного менеджера. А ещё лучше если софт просто лежит в одной папке, а не размазывается по файловой системе ровным слоем.
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 — паковка в контейнер докера выглядит избыточной.
Утверждение «не все есть гвоздь, когда в руках молоток» — считаю хорошим уровнем освоения «молотка» как инструмента.
Хотя бы отчасти — да.
- Не нужно тащить демона докера — следовательно — нет лишней абстракции и проблем типа "демон упал и утащил за собой все контейнеры"
- Решена проблема с безопасностью. Можно каждому юзеру показывать только его контейнеры. Да, кэш образов у каждого юзера свой. В этом есть свои плюсы и минусы.
- Более нативная интеграция с остальной системой — с тем же systemd.
Мы пока с коллегами присматриваемся в рамках профильных телеграм чатов. Пока нюансов много всплывает. Та же сборка через buildah — неидеальна. Мягко говоря
Многие пункты это не хейт, а скорее здравый смысл :)
Безопасность, правда, никто и не обещал – от докера нужна лишь изоляция между приложениями.
А контейнеры без оркестрации в продакшене это воистину мазохизм. Если у вас один хост на хецтнере и полтора сервиса с SLO 50% – ничего не мешает катить ансиблом, а запускать системд, сам так вполне успешно делал. Докер лишь кирпичик в инфраструктуре, а не серебряная пуля, и вроде бы хайп давно прошёл (сейчас как раз по кубернетису угорают, но и он в эксплуатации сложен, пусть и крут).
- без глубокого знания докера — эффективно пользоваться кубернетесом не получится. Т.к. сейчас все нынешние дистрибутивы k8s основаны на докере
- В силу п.1, безопасность докера = безопасность кубернетеса. Рваться будет по самому слабому звену. Что и наблюдаем.
- на роль оркестрации подходит puppet/salt/chef. Как бы и раньше как-то оркестрировали и ничего. ОК. Сейчас еще есть Nomad и Mesos. К сожалению, они на порядок менее популярные, чем куберенетес. Но жизнь в них теплится.
- касательно угара по докеру и кубернетесу — это то, что если власть в психбольнице получают психи. То бишь разработчики. Им удобно. А то что необходимо правильно написать софт, чтобы запихать его в кубернетес, они не понимайт или не осиливают. В кубернетесе действительно много классного (если не заглядывать в его код ))) и он реально облегчае некоторые моменты разработки. Но дисциплина разработки должна быть на уровне… иначе — хаос.
Лично мне докер и в разработке выносит всю психику своими перманентными препонами. Терпеть его не могу, хотя в некоторых случаях, он бывает удобен только для скорости разворачивания прототипа на демонстрационном показе.
А кто её должен выполнять, если девопса в штате нет? Или он один на несколько десятков разработчиков? И если не каждый день новый сервис, то новая зависимость? И вообще чем работа девос отличается от работы админа продакшен-сервера?
Ещё раз. Я не говорю, что докер — плохо. Я говорю, что докер в продакшене скорее всего признак лени и пофигизма, что влечёт за собой хаос, падение производительности, а при усложнении системы, постоянные проблемы.
А причём тут лень? Поднимать инфраструктуру для докера с нуля довольно утомительно для программиста, имхо. С другой стороны, часто именно с докеризации начинается нормальная автоматизация деплоев и вот это вот всё — с докером уже rsync c дев машины не запустишь.
Знавал я таких "девопсов": "у себя в разработке делайте что хотите, а на прод мои пайплайны будут выкатывать как мне надо", а потом не может ни сам пофиксить что-то, ни предоставить информацию для локализации и фикса, ни внятно запросить информацию нужную ему. А следить за хоть как-то, но работающими докерфайлами, где, например, все нужные зависимости перечислены, отказывается — требует отдельный список всех пакетов для него вести, причём для какой-нибудь CentOS, которую никто из разрабов в глаза не видел.
1 ещё актуально? )
Из таких интересных пересечений по именам — minio. Клиент к этому s3 хранилищу внезапно называется mc. Прям как всем известный mc (midnignt commander).
Еще я видел алиас mc на meteor create.
Чем люди думают, когда так делают, для меня неведомо
да это же просто гошный бинарь, обзывайте как хотите:
# mv ./mc mcliи проблема решена
да несомненно. Я сделаю. Только почему разрабы заранее это не предусмотрели?
Опен-сурс такой опен-сурс.
Я думаю предусмотрели, они просто #противсистемы
Мало букв в алфавите, что делать :)
Network host mode убивает одну из главных возможностей докера для разработки: запуск кучи приложений на "одном" порту без вмешательства в код/конфиги приложения.
Контейнеры для компилируемых языков имеют право на жизнь тоже:
- нет необходимости ставить билд окружения на локальную машину
- инкапсуляция: вот на днях переписал один сервис с PHP на. Go. Кроме git репозитории исходников и Dockerfile этого сервиса никаких изменений не потребовалось в системе. Есть образ, есть его API (тут в совокупности и API приложения и соглашения докера, близкие к 12f) и на чём он написан не волнует "никого" кроме интерпретатора Dockerfile. Да, есть другие способы добиться подобного, но Докер, имхо, предлагает самый простой, удобный и универсальный на сегодняшний день. Реальная альтернатива, по-моему, сейчас только сборка apt/rpm/… пакетов (порог входа низким точно не назовёшь, есть подозрение, что универсальной тулзы просто нет, нужно разбираться с каждым языком, фреймворком, транслятором, возможно дистром ОС, systemd и т. д. и т. п. ). Плюс какой-то ansible освоить чтобы с багем поменьше дела иметь, плюс придумать свою систему оркестрации "виртуальными" "машинами" и "сетями" если не для изоляции, то хоть для совместного использования ресурсов типа портов.
Почему не рассматриваете подготовку образов операционной системы со всем необходимым? AMI — в терминологии Амазона. Прекрасно осуществляется Packer'ом от HashiCorp
Ах, да, извините, забыл, что у Вас мощностей-то и нет… 1.5 сервера, как я понял, из нижних постов и все. Тогда да — там особо не развернешься.
Было для VMware. Докер удобнее оказался. Вернее удобным оказался запуск докера в VMware машинах.
А если не секрет — операционную систему внутри виртуалки какую используете?
Я бы рекомендовал смотреть в сторону облегченных дистрибутивов вроде coreos / photonos
Действительно — они атомарно обновляются, содержат минимальный набор драйверов (т.к. "железо" в виртуалках стандартизировано), следовательно, идеально подходят под запуск контейнеров.
Дополнительно никак не могу не отметить наличие инструментария вроде fpm, который радикально снижает порог входа в сборку своих пакетов, нативных для конкретного дистрибутива.
Я тоже недолюбливаю докер, хотя, начал использовать его до того, как это стало мейнстримом.
И мои мысли о тех преимуществах, про которые рассказывают следующие:
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 и т.п. сервисы отдельные серваки жирно. А сопровождать их все на одном физическом хосте муторно. Распиливание их по контейнерам приводило к существенному упрощению администрирования.
они начинают больше копипастить со stackoverflow в стиле
apt-get install 200 пакетов которые я хз зачемили
chmod 777 -R /usr # потому что без этого, почему-то не работаетИ мой любимчик:
chown 775 /home/appИ раскажите, чем преступен chown 775 /home/app в пределах докера, который не запускается под рутом? И не имеет смонтированых шаред волюмов с хоста на запись.
Если мы выделяем devops в отдельного человека, то мы вместо слома барьеров — создаем новые (девы перекидывают код девопсу, а он перекидывает дальше на админов). Более неверного толкования я в принципе не видел.
Я понимаю, что pure devops — идёт дальше вплоть до деплоймента в лайв самими разработчиками. Но не везде это возможно.
настраивает CI/CD
это билд инженер или релиз инженер, а не девопс.
Девопс один раз собирает «правильный» докер/под из проекта
В зависимости от темпов разработки и скорости внеения изменений — правильного может и не быть (хотя в каждый момент времени мы можем к этому стремиться).
говорит «далее уже ваша проблема как доставить мне стабильный докер для лайва»
Там еще бездна того, что нужно сделать. Логирование, мониторинг, пр. пр. пр.
Тут ключевое, что бы девопс понимал как работу девелоперов, так и эксплуатацию, тем самым определяя требования к софту.
Опять выделяете это в отдельного человека. :-( На самом деле вопрос что такое DevOps и является ли DevOps каким-то человеком — очень холиварный.
Тут ключевое, что бы девопс понимал как работу девелоперов, так и эксплуатацию, тем самым определяя требования к софту.
Понимать недостаточно. Нужна коллаборация, обмен опытом и лучшими практиками и работа на общий конечный результат.
Но не везде это возможно.
очень интересно посмотреть, как бы это работало в жестко зарегламентированной сфере. Вроде банков, государственных предприятий, транспорта.
Извините, но Вы же не отрицаете необходимость специалистов по DBA, сетевых инженеров и пр.? Просто иначе мы имеем очень интересных кадавров в инфраструктуре.
Будущее за Т-shaped persons. Это те, которые имеют какую-то глубокую специализацию. А еще имеют широкий кругозор. Если что — переквалифицироваться такому специалисту будет не очень сложно.
Как будто уже выработаны нормальные практики деплоя в 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 добавили возможность эту хрень закрыть, а в "десятке" вернули что-то похожее на нормальный "Пуск" (по крайней мере, кнопка выключения снова на месте).
Грубо, 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. Но если у вас кластер эластика на 15 машин — считайте это за 1.
>унифицированные интерфейсы конфигурирования
нет. Переменные окружения? У всех всё по-разному, а некоторые аппы, пока файл не положишь — не заработают. Либо приложение можно удобно конфигурировать, либо нет. Докер тут никак не помогает. И если завтра дедлайн, а конфигурить через файл — будешь монтировать файл.
>Не зависит особо от докера
О том и моя мысль, что плюсы, которые приписывают докеру, вовсе не его
> Да, можно понаписать башскриптов
Не так. «нужно понаписать пачку башскриптов». Entrypoint более-менее непростого контейнера видели? Init перед entrypoint-ом и прочее весёлости. там много скриптов получается. Благо, это не всегда плохо.
> Грубо, 49 запущенных на хосте nginx слушают порт 8080 и только один слушает 80
Это тоже не про докер.
Ну так и софт надо писать с пониманием, что он будет запускаться в контейнере. Хотя бы конфиг из 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 — т.к. были свои патчи и нужно было ставить неколько версий в параллель. Были и свои внутренние разработки, которые тоже были опакечены ради более легкой установки.
Ну, здесь понадобилось два человека — раз.
Два — если считалка сама умела параллелиться и как-то в распределенное режиме получать input, а потом давать результат, то неясно чем там докер поможет.
Легко (относительно) можно было запаковать все в AMI и поднять нужноеколичество инстансов EC2. Естественно, что без полного обследованич кода ничего нельзя сказать наверняка.
Возможно вся фишка была в оркестраторе типа Мезоса, но он тоже из однопоточного приложения, которое не умеет в несколько реплик, cloud-native конфетку не сделает.
В любом случае, спасибо за отзыв — очень интересный опыт описали. Т.с. взгляд со стороны.
И еще вопросик — во сколько вам это обошлось?
Порой счета от амазона бьют по карману.
2) WebAssembly создавался для браузеров(слово web названии какбы намекает) для пропуска этапа парсинга и оптимизации js кода, а также для поддержки других языков программирования. Производительность не была главной целью, даже многопоточность недавно завезли. В общем, такой код сильно уступает в производительности нативной реализации.
3) Wasi совершенно не готов. До сих пор идут обсуждения основного api. Сборка возможна только для сишного кода и скоро можно будет на расте.
Т.е. для серверов wasm не готов. И вряд ли будет в ближайшем будущем.
На мой взгляд, Wasi — это попытка создать эдакий jvm для раста и ещё парочки яп. Т.е. кроссплатформенность — один раз собрать для кучи платформ. Но как показывает java, такое не особо работает. В теории можно, но как только проект вырастает больше hello world'a начинают появлятся платформоспецифичные хаки. Или использование приложения удобно только под Windows, под Linux тоже можно запустить, но выглядит слишком инордно и вызывает дискомфорт.
Как будто проблемы разработчиков никто не должен решать (вот та же история с перекрытием сетей — думаете, что она не пьет кровь девам?). А они зачастую не в состоянии это сделать, т.к. у них фокус не на админстве.
CI и пр. Production ready это k8s (или его «мини» версии, типа mikrocube или k3s)
Повторюсь, что не всегда и не везде кубернетес нужен. Есть куча компаний, которые с радостью его "продадут" вам как клиенту, т.к. это является основой их бизнеса.
За упоминание k3s — жирный плюсик. Спасибо
K8s и сети — это одна сплошная проблема. Начиная от вопросов выбора — какой cni мы хотим. И как мы хотим его настроить.
К тому же, я больше говорил про проблемы разработчиков с докером на их машинах. Согласитесь — вряд ли разработчики будут тащить полноценный кубернетес к себе на ноутбук или рабочую станцию (разве что в урезанном виде а-ля minikube или k3s).
По поводу того, что лучший кубернетес — тот, который ты не хостишь, т.е. в идеале — managed от Гугла — полностью согласен.
Единственное, что действительно похоже (некоторые коллеги озвучивали такое мнение), что сложность k8s именно что избыточна и создана специально, чтобы все переезжали в облако к Гуглу. Почему мы уверены, что это так — потому что есть оркестраторы намного проще (вроде связки nomad + consul).
Отвратительная документация.
Как думаете — это сделано умышленно? Или само так получилось? Дело в том, что есть сертификация по docker. Получается можно заплатить денег и вас ему научат :-o :-o :-o А раз так, то с капиталистической точки зрения нужно делать продукт достаточно хорошим, но не более. Чтобы новички быстро в него въезжали (цель достигнута), а профессионалы могли рубить капусту (вроде как тоже).
На самом деле есть вполне бесплатный Katacoda — для любителей сразу потрогать ручками
Главное не ставьте Docker под Ubuntu через snap — словите непонятных багов, честно, сами встречали такое.
https://t.me/ru_docker
https://t.me/docker_ru
https://t.me/kubernetes_ru
Но там скучно прям — одни и те же вопросы изо дня в день
И после парочки итераций я пришел к докеру.
Почему? Потому что мне хочется единообразного цикла доставки и управления помянутыми проксями и впнами на различных хостах для различных пользователей.
У меня есть 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.
держать в голове подробности не хочется, а кубернетес для моих целей слишком монструозен
Не смотрели в сторону Nomad?
По-крайней мере там где я работал раньше крутилось 30 инстансов в AWS и я не трогал их по пол года и больше. И были среди них два микросервисных докера напиханные bash-костылями. А для стабильной работы контейнеры каждую ночь пересобирались.
Конечно в подходе «сломалось — выкинь и сделай новое» тоже есть рациональное зерно. Но ИМХО поднять простецкий LAMP в виртуалбоксе гораздо быстрее и удобнее чем ковыряться с докером в девелопе. Хотя второй создан как раз для быстрого развертывания среды.
Конечно у меня нет опыта работы в проектах с сотнями и тысячами серверов, там правила и условия, но и докер частенько используется в проектах с общим количеством машин не больше 10.
На той же vmware можно построить гораздо более стабильную и отказоустойчивую систему нежели модный кубернетес, который поверху тех же виртуальных серверов и ставится, которые абсолютно так же падают.
И из-за этого действительно бомбит, потому что когда приходишь на собеседование и тебя начинают гонять по «брендовым» словечкам аля контейнеры, кубернетес, эластиксерч, флуентд, а ты им говоришь, ребята, у меня тут пару серверов было, я набросал пару скриптов на баше, накинул забикс и все это нормально работало, то на тебя смотрят как на идиота, который не постиг ит-дзена и ничего не умеет.
ого что в репозиториях что-то изменилось
Во первых форкаем чужие докера к себе, во вторых не используем :latest. Неумение готовить — проблема обучения, а не инструмента.
Виртуалки не заменяют докера, как и докера не заменяют виртуалки. Эти 2 технологии хорошо дополняют достоинства друг друга.
Под репозиторием я имел ввиду не только репозитории докера. В овер 90% docker-compose файлов установка nginxов и mysqlей идет на лету во время билда. Это вполне готовые семплы или рабочие контейнеры, которые даже на гитхабе много звезд имеют.
Делов-то, форкнуть epel репозиторий.
Виртуальный сервер из образа с каким-нибудь ansibleом можно развернуть также автоматически как и контейнер.
Из неоспоримых плюсов можно назвать только скорость непосредственного билда и лёгкость контейнера.
Правда, когда говорят о производительности контейнеров, почему-то сравнивают 5 физических машин, по сервису на каждую, против 5 контейнеров. А если все эти сервисы положить на один хост, то получится гораздо более производительная система, чем с 5 раздельными контейнерами.
Потом говорят про то что контейнеры легко удалять и создавать, так это потому что они без падений дольше месяца не работают, за ними постоянно нужно следить.
Чтобы работать с контейнерами нужны более квалифицированные и админы и программисты, чем при работе с виртуальными серверами. И это факт, доказательством которому может служить повсеместный виртуалбокс, который как игрушку ставят. Как можно упрощать инфраструктуру усложняя её?
Когда ковырялся с кубернетес, он мне на лопатки два ноутбука с 4мя виртуальными машинами клал при запуске "hello world" на nginx кластере из 2х контейнеров. По старинке на LAMP на этих буках можно онлайн магазин с тысячами просмотров в день развернуть и еще ресурсы останутся.
Контейнеризацию выгодно продвигать только облачным провайдерам, потому что легко и быстро перебрасывать и перераспределять свободные ресурсы и, соответсвенно, перепродавать. Чем они и занимаются.
В общем я пока что до этого либо не дорос, либо наоборот, консервативный старпёр.
Отказоустойчивый кубер — да, но толку от него, если приложение не соответствует лучшим практикам написания для cloud native среды
Кубер — не магическая палочка или серебряная пуля, которая автомагически решит проблемы бизнеса
Несомненно — кубер даёт новые возможности. Например, экономию денег на спот инстансах (появляется возможность использовать их, а не обычные вм). Возможность проводить хаос инжиниринг. И пр. Но какой ценой?
Простой пример — коллеги разрабатывают сайт для небольшой компании. Нагрузку сайта (стандартно — БД + nginx + php-fpm) прекрасно держит одна VPS. Ну, ок — хотим немного отказоустойчивости — cloudflare + второй инстанс. Они пробовали разрабатывать на кубернетесе — не зашло. Слишком сложно и дорого (брали GKE, причем я не участвовал в выборе, конфигурировании среды).
Второе. Кубернетес выдвигает определенные требования к приложениям. Определенный способ упаковки, декомпозиция по контейнерам, эндпойнты для healthcheck/readiness и многое другое. В целом, это все не очень плохо, тем более, когда смотрим на далекую перспективу. Но для какой-то простой штуки (не знаю, прототип телеграм бота, например) все это может оказаться излишним, а, следовательно, на начальных стадиях внести оверпрайс в разработку.
Условно — отказоустойчивый сервис по обработке данных я и без k8s на консуле (etcd/zookeeper) + питоне на трех нодах запущу. И это будет проще и дешевле.
То, что товарищи не смогли разбить по сервисам в докере очень странно. Я думаю по первым трем результатам в гугле можно найти примеры на БД + nginx + php-fpm.
Откуда такой вывод, что ребята не осилили декомпозицию? Я такого не писал.
Но в конце концов решает бизнес — насколько надо отказоустойчивость и скейлинг приложению.
Именно так.
Если писать приложение правильно с самого начала, используя контейнеры, то проблем быть не должно. Если это перевод существующего монолита, то это конечно много дополнительной работы. Многие на этом и зарабатывают, помогая перейти на контейнеры.
Вы же наверняка слышали рекомендации, что не стоит начинать с микросервисов, т.к. зачастую получается самая ужасная вещь — распределенный монолит. А лучше начать — с монолита, который решает какую-то задачу, а потом начать его потихонечку распиливать на микросервисы. По-моему, так даже великий Фаулер завещал.
- не умеет средний разработчик в декомпозицию. Если он родит не монолит, то родит "100500 контейнеров под каждый метод — та же статья", как выше пишет usego
- web'ом задачи не ограничиваются. Есть хадупы, (потоковая) обработка данных, телефония и много чего еще интересного.
Для простого сайта без резервировнаия/масштабирования k8s сожрёт слишком много человеко часов. docker-compose вполне справится, сочетая плюсы контейнеризации с отсутствием минусов конфигурирования огромной системы оркестрации.
ansible прекрасно заменяет docker-compose.
Единственное, чего не умеет ansible — это тушить контейнеры по лейблам, но решить это запросом к docker api и фильтром json не проблема.
Может и справится, но чем он лучше будет в этом качестве? И можно ли с ним делать такие вещи как docker-compose logs --follow?
Это возможность для отладки того, что оркестратор развернул.
У нас немного разные представления об оркестраторе. Мне вот 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 .., если очень хочется. Выгода компоуза тут преувеличена.
Ещё интересный момент, что уже появилось поколение людей, которые знают компоуз, разбираются в его ключах запуска, директивах, но абсолютно беспомощны перед лицом "голого" докер-клиента. Занятно, не так ли?
Серьёзно. И да, предпочитаю запускать docker-compose up -d, Как я понимаю природу ansible он плохо справится как с docker-compose up, так и с docker-compose logs --follow
docker logs очень неудобен когда хочется иметь агрегированный лог
docker-compose up (без -d) не делает exit/return после поднятия контейнера, ansible не рассчитан (могу ошибаться) на такой режим.
А наличие отладочных функций очень упрощает отладку многопроцессных приложений.
Ошибаетесь.
Ансибл прекрасно работает в режиме "наплодил контейнеров и ушел с сервера".
Вот возьмите и попробуйте наконец-то. Чего обсуждать?
Или боитесь, что вдруг понравится?
Мы пришли к ансиблу по следующим соображениям:
- Зачастую недостаточно сделать docker-compose up -d
А нужно сделать ещё кучу действий, чтобы запустить контейнер (мы не про микросервисную архитектуру, а скорее про использование докера как такого пакетноно менеджера) - Зачем на удаленной машине лишний компонент в виде docker-compose? Ну, и если локально на удаленной машине делать docker-compose up, то, как выше уже заметили — у вас уже две проблемы: запуск контейнеров и доставка описания контейнеров в виде docker-compose.yaml на эту удалённую машину
- В теории compose умеет цепляться к удалённому демону. Но это костыли и риски ИБ: кто его знает как там написан docker демон.
- Отсутствие шаблонизации в 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с в тестовом режиме приложение из пары десятков сервисов, разрулить волумы и ингрессы не так уж и просто. Это понимая как работает докер и имея большой опыт аналогичных задач на кластерах конкурента.
А с :latest отдельная история была, когда на сервере два года gitlab крутился созданный из latest, а после переустановки хостовой ос на более новую (а вместе с ней и докера и докер-композа, а про совместимость в статье уже было написано), пришлось создавать новый контейнер. Вот тогда пришлось знатно поснашаться, чтобы узнать что же за latest версия была два года назад и потом узнать что в репозитории, оказывается, самой старой версии всего пол года. А все что до этого сожжено в адском пламени.
Да, конечно, это не прямой косяк докера, косяк докера в том, что пока на эти, и многие другие, грабли не наступишь — ничего дурного не заподозришь.
Могу посочувствовать. Чтобы не попадать в такую историю достаточно сохранять id образа и сам образ (т.к. спустя столь продолжительное время его могут попросту удалить). Есть ещё подход — бежать так же быстро, как и окружающие, и своевременно обновляться, но это прям очень ресурсоемко.
В любом случае, признаю — я тоже задним умом силен, а не передним, но катастрофы проще предотвращать, чем ликвидировать последствия.
Да, хотел привести пример github'а, который тоже превратился в помойку.
Но на самом деле есть разница. Docker Hub мог бы модерироваться Docker Inc по примеру магазинов приложений (Apple Store, Google Play) или репозиториев ПО (любой серьезный репозиторий любого серьезного дистрибутива). Но нет. В docker hub даже не всегда можно понять ИЗ ЧЕГО получен образ и какова его история изменения. А в гитхабе никто ничего не гарантирует. Вообще.
В dockerhub есть официальные образы, от компаний или сообществ — типа PostgreSQL, Apache т.д. Если нужно что-то официальное, то это к ним.
тем не менее — даже официальные образы имеют определенные родовые болячки и требуют доработки напильником. Например, самое очевидное — разброд в том, каким образом передавать настройки приложения. Какие-то образа ждут переменных окружения, какие-то — файла конфигурации. Другой вопрос, что да — докерхаб позволяет взять готовый образ и протестировать какую-то гипотезу быстро. Относительно быстро, учитывая время необходимое для того, чтобы разобраться как с конкретным образом работать. Но в production это пускать… Такое себе. А собирать все образы под себя — просто умрешь от объема работы.
то всё это в докера переводится на раз два
Нет. Нужно учитывать специфику докера. volume, init, права пользователей, отсутствие systemd и пр. пр. Поэтому — не раз-два.
Так докер не про микросервисы, а контейнеры. Как бы немного ортогональные вещи.
А для написания современного софта совершенно неглупые люди придумали 12FA.
В теории можно задать максимальный размер и параметры ротации, но кто это делает? Только честно
Да все это и делают. 3 строчки в конфиге. Потому что те, кто с этим реально работал, на эти грабли наступали уже N лет назад и давно приняли на вооружение как best practice. Так же и с остальным.
Ну, вот смотрите честно — из коробки никаких лимитов нет (мы же помним, что дефолтные настройки почему-то всегда оторваны от жизни). Соответственно, я почти наверняка уверен, что каждый пользователь докера сталкивался с переполнением диска от логов.
Можно написать целый талмуд с рекомендациями (от "ограничивает размер логов" и "используйте другой драйвер логов" до "выделяйте под докер отдельный том (раздел)) — только толку? Как стреляли люди себе по ногам — так и будут.
Что интересно — единого свода таких эксплуатационных рекомендаций (по сути — best practice) я не видел. Может плохо искал. Поэтому каждый ходит по граблям самостоятельно. Иногда это весело. Иногда не очень
Не соглашусь, но это мое частное мнение. Любая последующая абстракция в идеале требует понимания всех лежащих в основе ее. Сможет ли разработчик эффективно работать с докером (писать докерфайлы, запускать/отлаживать контейнеризованное приложение и т.п.) не зная вообще баш, основы сетей, основы линуксе и прочее? Чего-то я очень сильно сомневаюсь.
Если задача — изучить nginx — да.
Если задача — быстро получить работоспособный сайт — да, но с оговоркой, что у коллеги должен быть докер соответствующий версии, правильно настроены права на каталоги и пр. пр. (что относится к окружению).
Внезапно — передать готовую виртуалку проще (за исключением того факта, что она "жирнее" и "весит" больше гигабайтов, чем контейнер).
А если вы пытаетесь под докером гонять машинное обучение… То там просто тьма нюансов с версиями nvidia, ядер и прочего
какие права? Всё эти кишки заботливо упакованы более опытными людьми в сам контейнер. Этим докер и прекрасен именно в контексте тимворка.
А то, что разраб, когда разрабатывает — не будет пересобирать контейнер на каждое изменение (хотя возможно лучше, чтобы пересобирал). Настраивается bind mount + hot reload, по возможности. И дальше потенциально начинаются проблемы с правами — код-то снаружи контейнера. Интересная дискуссия была в треде. Я там накидал элементов супового набора, которые могут помочь решить эту проблему… Но ее ведь приходится решать и городить свой очередной велосипед.
Ес-но, для продакшена такое не годится — когда образ едет в продакшен в него запекается: код, конфиги, какие-то данные (например, веса ML-моделей, статика для веба). Это все снижает проблемы ТАМ, но не здесь, на машине разраба.
Вот отличный пример "изоляции" — https://habr.com/ru/post/467607/#comment_20634225
С тем же компоузом — есть матрица совместимости версий:
https://docs.docker.com/compose/compose-file/compose-versioning/
И там далеко не все форматы работают на любых версиях compose. И не любая версия compose работает с любой версией docker демона. И, да, я в это наступал.
Но соглашусь — что это-то как раз является решаемой проблемой.
Еще могу отметить, что у того же редхата своя нумерация версий (у них до сих пор docker 1.13).
Обычно это эмулирует среду на продакшн и помогает разрабам избежать разных ошибок, связанных со средой. Копирование продакшн среды по-моему одно из самых главных преимуществ контейнеров.
Это отчасти миф. Невозможно полноценно воспроизвести на машине разработчика продакшн среду. Всегда будут какие-то отличия. Ну, например, трафик. Вы сможете влить на машину разраба столько трафика сколько в продакшен среде? Нет. А это и не нужно. Или может отличаться архитектура процессора (а там связанные с этим оптимизации). Или минимально необходимый набор сервисов для запуска тупо не влезает в машину разраба. А может это и не нужно — можно либо подцепиться к клону продакшена снаружи, либо замокать сервисы-зависимости. И пр. пр. пр.
В каждом случае граница определяется индивидуально.
Виртуалку нужно постоянно апдейтить, перестраивать, настраивать шеринг директорий, и т.д. и т.п., да и легче запустить одну команду, чем тащить лишние гигабайты.
Vagrantfile + vagrantbox — вполне повторяемая и удобная среда.
Для локального девелопмента я бы однозначно выбрал бы контейнер, а не виртуалку.
Соглашусь, что при прочих равных — контейнер и стартует быстрее, и кушает меньше ресурсов, и как-то docker удачнее зашел в среду смузихлёбов (сам такой ))), поэтому — да, возможно, что для локальной разработки докер будет удобнее.
В большинстве разрабу нет необходимости копировать абсолютно всю среду продакшена, достаточно сервиса который он разрабатывает и то что к нему относится.
Прямо необходимости может и нет, но очень часто разворачивание всей среды локально заметно повышает скорость разработки/отладки/тестирования. Пока она помещается локально, конечно.
Есть ещё ссуперофициальные library/*, которые без префикса можно использовать.
два момента: докер популяризовал не контейнеры (как технику запуска), а контейнеры (как технику пакетирования). Квадратно-гнездовой деплой — это правильно.
Второе, нативный докер не совместим с жизнью на десктопе линукса. После наблюдения за тем, во что превращается машина при запуске тестов (testinfra) в локальном докере я поднял виртуалку (kvm) и сделал докер на ней (так же, как это в маках и т.д.) — и оно стало работать (как в маках). Т.е. маководы, которые завидуют "нативному докеру" могут перестать завидовать.
Видимо, testinfra создает слишком много контейнеров и не очень подчищает хвосты за ними? Тоже не совсем понял, хотелось бы подробностей.
Но, кстати, знаю людей, которые ставят lxc/lxd и внутрь загоняют docker.
Я обнаружил, что у меня
а) меняется hostname на несвязной консоли
б) logind и другие системные демоны сходят с ума поедая тонны CPU.
Я сделал как на маках — есть виртуалка, внутри которой докер, а локальный докер-клиент к ней коннектится через бридж.
Наверное есть что-то похожее, но другое. Наверное, у всех найдётся за что попинать этот (и любой другой) инструмент. Но.
Мои задачи с ним выполняются быстрее, чем без него. Проблемы бывают, но я уже готов их решать. Есть граничные случаи, есть баги между версиями, но со всем этим в принципе можно жить.
Бывают трудные места для понимания и объяснения другим, но в целом кривая обучения довольно пологая. Инвестиции от обучения сотрудников базовым навыкам возвращаются быстро. Новые сотрудники могут начать работу в течение нескольких часов. И большая часть этого времени не будет связана с контейнерами (поставить, настроить IDE, и прочее).
Хочу попробовать инструмент от Фланта (flant/werf aka dapp), хочу заменить bash-скрипты на ansible и make-файлы, собираюсь развернуть кластер k8s… Но это не мешает мне уже работать и решать свои задачи достаточно эффективно.
Хочу сказать, что докер — он как танк. Даже самый лучший и современный танк обладает врождёнными родовыми уязвимостями. Но никто в здравом уме не пошлёт танки в бой без пехоты и других видов техники, которые эти уязвимости будут закрывать. Докер — для командной игры. Некоторые его недостатки можно и нужно закрывать другими инструментами. Например, виртуальными машинами.
Но, самое главное — что кроме докера, как реализации, есть ещё runC и другие спецификации, которые подстёгивают развитие альтернативных реализаций отдельных кубиков workflow контейнеризации и оркестрации.
И уж конечно, дольше докера проживёт сама идея «инфраструктура как код». На чём бы вы её не воплощали — это уже большой шаг от ремесленника к инженеру. Начните с чего угодно — главное начать.
Спасибо, очень интересное мнение.
Касательно "инфраструктура как код" — эта идея началась РАНЬШЕ докера, причем существенно. Примерами ее реализации являются SCM (системы управления конфигурацией): Chef, puppet, ansible, salt. Сейчас это все, конечно, переходит на следующий, новый уровень описания. Появляются более высокоуровневые инструменты вроде terraform/cloudformation. В общем — все очень интересно и здорово.
Именно поэтому я радуюсь, что докер дорос до того, чтобы для борьбы с ним большие дяди объединились и написали спецификации. Чтобы вы могли заменить его по частям на что-то более зрелое, конструктивно православное и т.п.
А ещё «докеризация» способствует лени программеров. Вместо полноценного вменяемого INSTALL, встречаешь «устанавливайте докер, тяните вот этот имидж из регистри, запускайте вот так».
Зла не хватает.
Несомненно — докер прививает вредную привычку заметать весь мусор под ковер, т.е. внутрь контейнера. Даже не разбираясь как оно работает. Ну, что остается. Писать регламенты, осуществлять процессы контроля безопасности образов, пытаться уменьшать их размер и пр. пр. пр.
Это не заметать мусор под ковёр, это запирать тех, кто мусорит в отдельной комнате, общаясь с ними через окошко в двери, а разбираться с ними в индивидуальном порядке при необходимости и(или) появлении желания. Это лучше чем собирать их вместе в опенспейсе и позволять мусорить, зачастую даже не имея возможности определить где чей мусор.
Всё совсем наоборот: Dockerfile (и композ) — это и есть INSTALL, только формализованный и тестируемый.
Ну как сказать. Иногда нужно запустить какой то стек, чтобы посмотреть или проверить что-то. Например тот же ELK. И мне не хочется тратить час времени на чтение документации к каждому из компонентов этого стека. Ибо при установке по Readme/INSTALL может выясниться, через час дебага, что у тебя не совместимая версия ОС/библиотеки. А поймешь ты это только по issue на гитхабе, если повезет
И согласен, и нет. Именно с ELK прекрасный пример, когда требуется настройка хост оси. Без того, чтобы прописать на хосте
vm.max_map_count=262144 ничего не заработает. И они мне тут про изоляцию от среды рассказывают...
Вам некогда выяснять всё ли у вас совместимо со стеком разработчика, а хочется docker pull… и поехали, А мне — совсем наоборот — хочется выполнять инструкции из INSTALL, и может даже по ходу пьесы где-то там что-то подправить в исходниках, чтобы оно работало на моих системах как минимум так как обещает разработчик, как максимум — так как хотелось бы мне.
Кстати, получение вот такого совместимого с самим собой «чёрного ящика» лишает меня возможности копаться внутри апликухи с целью исправления чего-то там мелкого или кастомизации под себя. Потому что, одно дело — включить дебаг лог, посмотреть что не так и поправить 1-3-5-10-15 строк, другое дело — «сначала установить docker, docker-compose и ещё 33 зависимости...», а потом пересобирать/запускать имидж со своими правками?
Но вот тут уже мне лень, скорее всего в сторону того, что работает только в докере смотреть я просто не будут.
А мне — совсем наоборот — хочется выполнять инструкции из INSTALL
Ну так это, находите dockerfile от образа, и выполняете.
Потому что, одно дело — включить дебаг лог, посмотреть что не так и поправить 1-3-5-10-15 строк
А вы ожидаете, что вам приложение с исходниками дадут? А почему, собственно?
Вот так же и "подразумевается", что вы способны прочитать dockerfile вместо install, и подправить, что вам нужно и где. Так что никто вас альтернатив не лишает.
Ну так это, находите dockerfile от образа, и выполняете.
И внезапно выясняетя, что те файлы, в нем используются — уже недоступны, т.к. удалены. Или в докерфайле не зафиксированы версии устанавливаемого ПО и при сборке ты получаешь вроде бы то же самое, но бинарно другое. И прочее, прочее.
Несомненно — наличие докерфайла как концепции, как чертежа УЖЕ сильно облегчает жизнь и позволяет наводить мостики между разработкой и эксплуатацией. Но этого недостаточно.
Это из разряда логики — - Мы вам продадим этот седан, но чтобы им пользоваться, вам надо приобрести асфальтоукладчик. Не обязательно брать у нас, выберите ваш любимый цвет.
— Но позвольте, а можно я буду ездить по уже готовым дорогам?
— Ну нет, а вдруг дороги будут слишком узкие, или скользкие. Возьмите асфальтоукладчик — он проложит оптимальные дороги именно для вашей машины — экономия топлива максимальная и никаких ухабов. Будете быстро ездить и безопасно.
— Но я не хочу укладывать асфальт.
— Ну тогда мы не продадим вам машину, она едет только после асфальтоукладчика. Напрасно вы отказываетесь — управлять асфальтоукладчиком совсем несложно, вам понравится, может даже будете потом сами дороги прокладывать, освоите смежную специальность…
Будет как в Вистой. Только ленивый не написал как она плоха. Сейчас же все сидят на той же самой слегда допиленной висте (10ка) и не жужат.
Не все сидят. Для некоторых именно Виста стала причиной использования других ОС как основных.
Как замечено выше, файлы докера и есть INSTALL, но обязательно вменяемый (тестирование работоспособности предполагаем), а у ленивого программиста простого текстового вообще может не быть или быть такой, что лучше бы его не было.
А как вы решаете проблему коллизий имен с программами, которые кто-то напишет в 2030м году? У вас хрустальный шар есть? Не расскажите — чего он умеет?
мне казалось, что хабр — более профессиональная площадка.
а что в статье, что в комментариях — уровень «программиста 1С»
Автору б на конференции что-ли сходить, особенно по теме девопс, в которой он абсоютно ни в зуб ногой
билд инженер — это вымирающий динозавр в конторах, которые пилят дичайшие легаси монолиты. админ — это эникейщик который картриджи меняет. ВСЕ! в разработке админов не осталось. от слова совсем.
все норовят уйти в клауд, при невозможности — арендованные бареметал решения, на которых работает тот же кубер, номад, опеншифт.
ну не осталось в товарном к-ве задачь, где требуется sql база на надцать терабайт с доступом в миллионы операций в секунду.
другие тренды в разработке.
поэтому клауд ориентированные контейнеры обернутые оркестратором — рулят
кстати, внезапно, при переходе с композа на кубер — разработчикам стало ЛЕГЧЕ. Ну, если девопс хороший, конечно.
А чистый докер я уже лет 5 как не запускал.
кстати, по поводу к-ва контейнеров. не, понятно, что если на делфи педалить лабы в универе — их будет как пальцев на руке у пиромана. но вот нормальный проект — это уже давно не фронт+бек+база.
я для дев окружения использую миникуб, так вот, столкнулись с тем, что уперлись в ограничение в 110 под (запущеных контейнеров) на одну ноду. И это — обычный проект, не фейсбук.
а как еще оценивать пост «я, в 2019 году, наконец-то начал аккуратно использовать докер в проде?
а код вы, извините, храните где? на дискетке 3,5 дюйма, или начали наконец-то использовать svn? или до гита добрались?
мир РЕАЛЬНОЙ разработки давно уже переживал и выплюнул все „проблемы“ поднятые автором. и ушел от них настолько далеко, что отсель не видать.
сейчас занимаются аркестраторами, аркестрирующие аркестраторов, а отличия композа 2 от 3 забыли за ненужностью.
кстати, внезапно, при переходе с композа на кубер — разработчикам стало ЛЕГЧЕ. Ну, если девопс хороший, конечно.
А если нет? Причем если тут ерчь про composer php. То он внезапно более универсальное решение. Которое можно обернуть куда угодно и как угодно.
все норовят уйти в клауд
Не все норовят. Пускай многие (опять же не все) отказываются от собственных серверов, не говоря о "серверных", но ограничиваются арендой бареметал, а разворачивают и поддерживают "кубер, номад, опеншифт" сами. Иногда ещё базовую поддержку покупают, но с постоянными платными тикетами типа "добавьте на все ноды вот этот самоподписанный сертификат CA, раз доступа кнодам не дали", "обновите ингресс до последней версии, раз к его неймспейсу дорступа не дали" и т. п.
кстати, внезапно, при переходе с композа на кубер — разработчикам стало ЛЕГЧЕ
Вот как такой разработчик не могу согласиться. Количество сущностей в кубике на порядок выше, если не больше.
Ну, если девопс хороший, конечно.
А если его нет? Ну или он требует готовые конфиги, в которых он только права и ресурсы прописывает?
другие тренды в разработкеа можно узнать источник этих трендов?
поэтому клауд ориентированные контейнеры обернутые оркестратором — рулятопять таки, на основании чего такой вывод? В амазоне не было нормального оркестратора, aws fargate не крутил, ничего не скажу, да и появился он совсем недвно.
кстати, внезапно, при переходе с композа на кубер — разработчикам стало ЛЕГЧЕТ.е. когда человеку надо запустить nodejs приложение или банальный LAMP, предлагаете использовать кубик? И в чем проявилась легкость после перехода?
А еще, если использовать использовать docker swarm режим, то через некоторое время обнаруживаешь что у бэкенда за балансировщиком нагрузки нет нормальной возможности узнать реальный IP адрес клиента, который отправил запрос.
Не припомню таких проблем, хотя, может, от балансировщика зависит. А может и была "проблема", которая решилась одной строчкой в кофиге после чтения доки балансировщика
Это действительно техническая проблема, т.к., очевидно, что докер работает через файрволл и там магия с iptables, то он легко может подменять адреса real-ip клиента, причем безвозвратно.
Но, как правильно, говорите — все упирается в тип балансировки и способ взаимодействия с сетью используемого proxy (nginx, traefik и пр.).
Есть некие способы "решения" этой проблемы, но все это некоторого рода костыли.
В общем, это by design так балансировщик сделан.
www.cvedetails.com/vulnerability-list/vendor_id-13534/product_id-28125/Docker-Docker.html
Еще вспомнил, что вымораживает.
Если качаешь большой образ, то обычно делаешь docker pull. Все здорово, все классно — слои качаются в параллель и т.п. А дальше начинаешь видеть недостатки
- второй образ в параллель не поставишь. Точнее поставишь, но он будет ждать, пока скачается хотя бы 1 слой первого.
- если случайно закрыть сессию, в которой происходит docker pull — закачка большого образа оборвется. Хотя странно — она же ведь не на клиенте происходит, а на сервере. Кхм.
- если закачку оборвать, то все скачанные слои удаляются. Поэтому прервал закачку большого образа — будь добр перекачивать все слои заново. Где логика? Чтобы это обойти каждый промежуточный слой можно оформлять в виде отдельного образа — тогда можно обеспечить докачку.
- docker save | docker load и прочие механизмы не обеспечивают послойного скачивания образа — только docker push/docker pull.
- не проверял — но при параллельном скачивании двух образов — возможно как-то криво срабатывает кэширование и если они сделаны с общими слоями, то они будут скачены параллельно (т.е. дважды). Не уверен, правда.
Зачем проекты вообще переносить с Linux потребовалось?
Никаких проблем с совместимостью.
Годы периодических экспериментов с докером на винде для виндофронтов лично мне показали, что лучше "ручками" собранного виртуалбокса как удаленного докерхоста для бэка ничего нет ещё для локальной разработки. Черрез нескольк месяцев буду экспериментировать с миникуб штатным, но есть сомнения что станет лучше.
Ну то есть как — нет? У меня рабочая станция по виндой, мне надо запустить контейнер для того-то и того-то, который собран под Линуксом. Я ровно для этого докер и использую.
Так зачем извращаться если все равно виндовской докер на недо-виртуалке бежит.
Ровно наоборот: зачем извращаться с самостоятельно поставленной виртуалкой и прокидыванием данных с вашей машины в виртуалку, а потом оттуда в докер, если можно просто поставить работающий докер, который большую часть сделает сам.
"у меня такая же нога и не болит"
В том смысле, что у меня последние полгода, которые я с ним вожусь, работает нормально (кроме одного специфического кейса с sagemaker-local, где сами разработчики виноваты), а на стабильность в смысле "чтобы работало дольше суток" мне искренне положить, у меня все контейнеры короткоживущие.
https://www.cyphar.com/blog/post/20190121-ociv2-images-i-tar
https://www.youtube.com/watch?v=bbTxdzbjv7I
Отлично. До коллег дошло осознание, что OCI стандартн на образа в нынешнем виде никуда не годится.
Docker предназначен для контейнеров приложения (где запускается только оно напрямую, без init-системы и системных демонов), LXC/LXD/systemd-machined — для системных контейнеров (как виртуалка, только на общем ядре, а-ла OpenVZ).
Вы только что сказали глупость. Действительно, в теории очень круто разносить контейнеризированную ОС (типа OpenVZ) и контейнеризированные приложения. На практике — все равно получается, что очень большой кусок операционной системы тащат в докеры (в первую очередь — всякие библиотеки). И это нормально. А потом обвешиваются супервизорами и инит системами, т.к. внутри контейнера докера появляются зомби-процессы (само приложение или шелл-скрипт для запуска не корректно обрабатывает форки) или приходится засосывать несколько сервисов в один контейнер.
Я лично за то, чтобы разделение было хотя бы на уровне обучения разработчиков и опсов. И глядишь — когда-нибудь этой фигней не придется заниматься, но пока… Таскаем круглое и носим квадратное.
А потом обвешиваются супервизорами и инит системами, т.к. внутри контейнера докера появляются зомби-процессы
Если правильно писать и проектировать приложение — не появляются.
Отличный аргумент (((( Покажете этих людей, которые нормально пишут? Можно поименно. А еще у них наверняка образы FROM scratch со статически скомпилированным бинарником?
На самом деле проблема шире — на докерхабе уже есть сотни официальных образов, которые, прям скажем, не идеальны. И их реально приходится запускать в кубернетесе (по разным причинам — хотя бы для тестов). Ну, реально — не будете же Вы перепиливать тот же airflow под себя полностью? Или писать с нуля такой же аналогичный продукт (проще ведь взять готовый модуль)?
Отличный аргумент ((((
Достаточный чтобы не пользоваться образами с подобными костылями и требовать/контрибутить поддержку докер-совместимого поведения.
Покажете этих людей, которые нормально пишут? Можно поименно.
Он перед вами. Не пложу форки, обхожусь нитками.
у них наверняка образы FROM scratch со статически скомпилированным бинарником?
alpine-jdk и ubuntu:bionic
их реально приходится запускать в кубернетесе (по разным причинам — хотя бы для тестов)
эээээ… compose уже недостаточно для тестов?!
Ну, реально — не будете же Вы перепиливать тот же airflow под себя полностью? Или писать с нуля такой же аналогичный продукт
Если не удовлетворяет критериям проекта — почему нет? На прошлом проекте помнится искали security policy decision сервер, коих в природе штук пять что ли, причем все жутко медленные. Плюнули, написали свой.
В итоге, правда, посрались на предмет DSL для описания тех самых полисей и я с проекта ушел.
Не работать с мудаками и не жрать говно — два принципиальных момента в любой работе, и все будет хорошо.
Спасибо за развернутый ответ.
alpine-jdk и ubuntu:bionic
Позвольте поинтересоваться — пишете промышленный код на java?
Или на каких-то более хипстерский языках вроде golang, python etc.?
перепиливать тот же airflow
Ну, смотрите. Разраб хочет потыкать в приложение. helm install и пошло. Понятно, что это никаким боком к продакшену не относится. И то, что качество чартов оставляет желать лучшего. Но удобно же. А потом ловишь странные проблемы. И почему не компоуз — потому что если приложение многокомпонентное (не все поставляется в виде единого докер образа), то никаких внятных способов поставки нет (хельм мне, кстати, тоже сильно не нравится).
эээээ… compose уже недостаточно для тестов?!
Для юнит тестов его скорее достаточно, но есть нюансы. Начиная от того, что компоуз не везде будет одинаково работать (причин достаточно). И кончая тем, что разрабы достаточно ленивы, чтобы писать и компоуз, и манифесты для кубернетеса. И коли мы говорим о кубернетесе как о целевой платформе (ну, вдруг), то хочется тестировать весь деплоймент (с конфиг мапами, секретами и пр), но мы в принципе успешно и без этого обходимся ))))
Не работать с мудаками и не жрать говно — два принципиальных момента в любой работе, и все будет хорошо.
+++
Позвольте поинтересоваться — пишете промышленный код на java?
Java, Kotlin, python. У нас тут такой себе зоопарк — обработка медиа, нейронки, и CRUDы.
Что до Кубернетеса, я его рассматриваю как надстроечку над докером. Он, наверное, полезный, но излишне сложный концептуально. Поэтому обсуждать не могу.
Что до Кубернетеса, я его рассматриваю как надстроечку над докером.Ну это странно как-то. Изначально же всё-таки был Kubernetes. Только его тогда Borg звали.
А потом от него «отрезали» маленький такой кусочек и назвали вот это вот — Docker. По незнанию больше, просто потому что существование чего-то типа Docker'а при взгляде на Cgroups очевидно, а вот Borg/Kubernetes — нет.
А до это был хадуп )))) хотя он под весьма узкую задачу, но тем не менее распределенные системы начинались не с Борга.
Hadoop — это всего лишь более ранняя попытка воссоздать «осколок» ранней версии Borg'а, на самом деле.
Не пложу форки, обхожусь нитками.И где гарантия, что fork() не вызовет какая-нибудь библиотека, которую вы используете? Или вы библиотеками не пользуетесь, всё сами, с нуля?
а вызывать внешний процесс — некомильфо, да
Тут можно только посочувствовать вашим заказчикам — вместо поддающихся исследованию админом процессов они получают простая вагоном не понять ничего вообще… без специальных средств отладки.
Но да, гильотиной головная боль успешно лечится, признаю…
Тут можно только посочувствовать вашим заказчикам — вместо поддающихся исследованию админом процессов они получают простая вагоном не понять ничего вообще… без специальных средств отладки.
Вы что-то попутали. Обычно достаточно куска лога со стектрейсом. И всё. Какие «специальные средства отладки»? Тем более, что на продакшне все тащится в ELK скоррелированным логгированием.
Вот они как раз нужны, если у вас многопоточное приложение, написанное в модели COM выносит ntoskrnl всиньку, и от причины остается только крэшдамп с содержимым регистров. Да, проходил.
Но да, гильотиной головная боль успешно лечится, признаю…
Я так понимаю, нитки и файберы отобрали, раз альтернатив форку не видно? Нет форков — нет головной боли.
И до кучи приложение выглядит элегантно и не вылазит из назначенных memory boundaries.
И до кучи приложение выглядит элегантно и не вылазит из назначенных memory boundaries.У нас с вами, наверное, разная Java. Потому что у нас — типичная проблема в том, что Java приложение начинает жрать память как не в себя… после некоторых действий. Как правило — после каких-нибудь странных запросов или необычных паттернах использования.
Когда у вас много процессов — это тоже возникает, но поскольку всякие кеширующие сервисы (а именно там такая фигня и лезет) можно перезапустить — то это не проблема. А вот с Java — это постоянная головная боль. Оно ж ведь, перед тем как сожрать выделенные гигабайты и окончтаельно «навернуться» успевает превратить жизнь пользователей в муку…
Но да, проблемы убежавних процессов нету, призняю…
Я так понимаю, нитки и файберы отобрали, раз альтернатив форку не видно?Нитки и файберы никак, ну вот совсем никак не помогут вам изолировать сырой код с утечками памяти от того, которому падать ни при каких случаях недльзя. Извините.
Вот они как раз нужны, если у вас многопоточное приложение, написанное в модели COM выносит ntoskrnl всиньку, и от причины остается только крэшдамп с содержимым регистров.Если у вас на сервере откуда-то взялся COM и ntoskrnl — то дальше уже неважно, Java там или C#.
у нас — типичная проблема в том, что Java приложение начинает жрать память как не в себя… после некоторых действий. Как правило — после каких-нибудь странных запросов или необычных паттернах использования.
Возникает резонный вопрос — а зачем вы ее так необычно готовите?
Я даже больше скажу — ООМ в Java несложно накликать тупо пробросив метод с Async аннотацией. Но Async на долгоживущих операциях — это стрелять себе в ногу.
Нитки и файберы никак, ну вот совсем никак не помогут вам изолировать сырой код с утечками памяти от того, которому падать ни при каких случаях недльзя. Извините.
Для того, чтобы не падать — у вас уже есть докер. Точнее, чтобы переподниматься. Если память течет — значит кто-то ее не отдал обратно. Пусть правит, а дальше рутина разработки — покрывать такие вещи тестами.
Если у вас на сервере откуда-то взялся COM и ntoskrnl — то дальше уже неважно
Во времена оные в энтерпрайзе выбора особо не было, а вот отлаживать это было куда больнее, чем разбирать логи джава-сервиса.
Для того, чтобы не падать — у вас уже есть докер. Точнее, чтобы переподниматься. Если память течет — значит кто-то ее не отдал обратно.
Учитывая, что на докер хосте память общая… Ну, будет подтекать медленно, но уверенно во всей системе (ядро-то и память общие!). Ну, да, переподнимется конкретный контейнер. Но тот же ООМ может придти и за соседями. Короче, аргументы ЗА контейнеризацию у Вас какие-то слабые.
Ну, будет подтекать медленно, но уверенно во всей системе
Пять хостов с аптаймами по полгода и больше смотрят на этот коммент с недоумением.
А хосты смотрят с недоумением на Вас — Вы там ядро, что ли, не патчите? А как же уязвимости?
Я недавно сканирование на уязвимости заказывал. Судя по отчету — проблем нет.
Я недавно сканирование на уязвимости заказывал. Судя по отчету — проблем нет.
так не бывает. Даже лень объяснять почему. Проблем не может быть только в том случае, если ничего нет. Ну, либо Вы прям Бог-администратор. Ну, тогда могу только порадоваться за Вас.
так не бывает.
Ну вон же лежит отчетик. От сертифицированного ИБшника, свежим MaxPatrol-ом. Что касается удаленных уязвимостей — там все ок. А локальные меня не колышут.
MaxPatrol работает как — он сканирует удаленный узел в каком-либо режиме и матчит сервисы (их версию по баннеру или версию пакета) со своей базой. Поэтому запросто могут быть false positive или false negative результаты. Он же не "взламывает" сервис, не проверяет конкретные эксплойты (самое то делать на продакшене, ога).
Я уж не говорю о том, что локальные уязвимости тоже фиксить надо, хотя именно удаленные — в первую очередь. Иначе хакер может по цепочке зайти.
Поэтому я а эти отчёты по ИБ не очень верю и отношусь со здоровым скепсисом.
Он же не «взламывает» сервис, не проверяет конкретные эксплойты
Ну ващет — может проверять )
локальные уязвимости тоже фиксить надо[...]. Иначе хакер может по цепочке зайти.
Угу, на обложенный файрволом хост, с выключенной парольной авторизацией по SSH?
Ну, э… Ну пусть заходит. Если сможет.
В самом крайнем случае я там хостовую систему перезалью, а дальше сопцна накат докера, и сервисов.
Дел на пять минут.
Возникает резонный вопрос — а зачем вы ее так необычно готовите?По той же причине, по которой нужны контейнеры вообще, однако. Люди несовершенны и созданные ими программы — тоже.
Точнее, чтобы переподниматьсяВот только переподнимать он будет «весь мир» целиком, если у вас один процесс. А это чревато: одно дело, если у вас пропал какой-нибудь блок «с этим товаром обычно покупают...», и совсем другое — если человек не получает ответа от сервера вообще.
Пусть правит, а дальше рутина разработки — покрывать такие вещи тестами.А пока он правит — пусть посетители от вашего сайта держатся подальше… замечательный такой план, да.
Во времена оные в энтерпрайзе выбора особо не былоЭто у вас какой-то странный «энтерпрайз». То что я встречал — это переход с AIX'а и Solaris'а на Linux в основном.
А COM и ntoskrnl — это в основном о малом и среднем бизнесе…
А пока он правит — пусть посетители от вашего сайта держатся подальше… замечательный такой план, да.
А вы докером пытаетесь проблемы в организации процесса разработки решить? Неожиданно.
Это у вас какой-то странный «энтерпрайз». То что я встречал — это переход с AIX'а и Solaris'а на Linux в основном.
AIX и Solaris — это в основном банки. А крупные компании федерального масштаба с 1995 по 2005 вполне себе жили на Windows. И на Linux стали переползать относительно недавно, в 2011-2013
Я еще чего хотел сказать. Возможно Вы и правы, что нужно изобретать каждый раз свой велосипед. В принципе, большие компании этим занимаются постоянно. Для инженеров, наверное, это забавно, т.к. позвояяет решать одни и те же задачи снова и снова (в том числе и применяя разные новые способы). Но с другой стороны — это не решает бизнес-задачи (они больше решаются "взять модуль" и "сшить с тем, что уже есть", правда, иногда интеграция становится кошмаром — тут действительно нужно взвешивать сложность и выгоды) и я очень расстроен опен-сурсом. В чем его смысл, если каждый будет изобретать велосипед? Хотя и тут — действительно, качество большинства опен-сурс проектов ниже плинтуса...
Как пример — есть прекрасная Java-библиотека Orchid, которая реализует функциональность Tor. Но вот в том форке, который сейчас активно развивается — есть косячки, препятствующие нормальной работе в условиях Android-окружения. Пришлось форкнуть форк и допилить )
Достаточный чтобы не пользоваться образами с подобными костылями и требовать/контрибутить поддержку докер-совместимого поведения.
Инит-системы разной степени велосипедности, равно как форк мастер процесса для воркеров (самый популярный, наверное, nginx) не нарушают докер-совместимости по умолчанию. Один процесс на контейнер — это не жесткое правило, которое должно соблюдаться. Это лишь хорошая практика, которую не следует нарушать без веских причин. Системы, которые написаны как многопроцессные, предполагающие тесное взаимодействие своих процессов сначала разбивать дефолтными средствами докера на изолированные процессы, а потом пробивать эту изоляцию десятками параметров контейнеров — усложнять себе жизнь на ровном месте, если это не даёт каких-то ощутимых плюсов в конкретном сценарии использования.
Можно на "ты"?
В целом — соглашусь. В докер с известной степенью беспроблемности можно запихать все. Другой вопрос, что та же init система внутри докера автоматом ломает конвенцию, что мы пишем ошибки в stdout/stderr. И приходится извращаться — либо пробрасывать сокет для логирования с хост-машины, либо писать логи в файл, а потом приделывать к ним транспорт какой-то. А потом выясняется, что это ещё и стейтфул приложение. И нужно куда-то данные отгружать. И понеслась.
И выясняется, что мы всего лишь хотели что-то типа виртуалки полноценной или lxc-контейнера, а использовали просто более знакомую технологию — docker
Системы, которые написаны как многопроцессные, предполагающие тесное взаимодействие своих процессов
Я вот уже два десятка комментов не могу понять зачем пользоваться форком вместо ниток. Заодно оверхед на взаимодействие меньше.
А зачем основному потоку работать под рутом? Тем более в контейнере?
Один из доводов за рута для nginx'а — необходимость слушать (ему) привилегированные порты 80 и 443. Поэтому при запуске в докере легко можно перевесить на 8080 и 8443 и сделать проброс файрволлом. Тут, конечно, все зависит от требований. Но тот же "rootless" энжинкс при желании вполне можно собрать. Да и без докера в принципе тоже....
$ man setuidIf the user is root or the program is set-user-ID-root, special care must be taken. The setuid() function checks the effective user ID of the caller and if it is the superuser, all process-related user ID's are set to uid. After this has occurred, it is impossible for the program to regain root privileges.seteuid не подходил, но так как это было давно, я не помню, в чём он состоял.Вероятно, есть непонятные вам плюсы. Я не знаю какие, я пользуюсь тем, что есть.
Если правильно писать и проектировать приложение — не появляются.Если всё всегда правильно писать и ошибок не делать, то и все эти контейнеры нафиг не нужны.
Все современные ОС — многозадачные, как бы.
Я даже не знаю что сказать. Вам недостаточно средств изоляции, которые дают systemd и прочие встроенные средства? Аккаунтинг и изоляция ресурсов не требует docker'а. От слова совсем.
Ну, что ж. Конец 2019-го года — самое время изучать линукс и системди на глубоком уровне. Ничего зазорного в этом нет. Все так же продолжаем выезжать на технологиях 30-50 летней давности....
Так вот докер как раз про это — собрать один раз и распространять вместе с окружением.
Изоляция вместе с окружением — так понятнее, что я имею в виду? Да, ценой дискового пространства, конечно, но кто считает гигабайты накопителя в 2019?
Программист написал как ему удобнее/быстрее, сбилдил образ, который точно запускается и выложил в реестр.
Конечный потребитель/девопс забрал этот образ и запустил без размышлений какие зависимости ему надо ставить.
Все довольны. При этом оверхед существенно ниже, чем у VM.
Вы никогда не сталкивались с тем, что у вас какое-нибудь приложение банально не ставится/не собирается/не работает, потому что stdlibc или какая-нибудь еще библиотечка, которая в систему заезжает из репозитория не той версии?
systemd умеет в такую изоляцию. chroot — туда же.
Конечный потребитель/девопс забрал этот образ и запустил без размышлений какие зависимости ему надо ставить.
Ага. А потом выясняется, что образ собран на arm, а вы пытаетесь его на x64 запустить. Или в образе некий софт, который собран с SSE инструкциями, а на хосте старый проц. Или — образ требует привилегированный режим. Или — эластик — требует предварительной настройки sysctl на удаленной машине, т.к. это настройки ядра. И изоляция течет.
systemd умеет в такую изоляцию. chroot — туда же.
chroot — убог и костылен чуть более, чем полностью. давайте тогда уже про openvz говорить. собственно, во времена оные, когда докера еще не было, я предпочитал физическую железку нашинковать на VPS-ки, и в случае чего потерять одну VPS а не целиком хостовую ось.
А если на хосте sysvinit или upstart — мне что делать? docker опять же унифицирует.
Ага. А потом выясняется, что образ собран на arm, а вы пытаетесь его на x64 запустить. Или в образе некий софт, который собран с SSE инструкциями, а на хосте старый проц.
Ну… ээээ… если документацию к образу не читать — то сам виноват же. К слову второй случай на практике почти не встречается.
Или — образ требует привилегированный режим. Или — эластик — требует предварительной настройки sysctl на удаленной машине, т.к. это настройки ядра.
А вот такие вещи фпечь. Особенно «привилегированный режим».
собственно, во времена оные, когда докера еще не было, я предпочитал физическую железку нашинковать на VPS-ки, и в случае чего потерять одну VPS а не целиком хостовую ось.
Я тоже так делал. И более того всем рекомендовал использовать настоящие VPS, а не недо-VPS на OpenVZ.
А если на хосте sysvinit или upstart — мне что делать? docker опять же унифицирует.
Достаточно странный аргумент, учитывая, что докер тупо нормально не встанет на старые ядра. А весь нынешний линукс сплошь systemd, кроме отщепенцев типа гентушников. Но где гентушники и где докер? И еще. Положим, у вас не винда и не линукс. Тогда у вас и докера нет. Мак — ну, ок, через виртуалку. А BSD? Нет. И точка. Поэтому про портабельность… не надо.
Ну… ээээ… если документацию к образу не читать — то сам виноват же. К слову второй случай на практике почти не встречается.
А ее кто-то пишет? Я же писал, что докерхаб — помойка. Да, и опен-сурс зачастую не такой качественный, как ты ожидаешь. Хотя, реально, есть образцовые проекты.
Почитал статью, очень любопытно. Непонятно, какие все же альтернативы есть, чтобы:
- Разработчик без особого опыта поднимания сервисов мог упаковывать и разворачивать приложение. Ну или не очень опытный девопс (который не умеет в мультистейдж и кубернетсы)
- Чтобы приложение не требовало специального развертывания на хостовом окружении
- Чтобы приложение можно было без проблем развернуть в том числе на win/mac.
- Чтобы само разворачивание локально выполнялось одной командой на всех вышеперечисленных осях.
На моих последних проектах докер отлично подходил. Странностей не делали, докерфайл на 50 строк из которых большую часть умеет генерировать идешка, приложенька спокойно запускается на всех операционках, после чего к ней можно подключиться из любимой IDE и подебажиться. Быстро и удобно. Всё сделал — запустил на билдсервере билд, он пересобрал образ, запушил и перегрузил докер-композ на продакшн инстансах. Изменения долетели, все довольны.
Ну то есть я признаю, что у докера проблемисы. Гигабайтные логи разбирать отдельное удовольствие. Хорошо хоть узнал про -.json файлики, начал руками из /var/lib/docker их читать, причем на винде этот способ не работает потому что докер запущен в виртуалке, и как получить к ней доступ я не нашел. Проблемы есть, но какие альтернативы, чтобы не потерять в удобстве? Я тот самый "ленивый разраб", который хочет ткнуть кнопку и чтобы оно само.
Проблемы есть, но какие альтернативы, чтобы не потерять в удобстве? Я тот самый "ленивый разраб", который хочет ткнуть кнопку и чтобы оно само.
- Проблемы решаемы. Болью. Потом. И кровью.
- Само не бывает. Не придумали еще кнопку "сделать зашибись"
- Я, конечно, могу предложить Вагрант — он чуточку более переносим, чем докер, но там свои нюансы. Начиная от того, что это полноценная виртуалка со всеми своими плюсами и минусами (да, там еще могут быть разные провайдеры — от гипер-ви до kvm-qemu), кончая тем, что конфиг — Vagrantfile — это по сути код на руби ((((
- Ну, и не забывайте, что виндовс-контейнеры — это не то же самое, что и линукс-контейнеры. Я так понял из Вашего комментария, что вы на работе пользуетесь именно линуксовыми контейнерами?
- Ну вот с болью не хочется. С докером пока получалось достаточно просто.
- Пока что
docker-compose up -dдля меня является такой кнопкой. - Не, конфиги на руби это на любителя офк.
- На винде можно из-под винды дебажить линуксовые контейнеры в докере, аттачится к ним, и полноценно с ними работать. Так что да, и во время отладки и на проде используются линуксовые контейнеры, но вот хост-система может быть совершенно разной.
Парадоксальный вывод, что винда на текущем этапе представляется более удобной для разраба системой, т.к. позволяет работать и с вЕндо приложениями
И с Линукс. Но тут какой момент. Это все даётся не бесплатно — по сути в Винду уже встроен полноценный Линукс со своим полноценным ядром. Точно так же я могу и на маке, и на линуксе гонять ВМки с виндой и пользоваться преимуществами обеих систем. Ну, может это менее нативно будет, что ли. Но вот лично мне — wsl не зашёл. Совсем. И, да, под той же виндой в теории производительность докер контейнеров может быть ниже, чем под нативным линуксом. Не зря же docker-sync [1] изобрели!!
Еще добавлю, что у нас задачи связанные с машинным обучением. Ну, там CUDA всякая. Я почти наверняка уверен, что на маке и на винде оно не заведется. В линуксе — без проблем. Явных причин, почему CUDA не будет работать в WSL не вижу — как-то же видеоадаптеры виртуализируют. Но почему-то все DataScientist сидят все равно на линуксах....
… на маке и на винде оно не заведется. В линуксе — без проблемРечь про nvidia-docker? Или может вообще без докера?
nvidia-docker, ога. Все верно.
Почему через докер — потому что там всякие tensorflow и pytorch, которые очень инвазивны по отношению к системе + удобно это катить на продакшн в таком виде.
Учитывая, что еще и образы достаточно хорошо разбиты на слои, то есть возможность не перекачивать все, а только изменившуюся часть (там образы по 5ГиБ получаются — прилично, чтобы каждый раз их качать с нуля).
Я почти наверняка уверен, что на маке и на винде оно не заведетсяВсе работает без вопросов на Винде. И Куда и TF и Пайтроч и все остальное. И с минимальными правками в коде Питона. Переносимость у него хорошая.
И, да, под той же виндой в теории производительность докер контейнеров может быть ниже, чем под нативным линуксом. Не зря же docker-sync изобрели!!!!
Это все конечно верно, но ведь во время дебага производительность особо ни к чему, главное чтобы код как-то выполнялся.
А WSL и мне не зашел, когда я тыкал в моем пет-проекте его у меня он не мог собрать сишные зависимости из-за ошибки где-то в ядре. На виртуалке в итоге все собралось норм.
Получается, я все же не динозавр, что пользуюсь докером, и более удобных инструментов для моих потребностей нет?
ну, как сказать. Вариант — выделять отдельную ВМ и к ней коннектиться через среду разработки посредством ssh / git hook (тот же пайчарм так умеет). Но это действительно не очень удобно.
Это все конечно верно, но ведь во время дебага производительность особо ни к чему, главное чтобы код как-то выполнялся.
Если речь про изолированный сервис и вы под виндой — да, докер удобен.
Если разрабатываете под линуксом или маком — зачастую удобнее использовать нативные инструменты (те же python virtual environment), хотя они требуют определенной сноровки для эффективной и… безошибочной (хотел сказать — безопасной) работы с нми.
Если же сервис требует чего-то еще дополнительно для запуска — тут начинаются проблемы. Начиная от того, что докер не про порядок запуска сервисов (совсем) и кончая тем, что на машину разраба все тестовое окружение может не влезть. Т.е. здесь больше вопрос в том насколько приемлема для вас локальная разработка.
Про вагрант понял Вашу точку зрения, но иногда он бывает единственным вариантом, который более-менее удобен и переносим.
Я ходил по КАЖДЫМ граблям, описанным в статье. Думал, мне не везёт. :) Любимое, конечно, это файрвол – особенно, если отрубить userland-proxy и, внезапно, секьюрити пропадает вообще, несмотря на дефолтный DROP во всех цепочках. Я не нашёл ничего лучше, как вручную добавлять DROP в цепочку DOCKER-USER для каждого порта каждого сервиса, который смотрит наружу, но это ломает всю UNIX философию безопасности. А ещё DOCKER-USER нет для IPv6, а ещё nft не поддерживается и, похоже, не предвидится, потому что… ну потому что вот так вот!
А наткнулся на статью случайно, искал про Nix vs Habitat…
В конце инсталяции есть выбор установки ssh, postfix и docker.
Ок поставил галочку докер. Дык он установил через snap.
Порог адекватного использования этой технологии очень высок. Набивая шишки, его адепты уже начинают восхищаться тем, что знают столько много тонкостей о нём. Но если вам нужно решать задачи, а не сублемировать, то скорей всего при нулевых знаниях о докере вы весьма эффективно и быстро развернёте сервис на старых «советских» технологиях вроде виртуальной машины.
Вот и получается порочный круг. Чтобы использовать докер или кубер нужно их изучать, прям изучать, проходить курсы, лучшие практики и всё равно иметь кучу проблем, хотя бы потому, что другие твои коллеги совершенно по другому видят организацию этой технологии и челают всё то же, но несколько иначе. А можно делать всё по старинке с гарантированными привычками, адекватной работой системных утилит и сервисов и не решать детские проблемы с доступом к файловой системе или с сетью.
А удручает последняя тенденция тем, что всё больше и больше любителей понаговноделать изучает эту технологию и продолжает говноделать уже с геометрической прогрессией то, что делали раньше линейно. И что удивительно им платят больше денег и называют их гордым именем DevOps.
И если раньше я думал, что это всё скоро закончится, и эта технология себя изживёт, то сейчас начинаю понимать, что куча идиотов, так легко нырнув с головой в эту кучу помёта, будут до последнего себя оправдывать и продолжать жрать кактус. Да и разгребать весь этот цирк с конями и клоунами ни один здравый человек не станет.
вы весьма эффективно и быстро развернёте сервис на старых «советских» технологиях вроде виртуальной машины.
По каким метрикам эффективно? С учётом, что разворачивать его надо будет, возможно, десятки раз в день?
По каким метрикам эффективно? С учётом, что разворачивать его надо будет, возможно, десятки раз в день?
вообще-то я с коллегой согласен. Вопрос эффективности сводится к наличию рабочих и отлаженных пайплайнов. А ими можно строить что угодно — я вот буквально месяц назад строил пайплайн для сборки образов SD карточек для распбери. Почему нет? Но, к справедливости, там нет необходимости деплоиться каждые пять минут, но ее даже в ВЭБ ПРИЛОЖЕНИЯХ НЕТ ^_^ Это какая-то странная придуманная мантра — толку от деплоя каждые пять минут, если у вас фронт по 40 собирается? Конечно, время сборки надо оптимизировать, но у любого процесса есть предел. Готовы ли Вы достичь время сборки в 1 секунду, скажем, за стоимость месячного оборота Вашей компании?
Ну, и, конечно, надо разделять разработческие среды и продакшен. В первых — можете катить чем угодно и как угодно, только не надо делать вид, что это продакшен )
Это какая-то странная придуманная мантра — толку от деплоя каждые пять минут, если у вас фронт по 40 собирается?
Да хоть троё суток пускай собирается. Суть "деплоя каждые пять минут" ведь не в том, как быстро попадёт отдельный коммит на продакшен, а что он попадёт независимо от других, что не нужно накапливать слабо связанные фичи в накопительный релиз.
Ну, и, конечно, надо разделять разработческие среды и продакшен.
Зачем? Не, понятно, что полностью идентичными они не будут, но в целом зачем сознательно к этому стремиться? Я вот на новый проект пришёл: три различающихся способа выкатки на дев, тест и прод среды. Без документации по дев-среде вообще и "умному" копипасту между тестом и продом. Ладно неудобно и сильно подвержено человеческому фактору. Но куча времени тратится на локализацию багов из-за различий с одной стороны, а, с другой, некоторые фиксы только на продакшене тестить можно.
Я вот на новый проект пришёл: три различающихся способа выкатки на дев, тест и прод среды
разделять — не означает делать три принципиально различающихся способа выкатки. В одном из вариантов это могут быть просто три набора values.yaml с параметрами и три целевых кластера кубернетес.
Но куча времени тратится на локализацию багов из-за различий с одной стороны, а, с другой, некоторые фиксы только на продакшене тестить можно.
в нормальном проде никто туда доступа напрямую не даст — импакт от человеческой ошибки слишком высок, ну, а если у вас риски малые, то можно хоть прямо на проде тестировать...
/me промахнулся
Все случаи, когда я сталкивался с использованием Докера, повергали меня в уныние. Это отчаянные попытки не разбираться в том, как что работает, а максимально быстро сделать так, чтобы твой прототип заработал. Мне пофигу, как программист девелопит. Но на практике, даже опытные и хорошие программисты могут вливать тонны хаоса в продакшн своими замашками, взятыми из прототипирования и особенностей разработки, потому что им так удобно. И начинается:
— База в докере, хотя данные не должны лежать в контейнере, что ясно написано в мануалах. Это прямо вот маркер. Если база в докере, значит всё остальное будет ещё хуже. Дальше ssh по паролям сразу в рута для всех пользователей. А чо? Работает же.
— Приложения в режиме сервера разработки, а не режиме сервера приложения. А чо? Работает же.
— Бэкапы? Не, не слышали. А чо? Работает же.
— Приложение запускается только от рута, в том числе потому, что порты низкие и произвольные, хотя так делать нельзя. И сам Докер тоже запускается от рута там, где в этом нет никакой необходимости.
— А где логи? Как нет? Логи — часть контейнера и при пуше оного они перезаписываются? Вот это да!
— Версионность пакетов и батареек? А зачем? Оно же в контейнере и уже собраны. На это нет времени.
— Пересобирать контейнер раз в день, чтобы он стабильно работал? Это норма. Зачем делать ревью кода, если у тебя модуль на Си течёт на 32Gb памяти в день? Проще перезапустить. Зачем разбираться в том, почему модуль рандомно виснет, проще написать отлавливатель зависшего состояния по крону, делать kill -9 и перезапускать. init.d/systemd? Не, не слышали, зачем, есть же cron и скриптоложество. Зачем вообще тратить время на ревью кода, если можно расплачиваться аптаймом, который почти никто не заметит?
И так далее. У меня от этого вытекают глаза. При слове «докер» я инстинктивно хватаюсь за пистолет.
Проблема докера и всех этих новомодных трендов в том, что средний программист становится ещё тупее и ещё ленивее. Он не знает, как что работает, а сама работа сводится к быстрой реализации хоть как-нибудь, лишь бы работало, что распространяется и на код, и на деплой, и на проекты в целом. Тот самый «хуяк-хуяк и в продакшн». Я не против такого подхода для разработки, но когда дело касается продакшена, тут в моём понимании, без вариантов вообще. Даже то, как Докер хранит свои логи, уже указывает на то, что делался он без соблюдения хоть каких-то стандартов, потому что логи должны лежать в /var/log/, а не в рандомном месте ОС.
Люди не с той стороны заходят на процесс разработки/деплоя. Ты не должен передавать в продакшн собранную на коленке магию в контейнере, в которой не разбирается никто, включая тебя, ибо так исторически сложилось. У тебя изначально должен быть «метаскрипт», который, будучи запущенным при определённых условиях, выполнит полную установку и настройку твоего софта и голой ОС. Но ты должен понимать, как, что и почему работает именно так, а не иначе. Я сторонник партии качества в продакшене, а не скорости и удобства. Все эти инструменты: образы ОС с предустановленным софтом, виртуальные машины, контейнеры сделаны для удобства и скорости, но нигде не было сказано, что надо делать на пофиг, лишь бы работало.
Хотя я сам с этого докера порой в шоке, но заступлюсь за программистов.
База в докере, хотя данные не должны лежать в контейнере, что ясно написано в мануалах.
Тома и точки монтирования в докере задаются не изнутри контейнера, а снаружи; и задать их — задача не программиста, а админа, ведь администрирование серверов в должностные обязанности программиста обычно не входит.
Бэкапы? Не, не слышали. А чо? Работает же.
А их точно программист должен настраивать и проверять?
А где логи? Как нет? Логи — часть контейнера и при пуше оного они перезаписываются? Вот это да!
А это уже косяк архитектора, который не предусмотрел как эти самые логи будут собираться и храниться. И я не вижу, как программист может эту ситуацию взять и исправить. Фактически, он и так сделал что мог — логи пишутся и кое-как доступны.
Описанные мной проблемы не являются проблемами только на продакшене и говорят об общей культурке программирования, коей не так, чтобы много. Логи в текущую папку класть, пароли и пути хардкодить, экспорт делать куда попало — на тёмную сторону дорога ведёт эта, где Докер в конце.
Нет никакого архитектора или сисадмина.
Ну а докер-то тут в чём виноват?
Если никто не проверяет, что уехало в продакшен в Докере, если никто не довёл до программиста, что можно, а что нельзя делать в докерфайлах, то явно проблема не в программисте, а в отсутствующих процессах поддержки жизненного цикла приложений в компании. Нет корпоративных стандартов хотя бы разработки — глупо пенять на их несоблюдение.
Нет корпоративных стандартов хотя бы разработки — глупо пенять на их несоблюдение.
корп стандарты не спасают. По многим причинам. Начиная от того, что "что русскому полезно, то немцы — смерть". Очень сложно все под одну гребенку сделать, да и попросту не нужно. Хороший стандарт — это баланс между унификацией и вариативностью
Нет никакого архитектора или сисадмина. Что программиста нафигачил в Докер, то и уехало в продакш.Знаю нескольких таких программистов. Без умиления на их Dockerfile смотреть сложно. На вопросы, а какого хрена вообще в него полез, более менее общие ответы: сейчас модно и актуально, но самое главное — строки в резюме про докер позволяют повысить планку ЗП или претендовать на более высокую должность.
Даже то, как Докер хранит свои логи, уже указывает на то, что делался он без соблюдения хоть каких-то стандартов, потому что логи должны лежать в /var/log/, а не в рандомном месте ОС.
Most logs must be written to this directory or an appropriate subdirectory. — вы про этот стандарт? А он вообще официально принят?
вопрос в том как эти логи рассматривать. Если как логи приложений — да, они должны улетать в /var/log/, но если их рассматривать именно как персональные данные самого докер-демона, то можно оправдать их нахождение в /var/lib/docker...
Потому что вы потом pid'ы будете в логи класть, временные файлы писать куда попало, сокеты у вас будут 777, конфиги с паролями 644, а кончится половым секасом несоврешеннолетних ребятушек и прочих представителей флоры и фауны. Не надо так. Это очень bad practice, даже если он сейчас работает.
я сам хотел ссылку на en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard дать )))
Приходится запоминать, что где лежит, вместо того, что бы просто набрать /var/log/docker, и всё
еще раз — это так не работает в случае докера ) Потому что докер-логи — это не логи приложений в том виде, в котором Вы хотели бы их получить. Это некий полуфабрикат — что контейнер в stdout насерил, то и получили (причем еще и в json формате). И это запросто может быть что угодно, а не логи приложения в контейнере.
В целом, если не нравится подход логера в докере (класть в /var/lib/docker) — включайте journald логирование и получайте логи в системном journald… Делов-то
Программист же не знает, что логи могут быть гигантскими, и их надо ротировать несколько раз в день, но при этом сохранять. А потом у вас резко заканчивается место на диске, и хрен поймёшь, при нерабочем шеле, где именно засралось. И поди, ищи вот это всё по файловой системе. И вот Докер весь из такой хрени состоит.
И вот Докер весь из такой хрени состоит.
ну, э, да :-) Как бы вся настоящая статья про это.
Я бы предпочёл, что бы демон был нормальным из коробки, без дополнительных настроек там, где в этом нет необходимости
Ваши предложения? Есть логи самого докер демона (с ними все ок) и есть логи самих контейнеров.
Вот почему другие демоны пишут, как нормальные люди, можно даже прямо в корень /var/log, это ещё лучше, потому что они ротироваться будут автоматически.
ну, да, конечно… В частности, всякие nginx, exim и прочее… Может лучше в journald слать все-таки? А ротация — это конфигурационный параметр. Кому нужно хранить логи за последние пять дней, кому по размеру… Сложно там все, включая truncate файла логов, чтобы логи не терялись — сколько приложений — столько пресетов.
Программист же не знает, что логи могут быть гигантскими, и их надо ротировать несколько раз в день, но при этом сохранять
лучше чтоб знал. Весь DevOps подход про это — "you built it — you run it"
А потом у вас резко заканчивается место на диске, и хрен поймёшь, при нерабочем шеле, где именно засралось
отсутствие места шелл не ломает. Как правило.
Ни одного. Я просто вайню и хейчу. Даже думать про Докер не хочу. Ни секунды своего времени не потрачу. Буду скакать три дня, чтобы рассказать, на сколько он мне безразличен.
>> А ротация — это конфигурационный параметр.
Речь про настройки по-умолчанию. Обычно, их хватает, даже для nginx. Если нет, можно в дистрибутиве демона докладывать настройки для logrotate. Если вас интересует результат. (с)
>> лучше чтоб знал. Весь DevOps подход про это — «you built it — you run it»
В мире розовых пони и свободного Навального — да. Программист сам пишет скрипт установки, кладёт в git шаблон конфига для своего софта и всех других конфигов для зависимостей, а девопс это реализует в виде CI/CD. Но если есть Докер, то об этом вообще не надо думать. С одной стороны, хорошо, с другой стороны, продукт неюзабельный вообще вне докера.
>> отсутствие места шелл не ломает. Как правило.
Вам или повезло, или вы не сталкивались с ситуацией, когда шела приходится минутами ждать, а там не только место кончилось, но и память вся вышла, и процессоры все поедены.
Программист сам пишет скрипт установки, кладёт в git шаблон конфига для своего софта и всех других конфигов для зависимостей
Dockerfile и есть скрипт установки на "голую" машину :)
штатном Докере я про него ничего не слышал.
она (концепция эта) там не нужна. Нужно — можно образы тем же ansible/chef/salt собирать.
Если только не обновлять само содержимое контейнера в бою.
это вообще антипаттерн. Контейнер — это типичный пример immutable инфраструктуры.
Шаблонизатор там есть на уровне envsubst, но я неправильно, видимо понял вашу мысль про шаблоны конфигов: я понял как шаблон для девопса, а не как готовый шаблон для его инструментов. То есть вы предлагаете, чтобы вместо докерфайлов и ко разработчики писали роли и плэйбуки для своих приложений, а девопсы будут их накатывать в пайплайнах? Результат может оказаться ещё хуже (
Всю эту красоту можно собрать в контейнер, но при прочих равных, это просто для удобства, не более того. Проект из-за того, что от распространяется в контейнере, не должен быть собран на пофиг, лишь бы хоть как-то работал. В этом проблема докера в моём понимании. И зачастую этот фундаментальный недостаток перекрывает все достоинства.
Типичный пример: у вас в проекте периодически запускаются процессы (скрипты), которые могут отрабатывать очень долго. В это время вы не можете деплоить, если проект собран в контейнере. Если проект лежит прямо на ОС, то таких проблем не будет. В случае с контейнерами, надо будет делать какие-то велосипеды с запуском скриптов в отдельном контейнере и понеслась. Возможно, есть какие-то способы накатить докер без его остановки и потери работающего в нём скрипта, но что-то мне подсказывает, что нет.
Если проект лежит прямо на ОС, то таких проблем не будет.
Есть проблема. Просто не решение более понятно.
случае с контейнерами, надо будет делать какие-то велосипеды с запуском скриптов в отдельном контейнере и понеслась. Возможно, есть какие-то способы накатить докер
Необязательно в отдельном. Можно и в том же. Но — да, думать надо, как лучше сделать.
В конце-концов основной контейнер может предоставлять API, а во внешнем с планировщиком можете эти ручки дергать… получается лучше, чем в ту же базу напрямую ходить.
Возможно, есть какие-то способы накатить докер без его остановки и потери работающего в нём скрипта, но что-то мне подсказывает, что нет.
Несомненно, что любая инфраструктура накладывает определенные ограничения на софт, который под не разрабатывается. Докер — не исключение. И это не является проблемой.
Для меня проект, это чистый код + настройка кода + данные. Т.е. я должен иметь возможность с полного нуля развернуть проект и понимать, что для этого необходимо.
Так точно
При прочих равных, если в процессе обновления проекта не изменяется то, что использует скрипт, и если сам скрипт не выполняется в рамках перманентно запущенного проекта, то проблем нет. В случае с докером так не проканает и надо делать велосипеды. И будьте уверены, каждый сделает свой.
>> В конце-концов основной контейнер может предоставлять API…
Ой-ёй… Начинается наворачивание неоправданной сложности.
>> Докер — не исключение. И это не является проблемой.
У меня нет проблем с докером, как инструментом. Я вижу проблемы более высокого уровня, к которым приводит использование докера. Программисты итак не хотят и/или не могут выходить за рамки текущей компетенции и знать хоть что-то рядом со своей областью, вплоть до неумения толком войти по ssh или понимания каких-то внутренних процессов в ОС. А использование докера с наляпанной сборкой, работающей абы как, прямиком из разработки в продакшене при таком подходе приводит к печальным последствиям по надёжности, производительности и далее по списку. Это наглядное воплощение мемов «хуяк-хуяк и в продакшн» и «из говна и палок». Именно из-за этого я не люблю докер. То, что он мне не нравится, как ПО, это вопрос личных предпочтений. Хотя, наверное имеет смысл научиться собирать в нём прототипы. Хотя, как показывает опыт, наличие перманентно торчащего в интернет сервера для разработки, решает все проблемы с демонстрацией (если есть интернет).
У меня нет проблем с докером, как инструментом. Я вижу проблемы более высокого уровня,… Хотя, как показывает опыт, наличие перманентно торчащего в интернет сервера для разработки, решает все проблемы с демонстрацией (если есть интернет).
с этим не могу не согласиться.
При прочих равных, если в процессе обновления проекта не изменяется то, что использует скрипт, и если сам скрипт не выполняется в рамках перманентно запущенного проекта, то проблем нет. В случае с докером так не проканает и надо делать велосипеды. И будьте уверены, каждый сделает свой.
т.е. опять же — должны быть нормальная архитектура проекта и нормально построенные процессы вне его и внутри него.
Так докерфайл и ко и является таким шаблоном, нет? И тут два варианта: или этот девопс-инженер контролирует что делают разработчики в плане инфраструктуры для развертывания и всё будет хорошо, или не контролирует и всё будет плохо — хоть образы докера, хоть деб-пакеты, хоть баш-скрипты, хоть плэйбуки без знаний инфраструктуры хороши не будут.
Вам или повезло, или вы не сталкивались с ситуацией, когда шела приходится минутами ждать, а там не только место кончилось, но и память вся вышла, и процессоры все поедены.
Нууу… Такие-то штуки, в не зависимости от наличия или отсутствия докера, лечатся мониторингом и алертингом, которые срабатывают задолго до того как всё станет совсем плохо. А то и вообще правильной настройкой cgroups / OOM и вот этого вот всего.
Проблема докера и всех этих новомодных трендов в том, что средний программист становится ещё тупее и ещё ленивее.Это что!!! Вон некоторые жильцы на второй этаж лифтом ездят [/sarcasm].
Это ни разу не проблема ни системы контейнеризации, ни всех этих новомодных трендов. Потому что это всего лишь инструменты и они никак не виноваты, что ими саморезы в бордюр (для коллег из Питера — в поребрик) забивают. Знаю компанию, где твёрдо уверены, что контейнеры это такие легковесные виртуальные машины. Поэтому запускают в них сразу вэб-сервер, сервер приложений и сервер баз данных. Там entrypoint.sh просто загляденье. Да, они не дураки и щи не лаптями хлебают, поэтому данные базы примонтированы как volume. В другой компании от тех-лида до последнего программиста уверены, что раз приложение в контейнере, значит это и есть микросервис. Возражения и объяснения не принимаются. В третьей компании с какого-то перепугу решили поменять полностью git flow за месяц до релиза. И потом ещё две недели одни объясняли другим какой flow правильный, как его готовить, и куда деплоить потерянные ветки.
Это отчаянные попытки не разбираться в том, как что работает, а максимально быстро сделать так, чтобы твой прототип заработал.Довольно распространённый подход на некоторых «галерах». Поэтому появившихся оттуда специалистов надо на первое время поселять в карантин, чтобы не разносили заразу.
но когда дело касается продакшена, тут в моём понимании, без вариантов вообще.Если это бизнес полностью устраивает, а иначе бы это не допускалось, то не стоит никого осуждать.
Исповедь docker хейтера