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

    Всем привет!


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


    Вступление


    Я программист с опытом разработки 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:



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

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

    More
    Ads

    Comments 308

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

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


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


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

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


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

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

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

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

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

        Соболезную вам в таком случае, ни разу не поддерживал 5 — 10 проектов одновременно да и тем более с разным стеком технологий
          +13
          Ansible не тащит какой либо экосистемы на сервер, ему нужен только ssh и python интерпретатор. Бага в Ansible может привести только к тому что на серваке что то не запустится во время проигрывания плейбука.

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


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

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


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

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

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

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

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

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

                    –1
                    Ну, из этого всего мы делаем очень простой вывод:
                    * для первоначальной раскатки софта (с нуля) — ансибл практически идеальный инструмент. Т.к. именно этот сценарий все и используют и именно он требует максимальной степени автоматизации. Молекула проверяет именно его.
                    * Для остальных сценариев — поддержание инфраструктуры в определенном состоянии — ансибл можно использовать, но есть куча подводных камней. Например, особую боль могут доставить миграции между разными версиями одной и той же роли.
                    * Автоматизация рутинных задач на ансибле (бекап баз, например) — вообще странное занятие, ну, ок, можно и так…
                      0
                      Никогда, никогда не переобувайте тапки на ходу. Выбрали без докера, так и живите, пока не поймёте, что он будет решать проблемы вашего проекта. И да, в 99% случаев, если ваш сервис — это 1 jar, вам не нужен докер.
                        0
                        А мне-то зачем отвечаете? Я только затронул один аспект — ансибл. Про докер я тут ничего не писал )
                        Никогда, никогда не переобувайте тапки на ходу

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

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

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

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


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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

                    Ну как, это проблема внедрения докера.
                    А жалоба не на возможность, а на возрастающий порог входа.
                    Есть возможности опциональные (я могу использовать докер, а могу про него не знать), а есть селективные (если внедрен докер, то мне надо как-то уметь Dockerfile).
                      0
                      Есть возможности опциональные (я могу использовать докер, а могу про него не знать), а есть селективные (если внедрен докер, то мне надо как-то уметь Dockerfile).

                      Повторюсь, что есть 100500 способов получить образ докера, не применяя Dockerfile.
                      Просто этот метод (через Dockerfile) считается самым простым и базовым. Не более того
                        0
                        То есть вы предлагаете внедрять докер не ознакомившись с простым и базовым способом, и обещаете, что я с ним не столкнусь?

                        Ну, допустим. Тогда мне надо учить другой способ, сложный и почему-то не базовый. Ну, мне не полегчало
                          0
                          В общем случае — он не самый простой и не самый лучший.
                          Например, возможна ситуация, когда Вам нужно собирать образ, а вариантов кроме как в докере запускаться нет — будете городить docker-in-docker с необходимостью привилегированного запуска? Или возьмете kaniko или buildah, которые лишены соответствующей проблемы? Да еще и быстрее?
                          Я не говорю, что Dockerfile и сборку докером докер-образа нужно в принципе отрицать — действительно нужно знать, что такой механизм есть, но что он абсолют… Ну, не так это. Не говоря уже о том, что появилось 100500 замен докеру. Тот же cri-o, containerd, rкt и пр… Главное, что формат образа стандартизован (OCI).
                    +1
                    если я хочу запустить свой (приватный) локально собранный образ на удаленном сервере, то мне нужен свой docker репозиторий

                    Если чисто поиграться, то не нужен. Ничто вам не мешает сделать docker build напрямую на удаленном сервере и запускать сбилденный образ. Более того, я так пол года в продакшене жил. Все ок, разве что трафик туда-сюда гоняется нешуточный и в лесу деплой не сделать.
                      +1
                      Это самая худшая из практик. Сами же верно говорите, что лишний трафик. А ещё лишняя нагрузка на процессор и диск. Да и система засоряется временными докер образами (тем более, если процесс сборки по какой-то причине упадет).
                      Есть ещё одно очень важное соображение. Вы не гарантируете, что сборка локально и удаленно совпадет. Потому что как минимум — никто не фиксирует версии базовых образов в докерфайлах. И, да, я не просто про метку или тег говорю, которые всегда могут быть перезаписаны, а именно sha сумму образа. Сколько образов именно по ней ссылаются на базовый образ?
                        +1
                        По мне так это обычная практика. Ничего там не засорялось, по крайней мере бесконтрольно.
                        Да, на сервере должны быть определенные ресурсы для сборки. В моем случае это были не большие ресурсы.
                        На счет гарантий — все точно так же как при сборке локально или через CI/CD. По sha образы никогда не фиксируют просто потому что это маразм. Никто просто так не перезаписывает теги (кроме latest конечно).
                          0
                          Никто просто так не перезаписывает теги (кроме latest конечно).

                          Объясните это безопасникам. И я с ними, кстати, согласен. Ни один из по-простому доступных докер репозиториев не умеет иммутабельные теги. К сожалению. Это можно заимплементировать на уровне прав доступа + в пайплайнах сборки, но это костыли.
                          Просто надо понять, что существует как минимум два типа тегов — постоянные (релизы) и перезаписываемые (latest, master, dev и по названиям веток). Почему-то при проектировании докера как системы это не учли и имеем то, что имеем.
                          Повторюсь, что нет единой конвенции и даже если бы она была, то многие ее нарушали бы (пример — hub.docker.com/_/golang — под 1.11-stretch ВСЕГДА будет последний билд, а не какой-то определенный)
                            0
                            Я не спорю с тем, что теги могут быть перезаписаны. Но не пойму что вас удивляет в 1.11-stretch. Да, там всегда будет последний билд и… это так и задумано, по крайней мере в моем понимании.
                            Если вам это не подходит, ничто не мешает собрать свои базовые образы и использовать их, там все теги полностью под контролем.
                      +19
                      Когда любую технологию (кросс-платформенность, докер, микросервисы, ...) обьявляют «общей теорией всего» — тогда начинаются проблемы. Докер хорош для ситуаций, когда вам нужно поднять разные окружения на одной машине или просто запустить что-то требующее нудной и нетривиальной компиляции и конфигурации (OpenCV, TensorFlow — отличные примеры). Docker-compose, соответственно — если таких компонентов у вас несколько.
                      А когда все устаканилось, есть официальные CI/CD конвееры и окружения для тестов — можно хоть Linux from scratch собирать, Докер здесь только одна из возможностей.
                        +9
                        Докер популярен потому, что программисты в 99% случаев не имеют админской квалификации в Linux.
                        По той же причине популярен Windows.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                                Это просто админ, никакой не супер. А ещё в нормальных конторах есть безопасник. Ибо практика показывает, что если девляпусов не контролировать, информационной безопасности вообще не будет.
                                  0
                                  Я не спорю что это делается (хотя и не за две минуты). Это неудобно и требует дополнительного человека, а тут вам удобный инструмент.
                                    +1
                                    >Это неудобно и требует дополнительного человека

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

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

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

                                      Окей вы в 5 строчек сделали ингресс (конечно, нет, но предположим, что да). Еще надо service-discovery, deployments/rolling update, workload scheduling/autoscaling, access-control, ci/cd и у вас 10 команд, которые пишут на Go, Python, Elixir, Ruby, JS, и деплоят по 10 раз в день в 3 DC. Сколько вам еще строчек конфига хапрокси нужно чтоб эту задачу решить?
                                        0
                                        Смешно мне с этого натягивания совы на глобус. Начали с голого доцкера в днищенских конторах которым на одного средненького одмина денег жалко, сейчас понеслось — 10 команд, зоопарк стеков и кубер.

                                        Практика показывает, что можно успешные проекты на убогом php делать (VK, да FB). ХЗ есть ли у них сейчас кубер, даже если есть сейчас, то сколько лет без него жили и не жужали? Все эти вопли про незаменимость доцкера просто смердят смузи. ;)
                                          0
                                          Начали с голого доцкера

                                          Я в этой ветке оставил ровно один коментарий (помимо этого), ничего про «голый доцкер» не писал. Ответил на ваш «HA в 5 строк конфига». Так-то, в «днищенских конторах которым на одного средненького одмина денег жалко» и HA нафиг не уперся. А все эти рассуждения про 5 строчек и про то, что «VK и FB вон вообще на PHP пишут» говорят о том, что вы, скорее всего, большие проекты только на картинках видели.
                                            0
                                            >А все эти рассуждения «VK и FB вон вообще на PHP пишут» говорят о том, что вы, скорее всего, большие проекты только на картинках видели.

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

                                            Зачем это всё, когда есть нормальные фулстек платформы, как например жабка?

                                            Разработка например linux kernel у фанбоев доцкера относится к маленьким проектам? ))) Они там и без CI хипсторского как-то живут. Наверное потому что о безопасности немного думают и за модный нынче подход «быстро поднятое упавшим не считается» там обычно Линус ломает ноги.
                                              0
                                              Они там и без CI хипсторского как-то живут. Наверное потому что о безопасности немного думают и за модный нынче подход «быстро поднятое упавшим не считается» там обычно Линус ломает ноги.

                                              Нет, не поэтому. А потому что разработка linux — это, в основном, работа с "железом". И проверить её можно только на реальном железе.

                                                –1
                                                >Нет, не поэтому.

                                                Линус, ты? Если нет, то можно было и не так категорично.

                                                Плюсов, ООП, CI итд итп нет вовсе не потому, что 50% кода — дрова.
                                                  0
                                                  Полюсов там нет потому что плюсы любят вызывать std::terminate в непонятных ситуациях.

                                                  ООП там есть.
                                                    0
                                                    Ну, это из разряда, «при наличии бесконечного количества прогеров и времени, любую задачу можно сделать на ассемблере, т.к. всё высокоуровневое написано на ассемблере».

                                                    Но при этом нынче почти всё нет смысла делать на асме.
                                                0
                                                Зачем это всё, когда есть нормальные фулстек платформы, как например жабка?

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

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

                                  +6
                                  Но ведь в этом самом docker-compose в итоге будет этот же самый бардак, только запрятанный парой слоёв абстракций. Софт и библиотеки в образе докера сами по себе не появятся.
                                    +10
                                    Докер и начинают везде пихать как средство заметания муора под ковер ИМХО.
                                      +3

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


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

                                        +1

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


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

                                    +5

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

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

                                        В общем я понимают боль девов, когда им навязывают докер, но это боль во благо продукта.
                                          –1
                                          Есть еще один недостаток — высокий расход ресурсов.
                                          Другой недостаток, вместо порядка — «замести под ковер».
                                            +2
                                            Каких ресурсов? Что значит высокий?
                                              –3
                                              Память, диск.
                                                +3
                                                Вы серьёзно? Я вот эти доводы слышу от людей, которые судят про докер потому что увидели что на маке он работает в Virtualbox (ой, докер оверхед создает и тд). Используем докер в продакшене на нескольких десятках машин под Кубером. Более удобного инструмента для масштабирования, деплоя, мониторинга и тд я в жизни не встречал.
                                                  0
                                                  Docker на Mac уже давно не использует Virtualbox.
                                                    0
                                                    Да, я знаю. Но почему-то часть народа до сих пор так думает, что докер это виртуалка со всеми вытекающими минусами. Несколько раз сталкивался с таким мнением
                                                      0
                                                      На самом деле все так и есть. Посмотрите внимательно на docker for mac
                                                      И, да, это не виртуалбокс. А другое. Но работает все равно на выделенных ресурсах и в виртуалке.
                                                    0
                                                    Расскажите, где реально кубер используется в каких проектах?
                                                    Говорят, что кубер сложен в настройке и глючный. Насколько это правда?
                                                      0
                                                      У нас вся инфраструктура на кубере, не важно какой именно проект: и телеметрия, и сами проекты и базы данных, и гитлаб и прочее, все в докере (у нас геймдев студия). Кубер относительно сложный в настройке, скорее в него не так легко вкатиться сначала, потом уже становится все сильно проще. То что прям сильно глючный — не могу сказать, но иногда проскальзывают мелкие неприятные моменты, но ни разу не привели к даунтайму. Но дальнейшее удобство от его использование сильно перевешивает это.
                                                      0
                                                      Ну, у меня имиджи по 2 гига получаются, вот только сейчас глянул.
                                                        0
                                                        Подозреваю что вы что-то делаете не так, что-то лишнее запихиваете в образ, что должно лежать на внешнем volume. Почти любое приложение можно запихнуть в alpine образ, если уж сильно постараться. У нас даже кривые образы, до которых не доходят руки поправить, не выходят за гиг.
                                                          0
                                                          Вот глянул, базовый образ, выбирал не я — python2.7 925MB, После установки и компиляции всех нужных пакетов получается 1.97.
                                                          Думаю на пару сот мегов можно уменьшить, если повозиться.
                                                          Но это же и есть то, о чем я пишу, докер ест мое время за напонятный выигрыш. Точнее выигрыш для девопов, им не нужно возиться с установкой нужного мне софта и они могут поиграться с тем, что им нравится, вместо того, чтобы влезать в то, что на самом деле работает.
                                                          А проблемы они будут решать рестартом контейнера.
                                                          По моему так.
                                                          А делать образ из альпайн? Сначала я должен всех переубедить, что это стоит того. Еще туда должен буду установить мои зависимости и еще не факт, что получу большой выигрыш.
                                                          Ну плюс риск, что я могу потратить несколько дней на компиляцию и установку всего чего нужно, а в конце натолкнусь на непреодолимое препятствие.
                                                            0
                                                            Докер ест время на вполне понятный выигрыш. Если у вас одна машина, то он вам не нужен. Если у вас несколько машин, то каждый раз ставить на них все зависимости и производить базовые настройки для запуска приложения — это трэш. Завтра у вас одна машина упала и вы судорожно настраиваете ей замену, а я просто ставлю label на другой и смотрю как Кубер поднимает на ней контейнер за минуту, согласно заданным правилам.

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

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

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

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


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

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

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


                                                                Не поверите, ровно для этого случая все и задумывалось!
                                                                  0
                                                                  Ну так как оно работать-то будет?
                                                                    0
                                                                    Отлично работать будет. Программист просто пнет сборку на месте, оно соберется и запустится.

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

                                                                    При этом в числе зависимостей сборки будут а) наличие репозитория исходного кода б) доступ к докер-регистри.
                                                                      0
                                                                      Вот я уже приводил ниже пример проекта, над которым не так давно работал. Для сборки требуется, в том числе, Visual Studio с особыми дополнениями, всяческих Build Tools недостаточно.

                                                                      Вы предлагаете добавлять образ установленной студии (5 гигабайт) в регистр образов? Как часто он будет выкачиваться оттуда при сборке? Что делать работающим удалённо разработчикам?
                                                                        0
                                                                        Вот я уже приводил ниже пример проекта, над которым не так давно работал. Для сборки требуется, в том числе, Visual Studio с особыми дополнениями, всяческих Build Tools недостаточно.


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

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


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

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


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

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


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


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

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


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

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


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

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


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

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

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


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

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


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

                                                                                Собственно, для CI/CD (и собственно DevOps) неплохо подходит .NET Core, но его собирать студия не нужна.
                                                                                  0
                                                                                  Не моя цитата. Я как раз про «докер — отличный инструмент для определенных проектов(не для всех)».

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


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

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


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

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

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


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

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


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

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

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

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


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

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


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

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


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

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


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

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


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

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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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


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


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

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


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

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

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


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

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


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

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


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

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

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


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

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


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

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


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

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

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


                                                                                            Это просто значит, что контейнеры вам не помогут. А хочется, признайте уже!)))
                                                                                              0
                                                                                              Только не подавайте «нам не подошло» как недостаток контейнерной виртуализации в целом. Оно просто вам не подошло, но вы, видимо, интересуетесь. Не зависть ли это?)

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


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


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

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


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

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


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


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

                                                                                              Ну уж нет.


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

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


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

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


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

                                                                                              Бинго!

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


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

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

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

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


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

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


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

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

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


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

                                                                                                Ну уж нет.


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

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


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

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


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


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


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


                                                                                            Как надо?

                                                                                              0
                                                                                              Как надо?


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

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

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


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


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

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

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


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

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

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


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

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


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

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


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

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

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

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

                                                                                                      Ну у меня просто код такой, там вот меньше, чем только недавно зарелиженный gcc 8, уже не хватает для сборки, и это я ещё удерживаю себя в руках и не пользуюсь всеми вкусняшками из C++20. Поэтому только анстейбл, только хардкор!


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


                                                                                                      Да, ожидать, что это достаточно распространённый кейс, как-то глуповато с моей стороны.

                                                                                                +1
                                                                                                > берете разработчика с зарплатой, предположим, 1500р/час

                                                                                                А сколько уйдет ЧЧ на объяснение команде, например, из 10 разрабов о том, что такое докер и как его пользовать? Ну и сколько вы за такую услугу готовы взять?

                                                                                                А то у меня ощущение, что два нуля добавляются легко.
                                                                                                  0
                                                                                                  А сколько уйдет ЧЧ на объяснение команде
                                                                                                  В моем случае наоборот произошла экономия ЧЧ, я им дал одну команду «make start» и проект запускается (и не факт что они знают что оно на докере), вручную запускать и связывать эту кучу сервисов — они бы потратили не один день.
                                                                                                    0
                                                                                                    > я им дал одну команду «make start» и проект запускается

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

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

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

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


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


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

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


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


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


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

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

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

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


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

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

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


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

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


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

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

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


                                                                                Не отрицаю. Просто происходить это будет не при каждой сборке и не целиком, а только при изменении в проекте и теми кусками, которые нужно пересобрать. Т.е. как раз рантайм, например, тащить каждый раз не придется, он будет лежать в базовом слое. При наличии, допустим, 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ю (а там, предположим, апи поменялся).

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

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


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

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


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


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


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

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


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

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

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


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

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

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


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

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

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

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

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


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

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


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

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


                                                                                    Не, совершенно не точно будет. И, опять же, «можно скачать». Т.е., типа, скачать, сложить, а потом ручками раскатывать на сервера по памятке: «поставить рантайм версии X.Y.Z -> Далее -> Далее -> Далее»? Не-не-не, увольте)
                                                                                      0
                                                                                      Посмотрел, немного не то нашлось в репозитории. «The ghostscript dlls» написано. А мне экзешник нужен, причем с путями прописанными… Вот такие «зависимости», сори, конечно, ни один языковой пакетный менеджер не резолвит.

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


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

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


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


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

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


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

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


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

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


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

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


                                                                                        Элементарно:
                                                                                        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, это просто управлялка штатными механизмами изоляции ядра.
                                                                                          0
                                                                                          Имею право, почему нет?

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


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

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


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

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


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


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


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

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

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


                                                                                            Ну, во первых, имею право, ничего предосудительного в этом нет. В конце концов, и работа с библиотекой может быть сложнее, чем «пнуть экзешник с набором параметров». И сама либа-враппер может быть разной степени сомнительности. Да и приложуха по сути вполне может быть какой-нибудь «удаленной управлялкой», которая в 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). Вся фишка в том, что контейнер существует ровно с момента запуска, это, если угодно, «рантайм-сущность». А на входе один фиг образ, который для всех одинаковый. Как он представлен в виде контейнера никого не колышет, он будет работать.
                                                                                              0
                                                                                              Вы же про деплой ансиблом говорили.

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


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

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


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

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


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

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


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


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

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


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


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

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


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

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


                                                                                                Вот к вопросу о «бонусах» контейнеров. В контейнере у вас базовый слой (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 есть, возьметесь? Буду считать, это же очевидно!
                                                                                                  0
                                                                                                  Вот к вопросу о «бонусах» контейнеров.

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


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

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


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

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


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

                                                                                                  Вот и я могу!

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


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

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


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

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


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

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


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

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

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


                                                                                                        Осталось понять, кто эту задачу поставит. Дело в том, что 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, вероятно, норм смигрирует, что-то крупнее… Ну, не знаю.

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

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


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

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


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

                                                                                                            0
                                                                                                            То же самое применимо и для .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]). Но их всё ещё можно использовать.


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

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

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


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

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

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

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


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

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


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

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

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


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

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

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


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

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

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


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

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


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

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


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

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


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

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

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


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


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


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

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


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


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

                                                                                    –1
                                                                                    Так и хочется вам сказать, идите уже на… отдельный чат со своим .NET Core…
                                                                                      –1
                                                                                      Я не сишарпер. Так что .NET Core, видимо, скорее ваш (если вы на C# пишете).
                                                                                        0

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

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

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

                                                                                        Я вот просто читаю, и ощущение, что докер нужен потому, что у вас остальной инструмент кривой, отсюда и желание «собрать и не трогать, пока что-то не отвалилось».
                                                                                          0
                                                                                          Я вот просто читаю, и ощущение, что докер нужен потому, что у вас остальной инструмент кривой


                                                                                          Хм, читаю я вот вас, и ощущение такое, что опыт у вас специфический и узкоспециализированный. Дело в том, что любой, без исключения, инструмент — кривой. Дело только в степени кривизны.

                                                                                          При этом у нас есть две стороны процесса: экосистема разработки, в которой могут и разрабатывают в той среде, которая наиболее подходит для языковой среды, и экосистема эксплуатации, где принято применять методы, наиболее нативные в рамках выполняемой задачи. И вот эти экосистемы несколько разные, а желание иметь универсальный инструмент, позволяющий сгладить некоторые углы гетерогенных продуктов, а также гетерогенных сред эксплуатации — достаточно нормальная вещь.
                                                                                            +1
                                                                                            > Дело только в степени кривизны.

                                                                                            То есть проблем с обратной совместимостью дотнета вы тоже не видели.

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


                                                                                              Ну йошкин кот, кто о чем, а вшивый о бане. docs.microsoft.com/ru-ru/dotnet/framework/migration-guide/net-framework-4-migration-issues — вот тут ласково намекают, что миграция не в 1 клик делается, а значит два фреймворка тащить за собой может понадобиться, что не есть хорошо.

                                                                                              Ну и, собственно, если вы разработчик .NET Framework — относительно докера можете смело проходить мимо, т.к. это не ваш инструмент. Собственно, докер на вашей целевой платформе (aka Windows) — явление достаточно странное и чужеродное, в жутко зачаточном состоянии.

                                                                                              А вот если вы на .NET Core пишете, тут вопрос другой.

                                                                                              docs.microsoft.com/ru-ru/aspnet/core/migration/21-to-22?view=aspnetcore-2.2&tabs=visual-studio — вот тут прямо говорят, как и откуда докер-образы брать. Отличная штука, если деплой-таргет для вас — кубернетс или какой-нибудь облачный провайдер контейнерной изоляции.

                                                                                              Поэтому ненормально, когда виртуальная машина исполнения кода обратной совместимости не имеет


                                                                                              Ну неправда же. Если виртуальная машина обратной совместимости не имеет — вполне нормальная и местами предпочтительная ситуация. Минималистичная шустрая ВМ под строго одну версию рантайма — это всяко лучше, чем монструозная фигота, обвешанная костылями вида if(vm.version < 261) {...} else {...} Не говорите мне, пожалуйста, что костыли и заботливое бекпортирование багов из старых версий «для совместимости» — это хорошо. Вот ни разу.

                                                                                              Вот, собственно, для таких вещей, где рантайм менее, кхм… универсален, скажем так, и пилят докер.

                                                                                              возникает желание тащить бета-версию в продакшн, навесив ради этого сверху докер


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

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


                                                                                                Поэтому любая легаси хоть под .net 1.1 запускается как родная


                                                                                                всяко лучше, чем монструозная фигота

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

                                                                                                  0
                                                                                                  что бы этим использование другой монструозной фиготы обосновать.


                                                                                                  Ну, как бы, в сравнении с контейнерной изоляцией, которая, по факту, управлялка над механизмами изоляции ядра (cgroups, namespaces)… Ну, как бы, да, .NET Framework — монструозная фигота)

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

                                                                                                  И да, еще раз, если вы — разработчик .NET Framework, докер не для вас. Ну вот не пролазит windows-only фреймворк в концепцию, ничего не поделаешь. Так и запишите: «Конкретно в моем случае — не подходит, лишний геморрой и пятая нога для собаки». Только не кричите «докер плохой» и «контейнерная виртуализация нинужна», перефразируйте на «лично мне контейнерная виртуализация не подходит, очень жаль».

                                                                                                  Это разные фреймворки, на машине стоят одновременно. Разные, понимаете?


                                                                                                  Понимаю, что разные, отлично понимаю, только не нервничайте. Я вот только не понимаю, допустим, в случае, если у меня 10 серверов, на которых крутится 50 сервисов, 3 из которых просят .NET Framework 1.1 и планируются к замене в обозримом будущем… Вот реально, мне на все 10 серверов по .NET Framework 1.1 раскатать? Вы уверены, что «изолировать легаси» не будет лучшим решением?

                                                                                                  Поэтому любая легаси хоть под .net 1.1 запускается как родная


                                                                                                  Чтобы она запустилась «как родная», нужно сначала еще один фреймворк рядом вкорячить. А потом вдруг выяснить, что какой-то кусок легаси внутрях содержит unmanaged код, которому требуется версия библиотеки, которая роняет мой распрекрасный самый ультрасовременный .NET Framework самой что ни на есть стабильной версии.

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

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

                                                                                                  Перейдите хотя бы на .NET Core, тогда и смотрите, придется ли оно вам к месту. Сама экосистема разработки под .NET Framework старше, чем cgroups, поверх которых уже сильно потом контейнеры росли. Зря ругаетесь, вас уже не сломают, и лучше просто не следите за новостями, не портите себе нервы.
                                                                                                    +1
                                                                                                    Ну, как бы, в сравнении с контейнерной изоляцией,

                                                                                                    Сравнением чего? Одного костыля, который вы нашли? Нет, передергиванием докер тоже не оправдать.


                                                                                                    Только не кричите «докер плохой» и «контейнерная виртуализация нинужна»

                                                                                                    Это где вы такое у меня нашли? Или просто такой метод дискуссии, приписать мне что-то и с этим спорить?


                                                                                                    Зачем докер нужен я понимаю. Зачем он нужен каждому — нет.


                                                                                                    Вот реально, мне на все 10 серверов по .NET Framework 1.1 раскатать?

                                                                                                    А раскатать докер с образами из тех же файлов чем именно проще? Напомню, версий там за 20 лет — по пальцам одной руки.


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

                                                                                                    Я, почему-то, уверен, что смогу написать код, который не заработает в докере на линуксе старше таргета на 18 лет. Но да, если(!) мне в этой жизни встретится такое, что библиотека ломает фреймворк а винду гоняет в BSOD, а я эту хтонь нести на продакшн должен доверить… А что, в линуксе так часто?


                                                                                                    Признайтесь, вам просто завидно, что другие пользуют и довольны

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

                                                                                                      –1
                                                                                                      Нет, передергиванием докер тоже не оправдать.


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

                                                                                                      Одного костыля, который вы нашли?


                                                                                                      Ну вот видите, «костыль». Докер — не костыль, а средство доставки приложения.

                                                                                                      Зачем он нужен каждому — нет


                                                                                                      Ну вот теперь вы перечитайте, что я писал. Где же вы увидели, что докер нужен каждому. Я даже, более того, прямо написал, что разработчику на .NET Framework, например, он не только не нужен, а даже, скорее, противопоказан. Есть более другие разработчики, им нужен. А вы эгоцентрист, видимо.

                                                                                                      А раскатать докер с образами из тех же файлов чем именно проще?


                                                                                                      Тем, что не все задачи можно/стоит покрывать средствами одной языковой экосистемы. А докер — инструмент универсальный. Т.е. им можно покрыть и .NET Core, и PHP, и Node.js. И сделать это, с точки зрения доставки приложения на сервер, одинаково.

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


                                                                                                      Я вот, почему-то, уверен, что докер в принципе не запустится на линуксе 18-летней давности, например.

                                                                                                      Но да, если(!) мне в этой жизни встретится такое, что библиотека ломает фреймворк а винду гоняет в BSOD, а я эту хтонь нести на продакшн должен доверить… А что, в линуксе так часто?


                                                                                                      Это не в линуксе, это в прекрасном мире энтерпрайза.

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


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

                                                                                                        На винде? Часто? И до сих пор никто не спешит докер прикрутить, все молча страдают?


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

                                                                                                          –1
                                                                                                          На винде?


                                                                                                          Платформо-агностически. Т.е. на «везде». Например, в 2015 году (насчет после не знаю, не работаю уже там) в некоторой достаточно крупной организации имелась необходимость крутить АРМ оператора, написанный на Clipper'е. DOS-only, последний стабильный релиз языка — 1997 год. И человек, вроде вас, утверждающий «все это говно, надо переписать, работать не будет» — тоже был. Ну, т.е. остановить прием платежей от населения на полгодика в масштабах области и переписать не спеша… Был. Уволили к хренам, потому что «энтерпрайз».

                                                                                                          Часто?


                                                                                                          Достаточно часто, достаточно масштабно, с различной степенью обоснованности подхода.

                                                                                                          И до сих пор никто не спешит докер прикрутить, все молча страдают?


                                                                                                          Чоэта страдают? Вот, пилят, например. И WSL пилят, причем тот же Microsoft, который нежно любимый вами .NET пилит. При этом под ASP.NET Core его даже очень рекомендуют… Видимо, это кому-нибудь нужно, ага. А страдать… Не, не страдают. Страдать — это к вам, остальным работу работать.

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


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

                                                                                                          работающих не везде,


                                                                                                          «Работающие везде» нереализуемо.

                                                                                                          и, действительно, пойду


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

                                                                                                            Кто-то слышал, что в 2015 было приложение, поэтому надо насаждать докер, ОК. У вас все аргументы «а вы на шкаф залезте».


                                                                                                            Кхм, вы на полном серьезе противопоставляете средства доставки в пределах программного стека средствам доставки в пределах экосистемы задач?

                                                                                                            Вы, видимо, не очень знакомы со средствами доставки на винде. Ну и ладно.

                                                                                                              0
                                                                                                              Кто-то слышал, что в 2015 было приложение


                                                                                                              Не кто-то, а я. Не слышал, а видел…

                                                                                                              поэтому надо насаждать докер


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

                                                                                                              У вас все аргументы «а вы на шкаф залезте».


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

                                                                                                              Вы, видимо, не очень знакомы со средствами доставки на винде.


                                                                                                              Вы, видимо, вообще не знакомы со средствами доставки за пределами винды… И?
                                                                                                                +1
                                                                                                                > в определенном спектре задач контейнерная изоляция дает весьма ощутимые плюшки

                                                                                                                И Ваш пример — в спектре доставки АРМ под DOS, внезапно ставший проблемой.
                                                                                                                  –2
                                                                                                                  И Ваш пример — в спектре доставки АРМ под DOS, внезапно ставший проблемой.


                                                                                                                  Мой пример иллюстрировал некорректность вашего высказывания «Но да, если(!) мне в этой жизни встретится такое, что библиотека ломает фреймворк а винду гоняет в BSOD, а я эту хтонь нести на продакшн должен доверить… А что, в линуксе так часто?» Линукс тут совершенно ни при чем, есть определенные задачи, которые нужно решать, а ваше «а у нас в .NET лучше» или «у нас такого треша нет» — дело строго второстепенное. Деньги платят за задачу, а не за экзерцисы с любимым стеком технологий.

                                                                                                                  Если хотите посмотреть на задачи, в которых контейнеры хороши — велкам. Есть серверы, 5 штук. На них надо хостить 50 мелких интернет-магазинов, которые работают на 10 версиях PHP и 2 версиях Django. При этом хочется отказоустойчивости и автомиграций.

                                                                                                                  Подскажете, что справится с этой задачей лучше контейнеризации?
                                                                                                                    +1
                                                                                                                    Мой пример иллюстрировал некорректность вашего высказывания

                                                                                                                    То есть я вам пишу про библиотеку, ломающую фреймворк, а вы мне ответом про приложение под DOS показываете некорректность? Оок )
                                                                                                                    Интересно только зачем, если к контейнерам это отношения не имеет.


                                                                                                                    работают на 10 версиях PHP

                                                                                                                    ДЕСЯТЬ несовместимых версий. Как я скучно живу. Подозреваю, что эта коллекция вовсе не с 1997 года началась…

                                                                                                                      0
                                                                                                                      То есть я вам пишу про библиотеку,


                                                                                                                      Вы пишете про то, что проблема присуща только линуксу. Я вам пишу, что не только, это общая проблема.

                                                                                                                      ДЕСЯТЬ несовместимых версий. Как я скучно живу


                                                                                                                      Десять — далеко не предел. Да, вы живете скучно.
                                                                                                                        0
                                                                                                                        Вы пишете про то, что проблема присуща только линуксу

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


                                                                                                                        Десять — далеко не предел.

                                                                                                                        Хорошо, когда не скучно и есть повод докер изобрести. Уговорили, я завидую.

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

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

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

                                                                            Собственно, к чему это я — что у вас там за безумные приложения, что тянут за собой зависимости в 1гб(!) и при этом сам образ под гб доходит? Реально интересен функционал, который требует таких размеров?
                                                                              0
                                                                              Абсолютно поддержу. Единственное, что может там 60 слоев в сборке контейнера.
                                                                                0
                                                                                Python+gstreamer с плагинами
                                                                        +1
                                                                        Вы забыли слезы разработчиков.
                                                                        А если серьезно, то реальный оверхед добавляют разве что докеровские сети, но для большинства проектов даже он ничтожно мал.
                                                                          0
                                                                          Что-то мимо вообще. По памяти и диску от докера оверхед настолько минимален, что его можно списать в статпогрешность.

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

                                                                      Дайте угадаю, вы не дев?
                                                                      Ну то есть, перекладывание с больной головы на здоровую? Теперь дурака валять могут админы.
                                                                        0
                                                                        Я был девом лет 15, но последние лет 5 поневоле стал кем-то вроде SRE / архитектора. И программерский опыт очень помогает понимать, как именно могут нашкодить девелоперы, особенно современные.
                                                                          0
                                                                          Трава зеленее, деревья выше, «были люди в наше время».

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

                                                                          А внедрять девопс через боль, рассказывая как вы тут все молодежь шкодите, получайте…
                                                                            0
                                                                            Я ведь не про идеальный код, а про доставку продукта и то, как докеризация её унифицирует. Это вне времени. А всяких художников, знающих лучше операционщиков, как их поделие должно запускаться и каких проблем в продакте не бывает, или наоборот, желающих писать только код, но не желающих даже задумываться, как оно в лайве будет работать — я уже навидался. В общем-то и сам таким по молодости был, в том и пойнт, что девелоперский опыт — мас хэв для SRE/DevOps, что бы ставить процесс.
                                                                              +1
                                                                              Меня то удивил поинт про нанесение пользы и принуждение думать через внедрение неудобств при разработке. Индифферентно к докеру. Как только человек 2 недели код не пишет — опыт вытесняется и включается «да что ж вы так плохо/медленно/не так делаете», а мысли ставить процесс так, что бы минимизировать ущерб перестают считаться конструктивными.

                                                                              Как доставка продукта происходила мне сложно оценить, а код этих гордых титанов прошлого остается.
                                                                                0
                                                                                Ну вот раньше было удобство — пойти на сервер по SSH, поправить файлик / посмотреть что будет. Теперь оно невозможно. Это удобство для дева во зло или благо?
                                                                                  0

                                                                                  Почему вы считаете, что ходить по SSH удобно?

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

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

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


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

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


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

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


                                                                    Что-то вы и LXC в старье запихали, и snap в ту же кучу замешали…
                                                                  • UFO just landed and posted this here
                                                                      0
                                                                      Это где так мощщно используется docker? В какой компании?
                                                                      • UFO just landed and posted this here
                                                                        +2
                                                                        Не путайте docker и swarm. Ввместо второго в приличном обществе принято использовать кубернетес
                                                                        • UFO just landed and posted this here
                                                                            0
                                                                            То что нативный это хорошо, но вы писали что докер бажный, но приводили примеры багов сварма. Это и смутило.
                                                                            • UFO just landed and posted this here
                                                                          0
                                                                          Это клауд был или какой-то ДЦ?
                                                                          • UFO just landed and posted this here
                                                                          –10
                                                                          Делал контейнер из Windows приложения и Wine. Такая себе штука этот ваш Docker. Мне лично показалось что проще было бы все поставить на целевой машине чем тащить в Docker.
                                                                          +9
                                                                          Говорить, что Docker говно — все равно, что говорить: «отвертка — говно, так как хреново забивает гвозди!»

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

                                                                          Из моего опыта — работа в студии… за день можно поработать с 3-мя проектами, которые используют разные базы, разные версии PHP, где-то Апач, где-то Нжинкс… я хз что бы делали без докера и докер-композера… а так: down/cahnge_project/up — и окружение полностью изменилось…
                                                                          • UFO just landed and posted this here
                                                                              0
                                                                              На проде у него своя ниша. Это микросервисы плюс k8s, nomad и т.п.
                                                                              Если тянуть на прод через docker-compose будет очень быстрое и простое первоначальное разворачивание приложения. И большие проблемы с деплоями.

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

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

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

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

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


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

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

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

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

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