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:



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

    Поделиться публикацией

    Комментарии 264

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

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


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


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

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


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

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

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

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

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

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

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


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

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


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

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

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

              Даже если проигнорировать то, что `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-плейбуки прекрасно тестируются… в докере.


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

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

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

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

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

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

                  Жаль, что не всё работает в контейнерах
                  Например?
                    +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 собирать, Докер здесь только одна из возможностей.
                        +8
                        Докер популярен потому, что программисты в 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. Это и есть хипстерство и попытки подзаработать на свеженьком.
                              +3
                              Давайте будем честными. Профессиональные сисадмины, которые знают свою систему вдоль и поперек, само-собой, лучше справятся с ее настройкой, чем программист с Docker.

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

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

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

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

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

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

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

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

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

                                    Фанбои докера не в курсах, что Кубер это сборная солянка из совершенно разных «удобных инструментов», которым лет намного больше, чем докеру и куберу. И никто не мешает делать HA и FO на например haproxy, у которого конфиг 5 строчек. По сравнению с ним докер и кубер жуткие монстры. И не надо спорить.
                            +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
                                                                    Ага, деплой скрипт, который пойдет все качать, ставить настраивать и тд, и тд. вместо того чтобы просто сделать 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
                                                                      У нас готовое приложение на java, завёрнутое в докер весит не больше 200(!) мегабайт, хотя я и такого не смог найти. Не больше 150 выходит.
                                                                      Но у нас микросервисы, которые не совсем и микро, просто разделены на функциональные компоненты и не повторяют костыли одного и того же, если уже есть сервис с нужным функционалом.

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

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

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

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

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

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


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

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


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

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


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

                                                            По ансиблу ничего не могу сказать, сама концепция не очень понятна. Зачем городить надстройки к тому, что можно сделать простым bash? С другой стороны, ни разу серьёзно им не пользовался, скорее всего потому и не понимаю.
                                                              0
                                                              Это где так мощщно используется docker? В какой компании?
                                                                +1
                                                                Одна зарубежная конторка, занимаются всякими припаркам для волос, решили попробовать в айти и заняться екоммерц-системами. Вот и придумали такую вещь — запускать приложения клиентов (интернет-магазины, которые на жаве) в контейнерах. По мне, так не мощно, а глупо. Ресурсов всё съедает килотонны, в поддержке весьма тяжеловато, куча костылей и огородов. На мой взгляд простенький продукт на php сэкономил бы им сотни тысяч.
                                                                +2
                                                                Не путайте docker и swarm. Ввместо второго в приличном обществе принято использовать кубернетес
                                                                  0
                                                                  Когда я работал над этим проектом, k8s был ещё в личиночном состоянии.
                                                                  PS: а почему не путать? swarm — нативный для докера оркестратор, и весьма неплохой в плане удобства, на мой взгляд. Легковесный, быстрый, без кучи гембеля как в том же k8s. Вот то что разрабы докера на него по сути забили, оставив жить с кучей багов, это конечно печально. А в чистом докере без оркестратора я уже смысла не вижу. Только для сборки образов и локального запуска на одном хосте? Ну такое, сомнительное применение, можно и lxc обойтись.
                                                                    0
                                                                    То что нативный это хорошо, но вы писали что докер бажный, но приводили примеры багов сварма. Это и смутило.
                                                                      0
                                                                      Ну почему сворма-то? Ключевая проблема была в том, что докер не удалил контейнеры как надо, что-то ему помешало (по факту в списке запущенных их не было, но они были запущены, выяснить можно было либо через network inspect, либо через image inspect; когда и тех и других — сотни, задачка не из самых интересных). Запуск-удаление контейнеров вроде как относится именно к dockerd. Уж разбираться что именно к такому привело, было некогда, пардон. Всё остальное уже шло как последствия.
                                                                      ps: и чем swarm mode не часть докера? Вы не путаете со старым swarm, который как и кубернейтс, крутился в своих контейнерах?
                                                                  0
                                                                  Это клауд был или какой-то ДЦ?
                                                                    0
                                                                    Не, просто кривая архитектура такая, так вышло ¯\_(ツ)_/¯
                                                                  –10
                                                                  Делал контейнер из Windows приложения и Wine. Такая себе штука этот ваш Docker. Мне лично показалось что проще было бы все поставить на целевой машине чем тащить в Docker.
                                                                  +9
                                                                  Говорить, что Docker говно — все равно, что говорить: «отвертка — говно, так как хреново забивает гвозди!»

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

                                                                  Из моего опыта — работа в студии… за день можно поработать с 3-мя проектами, которые используют разные базы, разные версии PHP, где-то Апач, где-то Нжинкс… я хз что бы делали без докера и докер-композера… а так: down/cahnge_project/up — и окружение полностью изменилось…
                                                                    +6
                                                                    А никто и не говорит что в таких сценариях он говно. Для разработки это удобная штука. Неудобным он становится в большом продакшене.
                                                                      0
                                                                      На проде у него своя ниша. Это микросервисы плюс k8s, nomad и т.п.
                                                                      Если тянуть на прод через docker-compose будет очень быстрое и простое первоначальное разворачивание приложения. И большие проблемы с деплоями.

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

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

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

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

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


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

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

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

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

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


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

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


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

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

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

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


                                                                                    Вот, оно!)))
                                                                                      0
                                                                                      Ну если очень хочется сделать проект на k8s, но у вас только блог на 50 человек? Это отличный первоначальный опыт, кстати :)
                                                                                        0
                                                                                        Дык, попробовал уже, потыркал! Прикольная штука.

                                                                                        Но именно идея «заюзать по-взрослому что-то минимально продоподобное» лично для меня утыкается уже в вопрос, что на такие траты я могу пойти при условии хотя бы теоретической «когда-нибудь-окупаемости». Оно не совсем копеечным решением выходит.
                                                                                          0
                                                                                          В это упираются абсолютно все проекты, как по мне.
                                                                          +2
                                                                          • для того чтобы мое приложение работало, нужен сам docker на сервере. А зачем мне это, если мои приложения работают на jre или на nodejs и окружение для них уже есть на сервере?

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


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

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


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

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


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

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


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

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


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

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

                                                                            +3
                                                                            doсker отличнейший инструмент, просто
                                                                            А. надо уметь его готовить
                                                                            В. не запихивать его везде где можно, только потому, что могу.
                                                                            Недавно (тройку месяцев назад), я поработал с DevOps командой, почти каждый участник которой, негативно относился к docker

                                                                            а нужно ли всех слушать? у нас вот сидит тут девопс, который впервые в жизни графану у меня на мониторе увидел)
                                                                              0
                                                                              FreeBSD, Jail и Ansible — это все что нужно.
                                                                                +1

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

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


                                                                                  а по мне так Nix Package Manager решает все эти проблемы без всяких контейнеров
                                                                                    0
                                                                                    Для меня как-то странно сравнивать docker и ansible. Это как утверждать что вилка отстой и надо пользоваться ложкой. А если ansible билдит, запускает и скейлит докер контейнеры… Да не, глупости…
                                                                                      +13
                                                                                      Просто оставлю тут пару цитат из статьи выше:
                                                                                      В качестве виртуальной машины на локали можно использовать тот же Alpine

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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


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

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


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

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


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

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


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

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

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

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

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

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

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

                                                                                                  Впн я давно использовал в компаниях где были админы и настраивали его сами. Про ssh туннели я не знал, да, но как то пользовался пробросом портов в `kubectl`, думал это специфичная штука кубера
                                                                                                    +3
                                                                                                    Тоже самое использует Ansible, только с помощью него можно сделать что угодно и где угодно (создать директории, спулить образы, тп) + запустить docker контейнеры.


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

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

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

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

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

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

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

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

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

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


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

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


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

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