Исповедь docker хейтера

    Я должен признаться. Я ненавижу 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 как более новый и удобный способ сборки и многое другое, но это общей картины все равно не меняет — все эти фичи достаточно сырые и непродуманные.

    Support the author
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 468

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

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

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

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

              +3

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


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

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

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


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

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

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


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

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

                    +2

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


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

                      0

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

                        +1

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


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


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

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

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


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


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

                              0

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

                                0

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


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

                                Это хабр. :-(

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

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

                    0
                    Я для этой цели использую dadarek/wait-for-dependencies
                +19
                Критика, мне кажется, обоснована. Но каковы альтернативы?
                Мы живем в такую эпоху, кто первый тот срывает банк.
                Кто успел захватить рынок или нишу будет иметь время и ресурсы потом довести продукт до ума или будет сметен очередной волной.
                На данный момент со всеми костылями и недостатками Docker остается практически безальтернативным лидером в быстрой и удобной виртуализации как при разработке так и при развертывании решений в цепочках CI/CD и деплое.
                Во всяком случае я не вижу серьезных конкурентов.
                Рынок и время все расставит по местам.
                  +4
                  на самом деле в том же lxc можно делать абсолютно всё тоже самое, и да неизменяемый и да всё остальное… просто требуется чуть больше телодвижений. но народ ленив.
                    +11

                    Может не ленив, а рационален? :)

                      –6
                      использовать докер и называть это рациональностью это как те псевдобизнесмены которые пытаясь сэкономить покупают дешёвое гавнооборудование которое сдыхает на следующий день и не тянет возложенные задачи и в итоге тратят больше?
                        0

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

                          +1

                          посмотрите на podman

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

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

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

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


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

                          0

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

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

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

                            0

                            А разве в докер винда пакуется?

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

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

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

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

                              +2
                              CNI сети это как docker networks, только для podman. Есть всякие cnitool, но я предпочитаю напрямую изменять конфиг файлы в /etc/cni/net.d скриптами.
                              С удаленными машинами работает через varlink interface.
                          +8
                          т.к. сети в нем как будто захардкожены.

                          да github.com/docker/libnetwork/blob/master/ipamutils/utils.go#L10
                            +2
                            Да, но есть возможность указать нужные сети через конфигурационный файл. См. default-address-pools и github.com
                              0

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

                            +11

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

                              +11

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

                                +8

                                Эльбрус 2000?

                                  +4

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


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

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

                                    +5
                                    протокол eDonkey2000, сокращённо ed2k, так что это не то
                                    +3

                                    Эльбрус, как резонно заметили ниже.

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

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

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

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


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

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

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

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

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

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

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

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


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

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

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

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

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


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

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

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


                                                            Так что, выдумки все это.
                                                              0
                                                              А что же там написано? Мы сделали это просто так? Везде именно так задвигают использование docker
                                                                0
                                                                И что? Я иногда встречал бредовые высказывания, что когда апп умеет в треды и создает потомков, то крику поднимается, что нельзя такое, только один процесс без детей. Я считаю, что если нужно два процесса, так тому и быть.
                                                                  0
                                                                  Тогда docker должен уметь обрабатывать такое из коробки. И без костылей. Ну и собственно где?
                                                                    0
                                                                    Какие костыли? один баш скрипт. Ведь один вход на запуск. а этот скрипт может что угодно запускать и как угодно.
                                                                      +1
                                                                      Это и есть костыль. Я обязательно должен с собой тащить дополнительную прокладку. Если вы не понимаете почему это плохо, то посмотрите в скрипты запуска sysvinit и unit файл systemd. Знаете в чем разница? Первый регламентирован весьма условно и он будет разный в разных дистрибутивах. Во втором случае он всегда одинаковый во всех дистрибутивах. Более того разработчик приложения наконец-то может сам сопровождать unit файл.
                                                                        0

                                                                        Некоторые называют это Unix-way...

                                                                        0
                                                                        А напрямую запустить нужный процесс не? Обязательно баш-скрипт тащить?
                                                                          0
                                                                          Тогда дети процесса не умрут :) Фишка в том что идея запустить напрямую процесс, приводит к невозможности завершить процессы детей, если процесс упал через segfault и не отправил им sigterm.
                                                                            –1
                                                                            Так не надо писать так, чтоб приходилось плодить детей. Нитки же (threads) есть.
                                                                            Вот и всё.
                                                                              0

                                                                              Авторам nginx это объясните, например :)

                                                                                –1
                                                                                Ну, может Сысоеву принципиально пофиг на докеризацию ) или он не считает init в докере костылем.
                                                                                Но, имхо fork вместо нитки — само по себе костыль.
                                                                              0
                                                                              А докер разве не про облегчение жизни разработчикам? Если да то с чего такие драконовские ограничения.
                                                                                +1
                                                                                Ограничения в голове у людей. Если что-то не нравится можно переделать, сделать по своему, а то ишь, понапридумывали бредовых правил про один контейнер один процесс.
                                                                                  0
                                                                                  Просто она не работает :) Если бы она работала нормально, вопросов бы не было.
                                                                                  0
                                                                                  Докер прежде всего про облегчение жизни эксплуатационщикам. Не знаю кто сказал что он жизнь разработчикам облегчает.
                                                                                  Ну т.е. есть унифицированный способ деплоить сетевые приложения без загаживания хостовой системы. Отлично.
                                                                                  Ограничение проистекает из необходимости корректно определять состояние контейнера по состоянию порожденного в нем корневого процесса.
                                                                                  И это вполне разумное ограничение — контейнер под задачу. умерла — убить/перезапустить в соответствии с полиси.
                                                                                  А если вам в контейнере нужен init — вы что-то делаете не так.
                                                                                    +1
                                                                                    Угу он при этом отлично гадит в фаервол хостовой системы. То как там сделана сеть делает меня печальной пандой. Примеры когда это не работает тут уже приводили. Далее может происходить задача умерла, дети не умерли. Убили контейнер в итоге сломали задачу, так-как она по новой не стартует.

                                                                                      0

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

                                                                          0
                                                                          А зачем вам 2 процесса?
                                                                            +1

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

                                                                              0
                                                                              Ага и приходим к обычному контейнеру с init системой :)
                                                                                +2

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


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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                                                                                      0

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

                                                                                        0

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


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

                                                                                          +1

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


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

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

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

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


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

                                                                                              +1

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


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

                                                                                                +1

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

                                                                                        0

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


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

                                                                                          0

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


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

                                                                                            0

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


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

                                                                                              0

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


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

                                                                                                0

                                                                                                Лишняя сущность потому что.

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

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

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

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

                                                                                    0

                                                                                    https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#decouple-applications


                                                                                    Limiting each container to one process is a good rule of thumb, but it is not a hard and fast rule.

                                                                                    Всё же написано.

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

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

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

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


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

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

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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

                                                                                    0

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


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

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


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

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

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


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


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


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

                                                                                          0

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

                                                                                          0

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


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


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

                                                                                            0

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


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

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


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

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

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

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

                                                                                                0

                                                                                                Какие админы, такой и квест ¯\(ツ)

                                                                                        0
                                                                                        Virtual Box с версии 6 уже в состоянии уживаться с Hyper-V
                                                                                        0

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

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

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

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

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

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

                                                                                            +2

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

                                                                                              +2
                                                                                              docker system prune -a

                                                                                              ?
                                                                                                +2

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

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

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

                                                                                                  +2

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


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

                                                                                                    0

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


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

                                                                                                      0

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

                                                                                                        0

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


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


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


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


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


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


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

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

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

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


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

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

                                                                                                    +5

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


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

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

                                                                                                      по поводу пакета docker: смотрим на https://tracker.debian.org/pkg/docker и понимаем, что эта программа там была ещё в 2002, намного раньше чем докер был изобретён
                                                                                                      переминовывать её никто не будет, приходится изворачиваться


                                                                                                      Выше уже написали — управлять контейнерами можно и из Nomad, он к тому же может запустить просто бинарники или lxc.


                                                                                                      В остальном согласен: Докер был хорошим этапом освоения контейнеров. Но в прод я его не поставлю.
                                                                                                      Я всегда привожу речь Брайана Кантрилла про контейнеры, насколько давно они были изобретены: https://www.youtube.com/watch?v=xXWaECk9XqM

                                                                                                        +1

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

                                                                                                          0

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


                                                                                                          # mv ./mc mcli

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

                                                                                                            0

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

                                                                                                          +1

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


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


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

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

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

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

                                                                                                            +1

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

                                                                                                              0

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

                                                                                                            +4

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


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

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


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

                                                                                                                0

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

                                                                                                                  0

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


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

                                                                                                                    0

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

                                                                                                                0

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

                                                                                                                +8
                                                                                                                Внесу свои 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.
                                                                                                                  +1
                                                                                                                  Изоляция процессов — посмотрите на свой проект, сколько там контейнеров? 5? nginx, java, redis, postgres, logstash? Запусти это всё просто на хосте и ок. Что тут изолировать? Другое дело, если вы — public ci cluster. Может быть.

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

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

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

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

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

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


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

                                                                                                                          И раскажите, чем преступен chown 775 /home/app в пределах докера, который не запускается под рутом? И не имеет смонтированых шаред волюмов с хоста на запись.
                                                                                                                            +3
                                                                                                                            Тем, что чел явно хотел делать chmod ;)
                                                                                                                              +1
                                                                                                                              фейспалм, даже не заметил :))
                                                                                                                              +5

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

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

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

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


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

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


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

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


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

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


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

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


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

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

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

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


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

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

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


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


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

                                                                                                                          +7
                                                                                                                          Изоляция процессов — посмотрите на свой проект, сколько там контейнеров? 5? ngin