Я должен признаться. Я ненавижу docker. Всей своей душой. Это самая ужасная софтина, которую я видел за последние 10 лет.
С одной стороны, я очень уважаю одноименную компанию. Ребята из Docker Inc. реально популяризировали контейнеризацию. Теперь о ней не знает только ленивый. С другой стороны, ничего принципиально нового они не изобрели — контейнеризация на момент, когда Docker "выстрелил", уже существовала более 30 лет (начиная от chroot, вспомним еще jails и zones, ну, и наконец-то — namespaces & cgroups).
Круто, что docker реально ускоряет разработку во множество раз. Если вести ее правильно, то даже без потери в качестве. В любом случае, docker здесь, от него не деться и приходится им пользоваться.
Но почему у меня этот продукт с логотипом кита вызывает столь разнообразные эмоции? Ниже я перечислю те моменты, от которых бомбит. Возможно, что читатель будет не согласен или, напротив, найдет какие-то вещи, о которых не знал и сочтет интересными.
Disclaimer: все написанное ниже является личным мнением автора и может как отражать реальность, так и не отражать реальность. Материал строго провокационного характера и основной целью является не унизить или обидеть кого бы то ни было, а скорее заставить людей включить голову и осознать масштабы глубин (с).
docker и файрволл
При создании контейнеров в бриджованных сетях, docker добавляет свои правила файрволла на системе. Это приводит к очень интересным эффектам. Во-первых, просто так становится невозможно сбросить цепочки netfilter (такое может происходить при повторном применении своих правил), т.к. после этого нарушается работоспособность docker-контейнеров и приходится docker-демон перезапускать. Также теряется смысл в утилитах iptables-save/restore, т.к. фактически они сохраняют правила, но не те, которые нужно — приходится фильтровать их вывод. Еще очень интересная задача совместить docker и что-либо, что пытается самостоятельно управлять файрволлом — будь то VPN-клиент/сервер или система управления конфигурацией, которая зорко следит за тем, чтобы правила соответствовали тому, что описал администратор системы.
До последней поры вообще не существовало способа надежно и повторяемо регулировать через файрволл сетевой доступ к контейнеру, но разработчики добавили отдельную цепочку DOCKER-USER, но, честно говоря, толку от нее нет.
А чего стоит возможность получить интересный баг: контейнер с внешних узлов доступен, а с самого хоста, где он расположен — нет. Оказывается, в цепочке INPUT порт контейнера запрещен и по умолчанию не открывается, а внешнее взаимодействие идет через таблицу NAT (такое поведение наблюдается на CentOS при публикации портов через docker run ... -p XX:YY)
Решение, кстати, простое, но довольно муторное — вообще отобрать у docker-демона возможность вносить изменения в правила файрволла, правда, при этом приходится все необходимые правила создавать руками или через систему управления конфигурацией. Правда, это напоминает закат солнца вручную, т.к. сразу же улетучивается удобство и кажущаяся простота docker'а.
docker и сети
По умолчанию docker-демон создает docker-bridge docker0, на который садятся контейнеры, если при их создании не была указана какая-либо другая сеть. При этом (неожиданность!) в этой сети не работает внутренний DNS докера. Он для контейнеров работает только при создании кастомных сетей (через docker network create или через docker-compose). Так вот. По умолчанию докер бридж создается на адресах из подсети 172.16.0.0/12. Фактически это означает, что если мудрые администраторы корпоративной сети организовали ее на той же подсети, то можно ловить очень странные проблемы с доступностью узлов. И долго гадать — что же является причиной этих проблем. Самое печальное, что даже если bip перевесить, то docker-compose игнорирует эту настройку, т.к. сети в нем как будто захардкожены.
При прочих равных рекомендую не пользоваться пробросом портов через -p или --publish, а использовать режим network host mode — получите производительность сети на 5% процентов больше, а по безопасности… Ее и так в докере нет :-) Производительность бриджованной сети ниже из-за того, что docker активно вторгается в настройку файрволла и использует механизмы NAT.
docker — это не про совместимость
Действительно, зачем соблюдать совместимость и придумывать пути миграции для пользователей, если можно этого не делать? Я с этим столкнулся два раза. Первый — когда был старый "добрый" драйвер aufs, но пришлось переходить на overlay2, т.к. последний работает в разы лучше. Так вот — напрямую это сделать нельзя. Только через полную потерю всех volume и image, которые созданы в хост-системе со старым драйвером. Сейчас эта проблема уже практически потеряла актуальность, потому что большинство систем по умолчанию идут уже с overlay2 драйвером. Проверить можно через вывод docker info команды.
Вторая ситуация — ВНЕЗАПНО! образы созданные более свежей версией докер-демона могут не работать на более старых докер-демонах. В обратную сторону (образы от более старой версии докера на более новой) — работает все прекрасно. Это может выстрелить, если имеется достаточно большой парк различных серверов с разношерстной версией докер-демона.
docker hub — это помойка
Docker Inc. для поддержки экосистемы докера разработали первый и самый всеобъемлющий каталог образов для докера — Docker Hub. На нем можно найти как официальные образы, так и любительские. Можно хостить как публичные образа, так и приватные (требуются учетные данные для доступа к ним). Вроде все здорово, не так ли? По факту получается, что большинство любительских образов не поддерживаются, собраны кое-как и имеют уязвимости. Чего уж говорить — если даже официальные образы зачастую запускаются под root'ом и это поведение не изменить. Еще никто никогда не гарантирует, что образ, который сейчас присутствует в хабе будет там завтра. Более того — даже то, что у него есть тег совершенно не означает, что под ним завтра будет такой же образ.
Еще возможность все легко упаковать в образ отшибает у программистов желание думать — как оптимизировать код. Коллеги просто берут и в образ запихивают все подряд, не разбираясь — нужен ли этот модуль или нет. В принципе, это уменьшает количество хлама в хост-системе (а раз так, то и увеличивает стабильность ее работы). С другой стороны — переместив бардак из точки А в точку Б, мы его не уменьшаем. Если смотреть на докеры с этой стороны — они действительно хороши для изоляции интерпретируемых языков с не очень вменяемыми пакетными менеджерам — python, ruby, node.js. Для компилируемых языков вроде golang или виртуальных машин вроде java — паковка в контейнер докера выглядит избыточной.
Какая может быть рекомендация? А простая — любой образ, который используется в проект — по возможности — собирать самостоятельно и класть в свой собственный registry для докер-образов. Стараться собирать минимальный комплект в ПО в контейнере (это и уменьшает поверхность атаки, и сложность поддержки образа, а еще чем меньше образ, тем быстрее он скачивается на хост ноду, что критично для оркестраторов вроде k8s).
Путаница с терминами и с ключами командной строки
registry vs repository, bind mount vs volume (оба могу быть созданы через docker run ... -v, хотя по факту это разные сущности), tag vs image name, EXPOSE vs expose vs ports, различные типы volumes (анонимные, именованные...). И пр. В принципе, это понятно, т.к. продукт достаточно свежий и терминология в принципе не могла успеть устояться. Я уж не говорю про то, что лучше все всегда смотреть в оригинальном написании, т.к. наши переводчики умудряются перевести так, что изначальный смысл ускользает.
Порядок запуска
Надо уяснить — docker не решает проблему порядка запуска контейнеров. Никак. От слова совсем. Он это не умеет и точка. Для этого используйте внешние средства. Начиная от systemd unit'ов (предпочтительно, но нужно их аккуратно писать — возможно как-нибудь напишу статью по этой теме), кончая портянками на bash.
Да, стоит упомянуть docker-compose. Внезапно, но он тоже НЕ решает эту проблему. Директива depends_on, которая вроде как за это отвечает — бесполезна, т.к. по факту она действительно позволяет в моменте (при выполнении команды docker-compose up) запустить контейнеры последовательно, но тут куча нюансов. Начиная от того, что она по умолчанию не ждет готовности контейнера (это реализовано только в формате 2.4 docker-compose).
Форматы docker-compose
Утилита docker-compose принимает файл описания контейнеров в двух разных конкурирующих между собой форматах — версий 2.* и 3.*. Понятно почему так произошло. Формат версии 3.* затачивался под docker swarm и в этой системе оркестрации в принципе часть возможностей не работает. Для начинающих наличие двух форматов вносит ненужную путаницу.
Установка
Есть 100500 способов установки docker и docker-compose. Я столкнулся с кучей различных проблем. Начиная с того, что какие-то умные люди в Убунту сделали пакет docker, который к Docker Inc. не имеет никакого отношения. В результате "правильный" пакет имеет название docker.io или docker-ce. Ну, и, конечно, его лучше устанавливать по официальной инструкции с оф. сайта Docker
Еще хочу добавить, что самые интересные спецэффекты я наблюдал, когда разработчик устанавливал docker в Ubuntu через snap. Как будто какие-то рандомные фичи переставали работать. Сейчас уже не вспомню. Но все проблемы снимало рукой, когда переустанавливали docker по официальной инструкции пакетным менеджером.
docker-compose — если его ставить из репозиториев операционной системы или через пакеты pip — это гарантированный способ навлечь проблем себе на голову. Во-первых, в этом случае docker-compose приносит с собой в систему лишние пакеты и получаются интересные эффекты вроде такого (вариант для Убунты). Во-вторых, если случайно сломается python окружение (внезапно! такое тоже бывает), то docker-compose тоже перестанет работать (например, я влетал в такое — это не проблема компоуза, конечно, но на нем тоже отразилось бы). Поэтому — верный способ ставить компоуз — по инструкции с оф. сайта единым бинарником (если есть сомнения в его целостности — проверяйте md5sum).
docker и безопасность
В слове docker нет буквы Б — это все, что нужно знать про безопасность. Действительно, docker проектировался по типичным канонам agile-методологии в ее худшем сценарии: фичи важнее всего остального. Результат таков, что в архитектуре докера безопасности нет. Первый момент — пользователь, который имеет доступ к докер-демону ЭФФЕКТИВНО имеет root права на хост системе. Например, легко получить доступ ко всей файловой системе:
docker run --rm -it -v /:/rootfs ubuntu bash
Понятно, что разделения контейнеров между различными пользователи на одной системе тоже нет. Каждый видит все контейнеры, запущенные на хосте. Это можно обойти запуском нескольких демонов на одном хосте (пример), но это жуткий костыль и по факту безопасность он не увеличивает.
Еще очень неприятный момент, что все файлы, которые создаются в bind mount (проброс каталога в докер-контейнер), имеют права пользователя внутри контейнера. Пользователи зачастую таким образом разделяют файлы между хост машиной, на которой происходит процесс разработки, и докер контейнером, чтобы лишний раз не пересобирать образ, а измененный код подгружается hot reload'ом или перезапуском контейнера. Причем, что интересно — корневой каталог bind mount при его создании через директиву docker run ... -v ... имеет владельца root независимо от фактического пользователя внутри контейера. Если же использовать расширенный синтаксис bind mount (docker run ... --mount ...), то каталог, в который идет монтирование не создается и ему можно задать любые права. Продуманный дизайн? Не, не слышал :-) Здесь могу сказать одно — используйте настоящие volume (которые хранятся по умолчанию в /var/lib/docker/volumes
Не стоит забывать, что есть возможность убежать из песочницы docker и не стоит запускать на своей машине произвольно выбранные образы. Действительно, можно наткнуться на образ, эксплуатирующий CVEшку и скомпрометировать свою систему.
docker и не-Линукс
До сих пор не научился нативно не в linux-kind операционных системах. Это и логично, т.к. docker очень глубоко завязан на механизмы namespaces и cgroups ядра Линукс. Что это означает на практике? А то, что пользователи Mac и Windows имеют возможность работать с docker через Docker Desktop или аналогичное решение, но постоянно возникают вопросы с пробросом volume и скоростью работы приложений (это логично, т.к. задействуется полноценная виртуализация). Но лучше уж так, чем никак.
docker и изоляция
Докер не обеспечивает 100% изоляцию ресурсов между контейнерами. Это может приводить к конкуренции за iops, кэши процессора и пр. и, как следствие, — меньшему быстродействию, чем на выделенных инстансах. Так же есть целая плеяда ресурсов ядра, которые не учитываются при создании контейнеров, и не являются предметом для квотирования. Самый последний вопиющий случай — с dentry
docker и логирование
По умолчанию docker использует json-file драйвер. Он складывает логи от приложения в /var/lib/containers/<hash>/<hash>-json.log При этом их размер может расти бесконтрольно. В теории можно задать максимальный размер и параметры ротации, но кто это делает? Только честно. И к тому же все равно эти параметры "на лету" не изменишь
Есть второй драйвер — journald, который тоже поддерживает команду docker logs (удобно же смотреть логи командой!?). Все остальные драйвера — эту команду не поддерживают, разве что только в Docker-EE, но сколько реальных пользователей энтерпрайз версии вы видели?
Дополнительный вопрос — что если докер не будет успевать перемалывать логи от приложения? Оно блокируется на выводе. С этим, к сожалению, ничего не поделаешь толком.
docker и альтернативы
Сейчас получается интересная ситуация. В принципе, docker становится не нужен. Ранее и сейчас были прекрасные, но незаслуженно неизвестные альтернативы вроде systemd-nspawn. Есть еще очень нехорошая тенденция у разработчиков тащить многосервисные комплексы ПО в докер и использовать его виртуальную машину — это тем более странно, что есть прекрасные Vagrant, VirtualBox и lxc/lxd, если нужны легковесные виртуалки. Еще docker становится лишней прослойкой, если мы говорим про kubernetes — последний ведь умеет уже напрямую работать с containerd, причем даже производительнее.
Прочее
Можно припомнить еще очень многое: и отсутствие нормальной шаблонизации в docker-compose — мы ведь YAML якоря и возможность склейки docker-compose-файлов за таковую не считаем? Практически мертвое состояние docker swarm (kubernetes почти съел его живьем) — эту тему развивать можно вечно. Что интересно в Docker Inc. знают обо всем этом (стоит только посмотреть на ишью трекер), только ничего особо не делают (*) либо потому что не хотят, либо потому что не могут. Да в принципе уже и не нужно.
The END
Какой итог можно подвести? На самом деле если отбросить все предрассудки — docker — это инструмент. Чтобы им эффективно пользоваться, нужен опыт работы с ним и знание подводных камней. Часть из них перечислена в настоящей статье. Так же docker — это инструмент для управления контейнерами первого поколения. Сейчас идет активная разработка альтернативных средств, например, cri-o/podman/buildah, которые нацелены на большую безопасность и удобство эксплуатации. Появляются средства вроде FireCracker, которые наследуют лучшие черты и от контейнеров (легковесность и скорость запуска) и лучшие черты от больших ВМ (возможность работы на разных ядрах и полноценную изоляцию).
Развитие технологий не стоит на месте и я надеюсь, что разработчики нового учтут недоработки текущий решений и мы получим новые хорошие инструменты для решених наших задач.
(*) — разработчики завезли шаблонизацию через docker-template, multi-stage сборки в docker build, buildkit как более новый и удобный способ сборки и многое другое, но это общей картины все равно не меняет — все эти фичи достаточно сырые и непродуманные.
Комментарии (364)
dzsysop
16.09.2019 21:56+5Критика, мне кажется, обоснована. Но каковы альтернативы?
Мы живем в такую эпоху, кто первый тот срывает банк.
Кто успел захватить рынок или нишу будет иметь время и ресурсы потом довести продукт до ума или будет сметен очередной волной.
На данный момент со всеми костылями и недостатками Docker остается практически безальтернативным лидером в быстрой и удобной виртуализации как при разработке так и при развертывании решений в цепочках CI/CD и деплое.
Во всяком случае я не вижу серьезных конкурентов.
Рынок и время все расставит по местам.
13werwolf13
17.09.2019 08:39+1на самом деле в том же lxc можно делать абсолютно всё тоже самое, и да неизменяемый и да всё остальное… просто требуется чуть больше телодвижений. но народ ленив.
VolCh
17.09.2019 09:09+1Может не ленив, а рационален? :)
13werwolf13
17.09.2019 09:13-1использовать докер и называть это рациональностью это как те псевдобизнесмены которые пытаясь сэкономить покупают дешёвое гавнооборудование которое сдыхает на следующий день и не тянет возложенные задачи и в итоге тратят больше?
VolCh
17.09.2019 09:25Нет, не так. Просто нужно ставить задачи, которые докер способен эффективно (как плане человеко-часов, так и в плане вычресурсов) решить. Я вот сейчас понятия не имею есть ли вообще докер на нодах нашего кластера, главное что он разворачивает образы с помощью докера построенные. Попробовал несколько других тулс для билдинга стандартных образов — уступают, как минимум в поддержке Dockerfiles.
kvaps
17.09.2019 12:32посмотрите на podman
dzsysop
17.09.2019 15:38Мне кажется Podman это альтернатива не докеру а скорее конкурент К8?
PS: для продакшн — рискованно брать недостаточно обкатанное решение. Специально сходил проверил первая альфа вышла чуть более года назад podman.io/releases/2018/06/04/podman-alpha-v0.6.1.html. Для боевых систем всегда выбирается стэк проверенный временем. Как я уже сказал в первом комменте, возможно со временем что-то вытеснит докер с его сегодняшних позиций. Podman выглфдит неплохо, но надо подождать когда первая волна энтузиастов его доведет до ума и докажет его превосходства и эффективность. Например, у меня нет времени на тестирование подобных альтернатив. Меня докер устраивает для моих небольших задач. И большая часть успеха кроется в огромном количестве доступной информации и примеров. Podman и поэтому я не уверен как скоро я начну (если вообще когда-нибудь начну) его использовать и/или тестировать. Се ля ви.
dominigato
17.09.2019 15:43Не, как раз Podman это альтернатива докеру. Podman и k8s соотносятся как docker и docker swarm.
kvaps
17.09.2019 15:44Это именно альтернатива докеру и есть, т.е. он предоставляет пользователю знакомый интерфейс для запуска контейнеров в cri-o. В kubernetes тоже есть нативная поддержка cri-o
lair
17.09.2019 16:00на самом деле в том же lxc можно делать абсолютно всё тоже самое
"Э — экосистема".
Можно "в том же lxc" на винде собрать образ, который залить в AWS SageMaker в качестве кастомного training algorithm?
gecube Автор
17.09.2019 16:10Я так понял, что SageMaker сделан поверх EC2. И причем тут докер? Или, пожалуйста, разверните свою мысль.
lair
17.09.2019 16:29Я так понял, что SageMaker сделан поверх EC2. И причем тут докер?
Докер при том, что это штатный способ задания алгоритмов в SageMaker — через указание образа в ECR. Так что скорее вопрос "при чем тут EC2".
river-fall
17.09.2019 13:04Да, тут как с демократией. Она — худший способ управления государством, за исключением всех других способов, которые ещё хуже.
gecube Автор
17.09.2019 13:06Почему? Та же автократия хорошо работает. Эффективно. Только вот цена достаточно высока. И все хорошо, пока цели конкретного индивидуума совпадают с глобальными целями (хотя так везде)...
dominigato
17.09.2019 14:25podman и buildah например. Чем не достойные конкуренты? Podman еще и поддерживает rootless контейнеры, для половины задач их хватает, +1 к безопасности. Не надо устанавливать никакой сервис и заморачиваться его статусом. docker-compose заменить podman-pod. Как-то собирался написать свой podman-compose (существующий на гитхабе не работает) чтобы можно было запускать podman pod с существующим конфигом от docker-compose.
К тому же не надо особо учить новый интерфейс, так как podman почти один в один повторяет функции докера. Просто «s/docker/podman/» и скорее всего все будет работать как обычно.
Вот только с нетворкингом не так удобно, так как нет команды «podman network» и приходится конфигурить CNI сети скриптами. Но тоже очень просто, обычный JSON или YAML.
Я думаю для большинства задач для разработчика podman вполне заменяет docker. А на серверах все равно будет kubernetes какой-нибудь.VolCh
17.09.2019 15:37Я не нашёл упоминаний может ли он работать с удалёнными машинами. Ну и "конфигурить CNI сети скриптами" я не очень даже понимаю что значит — эти виртуальные сети, в которых docker-compose резолвит сервисі?
dominigato
17.09.2019 15:56CNI сети это как docker networks, только для podman. Есть всякие cnitool, но я предпочитаю напрямую изменять конфиг файлы в /etc/cni/net.d скриптами.
С удаленными машинами работает через varlink interface.
MainNika
16.09.2019 22:03+5т.к. сети в нем как будто захардкожены.
да github.com/docker/libnetwork/blob/master/ipamutils/utils.go#L10nicestep
17.09.2019 10:06Да, но есть возможность указать нужные сети через конфигурационный файл. См. default-address-pools и github.com
gecube Автор
17.09.2019 10:06Спасибо. Ждал этого коммента ) Действительно впилили эту фичу. Спустя… Очень долгое время.
fearan
16.09.2019 22:10+5Автор не в полной мере осознает масштаб проблем.
Однажды меня попросили "быстренько посмотреть один из серверов, туда что-то докер не встаёт. Надо поставить, и нужно через пару часов уже раскатать там микросервисный проект — ведь докер ровно для этого и сделан, чтобы легко разворачивать весь ворох сервисов с нуля".
На хосте оказался e2kjustboris
17.09.2019 10:56+1Для общего развития, а что такое e2k? Гугл ничего подходящего по теме не находит
eumorozov
17.09.2019 11:49У меня целых три предположения:
- до появления BitTorrent было пиринговое приложение для пиратства музыки и фильмов, которое называлось eDonkey. Кажется какая-то разновидность то ли приложения, то ли протокола, называлась e2k.
- Эльбрус 2000, как уже отписались
- Возможно какая-то разновидность Ethernet-карты?
Но вообще, уж слишком таинственный комментарий.
Rober
16.09.2019 22:32+6Пожалуй, самая полезная статья про Docker, которая когда-либо была написана. Спасибо.
Эх, прочти я такое пару лет назад — избежал бы всех вышеописанных граблей Docker и сэкономил бы массу времени.vladshulkevich
17.09.2019 10:22А как? костылили бы Докер, или заменили бы на что-то вменяемое?
gecube Автор
17.09.2019 10:25Действительно, интересный вопрос. Т.к. коллеги умудряются использовать кубернетес оставляя от него только по сути scheduler (сеть плоская как в букинге, поды прибиты руками к нодам, вся персистенция через host volume etc.). И оно даже как-то работает :-o :-o :-o Правда, ценность такого решения не очень понятна (разве что разработчикам удобно YAML писать....)
Rober
17.09.2019 11:28Да, сначала придумывал костыли. Комбинировал сети и старательно составлял докерфайлы, чтобы внутри каждого контейнера был свой пользователь, прописывал права на хостовой машине, упорно дорабатывая то, что создатели докера не додумались автоматизировать.
Потом розовые очки спали, я перестал пихать квадратный объект в круглое отверстие и осознал, что для моих крайне скромных задач хватает комбинации chroot, virtualbox и отдельно поднятых VPS, благо у многих хостеров есть для этого API и можно автоматизировать их создание и настройку. Docker по-прежнему использую, чтобы быстро что-нибудь проверить или воспользоваться какой-нибудь софтиной, не мусоря в системе, но в основном предпочитаю поднимать отдельные виртуальные машины. Кубернетес для меня — что микроскоп для забивания гвоздей, не те масштабы, поэтому более примитивных и устаревших средств хватает с избытком.gecube Автор
17.09.2019 11:48Очередная иллюстрация на темы
- "кубернетис не нужин" (с) (по крайней мере не для всех)
- "подбирайте инструменты по задачам" (не наоборот)
- "преждевременная оптимизация — зло"
Без издевки — очень понимаю, мои апплодисменты. Все правильно говорите.
vladshulkevich
17.09.2019 21:04+1так да! я за это и топил. но «модно стильно молодежно» это ж… сами понимаете, модно, стильно и молодежно
Lucio
16.09.2019 22:41+2Практически все перечисленные проблемы решает Openshift или любой другой полноценный оркестратор.
gecube Автор
16.09.2019 22:44+4Не всегда допустимо тащить оркестратор. Ну, например, зачем мне оркестратор, если есть один, два или три узла с докером?
Вообще я столкнулся с тем, что вся эта оркестрация именно в реализации кубернетеса достаточно жручая штука и оправдана либо на масштабе, либо если есть особые требования (например, отказоустойчивость, или разработчики хотят отлаживаться и писать YAML манифесты для обеспечения идентичности промышленной или разработческой сред)
norguhtar
17.09.2019 08:24+1Практически все проблемы решает замена на lxc/lxd Там даже сеть нормальную завезли и ей удобно управлять.
kvaps
17.09.2019 12:35Докер и LXC — это всего-лишь два инструмента, которые решают две разные задачи
norguhtar
17.09.2019 12:39И тот и тот и контейнеры. То что докер заворачивает приложение внутри себя я в курсе. Проблема начинается когда у вашего приложения требуется запускать более одного процесса. Классический пример nginx + uwsgi сервис. В случае lxc я запущу один контейнер который будет их содержать. В случае же docker мне потребуется два контейнера и надо будет их еще как-то связать. Плюс если сервис захочет что-то хранить надо будет делать отдельный том. Проще говоря количество телодвижений при использовании docker на порядок больше и требуются специальные оркестровщики, где в случае lxc можно обойтись командами.
kvaps
17.09.2019 13:02Это сделано намеренно. Контейнеры в linux в т.ч. и LXC, имеют ряд проблем или особенностей (называйте как хотите). Основная причина в том, что если вы убиваете родительский процесс в контейнере, это не означает, что все дочерние процессы завершились правильно, некоторые из них могут продолжать использовать сетевые интерфейсы и блокировать хранилище, в итоге мы имеем повисший в непонятном состоянии контейнер.
Подход "по процессу на контейнер" позволяет избежать данной проблемы и получить всегда гарантированное состояние. Кроме того это позволяет container engine сделить за каждым процессом отдельно, автоматически собирать логи и метрики с него.
gecube Автор
17.09.2019 13:04+1Подход "по процессу на контейнер" позволяет избежать данной проблемы и получить всегда гарантированное состояние. Кроме того это позволяет container engine сделить за каждым процессом отдельно, автоматически собирать логи и метрики с него.
Зачастую это не работает. Приходится мириться с тем, что процесс внутри контейнера форкается и плодит потомков. Еще хуже — если там разнородные процессы под управлением супервизора. В результате — типовая проблема, что появляются процессы-зомбяки. Решается вроде как засовыванием init в контейнер. Но это костыль. Очередной. Впрочем, неудивительно.
norguhtar
17.09.2019 13:14Про init и дочерние процессы в docker аж целая проблема была. Ее разве побороли?
gecube Автор
17.09.2019 13:20+1Ну, "окончательного решения init вопроса" разработчики не придумали. Есть какие-то разрозненные практики. Начиная от запихивания supervisor (фу), кончая появлением специального --init ключа у docker run.
Да. Еще стоит упомянуть, что коллеги умудрялись с матами и приседаниями запускать полноценный systemd в докере, но вряд ли оно того стоит. Преимущество такого подхода очевидно — ты просто пишешь свой приклад, пишешь юнит файл и оно вместе работает везде — что на выделенной ВМ, что в докере.
norguhtar
17.09.2019 13:25Прекрасно. В итоге на основную идею докера один контейнер, одно приложение положен большой болт. Причем как я понимаю, это вполне частая практика.
Nengchak
18.09.2019 06:07Насколько мне память не изменяет, нигде такого в офф. доке не было написано |
В итоге на основную идею докера один контейнер, одно приложение положен большой болт.
Так что, выдумки все это.norguhtar
18.09.2019 06:25А что же там написано? Мы сделали это просто так? Везде именно так задвигают использование docker
Nengchak
18.09.2019 06:28И что? Я иногда встречал бредовые высказывания, что когда апп умеет в треды и создает потомков, то крику поднимается, что нельзя такое, только один процесс без детей. Я считаю, что если нужно два процесса, так тому и быть.
norguhtar
18.09.2019 06:35Тогда docker должен уметь обрабатывать такое из коробки. И без костылей. Ну и собственно где?
Nengchak
18.09.2019 06:50Какие костыли? один баш скрипт. Ведь один вход на запуск. а этот скрипт может что угодно запускать и как угодно.
norguhtar
18.09.2019 06:54Это и есть костыль. Я обязательно должен с собой тащить дополнительную прокладку. Если вы не понимаете почему это плохо, то посмотрите в скрипты запуска sysvinit и unit файл systemd. Знаете в чем разница? Первый регламентирован весьма условно и он будет разный в разных дистрибутивах. Во втором случае он всегда одинаковый во всех дистрибутивах. Более того разработчик приложения наконец-то может сам сопровождать unit файл.
ne_kotin
18.09.2019 09:24А напрямую запустить нужный процесс не? Обязательно баш-скрипт тащить?
norguhtar
18.09.2019 09:46Тогда дети процесса не умрут :) Фишка в том что идея запустить напрямую процесс, приводит к невозможности завершить процессы детей, если процесс упал через segfault и не отправил им sigterm.
ne_kotin
18.09.2019 10:43Так не надо писать так, чтоб приходилось плодить детей. Нитки же (threads) есть.
Вот и всё.VolCh
18.09.2019 10:59Авторам nginx это объясните, например :)
ne_kotin
18.09.2019 11:11Ну, может Сысоеву принципиально пофиг на докеризацию ) или он не считает init в докере костылем.
Но, имхо fork вместо нитки — само по себе костыль.gecube Автор
18.09.2019 11:17Сысоев только недавно научил свой nginx правильно определять количество ядер, доступных в це-группе.
https://github.com/kubernetes/ingress-nginx/issues/2948
и корневая причина:
https://trac.nginx.org/nginx/ticket/1151
norguhtar
18.09.2019 11:24А докер разве не про облегчение жизни разработчикам? Если да то с чего такие драконовские ограничения.
ne_kotin
18.09.2019 11:34Докер прежде всего про облегчение жизни эксплуатационщикам. Не знаю кто сказал что он жизнь разработчикам облегчает.
Ну т.е. есть унифицированный способ деплоить сетевые приложения без загаживания хостовой системы. Отлично.
Ограничение проистекает из необходимости корректно определять состояние контейнера по состоянию порожденного в нем корневого процесса.
И это вполне разумное ограничение — контейнер под задачу. умерла — убить/перезапустить в соответствии с полиси.
А если вам в контейнере нужен init — вы что-то делаете не так.norguhtar
18.09.2019 11:38Угу он при этом отлично гадит в фаервол хостовой системы. То как там сделана сеть делает меня печальной пандой. Примеры когда это не работает тут уже приводили. Далее может происходить задача умерла, дети не умерли. Убили контейнер в итоге сломали задачу, так-как она по новой не стартует.
VolCh
18.09.2019 15:05Как-то топят за него больше разработчики, чем эксплуатационщики. Унифицированній способ разворачивать сетевые приложения без загаживания своей машины :)
ne_kotin
18.09.2019 09:24А зачем вам 2 процесса?
VolCh
18.09.2019 09:31+1Обычный пример: php-fpm+nginx, которые должны шарить public директорию и второй без первого просто не имеет смысл (по крайней мере в рамках конкретной системы даже для локальной разработки или отладки), неотделим от него.
norguhtar
18.09.2019 09:46Ага и приходим к обычному контейнеру с init системой :)
mayorovp
18.09.2019 10:37+1"Обычный контейнер с init системой" включает в себя tty, ssh-сервер, что-то для управления сетью, что-то для сбора логов...
А тут всего две программы запускаются, помимо самой init системы.
norguhtar
18.09.2019 11:36tty у вас всегда есть. Логи и управление сетью а так же ssh это вообще опциональные вещи.
А тут всего две программы запускаются, помимо самой init системы.
И? Идея докера берем приложение берем окружение запускаем. Когда вот такое как у вас то там нужно настроить супервизор или написать bash скрипт которые это все будут запускать. И да придется добавить логгирование, так-как в стандартный поток может писать только одна программа.mayorovp
18.09.2019 11:42tty у вас всегда есть
Но не всегда на нём висит getty или там login...
И? Идея докера берем приложение берем окружение запускаем
А в чём отличие в случае наличия init?
norguhtar
18.09.2019 11:44Но не всегда на нём висит getty или там login...
Это совершенно не обязательно
А в чём отличие в случае наличия init?
В том что внутри контейнера еще потребуется настроить приложение и дополнительно делать init так чтобы он пробрасывал вывод приложения в докер.
ne_kotin
18.09.2019 10:46Обычный пример: php-fpm+nginx
Ну, раз они плодят детей — значит это плохо докеризуемое решение, и не стОит его докеризовывать.
P.S. Дякую тобi боже що у мене СпрiнгVolCh
18.09.2019 11:00Нут не про детей даже речь, тут про то, что это два разных процесса, которые должны работать исключительно в паре и шарить между собой некоторые файлы.
ne_kotin
18.09.2019 11:12ну, ой. не для докера такая парадигма.
khim
18.09.2019 12:03Ну тогда это просто значит, что докер не нужен вообще никому.
Потому что ситуация, когда у вас два приложения, связанные между собой — это первое, вот совсем самое первое, что появляется, если вы начинаете думать о безопасности (о реальной безопасности, а не рекламной).
Ибо «основное» приложение (которое мы часто меняем и в котором могу быть ошибки) должно быть отделено от логгера (задача которого — меняться редко, быть надёжным, как скала, и обеспечить доставку логов даже после того, как основное приложение скомпроментируют).
Если же вы умеете писать приложения так, что они ошибок не содержат и в защите не нуждаются… нафига тогда вам контейнеризация вообще?ne_kotin
19.09.2019 00:56При чем тут логгеры?
Если у вас два приложения, связанных — вяжете их по сети. Условный веб-сервер в одном контейнере, логгер — в другом, БД — в третьем.
Если вам надо запихнуть в один контейнер больше одного приложения — you doing it wrong. Всё. Точка.
Если вам надо плодить детей форком — you doing it wrong.
Один контейнер — один процесс.VolCh
19.09.2019 09:01Вот интересно, авторы докера в официальной документации указывают на то, что несколько процессов не значит "you doing it wrong", а вы указываете. Вы более компетенты чем они в этом вопросе?
ne_kotin
19.09.2019 11:34Один процесс, который не плодит потомков — он или работает, или упал. Состояние контейнера с ним отследить сильно проще. А перезапуском упавшего контейнера докер занимается сам.
gecube Автор
19.09.2019 11:56Или попал в вечный цикл или блокировку. Процесс есть? Есть. Работает? Ну, вроде как да. Сервис клиенту оказывается? Да фиг там был. Получается, все равно хелсчеками обмазываться.
kvaps
18.09.2019 13:55А в чём проблема запустить php-fpm и nginx в разных контейнерах?
Они всё также могут смотреть в одну директорию и общаться друг с другом через tcp/unix-сокетgecube Автор
18.09.2019 13:58Это первый путь в ад, если php-fpm, например, нужно писать в этот каталог, а nginx читать — опять начнется свистопляска с правами. В принципе, это все решаемо, но это время и усилия на это.
kvaps
18.09.2019 14:34Чем процесс запущенный в Docker отличается от запуска такого же процесса в системе? — ничем. Чтобы не было проблем с правами достаточно запустить контейнеры с одинаковыми uid/gid. Docker это давно умеет.
По факту я бы советовал рассматривать Docker не как альтернативу LXC, а скорее как альтернативу Systemd.
Обе системы запускают и следят за процессами, то что процесс работает в контейнере — в каком-то смысле второстепенно.gecube Автор
18.09.2019 15:01+1Вот Вы думаете, что вот берешь и просто меняешь uid/gid. В том и дело, что нет — иногда это влечет полную перенастройку и пересборку оригинального контейнера, т.к. там в docker-entrypoint всякая дичь и софт, который через пакетный менеджер ставится, не всегда ожидает, что он будет запущен, скажем, не от рута.
Дьявол в деталях, как обычно.
Обе системы запускают и следят за процессами, то что процесс работает в контейнере — в каком-то смысле второстепенно.
Только альтернатива какая-то куцая. Докер умеет перезапускать упавшие контейнеры? Умеет. А вот те, который не упали, но хелсчек failed? Нет. Зависимости между контейнерами есть? Нет, нету. Ну, и сравнения, значит, нет.
kvaps
18.09.2019 15:25в docker-entrypoint всякая дичь и софт, который через пакетный менеджер ставится, не всегда ожидает, что он будет запущен, скажем, не от рута.
Это вообще антипатерн, здесь я с вами согласен. Но это проблема не Docker как системы оркестрации контейнеров, а это проблема образов, которые вы используете.
Возможно я смотрю на Docker со своей башни (Kubernetes) где всё хорошо и не замечаю проблем у простых пользователей, которые просто пытаются использовать готовые образы из Docker Hub'а, простите меня за данное допущение.
gecube Автор
18.09.2019 15:40+1Все ок, извинения приняты. Спасибо за понимание.
Просто действительно — если собирать из готовых блоков (те же пакеты helm), то ± все уже понятно.
А если нужно в кубер закатить что-то, что еще никто не делал, то тут возникают нюансы.
mayorovp
18.09.2019 14:02Проблема в настройке взаимодействия этих самых контейнеров.
Простой контейнер можно при желании запросто запустить в нескольких экземплярах. А вот для двух зависимых контейнеров эти самые зависимости придётся настраивать.
kvaps
18.09.2019 14:24Если честно не знаю как это организованно в docker, но в Kubernetes есть специальная абстракция — Pod, можно сказать это наименьшая единица для запуска workload в кластере. Описать два разных контейнера в одном Pod'е не составляет никакого труда (это всего несколько строк в одном yaml-файле).
Да, работа с Kubernetes ломает привычные принципы и требует определённого уровня сноровки, но научившись "правильно" работать с контейнерами, поверьте, многое становится проще и понятнее.
mayorovp
18.09.2019 14:38Ну, значит в Kubernetes эту проблему решили.
Но не будете же вы ставить Kubernetes каждому разработчику? Значит, для разработки нужен отдельный контейнер, с как можно более простым запуском.
VolCh
18.09.2019 15:15Описать два разных контейнера в одном Pod'е не составляет никакого труда (это всего несколько строк в одном yaml-файле)
Лписать не проблема, проблема чтобы это описание заставило их корректно работать.
VolCh
18.09.2019 09:04https://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.
Всё же написано.
csdoc
18.09.2019 02:02Да. Еще стоит упомянуть, что коллеги умудрялись с матами и приседаниями запускать полноценный systemd в докере, но вряд ли оно того стоит. Преимущество такого подхода очевидно — ты просто пишешь свой приклад, пишешь юнит файл и оно вместе работает везде — что на выделенной ВМ, что в докере.
Кстати, полноценный systemd в podman можно запустить без матов и без приседаний — это штатная возможность: How to run systemd in a container
E_STRICT
17.09.2019 19:59Можно сказать что да.
github.com/Yelp/dumb-init
github.com/krallin/tininorguhtar
17.09.2019 20:12Через init и я умею. А без него? Я как бы намекаю, что сама идея докера внутри только приложение такой оберткой нивелируется.
kvaps
17.09.2019 13:33+1процесс внутри контейнера форкается и плодит потомков
Это не должно быть проблемой, так как в данном случае процесс который форкается как правило без проблем отрабатывает
SIGTERMи мочит всех своих потомков.
Кстати, это один из пунктов 12factor app.
norguhtar
17.09.2019 13:44А по факту у вас случается segfault в родителе и SIGTERM не отправляются :)
norguhtar
17.09.2019 13:14+1Ага теперь мы кладем в docker любой веб сервер или uwsgi сервис и наблюдаем в нем дочерние процессы. Что-то не помогло. Плюс наблюдаем кучу костылей в виде запихивания в docker супервизоров. Проще говоря идея докера благополучно провалилась. При этом если мы возьмем lxc/lxd там сразу из коробки запускается systemd который за все следит и при остановке все гарантировано пристреливает.
kvaps
17.09.2019 13:26+1Ну в Kubernetes эта идея вполне живёт и процветает.
Каждый pod может состоять из нескольких контейнеров работающих в одном сетевом пространстве. Внутри каждого такого контейнера работает отдельный процесс и пишет логи в обычный /dev/stdout и /dev/stderr.
Каждый такой контейнер может быть запущен из отдельного docker image, логи можно посмотреть из любого места:
kubectl logs myapp -c nginx.
Это может быть по началу непривычно, но на мой взгляд, очень удобно.norguhtar
17.09.2019 13:30Угу в итоге Kubernetes через pod реализует один контейнер lxc/lxd и требует своей установки и его изучения. При этом lxc/lxd контейнер kubernetes не требует. Как и не требует совершать дополнительные телодвижения для расшаривания совместных ресурсов.
Единственный плюс тут только наличие интерфейса и упаковки вашего приложения в докер. Но только в случае если ваше приложение нормально туда пакуется.kvaps
17.09.2019 13:37А как же иммутабельность, автоскейлинг, декларативность, автоматический сбор логов/метрик, возможность создания абстракций для повторяющихся частей вашего деплоймента?
norguhtar
17.09.2019 13:43Это прям очень надо когда у вас ОДИН nginx ОДИН uwsi и ОДНА база данных. И два сервера.
onlinehead
18.09.2019 19:51Классический пример nginx + uwsgi сервис
Ну для этого в общем то и придумали оркестраторы.
Опять же его классическое решение это два контейнера, один с nginx, второй с приложением и все это завернуто в единый pod (если в терминах K8s).
При том, что скорее всего nginx-ов там надо меньше чем приложений и их вполне можно разделить и управлять ими отдельно (если позволяют условия задачи).
Бонусом получается целостная система управления, переносимость, скейлинг там всякий, раскатка апдейтов и т.п.
Если все это не нужно, то речь скорее всего о маленькой задачке, которую можно кроме docker\lxc решить еще кучей способов на любой вкус и городить тут оркестратор нет смысла, да и контейнеры вероятно тоже. Правда такие задачки попадаются крайне редко (в моей практике) и обычно уже есть оркестратор для чего-то более серьезного.norguhtar
18.09.2019 20:12Это классический пример забивания гвоздей микроскопом. Проблема как раз в том что везде кладут докер. Когда возникают проблемы прикатывают K8s. Или начинают городить из докера обычный контейнер.
VolCh
19.09.2019 09:16Не знаю насчёт uwsgi на 100%, но близкий к ней fastcgi скорее предполагает один nginx (мастер) процесс на один же master fcgi (если опустить скейлинг). Плюс очень часто шаринг дисковых ресурсов, включая те, которые в образ положить нельзя в принципе. И управлять ими надо чаще всего синхронно в плане запуска и конфигурирования. В кубике придумали ещё один уровень абстракции — поды, как бы эмулирующие физическую машину с абстрактным init. Но называть это классическим решением как-то язык не поднимается, классическое исключительно в рамках k8s
dominigato
19.09.2019 10:11+1Насколько понимаю обычно uwsgi и код приложения идет в одном контейнере, nginx если есть — в другом. Просто uwsgi и сам по себе может быть веб сервером. Вся статика на CDN.
Зачем nginx и uwsgi шарить какие-то ресурсы?VolCh
20.09.2019 07:22Есть "полустатика", файлы, загружаемые пользователями. Ну и CDN есть далеко не у всех
dominigato
20.09.2019 13:01В любом случае ее незачем шарить, любые файлы идут на выделенный сторедж и оттуда берутся. Ну разве что какой-то пет проджект расчитаный на один сервер, но там и контейнер не нужен.
snd3r
16.09.2019 22:52+1Всё так, кроме одного: Docker в Windows работает нативно через Windows Containers, хотя не понятно зачем нужен Docker если есть PS и Windows Containers.
raamid
17.09.2019 00:53Я использую Docker for Windows, и у меня он создает Hyper-V виртуальную машину с Linux и уже в ней контейнеры. Удобно, хотя иногда внешние диски могут отваливаться.
gecube Автор
17.09.2019 00:56Я так понимаю, что Docker под виндовс испытал несколько итераций. И я уже попросту потерялся в них.
Касательно Hyper-V есть неприятный нюанс, что вроде как Docker for Windows несовместим с другими средствами виртуализации — вроде VirtualBox или vmware.
slonopotamus
17.09.2019 09:03вроде как Docker for Windows несовместим с другими средствами
Да. Докер, винда, виртуалбокс — выберите любые два. Все три одновременно запустить не выйдет.
P.S. Я в курсе про существование Docker Toolbox. Оно а) объявлено устаревшим/неподдерживаемым б) в некоторых моментах ведёт себя несовместимым с Docker Desktop образом.
rogoz
17.09.2019 15:42Вроде же вопрос VirtualBox/Hyper-V решён, на какой-то версии 6.х:
docs.oracle.com/cd/E97728_01/F12469/html/hyperv-support.htmlVocler
17.09.2019 20:36+1Де-факто — нет, на форуме уже есть огромная нить из сообщений о том что VirtualBox 6 отказывает запускаться с HyperV.
Ну и лично у меня так и не получилось их запустить.
snd3r
17.09.2019 10:13Дело не в докере, а в Hyper-V, он действительно был не совместим с другими системами виртуализации, так как монополизировал доступ к аппаратным расширениям процессора, но есть пара но:
- Какой вообще смысл использовать дырявый и тормозной VirtualBox, когда MS бесплатно дает возможность использовать enterprise-level Hyper-V? (При этом давно есть возможность в VB включить тип виртуализации Hyper-V)
- В свежих версиях Windows появился слой абстракции — Virtual Machine Platform, позволяющий использовать виртуализацию для контейнеров, при этом не включая Hyper-V и не блокируя другие гипервизоры. Если я правильно понимаю, поддержка этой платформы другими гипервизорами уберет все конфликты.
gecube Автор
17.09.2019 10:16enterprise-level Hyper-V
Я бы поспорил насчет enterprise level. Типичный кейс с 2012 сервером. Используем его в качестве ноды виртуализации. Пускай, на нем 16ГиБ ОЗУ. Забиваем его виртуалками на 14ГиБ (остается 2ГиБ под систему). Работаем так месяц. Потом возникает необходимость выключить одну из ВМ. Пытаемся запустить — нет памяти. WTF!? Изначально ведь памяти хватало. Берем и психуем — ребутаем вообще всю ноду виртуализации. Все виртуалки опять на свежеперезагруженной ноде запускаются на ура. Поясню, что я никогда не использовал динамическое выделение памяти под ВМ — только руками прибивал объем. Получается, вЕнда течет? Вот тебе и продакшен реди.
Я уж не говорю про особенности перевода в русскоязычной версии, когда внезапно VLAN становится адаптером беспроводной сети (WAT???)
eumorozov
17.09.2019 10:33собенности перевода в русскоязычной версии, когда внезапно VLAN становится адаптером беспроводной сети (WAT???)
Я когда-то очень очень давно в студенческие времена переводил кое-что для XX. Правда под NDA, но по-моему, любая NDA имеет срок давности, а та NDA даже явно его имела. Прошло столько лет, что уже не вспомнить. Ну и потом, сам факт того, что я сейчас пишу, наверняка под NDA не попадает.
Так вот, не боги горшки обжигают. XX заказывает перевод у какой-нибудь солидной европейской компании. Европейская компания может заказать субподряд еще одной компании. В конце-концов эта цепочка заканчивается на бедных российских студентах. Хотя мне тогда деньги казались астрономическими.
Ну и делали мы перевод хорошо, я считаю. Проблема была в том, что какие-то сложные термины мы не могли правильно перевести в принципе, т.к. для этого нужен был серьезный экспириенс работы с продуктами. Поэтому иногда приходилось импровизировать и придумывать перевод гадая, что мог бы значить оригинальный термин. Углубляться все-таки боюсь, т.к. NDA какая-никакая была, хотя уже наверное давно всеми утеряна и потеряла актуальность, да и самой компании скорее всего уже давно не существует.
Так что неудивительно, что кто-то спутал VLAN и WLAN. Возможно также что где-то была опечатка, а переводчик пропустил, т.к. скорее всего в лучшем случае является профессиональным переводчиком, но не профессиональным сисадмином или программистом.
gecube Автор
17.09.2019 11:24Ну, для этого предназначено бета-тестирование на фокус-группе пользователей. Но уж точно такого в релизе быть не должно — СТЫДНО.
snd3r
17.09.2019 14:14Почему течёт? Набивает кеши как и любая другая ос.
У операционной системы подход простой: видишь пустую память — забей её кешами, что логично для всех сценариев — дабы пользователю запускать приложения быстрее и не читать их с диска, кроме того случая, что пользователь жук пытается выжать последние крохи из и без того пустого пула.
По-поводу венды 2012 для виртуализации ну тоже сомнительно, есть же бесплатный безгуевый Hyper-V Server который построен на Core версии и не стоит денег совсем. Свежий, бесплатный, Core (читай даже без гуи и требований к ресурсам), что еще нужно?
Что касается не венды, попробуйте забить память на линуксе и там не то, что все остальное продолжит работать, там всё встанет на пол часа пока ООМ-киллео не сможет наконец пробраться повыше: https://www.opennet.ru/opennews/art.shtml?num=51231
gecube Автор
17.09.2019 14:20На всякий случай поясню.
- это не кэши. Т.к. есть вполне понятные методики для их сброса. И они не помогали. Это раз. Два — в любой нормально операционке кэш сбрасывается, когда есть запрос на ОЗУ. Три — это сервер. Там другая профиль нагрузки. Не быстрее запускать foreground приложения, а обеспечивать стабильную работу сервисов.
- Насчет Core — тогда еще его не было. Это раз. Два — чем 2012 плох для виртуализации? Три — чем конкретно поможет Core, если Вы сами говорите, что дело в кэше? Ну, и добавлю, что Hyper-V server достаточно специфическая штука и одмины, умеющие только в ГУЙ, его не осилят (ага, запусти оснастку на другом сервере и подцепись к Hyper-V Server — тот еще квест).
Короче, аргументы какие-то сомнительные. Прям совсем. А я рассказал о вполне конкретном кейсе.
Что касается не венды, попробуйте забить память на линуксе и там не то, что все остальное продолжит работать, там всё встанет на пол часа пока ООМ-киллео не сможет наконец пробраться повыше
overcommit и своп настраивать не нужно, да? Мы же все знаем, что дефолтные настройки практически везде никакого отношения к реальной работе не имеют (и на это есть масса причин).
snd3r
17.09.2019 09:56И в чем противоречие?
Идея контейнеров — использовать ядро хоста, если вы пускаете на венде линуксовые программы то каким образом они будут использовать вендовое ядро хоста?
Нативные контейнеры только для приложений под Windows, тогда и контейнеры будут легкие, нативные и на хостовом ядре.
Kurnevsky
16.09.2019 22:54+1До сих пор не научился нативно не в linux-kind операционных системах.
И при этом только для линуксов не заимплеменчен резолвинг host.docker.internal. Мой личный pet hate.symbix
17.09.2019 06:13Категорически присоединяюсь! Я с этим делом недавно совсем дошел до ручки — сделал промежуточный контейнер, который пробует getent hosts host.docker.internal, а если не получается — берет default gateway, и NAT-ит на полученный IP весь диапазон портов через iptables. :-)
mikevmk
16.09.2019 23:02+4Спасибо за пост, хоть буду знать, что я не один такой немодный
Dansoid
17.09.2019 05:32Да что вы, не вы едины:
www.smashcompany.com/technology/docker-is-a-dangerous-gamble-which-we-will-regret
roller
16.09.2019 23:37+1В первую очередь докер решают проблему надежного атомарного УДАЛЕНИЯ СОФТА с тачки, а во вторую очередь — все остальное. Любой передеплой включает в себя удаление старой версии софта с машины, и вот это вот докер и сделал максимально удобным — не надо думать о мусоре, который раскидает инсталлятор по системе на пару с криворуки «коллегами»
gecube Автор
16.09.2019 23:43На самом деле нет. Если самому собирать пакеты и устанавливать их в стандартное место (например, /opt/), то никаких проблем вычистить старые версии софта нет.
А докер, на минуточку, создаёт проблему очистки неиспользуемых образов. Т.е. действительно хост-система не загадывается ошметками софта в контейнерах, но политику очистки образов все равно нужно продумывать. Проблема особо актуальна для docker registry, которые содержат мастер-образа для разливки софта на целевые машины
CyboMan
17.09.2019 00:24docker system prune -a
?gecube Автор
17.09.2019 00:34Не помню, но чем-то не понравилось — то ли удаляло слишком много лишнего, то ли наоборот — приходилось руками дочищать (совсем условно — то, что некий объект — образ или вольюм — сейчас не используется, не означает, что его можно брать и удалять)
usego
17.09.2019 08:18Ну конечно всё это можно, но если есть более удобный инструмент, улучшающий и многие другие аспекты процесса разработки и доставки, почему им не пользоваться? Большинство проблем, описанных в статье — это сетевое и «архитектурное». Но так оно и решается совсем другими способами.
mayorovp
17.09.2019 08:53Для задачи удаления старой версии софта докер делает слишком много. Достаточно вменяемого пакетного менеджера. А ещё лучше если софт просто лежит в одной папке, а не размазывается по файловой системе ровным слоем.
VolCh
17.09.2019 09:121) Пакетные менеджеры как правило очень осторожны. Особенно в части каталогов/файлов с конфигами и данными.
2) "Иногда" положить весь софт, да с зависмостями, в одну папку очень сложно.
mayorovp
17.09.2019 09:22Ну так данные-то при передеплое удалять как раз и не требуется. А если удалить нужно — у тех пакетных менеджеров что я видел есть для этого особая команда.
А вот по поводу зависимостей вы правы.
VolCh
17.09.2019 09:29Смотря что иметь в виду под передеплоем. На локальной машине разработчика передеплой нередко означает полный сброс всего. А особая команда типа apt purge не всегда удаляет все следы установки и использования. Хорошо если просто "утечка диска", а не переиспользование старых конфигов созданных в например, /etc/*.d/
gecube Автор
17.09.2019 10:00Как пакетный менеджер docker относительно хорош.
Слои — очень спасают, когда изменяешь образ, а он жирный, но не хочется перекачивать все.
Другой вопрос, что хотелось бы, чтобы слои были полностью независимы, тогда — было бы существенно интереснее и переиспользование диска было бы лучше. Тупая реализация сломала бы объединение слоев в цепочку, но в принципе никто не мешал бы сделать "умные реализацию".
Про теги говорил — никто никаких гарантий не дает. Если есть контроль над скачиванием образа, то удобно все пушить в :latest — неверный релиз не попадет. Но для всех прочих целей рекомендуется тегать артефакты четко — по git sha, по дате + версия или по git tag. Т.к. тот же кубернетес может легко скачать в рамках одной версии деплоймента разные версии образов, после чего инженер утонет в отладке что же это происходит.
Про docker hub сказал. Обидно, что он захардкожен и его по простому нельзя отключить. Можно добавлять свои registry, но это выглядит как костыль, т.к. все равно в имени образа зашита ссылка и просто безболезненно с одного домена на другой не переехать.
Еще изначально в докере нет средств проверки целостности образа (хотя есть вроде DTR и Notary, но это появилось позже) и HA для докер регистри (ну, действительно — зачем?)
Просто вымораживает путаница entrypoint vs command. И два типа синтаксиса их (через exec и через shell — хорошее описание тут). Мы для себя выработали такую практику: в энтрипойнт помещается то, что пользователь образа менять не будет (только в исключительных ситуациях), в command — аргументы. Везде по возможности используем exec-style описания (перечисление аргументов в квадратных скобках) — он более предсказуем.
Есть еще тонкости, но это уже по мелочи.
karavan_750
17.09.2019 00:01Для компилируемых языков вроде golang или виртуальных машин вроде java — паковка в контейнер докера выглядит избыточной.
Утверждение «не все есть гвоздь, когда в руках молоток» — считаю хорошим уровнем освоения «молотка» как инструмента.
divastator
17.09.2019 00:02+1решает ли хотябы отчасти проблемы подман от красношапки?
gecube Автор
17.09.2019 00:18Хотя бы отчасти — да.
- Не нужно тащить демона докера — следовательно — нет лишней абстракции и проблем типа "демон упал и утащил за собой все контейнеры"
- Решена проблема с безопасностью. Можно каждому юзеру показывать только его контейнеры. Да, кэш образов у каждого юзера свой. В этом есть свои плюсы и минусы.
- Более нативная интеграция с остальной системой — с тем же systemd.
Мы пока с коллегами присматриваемся в рамках профильных телеграм чатов. Пока нюансов много всплывает. Та же сборка через buildah — неидеальна. Мягко говоря
cy-ernado
17.09.2019 00:17+2Многие пункты это не хейт, а скорее здравый смысл :)
Безопасность, правда, никто и не обещал – от докера нужна лишь изоляция между приложениями.
А контейнеры без оркестрации в продакшене это воистину мазохизм. Если у вас один хост на хецтнере и полтора сервиса с SLO 50% – ничего не мешает катить ансиблом, а запускать системд, сам так вполне успешно делал. Докер лишь кирпичик в инфраструктуре, а не серебряная пуля, и вроде бы хайп давно прошёл (сейчас как раз по кубернетису угорают, но и он в эксплуатации сложен, пусть и крут).
gecube Автор
17.09.2019 00:33+1- без глубокого знания докера — эффективно пользоваться кубернетесом не получится. Т.к. сейчас все нынешние дистрибутивы k8s основаны на докере
- В силу п.1, безопасность докера = безопасность кубернетеса. Рваться будет по самому слабому звену. Что и наблюдаем.
- на роль оркестрации подходит puppet/salt/chef. Как бы и раньше как-то оркестрировали и ничего. ОК. Сейчас еще есть Nomad и Mesos. К сожалению, они на порядок менее популярные, чем куберенетес. Но жизнь в них теплится.
- касательно угара по докеру и кубернетесу — это то, что если власть в психбольнице получают психи. То бишь разработчики. Им удобно. А то что необходимо правильно написать софт, чтобы запихать его в кубернетес, они не понимайт или не осиливают. В кубернетесе действительно много классного (если не заглядывать в его код ))) и он реально облегчае некоторые моменты разработки. Но дисциплина разработки должна быть на уровне… иначе — хаос.
maxim_ge
17.09.2019 07:36nomad прекрасен. C моей точки зрения он имеет один минус — в нем нельзя организовать внутренние сети, с опцией шифрованния, как в swarm.
steamoor
17.09.2019 01:43по поводу пакета docker: смотрим на https://tracker.debian.org/pkg/docker и понимаем, что эта программа там была ещё в 2002, намного раньше чем докер был изобретён
переминовывать её никто не будет, приходится изворачиваться
Выше уже написали — управлять контейнерами можно и из Nomad, он к тому же может запустить просто бинарники или lxc.
В остальном согласен: Докер был хорошим этапом освоения контейнеров. Но в прод я его не поставлю.
Я всегда привожу речь Брайана Кантрилла про контейнеры, насколько давно они были изобретены: https://www.youtube.com/watch?v=xXWaECk9XqMgecube Автор
17.09.2019 08:18Из таких интересных пересечений по именам — minio. Клиент к этому s3 хранилищу внезапно называется mc. Прям как всем известный mc (midnignt commander).
Еще я видел алиас mc на meteor create.
Чем люди думают, когда так делают, для меня неведомоeumorozov
17.09.2019 13:40Почему бы и нет. Я не думаю, что mc настолько популярен за пределами бывшего СССР, где почему-то были популярны двухпанельные менеджеры типа nc и FAR.
Я например, никогда Midnight Commander не использовал, и вообще редко видел людей, его использовавших. Мне командная строка кажется намного более удобной, и крайне редко, при разборе большого количества фотографий, например, я запускаю какой-нибудь GUI файловый менеджер типа Thunar.
Ни на одном сервере, к которому я имею отношение, Midnight Commander нет и не было. И никто никогда не спрашивал о нем и не просил установить.
netch80
18.09.2019 07:23+1Во FreeBSD `mc` много лет был интерфейсом к тулзе управления лентами, а Midnight Commander был `midc`. Переименовали уже где-то около 2006. Источник такой же — та тулза пришла на много лет раньше…
Мало букв в алфавите, что делать :)
VolCh
17.09.2019 03:44Network host mode убивает одну из главных возможностей докера для разработки: запуск кучи приложений на "одном" порту без вмешательства в код/конфиги приложения.
gecube Автор
17.09.2019 08:17Для разработки, когда изоляция более важна, чем производительность — да.
Для production, когда все равно нельзя допускать выполнение недоверенного кода + ВСЕ равно настраивать софтину в контейнеру + важно быстродействие — ценность бриджа преувеличена.VolCh
17.09.2019 09:16Если продакшен — это один инстанс каждого приложения большой системы с использованием его собственных (читай — не унифицированных) механизмов масштабирования и балансировки, то может и преувеличена. Я крайне редко вывожу прямо на хост что-то кроме роутеров/балансировщиков.
VolCh
17.09.2019 04:07Контейнеры для компилируемых языков имеют право на жизнь тоже:
- нет необходимости ставить билд окружения на локальную машину
- инкапсуляция: вот на днях переписал один сервис с PHP на. Go. Кроме git репозитории исходников и Dockerfile этого сервиса никаких изменений не потребовалось в системе. Есть образ, есть его API (тут в совокупности и API приложения и соглашения докера, близкие к 12f) и на чём он написан не волнует "никого" кроме интерпретатора Dockerfile. Да, есть другие способы добиться подобного, но Докер, имхо, предлагает самый простой, удобный и универсальный на сегодняшний день. Реальная альтернатива, по-моему, сейчас только сборка apt/rpm/… пакетов (порог входа низким точно не назовёшь, есть подозрение, что универсальной тулзы просто нет, нужно разбираться с каждым языком, фреймворком, транслятором, возможно дистром ОС, systemd и т. д. и т. п. ). Плюс какой-то ansible освоить чтобы с багем поменьше дела иметь, плюс придумать свою систему оркестрации "виртуальными" "машинами" и "сетями" если не для изоляции, то хоть для совместного использования ресурсов типа портов.
gecube Автор
17.09.2019 10:04Почему не рассматриваете подготовку образов операционной системы со всем необходимым? AMI — в терминологии Амазона. Прекрасно осуществляется Packer'ом от HashiCorp
Ах, да, извините, забыл, что у Вас мощностей-то и нет… 1.5 сервера, как я понял, из нижних постов и все. Тогда да — там особо не развернешься.
VolCh
17.09.2019 13:08Было для VMware. Докер удобнее оказался. Вернее удобным оказался запуск докера в VMware машинах.
gecube Автор
17.09.2019 13:10А если не секрет — операционную систему внутри виртуалки какую используете?
Я бы рекомендовал смотреть в сторону облегченных дистрибутивов вроде coreos / photonos
Действительно — они атомарно обновляются, содержат минимальный набор драйверов (т.к. "железо" в виртуалках стандартизировано), следовательно, идеально подходят под запуск контейнеров.
jsirex
17.09.2019 07:13Внесу свои 6 копеек.
Я тоже недолюбливаю докер, хотя, начал использовать его до того, как это стало мейнстримом.
И мои мысли о тех преимуществах, про которые рассказывают следующие:
1. Безопасность — разработчику плевать, это не то, ради чего он рад пользоваться докером. admin/admin глубоко в коде и прочие радости. Пока разраба не пнут — не пофиксит
2. Изоляция процессов — посмотрите на свой проект, сколько там контейнеров? 5? nginx, java, redis, postgres, logstash? Запусти это всё просто на хосте и ок. Что тут изолировать? Другое дело, если вы — public ci cluster. Может быть.
3. Удобство запуска — НЕТ. Да, выполнить docker run легко. Но прилага на дефолтах. Только «на посмотреть». Когда надо сконфигурить — поехали тонна переменных окружений, монтирование папок, конфиг-файлов и т.д. А entry-points под это дело писать на 2000 строк — то ещё удовольствие.
4. Сетка — стало только сложнее. А когда речь идёт о траблшуте, почему порт из контейнера внутри hyper-v на хост систему не пробросился — почему-то теряются даже сеньоры.
И вот мы подобрались к тому, из-за чего контейнеры стали популярны:
5. Запаковать all-in-one. Современный разработчик — это модный чувак, который сидит под вендой, тыкает пальцем в кнопочку в ide, нихрена не понимает как устроена его ОС, не умеет в линукс, не умеет упаковывать и распространять дистрибутив своей же программы (tar.gz/npm/deb/rpm/gem/whatever). Но при этом разрабатывает, конечно-же, под линукс. И как же ему бедненькому всё что он локально сделал запустить? Правильно, используя stack overflow наустанавливать не пойми чего, скопировать всё подряд и через 30 баш скриптов запустить без особого понимания в докере. Зато работает. А потом на прод.
Docker — это современная package management система.
Ну и, пожалуй, есть ещё один удобный пункт — который близок к 5ому:
6. создание окружения для сборки. Собрал себе в контейнере всё, что нужно, компиляторы, тулы, и т.д. — и собирай себе на здоровье. Кстати, это же можно было делать и в chroot, но да — docker удобнее будет.
Альтернативы: разобраться в пакетной системе. Например, deb трекает каждый файл при установке и гарантировано удалит это за собой во время удаления. Есть жизненный цикл пакета — pre/post-install/rm, pre/post-configure и т.д.
Однако, текущие пакетные системы тоже имеет проблемы, например, нельзя или очень сложно иметь сразу несколько версий пакетов в системе. И тут на сцену выходят следующие ребята, которые решают и это: nix, guix, flatpack, snap, chef habitat.gecube Автор
17.09.2019 08:25Изоляция процессов — посмотрите на свой проект, сколько там контейнеров? 5? nginx, java, redis, postgres, logstash? Запусти это всё просто на хосте и ок. Что тут изолировать? Другое дело, если вы — public ci cluster. Может быть.
Маленький пример. Тот же гитлаб, который активно продвигает использование контейнеров для CI, на публичных сборщиках (=раннерах) использует полноценные ВМ с предустановленным docker'ом, а не, скажем, большой кубернетес кластер. А почему? Потому что если IaaS платформа или облако предоставляет виртуалки, то они не сильно дороже в плане трудоемкости создания (мы не про деньги говорим, а про удобство), а изоляция сильно лучше, чем у контейнеров.
Возможно, есть публичные сборочные конвейеры, которые бегут исключительно в контейнерах. Но это какая-то прям стремная история тогда
norguhtar
17.09.2019 08:27+1Изоляция процессов — посмотрите на свой проект, сколько там контейнеров? 5? nginx, java, redis, postgres, logstash? Запусти это всё просто на хосте и ок. Что тут изолировать?
Контейнеризация по типу openvz/lxc/lxd решает этот вопрос. Плюс дает хорошую переносимость. Дополнительно можно сложить пачку легких сервисов на большой и толстый сервак. Я так делал еще в openvz задолго до появления docker. Так-как ставить под почтарь, dns и т.п. сервисы отдельные серваки жирно. А сопровождать их все на одном физическом хосте муторно. Распиливание их по контейнерам приводило к существенному упрощению администрирования.gecube Автор
17.09.2019 10:03Мы OpenVZ похоронили очень давно. И перекрестились.
LXD/LXC — да, но пугает, что это в первую очередь убунтовский проект. Остальные компании, то ли мне так показалось, то ли так оно и есть, но не поддержали этот вариант контейнеризации.norguhtar
17.09.2019 10:06Это было в те годы когда OpenVZ было стильно модно молодежно. Ну LXD/LXC да такое, но все же лучше треша в виде docker
usego
17.09.2019 08:50Наверное в вашей среде очень крутые разработчики. В моей — они не то, что с докерами мало знакомы, так и вообще про эксплуатацию мало понимают. Админы, в свою очередь, часто мало понимают нюансы работы / настройки конкретного софта. Докер в данном случае является связующим звеном между админами и разработчиками. Благодаря ему центр тяжести ответственности по эксплуатации смещается в сторону разработчиков и они начинают больше думать головой. Нет уже всех этих «а у меня работает», так как воспроизвести прод среду становится кардинально проще. Админ же в свою очередь получает своего рода преднастроенный софт, что значительно упрощает его обслуживание. Про скалабилити и не говорю.
jsirex
17.09.2019 11:54> они начинают больше думать головой
они начинают больше копипастить со stackoverflow в стиле
apt-get install 200 пакетов которые я хз зачем
или
chmod 777 -R /usr # потому что без этого, почему-то не работает
И мой любимчик:
chown 775 /home/appusego
17.09.2019 12:29Devops, он на то и devops, что бы быть посередине между разрабами и админами и не допускать кривое написание докеров. Чаще — писать их самому. Никто же не говорит, что писать докера должны разрабы, мало в них понимающие.
И раскажите, чем преступен chown 775 /home/app в пределах докера, который не запускается под рутом? И не имеет смонтированых шаред волюмов с хоста на запись.gecube Автор
17.09.2019 12:41+1Если мы выделяем devops в отдельного человека, то мы вместо слома барьеров — создаем новые (девы перекидывают код девопсу, а он перекидывает дальше на админов). Более неверного толкования я в принципе не видел.
usego
17.09.2019 12:48Девопс один раз собирает «правильный» докер/под из проекта, настраивает CI/CD, пушит всё это хозяйство прямо в проект, проводит базовое обучение как с этим жить и говорит «далее уже ваша проблема как доставить мне стабильный докер для лайва» и это уже становится ответственностью цикла разработки. Тут ключевое, что бы девопс понимал как работу девелоперов, так и эксплуатацию, тем самым определяя требования к софту.
Я понимаю, что pure devops — идёт дальше вплоть до деплоймента в лайв самими разработчиками. Но не везде это возможно.gecube Автор
17.09.2019 13:00настраивает CI/CD
это билд инженер или релиз инженер, а не девопс.
Девопс один раз собирает «правильный» докер/под из проекта
В зависимости от темпов разработки и скорости внеения изменений — правильного может и не быть (хотя в каждый момент времени мы можем к этому стремиться).
говорит «далее уже ваша проблема как доставить мне стабильный докер для лайва»
Там еще бездна того, что нужно сделать. Логирование, мониторинг, пр. пр. пр.
Тут ключевое, что бы девопс понимал как работу девелоперов, так и эксплуатацию, тем самым определяя требования к софту.
Опять выделяете это в отдельного человека. :-( На самом деле вопрос что такое DevOps и является ли DevOps каким-то человеком — очень холиварный.
Тут ключевое, что бы девопс понимал как работу девелоперов, так и эксплуатацию, тем самым определяя требования к софту.
Понимать недостаточно. Нужна коллаборация, обмен опытом и лучшими практиками и работа на общий конечный результат.
Но не везде это возможно.
очень интересно посмотреть, как бы это работало в жестко зарегламентированной сфере. Вроде банков, государственных предприятий, транспорта.
usego
17.09.2019 13:14Билд инженер, релиз инженер… Кто эти люди? Может потому и нелюбовь в докерам и оркестрации у некоторых, так как эти веяния у кого-то хлеб стали отнимать, «стандартизируя» всю эту работу и выветривая волшебную пыль этих специализаций?
gecube Автор
17.09.2019 13:25Извините, но Вы же не отрицаете необходимость специалистов по DBA, сетевых инженеров и пр.? Просто иначе мы имеем очень интересных кадавров в инфраструктуре.
Будущее за Т-shaped persons. Это те, которые имеют какую-то глубокую специализацию. А еще имеют широкий кругозор. Если что — переквалифицироваться такому специалисту будет не очень сложно.
usego
17.09.2019 13:39+1Всё зависит от размера организации. Даже далеко не во всех банках есть такие люди. Что уж говорить про относительно небольшие компании. Для них подобная «стандартизация» процессов — благо, так как повышается мобильность с точки зрения передачи знаний и уменьшения издержек на таких выделенных специалистов. Как бы не был сложен K8S, но перенять настроенный кластер другому опытному K8S специалисту будет на порядки проще, чем унаследовать самопальное хозяйство, обвешенное всяким башем и прочей knowhow магией каждой конкретной организации.
gecube Автор
17.09.2019 14:23Как будто уже выработаны нормальные практики деплоя в k8s, его развертывания, поддержки. Вот же все свои велосипеды пилят. Те же флантовцы, например — werf; booking.com — shipper etc.
Не могу еще не упомянуть разговор на ЛинкМиАп про кубернетес: Докер, Кубер два апдейта.
OpenShift как инкарнация энтерпрайз кубернетеса тоже навязывает свои подходы ко всему вышеописанному, причем… кхм… не всегда оптимальные.
VolCh
17.09.2019 09:09+3Изоляция процессов — посмотрите на свой проект, сколько там контейнеров? 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 система
пускай и требующая обёрток из баша
gecube Автор
17.09.2019 09:21+1В чём-то сложнее, в чём-то проще. Уровень конфигугирирования сетки инстанса системы переместился с конфигов элементов системы на общий конфиг системы. Грубо, 49 запущенных на хосте nginx слушают порт 8080 и только один слушает 80, роутя запросы на эти 49 и автоматически подхватывая новые. Можно ли подобное сделать на условном баше? Наверное можно, но боюсь представить сколько отдельных скриптов и строк это будет. Не говоря о том, насколько этот код будет поддерживаемым.
Лукавите. Этот nginx должен быть специальным образом собран, чтобы он динамически изменял свою конфигурацию в зависимости от запущенных контейнеров. Он это умеет со скрипом, либо приходится сразу ударяться в lua программирование. Есть, конечно, сборка от jwilder. Но какая-то она не production ready. А для тестовых сред очень хорошо себя показал хипстерский traefik
Альтернативы есть, конечно, но как-то они разработчика превращают в мэйнтейнера и эксплуатационщика по соотношению времени разработки к полному времени
Вообще-то в этом и суть явлений DevOps/SRE. Если разрабы не могут сделать конфетку, то пускай они занимаются эксплуатацией, фиксацией багов и их исправлением… И через несколько итераций, внезапно, качество кода вырастет. Потому что если разработка и эксплуатация отделены, то как это не называй, но получится фигня, т.к. ответственность будет размазана.
roller
18.09.2019 18:10Лукавите. Этот nginx должен быть специальным образом собран, чтобы он динамически изменял свою конфигурацию в зависимости от запущенных контейнеров.
На самом деле никакой специальный nginx конечно же не нужен, хватит consul + consul-template
VolCh
19.09.2019 09:29+1Этот nginx должен быть специальным образом собран, чтобы он динамически изменял свою конфигурацию в зависимости от запущенных контейнеров. Он это умеет со скрипом, либо приходится сразу ударяться в lua программирование.
nginx вполне стандартный, специально не надо собирать бинарники nginx, та же сборка от jwilder может біть задеплоена как один контейнер и как два, один из которых стандартный nginx, а второй — абстрактный генератор файлов на базе потока событий от докера.И вполне продакшен реди он было года 3 назад ещё.
Вообще-то в этом и суть явлений DevOps/SRE
Про SRE ничего сказать не могу, даже что знаю только понаслышке не могу сказать. Но вот DevOps явно не про то, чтобы рядовые разработчики занимались эксплуаатацией.
gecube Автор
19.09.2019 09:56Но вот DevOps явно не про то, чтобы рядовые разработчики занимались эксплуаатацией.
Несомненно — все это хайповое в разработке (agile, devops, xp etc.) — требует высококвалифицированных и высокомотивированных сотрудников, иначе ничего не получится. В стандартном укладке мира, когда вотерфольная разработка и кодеры ничего не умеют — да, их подпускать к продакшену даже на расстояние пушечного выстрела нельзя.
nginx вполне стандартный, специально не надо собирать бинарники nginx
Сам бинарник nginx — конечно, не обязательно пересобирать (но если нужны функции не включенные в базовый — ну, сорян, придется пересобирать), речь больше про то, что придется пересобрать образ и сдобрить nginx всякими дополнительными программными компонентами сбоку (как выше коллега советует — consul + consul-template), чтобы обеспечить это самое динамическое изменение конфигурации.
Очень странно, что это приходится разжевывать. Как будто я недостаточно подробно комментирую изначально, что возможно наводит на неверные мысли?
mayorovp
17.09.2019 09:31Небольшое уточнение.
а начиная с Висты не понимает даже как меню "Пуск" открыть — все попытки приводят к вываливанию какой хрени на весь экран
Что-то вы напутали, непонятная хрень на весь экран вываливалась в "восьмёрке". Потом в 8.1 добавили возможность эту хрень закрыть, а в "десятке" вернули что-то похожее на нормальный "Пуск" (по крайней мере, кнопка выключения снова на месте).
VolCh
17.09.2019 13:11Может быть, давно это было. Но что-то в Висте буквально после 0 минут работы заставило начать серъёзно рассматривать альтернативы.
mayorovp
17.09.2019 13:33Из того что я помню — там настройку разрешения экрана запихнули в "Персонализацию" (позже в "семерке" вытащили обратно), да и вообще панель управления перетасовали до неузнаваемости. Ну и первое появление UAC, конечно же.
norguhtar
17.09.2019 10:08Грубо, 49 запущенных на хосте nginx слушают порт 8080 и только один слушает 80, роутя запросы на эти 49 и автоматически подхватывая новые.
Откройте для себя unix сокеты. Да nginx их умеет, там можно хоть 100500 nginx использовать.VolCh
17.09.2019 13:12Причём тут сокеты?
gecube Автор
17.09.2019 13:16затем, что проблема с 49 nginx на одном порте 8080 надуманна. В любом случае, придется их как-то различать — хотя бы по именам или по instance id, а ценности в этом сильно больше, чем распихивать их по разным парам ip:port, нет.
Кстати, у меня docker-compose scale в какой-то момент стрельнул. У меня было докеризированное приложение, которое обсчитывало на видеокарте некий массив данных. Если делаешь docker-compose scale — все инстансы запускаются с одинаковыми переменными. И либо городить систему, по которой приложение будет узнавать свой инстанс айди, либо пойти по более простому пути (что я и сделал) — просто три блока описания service, каждым со своим уникальным набором переменных (изменяля
CUDA_VISIBLE_DEVICES). Так что… Шило на мыло.VolCh
17.09.2019 13:21Мне их зачем различать? :) Прелесть докера и его экосистемы, что он довольно хорошо прячет под капотом эти различия.
jsirex
17.09.2019 12:10> Допустим под 20
сколько РАЗЛИЧНЫХ контейнеров ранается в проекте. Возможно, у вас действительно 20. Но если у вас кластер эластика на 15 машин — считайте это за 1.
>унифицированные интерфейсы конфигурирования
нет. Переменные окружения? У всех всё по-разному, а некоторые аппы, пока файл не положишь — не заработают. Либо приложение можно удобно конфигурировать, либо нет. Докер тут никак не помогает. И если завтра дедлайн, а конфигурить через файл — будешь монтировать файл.
>Не зависит особо от докера
О том и моя мысль, что плюсы, которые приписывают докеру, вовсе не его
> Да, можно понаписать башскриптов
Не так. «нужно понаписать пачку башскриптов». Entrypoint более-менее непростого контейнера видели? Init перед entrypoint-ом и прочее весёлости. там много скриптов получается. Благо, это не всегда плохо.
> Грубо, 49 запущенных на хосте nginx слушают порт 8080 и только один слушает 80
Это тоже не про докер.usego
17.09.2019 12:35>Entrypoint более-менее непростого контейнера видели? Init перед entrypoint-ом и прочее весёлости. там много скриптов получается. Благо, это не всегда плохо.
Ну так и софт надо писать с пониманием, что он будет запускаться в контейнере. Хотя бы конфиг из env variables должен уметь читать. Тогда и не надо будет колхозить энтрипойнты. Докер — не серебряная пуля для всех проектов, особенно легаси. Но при правильном применении — чрезвычайно мощный инструмент, упрощающий весь процесс.
VolCh
17.09.2019 13:17сколько РАЗЛИЧНЫХ контейнеров ранается в проекте.
под 20 различных образов
нет
Я имею в виду docker-compose.yaml и ко прежде всего.
Это тоже не про докер.
Докер предоставил самый удобный DX(UX?) для этого из тех, что я встречал за 10+ лет работы с ним.
beduin01
17.09.2019 09:41«If WASM+WASI existed in 2008, we wouldn't have needed to created Docker.» (с) Один из основателей Docker. Ссылка.
Jipok
17.09.2019 18:231) Языков с нормальной компиляцией в wasm нет, rust разве что. Большинство через llvm и emscripten. Тот ещё костыль.
2) WebAssembly создавался для браузеров(слово web названии какбы намекает) для пропуска этапа парсинга и оптимизации js кода, а также для поддержки других языков программирования. Производительность не была главной целью, даже многопоточность недавно завезли. В общем, такой код сильно уступает в производительности нативной реализации.
3) Wasi совершенно не готов. До сих пор идут обсуждения основного api. Сборка возможна только для сишного кода и скоро можно будет на расте.
Т.е. для серверов wasm не готов. И вряд ли будет в ближайшем будущем.
На мой взгляд, Wasi — это попытка создать эдакий jvm для раста и ещё парочки яп. Т.е. кроссплатформенность — один раз собрать для кучи платформ. Но как показывает java, такое не особо работает. В теории можно, но как только проект вырастает больше hello world'a начинают появлятся платформоспецифичные хаки. Или использование приложения удобно только под Windows, под Linux тоже можно запустить, но выглядит слишком инордно и вызывает дискомфорт.
EmotionTigran
17.09.2019 10:06Думаю, статья утратила свою актуальность (в том числе выше перечисленные аргументы по сетям и прочему), потому как в 2019 мало кто деплоит Docker на production. Docker (вместе с docker-compose) нужен для рабочего окружения разработчиков, CI и пр. Production ready это k8s (или его «мини» версии, типа mikrocube или k3s) с runC вместо Docker.
gecube Автор
17.09.2019 11:51Как будто проблемы разработчиков никто не должен решать (вот та же история с перекрытием сетей — думаете, что она не пьет кровь девам?). А они зачастую не в состоянии это сделать, т.к. у них фокус не на админстве.
CI и пр. Production ready это k8s (или его «мини» версии, типа mikrocube или k3s)
Повторюсь, что не всегда и не везде кубернетес нужен. Есть куча компаний, которые с радостью его "продадут" вам как клиенту, т.к. это является основой их бизнеса.
За упоминание k3s — жирный плюсик. Спасибо
dominigato
17.09.2019 14:36Rancher/k3s, есть разные «кубер для людей» дистры, которые не намного сложнее чем тот же docker swarm. Который умер, конечно же.
Когда сетапы с контейнерами становятся настолько сложными, что возникают проблемы которые вы описываете, это время выбирать нужную оркестрацию.
Для обычных тасков на компе podman хватает за глаза.
EmotionTigran
17.09.2019 17:28А с какими проблемами настройки сетей вы сталкивались в k8s? Если речь идёт про классические приложения (например, Django), то я склоняюсь к тому, что без k8s или его урезанных версий на проде нормально не настроить те же сети. А если хочется больше автоматизации, можно (и нужно имхо) брать managed k8s у того же Google или DO.
gecube Автор
17.09.2019 17:35K8s и сети — это одна сплошная проблема. Начиная от вопросов выбора — какой cni мы хотим. И как мы хотим его настроить.
К тому же, я больше говорил про проблемы разработчиков с докером на их машинах. Согласитесь — вряд ли разработчики будут тащить полноценный кубернетес к себе на ноутбук или рабочую станцию (разве что в урезанном виде а-ля minikube или k3s).
По поводу того, что лучший кубернетес — тот, который ты не хостишь, т.е. в идеале — managed от Гугла — полностью согласен.
Единственное, что действительно похоже (некоторые коллеги озвучивали такое мнение), что сложность k8s именно что избыточна и создана специально, чтобы все переезжали в облако к Гуглу. Почему мы уверены, что это так — потому что есть оркестраторы намного проще (вроде связки nomad + consul).
eumorozov
17.09.2019 10:09У меня есть еще пара соображений.
- Отвратительная документация. Возможно, это моя идиосинкразия, но когда только учился готовить Docker, пришлось прочитать кучу информации не с сайта docker, потому что документация на официальном сайте сухая и бесполезная. Она очень плохо объясняет даже простые вещи и написана нечитаемым образом. Из нее очень сложно сложить цельную картину. Для этого требуется читать сторонние источники и много экспериментировать.
- Миллиард багов. Например, лично из моего опыта: пару дней билдил конфигурацию для клиента, у которого Mac. Он мне возвращал со словами: «У меня не работает». В итоге, после долгой и нервной отладки и долгого гуглинга, всплыло наконец, что в Docker для Mac при каких-то условиях на каких-то версиях docker может свалиться интерпретатор Python. При этом далеко не всегда эти баги правятся и не всегда есть возможность оперативно установить исправленную версию… В которой могут быть свои баги и несовместимости.
А уж это залезание docker'а кривыми руками в сеть просто… Очень неудобно.
gecube Автор
17.09.2019 10:13Отвратительная документация.
Как думаете — это сделано умышленно? Или само так получилось? Дело в том, что есть сертификация по docker. Получается можно заплатить денег и вас ему научат :-o :-o :-o А раз так, то с капиталистической точки зрения нужно делать продукт достаточно хорошим, но не более. Чтобы новички быстро в него въезжали (цель достигнута), а профессионалы могли рубить капусту (вроде как тоже).
veselovi4
17.09.2019 10:49В общем хотел было стать модным. Читал читал про докер. Уже вроде как занес руки над клавиатурой. И так и остался со своими VirtualBox-ми. Брат жив. :)) Никаких костылей не изобретаю. Если нужно. То под Виндой или Линухом разворачиваю все и живу спокойно.Правда у меня и виртуалок всего 5-6 штук по десятку юзеров на них.
Groramar
17.09.2019 11:29Я вот считаю докер (как и любые другие прослойки) костылём. Мы собираем свои программы в пакеты установки для Линукса. Стараемся, что бы всё разворачивалось и удалялось максимально прозрачно насколько это физически возможно. Да, разработка ведется в Windows (Delphi + FPC/Lazarus), но это никак не мешает и софт и пакеты собирать. Чем меньше зависимостей — тем лучше. Наш путь такой.
ferocactus
17.09.2019 12:09Тоже считаю докер костылём, но не костылём для поставки/инсталляции, а костылём изначально недостаточной изоляции процессов в операционных системах.
Ogra
17.09.2019 13:00+1Я раньше собирал в deb-пакет одно наше приложение. Перешел на докер. Во-первых словил проблемы с libssl, который немножко разных версий на разных дистрибутивах, и собранное на одном компе не может запуститься на другом. Наверное, это можно решить, но неудобненько как-то. Во-вторых, обновление софта через Докер оказалось быстрее — пока deb пакет удалится, пока свежий поставится, пока подтянет зависимости, если они появились… А вот вытянуть свежий образ, остановить контейнер, создать новый контейнер, запустить — работает просто прелестно, даунтайм близок к нулю.
Главное не ставьте Docker под Ubuntu через snap — словите непонятных багов, честно, сами встречали такое.
NIK0g
17.09.2019 12:24Автору спасибо и за эту публикацию и за самоотверженный труд в его Tg-каналах. Лично мне помог избежать многих граблей и смог объяснить все заданные вопросы на пальцах.
DarkGenius
17.09.2019 12:26+1Я не думаю, что описанные особенности сети ведут к массовым проблемам. Скорее всего, они становятся проблемными в каком-то ограниченном количестве специфических случаев. В своем опыте еще ни сталкивался с такими кейсами. Хотя, может потому, что опыт использования Docker пока небольшой.
ne_kotin
17.09.2019 14:23Я уже год немножко оператор проксей и VPN для обхода блокировок.
И после парочки итераций я пришел к докеру.
Почему? Потому что мне хочется единообразного цикла доставки и управления помянутыми проксями и впнами на различных хостах для различных пользователей.
У меня есть Docker Hub как источник образов, и подготовка хоста заключается в одной команде.
apt-get -y install docker.io python python-flask && docker pull [тут образы]
всё.
Но есть существенное отличие от энтерпрайзных сценариев — у меня контейнеры автономные (не требуют зависимостей в виде других контейнеров).
Единственное что пришлось «допилить напильником» — свою примитивную систему менеджмента конфигураций и управления запуском контейнеров. Потому что держать в голове подробности не хочется, а кубернетес для моих целей слишком монструозен.
Один основной питоновский скрипт и 3 утилитных к нему. Скоро на гитхабе.
Живу так больше года.gecube Автор
17.09.2019 14:31Очень ждем! Круто будет посмотреть. Мы в свое время использовали для тестового стенда прекрасный образ https://github.com/kylemanna/docker-openvpn
А еще мне пришлость forticlient закатать в docker, т.к. там был нюанс с тем, что он радикально портил route на моей машине.
Единственный недостаток, что vpn в docker требует privileged режима или определенного cap NET_ADMIN.
ne_kotin
17.09.2019 14:42для моих целей хватает Shadowsocks, которому замечательно в докере живется.
для десктопных клиентов — pptpd на хосте.
да, знаю, что obsolete, зато вездеходно и настраивается неквалифицированными пользователями.roller
18.09.2019 20:52Кошмар, чем не угодил openvpn and/or pritunl?
ne_kotin
19.09.2019 01:01Кошмар — это как раз OpenVPN — скачай клиента, заморочься с УЦ, экспортируй профиль, обломайся, если в ядре нет tun/tap.
Блондинке-гуманитарию попробуйте это всё объяснить.
Shadowsocks — отличный mobile-first VPN для обеих платформ с легким конфигом и небольшим потреблением ресурсов.
razielvamp
17.09.2019 14:27Соглашусь. По моему опыту написать yml файл протестировать его развертку, затем стабильность работы и в итоге переодически ловить баги из-за того что в репозиториях что-то изменилось и билд уже не торт, занимает дольше времени, чем топорно вручную поставить линух, настроить его и закатать в vdi образ и потом клонировать сколько нужно раз.
По-крайней мере там где я работал раньше крутилось 30 инстансов в AWS и я не трогал их по пол года и больше. И были среди них два микросервисных докера напиханные bash-костылями. А для стабильной работы контейнеры каждую ночь пересобирались.
Конечно в подходе «сломалось — выкинь и сделай новое» тоже есть рациональное зерно. Но ИМХО поднять простецкий LAMP в виртуалбоксе гораздо быстрее и удобнее чем ковыряться с докером в девелопе. Хотя второй создан как раз для быстрого развертывания среды.
Конечно у меня нет опыта работы в проектах с сотнями и тысячами серверов, там правила и условия, но и докер частенько используется в проектах с общим количеством машин не больше 10.
На той же vmware можно построить гораздо более стабильную и отказоустойчивую систему нежели модный кубернетес, который поверху тех же виртуальных серверов и ставится, которые абсолютно так же падают.
И из-за этого действительно бомбит, потому что когда приходишь на собеседование и тебя начинают гонять по «брендовым» словечкам аля контейнеры, кубернетес, эластиксерч, флуентд, а ты им говоришь, ребята, у меня тут пару серверов было, я набросал пару скриптов на баше, накинул забикс и все это нормально работало, то на тебя смотрят как на идиота, который не постиг ит-дзена и ничего не умеет.usego
17.09.2019 15:23ого что в репозиториях что-то изменилось
Во первых форкаем чужие докера к себе, во вторых не используем :latest. Неумение готовить — проблема обучения, а не инструмента.
Виртуалки не заменяют докера, как и докера не заменяют виртуалки. Эти 2 технологии хорошо дополняют достоинства друг друга.razielvamp
17.09.2019 17:48Под репозиторием я имел ввиду не только репозитории докера. В овер 90% docker-compose файлов установка nginxов и mysqlей идет на лету во время билда. Это вполне готовые семплы или рабочие контейнеры, которые даже на гитхабе много звезд имеют.
Делов-то, форкнуть epel репозиторий.
Виртуальный сервер из образа с каким-нибудь ansibleом можно развернуть также автоматически как и контейнер.
Из неоспоримых плюсов можно назвать только скорость непосредственного билда и лёгкость контейнера.
Правда, когда говорят о производительности контейнеров, почему-то сравнивают 5 физических машин, по сервису на каждую, против 5 контейнеров. А если все эти сервисы положить на один хост, то получится гораздо более производительная система, чем с 5 раздельными контейнерами.
Потом говорят про то что контейнеры легко удалять и создавать, так это потому что они без падений дольше месяца не работают, за ними постоянно нужно следить.
Чтобы работать с контейнерами нужны более квалифицированные и админы и программисты, чем при работе с виртуальными серверами. И это факт, доказательством которому может служить повсеместный виртуалбокс, который как игрушку ставят. Как можно упрощать инфраструктуру усложняя её?
Когда ковырялся с кубернетес, он мне на лопатки два ноутбука с 4мя виртуальными машинами клал при запуске "hello world" на nginx кластере из 2х контейнеров. По старинке на LAMP на этих буках можно онлайн магазин с тысячами просмотров в день развернуть и еще ресурсы останутся.
Контейнеризацию выгодно продвигать только облачным провайдерам, потому что легко и быстро перебрасывать и перераспределять свободные ресурсы и, соответсвенно, перепродавать. Чем они и занимаются.
В общем я пока что до этого либо не дорос, либо наоборот, консервативный старпёр.dominigato
17.09.2019 18:12Потом говорят про то что контейнеры легко удалять и создавать, так это потому что они без падений дольше месяца не работают, за ними постоянно нужно следить
Это работа оркестраторов, типа к8 и пр. Сами все переподнимут.
Чтобы работать с контейнерами нужны более квалифицированные и админы и программисты, чем при работе с виртуальными серверами.
Это сомнительное утверждение. Что не отнять у докера, так это популяризация контейнеров в среде девелоперов. Обычные программисты спокойно им пользуются без всяких проблем, уж точно не «квалифицированные админы». Последние нужны уже для оркестрации и продакшена.
Когда ковырялся с кубернетес, он мне на лопатки два ноутбука с 4мя виртуальными машинами клал
Зачем вы добавили виртуалки? Они как-раз и сожрали все ваши ресурсы.
Контейнеризацию выгодно продвигать только облачным провайдерам, потому что легко и быстро перебрасывать и перераспределять свободные ресурсы и, соответсвенно, перепродавать. Чем они и занимаются.
Это выгодно не столько провайдерам, как их клиентам. Отказоустойчивый кубер в облаке, где крутятся их микросервисы — и ничего больше не надо знать. Сам все переподнимет, перескейлит, и т.д. и т.п. Экономия на нескольких работниках в компании.gecube Автор
17.09.2019 18:15Отказоустойчивый кубер — да, но толку от него, если приложение не соответствует лучшим практикам написания для cloud native среды
Кубер — не магическая палочка или серебряная пуля, которая автомагически решит проблемы бизнеса
Несомненно — кубер даёт новые возможности. Например, экономию денег на спот инстансах (появляется возможность использовать их, а не обычные вм). Возможность проводить хаос инжиниринг. И пр. Но какой ценой?dominigato
17.09.2019 18:17И какой ценой?
gecube Автор
17.09.2019 18:52Простой пример — коллеги разрабатывают сайт для небольшой компании. Нагрузку сайта (стандартно — БД + nginx + php-fpm) прекрасно держит одна VPS. Ну, ок — хотим немного отказоустойчивости — cloudflare + второй инстанс. Они пробовали разрабатывать на кубернетесе — не зашло. Слишком сложно и дорого (брали GKE, причем я не участвовал в выборе, конфигурировании среды).
Второе. Кубернетес выдвигает определенные требования к приложениям. Определенный способ упаковки, декомпозиция по контейнерам, эндпойнты для healthcheck/readiness и многое другое. В целом, это все не очень плохо, тем более, когда смотрим на далекую перспективу. Но для какой-то простой штуки (не знаю, прототип телеграм бота, например) все это может оказаться излишним, а, следовательно, на начальных стадиях внести оверпрайс в разработку.
Условно — отказоустойчивый сервис по обработке данных я и без k8s на консуле (etcd/zookeeper) + питоне на трех нодах запущу. И это будет проще и дешевле.
dominigato
17.09.2019 19:13Вебсайты прекрасно лягут на кубер, он для их и написан в первую очередь. То, что товарищи не смогли разбить по сервисам в докере очень странно. Я думаю по первым трем результатам в гугле можно найти примеры на БД + nginx + php-fpm.
То что дорого — верю. Но платить зарплату админам которые над этим всем сейчас работают тоже дорого. Может даже еще дороже.
Если писать приложение правильно с самого начала, используя контейнеры, то проблем быть не должно. Если это перевод существующего монолита, то это конечно много дополнительной работы. Многие на этом и зарабатывают, помогая перейти на контейнеры.
Но в конце концов решает бизнес — насколько надо отказоустойчивость и скейлинг приложению.gecube Автор
17.09.2019 19:16То, что товарищи не смогли разбить по сервисам в докере очень странно. Я думаю по первым трем результатам в гугле можно найти примеры на БД + nginx + php-fpm.
Откуда такой вывод, что ребята не осилили декомпозицию? Я такого не писал.
Но в конце концов решает бизнес — насколько надо отказоустойчивость и скейлинг приложению.
Именно так.
Если писать приложение правильно с самого начала, используя контейнеры, то проблем быть не должно. Если это перевод существующего монолита, то это конечно много дополнительной работы. Многие на этом и зарабатывают, помогая перейти на контейнеры.
Вы же наверняка слышали рекомендации, что не стоит начинать с микросервисов, т.к. зачастую получается самая ужасная вещь — распределенный монолит. А лучше начать — с монолита, который решает какую-то задачу, а потом начать его потихонечку распиливать на микросервисы. По-моему, так даже великий Фаулер завещал.
usego
17.09.2019 19:26Ну монолит монолиту рознь. Зависит от апликухи, но по нынешним временам например замоноличивать фронт с API и всяким BL — расстрельная статья. Дробить же API на 100500 контейнеров под каждый метод — та же статья.
dominigato
17.09.2019 19:30Может раньше так и было лучше. Если уже все накатано и народ уже мыслит микросервисами, то не вижу никаких проблем сразу их и писать. Особенно в вебе, где все уже жевано-пережевано.
gecube Автор
17.09.2019 19:33- не умеет средний разработчик в декомпозицию. Если он родит не монолит, то родит "100500 контейнеров под каждый метод — та же статья", как выше пишет usego
- web'ом задачи не ограничиваются. Есть хадупы, (потоковая) обработка данных, телефония и много чего еще интересного.
dominigato
17.09.2019 19:36не умеет средний разработчик в декомпозицию. Если он родит не монолит, то родит «100500 контейнеров под каждый метод — та же статья», как выше пишет usego
Для этого есть Software Architect. Средний разработчик и не обязан уметь.
А вот если не веб, тогда уже интереснее, да. Хотя здесь большинство просто тупо переходит на амазон/гугл/ажур и пользуется облачными сервисами.gecube Автор
17.09.2019 19:39Хотя здесь большинство просто тупо переходит на амазон/гугл/ажур и пользуется облачными сервисами.
Не все могут. По различным причинам. Начиная от специфики российского бизнеса. И кончая ограниченным бюджетом и кругозором.
dominigato
17.09.2019 19:48Насчет бюджета — я часто слышу мысль, что держать спецов по определенным технологиям гораздо дороже чем платить Амазону за менеджмент этих технологий. Так что не все однозначно (с)
VolCh
17.09.2019 20:03Для простого сайта без резервировнаия/масштабирования k8s сожрёт слишком много человеко часов. docker-compose вполне справится, сочетая плюсы контейнеризации с отсутствием минусов конфигурирования огромной системы оркестрации.
gecube Автор
17.09.2019 20:07ansible прекрасно заменяет docker-compose.
Единственное, чего не умеет ansible — это тушить контейнеры по лейблам, но решить это запросом к docker api и фильтром json не проблема.VolCh
18.09.2019 07:24Может и справится, но чем он лучше будет в этом качестве? И можно ли с ним делать такие вещи как
docker-compose logs --follow?dominigato
18.09.2019 07:28docker-compose logs --follow — это для ручных тасков, не для оркестраторов.
VolCh
18.09.2019 09:10Это возможность для отладки того, что оркестратор развернул.
dominigato
18.09.2019 09:15Я имею в виду что эта команда предполагает что человек смотрит на вывод в терминале. А дело оркестратора — задеплоить и свалить с сервера, а не быть залоченным с --follow.
После этого вы можете вручную зайти и смотреть с --follow. Ну или попросить ансибл сделать docker-compose logs в файл и принести вам этот файл.VolCh
18.09.2019 09:24У нас немного разные представления об оркестраторе. Мне вот docker-compose как оркестратор как не нравится тем, что слишком рано сваливает с сервера в отличии от того же docker swarm mode, а ansible вообще как оркестратор не воспринимаю.
gecube Автор
18.09.2019 10:03не нравится тем, что слишком рано сваливает с сервера в отличии
Разверните, пожалуйста, мысль. Какой Вам функционал нужен?
VolCh
18.09.2019 10:04Да вот теже логи агрегированные со всей системы или отдельного его сервиса
gecube Автор
18.09.2019 10:20Ну, выглядит будто Вам не docker-compose logs нужен (тем более, что он отловит только логи, сгенерированные ТОЛЬКО в рамках конкретного "проекта" — по сути из одного docker-compose.yaml), а трейсинг, сопоставление и агрегация в единой панели. Да и завсегда может быть какой-то внешний по отношению к компоуз-файлу сервис, который тоже захочется помониторить. В общем — эта задача не решена. Да и не решаема она без сборки какого-то единого централизованного хранилища логов, но это выглядит так, что про локальную разработку (вообще без интернета, подсоединения к рабочим серверам и пр.) придется забыть.
А если разрабатывать конкретный модуль и все его зависимости мокать, то разницы между docker logs & docker-compose logs нет. Ну, потому что проверяемый элемен один
Единственное для чего я вижу пользу от docker-compose logs или docker-compose up (желательно еще с ключом
--abort-on-container-exit, но это тоже палка о двух концах) — использование в пайплайне CI/CD, чтобы сразу получать лог запуска для последующего сохранения в артефакты и изучения. Но вообще-то для этого есть и более удобные средства, так-то.VolCh
18.09.2019 10:58а трейсинг, сопоставление и агрегация в единой панели.
Да, это было бы идеально, если при этом не надо инвестировать кучу человеко-часов и всё работало бы локально. Но простой docker-compose log хорошее решение.
А если разрабатывать конкретный модуль и все его зависимости мокать
Мы предпочитаем поднимать локально всё приложение, а совсем внешние зависимости типа сторонних API просто не иницализировать локально, если нет тестовых доступов. При этом локально могут быть подняты несколько версий одного приложения, например, мастер ветка и фичи.
Полноценные моки, да с конфигугрированием потребуют много времени, а пользы ощутимой не видится.
gecube Автор
18.09.2019 07:38Вы серьезно пользуетесь это функцией?
Ну, это, как минимум, означает, что Вы пользуетесьdocker-compose up -d, т.к. если бы Вы запускали набор контейнеров без -d, то лог запуска был бы перед глазами — это раз.
Два — ансибл у Вас не отнимает возможность выполнить командуdocker logs -f .., если очень хочется. Выгода компоуза тут преувеличена.gecube Автор
18.09.2019 07:46Ещё интересный момент, что уже появилось поколение людей, которые знают компоуз, разбираются в его ключах запуска, директивах, но абсолютно беспомощны перед лицом "голого" докер-клиента. Занятно, не так ли?
VolCh
18.09.2019 09:20Нормально. Вот уже (лет 30 назад точно) появилось поколение людей, которые используют PRINTF(3), но абсолютно беспомощны перед лицом "голого" ядра, без stdlib, не говоря о загрузке на голом железе, когда и ядра нет. Занято?
VolCh
18.09.2019 09:13Серьёзно. И да, предпочитаю запускать docker-compose up -d, Как я понимаю природу ansible он плохо справится как с docker-compose up, так и с docker-compose logs --follow
docker logs очень неудобен когда хочется иметь агрегированный лог
dominigato
18.09.2019 09:18С docker-compose up вроде никаких проблем. Особенно если вы используете ансибл вместо docker-compose — тогда просто запускаете контейнеры в своем порядке. По-моему именно это gecube и имел в виду.
docker-compose logs --follow это вообще отладочная функция, расчитанная на интеракции с человеком.VolCh
18.09.2019 09:36docker-compose up (без -d) не делает exit/return после поднятия контейнера, ansible не рассчитан (могу ошибаться) на такой режим.
А наличие отладочных функций очень упрощает отладку многопроцессных приложений.
gecube Автор
18.09.2019 09:49Ошибаетесь.
Ансибл прекрасно работает в режиме "наплодил контейнеров и ушел с сервера".
Вот возьмите и попробуйте наконец-то. Чего обсуждать?
Или боитесь, что вдруг понравится?
Мы пришли к ансиблу по следующим соображениям:
- Зачастую недостаточно сделать docker-compose up -d
А нужно сделать ещё кучу действий, чтобы запустить контейнер (мы не про микросервисную архитектуру, а скорее про использование докера как такого пакетноно менеджера) - Зачем на удаленной машине лишний компонент в виде docker-compose? Ну, и если локально на удаленной машине делать docker-compose up, то, как выше уже заметили — у вас уже две проблемы: запуск контейнеров и доставка описания контейнеров в виде docker-compose.yaml на эту удалённую машину
- В теории compose умеет цепляться к удалённому демону. Но это костыли и риски ИБ: кто его знает как там написан docker демон.
- Отсутствие шаблонизации в compose. Зачастую нужно, чтобы одни и те же параметры присутствовали в разных контейнерах (например, бд и бекенд). Или возможно нужно запустить 10к контейнеров из одного образа с разными параметрами. На ансибле эти задачи решаются на раз-два. В компоузе — ихх решить тоже можно, но через копи-паст и боль.
VolCh
18.09.2019 10:01Ансибл прекрасно работает в режиме "наплодил контейнеров и ушел с сервера".
Я о противоположном режиме: наплодил контейнеров и мониторит их.
Вот возьмите и попробуйте наконец-то. Чего обсуждать?
Пробовал. Не понравилось для управления докером. Развернуть докер на новом хосте — нормально. Оптимальным для меня оказался ansible для разворчивания докера в swam режиме и оркестрация через docker посредством docker-compose.yaml. Даже если "кластер" из одной машины, включая мою рабочую. Увы, принято решение на кубик переходить. И, более того, это моя задача обеспечить переход. Вот курю сейчас маны кубика, хелма, хелмфайла и т. п. Причём последние исключительно из-за того, что в кубике нет даже той шаблонизации что есть в docker-compose (интерполяции env в т.ч. из env файлов)
Мы пришли к ансиблу по следующим соображениям:
gecube Автор
18.09.2019 10:14наплодил контейнеров и мониторит их.
docker-compose их не мониторит. Если Вы думаете по-другому, то, извините, но ошибаетесь. Вообще с мониторингом работы контейнеров в docker в целом плохо. Смотрите статью и комментарии.
Причём последние исключительно из-за того, что в кубике нет даже той шаблонизации что есть в docker-compose (интерполяции env в т.ч. из env файлов)
А она там и не нужна. К тому же в kubectl завезли шаблонизатор от гугла — kustomize. Он не идеален, но решает часть проблем.
Некоторые (как коллеги в телеграм каналах https://t.me/ru_devops https://t.me/kubernetes_ru) — тоже используют ансибл для деплоя в куб (почему нет!?)VolCh
18.09.2019 10:38docker-compose их не мониторит. Если Вы думаете по-другому, то, извините, но ошибаетесь
вывод логов с follow — минимальный мониторинг.
А она там и не нужна.
Кому как. Например, я не нашёл простых способов деплоить приложение в разные окружения с разными настройками, зависящими от окружения с которого запускают деплой. Например, версия образа по git branch/tag/hash.
К тому же в kubectl завезли шаблонизатор от гугла — kustomize.
Kustomize introduces a template-free way to customize application configuration
Это не шаблонизатор, а попытка решить задачи, традиционно решаемые через шаблонизатор, без шаблонизатора.
тоже используют ансибл для деплоя в куб (почему нет!?)
Когда в руках молоток…? :) А если серьёзно, то в таких дискуссиях ожидаю получить не вопрос "почему нет?", а ответы на вопрос "чем лучше стандарта де-факто или хотя бы нашего текущего решения и какой ценой (дополнительно к полному переобучению команды и новой зависимости в стэке, пускай и взамен старой) это достигается?"
gecube Автор
18.09.2019 11:07Когда в руках молоток…? :) А если серьёзно, то в таких дискуссиях ожидаю получить не вопрос "почему нет?", а ответы на вопрос "чем лучше стандарта де-факто или хотя бы нашего текущего решения и какой ценой (дополнительно к полному переобучению команды и новой зависимости в стэке, пускай и взамен старой) это достигается?"
Я позволю себе быть немножко смелым и постулировать следующую вещь: если Ваш кластер сам по лучшим рекомендациям GitOps не забирает свое состояние из репозитория (тыц, кстати, не самый плохой подход), то Вам ПРИДЕТСЯ при обновлении софта ПУШИТЬ изменения в кластер через кубернетес-апи. А это, извините, Вы можете делать своим любимым инструментом — что хельмом, что ансиблом, что напрямую применять манифесты YAML через вызов kubectl -f apply. Разницы нет.
Например, я не нашёл простых способов деплоить приложение в разные окружения с разными настройками, зависящими от окружения с которого запускают деплой.
Посмотрите аргументацию почему так, а не иначе:
https://github.com/kubernetes-sigs/kustomize/issues/388
Ну, в крайнем случае патч-файлы или манифесты куба можно на лету генерить (опять отдельный шаблонизатор тащить — будь то envsubst, jinja, gomplate или что еще)...
Либо использовать другие техническая средства вроде jsonnet.
VolCh
18.09.2019 16:22Изучал я все эти аргументации. Основное в них "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. Но в целом понятно — разницы нет.
- Зачастую недостаточно сделать docker-compose up -d
VolCh
17.09.2019 18:36Обычные программисты спокойно им пользуются без всяких проблем, уж точно не «квалифицированные админы».
Справедливости ради, обычному программисту с нуля развернуть в имеющемся кластере к8с в тестовом режиме приложение из пары десятков сервисов, разрулить волумы и ингрессы не так уж и просто. Это понимая как работает докер и имея большой опыт аналогичных задач на кластерах конкурента.
dominigato
17.09.2019 18:40Пользуются докером, а не кластером к8с. Это слегка разные вещи.
Такие вещи делаются не руками, а оркестраторами или системами конфигурации как ансибл и т.д. Если он создает с нуля, то он работает уже не как программист, а как девопс :)
razielvamp
17.09.2019 18:07А с :latest отдельная история была, когда на сервере два года gitlab крутился созданный из latest, а после переустановки хостовой ос на более новую (а вместе с ней и докера и докер-композа, а про совместимость в статье уже было написано), пришлось создавать новый контейнер. Вот тогда пришлось знатно поснашаться, чтобы узнать что же за latest версия была два года назад и потом узнать что в репозитории, оказывается, самой старой версии всего пол года. А все что до этого сожжено в адском пламени.
Да, конечно, это не прямой косяк докера, косяк докера в том, что пока на эти, и многие другие, грабли не наступишь — ничего дурного не заподозришь.gecube Автор
17.09.2019 18:17Могу посочувствовать. Чтобы не попадать в такую историю достаточно сохранять id образа и сам образ (т.к. спустя столь продолжительное время его могут попросту удалить). Есть ещё подход — бежать так же быстро, как и окружающие, и своевременно обновляться, но это прям очень ресурсоемко.
В любом случае, признаю — я тоже задним умом силен, а не передним, но катастрофы проще предотвращать, чем ликвидировать последствия.
dominigato
17.09.2019 14:42Как-то мне надо было привязать сервис в докере на один IP на интерфейсе (из нескольких). Не host mode, не определенный порт, а именно все порты на один IP. Единственное что нашел — это проброс 0-65535 портов на определенный IP. Какое же мое удивление было обнаружить, что вместо того чтобы использовать range в iptables, docker создает там 65535 правил!
Как-то несерьезно даже.
Некоторые выводы в статье конечно не очень в тему, например про dockerhub. Он задумывался как github только для контейнеров, чем он и является. И хорошо свою функцию исполняет. Вы же не жалуетесь что на github много мусора и вообще это помойка?gecube Автор
17.09.2019 15:00Да, хотел привести пример github'а, который тоже превратился в помойку.
Но на самом деле есть разница. Docker Hub мог бы модерироваться Docker Inc по примеру магазинов приложений (Apple Store, Google Play) или репозиториев ПО (любой серьезный репозиторий любого серьезного дистрибутива). Но нет. В docker hub даже не всегда можно понять ИЗ ЧЕГО получен образ и какова его история изменения. А в гитхабе никто ничего не гарантирует. Вообще.dominigato
17.09.2019 15:05В dockerhub есть официальные образы, от компаний или сообществ — типа PostgreSQL, Apache т.д. Если нужно что-то официальное, то это к ним.
Все остальное делают сами люди, в том числе и я. И уже чего точно не надо, так это модерации а-ля гугл в андроиде. Это прямой путь отвратить от себя всех разработчиков)) Если бы модерировали гитхаб от всяких хелловордов, он бы никогда не стал бы гитхабом.gecube Автор
17.09.2019 15:40В dockerhub есть официальные образы, от компаний или сообществ — типа PostgreSQL, Apache т.д. Если нужно что-то официальное, то это к ним.
тем не менее — даже официальные образы имеют определенные родовые болячки и требуют доработки напильником. Например, самое очевидное — разброд в том, каким образом передавать настройки приложения. Какие-то образа ждут переменных окружения, какие-то — файла конфигурации. Другой вопрос, что да — докерхаб позволяет взять готовый образ и протестировать какую-то гипотезу быстро. Относительно быстро, учитывая время необходимое для того, чтобы разобраться как с конкретным образом работать. Но в production это пускать… Такое себе. А собирать все образы под себя — просто умрешь от объема работы.
usego
17.09.2019 16:50Какой объём работы? Если у вас уже есть скриптование для инсталяции серверов / виртуалок (надеюсь оно есть??), то всё это в докера переводится на раз два. Команды ведь те же плюс минус.
gecube Автор
17.09.2019 16:55то всё это в докера переводится на раз два
Нет. Нужно учитывать специфику докера. volume, init, права пользователей, отсутствие systemd и пр. пр. Поэтому — не раз-два.
usego
17.09.2019 17:01Ну ок, да, софт надо готовить к докеризации и оркестрации. Но стрёмный дремучий монолит не делает докер плохим. Это монолит плохой и нуждается в рефакторинге независимо от докеризации. Докеризация — это не только про packaging, это про подход к разработке софта, что бы получать от всего этого максимум пользы.
gecube Автор
17.09.2019 17:31Так докер не про микросервисы, а контейнеры. Как бы немного ортогональные вещи.
А для написания современного софта совершенно неглупые люди придумали 12FA.usego
17.09.2019 17:40Смешались в кучу кони, люди. Ладно, нам оно помогает делать процесс эффективней и прозрачней, как бы это ни называлось. За статью спасибо, но в реальной жизни таких проблем просто нет, при правильном подходе к работе. Даже перечитал ещё раз пункты, что бы не соврать. Ну одно это чего стоит:
В теории можно задать максимальный размер и параметры ротации, но кто это делает? Только честно
Да все это и делают. 3 строчки в конфиге. Потому что те, кто с этим реально работал, на эти грабли наступали уже N лет назад и давно приняли на вооружение как best practice. Так же и с остальным.gecube Автор
17.09.2019 17:51Ну, вот смотрите честно — из коробки никаких лимитов нет (мы же помним, что дефолтные настройки почему-то всегда оторваны от жизни). Соответственно, я почти наверняка уверен, что каждый пользователь докера сталкивался с переполнением диска от логов.
Можно написать целый талмуд с рекомендациями (от "ограничивает размер логов" и "используйте другой драйвер логов" до "выделяйте под докер отдельный том (раздел)) — только толку? Как стреляли люди себе по ногам — так и будут.
Что интересно — единого свода таких эксплуатационных рекомендаций (по сути — best practice) я не видел. Может плохо искал. Поэтому каждый ходит по граблям самостоятельно. Иногда это весело. Иногда не оченьusego
17.09.2019 17:57Это инструмент, требующий кривую обучения. Эта кривая не проще, но и не сложнее любой другой, будь то работа с bare metal или грамотное обслуживание виртуализации.
gecube Автор
17.09.2019 17:59Не соглашусь, но это мое частное мнение. Любая последующая абстракция в идеале требует понимания всех лежащих в основе ее. Сможет ли разработчик эффективно работать с докером (писать докерфайлы, запускать/отлаживать контейнеризованное приложение и т.п.) не зная вообще баш, основы сетей, основы линуксе и прочее? Чего-то я очень сильно сомневаюсь.
usego
17.09.2019 18:14Сколько раз мы это слышали по мере появления новых технологий? ;) Абстракции ведь и позволяют создавать специализации, не требующие досконального понимания тех основ, на которых они работают. Так же как сетевику не нужно возиться нынче с осциллографом, так и относительно современном админу уже не приходится залезать в кишки операционки (говорю про «средний» уровень проектов). Да вот те же облака взять. Нужно ли современному админу разбираться в мясе виртуализации, что бы запустить хай лоад на 1000 виртуалок? Не помешает конечно, но в реальности, это уже не требование при работе именно с облаками.
dominigato
17.09.2019 18:16Как раз чтобы запускать
docker run -d nginxничего из вышеперечисленного знать не надо. К тому же именно так легче всего дать человеку представление о среде в которой ему работать. В отличии от миллионов просроченных инструкций как запускать виртуалку и что там с ней делать.gecube Автор
17.09.2019 18:20Если задача — изучить nginx — да.
Если задача — быстро получить работоспособный сайт — да, но с оговоркой, что у коллеги должен быть докер соответствующий версии, правильно настроены права на каталоги и пр. пр. (что относится к окружению).
Внезапно — передать готовую виртуалку проще (за исключением того факта, что она "жирнее" и "весит" больше гигабайтов, чем контейнер).
А если вы пытаетесь под докером гонять машинное обучение… То там просто тьма нюансов с версиями nvidia, ядер и прочегоusego
17.09.2019 18:23>правильно настроены права на каталоги и пр. пр
какие права? Всё эти кишки заботливо упакованы более опытными людьми в сам контейнер. Этим докер и прекрасен именно в контексте тимворка.gecube Автор
17.09.2019 19:42А то, что разраб, когда разрабатывает — не будет пересобирать контейнер на каждое изменение (хотя возможно лучше, чтобы пересобирал). Настраивается bind mount + hot reload, по возможности. И дальше потенциально начинаются проблемы с правами — код-то снаружи контейнера. Интересная дискуссия была в треде. Я там накидал элементов супового набора, которые могут помочь решить эту проблему… Но ее ведь приходится решать и городить свой очередной велосипед.
Ес-но, для продакшена такое не годится — когда образ едет в продакшен в него запекается: код, конфиги, какие-то данные (например, веса ML-моделей, статика для веба). Это все снижает проблемы ТАМ, но не здесь, на машине разраба.
gecube Автор
18.09.2019 01:27Вот отличный пример "изоляции" — https://habr.com/ru/post/467607/#comment_20634225
dominigato
17.09.2019 18:30+1Контейнер будет работать на докере любой из последних версий. Не знаю зачем человеку ставить версию 5 летней давности и где ее даже найти. И скорее всего на ней он тоже будет работать.
Если это несколько сервисов, то передается docker-compose.yaml где все настройки уже включены. Обычно это эмулирует среду на продакшн и помогает разрабам избежать разных ошибок, связанных со средой. Копирование продакшн среды по-моему одно из самых главных преимуществ контейнеров.
Виртуалку нужно постоянно апдейтить, перестраивать, настраивать шеринг директорий, и т.д. и т.п., да и легче запустить одну команду, чем тащить лишние гигабайты.
Для локального девелопмента я бы однозначно выбрал бы контейнер, а не виртуалку.gecube Автор
17.09.2019 19:01С тем же компоузом — есть матрица совместимости версий:
https://docs.docker.com/compose/compose-file/compose-versioning/
И там далеко не все форматы работают на любых версиях compose. И не любая версия compose работает с любой версией docker демона. И, да, я в это наступал.
Но соглашусь — что это-то как раз является решаемой проблемой.
Еще могу отметить, что у того же редхата своя нумерация версий (у них до сих пор docker 1.13).
Обычно это эмулирует среду на продакшн и помогает разрабам избежать разных ошибок, связанных со средой. Копирование продакшн среды по-моему одно из самых главных преимуществ контейнеров.
Это отчасти миф. Невозможно полноценно воспроизвести на машине разработчика продакшн среду. Всегда будут какие-то отличия. Ну, например, трафик. Вы сможете влить на машину разраба столько трафика сколько в продакшен среде? Нет. А это и не нужно. Или может отличаться архитектура процессора (а там связанные с этим оптимизации). Или минимально необходимый набор сервисов для запуска тупо не влезает в машину разраба. А может это и не нужно — можно либо подцепиться к клону продакшена снаружи, либо замокать сервисы-зависимости. И пр. пр. пр.
В каждом случае граница определяется индивидуально.
Виртуалку нужно постоянно апдейтить, перестраивать, настраивать шеринг директорий, и т.д. и т.п., да и легче запустить одну команду, чем тащить лишние гигабайты.
Vagrantfile + vagrantbox — вполне повторяемая и удобная среда.
Для локального девелопмента я бы однозначно выбрал бы контейнер, а не виртуалку.
Соглашусь, что при прочих равных — контейнер и стартует быстрее, и кушает меньше ресурсов, и как-то docker удачнее зашел в среду смузихлёбов (сам такой ))), поэтому — да, возможно, что для локальной разработки докер будет удобнее.
dominigato
17.09.2019 19:27Всегда можно ставить docker-ce с сайта определенной версии. В одной компании нет проблем договориться какую версию docker-compose использовать.
Ну, например, трафик. Вы сможете влить на машину разраба столько трафика сколько в продакшен среде? Нет
Во-первых это не вопрос среды. Во-вторых — конечно могу. От самонаписанного скрипта до разных сервисов, которые забомбят ваш сетап еще больше чем в продакшне. Но это как-бы уже перформанс тестирование, немного другая история.
Или может отличаться архитектура процессора (а там связанные с этим оптимизации).
Если веб приложение зависит от архитектуры процессора, с ним что-то не так. В таком случае есть тестовые среды с нужной архитектурой. Если таких нет, то проблема такая же и с виртуалками, нет никакой разницы.
В большинстве разрабу нет необходимости копировать абсолютно всю среду продакшена, достаточно сервиса который он разрабатывает и то что к нему относится. В остальном обычно нет критической нужды. Виртуалки тут тоже вряд ли помогут.VolCh
18.09.2019 09:39В большинстве разрабу нет необходимости копировать абсолютно всю среду продакшена, достаточно сервиса который он разрабатывает и то что к нему относится.
Прямо необходимости может и нет, но очень часто разворачивание всей среды локально заметно повышает скорость разработки/отладки/тестирования. Пока она помещается локально, конечно.
usego
17.09.2019 19:36Он не случайно туда зашёл. Он тупо удобней и убирает многую ненужную возню и многих важно раздувающих щёки админов, билд инженеров и прочую нечисть, которым приходится переквалифицироваться в нечто ближе с непонятночтоозначаещему DevOps. В общем смиритесь. Можно его ненавидеть, но это то, с чем придётся работать ближайшее десятелетие так точно :))
amarao
17.09.2019 14:44два момента: докер популяризовал не контейнеры (как технику запуска), а контейнеры (как технику пакетирования). Квадратно-гнездовой деплой — это правильно.
Второе, нативный докер не совместим с жизнью на десктопе линукса. После наблюдения за тем, во что превращается машина при запуске тестов (testinfra) в локальном докере я поднял виртуалку (kvm) и сделал докер на ней (так же, как это в маках и т.д.) — и оно стало работать (как в маках). Т.е. маководы, которые завидуют "нативному докеру" могут перестать завидовать.
dominigato
17.09.2019 14:48+1Во что превращается машина?
Не совсем понятно — что значитсделал докер на ней (так же, как это в маках и т.д.) — и оно стало работать (как в маках).
? Как она работает в маках я немного знаю, не понимаю как к этому можно стремиться.gecube Автор
17.09.2019 15:02Видимо, testinfra создает слишком много контейнеров и не очень подчищает хвосты за ними? Тоже не совсем понял, хотелось бы подробностей.
Но, кстати, знаю людей, которые ставят lxc/lxd и внутрь загоняют docker.
amarao
18.09.2019 14:03Я обнаружил, что у меня
а) меняется hostname на несвязной консоли
б) logind и другие системные демоны сходят с ума поедая тонны CPU.
Я сделал как на маках — есть виртуалка, внутри которой докер, а локальный докер-клиент к ней коннектится через бридж.
bisquitie
17.09.2019 15:10Докер без сворма в продакшене для меня непредставим. А сворм они давно похоронили, что очень печально. Вообще, докер — не для серьёзного продакшена.
denis-vc
17.09.2019 15:40+2Работаю с докером уже несколько лет. В двух последних проектах рискнул выкатывать и на прод тоже. Так уж получилось, что на фоне других частей проекта — эта не самая проблемная. А значит в немедленной замене не нуждается.
Наверное есть что-то похожее, но другое. Наверное, у всех найдётся за что попинать этот (и любой другой) инструмент. Но.
Мои задачи с ним выполняются быстрее, чем без него. Проблемы бывают, но я уже готов их решать. Есть граничные случаи, есть баги между версиями, но со всем этим в принципе можно жить.
Бывают трудные места для понимания и объяснения другим, но в целом кривая обучения довольно пологая. Инвестиции от обучения сотрудников базовым навыкам возвращаются быстро. Новые сотрудники могут начать работу в течение нескольких часов. И большая часть этого времени не будет связана с контейнерами (поставить, настроить IDE, и прочее).
Хочу попробовать инструмент от Фланта (flant/werf aka dapp), хочу заменить bash-скрипты на ansible и make-файлы, собираюсь развернуть кластер k8s… Но это не мешает мне уже работать и решать свои задачи достаточно эффективно.
Хочу сказать, что докер — он как танк. Даже самый лучший и современный танк обладает врождёнными родовыми уязвимостями. Но никто в здравом уме не пошлёт танки в бой без пехоты и других видов техники, которые эти уязвимости будут закрывать. Докер — для командной игры. Некоторые его недостатки можно и нужно закрывать другими инструментами. Например, виртуальными машинами.
Но, самое главное — что кроме докера, как реализации, есть ещё runC и другие спецификации, которые подстёгивают развитие альтернативных реализаций отдельных кубиков workflow контейнеризации и оркестрации.
И уж конечно, дольше докера проживёт сама идея «инфраструктура как код». На чём бы вы её не воплощали — это уже большой шаг от ремесленника к инженеру. Начните с чего угодно — главное начать.gecube Автор
17.09.2019 15:42Спасибо, очень интересное мнение.
Касательно "инфраструктура как код" — эта идея началась РАНЬШЕ докера, причем существенно. Примерами ее реализации являются SCM (системы управления конфигурацией): Chef, puppet, ansible, salt. Сейчас это все, конечно, переходит на следующий, новый уровень описания. Появляются более высокоуровневые инструменты вроде terraform/cloudformation. В общем — все очень интересно и здорово.denis-vc
17.09.2019 16:15Я не утверждал, что докер был раньше. Я говорю, что инструменты вторичны — первичны идеи и паттерны. Пакеты, модули, контейнеры — это всё про одно: инкапсуляция, наследование, полиморфизм :)
Именно поэтому я радуюсь, что докер дорос до того, чтобы для борьбы с ним большие дяди объединились и написали спецификации. Чтобы вы могли заменить его по частям на что-то более зрелое, конструктивно православное и т.п.
xtotec
17.09.2019 15:42Вот!
А ещё «докеризация» способствует лени программеров. Вместо полноценного вменяемого INSTALL, встречаешь «устанавливайте докер, тяните вот этот имидж из регистри, запускайте вот так».
Зла не хватает.gecube Автор
17.09.2019 15:43Несомненно — докер прививает вредную привычку заметать весь мусор под ковер, т.е. внутрь контейнера. Даже не разбираясь как оно работает. Ну, что остается. Писать регламенты, осуществлять процессы контроля безопасности образов, пытаться уменьшать их размер и пр. пр. пр.
denis-vc
17.09.2019 16:19Докер ни причём. Промышленная революция требует всё большей глубины разделения труда и унификации процессов производства. В контексте обсуждаемого вопроса глубина разделения этого труда реализуется через делегирование отдельных этапов сборки контейнеров… Но это не запрещает осуществлять самый разный контроль над результатами такого аутсорса. И над внутренними процессами тоже.
VolCh
18.09.2019 09:01Это не заметать мусор под ковёр, это запирать тех, кто мусорит в отдельной комнате, общаясь с ними через окошко в двери, а разбираться с ними в индивидуальном порядке при необходимости и(или) появлении желания. Это лучше чем собирать их вместе в опенспейсе и позволять мусорить, зачастую даже не имея возможности определить где чей мусор.
Arepo
17.09.2019 18:13+1Всё совсем наоборот: Dockerfile (и композ) — это и есть INSTALL, только формализованный и тестируемый.
ALexhha
17.09.2019 20:39+2Ну как сказать. Иногда нужно запустить какой то стек, чтобы посмотреть или проверить что-то. Например тот же ELK. И мне не хочется тратить час времени на чтение документации к каждому из компонентов этого стека. Ибо при установке по Readme/INSTALL может выясниться, через час дебага, что у тебя не совместимая версия ОС/библиотеки. А поймешь ты это только по issue на гитхабе, если повезет
gecube Автор
17.09.2019 21:13И согласен, и нет. Именно с ELK прекрасный пример, когда требуется настройка хост оси. Без того, чтобы прописать на хосте
vm.max_map_count=262144ничего не заработает. И они мне тут про изоляцию от среды рассказывают...
xtotec
17.09.2019 22:41Моя, лично, печаль в отсутствии альтернативы.
Вам некогда выяснять всё ли у вас совместимо со стеком разработчика, а хочется docker pull… и поехали, А мне — совсем наоборот — хочется выполнять инструкции из INSTALL, и может даже по ходу пьесы где-то там что-то подправить в исходниках, чтобы оно работало на моих системах как минимум так как обещает разработчик, как максимум — так как хотелось бы мне.
Кстати, получение вот такого совместимого с самим собой «чёрного ящика» лишает меня возможности копаться внутри апликухи с целью исправления чего-то там мелкого или кастомизации под себя. Потому что, одно дело — включить дебаг лог, посмотреть что не так и поправить 1-3-5-10-15 строк, другое дело — «сначала установить docker, docker-compose и ещё 33 зависимости...», а потом пересобирать/запускать имидж со своими правками?
Но вот тут уже мне лень, скорее всего в сторону того, что работает только в докере смотреть я просто не будут.lair
18.09.2019 00:20+1А мне — совсем наоборот — хочется выполнять инструкции из INSTALL
Ну так это, находите dockerfile от образа, и выполняете.
Потому что, одно дело — включить дебаг лог, посмотреть что не так и поправить 1-3-5-10-15 строк
А вы ожидаете, что вам приложение с исходниками дадут? А почему, собственно?
xtotec
18.09.2019 01:09Если я беру приложение с открытым исходным кодом, то это подразумевается.
lair
18.09.2019 12:02Вот так же и "подразумевается", что вы способны прочитать dockerfile вместо install, и подправить, что вам нужно и где. Так что никто вас альтернатив не лишает.
xtotec
18.09.2019 19:56+1Если этот dockerfile мне дают. Частенько именно до этого руки как раз и не доходят.
Но встречалось и такое как
«baseimage у нас ubuntu:/latest, для него мы сделали 2 dpkg, вот вам dockerfile, в котором происходит apt-get install ..., ну дальше там разберётесь»… Конечно, всё же очевидно.lair
18.09.2019 21:15Dockerfile — часть исходников. Если вы ожидаете, что вам дадут исходники, то логично ожидать и докерфайл. Если же вам исходники дают частями, то не важно, докер или не докер.
gecube Автор
18.09.2019 12:11-2Ну так это, находите dockerfile от образа, и выполняете.
И внезапно выясняетя, что те файлы, в нем используются — уже недоступны, т.к. удалены. Или в докерфайле не зафиксированы версии устанавливаемого ПО и при сборке ты получаешь вроде бы то же самое, но бинарно другое. И прочее, прочее.
Несомненно — наличие докерфайла как концепции, как чертежа УЖЕ сильно облегчает жизнь и позволяет наводить мостики между разработкой и эксплуатацией. Но этого недостаточно.lair
18.09.2019 12:12+1И внезапно выясняетя, что те файлы, в нем используются — уже недоступны, т.к. удалены
Чем это отличается от "берешь INSTALL, и внезапно выясняется, что..."?
dominigato
18.09.2019 00:25«сначала установить docker, docker-compose и ещё 33 зависимости
Не надо 33, только docker и docker-compose = 2. Остальные зависимости оставьте пакет менеджерам.
потом пересобирать/запускать имидж со своими правками
Нет, потом docker commit и продолжайте наслаждаться своим имеджем.xtotec
18.09.2019 01:18+1Да не собираюсь я наслаждаться имиджем и всеми, сопутствующими наличию докера в системе побочными эффектами, которые ТС так тщательно перечислил.
Это из разряда логики — - Мы вам продадим этот седан, но чтобы им пользоваться, вам надо приобрести асфальтоукладчик. Не обязательно брать у нас, выберите ваш любимый цвет.
— Но позвольте, а можно я буду ездить по уже готовым дорогам?
— Ну нет, а вдруг дороги будут слишком узкие, или скользкие. Возьмите асфальтоукладчик — он проложит оптимальные дороги именно для вашей машины — экономия топлива максимальная и никаких ухабов. Будете быстро ездить и безопасно.
— Но я не хочу укладывать асфальт.
— Ну тогда мы не продадим вам машину, она едет только после асфальтоукладчика. Напрасно вы отказываетесь — управлять асфальтоукладчиком совсем несложно, вам понравится, может даже будете потом сами дороги прокладывать, освоите смежную специальность…dominigato
18.09.2019 01:21Вы извините, конечно, но я не понял вашей длинной аналогии. Вы написали какие проблемы вас беспокоят, я написал как они решаются. Или не проблемы вообще. Если у вас есть еще какие-то — пишите, обсудим.
norguhtar
18.09.2019 06:30Я вон выше про lxc/lxd писал. Что если мне надо изолировать в контейнер nginx+uwsgi + db то в docker по идеологии я должен создать три контейнера. В итоге мне сказали ну дак можно же взять k8s и там есть pod это удобно! Да действительно для контейнеризации 3 процессов мы возьмем оркестровщик рассчитанный, на десятки-сотни серверов и сотни-тысячи контейнеров. В случае lxc/lxd того же я просто сделаю один контейнер и настрою в нем необходимое. На любом языке можно решить любую задачу, если он тьюринг полный. Но при этом не на всех языках задача решается с одинаковыми трудозатратами.
dominigato
18.09.2019 07:31Вы как-то быстро подменили docker на к8. Абсолютно неважно на сколько к8 расчитан, важно сколько он ресурсов берет в вашем случае. Слишком много? Не берите к8, оставайтесь с docker/podman.
norguhtar
18.09.2019 07:37Это не я. Это мне тут люди пишут, что если вам надо такое используете k8s. Просто тут момент есть интересный с docker. Как с регекспами. У вас есть проблема. Вы узнали что ее можно решить при помощи регекспов. Теперь у вас две проблемы. Вот так и с докером.
usego
18.09.2019 09:05-2Вы меня извините, но все эти «проблемы» высосаны из пальца. Такое ощущение, что ищется любой предлог, лишь бы не признавать очевидное — докер/контейниризацию придётся принять и жить с этим, так как такой подход стал industry standart. И неважно во что он реинкарнирует через N лет, общий подход останется.
Будет как в Вистой. Только ленивый не написал как она плоха. Сейчас же все сидят на той же самой слегда допиленной висте (10ка) и не жужат.VolCh
18.09.2019 09:41Не все сидят. Для некоторых именно Виста стала причиной использования других ОС как основных.
norguhtar
18.09.2019 09:44+2Я не против контейнеризации и виртуализации. Это хорошая технология и очень часто позволяет сильно упросить жизнь. Я критикую как она реализована в докере. А реализована она на редкость корявенько и с большим количеством велосипедов. Но благо так-как это приняли как industry standart туда пришли нормальные инженеры. В итоге через несколько лет этим наконец-то можно будет пользоваться без содрогания.
gecube Автор
18.09.2019 09:59Ага. А в результате мы имеем такую ситуацию (комикс xkcd про стандарты):
В итоге через несколько лет этим наконец-то можно будет пользоваться без содрогания.
полностью согласен.
VolCh
18.09.2019 08:57Как замечено выше, файлы докера и есть INSTALL, но обязательно вменяемый (тестирование работоспособности предполагаем), а у ленивого программиста простого текстового вообще может не быть или быть такой, что лучше бы его не было.
khim
17.09.2019 22:09+1Насчёт «умных людей» — это просто какой-то странный наезд. Docker, который от WindowMaker появился чуток пораньше, чем Docker, о котором вы тут пишите — на какие-то лет 10, всего-то навсего. И тогда же, в 2002м был превращён в пакет.
А как вы решаете проблему коллизий имен с программами, которые кто-то напишет в 2030м году? У вас хрустальный шар есть? Не расскажите — чего он умеет?
galserg
17.09.2019 23:16-7какая жесть
мне казалось, что хабр — более профессиональная площадка.
а что в статье, что в комментариях — уровень «программиста 1С»
Автору б на конференции что-ли сходить, особенно по теме девопс, в которой он абсоютно ни в зуб ногой
билд инженер — это вымирающий динозавр в конторах, которые пилят дичайшие легаси монолиты. админ — это эникейщик который картриджи меняет. ВСЕ! в разработке админов не осталось. от слова совсем.
все норовят уйти в клауд, при невозможности — арендованные бареметал решения, на которых работает тот же кубер, номад, опеншифт.
ну не осталось в товарном к-ве задачь, где требуется sql база на надцать терабайт с доступом в миллионы операций в секунду.
другие тренды в разработке.
поэтому клауд ориентированные контейнеры обернутые оркестратором — рулят
кстати, внезапно, при переходе с композа на кубер — разработчикам стало ЛЕГЧЕ. Ну, если девопс хороший, конечно.
А чистый докер я уже лет 5 как не запускал.
кстати, по поводу к-ва контейнеров. не, понятно, что если на делфи педалить лабы в универе — их будет как пальцев на руке у пиромана. но вот нормальный проект — это уже давно не фронт+бек+база.
я для дев окружения использую миникуб, так вот, столкнулись с тем, что уперлись в ограничение в 110 под (запущеных контейнеров) на одну ноду. И это — обычный проект, не фейсбук.galserg
18.09.2019 00:29-6о, минусуют. за «программиста 1С»?
а как еще оценивать пост «я, в 2019 году, наконец-то начал аккуратно использовать докер в проде?
а код вы, извините, храните где? на дискетке 3,5 дюйма, или начали наконец-то использовать svn? или до гита добрались?
мир РЕАЛЬНОЙ разработки давно уже переживал и выплюнул все „проблемы“ поднятые автором. и ушел от них настолько далеко, что отсель не видать.
сейчас занимаются аркестраторами, аркестрирующие аркестраторов, а отличия композа 2 от 3 забыли за ненужностью.dominigato
18.09.2019 01:17+3Может не стоит всех оскорблять в треде и пытаться выставить себя д'Артаньяном?
Вы говорите о мире веба, почему-то представляя его как МИР РЕАЛЬНОЙ РАЗРАБОТКИ!!
Представьте себе, IT не ограничивается вебом, и продукты могут быть очень разные. Поэтому то, что принято в какой-то определенной области совсем не является таким в другой.
У меня прям фуражка капитана выросла пока я это писал.
norguhtar
18.09.2019 06:33+1Минусуют за то что выдаете окружающую вас действительность за общий тренд. Плюс вы там делаете такое вот допущение:
кстати, внезапно, при переходе с композа на кубер — разработчикам стало ЛЕГЧЕ. Ну, если девопс хороший, конечно.
А если нет? Причем если тут ерчь про composer php. То он внезапно более универсальное решение. Которое можно обернуть куда угодно и как угодно.
VolCh
18.09.2019 09:51+2все норовят уйти в клауд
Не все норовят. Пускай многие (опять же не все) отказываются от собственных серверов, не говоря о "серверных", но ограничиваются арендой бареметал, а разворачивают и поддерживают "кубер, номад, опеншифт" сами. Иногда ещё базовую поддержку покупают, но с постоянными платными тикетами типа "добавьте на все ноды вот этот самоподписанный сертификат CA, раз доступа кнодам не дали", "обновите ингресс до последней версии, раз к его неймспейсу дорступа не дали" и т. п.
кстати, внезапно, при переходе с композа на кубер — разработчикам стало ЛЕГЧЕ
Вот как такой разработчик не могу согласиться. Количество сущностей в кубике на порядок выше, если не больше.
Ну, если девопс хороший, конечно.
А если его нет? Ну или он требует готовые конфиги, в которых он только права и ресурсы прописывает?
ALexhha
18.09.2019 13:15+1другие тренды в разработке
а можно узнать источник этих трендов?
поэтому клауд ориентированные контейнеры обернутые оркестратором — рулят
опять таки, на основании чего такой вывод? В амазоне не было нормального оркестратора, aws fargate не крутил, ничего не скажу, да и появился он совсем недвно.
кстати, внезапно, при переходе с композа на кубер — разработчикам стало ЛЕГЧЕ
Т.е. когда человеку надо запустить nodejs приложение или банальный LAMP, предлагаете использовать кубик? И в чем проявилась легкость после перехода?
SergeyEgorov
18.09.2019 14:05А еще, если использовать использовать docker swarm режим, то через некоторое время обнаруживаешь что у бэкенда за балансировщиком нагрузки нет нормальной возможности узнать реальный IP адрес клиента, который отправил запрос.
VolCh
18.09.2019 16:25Не припомню таких проблем, хотя, может, от балансировщика зависит. А может и была "проблема", которая решилась одной строчкой в кофиге после чтения доки балансировщика
gecube Автор
18.09.2019 16:32Это действительно техническая проблема, т.к., очевидно, что докер работает через файрволл и там магия с iptables, то он легко может подменять адреса real-ip клиента, причем безвозвратно.
Но, как правильно, говорите — все упирается в тип балансировки и способ взаимодействия с сетью используемого proxy (nginx, traefik и пр.).
SergeyEgorov
18.09.2019 17:35Есть некие способы "решения" этой проблемы, но все это некоторого рода костыли.
chemtech
18.09.2019 16:58Дополнительно к статье станица Docker: Security Vulnerabilities
www.cvedetails.com/vulnerability-list/vendor_id-13534/product_id-28125/Docker-Docker.html
nitrat665
18.09.2019 21:19Докер вообще «модная» технология. В последнее время заметил, что дата инженегру по вакансии требуется докер, кубернетис и амазон клауд, даже если единственная используемая технология — PostgreSQL on premises.
xtotec
19.09.2019 00:05-1Эт всё менеджеры придумали, чтобы
денег не платитьсэкономить на позиции сисадминов. А потом «пошлО в массы» — модное, трендовое значит хороший специалист должен в него уметь.
Как показывает практика магнитолы — это гибрид неважного радио с посредственным магнитофоном, вот и ДевОпсы…
gecube Автор
20.09.2019 12:26Еще вспомнил, что вымораживает.
Если качаешь большой образ, то обычно делаешь docker pull. Все здорово, все классно — слои качаются в параллель и т.п. А дальше начинаешь видеть недостатки
- второй образ в параллель не поставишь. Точнее поставишь, но он будет ждать, пока скачается хотя бы 1 слой первого.
- если случайно закрыть сессию, в которой происходит docker pull — закачка большого образа оборвется. Хотя странно — она же ведь не на клиенте происходит, а на сервере. Кхм.
- если закачку оборвать, то все скачанные слои удаляются. Поэтому прервал закачку большого образа — будь добр перекачивать все слои заново. Где логика? Чтобы это обойти каждый промежуточный слой можно оформлять в виде отдельного образа — тогда можно обеспечить докачку.
- docker save | docker load и прочие механизмы не обеспечивают послойного скачивания образа — только docker push/docker pull.
- не проверял — но при параллельном скачивании двух образов — возможно как-то криво срабатывает кэширование и если они сделаны с общими слоями, то они будут скачены параллельно (т.е. дважды). Не уверен, правда.
gre
> Директива depends_on, которая вроде как за это отвечает — бесполезна
wait-for.sh упомянуть бы
gecube Автор
Коллеги неоднократно упоминали
wait-for.shв контексте статей про Докер, здесь на Хабре. Например, хотя бы тутК сожалению, это неидеальное решение, т.к. контейнер получается запущен и ждет остальные (т.е. как минимум — кушает ресурсы).
gre
понятно, что это костыль, который, если не путаю, даже в доке упоминается
но по ресурсам это дешевле, чем если контейнер рестартуется
Deissh
Ну так есть ещё health check с помощью которого можно явно проверять статус контейнера и переходить к запуску следующего.
gecube Автор
Не работает. Точнее не так — это функционирует только в момент
docker-compose up, если мы говорим про отдельные докер-хосты (пример). Либо в случае кубернетеса — там вообще отдельная и другая история.Обычно же шибко вумные коллеги говорят, что если вам нужен порядок запуска контейнеров, то вы что-то делаете не так.
eumorozov
А как должно быть? Многие веб-приложения, например, не запустятся, если в момент запуска недоступен SQL сервер или Redis, так как им для старта нужно прочитать какие-нибудь конфигурационные переменные из базы данных или еще откуда-нибудь.
Что предлагают умные коллеги? Стартовать сервис по первому обращению к порту? Но docker из коробки такую функциональность вроде бы не предоставляет.
gecube Автор
Вариантов-то немного.
К тому же, обычно бест пректис — выносить БД наружу, не держать ее на том же хосте, что и приложение-клиент (могу подробнее обосновать, если не очевидно почему).
eumorozov
Мы вроде бы сейчас говорим о первоначальном запуске. Из моего опыта, многие продукты или даже фреймворки ожидают, что в момент старта приложения БД готова отвечать на запросы.
Неспроста ведь всякие
wait-for.shпоявились — докер ломает подобные предположения, или получается, что в зависимости от времени суток и тому подобных факторов, конфигурация либо стартует, либо нет.gecube Автор
А можете пояснить — чем принципиально на Ваш взгляд отличается
wait-for.shот try/except/retry в самом приложении?eumorozov
По идее ничем. Но большинство уже написаного до докера софта не ждет, что именно в момент старта база будет недоступна. Так-то да, специально для докера можно в код инициализации добавить ожидание базы данных.
Но на мой взгляд, это костыльно, да еще и возникает проблема неожиданно. Думаешь, вроде бы упаковал приложение в докер, и вроде все работает, а оно вдруг каждый пятый раз отказывается стартовать. И простое решение не всегда существует. А до докера могло десятилетями нормально работать.
Или мы о каких-то разных вещах говорим?
dominigato
Во-первых приложение не должно заморачиваться вещами как докер и его особенности. try/except/retry при отсутствии базы не всегда может быть хорошим решением, если база упала то может лучше остановиться и громко кричать о помощи.
Во-вторых, wait-for это костыль, который по идее должен быть частью docker-compose, но видимо они понадеялись на healthcheck.
eumorozov
healthcheck у меня почему-то не решал проблему. Правда никак не могу вспомнить почему именно. Скорее всего, как обычно, кривая реализация и еще более кривая документация в Docker.
Прошу прощения за голословные обвинения, но экспериментировал с healthcheck год назад, восстанавливать ту конфигурацию и пытаться воспроизвести проблему ради комментария, считаю не заслуживающей усилий ситуацией.
Но точно помню, что не решал проблему healthcheck. Возможно, я что-то делал не так, как рассчитывали создатели docker, что неудивительно, принимая во внимание полную бесполезность официальной документации.
eumorozov
Минус уже поставили. По-моему, суть в том, что healthcheck служит для того, чтобы определить упал контейнер или нет, но он не применим для уточнения порядка запуска контейнеров. То есть, он не является механизмом, позволяющим запускать докер приложения после того, как база готова отвечать на запросы.
gecube Автор
несомненно. А еще, если мне память не изменяет, то докер не перестартует контейнер в failed state. Только если тащить внешние модули вроде https://hub.docker.com/r/willfarrell/autoheal/ или https://github.com/containrrr/watchtower (но последняя больше для авто-обновлений)
Это хабр. :-(
gecube Автор
Вообще-то я про это же и говорю. Что это зависит от конкретных требований и ситуации.
Praksitel
Я для этой цели использую dadarek/wait-for-dependencies