Comments 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 хейтера