Docker — это игрушка или нет? Или всё-таки да? +25



Всем привет!


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


Вступление


Я программист с опытом разработки frontend одностраничных приложений, scala/java и nodejs на сервере.


Довольно долго (уже точно пару — тройку лет), я придерживался мнения, что docker это манна небесная и вообще очень крутой инструмент и абсолютно каждый разработчик должен уметь пользоваться им. А отсюда вытекает, что и у каждого разработчика должен стоять docker на локальной машине. Да что там про моё мнение, вы полистайте вакансии, которые размещаются на том же hh. В каждой второй есть упоминание про docker и если вы им владеете — это будет вашим конкурентным преимуществом ;)


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


Причины использования


Почему я использовал docker? Наверное по следующим причинам:


  • запуск базы данных, 99% приложений пользуются ими
  • запуск nginx для раздачи frontend и проксирования на backend
  • можно упаковать приложение в docker образ, таким образом мое приложение будет работать везде, где есть docker, проблема дистрибутации решена уже сразу
  • service discovery из коробки, можно делать микросервисы, каждый контейнер (подключеный к общей сети) легко достучится до другого по алиасу, очень удобно
  • прикольно создать контейнер и "поиграться" в нем.

Что мне всегда НЕ нравилось в docker:


  • для того чтобы мое приложение работало, нужен сам docker на сервере. А зачем мне это, если мои приложения работают на jre или на nodejs и окружение для них уже есть на сервере?
  • если я хочу запустить свой (приватный) локально собранный образ на удаленном сервере, то мне нужен свой docker репозиторий, нужно чтобы где-то работал registry и еще нужно настроить https, потому что docker cli работает только по https. Ох блин… есть варианты, конечно, сохранить образ локально через docker save и через scp просто скинуть образ… Но это столько телодвижений. И к тому же выглядит "костыльным" решением, пока не появится свой репозиторий
  • docker-compose. Он нужен только для запуска контейнеров. И все. Больше ничего он не может. Docker-compose имеет кучу версий своих файлов, свой синтаксис. Каким декларативным он бы ни был, я не хочу читать их документацию. Мне она больше нигде не понадобится.
  • при работе в команде, в большинстве своем люди пишут Dockerfile очень криво, не понимают как это кешируется, добавляют в образ все что надо и не надо, наследуются от образов которых нету в dockerhub или приватном репозитории, создают какие-то docker-compose файлы с базами данных и ничего не персистируют. При этом разработчики гордо заявляют, что docker крут, у них все работает локально и HR важно пишет в вакансии: "Мы используем docker и нам нужен кандидат с таким опытом работы"
  • постоянно преследуют мысли о поднятии в docker всего и вся: postgresql, kafka, redis. Жаль, что не всё работает в контейнерах, не все легко сконфигурировать и запустить. Поддерживаются это сторонними разработчиками, а не самими вендорами. И кстати сразу возникает вопрос, вендора не парятся насчет поддержания своих продуктов в docker, почему же это, может они что-то знают?
  • всегда возникает вопрос про персистенцию данных контейнера. и тут думаешь, мне просто примонтировать хостовую директорию или создать docker volume или сделать data container который теперь deprecated? Если я монтирую директорию, то мне нужно убедиться что uid и gid пользователя в контейнере соответствует id пользователя, запустившего контейнер, иначе файлы, созданные контейнером будут созданы с правами владельца root. Если использую volume, то данные просто буду созданы в каком нибудь /usr/* и будет такая же история с uid и gid как в первом случае. Если запускаешь сторонний компонент, то нужно вчитываться в документацию и искать ответ на вопрос: "а в какие директории контейнера компонент пишет файлы?"


Мне всегда не нравилось, что приходится слишком долго возиться с docker-ом на начальном этапе: я придумывал как запускать контейнеры, из каких образов запускаться, делал Makefile, которые содержали алиасы к длинным docker командам. Терпеть не мог docker-compose, потому что не хотел учить еще один инструмент экосистемы docker. И docker-compose up меня напрягала, особенно, если там еще встречались build конструкции, а не уже собранные образы. Все, что я реально хотел — это просто делать продукт эффективно и быстро. Но я никак не мог разложить по полочкам использование docker.


Знакомство с Ansible


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


  • docker правит iptables (хотя можно отключить в daemon.json)
  • docker бажный и в проде запускать его не будем
  • если docker daemon падает, то соответственно, падают все контейнеры с инфрастуктурой
  • в docker нет необходимости
  • зачем docker если, есть Ansible и виртуальные машины

На той же работе я и познакомился с еще одним инструментом — Ansible. Когда-то я слышал о нем, но не пробовал писать свои плейбуки. А теперь я начал писать свои таски и тут мое видение поменялось окончательно! Потому что я понял: у Ansible есть модули для запуска тех же docker контейнеров, сборок образов, сетей и пр., при этом контейнеры можно запустить не только локально, но и на удаленных серверах! Моему восторгу не было предела — я нашел НОРМАЛЬНЫЙ инструмент и выбросил свои Makefile и docker-compose файлы, они были заменены на yaml таски. Был уменьшен код за счет использования конструкций типа loop, when, etc.


Docker для запуска сторонних компонентов типа бд


Недавно я познакомился с ssh тунелями. Оказалось, что очень просто "пробросить" порт удаленного сервера на локальный порт. Удаленный сервер может быть как машиной в облаке, так и виртуальной машиной, запущенной в VirtualBox. Если мне или моему коллеге нужна бд (или какой нибудь другой сторонний компонент), можно просто запустить сервер с этим компонентом и загасить, когда сервер не нужен. Проброс портов дает такой же эффект, как и бд, запущенная в docker контейнере.


Эта команда пробрасывает мой локальный порт на удаленный сервер с postgresql:


ssh -L 9000:localhost:5432 user@example.com

Использование удаленного сервера решает проблему с разработкой в команде. Таким сервером могут пользоваться сразу несколько разработчиков, им не нужно уметь настраивать postgresql, разбираться c docker и с прочими изощрениями. На удаленном сервере можно установить ту же бд в самом docker, если поставить спецефичную версию трудно. Все что будет нужно разработчикам — это выдать ssh доступ!


Недавно прочитал, что SSH тунели — это ограниченная функциональность обычного VPN! Можно просто настроить OpenVPN или другие реализации VPN, настроить инфраструктуру и дать ее в пользование разработчикам. Это ведь так круто!


Благо, AWS, GoogleCloud и прочие, дают год бесплатного использования, так используйте их! Они копеечные, если их гасить, когда не используются. Я всегда задумывался, в каких целях мне бы понадобился удаленный сервер типа gcloud, кажется, что я нашел их.


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


Итог: запускать бд и прочие инфрастуктурные плюшки можно и нужно на удаленных серверах или в virtualbox. мне не нужен docker для этих целей.


Немного про docker образы и дистрибуцию


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


Вы видели где-нибудь, чтобы разработчики ПО портировали свои продукты только в docker образе?
Результат большинства продуктов — это бинарные файлы под определенную платформу, именно их просто добавляют в docker образ, который наследуется от нужной платформы. Вы не задумывались, почему в dockerhub так много похожих образов? Вбейте, например nginx, вы увидите 100500 образов от разных людей. Эти люди не разрабатывали сам nginx, они просто в свой docker образ добавили официальный nginx и приправили своими конфигами для удобства запуска контейнеров.


В общем хранить можно просто в tgz, если кому-то понадобится запускать это в docker, то пусть в Dockerfile добавляют tgz, наследуются от нужного окружения и создают дополнительные плюшки, которые не меняют самого приложения в tgz. Тот, кто будет создавать docker образ, будет знать, что это за tgz и что ему нужно для работы. Именно так я использую docker тут


Итог: мне не нужен docker registry, воспользуюсь каким нибудь S3 или просто файловым хранилищем типа google drive/dropbox


Docker в CI


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


Эти компании используют docker на своих серверах где запускается CI процесс. Вопрос — зачем нужно собирать проекты в docker контейнере на своих серверах? Почему просто не подготовить окружение для сборки, например написать Ansible плейбук, который будет ставить нужные версии nodejs, php, jdk, копировать ssh ключи и пр. на сервер, в котором будет происходить сборка?


Сейчас я понимаю, что это стрельба себе по ногам, потому что docker не приносит никакого профита со своей изоляцией. Проблемы с CI в docker с которыми я столкнулся:


  • снова нужнен docker образ для сборки. нужно искать образ или писать свой dockerfile.
  • 90%, что нужно пробросить какие-нибудь ssh ключи, секретные данные, которые не хочется писать в docker образ.
  • контейнер создается и умирает, теряются все кеши вместе с ним. следующая сборка будет заново скачивать все зависимости проекта, а это долго и неэффективно, а время — деньги.

Разработчики не собирают проекты в docker контейнерах ( я — когда то был таким фанатом, жалко себя в прошлом xD ). В java есть возможность иметь несколько версий и менять одной командой на ту, которая нужна сейчас. В nodejs тоже самое, есть nvm.


Вывод


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


Используйте docker только на самом последнем этапе в вашем рабочем процессе, не тащите его в проект в начале. Он не решит ваших бизнес проблем. Он только сдвинет проблемы на ДРУГОЙ уровень и будет предлагать свои варианты решения, вы будете делать двойную работу.


Когда docker нужен: пришел к мысли что docker очень хорош в оптимизации поставленного процесса но не в построении базового функционала


Если вы все-таки решили использовать docker, то:


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

PS:



Спасибо, что дочитали, желаю вам прозрачных решений в ваших делах и продуктивных рабочих дней!

Вы можете помочь и перевести немного средств на развитие сайта



Комментарии (264):

  1. SirEdvin
    /#20028698 / +2

    docker бажный и в проде запускать его не будем

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


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


    не навязывайте использование docker разработчикам

    Я бы еще предложил не навязывать разработчикам всякие package.json. Пусть кое-как у него работает, потом он этот код пушит в мастер и кто-то другой пусть бегает с пухлой головой с мыслями о том "а какие же пакеты каких версий нужны?".


    Эти компании используют docker на своих серверах где запускается CI процесс. Вопрос — зачем нужно собирать проекты в docker контейнере на своих серверах? Почему просто не подготовить окружение для сборки, например написать Ansible плейбук который будет ставить нужные версии nodejs, php, jdk, копировать ssh ключи и пр. на сервер, в котором будет происходить сборка?

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

    • kondaurovDev
      /#20028840

      Но используют ansible, который бажный раз в 50 больше, чем сам докер когда либо был

      Ansible не тащит какой либо экосистемы на сервер, ему нужен только ssh и python интерпретатор. Бага в Ansible может привести только к тому что на серваке что то не запустится во время проигрывания плейбука.
      Как баги в Ansible пересекаются с багами в docker — не пойму
      Я бы еще предложил не навязывать разработчикам всякие package.json.

      Может вы имели ввиду package-lock.json? Если да то package-lock.json необходим в nodejs так как ссылается на точные коммиты кода.
      Как там вам собирать по 5-10 разных проектов с разными зависимостями и бинарными либами

      Соболезную вам в таком случае, ни разу не поддерживал 5 — 10 проектов одновременно да и тем более с разным стеком технологий

      • SirEdvin
        /#20028940

        Ansible не тащит какой либо экосистемы на сервер, ему нужен только ssh и python интерпретатор. Бага в Ansible может привести только к тому что на серваке что то не запустится во время проигрывания плейбука.

        Бага в ansible может привести к тому, что у вас сервер поломается, если что. Причем в некоторых случаях прямо совсем. И самое страшное в ansible, что у вас нет никакой возможности проверить, что реально произойдет с вашим сервером в результате выполнение скрипта, кроме как запустить его.


        Как баги в Ansible пересекаются с багами в docker — не пойму

        А причем тут докер? Конкретно в этом случае, ansible просто передавал ему две команды, сначала убивал старый контейнер, а потом пытался запустить новый, но ему не хватало данных и плейбук падал.


        Соболезную вам в таком случае, ни разу не поддерживал 5 — 10 проектов одновременно да и тем более с разным стеком технологий

        В том то и фокус, что таская окружение при помощи Docker вместе с проектом я не страдаю. Причем проекты не то, что бы разные, они все на python, но для них нужны разные версии библиотек. И вместо увлекательной содомии с venv у меня все в контейнерах с кешированием.

          • SirEdvin
            /#20029140 / +1

            А вы пробовали или нагуглили?

            Даже если проигнорировать то, что `check` режим это всегда «второсортный гражданин» в модулях ansible, особенно свежих, он банально сломал идеологически, так как в этом режиме предыдущие команды никак не влияют на следующие. Вы не можете в чек режиме создать пользователя в бд и потом выдать ему права, или скопировать docker-compose.yml, а потом запустить его, вторая команда упадет с очевидной ошибкой в духе «нет такого пользователя» или «нет такого docker-compose.yml файла».

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

            • Areso
              /#20029306

              А Молекула?

              • SirEdvin
                /#20029312

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

                • gecube
                  /#20031556

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

                  • nightvich
                    /#20031986 / -1

                    Никогда, никогда не переобувайте тапки на ходу. Выбрали без докера, так и живите, пока не поймёте, что он будет решать проблемы вашего проекта. И да, в 99% случаев, если ваш сервис — это 1 jar, вам не нужен докер.

                    • gecube
                      /#20032148

                      А мне-то зачем отвечаете? Я только затронул один аспект — ансибл. Про докер я тут ничего не писал )

                      Никогда, никогда не переобувайте тапки на ходу

                      А кто переобувает?
                      Выбрали без докера, так и живите, пока не поймёте, что он будет решать проблемы вашего проекта.

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

        • Merifri
          /#20029216

          Ansible-плейбуки прекрасно тестируются в виртуальных машинах (vagrant/virtualbox), либо в докере. Значимые изменения в скриптах — повод прогнать всё локально. Обновили ansible — прогнали плейбук, поправили deprecated warnings. Проверили ещё раз и отправили на прод.

          • SirEdvin
            /#20029242

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

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

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

            • gecube
              /#20031566

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

          • qrKot
            /#20031436

            Ansible-плейбуки прекрасно тестируются… в докере.


            Ну, т.е., это все-таки достаточно разные инструменты, которые могут дополнять друг друга, но никак не взаимозаменять? Я же правильно понимаю?

            Просто тогда изначальный посыл статьи «докер не нужен, используйте ансибл» кажется достаточно спорным…

            • gecube
              /#20031576

              Просто тогда изначальный посыл статьи «докер не нужен, используйте ансибл» кажется достаточно спорным…

              Тезис статьи неверный. Дихотомия неверная. Не docker vs ansible. А скорее иммутабельная инфраструктура с заранее подготовленными образами ВМ vs контейнеры. Образы ВМ, которые подготавливаются packer, как раз решают проблему инкапсуляции зависимостей и версионирования образов. Плюс возможность создавать виртуальные машины по запросу… Ну, вы поняли.
              Ну, т.е., это все-таки достаточно разные инструменты, которые могут дополнять друг друга, но никак не взаимозаменять? Я же правильно понимаю?

              Да

              • qrKot
                /#20031682

                иммутабельная инфраструктура с заранее подготовленными образами ВМ vs контейнеры.


                Ну вот тут с вами копья ломать не буду. Плюсы-минусы каждого подхода более-менее очевидны. «С высоты птичьего полета» — задача решается примерно одна и та же, только ВМ дают чувствительно больший оверхед по ресурсам, в то время как контейнеры дают гораздо более низкий (качественно) уровень изоляции. Тут уж «ситуативно». Надежно + дорого vs дешево + сердито.

                • gecube
                  /#20031698

                  только ВМ дают чувствительно больший оверхед по ресурсам, в то время как контейнеры дают гораздо более низкий (качественно) уровень изоляции.

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

                  • qrKot
                    /#20031900

                    Собственно, как мне с «моей колокольни» видится, Ansible — это более админский инфраструктурный инструмент. Docker тяготеет в сторону разработчиков.

            • Merifri
              /#20032262

              Конечно, их нельзя сравнивать. Оба инструмента могут прекрасно работать вместе.

              Как пример совместного использования, который вполне может существовать и будет далеко не самым плохим решением:
              — с помощью ansible разворачивается инфраструктура для разработки — git-сервер, сервер для тестов с докером, настраивается окружение для запуска докера на продакшн-серверах
              — в ci-пайплайне проект собирается в докер-образ, тестируется
              — с помощью ansible, запущенного внутри докер-контейнера (как часть процесса ci/cd), docker-образ выкатывается в продакшн.

  2. apapacy
    /#20028774 / +1

    это удобная вещь, гарантирующая кроссплатформенность

    Очень опасное заблуждение. Особенно если проект разработанный под linux пытаются запутить на windows.

    При разработке приложений например если Вам работать с проектами на разных версиях php и mysql по простоте и удобству работы docker + docker-compose проще и экономней по ресурсам, чем, например, виртуальные машины, vagrant и т.п. Если конечно Вы не ас по какой-то определенной технологии. Уровень вхождения достаточно низкий по сравнению с другими технологиями.

    Что касается прода — согласен. У докера своя ниша — это микросервисы, но только если докер используется совместно с чем-то вроде k8s, nomad и т.п.

  3. evgenyk
    /#20028780 / +1

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

    • Akuma
      /#20028892

      Внедрять его — вообще задача неблагодарная. А вот если писать с нуля, то вполне себе удобно.

    • CrzyDocTI
      /#20029382

      Я, по своему опыту общения, против идеи использования Докера в продакшене(он по своей сути только для микросервисов, но тут одного Докера мало — нужен еще Кибернетис, но Кибернетис еще слишком молодой и проблемный). Но вот есть пример:
      Пришли нам продавать CreenPlum(распаралеленная БД) с накрученными плюшками. Я говорю «дайте Докер чтоб я не мучился ставить выводок серверов неизвестного продукта» а в ответ тишина… в итоге конечно поставил к концу дня некое тестовое подобие, но исплевался. Директору был ответ «документации у них нет в открытом доступе(что правда), использование ресурсоемко(что правда)». Как думаете — это повлияет на продажи?
      Можно же всегда сделать что-то типа: github.com/CrazyDoc/docker-swarm или github.com/CrazyDoc/infrastructure-beanstalk-test — когда у тебя через 15мин готовый продукт для теста.

  4. lega
    /#20028864

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

    если я хочу запустить свой (приватный) локально собранный образ на удаленном сервере, то мне нужен свой docker репозиторий
    Нет не нужен, можно просто скопировать образ и запустить (docker save -> docker load).

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

    при работе в команде, в большинстве своем люди пишут Dockerfile очень криво
    постоянно преследуют мысли о поднятии в docker всего и вся
    всегда возникает вопрос про персистенцию данных контейнера
    Это проблема докера? Докер вам просто дает некоторые возможности с некоторыми ограничениями, вы уже решаете пользоваться ими или нет, зачем жаловаться на то что вам дают выбор.

    Жаль, что не всё работает в контейнерах
    Например?

  5. Akuma
    /#20028880

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

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

    • gecube
      /#20031608 / +1

      Это самая худшая из практик. Сами же верно говорите, что лишний трафик. А ещё лишняя нагрузка на процессор и диск. Да и система засоряется временными докер образами (тем более, если процесс сборки по какой-то причине упадет).
      Есть ещё одно очень важное соображение. Вы не гарантируете, что сборка локально и удаленно совпадет. Потому что как минимум — никто не фиксирует версии базовых образов в докерфайлах. И, да, я не просто про метку или тег говорю, которые всегда могут быть перезаписаны, а именно sha сумму образа. Сколько образов именно по ней ссылаются на базовый образ?

      • Akuma
        /#20032100

        По мне так это обычная практика. Ничего там не засорялось, по крайней мере бесконтрольно.
        Да, на сервере должны быть определенные ресурсы для сборки. В моем случае это были не большие ресурсы.
        На счет гарантий — все точно так же как при сборке локально или через CI/CD. По sha образы никогда не фиксируют просто потому что это маразм. Никто просто так не перезаписывает теги (кроме latest конечно).

        • gecube
          /#20032174

          Никто просто так не перезаписывает теги (кроме latest конечно).

          Объясните это безопасникам. И я с ними, кстати, согласен. Ни один из по-простому доступных докер репозиториев не умеет иммутабельные теги. К сожалению. Это можно заимплементировать на уровне прав доступа + в пайплайнах сборки, но это костыли.
          Просто надо понять, что существует как минимум два типа тегов — постоянные (релизы) и перезаписываемые (latest, master, dev и по названиям веток). Почему-то при проектировании докера как системы это не учли и имеем то, что имеем.
          Повторюсь, что нет единой конвенции и даже если бы она была, то многие ее нарушали бы (пример — hub.docker.com/_/golang — под 1.11-stretch ВСЕГДА будет последний билд, а не какой-то определенный)

          • Akuma
            /#20032210

            Я не спорю с тем, что теги могут быть перезаписаны. Но не пойму что вас удивляет в 1.11-stretch. Да, там всегда будет последний билд и… это так и задумано, по крайней мере в моем понимании.
            Если вам это не подходит, ничто не мешает собрать свои базовые образы и использовать их, там все теги полностью под контролем.

  6. Paskin
    /#20028938

    Когда любую технологию (кросс-платформенность, докер, микросервисы, ...) обьявляют «общей теорией всего» — тогда начинаются проблемы. Докер хорош для ситуаций, когда вам нужно поднять разные окружения на одной машине или просто запустить что-то требующее нудной и нетривиальной компиляции и конфигурации (OpenCV, TensorFlow — отличные примеры). Docker-compose, соответственно — если таких компонентов у вас несколько.
    А когда все устаканилось, есть официальные CI/CD конвееры и окружения для тестов — можно хоть Linux from scratch собирать, Докер здесь только одна из возможностей.

  7. mspain
    /#20029050 / +4

    Докер популярен потому, что программисты в 99% случаев не имеют админской квалификации в Linux.
    По той же причине популярен Windows.

    С точки зрения прогера-админа, docker «классическое нинужно», тем более он не первый, их как грязи было, есть и будет. Всяких разных вариаций, начиная древними LXC, продолжая всякими snap-пакетами и виндузообразными чудо-дистрибами где все проги ставятся в отдельный каталог.

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

    То же самое относится и к кубер vs нормальная виртуализиция.
    По секрету скажу, есть места, где никакая виртуализация не нужна.

    • Akuma
      /#20029068 / +1

      Что-то вы совсем не о том.
      100% из того, что программист сможет настроить в Docker, он сможет настроить и «напрямую», т.к. никакой разницы там нет. Использование готовых образов — это как apt-get. Вы же им пользуетесь, а не компилируете исходники каждый раз?

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

      • mspain
        /#20032938 / +1

        >особенно классические методы через apt-get, полсотней сырых реп, кривыми мейнтейнерами, игнорированием пакетных менеджеров дистрибутива и программного языка друг-друга и так далее

        Откуда программистикам знать, что у нормального админа есть RHEL/CENTOS и есть «весь остальной шлак» (навроде бубунточки с сырыми репами и кривыми мэинтейнерами).

        Если у ПО нет штатного YUM-репо и его нет в EPEL, это повод поискать более вменяемое ПО.

        >Не засоряет систему, дает контроль над ресурсами и ситуацией

        Вот и понабежали «программисты без админской квалификации в Linux». фаервол докер похабит, с lib-ами никакими не линкуется, в итоге внутри контейнера в 99.9% случаев дырка от бублика. Кстати, докерофилы не в курсе, что cgroups через который докер ограничивает, независимая подсистема linux, которую никто не запрещает использовать и без докера?

        На stackoverflow в вопросе «а что монго не стартует, на права какие-то ругается» 80% советует «да запусти из под рута, я так сделал и всё заработало», чуть более одаренные пишут про chown, а где-то в самом конце одинокий ответ про selinux, и то в виде «selinux отключается вот так».

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

        p.s. Все платформы/языки разные. Я уже понял, что большинство из них кривые и там с докером действительно удобнее жить. Плохо то, что его впаривают всем, в том числе в java-стек, хотя там родных инструментов полно, которые постарше докера будут лет так на 10. Это и есть хипстерство и попытки подзаработать на свеженьком.

        • Akuma
          /#20033636 / +3

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

          Но! Это прям чудо сисадмин. Он следит за каждым пакетиком, подбирает ПО, может поставить 10 версий разных БД, две нестабильные и одну из другой ОС. А когда ему надоест или он уйдет, наступит хаос. Никто не знает как он это делал, потому что нет стандартов, а если какие-то и есть, то фиг их кто соблюдает. Это человеческий фактор.

          «повод поискать более вменяемое ПО» — это утопия. Мне нужна именно такая версия именно вот этого ПО и через 10 минут. Кстати, сейчас три часа ночи. Справитесь?
          А завтра в 4 утра я выкатываю обновление. Новая версия несовместима со старой и в случае чего нужно будет все откатить за 2 минуты, не больше. Справитесь? Молодец. А если вы завтра заболеете, мне что делать? Правильно: kubectl rollout

          Да, Докер не идеален, но он крут, с этим сложно спорить.

          P.S. Отсортируйте ответы SO по полезности и будет вам счастье.

          • mspain
            /#20038944 / +2

            >Новая версия несовместима со старой и в случае чего нужно будет все откатить за 2 минуты, не больше. Правильно: kubectl rollout

            Самый главный минус докера это фанбои докера с очень узким кругозором.
            Уверен, что на любой популярной платформе откат легко делается БЕЗ докера, причём множеством способов. И за 2 сек при желании, а не 2 минуты.
            Ну и самое главное, что-то там в 4 утра накатывать и откатывать? Галерщик кровавого ынтырпрайза?

            >Он следит за каждым пакетиком, подбирает ПО, может поставить 10 версий разных БД, две нестабильные и одну из другой ОС. А когда ему надоест или он уйдет

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

            • Akuma
              /#20039106

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

              • mspain
                /#20044412

                >Это неудобно и требует дополнительного человека

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

                >а тут вам удобный инструмент

                Фанбои докера не в курсах, что Кубер это сборная солянка из совершенно разных «удобных инструментов», которым лет намного больше, чем докеру и куберу. И никто не мешает делать HA и FO на например haproxy, у которого конфиг 5 строчек. По сравнению с ним докер и кубер жуткие монстры. И не надо спорить.

    • evgenyk
      /#20029076 / +1

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

      • SirEdvin
        /#20029094 / -1

        А так все решается классическими методами меньшими силами.

        А вы уверены? Кмк, проще чем docker-compose.yml не может быть ничего в принципе, особенно классические методы через apt-get, полсотней сырых реп, кривыми мейнтейнерами, игнорированием пакетных менеджеров дистрибутива и программного языка друг-друга и так далее.

        • pangolin
          /#20029234

          Но ведь в этом самом docker-compose в итоге будет этот же самый бардак, только запрятанный парой слоёв абстракций. Софт и библиотеки в образе докера сами по себе не появятся.

          • evgenyk
            /#20029250 / +1

            Докер и начинают везде пихать как средство заметания муора под ковер ИМХО.

          • SirEdvin
            /#20029282 / +1

            Самое большое отличие в том, что бардак везде будет небольшой, разный и, обычно, минимально бардачный.


            Где-то будет выбран дистрибутив, для которого авторы собирают бинарные пакеты, где-то дистрибутив, на котором проще всего собрать все с нуля и так далее.

            • Danik-ik
              /#20031554

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


              Так что, как по мне, мусор-в-Докере — не худший вариант. Он не под ковром, он в ведре с пакетом, если бытовая аналогия для кого-то предпочтительнее "контейнера". И хоть мусор там внутри, хоть кости, хоть потроха.

      • zesetup
        /#20029264 / +1

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

        • evgenyk
          /#20029284

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

          • usego
            /#20030148

            Зачем искать лень там, где этот вид работ можно устранить докером как класс? Базовые докера со всеми зависимостями создаются один раз и забываются. Остаётся только app level. Профит для всех. И у админов эффективность многократно увеличивается, и девы перестают валять дурака с «а у меня всё работает», и инфраструктура полностью документирована в виде кода. Из недостатков вижу только более долгий CI, нет этих запушил один файлик и сразу его закинули на сервер. Но у этого тоже есть профит — девы начинают думать мозгами и максимально всё тестить на локалхосте, а не дебагить прямо на сервере.

            В общем я понимают боль девов, когда им навязывают докер, но это боль во благо продукта.

            • evgenyk
              /#20030200 / -1

              Есть еще один недостаток — высокий расход ресурсов.
              Другой недостаток, вместо порядка — «замести под ковер».

              • f0rk
                /#20030258

                Каких ресурсов? Что значит высокий?

                • evgenyk
                  /#20030306

                  Память, диск.

                  • Emil983
                    /#20030548

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

                    • mak_sim
                      /#20030900

                      Docker на Mac уже давно не использует Virtualbox.

                      • Emil983
                        /#20031096

                        Да, я знаю. Но почему-то часть народа до сих пор так думает, что докер это виртуалка со всеми вытекающими минусами. Несколько раз сталкивался с таким мнением

                        • gecube
                          /#20031624

                          На самом деле все так и есть. Посмотрите внимательно на docker for mac
                          И, да, это не виртуалбокс. А другое. Но работает все равно на выделенных ресурсах и в виртуалке.

                    • mishast
                      /#20032230

                      Расскажите, где реально кубер используется в каких проектах?
                      Говорят, что кубер сложен в настройке и глючный. Насколько это правда?

                      • Emil983
                        /#20032250

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

                    • evgenyk
                      /#20032278

                      Ну, у меня имиджи по 2 гига получаются, вот только сейчас глянул.

                      • Emil983
                        /#20032438

                        Подозреваю что вы что-то делаете не так, что-то лишнее запихиваете в образ, что должно лежать на внешнем volume. Почти любое приложение можно запихнуть в alpine образ, если уж сильно постараться. У нас даже кривые образы, до которых не доходят руки поправить, не выходят за гиг.

                        • evgenyk
                          /#20032504

                          Вот глянул, базовый образ, выбирал не я — python2.7 925MB, После установки и компиляции всех нужных пакетов получается 1.97.
                          Думаю на пару сот мегов можно уменьшить, если повозиться.
                          Но это же и есть то, о чем я пишу, докер ест мое время за напонятный выигрыш. Точнее выигрыш для девопов, им не нужно возиться с установкой нужного мне софта и они могут поиграться с тем, что им нравится, вместо того, чтобы влезать в то, что на самом деле работает.
                          А проблемы они будут решать рестартом контейнера.
                          По моему так.
                          А делать образ из альпайн? Сначала я должен всех переубедить, что это стоит того. Еще туда должен буду установить мои зависимости и еще не факт, что получу большой выигрыш.
                          Ну плюс риск, что я могу потратить несколько дней на компиляцию и установку всего чего нужно, а в конце натолкнусь на непреодолимое препятствие.

                          • Emil983
                            /#20032556

                            Докер ест время на вполне понятный выигрыш. Если у вас одна машина, то он вам не нужен. Если у вас несколько машин, то каждый раз ставить на них все зависимости и производить базовые настройки для запуска приложения — это трэш. Завтра у вас одна машина упала и вы судорожно настраиваете ей замену, а я просто ставлю label на другой и смотрю как Кубер поднимает на ней контейнер за минуту, согласно заданным правилам.

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

                            Всегда стоит смотреть из каких образов вы наследуетесь, доверять можно только офф хабам, в остальных случаях там может быть неизвестно что. У нас базовый образ node.js 650 метров, если взять на alpine, то еще меньше будет. Переубеждать вы никого не должны, внедрять это должны devops-ы.

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

                            • mayorovp
                              /#20033300

                              Завтра у вас одна машина упала...

                              … и я просто запускаю деплой-скрипт указав ему на другую машину.


                              Если разработчику с другого проекта, стэка понадобилось запустить ваш проект, то он просто берет и запускает собранный образ...

                              А если ему нужно не просто запустить проект, а внести изменения, собрать и отладить?

                              • qrKot
                                /#20033348

                                А если ему нужно не просто запустить проект, а внести изменения, собрать и отладить?


                                Не поверите, ровно для этого случая все и задумывалось!

                                • mayorovp
                                  /#20033420

                                  Ну так как оно работать-то будет?

                                  • qrKot
                                    /#20033782

                                    Отлично работать будет. Программист просто пнет сборку на месте, оно соберется и запустится.

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

                                    При этом в числе зависимостей сборки будут а) наличие репозитория исходного кода б) доступ к докер-регистри.

                                    • mayorovp
                                      /#20033828

                                      Вот я уже приводил ниже пример проекта, над которым не так давно работал. Для сборки требуется, в том числе, Visual Studio с особыми дополнениями, всяческих Build Tools недостаточно.

                                      Вы предлагаете добавлять образ установленной студии (5 гигабайт) в регистр образов? Как часто он будет выкачиваться оттуда при сборке? Что делать работающим удалённо разработчикам?

                                      • qrKot
                                        /#20033906

                                        Вот я уже приводил ниже пример проекта, над которым не так давно работал. Для сборки требуется, в том числе, Visual Studio с особыми дополнениями, всяческих Build Tools недостаточно.


                                        Нет, я предлагаю вам принять тот факт, что конкретно ваш случай в DevOps концепцию не ложится, и отказаться от заранее утопичной идеи пихать Windows-only приложение в конейнер.

                                        Вы предлагаете добавлять образ установленной студии (5 гигабайт) в регистр образов?


                                        Если оно у вас получится — дадите посмотреть?)

                                        Как часто он будет выкачиваться оттуда при сборке?


                                        Один раз на каждое обновление версии образа (в данном случае по разу на версию студии, вероятно).

                                        Что делать работающим удалённо разработчикам?


                                        Бежать с этого проекта при первой же возможности.

                                        • mayorovp
                                          /#20033936

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

                                          • qrKot
                                            /#20034014

                                            Ну вот, один случай, который в докер не ложится, уже нашли.


                                            А кто-то предлагал все-все-все в докер «уложить»? Идея запихать студию в докер была ваша…

                                            Только не понятно что тут принципиально не так с DevOps


                                            Принципиально не так — отсутствие автоматизации сборки.

                                            почему удалённые разработчики должны бежать с проекта…


                                            А почему только удаленные? С проекта, где Visual Studio пытаются запихать в Docker бежать надо всем, ортогонально удаленности.

                                            • mayorovp
                                              /#20034058

                                              А кто-то предлагал все-все-все в докер «уложить»? Идея запихать студию в докер была ваша…

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


                                              Принципиально не так — отсутствие автоматизации сборки.

                                              А кто сказал, что у сборки нет автоматизации? Простая команда "C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" /p:VisualStudioVersion=14.0 соберёт весь проект и запакует в готовый к установке архив… Но для этой команды нужна установленная студия.

                                              • qrKot
                                                /#20034856

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


                                                Не моя цитата. Я как раз про «докер — отличный инструмент для определенных проектов(не для всех)».

                                                А кто сказал, что у сборки нет автоматизации? Простая команда «C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe» /p:VisualStudioVersion=14.0 соберёт весь проект и запакует в готовый к установке архив… Но для этой команды нужна установленная студия.


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

                                                Собственно, для CI/CD (и собственно DevOps) неплохо подходит .NET Core, но его собирать студия не нужна.

                                                • mayorovp
                                                  /#20035266

                                                  Не моя цитата. Я как раз про «докер — отличный инструмент для определенных проектов(не для всех)».

                                                  Ну так свой первый комментарий я и не вам писал...


                                                  Вот в этом девопсе очень сильно не хватает «опса»

                                                  И что "опс" тут сделает?


                                                  Воспроизводимость сборки самоубивается, весь «девопс» коту под хвост.

                                                  А что не так с воспроизводимостью сборки?

                                                  • qrKot
                                                    /#20036030

                                                    А что не так с воспроизводимостью сборки?


                                                    С воспроизводимостью сборки проблема. Цитируя вас: «Для сборки требуется, в том числе, Visual Studio с особыми дополнениями, всяческих Build Tools недостаточно.» Т.е. окружение для сборки настраивается руками, детерминированная конфигурация отсутствует, развертывание в промышленных масштабах не предусмотрено, собирается при правильном положении звезд на машине самого разработчика…

                                                    И что «опс» тут сделает?


                                                    Опс тут всегда был. DevOps — это такая методология, в которой «все есть код» (не примите за определение). Т.е. все, начиная от кода, до непосредственного деплоя приложения — это часть проекта. И докер — порождение и достаточно удобный инструмент именно этой методологии. Отпилите «опс»-часть (эксплуатацию), и выгодны контейнеризации становятся гораздо менее очевидными.

                                                    Поэтому ваше «а я хочу взять десктопный проект на студии 2006 года, и сделать чтобы все по девопсу» — это классическое натягивание совы на глобус. Термин DevOps младше, чем ваша студия (и, видимо, проект).

                                                    В пайплайнах сборки от контейнеризации, по факту, всего один плюс — изоляция окружения сборки. Не больше и не меньше. Надо ли оно вам (по-взрослому, однозначно, надо), и не удобнее ли вам в вашем одном проекте 2006 года рождения использовать виртуалки — это ваши личные trade-off'ы. Но вот этот подход «в моем проекте не работает, значит не нужно» — ну, плохо это. Есть миллион других кейсов, где оно работает с разной степенью успешности.

                                                    • mayorovp
                                                      /#20036266

                                                      Т.е. окружение для сборки настраивается руками

                                                      Окружение для сборки ставится установщиками через "далее-далее-готово". Можно даже автоматически попытаться поставить, но нет смысла — не так часто создаются новые билд-сервера. Нет смысла автоматизировать работу, которая выполняется раз в три года.


                                                      детерминированная конфигурация отсутствует

                                                      Присутствует и указана в документации.


                                                      развертывание в промышленных масштабах не предусмотрено

                                                      Почему вы так решили? Что такое "развертывание в промышленных масштабах"?


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

                                                      Собирается при правильно установленном окружении.


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

                                                      А кто вам сказал, что это десктопный проект на студии 2006 года?


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

                                                      Надо-то надо, но как?

                                                      • qrKot
                                                        /#20036386

                                                        Окружение для сборки ставится установщиками через «далее-далее-готово».


                                                        «Установщик» — это должность у вас в организации такая? Или вы, если вам понадобился новый билд-сервер, берете разработчика с зарплатой, предположим, 1500р/час, и садите его за отдельный компьютер, на котором он по распечатанной инструкции в течение 2 часов тычет Далее-Далее-Готово и расставляет галочки в нужных местах? Поздравляю, вы только что купили услугу развертывания билд-сервера за 3000 рублей!

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


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

                                                        Присутствует и указана в документации.


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

                                                        Почему вы так решили? Что такое «развертывание в промышленных масштабах»?


                                                        Представим ситуацию: вам упало три срочных новых проекта за «дофига денег». Каждый со своей спецификой сборки, но фиксы быстрые, и платят за них хорошо… Докупим 3 новых билд-сервера, вероятно? Ваш билд не масштабируется. «установщиками через „далее-далее-готово“» — это обезьянье масштабирование какое-то. Взрослые же люди, в самом деле.

                                                        Собирается при правильно установленном окружении.


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

                                                        А кто вам сказал, что это десктопный проект на студии 2006 года?


                                                        Ну ладно, ошибся, не 2006. VisualStudio 14 — 2015 год. 4 года уже. При этом кастомная настройка таки намекает, что проект не .NET Core, и NuGet'ом зависимости, почему-то, не резолвятся. Т.е. даже заюзайте вы MS DevOps, которая вполне себе билдит проекты в облаке из исходников — не взлетит. Потому что, видимо, «изначально спроектировано так».

                                                        Надо-то надо, но как?


                                                        В вашем случае, видимо, никак. Доведите проект до состояния, в котором он самостоятельно может рулить своими зависимостями, для начала — сможете куда-то дальше двигаться. Если это невозможно… Ну, живите с этим, просто весь накопленный CI/CD инструментарий не для вас, видимо.

                                                        • mayorovp
                                                          /#20036492

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

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


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

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


                                                          Представим ситуацию: вам упало три срочных новых проекта за «дофига денег». Каждый со своей спецификой сборки, но фиксы быстрые, и платят за них хорошо… Докупим 3 новых билд-сервера, вероятно?

                                                          Подождите, что такое "упали проекты" и что такое "специфика сборки"?


                                                          Если это новые проекты, то мы будем делать их так, чтобы не было никакой "специфики сборки". Билд-сервера для сборки как бы уже есть.


                                                          Если же это чужое легаси — то я не понимаю как в этой ситуации могут помочь контейнеры. Ведь вместе с легаси-проектом никогда не "падает" контейнер с окружением для его сборки, это фантастика какая-то.


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

                                                          Рады бы, но если тулчейны для сборки ставятся только вместе со студией — значит, нужно или использовать студию, или писать свой тулчейн. Писать свой тулчейн — это куда дороже чем те 3000 рублей, насчитанные вами за развертывание билд-сервера.


                                                          Если это невозможно… Ну, живите с этим, просто весь накопленный CI/CD инструментарий не для вас, видимо.

                                                          Внезапно, мы используем нормальный CI/CD инструментарий. Если билд-сервер невозможно поднять в облаке — это ещё не означает, что это не CI. Если окружение для новый инстанса берется не из "базового" контейнера, а из "базового" бэкапа виртуалки — это ещё не значит, что это не CD.

                                                          • qrKot
                                                            /#20036612

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


                                                            Возможно, конкретно в вашем случае оно и дешевле (или не считал никто, на самом деле). Только не подавайте «нам не подошло» как недостаток контейнерной виртуализации в целом. Оно просто вам не подошло, но вы, видимо, интересуетесь. Не зависть ли это?)

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


                                                            Представляет, что понадобился «на время» проект на 13-й студии с аналогичными «фичами» сборки. Вы корячите на свои билд-сервера еще по одной студии, а после завершения проекта долго и мучительно ручками выпиливаете ошметки ставшего ненужным инструментария из разных уголков ФС машины? Ну, не знаю, странно это как-то.

                                                            Подождите, что такое «упали проекты» и что такое «специфика сборки»?


                                                            «Упали проекты» — это к вам пришли, принесли много денег и сказали «а не возьметесь ли вы вот этот проект до ума довести за разумно-большую сумму за обозримые сроки?».

                                                            «Специфика сборки» — это «наш проект собирается только на Visual Studio 13, 32-битной версии с набором установленных плагинов/модулей, вот список на 16 страниц». Ну, т.е. все, как вы привыкли (сори, не удержался от «минутки сарказма»)

                                                            Если это новые проекты, то мы будем делать их так, чтобы не было никакой «специфики сборки». Билд-сервера для сборки как бы уже есть.


                                                            Рискну предположить, что новые ваши проекты скорее унаследуют уже имеющуюся «специфику» (14 студия, вот с этими галочками).

                                                            Если же это чужое легаси — то я не понимаю как в этой ситуации могут помочь контейнеры. Ведь вместе с легаси-проектом никогда не «падает» контейнер с окружением для его сборки, это фантастика какая-то.


                                                            Вполне себе может и «упасть» сборочный образ, например. Я пару раз видел, честно-честно. А иногда и не падает, ага. Падает, например, столь ценимая вами «документация» вида «нужно проставить галочки при установке вот в этом порядке, затем жать Далее-Далее-Далее, пока не увидите синее окошко. Как увидели, закройте по Ctrl-Alt-Del, перезагрузитесь и запустите установку заново, второй раз пройдет нормально». Причем может еще оказаться, что документацию «забыли обновить» полтора года назад… Ну, это к тому, для чего вся эта возня с девопсом задумывалась, ага.

                                                            Рады бы, но если тулчейны для сборки ставятся только вместе со студией — значит, нужно или использовать студию, или писать свой тулчейн. Писать свой тулчейн — это куда дороже чем те 3000 рублей, насчитанные вами за развертывание билд-сервера.


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

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

                                                            Внезапно, мы используем нормальный CI/CD инструментарий. Если билд-сервер невозможно поднять в облаке — это ещё не означает, что это не CI. Если окружение для новый инстанса берется не из «базового» контейнера, а из «базового» бэкапа виртуалки — это ещё не значит, что это не CD.


                                                            Это просто значит, что контейнеры вам не помогут. А хочется, признайте уже!)))

                                                            • mayorovp
                                                              /#20036736

                                                              Только не подавайте «нам не подошло» как недостаток контейнерной виртуализации в целом. Оно просто вам не подошло, но вы, видимо, интересуетесь. Не зависть ли это?)

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


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


                                                              Представляет, что понадобился «на время» проект на 13-й студии с аналогичными «фичами» сборки. Вы корячите на свои билд-сервера еще по одной студии, а после завершения проекта долго и мучительно ручками выпиливаете ошметки ставшего ненужным инструментария из разных уголков ФС машины? Ну, не знаю, странно это как-то.

                                                              Если без 13й студии ну никак — то две студии могут существовать рядом и не будут ссориться. Проверено практикой: из-за параллельной работы над разными проектами у меня на старом рабочем компьютере стояли 2012 и 2015 студии одновременно — и никаких багов от этого не появлялось. А до этого стояли 2008 с 2010 и 2010 с 2012.


                                                              «Специфика сборки» — это «наш проект собирается только на Visual Studio 13, 32-битной версии с набором установленных плагинов/модулей, вот список на 16 страниц». Ну, т.е. все, как вы привыкли (сори, не удержался от «минутки сарказма»)

                                                              Ну, мы-то привыкли, и за кучу денег и не таким занимались (так, в одном из проектов на Java нам пришлось реверс-инженерить IDE чтобы иметь возможность запускать деплой из командной строки).


                                                              А вот что будете делать в этой ситуации вы? :-)


                                                              Рискну предположить, что новые ваши проекты скорее унаследуют уже имеющуюся «специфику» (14 студия, вот с этими галочками).

                                                              Ну уж нет.


                                                              Вполне себе может и «упасть» сборочный образ, например.

                                                              Если "упадёт" — мы им воспользуемся. Но пока что нам ни разу так не везло.


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

                                                              Тут согласен. Вот только этот фейл докером не исправляется.


                                                              Это просто значит, что контейнеры вам не помогут.

                                                              Бинго!

                                                              • qrKot
                                                                /#20036856

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


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

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

                                                                Блин, как будто про теток разговариваем)

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


                                                                Ну, вот тут искренне вам сочувствую. Как минимум, что не получается «пощупать» интересный инструментарий в продакшене.

                                                                Если без 13й студии ну никак — то две студии могут существовать рядом и не будут ссориться. Проверено практикой: из-за параллельной работы над разными проектами у меня на старом рабочем компьютере стояли 2012 и 2015 студии одновременно — и никаких багов от этого не появлялось. А до этого стояли 2008 с 2010 и 2010 с 2012.


                                                                Это, в общих чертах, понятно. Но, допустим, если вам старая студия нужна временно, например, на время миграции проекта на новую версию… Ну, не знаю, поставить-то их рядом действительно не проблема, удалить лишнее — вот истинный корень зол. У меня от таких вещей «зудит» просто)

                                                                Ну, мы-то привыкли, и за кучу денег и не таким занимались (так, в одном из проектов на Java нам пришлось реверс-инженерить IDE чтобы иметь возможность запускать деплой из командной строки).

                                                                А вот что будете делать в этой ситуации вы? :-)


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

                                                                Ну уж нет.


                                                                Ну, т.е. вам самому «не очень-то и нравится»)))

                                                                Если «упадёт» — мы им воспользуемся. Но пока что нам ни разу так не везло.


                                                                Ну, в .NET оно действительно пореже встречается, ага. У меня просто специфика несколько другая.

                                                        • 0xd34df00d
                                                          /#20044734

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

                                                          Не могу не влезть.


                                                          У меня есть хобби-проект. Плюсы, кроссплатформенный, основная платформа разработки — линукс.


                                                          Как CI происходит под линуксом. Настроен Jenkins, который каждую ночь собирает свежие докер-образы с debian unstable, opensuse tumbleweed и прочих типа-роллинг-дистров (при этом соответствующие докерфайлы лежат в репе проекта) и раскатывает их на пару машин в Хецнере, которые косят под билд-серверы. При каждом пуше/пуллреквесте (давно их не было, эх)/етц тем же дженкинсом запиливаются docker-образы, унаследованные от еженощно собираемых и имеющие в себе git clone ... && cmake && make && make test.


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


                                                          Как надо?

                                                          • qrKot
                                                            /#20044772

                                                            Как надо?


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

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

                                                            • 0xd34df00d
                                                              /#20044840

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


                                                              Ну и раз мы так хорошо начали, как решается вот такая вот проблема.


                                                              Собираю я, значит, каждую ночь свежие образы всяких анстейблов, и всё хорошо для дебиан и опенсусе. Однако, если я вдруг захочу ещё гонять сборку и тесты под гентой, то всё будет очень плохо: у меня там в зависимостях вебкит, например, а он редко обновляется, пересобирать его каждую ночь глупо. При этом свежие версии зависимостей для сборки иметь охота. Как это решают Ъ девопсы?

                                                              • evgenyk
                                                                /#20044864

                                                                Я не девопс, а простой пролетарий разработчик, для сборки пишу баш скрипты. Так там кэширую скачанные исходники на локальном дисеки и скачиваю и пересобираю только тот софт, для которого локальная версия не совпадает с удаленной.
                                                                Разве не везде так?

                                                                • 0xd34df00d
                                                                  /#20044890

                                                                  Вы всё это сами руками пишете? Вот всю эту логику? И чтобы оно с системным ПМом хорошо работало, и им пользовалось для скачивания и установки исходников, етц, да?


                                                                  Не, это весело и круто, конечно, но у меня другие пет-проекты уже есть.

                                                                  • evgenyk
                                                                    /#20044992

                                                                    А что там писать?

                                                                    • 0xd34df00d
                                                                      /#20045100

                                                                      Мини-ПМ, по факту.


                                                                      Не, у меня всё проще, у меня в базовом случае можно каждую ночь делать что-то вроде emerge -avuDN world, и раз в неделю пересобирать всё с нуля, чтобы избавиться от старого, но это как-то выглядит костыльно.

                                                                      • qrKot
                                                                        /#20046842

                                                                        но это как-то выглядит костыльно.


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

                                                                        «Автоматизируя хаос, получаете автоматизированный хаос». Ваш случай — достаточно приличный пример автоматизации хаоса, бывает сильно хуже.

                                                              • qrKot
                                                                /#20046424

                                                                Собираю я, значит, каждую ночь свежие образы всяких анстейблов, и всё хорошо для дебиан и опенсусе. Однако, если я вдруг захочу ещё гонять сборку и тесты под гентой, то всё будет очень плохо: у меня там в зависимостях вебкит, например, а он редко обновляется, пересобирать его каждую ночь глупо. При этом свежие версии зависимостей для сборки иметь охота. Как это решают Ъ девопсы?


                                                                Т.е. вы собираете роллинг-версии дистрибов, чтобы потом погонять сборку/тесты приложения в самых-самых свежих версиях окружения?

                                                                Ну, собственно, это без боли не обойдется, и оно же стало одним из движущих факторов зачинания хреновой уймы инструментов-«песочниц». Как бы, докер, флатпак, снап, lxc/lxd как раз в списке решаемых проблем имеют отсутствие хреновой уймы разнообразных окружений. Они как раз их унифицируют и стабилизируют.

                                                                Собственно, отсюда и 2 вещи:
                                                                1. Становится понятно, кто «оплачивает банкет».
                                                                2. Почему ни один коммерческий проект официально генту и идеологически-сходные дистрибутивы не поддерживает.

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

                              • Emil983
                                /#20033432

                                Ага, деплой скрипт, который пойдет все качать, ставить настраивать и тд, и тд. вместо того чтобы просто сделать docker pull и запустить уже собранный образ. Вообще ведь никакой разницы…

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

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

                                • mayorovp
                                  /#20033496

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

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


                                  Если вы скажите про локальный репозиторий образов — то ведь и деплой скрипт может к локальным репозиториям обращаться...


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

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


                                  Мне как-то не очень нравится идея гонять по сети туда-сюда контейнер с, допустим, установленной Visual Studio на 5 гигабайт — а ведь некоторые из проектов, над которыми я работал, иначе и не соберутся...


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


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

                                  А зачем ему в таком случае его как-то специально запускать, и почему он не может просто пойти на стенд где этот проект уже развернут и запущен?

                                  • qrKot
                                    /#20033878

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

                                    Если вы скажите про локальный репозиторий образов — то ведь и деплой скрипт может к локальным репозиториям обращаться…


                                    Вы же понимаете, что цепочка «поставить необходимые пакеты -> разложить конфиги в нужной последовательности -> пнуть необходимые демоны/сервисы, чтобы стартанули» несколько более сложна и менее предсказуема, чем «скопировать N иммутабельных слоев, положить в оговоренное место»?

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


                                    Именно! Окружение для сборки — в контейнере. Если билд-инструментарий «копеечный» — просто оставляем «как есть», т.к. слой с тулингом сборки будет один на N собранных образов (нет, N мало, лучше все-таки K). Если каждый проект тянет за собой гигабайт зависимостей (предположим, Node.js) — имеем отдельный билд-образ, собирающий проект, и отдельный образ с полученным «артефактом сборки».

                                    Мне как-то не очень нравится идея гонять по сети туда-сюда контейнер с, допустим, установленной Visual Studio на 5 гигабайт — а ведь некоторые из проектов, над которыми я работал, иначе и не соберутся...


                                    Могу вас утешить… Дважды… Нет, трижды даже:
                                    1. Образ вытягивается по сети при первом использовании, дальше лежит локально, пока не потребуется обновить.
                                    2. Visual Studio вы в контейнер не запихаете. Просто не получится. Т.е. если проект — Visual Studio only, это просто не ваш случай.
                                    3. Собирать прямо в докере вас тоже никто не заставляет. Это просто best practice такой для определенного диапазона проектов. Если вам в этом неудобно, возможно, оно вам просто не подходит.

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


                                    Не будет. Версий .NET Core больше одной, вы вполне можете иметь более 1 проекта одновременно, и зависимости проектов могут разрастаться, например. К тому же сама «умелка» развернуть проект, подтянуть к нему 100500 «вспомогательных» вещей, потестить, а потом тупо мановением руки удалить все (действительно все), что проект притащил за собой, не оставив окровавленных ошметков от проекта, размазанных по всей системе… Ну, это само по себе ценно, например.

                                    Ну а в момент деплоя, один общий слой с рантаймом .NET Core на 100500 проектов нормально так экономит место на диске, оставляя за вами возможность иметь более одного рантайма на хосте.

                                    • mayorovp
                                      /#20033992

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

                                      Это цепочку всё равно придётся проделывать при сборке образа.


                                      К тому же сама «умелка» развернуть проект, подтянуть к нему 100500 «вспомогательных» вещей, потестить, а потом тупо мановением руки удалить все (действительно все), что проект притащил за собой, не оставив окровавленных ошметков от проекта, размазанных по всей системе… Ну, это само по себе ценно, например.

                                      Это базовая функциональность .NET Core.


                                      Ну а в момент деплоя, один общий слой с рантаймом .NET Core на 100500 проектов нормально так экономит место на диске, оставляя за вами возможность иметь более одного рантайма на хосте.

                                      Нет смысла. Если фиксировать версию рантайма — то каждый проект будет идти со своим рантаймом, мы новые проекты начинаем реже чем рантаймы выходят. А если её не фиксировать — то сойдет и просто самый свежий рантайм, обратная совместимость все-таки существует.

                                      • qrKot
                                        /#20034088

                                        Это цепочку всё равно придётся проделывать при сборке образа.


                                        Не отрицаю. Просто происходить это будет не при каждой сборке и не целиком, а только при изменении в проекте и теми кусками, которые нужно пересобрать. Т.е. как раз рантайм, например, тащить каждый раз не придется, он будет лежать в базовом слое. При наличии, допустим, 10 приложений на 2 версиях рантайма, у вас будет ровно 2 слоя с рантаймом + 10 слоев приложения (поверх рантайма, не включая).

                                        А еще мы можем вспомнить про то, что apt update && apt upgrade (пакетный менеджер не принципиален, вставьте аналогичные команды своего любимого pm) может положить в систему не ту версию библиотеки, с которой приложение собиралось… В общем, проблем может возникнуть несколько более одной.

                                        Напомню еще про то, что таки «положить нужные слои в нужной последовательности» — тупо быстрее.

                                        Это базовая функциональность .NET Core.


                                        Ну неправда же. Вот понадобился мне в проекте, допустим, работающий… не знаю… ghostscript со специфическими настройками. Какой базовый инструмент .NET Core мне эту задачу решит?

                                        Нет смысла. Если фиксировать версию рантайма — то каждый проект будет идти со своим рантаймом, мы новые проекты начинаем реже чем рантаймы выходят. А если её не фиксировать — то сойдет и просто самый свежий рантайм, обратная совместимость все-таки существует.


                                        Ситуация: 10 проектов. 2 просят версию 1.0.11.23.55beta — строго фиксированную. 3 просят любую v1, 4 просят v2-самую-свежую, еще один хочет v2-не-выше-2.2. (Версии взяты с потолка). Все это должно крутиться на одной машине, при этом в процессе работы сервисов используется тулза (пусть будет что-то консольное, тот же ghostscript), но 1 сервис хочет 1-ю версию (и переписывать никто не будет, исходники надежно про… теряны, а работать должно сегодня), остальные — 2ю (а там, предположим, апи поменялся).

                                        Что будем делать, шеф?

                                        обратная совместимость все-таки существует.


                                        Вот с этих слов обычно и начинаются проблемы…

                                        • mayorovp
                                          /#20034536

                                          Вот понадобился мне в проекте, допустим, работающий… не знаю… ghostscript со специфическими настройками.

                                          Поможет пакет Ghostscript из nuget.


                                          Я понимаю, что под ghostscript вы понимали произвольную стороннюю программу, но примечательно что первый же пример нашелся в репозитории.


                                          Если же то чего нужно не найдется в nuget — всегда есть варианты вендоринга или своего собственного репозитория nuget.


                                          Что будем делать, шеф?

                                          Если никто не жалел места — то нужно просто взять готовый дистрибутив со всеми правильными версиями и развернуть его. Это так же просто как развернуть докер-образ, только без докера.


                                          Если места таки пожалели — есть nuget и есть лок-файл, где зафиксированы конкретные версии. Да, может произойти форс-мажор вроде случившегося с left-pad — но то же самое может случиться и с базовыми докер-образами. С версией рантайма сложнее, но основные можно скачать, а версия 1.0.11.23.55beta точно будет в дистрибутиве.

                                          • qrKot
                                            /#20034892

                                            Поможет пакет Ghostscript из nuget.

                                            Я понимаю, что под ghostscript вы понимали произвольную стороннюю программу, но примечательно что первый же пример нашелся в репозитории.


                                            Посмотрел, немного не то нашлось в репозитории. «The ghostscript dlls» написано. А мне экзешник нужен, причем с путями прописанными… Вот такие «зависимости», сори, конечно, ни один языковой пакетный менеджер не резолвит.

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

                                            Если никто не жалел места — то нужно просто взять готовый дистрибутив со всеми правильными версиями и развернуть его. Это так же просто как развернуть докер-образ, только без докера.


                                            Развернуть-то куда?

                                            «На железку»? Ценник решения в случае 2-3 конфликтующих конфигураций, собственно, и растет ровно в те же 2-3 раза… Ну, такое себе.

                                            В виртуалку? Ну, тоже оверхед не копеечный ни разу…

                                            А если все это для отладки прямо на машине разработчика запустить — вообще шик будет.

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


                                            Проблема пары рантаймов в одном окружении так и не решена. Юзать несколько разных рантаймов на системном уровне — плохая идея. Таскать рантайм за каждым проектом свой — докер экономнее получится.

                                            Да, может произойти форс-мажор вроде случившегося с left-pad — но то же самое может случиться и с базовыми докер-образами.


                                            Не, с моими, например, не может. Я базовый образ для своих проектов в собственном регистри держу, например. Я вот этот node-style подход вообще не одобряю…

                                            С версией рантайма сложнее, но основные можно скачать, а версия 1.0.11.23.55beta точно будет в дистрибутиве.


                                            Не, совершенно не точно будет. И, опять же, «можно скачать». Т.е., типа, скачать, сложить, а потом ручками раскатывать на сервера по памятке: «поставить рантайм версии X.Y.Z -> Далее -> Далее -> Далее»? Не-не-не, увольте)

                                            • mayorovp
                                              /#20035284

                                              Посмотрел, немного не то нашлось в репозитории. «The ghostscript dlls» написано. А мне экзешник нужен, причем с путями прописанными… Вот такие «зависимости», сори, конечно, ни один языковой пакетный менеджер не резолвит.

                                              А, собственно, нахера экзешник-то, да ещё и с путями прописанными? Зачем он нужен когда библиотека есть?


                                              Развернуть-то куда?

                                              Туда, куда требуется. Это ж вы изначально поставили задачу что надо приложение куда-то там поставить.


                                              Хоть на железку, хоть в виртуалку, хоть в контейнер.


                                              Таскать рантайм за каждым проектом свой — докер экономнее получится.

                                              Не получится: там кроме рантайма же куча библиотек, в том числе системных.


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

                                              Ну так и nuget-репозиторий можно свой держать при желании.


                                              Не, совершенно не точно будет.

                                              Совершенно точно будет. Ибо это самый простой способ обеспечить рантайм версии 1.0.11.23.55beta на проде.


                                              PS Кстати, у меня вот к вам встречный вопрос возник. Что вы будете делать если у вам потребуется развернуть два разных проекта, которые требуют несовместимых версий докера?

                                              • qrKot
                                                /#20036076

                                                А, собственно, нахера экзешник-то, да ещё и с путями прописанными? Зачем он нужен когда библиотека есть?


                                                Элементарно:
                                                Process.Start("someExeFile.exe")
                                                Имею право, почему нет? И вот этот someExeFile.exe туда как-то принести надо.

                                                Хоть на железку, хоть в виртуалку, хоть в контейнер.


                                                На железку один скрипт будет, на виртуалку… ну ладно, такой же, как на железку + разворачивание виртуалки. В контейнер — отдельный скрипт. Ну и нафига все это?

                                                Собственно, фишка контейнеров в том, что можно совершенно одинаково задеплоить несколько приложений, вне зависимости от языка, на котором эти приложения написаны. Т.е., предположим, у вас есть некоторый бек на C#, который использует что-то вроде мем-кеша, написанного на Java, рассылает уведомления скриптом на PHP, доступным на определенном порту, и все это валит логи в специальный парсер, написанный юным дарованием на Python.

                                                Сравниваем ваш деплой скрипт с докеровским. Докер: «Запустить рядом 4 контейнера. Тчк.» Ваш: «Установить .NET рантайм. Установить Java-рантайм. Вкорячить PHP+Apache (на нестандартном порту, чтобы не подрался с уже имеющимся на хосте nginx'ом). Установить python. Собрать venv, запустить парсилку логов. Положить конфиги апача, стартануть апач. Подтянуть зависимости java-аппликухи, стартануть мемкеш. Подтянуть бекенд, положить зависимости рядом. Стартануть, наконец, бекенд.»

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

                                                Не получится: там кроме рантайма же куча библиотек, в том числе системных.


                                                Получится. Доку по контейнерам почитайте уже, что ли. Есть такая штука — слои. Выглядеть может так:
                                                1. Есть базовый слой, «голая ОСь» (на самом деле, никакой оси там нет, оно все от libc начинается. Ниже — ядро хоста). — предположим, 30Мб.
                                                2. Поверх нее слой с системными библиотеками. — предположим, еще 20Мб.
                                                3. Слой рантайма — пусть будет 100Мб.
                                                4. Слой зависимостей приложения — (зависит от приложухи) пусть будет 10-30Мб.
                                                5. Слой самого приложения — (зависит от приложения) пусть будет 5-20Мб.

                                                После этого вы пишете 3 приложения на одной версии рантайма. Получаем: 150Мб — общие слои, 15-50Мб на каждое приложение собственных слоев. По пессимистичным прикидкам 300Мб всего.
                                                Берем еще одну версию рантайма: 50Мб слоев — общие, имеем второй слой рантайма (пусть 200Мб), пишем еще 3 приложения. Получаем 650Мб «на всех».

                                                Берем «классику» «нам надо несколько рантаймов, поэтом каждое приложение будет рантайм носить в себе». Первая версия рантайма 3по100 + 150 на приложения = 450Мб. Вторая версия рантайма — 3по200 + 150 на приложения = 750Мб. Опа! У нас одна вторая версия заняла больше, чем все вместе в докере.

                                                Ну так и nuget-репозиторий можно свой держать при желании.


                                                Не только можно, а, видимо, нужно.

                                                Совершенно точно будет. Ибо это самый простой способ обеспечить рантайм версии 1.0.11.23.55beta на проде.


                                                Ну т.е. «правильный» подход — хранить рантайм с проектом вместе.

                                                Что вы будете делать если у вам потребуется развернуть два разных проекта, которые требуют несовместимых версий докера?


                                                Несовместимых, простите, с чем? Вы точно понимаете, что такое докер? Это не VM, это просто управлялка штатными механизмами изоляции ядра.

                                                • mayorovp
                                                  /#20036328

                                                  Имею право, почему нет?

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


                                                  В контейнер — отдельный скрипт.

                                                  Зачем отдельный? Смотрел я формат ваших докерфайлов — не вижу причин которые бы помешали взять и запустить нужный скрипт в нем командой RUN. Или докерфайлы устарели и контейнеры теперь создаются как-то по-другому?


                                                  Сравниваем ваш деплой скрипт с докеровским. Докер: «Запустить рядом 4 контейнера. Тчк.» Ваш: «Установить .NET рантайм. Установить Java-рантайм. [...]

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


                                                  Всё остальное можно и правда поместить в контейнеры если оно так проще.


                                                  Кстати, а контейнеры настраивать чтобы они совместно работали уже не надо?


                                                  Несовместимых, простите, с чем? Вы точно понимаете, что такое докер? Это не VM, это просто управлялка штатными механизмами изоляции ядра.

                                                  Допустим, там форматы контейнеров разные. Что будете делать?

                                                  • qrKot
                                                    /#20036510

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


                                                    Ну, во первых, имею право, ничего предосудительного в этом нет. В конце концов, и работа с библиотекой может быть сложнее, чем «пнуть экзешник с набором параметров». И сама либа-враппер может быть разной степени сомнительности. Да и приложуха по сути вполне может быть какой-нибудь «удаленной управлялкой», которая в 99% случаев дает какую-то команду в консоль и парсит выдачу. Так что «разное бывает», а все рекомендации вида «вот же вам библиотеку написали» основаны на том, что штатных языковых средств для деплоя связанных бинарников не предусмотрено.

                                                    Да и, собственно, а если библиотеки нет?

                                                    Не, не зачёт, короче.

                                                    Зачем отдельный? Смотрел я формат ваших докерфайлов — не вижу причин которые бы помешали взять и запустить нужный скрипт в нем командой RUN. Или докерфайлы устарели и контейнеры теперь создаются как-то по-другому?


                                                    С докерфайлами, как раз, проблемы нет. Там строго один путь. Вы же про деплой ансиблом говорили. Собственно, деплой на железяку ансиблом будет выглядеть, как набор последовательных установок требуемых зависимостей, копирование бинарей и запуск. Деплой в контейнер тем же ансиблом будет выглядеть как «пнуть докерфайл, запустить то, что собралось». К слову, сам это ансибл сделать не сможет, докер ему понадобится. Т.е. вообще не совсем понятно становится, нафига в сборке докер-образа ансибл…

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


                                                    Рантайм отдельно ставить нужно. Именно в случае .NET Core. Либо пользоваться тем, что уже стоит на хосте… Но если он стоит на хосте, значит его установили, просто чуть раньше. И рекомендация по использованию различных рантаймов в одной среде выглядит как «принесите рантайм с собой». Ну, т.е. либо вы ставите рантайм на сервер заранее и делаете круглые глаза «я его не ставил, оно само, оно тут всегда было», либо копируете копию рантайма с приложением вместе.

                                                    Всё остальное можно и правда поместить в контейнеры если оно так проще.


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

                                                    Кстати, а контейнеры настраивать чтобы они совместно работали уже не надо?


                                                    Если нужно, чтобы они просто работали параллельно и друг другу не мешали — то не надо. Если нужна связная сущность с набором контейнеров, то надо, конечно. Но, как бэ, по опыту:
                                                    1. Есть несколько более удобные инструменты оркестрации контейнерами, чем ansible. Причем по мере использования вы, скорее всего, просто перепишете тот же docker-compose в виде ansible-playbook'ов. Ну и нафига, спрашивается, если инструмент уже есть? NIH-синдром?
                                                    2. Контейнерная изоляция даст вам возможность в момент настройки рабочего окружения (из набора взаимосвязанных контейнеров) не заморачиваться на то, что рядом существуют другие окружения. Скажем, того же postgre несколько экземпляров поднять на одной машине — задача достаточно нетривиальная. Поднять же по постгресу на каждое окружение — вообще без заморочек, они даже знать не будут, что они рядом. (Оффтоп: не подумайте, что я агитирую за то, чтобы держать БД в докере. Постгря взята строго в качестве примера, не более того. Никогда не делайте так в проде.)

                                                    Допустим, там форматы контейнеров разные. Что будете делать?


                                                    Давайте, все же, разделим понятия «образ» и «контейнер». Образ — это та штука, которая из Dockerfile'а собирается. Контейнер — запущенный экземпляр этой самой штуки.

                                                    Я просто про что. Если вы имели в виду «разные несовместимые форматы образов» — чушь. Их нет, например. Образ — это набор слоев, каждый из которых — тупо tar-архив, содержащий в себе diff от предыдущего слоя. Т.е. когда вы напишете FROM базовый образ и добавите что-то вида COPY fileName path, у вас сформируется «слой», т.е. тупо tar-архивчик, в котором этот самый файл будет лежать. О каких несовместимых форматах образов мы говорим?

                                                    Предположим, что вы говорили именно про контейнер. Ну и тут я вас отвечу: «Да насрать». Возьмите докер — у него свой «формат контейнера», k8s — свой (ЕМНИП, у них CRI-O). Вся фишка в том, что контейнер существует ровно с момента запуска, это, если угодно, «рантайм-сущность». А на входе один фиг образ, который для всех одинаковый. Как он представлен в виде контейнера никого не колышет, он будет работать.

                                                    • mayorovp
                                                      /#20036610

                                                      Вы же про деплой ансиблом говорили.

                                                      Я разве что-то говорил про ансибл?


                                                      Рантайм отдельно ставить нужно. Именно в случае .NET Core. [...] копируете копию рантайма с приложением вместе.

                                                      Да, именно так. Копия рантайма идет вместе с приложением. И всё работает.


                                                      Если нужно, чтобы они просто работали параллельно и друг другу не мешали — то не надо.

                                                      Нет, во вашему же условию они все должны друг с другом взаимодействовать.


                                                      Есть несколько более удобные инструменты оркестрации контейнерами, чем ansible. Причем по мере использования вы, скорее всего, просто перепишете тот же docker-compose в виде ansible-playbook'ов. Ну и нафига, спрашивается, если инструмент уже есть? NIH-синдром?

                                                      Не вполне понимаю о чем речь и при чем тут ansible. Вот у вас есть задача: "есть некоторый бек на C#, который использует что-то вроде мем-кеша, написанного на Java". Нужно связать контейрен с беком на C# и контейнер с кешем на Java, чтобы первый мог обращаться ко второму.


                                                      Какая такая магия позволит установить эту связь автоматически, в формате "просто запускаем два контейнера и всё заработало"?


                                                      Я просто про что. Если вы имели в виду «разные несовместимые форматы образов» — чушь. Их нет, например. Образ — это набор слоев, каждый из которых — тупо tar-архив, содержащий в себе diff от предыдущего слоя.

                                                      Да, я говорил об образах.


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


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

                                                      • qrKot
                                                        /#20036740

                                                        Я разве что-то говорил про ансибл?


                                                        Ну, может, и не вы. Может, контекст статьи подхватился ошибочно. Сорян тогда, если что.

                                                        Да, именно так. Копия рантайма идет вместе с приложением. И всё работает.


                                                        Вот к вопросу о «бонусах» контейнеров. В контейнере у вас базовый слой (X Мб) + слой рантайма (Y Мб) + слой приложения (Zn Мб, где n — идентификатор приложения). При наличии более одного приложения, пусть будет K штук, мы имеем следующую картину.

                                                        Рантайм с собой:
                                                        V(суммарный объем) = (K * Y) + (Z1 + Z2 + Z3 +… + ZK)
                                                        Докер деплой:
                                                        V = (X + Y) + (Z1 + Z2 + Z3 +… + ZK).

                                                        Несложно заметить, что, по сути, разница сводится тупо к (K * Y) vs (X + Y). Т.е. как только размер базового образа компенсируется количеством инстансов рантайма, существование какой-то выгоды от контейнеризации можно считать доказанным.

                                                        При это оно все так же работает.

                                                        Вот у вас есть задача: «есть некоторый бек на C#, который использует что-то вроде мем-кеша, написанного на Java». Нужно связать контейрен с беком на C# и контейнер с кешем на Java, чтобы первый мог обращаться ко второму.

                                                        Какая такая магия позволит установить эту связь автоматически, в формате «просто запускаем два контейнера и всё заработало»?


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

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

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

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

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


                                                        Неа. Там просто ссылка на id-шник самого верхнего. А в нем (вы же помните, с чего dockerfile начинается) FROM имяБазовогоОбраза тупо ссылка на родителя есть. И все.

                                                        Представьте, что в новой версии докера формат метаданных изменился.


                                                        Слабо верится. Очень слабо. На что менять-то? Там просто пары ключ-значение. Собственно, ни разу не менялся, а сейчас сменится? А кто в этом заинтересован? А кто меня заставит не мигрировать на новую версию по человечьи, а тупо убить к фигам всю экосистему и начать с нуля? Кто мне запретит, например, пересобрать образы? Ведь если запускалка поменяла формат, билд-инструментарий под это тоже есть ведь?

                                                        Не, не страшно.

                                                        И ещё, чтобы было веселее, заодно изменился формат докерфайлов.


                                                        Это называется «миграция на новую версию». Докерфайлы — они такие… как бы это вам сказать… текстовые. Я ведь могу и переписать при острой надобности, например. Там не сложно, на самом деле.

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


                                                        Ну, это как представить, что, например, вы на C# разрабатываете, и тут у C# появился конкурент (бугага, тысячи их, и уже есть). И к вам приходят и говорят: вот тут проект на Java есть, возьметесь? Буду считать, это же очевидно!

                                                        • mayorovp
                                                          /#20036848

                                                          Вот к вопросу о «бонусах» контейнеров.

                                                          Экономия на спичках.


                                                          Там просто ссылка на id-шник...

                                                          … которая где-то записана в каком-то формате. Есть чему меняться.


                                                          Слабо верится. Очень слабо.

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


                                                          Это называется «миграция на новую версию». Докерфайлы — они такие… как бы это вам сказать… текстовые. Я ведь могу и переписать при острой надобности, например. Там не сложно, на самом деле.

                                                          Вот и я могу!

                                                          • qrKot
                                                            /#20036886

                                                            Экономия на спичках.


                                                            Ну, она есть. С изоляцией запуска до кучи выглядит уже лучше.

                                                            … которая где-то записана в каком-то формате. Есть чему меняться.


                                                            В текстовом. Сложно что-то поменять.

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


                                                            Ну, как бы, стоит признать, что смигрировать проект с .NET 2.0 на .NET 4.6 — гораздо менее тривиальная задача, чем пнуть пересборку докер-образов.

                                                            • mayorovp
                                                              /#20036968

                                                              В текстовом. Сложно что-то поменять.

                                                              Вы недооцениваете изобретательность тех, кому поставлена задача "поменяй что-нибудь, чтобы появился повод всем переходить на новую версию" :-)


                                                              Ну, как бы, стоит признать, что смигрировать проект с .NET 2.0 на .NET 4.6 — гораздо менее тривиальная задача, чем пнуть пересборку докер-образов.

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

                                                              • qrKot
                                                                /#20037690

                                                                Вы недооцениваете изобретательность тех, кому поставлена задача «поменяй что-нибудь, чтобы появился повод всем переходить на новую версию» :-)


                                                                Осталось понять, кто эту задачу поставит. Дело в том, что docker-ce — продукт жизнедеятельности компании Docker.Inc. У них не сказать, что прямо головокружительные успехи, но живут, на жизнь особо не жалуются. Торгуют они, в основном, подписками на docker-enterprise, а также немножко мощностями для приватных репозиториев и прочих радостей жизни.

                                                                Поломанная обратная совместимость для них… Ну, как вам сказать, будут ли довольны подписчики enterprise-версии, если у них что-то перестанет работать?

                                                                Основные же продавцы контейнеров (в виде мощностей, чтобы их крутить) — «большая тройка» MS, Google, Amazon (плюс несколько контор поменьше). Они продают мощности, т.е. они кровно заинтересованы, чтобы ничего не сломалось. При этом крутят они всю эту радость в k8s, в котором от докера… Ничего. Единственный, не замещенный собственным продуктом инструмент — билд образа. Т.е. докер как таковой используется только на этапе сборки, в рантайме он не участвует.

                                                                Если Docker.Inc решит «поднасрать большим дядям»… Ну, учитывая открытость docker-ce продукта… Думаю, замещающий инструмент «который ничего не ломает» Google + MS + Amazon родят за сутки. И никто ни на какие новые версии апгрейдиться не будет, ибо «а зачем». Короче, после такой эскапады правление Docker.Inc сможет на полных основаниях закрыть «избушку на клюшку» и начать распродавать имущество.

                                                                Ну, короче, не верится. Никто Docker.Inc что-то резко поменять не даст. Open Container Initiative есть та же самая, цельный консорциум, в который Docker.Inc добровольно-принудительно ввели. И без консенсуса внутри организации какие-то breaking changes замутить для «авторов» проекта — самая верная попытка самовыпилиться.

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


                                                                Не совсем верится, что проект NET2.0 можно тупо одной кнопочкой на автомате смигрировать на нормальный NET4.6. Не, я понимаю, что «на любой версии C# можно писать на первой». Но это, имхо, так себе «миграция». Да и не уверен, что все с полпинка заведется. Какие-то апи, наверняка, депрекейтнулись, переписывать придется. HelloWorld, вероятно, норм смигрирует, что-то крупнее… Ну, не знаю.

                                                                Ну, хотя, пусть его. Сделаем вид, что я вам поверил.

                                                                • mayorovp
                                                                  /#20037772

                                                                  И без консенсуса внутри организации какие-то breaking changes замутить для «авторов» проекта — самая верная попытка самовыпилиться.

                                                                  То же самое применимо и для .NET Core: поломанная обратная совместимость — самый простой способ растерять пользователей, и на нее просто так авторы не пойдут.


                                                                  Какие-то апи, наверняка, депрекейтнулись

                                                                  Заобсолетились, если точнее (.net использует атрибут [Obsolete]). Но их всё ещё можно использовать.


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

                                                                  • qrKot
                                                                    /#20037902

                                                                    То же самое применимо и для .NET Core: поломанная обратная совместимость — самый простой способ растерять пользователей, и на нее просто так авторы не пойдут.


                                                                    Breaking changes
                                                                    FileResult Range header
                                                                    FileResult no longer processes the Accept-Ranges header by default. To enable the Accept-Ranges header, set EnableRangeProcessing to true.

                                                                    ControllerBase.File and PhysicalFile Range header
                                                                    The following ControllerBase methods no longer processes the Accept-Ranges header by default:

                                                                    Overloads of ControllerBase.File
                                                                    ControllerBase.PhysicalFile
                                                                    To enable the Accept-Ranges header, set the EnableRangeProcessing parameter to true.


                                                                    Взято отсюда.

                                                                    Еще есть вот это.

                                                                    Т.е. заведется таки не все, как мне кажется.

                                                                    Заобсолетились, если точнее (.net использует атрибут [Obsolete]). Но их всё ещё можно использовать.


                                                                    Иногда что-нибудь по мелочам ломается. Ссылки выше.

                                                                    Не все безоблачно.

                                                                    • mayorovp
                                                                      /#20038124

                                                                      Описанное по обоим ссылкам — это не breaking changes в рантайме, а breaking changes в библиотеке. Старая версия библиотеки всё ещё доступна в nuget.


                                                                      В добавок, описанные по первой ссылке изменения даже при обновлении библиотеки не вступят в силу если не написать строчку .SetCompatibilityVersion(CompatibilityVersion.Version_2_1)

                                                                      • qrKot
                                                                        /#20038174

                                                                        Справедливости ради, во второй ссылке написано, что, например, Json.NET больше нет в базовой поставке ASP.NET Core. Т.е. «сам собой» проект со второго Core на третий не смигрирует, придется таки NuGet потрогать для начала.

                                                                        В первой же ссылке предлагают ручками выставить EnableRangeProcessing в true, чтобы получить прежнее поведение кода. Ну, т.е. «тут надо быть внимательным», потому что имхо, когда «не собралось вообще» — все же лучше, чем «собралось и даже работает, только немного по-другому».

                                                                        • mayorovp
                                                                          /#20038228

                                                                          Ну так задача-то была не на свежий ASP.NET Core смигрировать, а на свежий рантайм и свежий SDK. Не вижу причин, по которым я должен мигрировать на свежий ASP.NET Core в ситуации, когда (цитирую) "исходники надежно про… теряны, а работать должно сегодня".


                                                                          Что же до EnableRangeProcessing — то по первой ссылке предлагают выставить EnableRangeProcessing в true, одновременно выставив CompatibilityVersion в Version_2_1. Первый совет в отрыве от второго избыточен.

                                                                          • qrKot
                                                                            /#20038262

                                                                            Ну так задача-то была не на свежий ASP.NET Core смигрировать, а на свежий рантайм и свежий SDK.


                                                                            Процитирую себя: «Не совсем верится, что проект NET2.0 можно тупо одной кнопочкой на автомате смигрировать на нормальный NET4.6»

                                                                            Задача была именно переползти на новый стек. Рискну предположить, что исходники под .NET 2.0 на .NET Core не соберутся, к слову.

                                                                            • mayorovp
                                                                              /#20038310

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


                                                                              Рискну предположить, что исходники под .NET 2.0 на .NET Core не соберутся, к слову.

                                                                              Ну да, потому что .NET и .NET Core — это не две разные версии рантайма, а два разных рантайма.

                                                                              • qrKot
                                                                                /#20038368

                                                                                Ну, если речь идёт о переходе на новый стек — то докер тут вообще никак не поможет


                                                                                На самом деле, поможет. Чуть-чуть. В определенных ситуациях. Если, например, ваше приложение состоит из нескольких сервисов. Вы по тихой грусти переносите один из сервисов на новый рантайм, остальные крутятся на старом.

                                                                                Плюсом вы можете не гасить старую версию, пока не убедились, что новая «фурычит». Запустили параллельно, потестили, потыкали в балансировщик, мол, пора бы уже и стрелки переводить. Ничего не упало, все работает — выключаем старую версию. Все упало? Тупо переводим стрелки балансировщика. Упала-то только новая версия, старая все еще работает.

                                                                                ведь все докерфайлы придётся обновлять.


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

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


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

                                                                                Ну да, потому что .NET и .NET Core — это не две разные версии рантайма, а два разных рантайма.


                                                                                Правильно, как и .NET 3.5 vs .NET 4.6. Даже больше того, 4.5 и 4.6 — разные рантаймы, вплоть до версии языка.

                                                                                • mayorovp
                                                                                  /#20038474

                                                                                  На самом деле, поможет. Чуть-чуть. [...]

                                                                                  Ну так без докера так тоже можно.


                                                                                  Ну не все же. Да и поменять одну строчку и запустить ребилд.

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

                                                                                  Вот пути до файлов сломать и можно. В каждой версии их можно менять :-)


                                                                                  А уж если формат конфига сменился...


                                                                                  Из опыта: использовали Монгу (MongoDB) — так там авторы в какой-то из версий поменяли формат передачи параметров в командной строке. Не то -- на /, не то / на --, уже не помню. Вот как тут ребилд образа помог бы?


                                                                                  Правильно, как и .NET 3.5 vs .NET 4.6. Даже больше того, 4.5 и 4.6 — разные рантаймы, вплоть до версии языка.

                                                                                  Вы ошибаетесь, трижды. Во-первых, .NET 3.5 и .NET 4.6 — это две разные версии одного рантайма, там есть обратная совместимость.


                                                                                  Во-вторых, 4.5 и 4.6 — это вообще один и тот же рантайм, отличается лишь версия стандартной библиотеки.


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

                                        • nightvich
                                          /#20035504

                                          Так и хочется вам сказать, идите уже на… отдельный чат со своим .NET Core…

                                          • qrKot
                                            /#20036096

                                            Я не сишарпер. Так что .NET Core, видимо, скорее ваш (если вы на C# пишете).

                                          • 0xd34df00d
                                            /#20044916

                                            А мне интересно почитать. Тут в C++-коммьюнити периодически что-то говорят про пакетные менеджеры, управление зависимостями, совместимость и прочую модульность. Интересно же, какие шишки другие языки и инфраструктуры уже успели набить.

                          • tamapw
                            /#20032604

                            У нас готовое приложение на java, завёрнутое в докер весит не больше 200(!) мегабайт, хотя я и такого не смог найти. Не больше 150 выходит.
                            Но у нас микросервисы, которые не совсем и микро, просто разделены на функциональные компоненты и не повторяют костыли одного и того же, если уже есть сервис с нужным функционалом.

                            Все зависимости, абсолютно все, нужные для работы приложения уже включены в этот образ. И это при том, что используется довольно объёмный spring boot(который тянет за собой всё, что только можно).

                            Образ одного, так сказать, самого большого по количеству интеграций и функций, backend-приложения — 140мб. Из них 70мб — само приложение и 70 мб чисто окружения-alpine

                            Собственно, к чему это я — что у вас там за безумные приложения, что тянут за собой зависимости в 1гб(!) и при этом сам образ под гб доходит? Реально интересен функционал, который требует таких размеров?

                            • Emil983
                              /#20032612

                              Абсолютно поддержу. Единственное, что может там 60 слоев в сборке контейнера.

                  • SirEdvin
                    /#20030600

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

                  • qrKot
                    /#20031470

                    Что-то мимо вообще. По памяти и диску от докера оверхед настолько минимален, что его можно списать в статпогрешность.

                    Я бы понял, если бы вы на сеть жаловались. Там и x3 расход сокетов, и некоторые задержки от виртуализации таки есть, в некоторых случаях вообще на проце считает… Но тут уж просто замеряйте, хватает вам latency, или докер не для вас…

    • CrzyDocTI
      /#20029428

      а как поднять микросервисы без того-же lxc/docker и иже с ними?

    • balsoft
      /#20031040

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

      Если вы про NixOS и GuixSD, то они решают не только и не столько эти проблемы. Для начала, они требуют от пользователя отличного понимания принципов работы, но только уже не только Linux, а ещё и своей системы конфигурации и сборки пакетов. Более того, и nix, и guix вполне себе интегрированы с докером и взаимодополняются с ним. Взять тот же nix-bundle и nix-docker, и guix --compose. Если вы про ещё какие-то дистрибутивы, то можно поподробнее?

    • qrKot
      /#20031456

      К счастью, рынок большой, помимо хипстоты, есть и более консервативные конторы или хотя бы отделы.


      Сноба в тебе вижу я…

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


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

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


      Что-то вы и LXC в старье запихали, и snap в ту же кучу замешали…

  8. bisquitie
    /#20029208 / +3

    Я как-то поработал с большой инфраструктурой на докере. Там swarm, пару десятков тысяч контейнеров, каждый из которых жрал по 3-4 гигабайта памяти. Всё на безумных серверах с терабайтами оперативки. Так вот, докер не просто бажный, он чертовски бажный. И иногда он может настолько больно вытрелить по ногам, что больше притрагиваться к нему не захочется. Ну например, несколько раз сталкивался с тем, что на одном из менеджеров что-то начинает клинить, и из-за этого перестают создаваться новые сервисы, не могут найти образ. Постепенно выясняется, что это из-за каких-то проблем с докер-сетью. Ковыряясь дальше выясняется, что это из-за парочки зависших контейнеров, которые уже давно удалены, но каким-то чудом продолжают работать. Пока не форсируешь их удаление и не пересоздашь сеть, ничего нового в кластере не запустится.
    Ну и у него есть куча проблем вида «это не баг а фича,» одна из основных и простейших — это абсолютное неумение передать ip пользователя клиентам в swarm. Приходится устраивать костыли в виде глобальных сервисов. И зачем тогда такой красивый swarm нужен?
    Несмотря на кучу минусов докер, конечно, мощная штука. Но готовить его надо с особой осторожностью, и если хочется действительно беспрерывной работы всей этой тучи, то архитектуру надо планировать крайне тщательно, закладывая двойной оверхэд по ресурсам.

    По ансиблу ничего не могу сказать, сама концепция не очень понятна. Зачем городить надстройки к тому, что можно сделать простым bash? С другой стороны, ни разу серьёзно им не пользовался, скорее всего потому и не понимаю.

    • mishast
      /#20029552

      Это где так мощщно используется docker? В какой компании?

      • bisquitie
        /#20029644

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

    • GrigoryPerepechko
      /#20031684

      Не путайте docker и swarm. Ввместо второго в приличном обществе принято использовать кубернетес

      • bisquitie
        /#20033298

        Когда я работал над этим проектом, k8s был ещё в личиночном состоянии.
        PS: а почему не путать? swarm — нативный для докера оркестратор, и весьма неплохой в плане удобства, на мой взгляд. Легковесный, быстрый, без кучи гембеля как в том же k8s. Вот то что разрабы докера на него по сути забили, оставив жить с кучей багов, это конечно печально. А в чистом докере без оркестратора я уже смысла не вижу. Только для сборки образов и локального запуска на одном хосте? Ну такое, сомнительное применение, можно и lxc обойтись.

        • GrigoryPerepechko
          /#20033884

          То что нативный это хорошо, но вы писали что докер бажный, но приводили примеры багов сварма. Это и смутило.

          • bisquitie
            /#20033900

            Ну почему сворма-то? Ключевая проблема была в том, что докер не удалил контейнеры как надо, что-то ему помешало (по факту в списке запущенных их не было, но они были запущены, выяснить можно было либо через network inspect, либо через image inspect; когда и тех и других — сотни, задачка не из самых интересных). Запуск-удаление контейнеров вроде как относится именно к dockerd. Уж разбираться что именно к такому привело, было некогда, пардон. Всё остальное уже шло как последствия.
            ps: и чем swarm mode не часть докера? Вы не путаете со старым swarm, который как и кубернейтс, крутился в своих контейнерах?

    • OrangeCrusty
      /#20038792

      Это клауд был или какой-то ДЦ?

      • bisquitie
        /#20038838

        Не, просто кривая архитектура такая, так вышло ?\_(?)_/?

  9. 0xf0a00
    /#20029228 / -1

    Делал контейнер из Windows приложения и Wine. Такая себе штука этот ваш Docker. Мне лично показалось что проще было бы все поставить на целевой машине чем тащить в Docker.

  10. Knightt
    /#20029334 / +1

    Говорить, что Docker говно — все равно, что говорить: «отвертка — говно, так как хреново забивает гвозди!»

    Есть инструмент — его нужно использовать там, где НУЖНО!

    Из моего опыта — работа в студии… за день можно поработать с 3-мя проектами, которые используют разные базы, разные версии PHP, где-то Апач, где-то Нжинкс… я хз что бы делали без докера и докер-композера… а так: down/cahnge_project/up — и окружение полностью изменилось…

    • bisquitie
      /#20029674 / +1

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

      • apapacy
        /#20029716

        На проде у него своя ниша. Это микросервисы плюс k8s, nomad и т.п.
        Если тянуть на прод через docker-compose будет очень быстрое и простое первоначальное разворачивание приложения. И большие проблемы с деплоями.

        Отдельного внимания базы данных + docker + k8s

        Многие почему-то хотят этого. И теперь это уже почти возможно (то есть возмодно но неясно чтоб будет при падении базы данных — молча создасться нвоый экземпляр неизвестно на коком поде?) По-моему от связки базы данных + docker + k8s необходиом отказаться сразу и навсегда

        • SirEdvin
          /#20029890 / +1

          И теперь это уже почти возможно (то есть возмодно но неясно чтоб будет при падении базы данных — молча создасться нвоый экземпляр неизвестно на коком поде?) По-моему от связки базы данных + docker + k8s необходиом отказаться сразу и навсегда

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

          • gecube
            /#20031692

            Это вы так думаете, что репликая и прочие штуки творят чудеса. Проблематика в том, что существует куча легаси баз, которые не умеют в кворум и консенсус. Что с ними делать? Мучительно больно обмазывать очередными слоями абстракции, чтобы упихать в кубер? А не проще что-то типа RDS от Амазона использовать или любой другой managed инстанс и не ломать голову? Вот в результате и появляются мегаподелки вроде Stolon для постгрес (я, кстати, не говорю, что он плохой — скорее овер-усложненный). К сожалению, множество проектов пока не готово переехать на БД нового поколения типа Cockroach, да и то — там своих подводных камней хватит (точно проверяли на отказоустойчивость во всех сценариях отказов, split-brain etc?)

            • CrzyDocTI
              /#20031734

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

              • bisquitie
                /#20033318

                Ой, одному моему знакомому аппаратный raid-10 тоже очень больно выстрелил в голову. Этот уникум считал, что raid решит все его проблемы, и хранил бэкапы на этом же томе. В итоге, в один прекрасный момент винда решила глюкнуть, нештатно перезагрузившись, а по базе пошли волны, которые успешно этим рейдом отреплицировались на все диски тома, и бэкапы тоже отчего-то внезапно пострадали. Было смешно.

                • CrzyDocTI
                  /#20033328 / +2

                  не, ну так то я и шарик железный сломать могу=)

            • SirEdvin
              /#20031916

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

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


              managed инстансы это тоже вариант, но по нормальному они внутри так же используют какие-то технологии кластеризации.

              • gecube
                /#20032194

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

                Если вас устраивает единая точка отказа, то, как бы, пожалуйста.

                с чего Вы решили? Вы сами завели разговор про перенос баз в k8s. А там далеко не все так просто, как кажется.

      • qrKot
        /#20031482

        Для большого продакшена k8s, например, пилят. И даже используют. И даже успешно.

        К слову, в k8s от самого докера — ничего. В смысле, вообще ничего. В кейсе k8s-продакшен докер используется как инструментарий для сборки образов, остальное у k8s свое.

        Единственное, что действительно смущает во всей истории с linux-контейнерами — это как раз «средняя» ниша. Есть сам docker, который отлично работает в качестве инструмента сборки и тестирования в пределах 1-хостовой инсталляции. Есть k8s, который оправдан на мега-деплоях. А вот чего-то из разряда «у меня тут пара небольших серверов есть» надежного и обкатанного нет. Хоть оно и понятно, почему так.

        • de1m
          /#20033132

          K8S это ведь не про размеры, это про автоматизацию. У нас он (k8s) на трёх небольших серверах крутится и мы его взяли не из-за размера, а так-как нам нужено было автоматизировать некоторые вещи и на чистом докере можно было бы тоже сделать, но уже намного сложнее.

          • qrKot
            /#20033184 / +1

            K8S это ведь не про размеры, это про автоматизацию.


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

            У нас он (k8s) на трёх небольших серверах крутится


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

            Для сетапов типа «два дублирующих сервера» и прочих средне-мелких инсталляций k8s — жесточайший оверхед, а альтернатив уровня «взрослости» k8s нет и, собственно, не предвидится по вполне очевидным причинам (потому что «а кому это надо», точнее «кто оплатит банкет»).

            Т.е. именно «у меня тут пара небольших серверов есть»-кейс не покрыт ничем вменяемым, вот я про что.

            • apapacy
              /#20033366 / +1

              а альтернатив уровня «взрослости» k8s нет и, собственно, не предвидится

              В nomad есть много что нужно (хотя не все что есть в k8s)

            • Akuma
              /#20033834

              Ничего не мешает запустить k8s в том же GKE. Расходов на мастера там нет и можно хоть одну ноду делать, вообще без разницы. Смысла в этом конечно мало, но все же можно, я делал :)
              Из минусов — при обновлении кластера может быть простой. Но с одной нодой как бы… это нормально.

              • qrKot
                /#20033924

                Смысла в этом конечно мало


                Вот, оно!)))

                • Akuma
                  /#20033938

                  Ну если очень хочется сделать проект на k8s, но у вас только блог на 50 человек? Это отличный первоначальный опыт, кстати :)

                  • qrKot
                    /#20034906

                    Дык, попробовал уже, потыркал! Прикольная штука.

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

                    • Akuma
                      /#20035264

                      В это упираются абсолютно все проекты, как по мне.

  11. vladbarcelo
    /#20029988 / +1

    • для того чтобы мое приложение работало, нужен сам docker на сервере. А зачем мне это, если мои приложения работают на jre или на nodejs и окружение для них уже есть на сервере?

    На чистой вдске окружений как правило нет.


    • если я хочу запустить свой (приватный) локально собранный образ на удаленном сервере, то мне нужен свой docker репозиторий, нужно чтобы где-то работал registry и еще нужно настроить https, потому что docker cli работает только по https. Ох блин… есть варианты, конечно, сохранить образ локально через docker save и через scp просто скинуть образ… Но это столько телодвижений. И к тому же выглядит "костыльным" решением, пока не появится свой репозиторий

    Есть canister.io, с приватными registry, где всё работает из коробки.


    • docker-compose. Он нужен только для запуска контейнеров. И все. Больше ничего он не может. Docker-compose имеет кучу версий своих файлов, свой синтаксис. Каким декларативным он бы ни был, я не хочу читать их документацию. Мне она больше нигде не понадобится.

    То что вы не хотите читать документацию — это ваши личные проблемы.


    • при работе в команде, в большинстве своем люди пишут Dockerfile очень криво, не понимают как это кешируется, добавляют в образ все что надо и не надо, наследуются от образов которых нету в dockerhub или приватном репозитории, создают какие-то docker-compose файлы с базами данных и ничего не персистируют. При этом разработчики гордо заявляют, что docker крут, у них все работает локально и HR важно пишет в вакансии: "Мы используем docker и нам нужен кандидат с таким опытом работы"

    Каким образом некомпетентность девопсов это "проблема" докера?


    • постоянно преследуют мысли о поднятии в docker всего и вся: postgresql, kafka, redis. Жаль, что не всё работает в контейнерах, не все легко сконфигурировать и запустить. Поддерживаются это сторонними разработчиками, а не самими вендорами. И кстати сразу возникает вопрос, вендора не парятся насчет поддержания своих продуктов в docker, почему же это, может они что то знают?

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


    • всегда возникает вопрос про персистенцию данных контейнера. и тут думаешь, мне просто примонтировать хостовую директорию или создать docker volume или сделать data container который теперь deprecated? Если я монтирую директорию то мне нужно убедиться что uid и gid пользователя в контейнере соответствует id пользователя запустившего контейнер, иначе файлы созданные контейнером будут созданы с правами владельца root. Если использую volume то данные просто буду созданы в каком нибудь /usr/* и будет такая же история с uid и gid как в первом случае. Если запускаешь сторонний компонент то нужно вчитываться в документацию и искать ответ на вопрос: "а в какие директории контейнера компонент пишет файлы?"

    Никогда не имел проблем с монтированием какой-нибудь /data/docker/mongo в контейнер. Ансиблом создавались необходимые директории на серверах, выставлялись разрешения на пользователей, и запускался swarm.

  12. Brain_Overload
    /#20030022

    doсker отличнейший инструмент, просто
    А. надо уметь его готовить
    В. не запихивать его везде где можно, только потому, что могу.

    Недавно (тройку месяцев назад), я поработал с DevOps командой, почти каждый участник которой, негативно относился к docker

    а нужно ли всех слушать? у нас вот сидит тут девопс, который впервые в жизни графану у меня на мониторе увидел)

  13. kuPyxa
    /#20030100

    FreeBSD, Jail и Ansible — это все что нужно.

  14. igrishaev
    /#20030270

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

  15. akimdi
    /#20030302

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


    а по мне так Nix Package Manager решает все эти проблемы без всяких контейнеров

  16. arheyy
    /#20030552

    Для меня как-то странно сравнивать docker и ansible. Это как утверждать что вилка отстой и надо пользоваться ложкой. А если ansible билдит, запускает и скейлит докер контейнеры… Да не, глупости…

  17. OneFive
    /#20030554

    Просто оставлю тут пару цитат из статьи выше:

    В качестве виртуальной машины на локали можно использовать тот же Alpine

    Недавно я познакомился с ssh тунелями.

    Недавно (тройку месяцев назад), я поработал с DevOps командой

    На той же работе я и познакомился с еще одним инструментом — Ansible.

    зачем docker если, есть Ansible и виртуальные машины

    Недавно прочитал что SSH тунели это ограниченая функиональность обычного VPN!

    для того чтобы мое приложение работало, нужен сам docker на сервере. А зачем мне это, если мои приложения работают на jre или на nodejs и окружение для них уже есть на сервере?

    Как хорошо что не придется занимать место еще сотней мегабайт и уже скачана на сервере нужна версия node/jre.
    docker-compose. Он нужен только для запуска контейнеров. И все. Больше ничего он не может.

    Так хотелось бы что бы docker-compose делал еще кофе по утрам.
    Docker-compose имеет кучу версий своих файлов, свой синтаксис. Каким декларативным он бы ни был, я не хочу читать их документацию. Мне она больше нигде не понадобится.

    Действительно, где это видано доки читать в 2019 году.
    при работе в команде, в большинстве своем люди пишут Dockerfile очень криво

    Ну тут очевидно виноват докер.
    Терпеть не мог docker-compose, потому что не хотел учить еще один инструмент экосистемы docker.

    Хочу что бы по щучьему велению.
    Если вы все-таки решили использовать docker, то:
    1. будьте предельно осторожны

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

    docker load
    90% что нужно пробросить какие нибудь ssh ключи, секретные данные, которые не хочется писать в docker образ.

    То ли дело ansible.
    p.s. С нетерпением жду следующую статью.

    • mak_sim
      /#20030926 / +2

      Лучший комментарий из всех. Сложилось ровно такое же впечатление от статьи. «Не осилил забить отвёрткой гвоздь, нашёл долото… О, а им получилось!!1»

    • kondaurovDev
      /#20031172

      Действительно, где это видано доки читать в 2019 году.

      Так хотелось бы что бы docker-compose делал еще кофе по утрам.

      Я люблю читать тех информацию и применять ее в реальных проектах. Docker-compose это инструмент для запуска docker контейнеров, мне жалко тратить время на инструмент который я смогу применить в ограниченном круге, к тому же у него есть свои косяки и свое видение как должен выглядеть yml и как запускать контейнеры.
      Ну тут очевидно виноват докер.

      Нет, просто docker имеет низкий порог вхождения и к сожалению люди пишут криво
      docker load

      И эту процедуру нужно постоянно делать при каждом деплое?

      • qrKot
        /#20031540

        Я люблю читать тех информацию и применять ее в реальных проектах. Docker-compose это инструмент для запуска docker контейнеров, мне жалко тратить время на инструмент который я смогу применить в ограниченном круге


        Любой инструмент можно и нужно применять «в ограниченном круге». Ограниченном предназначением инструмента. Docker-compose — это инструмент для запуска docker-контейнеров, да. Было бы странным применять его за пределом «ограниченного круга» запуска контейнеров. У него, простите, и спецификация соответствующая — коротенькая такая, со вкусом, ничего лишнего, быстро «раскурить» можно.

        к тому же у него есть свои косяки и свое видение как должен выглядеть yml


        Не, тут вы наговариваете. Строго стандартный yml, в строгом соответствии со спецификацией.

        и как запускать контейнеры.


        Ну, тут, конечно, у всех свое видение. Собственно, можно и docker run, никто не запрещает. А docker-compose, по факту, тупо берет совершенно обычный yaml-файл, совершенно обыденно парсит его в древовидную структуру в памяти, а затем тупо выполняет команды вроде docker run до просветления… Никто не запрещает сделать то же самое руками.

        Нет, просто docker имеет низкий порог вхождения и к сожалению люди пишут криво


        Причисление низкого порога вхождения к недостаткам инструмента, простите, отдает снобизмом. Особенно для человека, который «мне жалко тратить время на инструмент который я смогу применить в ограниченном круге» (т.е. не осилил docker-compose).

        И эту процедуру нужно постоянно делать при каждом деплое?


        По разному можно. Можно, например, автоматизировать docker load. А можно и приватный репозиторий поднять, чтобы не scp-шить, например. Там тоже рокет-сайенса нет.

        • Maximuzzz
          /#20034592 / +1

          Ну а что вы хотели? Автор совсем недавно открыл туннелирование и ВПН и не хочет изучать документацию к инструменту с которым работает, а вы про yaml… Тоже, скорее всего, технология с ограниченным применением не заслуживающая изучения документации.

          • kondaurovDev
            /#20034692

            Docker-compose это просто python скрипт который дергает docker daemon api через другую python либу. Тоже самое использует Ansible, только с помощью него можно сделать что угодно и где угодно (создать директории, спулить образы, тп) + запустить docker контейнеры.

            Вопрос: Зачем изучать docker-compose если есть инструмент с более широким применением?
            Далее, какие есть варианты запуска контейнера на удаленной машине? (вангую сейчас скажете про docker swarm и его поддержку docker compose формата)

            Когда то нравился compose, но сейчас нет, потому что это оверхед над docker api. Натыкались на такие issue? github.com/docker/compose/issues/3574

            а вы про yaml… Тоже, скорее всего, технология с ограниченным применением не заслуживающая изучения документации.

            Мне нравится декларативное описание в yaml. Он намного лучше json
            Автор совсем недавно открыл туннелирование и ВПН и не хочет изучать документацию к инструменту с которым работает,

            Впн я давно использовал в компаниях где были админы и настраивали его сами. Про ssh туннели я не знал, да, но как то пользовался пробросом портов в `kubectl`, думал это специфичная штука кубера

            • qrKot
              /#20035010 / +2

              Тоже самое использует Ansible, только с помощью него можно сделать что угодно и где угодно (создать директории, спулить образы, тп) + запустить docker контейнеры.


              Смотрите, что у нас есть. У нас есть Ansible, который «может все». С 13-минутным intro-видео для базового понимания, что это вообще такое. Предположим, мы его посмотрели, и пошли устанавливать и запускать…

              Прошли 10-страничный howto по установке и базовой настройке, к пониманию происходящего вообще не приблизились, но, вроде, получили «работающий сервер». Дальше выяснили, что надо бы теперь и клиентов сконфигурять. Ansible, емнип, у нас по ssh тупо команды из плейбуков пинает. Отлично, я примерно знаю, как ssh-туннелирование работает, и что нужно для доступа на хост по ключу. Если человек не знает… Он, собственно, сначала идет гуглить, что такое ssh и с чем его едят.

              Ну, в общем, вполне приличный разработчик, с отличным знанием языка и умением его применять, думаю, за пару дней с ansible hello-world'ом справится.

              Ну, я не знаю, конечно… Может быть, вы лично и уверены, что валить всю эту (простите за прямоту) админскую муть на нормального разработчика — это хорошая идея. Но все ваши манипуляции с ансиблом (а он, положа руку на сердце, вообще нафига на машине разработчика нужен?) вообще не приблизят разработчика к получению эталонной среды для запуска приложения в целях отладки. Ему один фиг еще и докер вкорячить нужно, потому что для "+ запустить docker контейнеры" ансиблу таки еще и докер нужен.

              И вот мы имеем то, что имеем. Разраб тащит к себе на машину ансибл, чтобы один раз запустить плейбук, который ему сбилдит докерфайлы и запустит эталонное окружение? Вот серьезно? А плейбук прямо вот так будет docker network create говорить? И потом связно запускать все образы? Или просто тупо пнет docker-compose?

              Не получится ли «как всегда»? Когда из полученной связки «ансибл — докер» ансибл-монстр окажется лишним?

              Вот для разработчика он лишний. Прямо вообще в хлам лишний. Деплой — это уже больше в сторону ops'а из dev-ops, и там вполне можно уже ansibl'ом катать на целевые ноды. А можно, например, и terraform'ом справиться. Тоже отличный инструмент, между прочим.

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

              • gecube
                /#20035208

                Насчёт ансибла категорически не согласен. Да, возможно, что для "чистого" разработчика его его функциональность избыточна, но с той же стороны — кто мешает его товарищу, который больше шарит в ОПС части, настроить основное и показать, куда нужно вносить изменения в случае чего?
                Да и "чисто" разработчики сейчас не в цене, а T-shaped персоны, которые имеют широкий кругозор, но и узкую специализацию

                • qrKot
                  /#20036126

                  Насчёт ансибла категорически не согласен. Да, возможно, что для «чистого» разработчика его его функциональность избыточна


                  Не «возможно», а «совершенно точно»)

                  кто мешает его товарищу, который больше шарит в ОПС части, настроить основное и показать, куда нужно вносить изменения в случае чего?


                  Вижу 3 проблемы:
                  1. Надо сначала найти товарища, который «настроит основное и покажет». Это либо «повезло», либо это дополнительные финансовые траты.
                  2. Если вам «настроят основное», понимания процесса у вас не появится. Дальнейшие правки все равно неизбежны, т.е., опять же, придется либо изучать, либо крепко дружить с человеком, который «умеет» (на какой итерации «слушай, тут поправить надо чуть-чуть, посмотри, пожалуйста» ваша дружба закончится), либо платить.
                  3. Мы добавляем в проект совершенно избыточный, достаточно «комбайнерский» стек, с достаточно высоким порогом вхождения. И это при том, что на выходе мы все равно должны отдать собранный контейнер? И для этого есть инструменты сильно проще, а местами и тупо набором bash-скриптов обойтись можно…

                  Короче, ваш подход, он, возможно, оправдан, но исключительно в одном достаточно редком кейсе: относительно крупная разработческая контора, достаточно крупная для содержания пары ops-спецов, а лучше полноценного отдела эксплуатации. И вот если «эксплуатация» есть, и она вплотную использует ansible в своих задачах (т.е. есть действительно спецы в технологии) — тогда есть смысл «поделиться» с «разработкой» наработанными практиками.

                  В случае же, если сидят 3 программиста, один из которых считается «шарящим» в ансибле потому, что он доку 2 раза читал, а остальные только слышали название. Не, нет пути.

                  Да и «чисто» разработчики сейчас не в цене, а T-shaped персоны, которые имеют широкий кругозор, но и узкую специализацию


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

                  • gecube
                    /#20036206

                    И да, и нет. Вы ещё скажите, что разработчики вагрант не должны знать :-) Между прочим, очень крутая штука, которая экономит кучу времени на разработку и отладку.

                    Вообще проблема в том, что если разработчик будет знать только как кодить, то он не нужен. Ну, напишет он что-то, а оно нагрузочные тесты не пройдет (еще вопрос имеются ли они в проекте). И что? Кто будет исправлять? «DevOps»? Тестировщики? Представьте сколько человеческих ресурсов уйдет вхолостую. А если бы у него был чуточку более широкий горизонт знаний, то проблема может быть и не возникла.

                    И, да, собирать образы ансиблом — такое себе удовольствие. Запускать — да, почему нет, если действительно в проекте что-то сложнее «docker run» с фиксированными аргументами.

                    • qrKot
                      /#20036296

                      Вы ещё скажите, что разработчики вагрант не должны знать :-)


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

                      И, да, собирать образы ансиблом — такое себе удовольствие.


                      Совершенно верно. Очень такое себе.

                      Запускать — да, почему нет, если действительно в проекте что-то сложнее «docker run» с фиксированными аргументами.


                      Но для «запускать» есть более простые инструменты… Т.е. я о чем: если у вас в инфраструктуре ансибл задействован в миллионе мест — можно им еще и контейнеры попинать. Ничего предосудительного, у вас есть экспертиза в инструменте, его использовать логично, да и тянуть лишнюю технологию внутрь — зачем, если у вас уже есть то, что работает. Но вот идея притащить в проект ansible тупо с целью пинать контейнеры… Ну, я не знаю, Г-дь вам, видимо, судья.

                      • gecube
                        /#20036318

                        Но вот идея притащить в проект ansible тупо с целью пинать контейнеры… Ну, я не знаю, Г-дь вам, видимо, судья.

                        Ну, вот идея притащить docker-compose, который вроде бы должен быть комбайном, умеющим все (сборка-запуск и пр.), но фактически сделан «как попало» — такое себе решение. И еще вопрос что хуже: docker-compose или ansible. Оба багованные.
                        Например, у меня было три кейса, которые с docker-compose не решаются в принципе:
                        1. шаблонизация docker-compose. Запуск разного количества контейнеров с разными параметрами в зависимости от… Решается наворачиванием jinja2 поверх. Либо можно сразу ansible (или любое другое)
                        2. шаблонизация docker-compose более сложная, чем просто подстановка переменных из ENV в нескольких местах. Опять же проще взять нормальный шаблонизатор типа jinja2, чем пытаться научить docker-compose чему-то новому. Можно там изворачиваться с override, extends, yaml anchor, но когнитивная сложность от этого не уменьшается.
                        3. запуск сервисов в определенном порядке. В рамках docker-compose можно костыльно решить через хелсчеки (ага, только во второй версии формата, т.к. только там есть depends_on: service_healthy). Либо docker-compose для описание списка сервисов и внешняя запускалка (bash? make?)

                        Как видите, все равно получается, что docker-compose не подходит как единственный инструмент, что сразу ставит вопрос, а зачем он нужен вообще.
                        Для чего он хорош — БЫСТРО и грязно запустить контейнер на машине разработчика.

                        • qrKot
                          /#20037034

                          Ну, вот идея притащить docker-compose, который вроде бы должен быть комбайном, умеющим все (сборка-запуск и пр.)


                          Это вы откуда взяли? В официально доке написано «Compose is a tool for defining and running multi-container Docker applications.» Переводим: «Тулза для определения(описания) и запуска мультиконтейнерных докер-приложений».

                          Описывает? Описывает. Запускает? Запускает. Выполняет фантазии пользователей — нет. Но он и не обещал.

                          шаблонизация docker-compose


                          Ну, видимо, не с той стороны зашли. Это примерно как шаблонизация json или xml. Тоже заранее утопичная идея. Распарсили в дерево, проставили нужные значения, сериализовали взад. А щаблонизировать не нужно, неудобно и больно.

                          шаблонизация docker-compose более сложная, чем просто подстановка переменных из ENV в нескольких местах


                          Вы это, видимо, еще и shell'ом делали. Гамак… Стоя… На лыжах…

                          запуск сервисов в определенном порядке. В рамках docker-compose можно костыльно решить через хелсчеки (ага, только во второй версии формата, т.к. только там есть depends_on: service_healthy). Либо docker-compose для описание списка сервисов и внешняя запускалка (bash? make?)


                          Официально так.

                          Как видите, все равно получается, что docker-compose не подходит как единственный инструмент, что сразу ставит вопрос, а зачем он нужен вообще.


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

                          Для чего он хорош — БЫСТРО и грязно запустить контейнер на машине разработчика.


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

                          • gecube
                            /#20037872

                            Это вы откуда взяли? В официально доке написано «Compose is a tool for defining and running multi-container Docker applications.» Переводим: «Тулза для определения(описания) и запуска мультиконтейнерных докер-приложений».

                            разработчик продукта может писать что угодно. Например, что небо зеленое, а солнце черное. Только это к реальности отношения не имеет.
                            Ну, видимо, не с той стороны зашли. Это примерно как шаблонизация json или xml. Тоже заранее утопичная идея. Распарсили в дерево, проставили нужные значения, сериализовали взад. А щаблонизировать не нужно, неудобно и больно.

                            ну, почему нет? Что в этом плохого, что такая проблема встает снова и снова? Причем даже в рамках того, что предлагает docker-compose (запуск приложения, состоящего из связанного набора контейнеров).
                            Официально так.

                            это очередной костыль. Официально. Шикарно.
                            Воот, оно (плюс еще функция документирования запуска. Нормальный опс его прочитает и напишет вменяемый деплой. Не описание от разработчика в произвольной форме, а файл со спекой). А на сервер его тянуть не надо. Для оркестрации более другие методы есть.

                            Разрабы очень хотят видеть docker-compose на пре-продовых окружениях. А в идеале — и на проде (им же туда иногда нужно будет ходить, чтобы чинить баги).

                            Еще раз — думайте, что хотите. Понятно, почему так получилось — докер-компоуз пихался вперед самой Docker, Inc как способ описания контейнеров для сворма. Сворм не взлетел. Инвестировать в разработку обоих продкутов никто не будет. The End.

                            • qrKot
                              /#20038146

                              разработчик продукта может писать что угодно. Например, что небо зеленое, а солнце черное. Только это к реальности отношения не имеет.


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

                              ну, почему нет? Что в этом плохого, что такая проблема встает снова и снова? Причем даже в рамках того, что предлагает docker-compose (запуск приложения, состоящего из связанного набора контейнеров).


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

                              Тупо на вход даете путь до значения, которое нужно заменить и нужное значение. Типа python templates-are-not-needed.py services.redis.image myAwesomeImage:3.0 — заменяет image в сервисе redis на новый. Чего не хватает? Проблему, блин, выдумали, и героически от нее страдаем.

                              это очередной костыль. Официально. Шикарно.


                              Ну, если внимательно прочитать, для чего docker-compose предназначен, то все норм. А, точно! Вы же лучше знаете, что docker-compose — полноценный оркестратор (на самом деле — нет).

                              Разрабы очень хотят видеть docker-compose на пре-продовых окружениях. А в идеале — и на проде (им же туда иногда нужно будет ходить, чтобы чинить баги).


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

                              • gecube
                                /#20038518

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

                                Отлично — вместо того, чтобы втащить в проект очередную зависимость типа j2cli (замечу — еще и качественную и отлаженную), Вы изобрели очередной велосипед. Браво!
                                А, точно! Вы же лучше знаете, что docker-compose — полноценный оркестратор (на самом деле — нет).

                                Не приписывайте мне не мои слова. Но, между прочим, да — docker-compose делался именно как способ декларативного описания контейнеров под swarm. Ах, да, так другого-то и нет!
                                Я вот типа разраб. Я НЕ хочу видеть docker-compose не то на проде, но и близко на препродовом окружении.

                                я тоже. Но это блокируется тем, что разрабы не хотят учить кубер и писать сразу нормальные манифесты. Да и кубик запустить локально не то, что сложно (в крайнем случае есть minikube и готовые образы вагранта), а скорее муторно и ресурсов есть поболе, чем просто запустить докер-контейнер.
                                Ужасная проблема! Прямо неразрешимая!

                                Тон свой сбавьте? Ваша ирония или сарказм и передергивания тут неуместны.

                                • qrKot
                                  /#20039798

                                  Отлично — вместо того, чтобы втащить в проект очередную зависимость типа j2cli (замечу — еще и качественную и отлаженную), Вы изобрели очередной велосипед. Браво!


                                  Т.е. я правильно понимаю, что:
                                  1. Вы жалуетесь, что вам не хватает шаблонизации в docker-compose конфигах.
                                  2. Вы пытаетесь решить проблему генерации yaml (который, согласно официальной доке, is a human-readable data serialization language, т.е. человекочитаемый язык сериализации данных) шаблонами, у вас не выходит и вы сетуете на судьбу.
                                  3. Вы серьезно уверены, что генерация «языка сериализации данных» из шаблона — хороший подход.
                                  4. Вы считаете, что jinja каким-то образом решает проблему.
                                  5. Извращенец здесь я.

                                  Я все верно понял? Вместо того, чтобы работать с набором «словарей» как с данными (которыми они и являются), вы предпочитаете собрать текстовый шаблон (видимо, исходя из фразы «INI, YAML, JSON data sources supported» в доке. Точнее из знакомых букв YAML во фразе, игнорируя «data sources») и притащить шаблонизатор вместо инструмента управления данными в проект как совершенно необходимую зависимость — вот это то, чего не хватает docker-compose'у.

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

                                  Не приписывайте мне не мои слова. Но, между прочим, да — docker-compose делался именно как способ декларативного описания контейнеров под swarm. Ах, да, так другого-то и нет!


                                  Я приписываю вам ровно ваши слова. «разработчик продукта может писать что угодно. Например, что небо зеленое, а солнце черное. Только это к реальности отношения не имеет.» — это ваше. Осталось только увидеть реальность, в которой docker-compose — полноценный инструмент оркестрации, которым вы его себе представляете, а не та запускалка, о которой говорится в официальной документации.

                                  То, «как оно изначально задумывалось» — действительно не имеет общего с реальностью. Потому что изначальной задумке инструмент не соответствовал никогда, ни в единый момент времени. Наполеоновские планы разработчиков и расчет Docker.Inc на «взлет» Swarm — это хорошо, конечно, и никто не отрицает, что планы такие, очень вероятно, были. Но именно это отлично подходит под определение «влажные фантазии». Реальность, на которую вы так упираете говорит другое. В нашей существующей реальности в официальной доке написано, что компоуз — запускалка сгруппированных контейнеров по декларативному описанию. И ни одна из умелок компоуза этому не противоречит.

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


                                  Едрить, ну наконец-то! Область применения определена. Разраб, может быть, и написал бы манифест, но геморрой от развертывания локального кубера — это, если честно, совсем не то, чем стоит заниматься оплачиваемому разработчику. Есть более логичное применение его «талантам», и более эффективное с точки зрения КПД.

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

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

                                  Можно бесконечно обсуждать, чего на самом деле Docker.Inc хотелась добиться своим инструментом в идеале, но реальность (набор реально существующих и подтвержденных практикой обстоятельств) говорит нам, что compose — туповатая тулза, решающая ровно одну проблему. «Грязный запуск набора связанных контейнеров в дебажных целях» — единственная цель этого интрумента. Но именно в этой области применения ему равных-то и нет.

                                  Вы мне, конечно, сейчас расскажете про идеального разработчика, который и в «кубер на атоме с гектаром оперативки развернуть» умеет. Практика же показывает, что в командах разработчиков от 3 голов и выше то, как это выглядит на проде, может интересовать примерно не более одного. Остальным нужна просто «запускалка». И это не делает их плохими разработчиками — вообще нет. Они могут писать охрененнейший оптимизированный идиоматичный код, и именно за это им платят. Просто в «девопсе» всегда кто-то больше «дев», а кто-то тяготеет в сторону «опса».

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

                                  Отсюда и docker-compose. Это инструмент для разраба. Он позволяет тупо запустить и потрогать без необходимости звать квалифицированного «эксплуататора». И здесь его область применения заканчивается — не надо его в прод тянуть. Но ничего лучше в этой нише нет — не надо тащить к разрабу на машину k8s, не нужен он там.

            • qrKot
              /#20035048 / +1

              Вопрос: Зачем изучать docker-compose если есть инструмент с более широким применением?


              Зачем пользоваться молотком, когда есть такой замечательный кухонный комбайн?

              Далее, какие есть варианты запуска контейнера на удаленной машине? (вангую сейчас скажете про docker swarm и его поддержку docker compose формата)


              Да миллион их. И вы ошиблись, ни docker swarm, ни docker-compose на проде я рекомендовать не буду. А оркестраторов — как конь… кхм… напривозил. Самое суровое решение — k8s. Самое простое — баш-скрипт по git-hook'у. Между ними — миллиард вариантов, выбирайте на вкус.

              Когда то нравился compose, но сейчас нет, потому что это оверхед над docker api.


              Вы путаете понятия «оверхед» и «враппер».

              Натыкались на такие issue? github.com/docker/compose/issues/3574


              И? Собственно, в простейшем варианте разработчики совершенно верно указали, что docker-compose pull && docker-compose up дает ровно тот же желаемый эффект. В варианте pull-policy внутри конфига, с конкуррентной докачкой и прочими прелестями это «с кондачка» не делается, о чем они тоже сообщили и известили всех, что «думаем, как это правильно реализовать». Достаточно разумно, собственно. В 4-й параллельной версии конфига никто не заинтересован. Что не так?

              Мне нравится декларативное описание в yaml. Он намного лучше json


              Чем, простите, оно лучше json?

              Впн я давно использовал в компаниях где были админы и настраивали его сами. Про ssh туннели я не знал, да, но как то пользовался пробросом портов в `kubectl`, думал это специфичная штука кубера


              Ну, т.е., с документацией и изучением полезных инструментов — это у вас не с docker-compose началось? Давняя проблема?)

      • Maximuzzz
        /#20034566 / +1

        Ну а зачем вы пишите статьи вида докер не нужен, если у вас:
        А) нет адекватного и достаточно опыта его использования
        Б) у вас нет достаточного уровня понимания и экспертизы для оценки инструмента
        В) вы не собираетесь тратить время на развитие и изучение инструмента, но используете его под прослойкой из ансибля


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

  18. inf
    /#20030670

    docker-compose есть лишь конфигурация `docker run` в yml формате. Странная неприязнь.

    • gecube
      /#20031674

      не только. docker build, docker create network и куча его всего.
      Самый эпик, что в докере действительно есть проблемы и странности, но с ними можно жить и как-то с ними бороться. docker-compose поверх этого навешивает еще свои проблемы и странности. Например, первая — наличие двух ограниченно совместимых параллельно развивающихся форматов 2.* и 3.*
      Я уж не говорю про особенности с выделением сетей (ага, в компании, у которой вся сеть на 172.12.0.0/16) и вольюмов…

    • niya3
      /#20035336 / +1

      Не совсем так. Это отдельная тулза со своими особенностями. И если ты делаешь build через compose, то будь готов к подвохам. Например, DOCKER_BUILDKIT пока не поддерживается https://github.com/docker/compose/issues/6440

  19. inf
    /#20030692 / +2

    Главная мощь докера видна в ci/cd пайплайнах. Документацию всё-равно никто никогда не пишет. А наличие Dockerfile в проекте обеспечивает доки и работающую конфигурацию. Плюс не надо искать и пытать разработчиков вопросами — «а что там установить чтобы оно заработало?»))

    • Merkat0r
      /#20033244 / +1

      Ох… какже я ненавижу энтерпрайз…
      Но вот в

      такие
      «а что там установить чтобы оно заработало?»

  20. iproger
    /#20030816 / -3

    Пока не решат дохлые томы в докере ничего не будет. В винде производительность садится на порядок.
    Пример: symfony 4. Базовая страничка без ничего отдается через пол секунды. Клево, че. Это на 9900k и nvme 970 pro. Хуже обстоит дело если винда home и нет гипервизора. В этом случае страница отдается после 700+ мс.
    Пример 2: magento 2. В среднем загрузка обычной страницы занимает до 8 секунд. Со всеми кэшами может сократиться до 3-4. А если поставить какой-нибудь i5 и hdd, то что, на обед ходить после f5?

    Многие не выдерживают и переходят на линукс. Я посидел на Убунте пару лет и тоже не выдержал — вернулся на винду. ОС с по-настоящему быстрым интерфейсом без единого глюка, лага. ОС где 2080 через 5 минут может отображать 165гц на мониторе, а не после двухчасовой возни в конфигах и последующем переходе на хромиум (в хроме нет поддержки высокогерцовых мониторов) и довольствованием 80fps.
    Линукс я люблю, но, как и родину, его лучше любить издалека. Решил вопрос покупкой интел нака и созданием локальной сети между пк и ним. Помимо некоторых проблем с сетью, получил желаемый интерфейс винды и отличный сервер.
    Таков мой опыт.

    • balsoft
      /#20031074

      довольствованием 80fps.

      Какой ужас, всего 80fps! Глаза болят, ага.


      Серьезно, ну посидел я у коллеги за настроенным 160Hz монитором. Никакой особой разницы не заметил. Разве что нагрузка на процессор и видеокарту у него побольше. Плавность интерфейса тоже особым преимуществом не назовешь — то, что у меня в настроенном и вылизанном линупсе происходит мгновенно, на винде может занимать 100-300мс из-за плавности и анимаций. Зачем мне это нужно?


      Возможно, это всё привычка и в винде есть какие-то непонятные мне прелести. Но в 2019 году можно и потерпеть ужасно неплавный интерфейс и 80fps ради ОС, которая вся целиком представляет из себя удобную и настраиваемую IDE.

      • iproger
        /#20031254 / -1

        Вы не заметили особой разницы, значит ее нет.
        На винде на нормальной машине все происходит моментально кроме некоторых заведомо кривых областей. Более того, на десятке даже на слабых пк (3ггц+) все будет работать не медленнее чем на xp, например. Я это тестировал на слабых мини-пк и не предполагаю о 100-300мс, а утверждаю.
        Допускаю что в 2019 есть крутые и красивые дистрибутивы, но самый популярный из них — Убунта — так и не стала такой. Особенно gnome 3. Надолго запомнил невозможность перехода из контекстного меню, проблемы с панелью задач и сложную ситуацию со шрифтами. Видимо, не смог, да.

        • balsoft
          /#20035410

          Вы не заметили особой разницы, значит ее нет.

          Нигде не утверждал, что её нет.


          Я это тестировал на слабых мини-пк и не предполагаю о 100-300мс, а утверждаю.

          Я это (windows 10) тестировал на своём рабоче-походном ноутбуке с i3-6600U и встройкой и тоже не предполагаю, а утверждаю. Пуск открывается около секунды, PS запускается даже дольше секунды, Firefox открывается около 4-5 секунд. У меня в Linux на том же ноуте: лаунчер (замена пуску) — меньше 100ms; терминал (с zsh, который ещё и удобнее PS) — меньше 100ms; firefox — две секунды.


          Убунта — так и не стала такой

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

    • qrKot
      /#20031562

      В винде производительность садится на порядок.


      Это логично. Docker — достаточно эффективная абстракция над lxc (Linux Containers), которые, в свою очередь, обеспечивают изоляцию штатными механизмами ядра (namespaces + cgroups). Странно было бы, если бы оно завелось под Windows с той же производительностью…

      • usego
        /#20031594

        Дык в 2019ой винде оно тоже на уровне ядра работает. Под трафиком докера ещё не тестил, но они заводятся, ASP.NET апликухи.

        • qrKot
          /#20031742

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

          Конечно, могу в чем-то ошибаться, никогда не рассматривал всерьез windows как платформу для контейнеризации, и мог какие-то новости пропустить. Но если оно «свежее», видимо, для прода пока еще не готово.

      • gecube
        /#20031656

        Docker — достаточно эффективная абстракция над lxc (Linux Containers)

        не надо это повторять. Это какая-то глупость, которая кочует из комментария в комментарий. docker — он работает параллельно с lxc/lxd, а не поверх него.

        • qrKot
          /#20031726

          Окей, уговорил, с 2015-го перешли на libcontainer. Спасибо, что поправили, у меня была сильно устаревшая информация.

          Однако базовые «ядерные» вещи на месте, все те же cgroups, namespaces.

          • niya3
            /#20035344

            с 2015-го перешли на libcontaine

            в 2014 в версии 0.9, если быть точным.

    • Brain_Overload
      /#20032070 / +1

      ОС с по-настоящему быстрым интерфейсом без единого глюка, лага

      от души посмеялся, спасибо)

  21. 411
    /#20031034

    Используйте docker только на самом последнем этапе в вашем рабочем процессе

    Так и представил:
    — Пацаны, через неделю выходим в прод, давайте наконец прикрутим докер

    • kondaurovDev
      /#20031156

      Любое приложение можно завернуть в docker образ за 5 минут.

      • gecube
        /#20031648

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

        • kondaurovDev
          /#20032868

          А я и не говорил что оно работать будет, а сказал что будет упаковано в docker образ.
          Очевидно что нужно подготавливать образ чтобы заработало

          FROM alpine
          
          RUN wget -O my-project http://ci-cerver/master/my-project.tgz
          
          ENTRYPOINT ["app"]
          

  22. horrrs
    /#20031146

    Мужики, ну растолкуйте за докер и все это, уж очень интересна тема Ci/cd пайплайнов и тд, но пока что не могу даже устаканить мысли о докере.
    Вот как я понимаю контейнеры умирают вместе с данными, (да я читал что там можно подключить разными способами что-то перстстентное, не об этом)
    Теоретически я заворачиваю свой фротенд в контейнер, бекенд в контейнер, что мне делать с базой? Мне же страшно, чтобы там не умерли мои данные.
    Поясните плз :)

    • microcoder
      /#20031232

      Можно вместо Docker использовать LXC, и данные «не умрут».

    • qrKot
      /#20031582

      Вот как я понимаю контейнеры умирают вместе с данными, (да я читал что там можно подключить разными способами что-то перстстентное, не об этом)


      Именно об этом. Если вам нужно что-то персистентное, то и подключается оно как что-то персистентное. Т.е. база либо а) в стороне на отдельном сервере, либо б) в контейнере с подмонтированным персистентным var'ом.

      • horrrs
        /#20032128

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

        • CrzyDocTI
          /#20032220

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

          • teamfighter
            /#20032898

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

            • CrzyDocTI
              /#20032936

              На мой взгляд это имеет смысл только в Swarm. Сам по себе контейнер докера — ничем не отличим от других. Вы бы к примеру стали LXC каждый раз гонять?

              • teamfighter
                /#20032950

                Ну необязательно swarm. Любой другой оркестратор, будь то кубик или амазоновский ECS. Докер без оркестрации вещь в себе на самом деле.

                • CrzyDocTI
                  /#20032990

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

                  на хосте уже крутится контейнер

                  как рациональнее всего осуществлять деплой? Работаю пока что в маленьких проектах

                  Вы все правильно заметили — предложенный вариант не best practice.

        • qrKot
          /#20032706

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


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

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


          Простой и быстрый способ — написать другие shell-скрипты, которые быстро по ssh все сделают)

          Каждый раз менять имейдж на локально, дальше из него билдить каждый раз новый контейнер на хосте?


          А «по науке» — смотреть на практики CI/CD. Обычно выглядит так:
          1. Вы делаете локальные изменения кода.
          2. Суете эти изменения в общий репозиторий.
          3. При пуше в репозиторий отрабатывают гит-хуки, например, которые запускают специальный контейнер, в котором ваше приложение собирается.
          4. Полученное приложение прогоняется по тестам.
          5. Если тесты прошли, полученная сборка деплоится на сервер. В процессе деплоя, чаще всего, новая версия запускается параллельно существующей. Если новая версия стартанула (тут возможны какие-то health-чеки), старая гасится.

          Но это «по науке», внедрять можно поэтапно.

  23. karavan_750
    /#20031278

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

  24. ttys
    /#20031504

    >> Docker в CI
    Судя по всему аффтор не стал даже читать как всё это работает.
    Ну и если человеку «проще» поставить весь набор пакетов на сборочную ноду, чем поставить один докер и запускать для каждой сборки свой контейнер — то можно сделать вывод о масштабах проектов.

    ЗЫ: Для явы возможно и нет смысла использовать докер т.к. код будет работать в ява контейнере который будет в докер контейнере который будет в опенстек ВМке в доме который построил Джек.

    ЗЗЫ: ансибл ещё то чудо, в котором после каждого релиза что то деприкейтят, и в через релиз уже старые роли нифига не работают.

    • AlexeySoshin
      /#20037282

      Да даже для JVM приложений Docker полезен. Не факт, что где-то будет установлен Maven/Gradle и правильная версия JDK.

  25. kudlayid
    /#20031640

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

    • qrKot
      /#20031774

      Docker нужен для запуска микросервисов в оркестраторе.


      Не, не нужен. k8s, например, отлично обходится без него. Еще можете здесь посмотреть — тоже докера нет.

    • usego
      /#20031790 / +1

      docker — это
      1) средство упаковки и доставки софта и его окружения (последнее ключевое)
      2) перенос многих вопросов, главным образом вопрос подготовки зависимостей на сторону разработчика, который лучше знает, что его софту нужно, тем самым КАРДИНАЛЬНО упрощая жизнь опсов
      3) относительно единая среда запуска везде
      4) документация среды в виде кода
      5) относительная чистота среды исполнения

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

      • kudlayid
        /#20040562

        По пунктам 1,2,3 подходят rpm/deb + systemd, которые, в отличии от docker, не добавляют целой пачки сущностей и не усложняют систему.

        > 4) документация среды в виде кода
        Dockerfile не самая удобочитаемая вещь в мире, тогда сюда же вполне ложится лобой configuration management tool или spec file.

        > 5) относительная чистота среды исполнения
        Точно так же зависит от приложения, если оно у вас stateless, то среда для него всегда будет чистая, независимо от того, что вокруг него, а если вы запускаете в докере на проде statefull workload, вероятно монтируя его volume'ми — вы значительно усложняете себе жизнь.

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

        • adictive_max
          /#20040794

          То есть вы реально считаете, что «rpm/deb + systemd» — это проще, чем Docker?
          В том числе на Windows или Mac?

          • kudlayid
            /#20045428

            Сложность системы определяется количеством элементов в ней и количеством связей между ними.
            Systemd и пакетный менеджер есть практически на любой системе, мы не вводим нового элемента.
            Для локалхоста разработчиков, если им нужны dev стенды на локалхостах (что обычно не так), есть vagrant.


            Поэтому да, rpm/deb + systemd — проще чем Docker.

            • qrKot
              /#20046904

              Systemd и пакетный менеджер есть практически на любой системе


              В контексте предыдущего вопроса «В том числе на Windows или Mac?» смотрится, как минимум, сверхоптимистично.

              При этом разработчик может пользоваться той же ubuntu, а на прод оно может уйти в RHEL-инстанс… Ну, скажу я вам, такое себе, эти ваши гетерогенные среды.

              Поэтому да, rpm/deb + systemd — проще чем Docker.


              Поэтому вот нифига.

              • kudlayid
                /#20053074

                Для локалхоста разработчиков, если им нужны dev стенды на локалхостах (что обычно не так), есть vagrant.

        • gecube
          /#20041172 / +1

          не могу согласиться от слова совсем.
          systemd — действительно великая вещь, но реально зачастую возможны проблемы, когда в системе стоит библиотека версии А, а программе нужна Б, причем обе не могут быть установлены одновременно. Сюда же — нормальный менеджмент пакетов у многих экосистем (например, python) отсутствует от слова совсем. Можно извращаться с chroot'ом и еще как-то — но зачем, если есть контейнеризация?

          Про упрощение жизни опсов также не соглашусь, docker усложняет любой траблшутинг, всегда. Для большинства опсов docker является новой сущностью.

          есть такой момент, да. Но это характерно для любой современной системы, которая является совокупностью слоев абстракции. Чего уж тогда от виртуализации не отказаться и гонять все на баре-метал? Слоев абстракции меньше — траблшутинг проще (*** не всегда )
          Dockerfile не самая удобочитаемая вещь в мире, тогда сюда же вполне ложится лобой configuration management tool или spec file.

          нормально он читается. Уж всяко лучше, чем переусложненный ruby DSL паппет-манифест или шеф-кукбук.

          • kudlayid
            /#20045402

            зачастую возможны проблемы, когда в системе стоит библиотека версии А, а программе нужна Б, причем обе не могут быть установлены

            Статическая линковка для c/cpp? fat jar для java?
            Или вы инфраструктурную обвязку в docker крутите? Этот вариант настолько же прекрасен в рамках процессов тестирования/разработки насколько плох в рамках процессов эксплуатации.
            И если вы хотите, чтобы хорошо было всем, вам придется поддерживать 2 разных механизма развертывания.


            | Сюда же — нормальный менеджмент пакетов у многих экосистем (например, python) отсутствует от слова совсем.


            pip + requirements.txt, vitrualenv? не знаю чем вам менеджмент пакетов python не угодил.


            есть такой момент, да. Но это характерно для любой современной системы, которая является совокупностью слоев абстракции. Чего уж тогда от виртуализации не отказаться и гонять все на баре-метал? Слоев абстракции меньше — траблшутинг проще (*** не всегда )

            Принцип бритвы Оккама. Любая техническая задача, это задача математической оптимизации — минимизируем временные расходы, при заданных ограничениях.
            У docker, как у любого инструмента есть свои применения (запуск stateless микросервисов в оркестраторе).
            Я не буду спорить, можно и отверткой гвозди забивать при наличии энтузиазма, главное при этом иметь вид достаточно лихой, чтобы потом не спросили за потраченное время и выбитые выскользнувшей отверткой окна.


            нормально он читается. Уж всяко лучше, чем переусложненный ruby DSL паппет-манифест или шеф-кукбук.

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

            • gecube
              /#20046228

              pip + requirements.txt, vitrualenv? не знаю чем вам менеджмент пакетов python не угодил.

              Потому что это не решение. Вы внутрь python-пакетов вообще заглядывали? А ничего,, то они часто за пределы экосистемы python выходят и начинают в систему тащить всякую всячь. И, да, многие pip-пакеты без компилятора gcc вообще не поставить в принципе. Ни о чем не говорит?


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

              Несомненно. Но, во-первых, у Dockerfile другая задача, чем у шеф-кукбука. И Вы сами про это знаете. И, во-вторых, никто не мешает конфигурировать содержимое Docker-образа через chef (так, например, Флант делает)

            • qrKot
              /#20047298

              Статическая линковка для c/cpp? fat jar для java?


              Ну, т.е. systemd + rpm/apt таки эту задачу не решают, от слова «совсем». Предложенный же вами вариант — ну, как бы, тоже trade-off. Вы «выкидываете» из цепочки пересборку докер-образов при обновлении базового слоя с зависимостями (например, при фиксах уязвимостей базовых библиотек). Что взамен? Очевидно, пересборка fat jar'ов, c/cpp проектов и т.д. «То на то» и выходит, конечно, с единственным нюансом: пересборка с зависимостями — отдельный инструментарий для каждого языка, пересборка докер-образов универсальна.

              pip + requirements.txt, vitrualenv? не знаю чем вам менеджмент пакетов python не угодил.


              Ну, тут три слабых места:
              1. Он сам по себе сильно не идеален, и может попросить (как указал уже ваш собеседник в другом комментарии) еще и gcc с собой принести, а то и что-то дополнительно в систему вкорячить.
              2. Он приемлемо решает вопрос доставки языковых зависимостей, но никак не решает вопрос их конфигурации и вопрос доставки инфраструктурных зависимостей.
              3. Он не универсален.

              Конкретно по 3 пункту. Вот есть у вас проект. На python, с venv и «всем вот этим». Дописали, стартанули новый. А он на js! Опачки, ваши «инженеры-эксплуатационщики» изучают npm, yarn, whatever. И тут приходит новая вещь: java-приложуха. И тот же самый бедолага инженер по тихой грусти изучает maven, gradle с задачей «автоматизируй это».

              Имхо, достаточно логично, что разработчик «в стеке» свои инструменты знает. Эксплуатационщик же может (имеет полное право) не знать «языковых экосистемных тонкостей». Его задача — инстансы гонять. Просто потом этот же товарищ, вконец «уставший» от изучения концепций третьего языка программирования, на котором он никогда не будет писать, пойдет на другую работу. А там… Там, предположим, Ruby… Кхм.

              Причина популярности всей этой возни с контейнеризацией, имхо, именно в том, что процесс эксплуатации проекта становится не зависим от стека, на котором проект разрабатывался. Т.е. мы имеем, условно, «lingua franca» — некоторый описательный язык, примерно понятный как разработчикам, так и «эксплуататорам».

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

              минимизируем временные расходы, при заданных ограничениях.


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

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

              Поэтому и пользуются, поэтому и популярно. Где-то неизбежно получаются «просадки качества управления», но именно в том и подход, что решать вручную надо именно те места, где «просадка» случилась, а не все подряд. Все подряд руками оптимизировать — это тупо дорого.

              • kudlayid
                /#20053174 / +1

                пересборка докер-образов универсальна.

                За иллюзию контроля платят дороже, чем за осознание ограничений своих инструментов на текущий момент времени.


                три слабых места pip + venv

                Производим артефакт с venv на этапе сборки, gcc остается только на сборочном агенте.
                Для доставки есть другие инструменты.
                Или вы считаете голый docker полноценным инструментом доставки?
                Расскажите, как вы голым докером, без обвязки и оркестрации произведете бесшовное обновление.


                «инженеры-эксплуатационщики» изучают npm,

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


                бедолага инженер по тихой грусти изучает maven, gradle

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


                процесс эксплуатации проекта становится не зависим от стека

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


                зачем все-то руками рулить?

                Разве я где-то писал про руление руками? Помимо docker есть масса инструментов, которыми вы кстати будете рулить и docker'ом, пока не поймете тленность его использования без оркестрации, но тут нужно учиться на своих ошибках и запороть пару проектов.


                «контейнер» — это концепция, понятная обоим сторонам процесса.

                systemctl start servicename
                systemctl stop servicename
                обе стороны процесса только что научились пользоваться systemd, сложнее чем docker?


                «не забудь, вот в этом месте должен лежать файлик вот с таким содержимым»

                Простите, а зачем?

              • kudlayid
                /#20053236 / +1

                Его задача — инстансы гонять. Просто потом этот же товарищ, вконец «уставший» от изучения концепций третьего языка программирования, на котором он никогда не будет писать, пойдет на другую работу. А там… Там, предположим, Ruby… Кхм.

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


                Вы уж простите за сарказм, не сдержался.

    • AlexeySoshin
      /#20037302 / +1

      «Х нужно только тогда, когда нужно, и никогда больше»

      У нас был монолит на Ruby on Rails, 150K строк кода, который не только лишь все могли у себя запустить. Потому что кто-то проапдейтил OSX, и вот уже какой-то Ruby Gem засивящий от C++ кода слетел. Docker все эти проблемы тоже отлично решил.

      • kudlayid
        /#20040572

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

        • AlexeySoshin
          /#20043306

          Всегда считал, что лучше скадывать вещи в шкаф Docker, чем раскидывать их по разным стульям Ansible/Chef/Puppet.

          • gecube
            /#20043462

            Salt еще забыли ) И да — докер не решает вопрос доставки образов на целевую машину (не бегать же по 100500+ серверов и руками засосывать туда docker-compose.yml и делать pull/up ?)

            • AlexeySoshin
              /#20043528

              Не решает, конечно. Потому меня статья на тему «Ansible лучше чем Docker» так и смутила.

  26. serf
    /#20031870

    запуск nginx для раздачи frontend и проксирования на backend
    Изолированный nginx можно запускать проще:
    wasmer run nginx.wasm -- -p . -c nginx.conf
    github.com/wasmerio/wasmer/tree/c8a71263db01365798ab5c05631ddc52a0b57198/examples/nginx

    Там же есть примеры php, sqlite, lua и тд github.com/wasmerio/wasmer/tree/c8a71263db01365798ab5c05631ddc52a0b57198/examples

    Вот еще в тему twitter.com/solomonstre/status/1111004913222324225

  27. nightvich
    /#20031996

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

  28. sergeyns
    /#20032272 / -1

    Хе, у меня докер на проде только в одном продукте от IBM, но уже надоело писать заявки ИБ чтобы открыли доступ в инет с боевого сервера «ко всему», иначе этот чертов докер не ставится-не обновляется, ибо до фига зависимостей и все эти бубны скачать с одной машины-сохранить-перенести вообще не реально сделать… Может быть с точки зрения разработчика удобно, но когда доходит до продакшина…

    • DMGarikk
      /#20032384 / +2

      но уже надоело писать заявки ИБ чтобы открыли доступ в инет с боевого сервера «ко всему»

      кхм, не в обиду, но вас нельзя допускать до сисадминства

    • Singaporian
      /#20032526

      Что вы там ставите? Что обновляете? Что с машины на машину переносите?

      Худший вариант: поставить его на yum/apt — это доступ в интернет на один узел, учитывая, что у докера есть свои репо под оба этих пакетных менеджера.
      Лучший вариант: стартануть CoreOS с игнишена (вообще в 2019-м пакеты и их зависимости в ОС звучат как дичь).

      Так зачем вам «доступ в инет с боевого сервера «ко всему»»

    • nightvich
      /#20033820 / +1

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

  29. Singaporian
    /#20032466 / +2

    для того чтобы мое приложение работало, нужен сам docker на сервере. А зачем мне это, если мои приложения работают на jre или на nodejs и окружение для них уже есть на сервере?

    Да? Вы уверены в этом? И версия JRE/NodeJS точно совпадает с тем, что тестировали QA?

    Используйте docker только на самом последнем этапе в вашем рабочем процессе, не тащите его в проект в начале. Он не решит ваших бизнес проблем. Он только сдвинет проблемы на ДРУГОЙ уровень и будет предлагать свои варианты решения, вы будете делать двойную работу.

    Это самый нелепый совет, который можно было дать.
    Смысл DevOps в том, чтобы сделать очень плавным переход от IDE к продакшену (через все промежуточные стадии). А чтобы этого достигнуть, код должен быть изначально в том же состоянии, в каком будет в конце. И Docker — как раз гарантия этого состояния. В нем описано все, что необходимо сделать, чтобы работало так, как оно работало у разработчика.

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

    • kondaurovDev
      /#20032792

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

      Я не знаю что вы имеете ввиду под «началом» и спорить не буду. Я написал, что с docker знаком уже больше 3х лет, и с вашей стороны говорить, что я ничего не понимаю — это грубо.

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

      Разработчики должны писать качественный код приложения. Думать как написать модульный, чистый код. Думать над версионированием, следить за коммитами и чтобы ничего не попало в git репозитории, делать тщательное ревью кода. У них огромная поляна работы в которой использование docker никак не поможет!

      Да? Вы уверены в этом? И версия JRE/NodeJS точно совпадает с тем, что тестировали QA?

      Это работа CI. Он делает git fetch, прогоняет тесты и билдит проект. Можно сделать так чтобы он паковал результаты работы в docker образ и запускаться в контейнере если вы хотите

      • Singaporian
        /#20032866

        Вы когда-нибудь задумывались, что и почему в слове DevOps делает слово Dev? Сможете объяснить концепцию?

        • kondaurovDev
          /#20032928

          Задумывался и спорил по этому много ни раз с другими людьми. И про CI/CD я спорил, что это такое и как должно работать. Но потом, когда устал спорить, я понял, что все это бессмысленно, потому что каждый понимает по своему.
          Теперь я смотрю только на результат, без разницы какой термин у процесса. Так же как и на docker я смотрю сейчас, что он умеет делать и как добиться определенного результата.

          • Singaporian
            /#20033134

            Да дайте хоть одно любое описание концепции DevOps, пусть даже самое спорное.
            Не так важно, на сколько ваше мнение отличается. Важно только, что в нем будет Dev, что и есть ответ на все вопросы.
            ___
            И да, кстати, DevOps — это не гуманитарное понятие. Только у людей, которые не понимают его смысл, расходятся «мнения».
            Термин был придуман и четко сформулирован Патриком Дебуа в 2009-м году. Все остальные люди, если хотят придумать новую смысловую нагрузку, должны для ее названия выбрать свободную комбинацию букв, а не DevOps.

            • Merkat0r
              /#20033908 / +1

              А давайте вернемся в более реальный мир не гиков — да всем плевать что там придумал какой-то никому не известный Патрик :))))

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

              PS Ну я надеюсь уже понятно что самым итшным там была точка доступа от длинка? :)

              • Singaporian
                /#20034046

                А в более реальном мире «негиков» остались те самые проблемы, которые и были решены «никому неизвестным» Патриком. Так вот я и хотел услышать, знает ли об этих проблемах kondaurovDev или не знает.
                Потому что он написал «У них огромная поляна работы в которой использование docker никак не поможет».
                Вы можете выкинуть имя Патрик или термин DevOps из диалога. Но проблему, которую он решает, вы не выкинете. Так что это за проблема?

      • qrKot
        /#20033136

        Думать как написать модульный, чистый код. Думать над версионированием, следить за коммитами и чтобы ничего не попало в git репозитории, делать тщательное ревью кода. У них огромная поляна работы в которой использование docker никак не поможет!


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

  30. Magn
    /#20032726

    Вы видели где-нибудь, чтобы разработчики ПО портировали свои продукты только в docker образе

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

    • kondaurovDev
      /#20032812

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

      • CrzyDocTI
        /#20033164 / +1

        ну, тогда зачем вы пользуетесь компьютерами, медициной, транспортом и т.д. — ведь потом, чуть позже, изобретут еще лучше… ваш выбор: кипу, подорожник, ноги!

      • qrKot
        /#20033304 / +2

        Пакуют ровно под то, под что не лень/имеет смысл.

        Под докер, видимо, имеет. А «технологии будущего»… Хм, как появятся билды, так и поговорим.

  31. AEP
    /#20034420 / +2

    Мое личное мнение: docker полезен в данном проекте, если команда умеет им пользоваться, и если было произведено сравнение полезности с чем-нибудь еще, в пользу docker'а. Умение использовать — это, как минимум, рабочий Dockerfile, процедура деплоя путем пересборки и замены контейнера и отсутствие необходимости делать что-либо еще на хосте, кроме жонглирования с контейнерами и штатного обновления системы. В моем случае (сайт на Drupal, pet container с целой системой вместо разбивки на сервисы), оба критерия были провалены, команда к смене идеологии с pet на cattle не готова, и руководитель сказал «спасибо» за перевод с неправильно используемого docker'а на LXC, который куда лучше подходит для pet container'ов.

    • lega
      /#20035564

      LXC, который куда лучше подходит для pet container'ов.
      А чем он лучше подходит?

      • AEP
        /#20035588 / +1

        Тем, что при рестарте LXC-контейнер ведет себя как виртуалка (не сбрасывается до исходного состояния). Нет ненужных абстракций в виде образов, репозиториев и томов. Просто клонирование, запуск, остановка и удаление, и еще настройки сети. Плюс еще бекап обычными утилитами вроде tar, как обычного каталога.

        • qrKot
          /#20036144 / +1

          Практически согласен, за некоторыми нюансами (чисто справедливости ради):

          Нет ненужных абстракций в виде образов, репозиториев и томов.


          Есть. Образы, репозитории и тома — все есть. (Не критика, это, скорее, хорошо).

          Плюс еще бекап обычными утилитами вроде tar, как обычного каталога.


          Вот тут плюсов не вижу. Докер вполне можно бекапить совершенно аналогично. docker save/load — ровно тот же тар.

        • lega
          /#20038602

          Но это все и в докере есть.

          • qrKot
            /#20039816

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

            Там вся приколюха в том, что докер — это контейнер приложения. LXC (и LXD — отличная штука, очень рекомендую сторонникам LXC) — контейнер ОС. Т.е. «пнул билд — получил образ» vs «вкорячил систему, зашел по ssh, настроил как надо. Что получилось — то и образ». В некоторых моментах работает очень хорошо. Особенно при наличии некоторой экспертизы работы с «честной» виртуализацией.

            • lega
              /#20041532

              Докер пляшет от иммутабельных образов, т.е. "(не сбрасывается до исходного состояния)" — нету.
              Вы заблуждаетесь: docker start, docker stop, docker restart — не сбрасывают контейнер к исходному образу.

              вкорячил систему, зашел по ssh, настроил как надо. Что получилось — то и образ
              Точно также и на докере — запустите нужный контейнер (дистрибутив), подключаетесь, настраиваете все что нужно и используете сколько угодно — запуск/остановка/рестарт/клонирование/бекапы/перенос на другой хост и т.д. все есть без всяких сбросов до исходного образа.
              И в этом плане у LXC никаких видимых преимуществ нет, поэтому переход Docker -> LXC — это просто даунгрейд.

              • qrKot
                /#20041952 / +1

                Вы заблуждаетесь: docker start, docker stop, docker restart — не сбрасывают контейнер к исходному образу.


                У вас `docker commit` отвалился. Без него в этих телодвижениях мало смысла.

                Точно также и на докере — запустите нужный контейнер (дистрибутив), подключаетесь, настраиваете все что нужно и используете сколько угодно — запуск/остановка/рестарт/клонирование/бекапы/перенос на другой хост и т.д. все есть без всяких сбросов до исходного образа.
                И в этом плане у LXC никаких видимых преимуществ нет, поэтому переход Docker -> LXC — это просто даунгрейд.


                Ну, учитывая то, что docker и lxc — две надстройки над ровно одними и теми же механизмами, было бы странно, если бы они действительно существенно различались.

                Справедливости же ради, стоит заметить, что обратная индукция примерно настолько же верна. Я ровно так же могу сделать на LXC все то, что привык делать в докере.

                Просто «дефолтное» поведение докера таки `docker run`, т.е. «стартанул контейнер, пнул в нем приложение, дождался, пока оно сдохнет, убил контейнер в память о приложении». Дефолтное же поведение lxc — прикидываться виртуалкой. Т.е. делать этими инструментами можно, конечно, одно и то же, вопрос только в том, что «кесарю — кесарево». Кувалда и молоток — примерно одинаковые инструменты, но первой менее удобно забивать гвозди, вторым — вбивать костыли.

                Конечно, строго по широте применения и наработанному инструментарию докер, безусловно, круче. Т.е. если вы уже юзаете докер во все поля, притаскивать новую сущность в виде LXC/LXD смысла особого нет. Но, собственно, если у вас определенные пайплайны, построенные на «честных» виртуальных машинах и соответствующий инструментарий поверх них имеется, а вы хотите оптимизировать расходы на содержание этой прелести — сори, докер для вас — оверхед и лишний геморрой.

  32. EgorLyutov
    /#20038812

    Ох, какая статья даже подгорает. Конечно вам не нужен докер, вы же даже не можете почитать документацию.
    Сейчас вполне есть возможность прокидывать безопасно любые секреты, которые не будут в конечном образе, а будут использоваться только при сборке. Так же есть кеширование и не нужно каждый раз при изменении кода и даже пакетов выкачивать все полностью.
    Почти вся статься показывает, что 3 года знакомства с докером это docker ps и docker run.

    • kondaurovDev
      /#20043206

      Конечно вам не нужен докер, вы же даже не можете почитать документацию.

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

      Это вы про --ssh парамерт говорите который появился в 18.09? Я всегда пользовался multistage билдом чтобы убедиться что ничего не попало в слой. Добавление --ssh это просто маркетинг, но это мое мнение, не хочу затронуть чувства верующих.
      Почти вся статься показывает, что 3 года знакомства с докером это docker ps и docker run.

      Статья показывает мою боль с которой я столкнулся при использовании docker. Это моя история и ничего плохого в том что я делаюсь ей — нет.
      Я игрался с k8s, c docker-swarm, с docker-daemon, docker-machine. Не подскажите какой там следующий docker-*?

      • gecube
        /#20043476

        Это вы про --ssh парамерт говорите который появился в 18.09? Я всегда пользовался multistage билдом чтобы убедиться что ничего не попало в слой. Добавление --ssh это просто маркетинг, но это мое мнение, не хочу затронуть чувства верующих.

        соглашусь, что это костыль. А вообще оптимально собирать образы не docker build, а kaniko github.com/GoogleContainerTools/kaniko или buildah github.com/containers/buildah