Комментарии 310
docker бажный и в проде запускать его не будем
Но используют ansible, который бажный раз в 50 больше, чем сам докер когда либо был. Самое классное, что я помню, это рестарт докер конейнера через ansible ломал его навсегда, так как какого-то лешего он пытался его пересоздать, не мог и падал. А еще есть "прекрасный" check режимы, который практически никогда не проходит до конца, потому что идеологически настолько плох, насколько это возможно и не учитывает результаты предыдущих команд.
Ansible классная штука, но мне кажется, что у людей очень странный компас "забагованности".
не навязывайте использование docker разработчикам
Я бы еще предложил не навязывать разработчикам всякие package.json. Пусть кое-как у него работает, потом он этот код пушит в мастер и кто-то другой пусть бегает с пухлой головой с мыслями о том "а какие же пакеты каких версий нужны?".
Эти компании используют docker на своих серверах где запускается CI процесс. Вопрос — зачем нужно собирать проекты в docker контейнере на своих серверах? Почему просто не подготовить окружение для сборки, например написать Ansible плейбук который будет ставить нужные версии nodejs, php, jdk, копировать ssh ключи и пр. на сервер, в котором будет происходить сборка?
Как там вам собирать по 5-10 разных проектов с разными зависимостями и бинарными либами. Ставите максимум из этих либ на сервер или под каждый проект новый сервер? Или ждете, пока все накатится каждый раз с нуля?
Но используют ansible, который бажный раз в 50 больше, чем сам докер когда либо был
Ansible не тащит какой либо экосистемы на сервер, ему нужен только ssh и python интерпретатор. Бага в Ansible может привести только к тому что на серваке что то не запустится во время проигрывания плейбука.
Как баги в Ansible пересекаются с багами в docker — не пойму
Я бы еще предложил не навязывать разработчикам всякие package.json.
Может вы имели ввиду package-lock.json? Если да то package-lock.json необходим в nodejs так как ссылается на точные коммиты кода.
Как там вам собирать по 5-10 разных проектов с разными зависимостями и бинарными либами
Соболезную вам в таком случае, ни разу не поддерживал 5 — 10 проектов одновременно да и тем более с разным стеком технологий
Ansible не тащит какой либо экосистемы на сервер, ему нужен только ssh и python интерпретатор. Бага в Ansible может привести только к тому что на серваке что то не запустится во время проигрывания плейбука.
Бага в ansible может привести к тому, что у вас сервер поломается, если что. Причем в некоторых случаях прямо совсем. И самое страшное в ansible, что у вас нет никакой возможности проверить, что реально произойдет с вашим сервером в результате выполнение скрипта, кроме как запустить его.
Как баги в Ansible пересекаются с багами в docker — не пойму
А причем тут докер? Конкретно в этом случае, ansible просто передавал ему две команды, сначала убивал старый контейнер, а потом пытался запустить новый, но ему не хватало данных и плейбук падал.
Соболезную вам в таком случае, ни разу не поддерживал 5 — 10 проектов одновременно да и тем более с разным стеком технологий
В том то и фокус, что таская окружение при помощи Docker вместе с проектом я не страдаю. Причем проекты не то, что бы разные, они все на python, но для них нужны разные версии библиотек. И вместо увлекательной содомии с venv у меня все в контейнерах с кешированием.
А вы пробовали или нагуглили?
Даже если проигнорировать то, что `check` режим это всегда «второсортный гражданин» в модулях ansible, особенно свежих, он банально сломал идеологически, так как в этом режиме предыдущие команды никак не влияют на следующие. Вы не можете в чек режиме создать пользователя в бд и потом выдать ему права, или скопировать docker-compose.yml, а потом запустить его, вторая команда упадет с очевидной ошибкой в духе «нет такого пользователя» или «нет такого docker-compose.yml файла».
Следовательно, любая цепочка команд всегда будет сбоить в check режиме, что делает это практически бесполезным для проверки того, что реально будет выполнено на сервере.
Даже если проигнорировать то, что `check` режим это всегда «второсортный гражданин» в модулях ansible, особенно свежих, он банально сломал идеологически, так как в этом режиме предыдущие команды никак не влияют на следующие. Вы не можете в чек режиме создать пользователя в бд и потом выдать ему права, или скопировать docker-compose.yml, а потом запустить его, вторая команда упадет с очевидной ошибкой в духе «нет такого пользователя» или «нет такого docker-compose.yml файла».
Следовательно, любая цепочка команд всегда будет сбоить в check режиме, что делает это практически бесполезным для проверки того, что реально будет выполнено на сервере.
А Молекула?
Молекула — это тестирование и опять же, она запускает скрипты и потом смотрит, что то, что произошло, соответствует тому, что было описано с проверочной спецификации.
Ну, из этого всего мы делаем очень простой вывод:
* для первоначальной раскатки софта (с нуля) — ансибл практически идеальный инструмент. Т.к. именно этот сценарий все и используют и именно он требует максимальной степени автоматизации. Молекула проверяет именно его.
* Для остальных сценариев — поддержание инфраструктуры в определенном состоянии — ансибл можно использовать, но есть куча подводных камней. Например, особую боль могут доставить миграции между разными версиями одной и той же роли.
* Автоматизация рутинных задач на ансибле (бекап баз, например) — вообще странное занятие, ну, ок, можно и так…
* для первоначальной раскатки софта (с нуля) — ансибл практически идеальный инструмент. Т.к. именно этот сценарий все и используют и именно он требует максимальной степени автоматизации. Молекула проверяет именно его.
* Для остальных сценариев — поддержание инфраструктуры в определенном состоянии — ансибл можно использовать, но есть куча подводных камней. Например, особую боль могут доставить миграции между разными версиями одной и той же роли.
* Автоматизация рутинных задач на ансибле (бекап баз, например) — вообще странное занятие, ну, ок, можно и так…
Никогда, никогда не переобувайте тапки на ходу. Выбрали без докера, так и живите, пока не поймёте, что он будет решать проблемы вашего проекта. И да, в 99% случаев, если ваш сервис — это 1 jar, вам не нужен докер.
А мне-то зачем отвечаете? Я только затронул один аспект — ансибл. Про докер я тут ничего не писал )
А кто переобувает?
есть одна вещь, которую докер реально круто решает — это пайплайны сборки и разворачивание тестовых стендов. Ну, и как рантайм для куба (но это еще бабка надвое сказала), но это не потому что докер сам по себе хорош.
Никогда, никогда не переобувайте тапки на ходу
А кто переобувает?
Выбрали без докера, так и живите, пока не поймёте, что он будет решать проблемы вашего проекта.
есть одна вещь, которую докер реально круто решает — это пайплайны сборки и разворачивание тестовых стендов. Ну, и как рантайм для куба (но это еще бабка надвое сказала), но это не потому что докер сам по себе хорош.
Ansible-плейбуки прекрасно тестируются в виртуальных машинах (vagrant/virtualbox), либо в докере. Значимые изменения в скриптах — повод прогнать всё локально. Обновили ansible — прогнали плейбук, поправили deprecated warnings. Проверили ещё раз и отправили на прод.
Ну, да. Вот только это значит, что у вас должны быть плейбуки полностью покрыты тестами. Если у вас это так, я только за вас рад и могу послать вам лучи добра. Но довольно часто это не так, к сожалению.
Еще не стоит забывать, что обычно исправленные скрипты накатываются на уже рабочие сервера, в отличии от обычного тестирования скриптов, которое каждый раз создает машину с нуля. И как побороть эту проблему я не знаю, разве что клонировать прод машину и прогонять сначала на клоне.
На всякий случай добавлю, что я не говорю, что ansible плохой, не смотря на все свои минусы, он все равно в 1000 раз лучше, чем ходить на сервера и править ручками.
Еще не стоит забывать, что обычно исправленные скрипты накатываются на уже рабочие сервера, в отличии от обычного тестирования скриптов, которое каждый раз создает машину с нуля. И как побороть эту проблему я не знаю, разве что клонировать прод машину и прогонять сначала на клоне.
На всякий случай добавлю, что я не говорю, что ansible плохой, не смотря на все свои минусы, он все равно в 1000 раз лучше, чем ходить на сервера и править ручками.
Абсолютно верно говорите — проблема ансибла именно в том, что он не всегда учитывает текущее состояние системы. Я уж не говорю о том, что в плейбуках могут быть весьма странные конструкции (типа «удалить файл», а потом «создать его заново» — в целом это идемпотентно, но может и не быть в зависимости от каких-либо стартовых условий)
Ansible-плейбуки прекрасно тестируются… в докере.
Ну, т.е., это все-таки достаточно разные инструменты, которые могут дополнять друг друга, но никак не взаимозаменять? Я же правильно понимаю?
Просто тогда изначальный посыл статьи «докер не нужен, используйте ансибл» кажется достаточно спорным…
Просто тогда изначальный посыл статьи «докер не нужен, используйте ансибл» кажется достаточно спорным…
Тезис статьи неверный. Дихотомия неверная. Не docker vs ansible. А скорее иммутабельная инфраструктура с заранее подготовленными образами ВМ vs контейнеры. Образы ВМ, которые подготавливаются packer, как раз решают проблему инкапсуляции зависимостей и версионирования образов. Плюс возможность создавать виртуальные машины по запросу… Ну, вы поняли.
Ну, т.е., это все-таки достаточно разные инструменты, которые могут дополнять друг друга, но никак не взаимозаменять? Я же правильно понимаю?
Да
иммутабельная инфраструктура с заранее подготовленными образами ВМ vs контейнеры.
Ну вот тут с вами копья ломать не буду. Плюсы-минусы каждого подхода более-менее очевидны. «С высоты птичьего полета» — задача решается примерно одна и та же, только ВМ дают чувствительно больший оверхед по ресурсам, в то время как контейнеры дают гораздо более низкий (качественно) уровень изоляции. Тут уж «ситуативно». Надежно + дорого vs дешево + сердито.
только ВМ дают чувствительно больший оверхед по ресурсам, в то время как контейнеры дают гораздо более низкий (качественно) уровень изоляции.
Именно! Все верно говорите. Но пайплайн раскатки виртуальных машин все равно должен существовать — хотя бы для подготовки инфраструктуры под докеры. Все равно все упирается в менеджмент вычислительных ресурсов (что запускаем? где? как?)
Конечно, их нельзя сравнивать. Оба инструмента могут прекрасно работать вместе.
Как пример совместного использования, который вполне может существовать и будет далеко не самым плохим решением:
— с помощью ansible разворачивается инфраструктура для разработки — git-сервер, сервер для тестов с докером, настраивается окружение для запуска докера на продакшн-серверах
— в ci-пайплайне проект собирается в докер-образ, тестируется
— с помощью ansible, запущенного внутри докер-контейнера (как часть процесса ci/cd), docker-образ выкатывается в продакшн.
Как пример совместного использования, который вполне может существовать и будет далеко не самым плохим решением:
— с помощью ansible разворачивается инфраструктура для разработки — git-сервер, сервер для тестов с докером, настраивается окружение для запуска докера на продакшн-серверах
— в ci-пайплайне проект собирается в докер-образ, тестируется
— с помощью ansible, запущенного внутри докер-контейнера (как часть процесса ci/cd), docker-образ выкатывается в продакшн.
это удобная вещь, гарантирующая кроссплатформенность
Очень опасное заблуждение. Особенно если проект разработанный под linux пытаются запутить на windows.
При разработке приложений например если Вам работать с проектами на разных версиях php и mysql по простоте и удобству работы docker + docker-compose проще и экономней по ресурсам, чем, например, виртуальные машины, vagrant и т.п. Если конечно Вы не ас по какой-то определенной технологии. Уровень вхождения достаточно низкий по сравнению с другими технологиями.
Что касается прода — согласен. У докера своя ниша — это микросервисы, но только если докер используется совместно с чем-то вроде k8s, nomad и т.п.
Для микросервисов — докер не нужен. Неудивительно, что редхат проталкивает cri-o, а как альтернатива есть ещё rkt…
rkt закапывать пора вроде
https://github.com/rkt/rkt/graphs/contributors
https://github.com/rkt/rkt/issues/3946
У меня от докера двойственное ощущение. Вроде хорошая штука, но если увлекаться слишком много сил забирает если испольвоать его для деплоймента. Для себя нашел пока единственное применение, которое экономит мне силы — как легковесную виртуальную машину, чтобы иметь на рабочем месте разработчика такое же окружение, как и на продакшен.
Внедряем докер на продакшен, но как-то очень уж много трудозатрат.
Внедряем докер на продакшен, но как-то очень уж много трудозатрат.
Внедрять его — вообще задача неблагодарная. А вот если писать с нуля, то вполне себе удобно.
Я, по своему опыту общения, против идеи использования Докера в продакшене(он по своей сути только для микросервисов, но тут одного Докера мало — нужен еще Кибернетис, но Кибернетис еще слишком молодой и проблемный). Но вот есть пример:
Пришли нам продавать CreenPlum(распаралеленная БД) с накрученными плюшками. Я говорю «дайте Докер чтоб я не мучился ставить выводок серверов неизвестного продукта» а в ответ тишина… в итоге конечно поставил к концу дня некое тестовое подобие, но исплевался. Директору был ответ «документации у них нет в открытом доступе(что правда), использование ресурсоемко(что правда)». Как думаете — это повлияет на продажи?
Можно же всегда сделать что-то типа: github.com/CrazyDoc/docker-swarm или github.com/CrazyDoc/infrastructure-beanstalk-test — когда у тебя через 15мин готовый продукт для теста.
Пришли нам продавать CreenPlum(распаралеленная БД) с накрученными плюшками. Я говорю «дайте Докер чтоб я не мучился ставить выводок серверов неизвестного продукта» а в ответ тишина… в итоге конечно поставил к концу дня некое тестовое подобие, но исплевался. Директору был ответ «документации у них нет в открытом доступе(что правда), использование ресурсоемко(что правда)». Как думаете — это повлияет на продажи?
Можно же всегда сделать что-то типа: github.com/CrazyDoc/docker-swarm или github.com/CrazyDoc/infrastructure-beanstalk-test — когда у тебя через 15мин готовый продукт для теста.
для того чтобы мое приложение работало, нужен сам docker на сервереНет, докер нужен только если вы хотите им пользоваться, имхо странный пункт.
если я хочу запустить свой (приватный) локально собранный образ на удаленном сервере, то мне нужен свой docker репозиторийНет не нужен, можно просто скопировать образ и запустить (docker save -> docker load).
docker-compose. Он нужен только для запуска контейнеров. И всеНе хотите не используйте, есть и другие способы (тут даже можно спросить — а при чем тут докер?).
при работе в команде, в большинстве своем люди пишут Dockerfile очень кривоЭто проблема докера? Докер вам просто дает некоторые возможности с некоторыми ограничениями, вы уже решаете пользоваться ими или нет, зачем жаловаться на то что вам дают выбор.
постоянно преследуют мысли о поднятии в docker всего и вся
всегда возникает вопрос про персистенцию данных контейнера
Жаль, что не всё работает в контейнерахНапример?
> Это проблема докера? Докер вам просто дает некоторые возможности с некоторыми ограничениями, вы уже решаете пользоваться ими или нет, зачем жаловаться на то что вам дают выбор.
Ну как, это проблема внедрения докера.
А жалоба не на возможность, а на возрастающий порог входа.
Есть возможности опциональные (я могу использовать докер, а могу про него не знать), а есть селективные (если внедрен докер, то мне надо как-то уметь Dockerfile).
Ну как, это проблема внедрения докера.
А жалоба не на возможность, а на возрастающий порог входа.
Есть возможности опциональные (я могу использовать докер, а могу про него не знать), а есть селективные (если внедрен докер, то мне надо как-то уметь Dockerfile).
Есть возможности опциональные (я могу использовать докер, а могу про него не знать), а есть селективные (если внедрен докер, то мне надо как-то уметь Dockerfile).
Повторюсь, что есть 100500 способов получить образ докера, не применяя Dockerfile.
Просто этот метод (через Dockerfile) считается самым простым и базовым. Не более того
То есть вы предлагаете внедрять докер не ознакомившись с простым и базовым способом, и обещаете, что я с ним не столкнусь?
Ну, допустим. Тогда мне надо учить другой способ, сложный и почему-то не базовый. Ну, мне не полегчало
Ну, допустим. Тогда мне надо учить другой способ, сложный и почему-то не базовый. Ну, мне не полегчало
В общем случае — он не самый простой и не самый лучший.
Например, возможна ситуация, когда Вам нужно собирать образ, а вариантов кроме как в докере запускаться нет — будете городить docker-in-docker с необходимостью привилегированного запуска? Или возьмете kaniko или buildah, которые лишены соответствующей проблемы? Да еще и быстрее?
Я не говорю, что Dockerfile и сборку докером докер-образа нужно в принципе отрицать — действительно нужно знать, что такой механизм есть, но что он абсолют… Ну, не так это. Не говоря уже о том, что появилось 100500 замен докеру. Тот же cri-o, containerd, rкt и пр… Главное, что формат образа стандартизован (OCI).
Например, возможна ситуация, когда Вам нужно собирать образ, а вариантов кроме как в докере запускаться нет — будете городить docker-in-docker с необходимостью привилегированного запуска? Или возьмете kaniko или buildah, которые лишены соответствующей проблемы? Да еще и быстрее?
Я не говорю, что Dockerfile и сборку докером докер-образа нужно в принципе отрицать — действительно нужно знать, что такой механизм есть, но что он абсолют… Ну, не так это. Не говоря уже о том, что появилось 100500 замен докеру. Тот же cri-o, containerd, rкt и пр… Главное, что формат образа стандартизован (OCI).
если я хочу запустить свой (приватный) локально собранный образ на удаленном сервере, то мне нужен свой docker репозиторий
Если чисто поиграться, то не нужен. Ничто вам не мешает сделать docker build напрямую на удаленном сервере и запускать сбилденный образ. Более того, я так пол года в продакшене жил. Все ок, разве что трафик туда-сюда гоняется нешуточный и в лесу деплой не сделать.
Это самая худшая из практик. Сами же верно говорите, что лишний трафик. А ещё лишняя нагрузка на процессор и диск. Да и система засоряется временными докер образами (тем более, если процесс сборки по какой-то причине упадет).
Есть ещё одно очень важное соображение. Вы не гарантируете, что сборка локально и удаленно совпадет. Потому что как минимум — никто не фиксирует версии базовых образов в докерфайлах. И, да, я не просто про метку или тег говорю, которые всегда могут быть перезаписаны, а именно sha сумму образа. Сколько образов именно по ней ссылаются на базовый образ?
Есть ещё одно очень важное соображение. Вы не гарантируете, что сборка локально и удаленно совпадет. Потому что как минимум — никто не фиксирует версии базовых образов в докерфайлах. И, да, я не просто про метку или тег говорю, которые всегда могут быть перезаписаны, а именно sha сумму образа. Сколько образов именно по ней ссылаются на базовый образ?
По мне так это обычная практика. Ничего там не засорялось, по крайней мере бесконтрольно.
Да, на сервере должны быть определенные ресурсы для сборки. В моем случае это были не большие ресурсы.
На счет гарантий — все точно так же как при сборке локально или через CI/CD. По sha образы никогда не фиксируют просто потому что это маразм. Никто просто так не перезаписывает теги (кроме latest конечно).
Да, на сервере должны быть определенные ресурсы для сборки. В моем случае это были не большие ресурсы.
На счет гарантий — все точно так же как при сборке локально или через CI/CD. По sha образы никогда не фиксируют просто потому что это маразм. Никто просто так не перезаписывает теги (кроме latest конечно).
Никто просто так не перезаписывает теги (кроме latest конечно).
Объясните это безопасникам. И я с ними, кстати, согласен. Ни один из по-простому доступных докер репозиториев не умеет иммутабельные теги. К сожалению. Это можно заимплементировать на уровне прав доступа + в пайплайнах сборки, но это костыли.
Просто надо понять, что существует как минимум два типа тегов — постоянные (релизы) и перезаписываемые (latest, master, dev и по названиям веток). Почему-то при проектировании докера как системы это не учли и имеем то, что имеем.
Повторюсь, что нет единой конвенции и даже если бы она была, то многие ее нарушали бы (пример — hub.docker.com/_/golang — под 1.11-stretch ВСЕГДА будет последний билд, а не какой-то определенный)
Я не спорю с тем, что теги могут быть перезаписаны. Но не пойму что вас удивляет в 1.11-stretch. Да, там всегда будет последний билд и… это так и задумано, по крайней мере в моем понимании.
Если вам это не подходит, ничто не мешает собрать свои базовые образы и использовать их, там все теги полностью под контролем.
Если вам это не подходит, ничто не мешает собрать свои базовые образы и использовать их, там все теги полностью под контролем.
Когда любую технологию (кросс-платформенность, докер, микросервисы, ...) обьявляют «общей теорией всего» — тогда начинаются проблемы. Докер хорош для ситуаций, когда вам нужно поднять разные окружения на одной машине или просто запустить что-то требующее нудной и нетривиальной компиляции и конфигурации (OpenCV, TensorFlow — отличные примеры). Docker-compose, соответственно — если таких компонентов у вас несколько.
А когда все устаканилось, есть официальные CI/CD конвееры и окружения для тестов — можно хоть Linux from scratch собирать, Докер здесь только одна из возможностей.
А когда все устаканилось, есть официальные CI/CD конвееры и окружения для тестов — можно хоть Linux from scratch собирать, Докер здесь только одна из возможностей.
Докер популярен потому, что программисты в 99% случаев не имеют админской квалификации в Linux.
По той же причине популярен Windows.
С точки зрения прогера-админа, docker «классическое нинужно», тем более он не первый, их как грязи было, есть и будет. Всяких разных вариаций, начиная древними LXC, продолжая всякими snap-пакетами и виндузообразными чудо-дистрибами где все проги ставятся в отдельный каталог.
Но с точки зрения бизнеса — «классическое нинужно» это прогер-админ. К счастью, рынок большой, помимо хипстоты, есть и более консервативные конторы или хотя бы отделы.
То же самое относится и к кубер vs нормальная виртуализиция.
По секрету скажу, есть места, где никакая виртуализация не нужна.
По той же причине популярен Windows.
С точки зрения прогера-админа, docker «классическое нинужно», тем более он не первый, их как грязи было, есть и будет. Всяких разных вариаций, начиная древними LXC, продолжая всякими snap-пакетами и виндузообразными чудо-дистрибами где все проги ставятся в отдельный каталог.
Но с точки зрения бизнеса — «классическое нинужно» это прогер-админ. К счастью, рынок большой, помимо хипстоты, есть и более консервативные конторы или хотя бы отделы.
То же самое относится и к кубер vs нормальная виртуализиция.
По секрету скажу, есть места, где никакая виртуализация не нужна.
Что-то вы совсем не о том.
100% из того, что программист сможет настроить в Docker, он сможет настроить и «напрямую», т.к. никакой разницы там нет. Использование готовых образов — это как apt-get. Вы же им пользуетесь, а не компилируете исходники каждый раз?
Докер популярен, потому что он просто работает. Не засоряет систему, дает контроль над ресурсами и ситуацией. К тому же образы очень легко переносимы между серверам и, иногда, даже между платформами.
100% из того, что программист сможет настроить в Docker, он сможет настроить и «напрямую», т.к. никакой разницы там нет. Использование готовых образов — это как apt-get. Вы же им пользуетесь, а не компилируете исходники каждый раз?
Докер популярен, потому что он просто работает. Не засоряет систему, дает контроль над ресурсами и ситуацией. К тому же образы очень легко переносимы между серверам и, иногда, даже между платформами.
>особенно классические методы через apt-get, полсотней сырых реп, кривыми мейнтейнерами, игнорированием пакетных менеджеров дистрибутива и программного языка друг-друга и так далее
Откуда программистикам знать, что у нормального админа есть RHEL/CENTOS и есть «весь остальной шлак» (навроде бубунточки с сырыми репами и кривыми мэинтейнерами).
Если у ПО нет штатного YUM-репо и его нет в EPEL, это повод поискать более вменяемое ПО.
>Не засоряет систему, дает контроль над ресурсами и ситуацией
Вот и понабежали «программисты без админской квалификации в Linux». фаервол докер похабит, с lib-ами никакими не линкуется, в итоге внутри контейнера в 99.9% случаев дырка от бублика. Кстати, докерофилы не в курсе, что cgroups через который докер ограничивает, независимая подсистема linux, которую никто не запрещает использовать и без докера?
На stackoverflow в вопросе «а что монго не стартует, на права какие-то ругается» 80% советует «да запусти из под рута, я так сделал и всё заработало», чуть более одаренные пишут про chown, а где-то в самом конце одинокий ответ про selinux, и то в виде «selinux отключается вот так».
Вот для таких вот докер и придумали, чтобы они не перенапрягли головушку. Правда потом почитаешь новости, там база без авторизации, сям ключи и пароли в репе, на третьем сервере крипту майнят и тд и тп.
p.s. Все платформы/языки разные. Я уже понял, что большинство из них кривые и там с докером действительно удобнее жить. Плохо то, что его впаривают всем, в том числе в java-стек, хотя там родных инструментов полно, которые постарше докера будут лет так на 10. Это и есть хипстерство и попытки подзаработать на свеженьком.
Откуда программистикам знать, что у нормального админа есть RHEL/CENTOS и есть «весь остальной шлак» (навроде бубунточки с сырыми репами и кривыми мэинтейнерами).
Если у ПО нет штатного YUM-репо и его нет в EPEL, это повод поискать более вменяемое ПО.
>Не засоряет систему, дает контроль над ресурсами и ситуацией
Вот и понабежали «программисты без админской квалификации в Linux». фаервол докер похабит, с lib-ами никакими не линкуется, в итоге внутри контейнера в 99.9% случаев дырка от бублика. Кстати, докерофилы не в курсе, что cgroups через который докер ограничивает, независимая подсистема linux, которую никто не запрещает использовать и без докера?
На stackoverflow в вопросе «а что монго не стартует, на права какие-то ругается» 80% советует «да запусти из под рута, я так сделал и всё заработало», чуть более одаренные пишут про chown, а где-то в самом конце одинокий ответ про selinux, и то в виде «selinux отключается вот так».
Вот для таких вот докер и придумали, чтобы они не перенапрягли головушку. Правда потом почитаешь новости, там база без авторизации, сям ключи и пароли в репе, на третьем сервере крипту майнят и тд и тп.
p.s. Все платформы/языки разные. Я уже понял, что большинство из них кривые и там с докером действительно удобнее жить. Плохо то, что его впаривают всем, в том числе в java-стек, хотя там родных инструментов полно, которые постарше докера будут лет так на 10. Это и есть хипстерство и попытки подзаработать на свеженьком.
Давайте будем честными. Профессиональные сисадмины, которые знают свою систему вдоль и поперек, само-собой, лучше справятся с ее настройкой, чем программист с Docker.
Но! Это прям чудо сисадмин. Он следит за каждым пакетиком, подбирает ПО, может поставить 10 версий разных БД, две нестабильные и одну из другой ОС. А когда ему надоест или он уйдет, наступит хаос. Никто не знает как он это делал, потому что нет стандартов, а если какие-то и есть, то фиг их кто соблюдает. Это человеческий фактор.
«повод поискать более вменяемое ПО» — это утопия. Мне нужна именно такая версия именно вот этого ПО и через 10 минут. Кстати, сейчас три часа ночи. Справитесь?
А завтра в 4 утра я выкатываю обновление. Новая версия несовместима со старой и в случае чего нужно будет все откатить за 2 минуты, не больше. Справитесь? Молодец. А если вы завтра заболеете, мне что делать? Правильно: kubectl rollout
Да, Докер не идеален, но он крут, с этим сложно спорить.
P.S. Отсортируйте ответы SO по полезности и будет вам счастье.
Но! Это прям чудо сисадмин. Он следит за каждым пакетиком, подбирает ПО, может поставить 10 версий разных БД, две нестабильные и одну из другой ОС. А когда ему надоест или он уйдет, наступит хаос. Никто не знает как он это делал, потому что нет стандартов, а если какие-то и есть, то фиг их кто соблюдает. Это человеческий фактор.
«повод поискать более вменяемое ПО» — это утопия. Мне нужна именно такая версия именно вот этого ПО и через 10 минут. Кстати, сейчас три часа ночи. Справитесь?
А завтра в 4 утра я выкатываю обновление. Новая версия несовместима со старой и в случае чего нужно будет все откатить за 2 минуты, не больше. Справитесь? Молодец. А если вы завтра заболеете, мне что делать? Правильно: kubectl rollout
Да, Докер не идеален, но он крут, с этим сложно спорить.
P.S. Отсортируйте ответы SO по полезности и будет вам счастье.
>Новая версия несовместима со старой и в случае чего нужно будет все откатить за 2 минуты, не больше. Правильно: kubectl rollout
Самый главный минус докера это фанбои докера с очень узким кругозором.
Уверен, что на любой популярной платформе откат легко делается БЕЗ докера, причём множеством способов. И за 2 сек при желании, а не 2 минуты.
Ну и самое главное, что-то там в 4 утра накатывать и откатывать? Галерщик кровавого ынтырпрайза?
>Он следит за каждым пакетиком, подбирает ПО, может поставить 10 версий разных БД, две нестабильные и одну из другой ОС. А когда ему надоест или он уйдет
Это просто админ, никакой не супер. А ещё в нормальных конторах есть безопасник. Ибо практика показывает, что если девляпусов не контролировать, информационной безопасности вообще не будет.
Самый главный минус докера это фанбои докера с очень узким кругозором.
Уверен, что на любой популярной платформе откат легко делается БЕЗ докера, причём множеством способов. И за 2 сек при желании, а не 2 минуты.
Ну и самое главное, что-то там в 4 утра накатывать и откатывать? Галерщик кровавого ынтырпрайза?
>Он следит за каждым пакетиком, подбирает ПО, может поставить 10 версий разных БД, две нестабильные и одну из другой ОС. А когда ему надоест или он уйдет
Это просто админ, никакой не супер. А ещё в нормальных конторах есть безопасник. Ибо практика показывает, что если девляпусов не контролировать, информационной безопасности вообще не будет.
Я не спорю что это делается (хотя и не за две минуты). Это неудобно и требует дополнительного человека, а тут вам удобный инструмент.
>Это неудобно и требует дополнительного человека
Неудобно это Кубер, который чтобы качественно развернуть в большом проде уж точно нужен либо подрядчик, либо неглупый админ (уж намного выше уровнем, чем админ на классические варианты).
>а тут вам удобный инструмент
Фанбои докера не в курсах, что Кубер это сборная солянка из совершенно разных «удобных инструментов», которым лет намного больше, чем докеру и куберу. И никто не мешает делать HA и FO на например haproxy, у которого конфиг 5 строчек. По сравнению с ним докер и кубер жуткие монстры. И не надо спорить.
Неудобно это Кубер, который чтобы качественно развернуть в большом проде уж точно нужен либо подрядчик, либо неглупый админ (уж намного выше уровнем, чем админ на классические варианты).
>а тут вам удобный инструмент
Фанбои докера не в курсах, что Кубер это сборная солянка из совершенно разных «удобных инструментов», которым лет намного больше, чем докеру и куберу. И никто не мешает делать HA и FO на например haproxy, у которого конфиг 5 строчек. По сравнению с ним докер и кубер жуткие монстры. И не надо спорить.
И никто не мешает делать HA и FO на например haproxy
Окей вы в 5 строчек сделали ингресс (конечно, нет, но предположим, что да). Еще надо service-discovery, deployments/rolling update, workload scheduling/autoscaling, access-control, ci/cd и у вас 10 команд, которые пишут на Go, Python, Elixir, Ruby, JS, и деплоят по 10 раз в день в 3 DC. Сколько вам еще строчек конфига хапрокси нужно чтоб эту задачу решить?
Смешно мне с этого натягивания совы на глобус. Начали с голого доцкера в днищенских конторах которым на одного средненького одмина денег жалко, сейчас понеслось — 10 команд, зоопарк стеков и кубер.
Практика показывает, что можно успешные проекты на убогом php делать (VK, да FB). ХЗ есть ли у них сейчас кубер, даже если есть сейчас, то сколько лет без него жили и не жужали? Все эти вопли про незаменимость доцкера просто смердят смузи. ;)
Практика показывает, что можно успешные проекты на убогом php делать (VK, да FB). ХЗ есть ли у них сейчас кубер, даже если есть сейчас, то сколько лет без него жили и не жужали? Все эти вопли про незаменимость доцкера просто смердят смузи. ;)
Начали с голого доцкера
Я в этой ветке оставил ровно один коментарий (помимо этого), ничего про «голый доцкер» не писал. Ответил на ваш «HA в 5 строк конфига». Так-то, в «днищенских конторах которым на одного средненького одмина денег жалко» и HA нафиг не уперся. А все эти рассуждения про 5 строчек и про то, что «VK и FB вон вообще на PHP пишут» говорят о том, что вы, скорее всего, большие проекты только на картинках видели.
>А все эти рассуждения «VK и FB вон вообще на PHP пишут» говорят о том, что вы, скорее всего, большие проекты только на картинках видели.
Рассуждения в духе «ты не гомосек, потому что у тебя нормального мужика не было». Ну или хотя бы насяльника архитектора-индуса, который развёл зоопарк и пытается с ним взлететь.
Зачем это всё, когда есть нормальные фулстек платформы, как например жабка?
Разработка например linux kernel у фанбоев доцкера относится к маленьким проектам? ))) Они там и без CI хипсторского как-то живут. Наверное потому что о безопасности немного думают и за модный нынче подход «быстро поднятое упавшим не считается» там обычно Линус ломает ноги.
Рассуждения в духе «ты не гомосек, потому что у тебя нормального мужика не было». Ну или хотя бы насяльника архитектора-индуса, который развёл зоопарк и пытается с ним взлететь.
Зачем это всё, когда есть нормальные фулстек платформы, как например жабка?
Разработка например linux kernel у фанбоев доцкера относится к маленьким проектам? ))) Они там и без CI хипсторского как-то живут. Наверное потому что о безопасности немного думают и за модный нынче подход «быстро поднятое упавшим не считается» там обычно Линус ломает ноги.
Они там и без CI хипсторского как-то живут. Наверное потому что о безопасности немного думают и за модный нынче подход «быстро поднятое упавшим не считается» там обычно Линус ломает ноги.
Нет, не поэтому. А потому что разработка linux — это, в основном, работа с "железом". И проверить её можно только на реальном железе.
Зачем это всё, когда есть нормальные фулстек платформы, как например жабка?
А можно попросить без сленга? Мозг сломал.
Вот соглашусь. Ддокер нужно применять тогда, когда классические методы установки софта не работают. Ну там тяжелый конфликт библиотек, всякие экзотические зависимости.
А так все решается классическими методами меньшими силами.
А так все решается классическими методами меньшими силами.
А так все решается классическими методами меньшими силами.
А вы уверены? Кмк, проще чем docker-compose.yml не может быть ничего в принципе, особенно классические методы через apt-get, полсотней сырых реп, кривыми мейнтейнерами, игнорированием пакетных менеджеров дистрибутива и программного языка друг-друга и так далее.
Но ведь в этом самом docker-compose в итоге будет этот же самый бардак, только запрятанный парой слоёв абстракций. Софт и библиотеки в образе докера сами по себе не появятся.
Докер и начинают везде пихать как средство заметания муора под ковер ИМХО.
Самое большое отличие в том, что бардак везде будет небольшой, разный и, обычно, минимально бардачный.
Где-то будет выбран дистрибутив, для которого авторы собирают бинарные пакеты, где-то дистрибутив, на котором проще всего собрать все с нуля и так далее.
А когда нужный бардак не получился, или внезапно потребовался совсем другой бардак — можно его одним движением выкинуть и забыть. Или откатить, по потребности.
Так что, как по мне, мусор-в-Докере — не худший вариант. Он не под ковром, он в ведре с пакетом, если бытовая аналогия для кого-то предпочтительнее "контейнера". И хоть мусор там внутри, хоть кости, хоть потроха.
Docker это не про установку софта, это способ дистрибуции ПО. Разработчик предоставляет ПО не ввиде инсталлятора, пакета и т.п., а ввиде докер-образа. Обычно разработчки хорошо знаком с зависимостями своего продукта, а админ плохо. Поэтому удобнее, когда разработчик сам все разложит в контейнере.
А зависимости это не установка софта?
Я знаю, что докер испольуется именно для того, чтобы не договариваться между собой. Только я бы сказал это скорее незнание классических методов и лень и еумение договариваться и вырабатывать единую политику и дисциплину.
Я знаю, что докер испольуется именно для того, чтобы не договариваться между собой. Только я бы сказал это скорее незнание классических методов и лень и еумение договариваться и вырабатывать единую политику и дисциплину.
Зачем искать лень там, где этот вид работ можно устранить докером как класс? Базовые докера со всеми зависимостями создаются один раз и забываются. Остаётся только app level. Профит для всех. И у админов эффективность многократно увеличивается, и девы перестают валять дурака с «а у меня всё работает», и инфраструктура полностью документирована в виде кода. Из недостатков вижу только более долгий CI, нет этих запушил один файлик и сразу его закинули на сервер. Но у этого тоже есть профит — девы начинают думать мозгами и максимально всё тестить на локалхосте, а не дебагить прямо на сервере.
В общем я понимают боль девов, когда им навязывают докер, но это боль во благо продукта.
В общем я понимают боль девов, когда им навязывают докер, но это боль во благо продукта.
Есть еще один недостаток — высокий расход ресурсов.
Другой недостаток, вместо порядка — «замести под ковер».
Другой недостаток, вместо порядка — «замести под ковер».
Каких ресурсов? Что значит высокий?
Память, диск.
Вы серьёзно? Я вот эти доводы слышу от людей, которые судят про докер потому что увидели что на маке он работает в Virtualbox (ой, докер оверхед создает и тд). Используем докер в продакшене на нескольких десятках машин под Кубером. Более удобного инструмента для масштабирования, деплоя, мониторинга и тд я в жизни не встречал.
Docker на Mac уже давно не использует Virtualbox.
Расскажите, где реально кубер используется в каких проектах?
Говорят, что кубер сложен в настройке и глючный. Насколько это правда?
Говорят, что кубер сложен в настройке и глючный. Насколько это правда?
У нас вся инфраструктура на кубере, не важно какой именно проект: и телеметрия, и сами проекты и базы данных, и гитлаб и прочее, все в докере (у нас геймдев студия). Кубер относительно сложный в настройке, скорее в него не так легко вкатиться сначала, потом уже становится все сильно проще. То что прям сильно глючный — не могу сказать, но иногда проскальзывают мелкие неприятные моменты, но ни разу не привели к даунтайму. Но дальнейшее удобство от его использование сильно перевешивает это.
Ну, у меня имиджи по 2 гига получаются, вот только сейчас глянул.
Подозреваю что вы что-то делаете не так, что-то лишнее запихиваете в образ, что должно лежать на внешнем volume. Почти любое приложение можно запихнуть в alpine образ, если уж сильно постараться. У нас даже кривые образы, до которых не доходят руки поправить, не выходят за гиг.
Вот глянул, базовый образ, выбирал не я — python2.7 925MB, После установки и компиляции всех нужных пакетов получается 1.97.
Думаю на пару сот мегов можно уменьшить, если повозиться.
Но это же и есть то, о чем я пишу, докер ест мое время за напонятный выигрыш. Точнее выигрыш для девопов, им не нужно возиться с установкой нужного мне софта и они могут поиграться с тем, что им нравится, вместо того, чтобы влезать в то, что на самом деле работает.
А проблемы они будут решать рестартом контейнера.
По моему так.
А делать образ из альпайн? Сначала я должен всех переубедить, что это стоит того. Еще туда должен буду установить мои зависимости и еще не факт, что получу большой выигрыш.
Ну плюс риск, что я могу потратить несколько дней на компиляцию и установку всего чего нужно, а в конце натолкнусь на непреодолимое препятствие.
Думаю на пару сот мегов можно уменьшить, если повозиться.
Но это же и есть то, о чем я пишу, докер ест мое время за напонятный выигрыш. Точнее выигрыш для девопов, им не нужно возиться с установкой нужного мне софта и они могут поиграться с тем, что им нравится, вместо того, чтобы влезать в то, что на самом деле работает.
А проблемы они будут решать рестартом контейнера.
По моему так.
А делать образ из альпайн? Сначала я должен всех переубедить, что это стоит того. Еще туда должен буду установить мои зависимости и еще не факт, что получу большой выигрыш.
Ну плюс риск, что я могу потратить несколько дней на компиляцию и установку всего чего нужно, а в конце натолкнусь на непреодолимое препятствие.
Докер ест время на вполне понятный выигрыш. Если у вас одна машина, то он вам не нужен. Если у вас несколько машин, то каждый раз ставить на них все зависимости и производить базовые настройки для запуска приложения — это трэш. Завтра у вас одна машина упала и вы судорожно настраиваете ей замену, а я просто ставлю label на другой и смотрю как Кубер поднимает на ней контейнер за минуту, согласно заданным правилам.
Если разработчику с другого проекта, стэка понадобилось запустить ваш проект, то он просто берет и запускает собранный образ, а не с бубнами и readme тратит время на сборку локально. Это прям доказано уже не один раз на собственном опыте.
Всегда стоит смотреть из каких образов вы наследуетесь, доверять можно только офф хабам, в остальных случаях там может быть неизвестно что. У нас базовый образ node.js 650 метров, если взять на alpine, то еще меньше будет. Переубеждать вы никого не должны, внедрять это должны devops-ы.
У вас какой-то странный взгляд: вы не хотите потратить время чтобы разобраться в чем-то новом, что в итоге вам дальше будет экономить куда больше времени, а уже считаете что это вам ничего не даст. Докер используют далеко не первый год в продакшене, в больших и малых компаниях, все плюсы и минусы его давно известны, надо просто взять и почитать.
Если разработчику с другого проекта, стэка понадобилось запустить ваш проект, то он просто берет и запускает собранный образ, а не с бубнами и readme тратит время на сборку локально. Это прям доказано уже не один раз на собственном опыте.
Всегда стоит смотреть из каких образов вы наследуетесь, доверять можно только офф хабам, в остальных случаях там может быть неизвестно что. У нас базовый образ node.js 650 метров, если взять на alpine, то еще меньше будет. Переубеждать вы никого не должны, внедрять это должны devops-ы.
У вас какой-то странный взгляд: вы не хотите потратить время чтобы разобраться в чем-то новом, что в итоге вам дальше будет экономить куда больше времени, а уже считаете что это вам ничего не даст. Докер используют далеко не первый год в продакшене, в больших и малых компаниях, все плюсы и минусы его давно известны, надо просто взять и почитать.
Завтра у вас одна машина упала...
… и я просто запускаю деплой-скрипт указав ему на другую машину.
Если разработчику с другого проекта, стэка понадобилось запустить ваш проект, то он просто берет и запускает собранный образ...
А если ему нужно не просто запустить проект, а внести изменения, собрать и отладить?
А если ему нужно не просто запустить проект, а внести изменения, собрать и отладить?
Не поверите, ровно для этого случая все и задумывалось!
Ну так как оно работать-то будет?
Отлично работать будет. Программист просто пнет сборку на месте, оно соберется и запустится.
Собственно, весь подход в том, что наличие репозитория гарантирует воспроизводимость автоматизированной сборки с нуля за конечное время.
При этом в числе зависимостей сборки будут а) наличие репозитория исходного кода б) доступ к докер-регистри.
Собственно, весь подход в том, что наличие репозитория гарантирует воспроизводимость автоматизированной сборки с нуля за конечное время.
При этом в числе зависимостей сборки будут а) наличие репозитория исходного кода б) доступ к докер-регистри.
Вот я уже приводил ниже пример проекта, над которым не так давно работал. Для сборки требуется, в том числе, Visual Studio с особыми дополнениями, всяческих Build Tools недостаточно.
Вы предлагаете добавлять образ установленной студии (5 гигабайт) в регистр образов? Как часто он будет выкачиваться оттуда при сборке? Что делать работающим удалённо разработчикам?
Вы предлагаете добавлять образ установленной студии (5 гигабайт) в регистр образов? Как часто он будет выкачиваться оттуда при сборке? Что делать работающим удалённо разработчикам?
Вот я уже приводил ниже пример проекта, над которым не так давно работал. Для сборки требуется, в том числе, Visual Studio с особыми дополнениями, всяческих Build Tools недостаточно.
Нет, я предлагаю вам принять тот факт, что конкретно ваш случай в DevOps концепцию не ложится, и отказаться от заранее утопичной идеи пихать Windows-only приложение в конейнер.
Вы предлагаете добавлять образ установленной студии (5 гигабайт) в регистр образов?
Если оно у вас получится — дадите посмотреть?)
Как часто он будет выкачиваться оттуда при сборке?
Один раз на каждое обновление версии образа (в данном случае по разу на версию студии, вероятно).
Что делать работающим удалённо разработчикам?
Бежать с этого проекта при первой же возможности.
Ну вот, один случай, который в докер не ложится, уже нашли. Только не понятно что тут принципиально не так с DevOps, и почему удалённые разработчики должны бежать с проекта…
Ну вот, один случай, который в докер не ложится, уже нашли.
А кто-то предлагал все-все-все в докер «уложить»? Идея запихать студию в докер была ваша…
Только не понятно что тут принципиально не так с DevOps
Принципиально не так — отсутствие автоматизации сборки.
почему удалённые разработчики должны бежать с проекта…
А почему только удаленные? С проекта, где Visual Studio пытаются запихать в Docker бежать надо всем, ортогонально удаленности.
А кто-то предлагал все-все-все в докер «уложить»? Идея запихать студию в докер была ваша…
Я намеренно привёл проект, который нельзя упихать в докер. Чтобы показать, что не всегда (цитата) "боль девов, когда им навязывают докер — это боль во благо продукта."
Принципиально не так — отсутствие автоматизации сборки.
А кто сказал, что у сборки нет автоматизации? Простая команда "C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" /p:VisualStudioVersion=14.0 соберёт весь проект и запакует в готовый к установке архив… Но для этой команды нужна установленная студия.
не всегда (цитата) «боль девов, когда им навязывают докер — это боль во благо продукта.»
Не моя цитата. Я как раз про «докер — отличный инструмент для определенных проектов(не для всех)».
А кто сказал, что у сборки нет автоматизации? Простая команда «C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe» /p:VisualStudioVersion=14.0 соберёт весь проект и запакует в готовый к установке архив… Но для этой команды нужна установленная студия.
Вот в этом девопсе очень сильно не хватает «опса». Да и сама идея ручками втыкать на билд-сервер студию «нужной модели» (или билдить продакшен-сборку на девелоперской машине) — это очень «такая себе» идея. Воспроизводимость сборки самоубивается, весь «девопс» коту под хвост.
Собственно, для CI/CD (и собственно DevOps) неплохо подходит .NET Core, но его собирать студия не нужна.
Не моя цитата. Я как раз про «докер — отличный инструмент для определенных проектов(не для всех)».
Ну так свой первый комментарий я и не вам писал...
Вот в этом девопсе очень сильно не хватает «опса»
И что "опс" тут сделает?
Воспроизводимость сборки самоубивается, весь «девопс» коту под хвост.
А что не так с воспроизводимостью сборки?
А что не так с воспроизводимостью сборки?
С воспроизводимостью сборки проблема. Цитируя вас: «Для сборки требуется, в том числе, Visual Studio с особыми дополнениями, всяческих Build Tools недостаточно.» Т.е. окружение для сборки настраивается руками, детерминированная конфигурация отсутствует, развертывание в промышленных масштабах не предусмотрено, собирается при правильном положении звезд на машине самого разработчика…
И что «опс» тут сделает?
Опс тут всегда был. DevOps — это такая методология, в которой «все есть код» (не примите за определение). Т.е. все, начиная от кода, до непосредственного деплоя приложения — это часть проекта. И докер — порождение и достаточно удобный инструмент именно этой методологии. Отпилите «опс»-часть (эксплуатацию), и выгодны контейнеризации становятся гораздо менее очевидными.
Поэтому ваше «а я хочу взять десктопный проект на студии 2006 года, и сделать чтобы все по девопсу» — это классическое натягивание совы на глобус. Термин DevOps младше, чем ваша студия (и, видимо, проект).
В пайплайнах сборки от контейнеризации, по факту, всего один плюс — изоляция окружения сборки. Не больше и не меньше. Надо ли оно вам (по-взрослому, однозначно, надо), и не удобнее ли вам в вашем одном проекте 2006 года рождения использовать виртуалки — это ваши личные trade-off'ы. Но вот этот подход «в моем проекте не работает, значит не нужно» — ну, плохо это. Есть миллион других кейсов, где оно работает с разной степенью успешности.
Т.е. окружение для сборки настраивается руками
Окружение для сборки ставится установщиками через "далее-далее-готово". Можно даже автоматически попытаться поставить, но нет смысла — не так часто создаются новые билд-сервера. Нет смысла автоматизировать работу, которая выполняется раз в три года.
детерминированная конфигурация отсутствует
Присутствует и указана в документации.
развертывание в промышленных масштабах не предусмотрено
Почему вы так решили? Что такое "развертывание в промышленных масштабах"?
собирается при правильном положении звезд на машине самого разработчика
Собирается при правильно установленном окружении.
Поэтому ваше «а я хочу взять десктопный проект на студии 2006 года, и сделать чтобы все по девопсу» — это классическое натягивание совы на глобус.
А кто вам сказал, что это десктопный проект на студии 2006 года?
В пайплайнах сборки от контейнеризации, по факту, всего один плюс — изоляция окружения сборки. Не больше и не меньше. Надо ли оно вам (по-взрослому, однозначно, надо)
Надо-то надо, но как?
Окружение для сборки ставится установщиками через «далее-далее-готово».
«Установщик» — это должность у вас в организации такая? Или вы, если вам понадобился новый билд-сервер, берете разработчика с зарплатой, предположим, 1500р/час, и садите его за отдельный компьютер, на котором он по распечатанной инструкции в течение 2 часов тычет Далее-Далее-Готово и расставляет галочки в нужных местах? Поздравляю, вы только что купили услугу развертывания билд-сервера за 3000 рублей!
Можно даже автоматически попытаться поставить, но нет смысла — не так часто создаются новые билд-сервера. Нет смысла автоматизировать работу, которая выполняется раз в три года.
Ну да, в вашем случае «проекту 13 лет», видимо, может и реже. А в случае, если у вас проектов больше одного, заводить по железке на каждый — ну, такое себе, с финансовой точки зрения. А вот крутить на имеющихся мощностях билды нескольких проектов, а то и делегировать билд в облако — полезная и достаточно экономная вещь. Только я вот не представляю, как вы свою «прелесть» куда-либо перенести сможете.
Присутствует и указана в документации.
Аааатлично! Берем высокооплачиваемого разраба и оплачиваем ему человекочасы за развертывание окружения по 15-страничной распечатке документации. При этом, вне зависимости от уровня разработчика, «самым слабым звеном» в вашей «автоматизации» окажется именно он.
Почему вы так решили? Что такое «развертывание в промышленных масштабах»?
Представим ситуацию: вам упало три срочных новых проекта за «дофига денег». Каждый со своей спецификой сборки, но фиксы быстрые, и платят за них хорошо… Докупим 3 новых билд-сервера, вероятно? Ваш билд не масштабируется. «установщиками через „далее-далее-готово“» — это обезьянье масштабирование какое-то. Взрослые же люди, в самом деле.
Собирается при правильно установленном окружении.
Правильно «установленном Далее-Далее-Далее-Готово» окружении. Ну, т.е. сборка масштабируется вручную через несколько человек, жмущих «Далее» человек, и не может быть делегируема в принципе.
А кто вам сказал, что это десктопный проект на студии 2006 года?
Ну ладно, ошибся, не 2006. VisualStudio 14 — 2015 год. 4 года уже. При этом кастомная настройка таки намекает, что проект не .NET Core, и NuGet'ом зависимости, почему-то, не резолвятся. Т.е. даже заюзайте вы MS DevOps, которая вполне себе билдит проекты в облаке из исходников — не взлетит. Потому что, видимо, «изначально спроектировано так».
Надо-то надо, но как?
В вашем случае, видимо, никак. Доведите проект до состояния, в котором он самостоятельно может рулить своими зависимостями, для начала — сможете куда-то дальше двигаться. Если это невозможно… Ну, живите с этим, просто весь накопленный CI/CD инструментарий не для вас, видимо.
Поздравляю, вы только что купили услугу развертывания билд-сервера за 3000 рублей!
… и это все равно получается дешевле чем автоматизировать то же самое или распихивать по контейнерам.
А вот крутить на имеющихся мощностях билды нескольких проектов, а то и делегировать билд в облако — полезная и достаточно экономная вещь.
Так они же и так крутятся. Трех билд-серверов достаточно для сборки всех проектов. Ещё есть четвёртый в запасе, отключен за ненадобностью.
Представим ситуацию: вам упало три срочных новых проекта за «дофига денег». Каждый со своей спецификой сборки, но фиксы быстрые, и платят за них хорошо… Докупим 3 новых билд-сервера, вероятно?
Подождите, что такое "упали проекты" и что такое "специфика сборки"?
Если это новые проекты, то мы будем делать их так, чтобы не было никакой "специфики сборки". Билд-сервера для сборки как бы уже есть.
Если же это чужое легаси — то я не понимаю как в этой ситуации могут помочь контейнеры. Ведь вместе с легаси-проектом никогда не "падает" контейнер с окружением для его сборки, это фантастика какая-то.
Доведите проект до состояния, в котором он самостоятельно может рулить своими зависимостями, для начала — сможете куда-то дальше двигаться.
Рады бы, но если тулчейны для сборки ставятся только вместе со студией — значит, нужно или использовать студию, или писать свой тулчейн. Писать свой тулчейн — это куда дороже чем те 3000 рублей, насчитанные вами за развертывание билд-сервера.
Если это невозможно… Ну, живите с этим, просто весь накопленный CI/CD инструментарий не для вас, видимо.
Внезапно, мы используем нормальный CI/CD инструментарий. Если билд-сервер невозможно поднять в облаке — это ещё не означает, что это не CI. Если окружение для новый инстанса берется не из "базового" контейнера, а из "базового" бэкапа виртуалки — это ещё не значит, что это не CD.
… и это все равно получается дешевле чем автоматизировать то же самое или распихивать по контейнерам.
Возможно, конкретно в вашем случае оно и дешевле (или не считал никто, на самом деле). Только не подавайте «нам не подошло» как недостаток контейнерной виртуализации в целом. Оно просто вам не подошло, но вы, видимо, интересуетесь. Не зависть ли это?)
Так они же и так крутятся. Трех билд-серверов достаточно для сборки всех проектов. Ещё есть четвёртый в запасе, отключен за ненадобностью.
Представляет, что понадобился «на время» проект на 13-й студии с аналогичными «фичами» сборки. Вы корячите на свои билд-сервера еще по одной студии, а после завершения проекта долго и мучительно ручками выпиливаете ошметки ставшего ненужным инструментария из разных уголков ФС машины? Ну, не знаю, странно это как-то.
Подождите, что такое «упали проекты» и что такое «специфика сборки»?
«Упали проекты» — это к вам пришли, принесли много денег и сказали «а не возьметесь ли вы вот этот проект до ума довести за разумно-большую сумму за обозримые сроки?».
«Специфика сборки» — это «наш проект собирается только на Visual Studio 13, 32-битной версии с набором установленных плагинов/модулей, вот список на 16 страниц». Ну, т.е. все, как вы привыкли (сори, не удержался от «минутки сарказма»)
Если это новые проекты, то мы будем делать их так, чтобы не было никакой «специфики сборки». Билд-сервера для сборки как бы уже есть.
Рискну предположить, что новые ваши проекты скорее унаследуют уже имеющуюся «специфику» (14 студия, вот с этими галочками).
Если же это чужое легаси — то я не понимаю как в этой ситуации могут помочь контейнеры. Ведь вместе с легаси-проектом никогда не «падает» контейнер с окружением для его сборки, это фантастика какая-то.
Вполне себе может и «упасть» сборочный образ, например. Я пару раз видел, честно-честно. А иногда и не падает, ага. Падает, например, столь ценимая вами «документация» вида «нужно проставить галочки при установке вот в этом порядке, затем жать Далее-Далее-Далее, пока не увидите синее окошко. Как увидели, закройте по Ctrl-Alt-Del, перезагрузитесь и запустите установку заново, второй раз пройдет нормально». Причем может еще оказаться, что документацию «забыли обновить» полтора года назад… Ну, это к тому, для чего вся эта возня с девопсом задумывалась, ага.
Рады бы, но если тулчейны для сборки ставятся только вместе со студией — значит, нужно или использовать студию, или писать свой тулчейн. Писать свой тулчейн — это куда дороже чем те 3000 рублей, насчитанные вами за развертывание билд-сервера.
Ну, если честно (суровое имхо, да простят меня аксакалы из майкрософта), эта ситуация — лютый фейл билд-инструментария. Ни тебе вменяемого вендоринга, зайчаточный менеджмент зависимостей и все вот это. Они что-то начали делать, даже успехи есть, но оно еще в начале пути, причем некоторые вещи дошли до состояния «проще переделать к хренам», о чем нам и говорит .NET Core.
Почему я про «Корю» говорю — это именно попытка запилить, наконец, вменяемый билд-инструментарий. Да, с ним нельзя делать половину того, что можно делать с полноценной студией (причем, пожалуй, самую приятную половину), однако концепция у него сильно поприятнее.
Внезапно, мы используем нормальный CI/CD инструментарий. Если билд-сервер невозможно поднять в облаке — это ещё не означает, что это не CI. Если окружение для новый инстанса берется не из «базового» контейнера, а из «базового» бэкапа виртуалки — это ещё не значит, что это не CD.
Это просто значит, что контейнеры вам не помогут. А хочется, признайте уже!)))
Только не подавайте «нам не подошло» как недостаток контейнерной виртуализации в целом. Оно просто вам не подошло, но вы, видимо, интересуетесь. Не зависть ли это?)
Ну так я и не говорю про что-то в целом. Мне просто не нравится фраза «боль девов, когда им навязывают докер — это боль во благо продукта», которая вроде и не ваша, но вы ее почему-то продолжаете защищать.
Про зависть — возможно. Тут хайп, всё такое, все рассказывают насколько им проще стало с докером — а у меня все проекты строго делятся на два типа: те, где докер не нужен — и те, где докер не поможет.
Представляет, что понадобился «на время» проект на 13-й студии с аналогичными «фичами» сборки. Вы корячите на свои билд-сервера еще по одной студии, а после завершения проекта долго и мучительно ручками выпиливаете ошметки ставшего ненужным инструментария из разных уголков ФС машины? Ну, не знаю, странно это как-то.
Если без 13й студии ну никак — то две студии могут существовать рядом и не будут ссориться. Проверено практикой: из-за параллельной работы над разными проектами у меня на старом рабочем компьютере стояли 2012 и 2015 студии одновременно — и никаких багов от этого не появлялось. А до этого стояли 2008 с 2010 и 2010 с 2012.
«Специфика сборки» — это «наш проект собирается только на Visual Studio 13, 32-битной версии с набором установленных плагинов/модулей, вот список на 16 страниц». Ну, т.е. все, как вы привыкли (сори, не удержался от «минутки сарказма»)
Ну, мы-то привыкли, и за кучу денег и не таким занимались (так, в одном из проектов на Java нам пришлось реверс-инженерить IDE чтобы иметь возможность запускать деплой из командной строки).
А вот что будете делать в этой ситуации вы? :-)
Рискну предположить, что новые ваши проекты скорее унаследуют уже имеющуюся «специфику» (14 студия, вот с этими галочками).
Ну уж нет.
Вполне себе может и «упасть» сборочный образ, например.
Если "упадёт" — мы им воспользуемся. Но пока что нам ни разу так не везло.
Ну, если честно (суровое имхо, да простят меня аксакалы из майкрософта), эта ситуация — лютый фейл билд-инструментария.
Тут согласен. Вот только этот фейл докером не исправляется.
Это просто значит, что контейнеры вам не помогут.
Бинго!
Мне просто не нравится фраза «боль девов, когда им навязывают докер — это боль во благо продукта», которая вроде и не ваша, но вы ее почему-то продолжаете защищать.
Тут просто два кейса ключевых. Есть случай, когда проект в этот инструментарий хорошо ложится, и девы «страдают» просто от внедрения нового инструментария. Ну, тут, как бы, фишка в том, что за этот банкет кто-то платит, и он имеет право рассматривать варианты, например, той же элементарной экономии на пайплайнах (допустим, в некоторых случах облачная сборка/тесты вполне себе позволяет сэкономить). И вот тут девам не страдать надо, а либо спокойно работать, либо обосновать, почему этот инструмент «не вкатил». Причем лучше с меркантильной точки зрения, руководство это лучше понимает.
Второй кейс — это когда руководство принципиально пытается впихнуть невпихуемое. Но это, простите, не вопрос страдания девов, а вопрос кретинизма руководства и поиска новой работы девами.
Блин, как будто про теток разговариваем)
Про зависть — возможно. Тут хайп, всё такое, все рассказывают насколько им проще стало с докером — а у меня все проекты строго делятся на два типа: те, где докер не нужен — и те, где докер не поможет.
Ну, вот тут искренне вам сочувствую. Как минимум, что не получается «пощупать» интересный инструментарий в продакшене.
Если без 13й студии ну никак — то две студии могут существовать рядом и не будут ссориться. Проверено практикой: из-за параллельной работы над разными проектами у меня на старом рабочем компьютере стояли 2012 и 2015 студии одновременно — и никаких багов от этого не появлялось. А до этого стояли 2008 с 2010 и 2010 с 2012.
Это, в общих чертах, понятно. Но, допустим, если вам старая студия нужна временно, например, на время миграции проекта на новую версию… Ну, не знаю, поставить-то их рядом действительно не проблема, удалить лишнее — вот истинный корень зол. У меня от таких вещей «зудит» просто)
Ну, мы-то привыкли, и за кучу денег и не таким занимались (так, в одном из проектов на Java нам пришлось реверс-инженерить IDE чтобы иметь возможность запускать деплой из командной строки).
А вот что будете делать в этой ситуации вы? :-)
Ну, если лично про меня. Вероятнее всего, откажусь от этого геморроя). Работа не волк, работа джоб же. Если вдруг другой работы на хлеб хватать будет, масло прямо на колбасу мазать буду, тогда, конечно, возьмусь, куда деваться. Хлеб — он же всему голова.
Ну уж нет.
Ну, т.е. вам самому «не очень-то и нравится»)))
Если «упадёт» — мы им воспользуемся. Но пока что нам ни разу так не везло.
Ну, в .NET оно действительно пореже встречается, ага. У меня просто специфика несколько другая.
Наткнулся я на наш старый разговор... Так вот, попробовал я вашу сборку в докере. Краткий вердикт - магии не случилось, с докером сборка стала скорее даже сложнее.
Во-первых, зависимость от окружения до конца не исчезла. Окружение создаёт инфраструктурные проблемы, которые требуют кооперации со стороны контейнера для своего решения.
И если "раньше" можно было положиться на то, что сборочный агент просто работает - то теперь детали окружения просачиваются в каждый проект. Подняли репозиторий nuget? Обновите-ка пайплайны во всех проектах! Подняли репозиторий npm? Ну, вы знаете что делать...
Ещё один источник "просачивания" окружения - docker in docker. Способ его запуска зависит от конфигурации агента.
И отдельное "фу" гитлабу за то, что он не даёт настраивать переменные на уровне агента (раннера).
Во-вторых, для управления сборкой больше нельзя использовать системы сборки - ведь системы сборки живут в контейнерах, а управлять надо снаружи. Приходится полагаться на пайплайны, а они работают куда медленнее. даже если на некоторой стадии сборки оказалось нечего делать - стадия всё равно должна запуститься чтобы выяснить этот факт.
И, в-третьих, если для сборки недостаточно стандартного образа - совершенно непонятно что делать. Выполнять apt-get при каждой сборке - слишком долго, а собрать образ один раз и куда-нибудь его положить - снова невоспроизводимо.
В общем, я уверен что любой из проектов со старой работы можно хоть сейчас, хоть через 10 лет собрать по инструкции. Но я совершенно не уверен что тот код, который я закомитил сейчас, удастся собрать через год.
НЛО прилетело и опубликовало эту надпись здесь
Как надо?
Практика использования (особенно с учетом изначальной природы докера в качестве надстройки над механизмами изоляции ядра Linux), а также наличие огромного количества инструментов и практик, нарощенных за время этого использования, видимо, намекает, что аналогичного тулинга на Windows, где аналогичная движуха начала делать первые шаги год-два назад, стоит ждать еще через пару-тройку лет.
Ну, в общем, неюзабельно оно пока что в Windows, хоть никто и не запретит вам родить недостающие инструменты самостоятельно. Возможно они и станут стандартом де-факто на windows-платформах. Осталость только понять, насколько оно вам нужно.
НЛО прилетело и опубликовало эту надпись здесь
Я не девопс, а простой пролетарий разработчик, для сборки пишу баш скрипты. Так там кэширую скачанные исходники на локальном дисеки и скачиваю и пересобираю только тот софт, для которого локальная версия не совпадает с удаленной.
Разве не везде так?
Разве не везде так?
Собираю я, значит, каждую ночь свежие образы всяких анстейблов, и всё хорошо для дебиан и опенсусе. Однако, если я вдруг захочу ещё гонять сборку и тесты под гентой, то всё будет очень плохо: у меня там в зависимостях вебкит, например, а он редко обновляется, пересобирать его каждую ночь глупо. При этом свежие версии зависимостей для сборки иметь охота. Как это решают Ъ девопсы?
Т.е. вы собираете роллинг-версии дистрибов, чтобы потом погонять сборку/тесты приложения в самых-самых свежих версиях окружения?
Ну, собственно, это без боли не обойдется, и оно же стало одним из движущих факторов зачинания хреновой уймы инструментов-«песочниц». Как бы, докер, флатпак, снап, lxc/lxd как раз в списке решаемых проблем имеют отсутствие хреновой уймы разнообразных окружений. Они как раз их унифицируют и стабилизируют.
Собственно, отсюда и 2 вещи:
1. Становится понятно, кто «оплачивает банкет».
2. Почему ни один коммерческий проект официально генту и идеологически-сходные дистрибутивы не поддерживает.
В общем, пилить костыль над сборочным инструментарием — вполне нормальный вариант, учитывая суть проблемы. Именно в такой сценарий никто деньги вкладывать не будет, а значит и стабильного инструментария не появится.
> берете разработчика с зарплатой, предположим, 1500р/час
А сколько уйдет ЧЧ на объяснение команде, например, из 10 разрабов о том, что такое докер и как его пользовать? Ну и сколько вы за такую услугу готовы взять?
А то у меня ощущение, что два нуля добавляются легко.
А сколько уйдет ЧЧ на объяснение команде, например, из 10 разрабов о том, что такое докер и как его пользовать? Ну и сколько вы за такую услугу готовы взять?
А то у меня ощущение, что два нуля добавляются легко.
Ага, деплой скрипт, который пойдет все качать, ставить настраивать и тд, и тд. вместо того чтобы просто сделать docker pull и запустить уже собранный образ. Вообще ведь никакой разницы…
Если надо внести изменения, то схема не сильно меняется, вообще даже не меняется. Просто вместо запуска уже собранного контейнера, надо будет перед этим собрать его. Опять-таки без необходимости устанавливать и настраивать все зависимости.
Вот отладка уже другое, докер тут не причем, но и разработчику с другого проекта незачем отлаживать другой проект
Если надо внести изменения, то схема не сильно меняется, вообще даже не меняется. Просто вместо запуска уже собранного контейнера, надо будет перед этим собрать его. Опять-таки без необходимости устанавливать и настраивать все зависимости.
Вот отладка уже другое, докер тут не причем, но и разработчику с другого проекта незачем отлаживать другой проект
Ага, деплой скрипт, который пойдет все качать, ставить настраивать и тд, и тд. вместо того чтобы просто сделать docker pull и запустить уже собранный образ.
Насколько я помню, образы докера могут ссылаться на базовые, которые так же понадобится откуда-то скачать.
Если вы скажите про локальный репозиторий образов — то ведь и деплой скрипт может к локальным репозиториям обращаться...
Если надо внести изменения, то схема не сильно меняется, вообще даже не меняется. Просто вместо запуска уже собранного контейнера, надо будет перед этим собрать его. Опять-таки без необходимости устанавливать и настраивать все зависимости.
А почему вы считаете, что для сборки контейнера зависимости не нужны? Или вы предлагаете поместить в контейнер всё окружение для сборки?
Мне как-то не очень нравится идея гонять по сети туда-сюда контейнер с, допустим, установленной Visual Studio на 5 гигабайт — а ведь некоторые из проектов, над которыми я работал, иначе и не соберутся...
С другой стороны, современные проекты, те что используют .NET Core, для сборки не требуют ничего кроме .NET Core SDK — для них докер будет той самой лишней зависимостью.
но и разработчику с другого проекта незачем отлаживать другой проект
А зачем ему в таком случае его как-то специально запускать, и почему он не может просто пойти на стенд где этот проект уже развернут и запущен?
Насколько я помню, образы докера могут ссылаться на базовые, которые так же понадобится откуда-то скачать.
Если вы скажите про локальный репозиторий образов — то ведь и деплой скрипт может к локальным репозиториям обращаться…
Вы же понимаете, что цепочка «поставить необходимые пакеты -> разложить конфиги в нужной последовательности -> пнуть необходимые демоны/сервисы, чтобы стартанули» несколько более сложна и менее предсказуема, чем «скопировать 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 проектов нормально так экономит место на диске, оставляя за вами возможность иметь более одного рантайма на хосте.
Вы же понимаете, что цепочка «поставить необходимые пакеты -> разложить конфиги в нужной последовательности -> пнуть необходимые демоны/сервисы, чтобы стартанули» несколько более сложна и менее предсказуема, чем ...
Это цепочку всё равно придётся проделывать при сборке образа.
К тому же сама «умелка» развернуть проект, подтянуть к нему 100500 «вспомогательных» вещей, потестить, а потом тупо мановением руки удалить все (действительно все), что проект притащил за собой, не оставив окровавленных ошметков от проекта, размазанных по всей системе… Ну, это само по себе ценно, например.
Это базовая функциональность .NET Core.
Ну а в момент деплоя, один общий слой с рантаймом .NET Core на 100500 проектов нормально так экономит место на диске, оставляя за вами возможность иметь более одного рантайма на хосте.
Нет смысла. Если фиксировать версию рантайма — то каждый проект будет идти со своим рантаймом, мы новые проекты начинаем реже чем рантаймы выходят. А если её не фиксировать — то сойдет и просто самый свежий рантайм, обратная совместимость все-таки существует.
Это цепочку всё равно придётся проделывать при сборке образа.
Не отрицаю. Просто происходить это будет не при каждой сборке и не целиком, а только при изменении в проекте и теми кусками, которые нужно пересобрать. Т.е. как раз рантайм, например, тащить каждый раз не придется, он будет лежать в базовом слое. При наличии, допустим, 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ю (а там, предположим, апи поменялся).
Что будем делать, шеф?
обратная совместимость все-таки существует.
Вот с этих слов обычно и начинаются проблемы…
Вот понадобился мне в проекте, допустим, работающий… не знаю… ghostscript со специфическими настройками.
Поможет пакет Ghostscript из nuget.
Я понимаю, что под ghostscript вы понимали произвольную стороннюю программу, но примечательно что первый же пример нашелся в репозитории.
Если же то чего нужно не найдется в nuget — всегда есть варианты вендоринга или своего собственного репозитория nuget.
Что будем делать, шеф?
Если никто не жалел места — то нужно просто взять готовый дистрибутив со всеми правильными версиями и развернуть его. Это так же просто как развернуть докер-образ, только без докера.
Если места таки пожалели — есть nuget и есть лок-файл, где зафиксированы конкретные версии. Да, может произойти форс-мажор вроде случившегося с left-pad — но то же самое может случиться и с базовыми докер-образами. С версией рантайма сложнее, но основные можно скачать, а версия 1.0.11.23.55beta точно будет в дистрибутиве.
Поможет пакет Ghostscript из nuget.
Я понимаю, что под ghostscript вы понимали произвольную стороннюю программу, но примечательно что первый же пример нашелся в репозитории.
Посмотрел, немного не то нашлось в репозитории. «The ghostscript dlls» написано. А мне экзешник нужен, причем с путями прописанными… Вот такие «зависимости», сори, конечно, ни один языковой пакетный менеджер не резолвит.
Ну и, собственно, в чем «фишка» именно подхода докера — его можно юзать как «chroot на стероидах», т.е. это инструмент, который позволяет упаковать именно что практически все. Причем все одинаково. Не знаю, как вам, но я склонен это скорее в плюсы записать.
Если никто не жалел места — то нужно просто взять готовый дистрибутив со всеми правильными версиями и развернуть его. Это так же просто как развернуть докер-образ, только без докера.
Развернуть-то куда?
«На железку»? Ценник решения в случае 2-3 конфликтующих конфигураций, собственно, и растет ровно в те же 2-3 раза… Ну, такое себе.
В виртуалку? Ну, тоже оверхед не копеечный ни разу…
А если все это для отладки прямо на машине разработчика запустить — вообще шик будет.
Если места таки пожалели — есть nuget и есть лок-файл, где зафиксированы конкретные версии.
Проблема пары рантаймов в одном окружении так и не решена. Юзать несколько разных рантаймов на системном уровне — плохая идея. Таскать рантайм за каждым проектом свой — докер экономнее получится.
Да, может произойти форс-мажор вроде случившегося с left-pad — но то же самое может случиться и с базовыми докер-образами.
Не, с моими, например, не может. Я базовый образ для своих проектов в собственном регистри держу, например. Я вот этот node-style подход вообще не одобряю…
С версией рантайма сложнее, но основные можно скачать, а версия 1.0.11.23.55beta точно будет в дистрибутиве.
Не, совершенно не точно будет. И, опять же, «можно скачать». Т.е., типа, скачать, сложить, а потом ручками раскатывать на сервера по памятке: «поставить рантайм версии X.Y.Z -> Далее -> Далее -> Далее»? Не-не-не, увольте)
Посмотрел, немного не то нашлось в репозитории. «The ghostscript dlls» написано. А мне экзешник нужен, причем с путями прописанными… Вот такие «зависимости», сори, конечно, ни один языковой пакетный менеджер не резолвит.
А, собственно, нахера экзешник-то, да ещё и с путями прописанными? Зачем он нужен когда библиотека есть?
Развернуть-то куда?
Туда, куда требуется. Это ж вы изначально поставили задачу что надо приложение куда-то там поставить.
Хоть на железку, хоть в виртуалку, хоть в контейнер.
Таскать рантайм за каждым проектом свой — докер экономнее получится.
Не получится: там кроме рантайма же куча библиотек, в том числе системных.
Не, с моими, например, не может. Я базовый образ для своих проектов в собственном регистри держу, например
Ну так и nuget-репозиторий можно свой держать при желании.
Не, совершенно не точно будет.
Совершенно точно будет. Ибо это самый простой способ обеспечить рантайм версии 1.0.11.23.55beta на проде.
PS Кстати, у меня вот к вам встречный вопрос возник. Что вы будете делать если у вам потребуется развернуть два разных проекта, которые требуют несовместимых версий докера?
А, собственно, нахера экзешник-то, да ещё и с путями прописанными? Зачем он нужен когда библиотека есть?
Элементарно:
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, это просто управлялка штатными механизмами изоляции ядра.
Имею право, почему нет?
Потому что слишком сложно получается. Когда есть идентичные по функциональности библиотека и внешняя программа — всегда проще вызвать функцию в библиотеке, чем вызывать внешнюю программу.
В контейнер — отдельный скрипт.
Зачем отдельный? Смотрел я формат ваших докерфайлов — не вижу причин которые бы помешали взять и запустить нужный скрипт в нем командой RUN. Или докерфайлы устарели и контейнеры теперь создаются как-то по-другому?
Сравниваем ваш деплой скрипт с докеровским. Докер: «Запустить рядом 4 контейнера. Тчк.» Ваш: «Установить .NET рантайм. Установить Java-рантайм. [...]
В случае .NET Core (я же про него говорю) рантайм отдельно ставить не нужно (если не заниматься избыточной экономией места). Просто копируется приложение и настраивается его запуск.
Всё остальное можно и правда поместить в контейнеры если оно так проще.
Кстати, а контейнеры настраивать чтобы они совместно работали уже не надо?
Несовместимых, простите, с чем? Вы точно понимаете, что такое докер? Это не VM, это просто управлялка штатными механизмами изоляции ядра.
Допустим, там форматы контейнеров разные. Что будете делать?
Потому что слишком сложно получается. Когда есть идентичные по функциональности библиотека и внешняя программа — всегда проще вызвать функцию в библиотеке, чем вызывать внешнюю программу.
Ну, во первых, имею право, ничего предосудительного в этом нет. В конце концов, и работа с библиотекой может быть сложнее, чем «пнуть экзешник с набором параметров». И сама либа-враппер может быть разной степени сомнительности. Да и приложуха по сути вполне может быть какой-нибудь «удаленной управлялкой», которая в 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). Вся фишка в том, что контейнер существует ровно с момента запуска, это, если угодно, «рантайм-сущность». А на входе один фиг образ, который для всех одинаковый. Как он представлен в виде контейнера никого не колышет, он будет работать.
Вы же про деплой ансиблом говорили.
Я разве что-то говорил про ансибл?
Рантайм отдельно ставить нужно. Именно в случае .NET Core. [...] копируете копию рантайма с приложением вместе.
Да, именно так. Копия рантайма идет вместе с приложением. И всё работает.
Если нужно, чтобы они просто работали параллельно и друг другу не мешали — то не надо.
Нет, во вашему же условию они все должны друг с другом взаимодействовать.
Есть несколько более удобные инструменты оркестрации контейнерами, чем ansible. Причем по мере использования вы, скорее всего, просто перепишете тот же docker-compose в виде ansible-playbook'ов. Ну и нафига, спрашивается, если инструмент уже есть? NIH-синдром?
Не вполне понимаю о чем речь и при чем тут ansible. Вот у вас есть задача: "есть некоторый бек на C#, который использует что-то вроде мем-кеша, написанного на Java". Нужно связать контейрен с беком на C# и контейнер с кешем на Java, чтобы первый мог обращаться ко второму.
Какая такая магия позволит установить эту связь автоматически, в формате "просто запускаем два контейнера и всё заработало"?
Я просто про что. Если вы имели в виду «разные несовместимые форматы образов» — чушь. Их нет, например. Образ — это набор слоев, каждый из которых — тупо tar-архив, содержащий в себе diff от предыдущего слоя.
Да, я говорил об образах.
Если образ — это набор слоев, значит там где-то должны храниться метаданные, описывающие в каком порядке эти слои накладывать друг на друга. Представьте, что в новой версии докера формат метаданных изменился. И ещё, чтобы было веселее, заодно изменился формат докерфайлов.
Или представьте, что у докера появился несовместимый конкурент, и к вам "упал" чужой проект, где этого конкурента использовали.
Я разве что-то говорил про ансибл?
Ну, может, и не вы. Может, контекст статьи подхватился ошибочно. Сорян тогда, если что.
Да, именно так. Копия рантайма идет вместе с приложением. И всё работает.
Вот к вопросу о «бонусах» контейнеров. В контейнере у вас базовый слой (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 есть, возьметесь? Буду считать, это же очевидно!
Вот к вопросу о «бонусах» контейнеров.
Экономия на спичках.
Там просто ссылка на id-шник...
… которая где-то записана в каком-то формате. Есть чему меняться.
Слабо верится. Очень слабо.
Вот и мне слабо верится, что я не смогу перенести сборку старого проекта под новый SDK за разумное время.
Это называется «миграция на новую версию». Докерфайлы — они такие… как бы это вам сказать… текстовые. Я ведь могу и переписать при острой надобности, например. Там не сложно, на самом деле.
Вот и я могу!
Экономия на спичках.
Ну, она есть. С изоляцией запуска до кучи выглядит уже лучше.
… которая где-то записана в каком-то формате. Есть чему меняться.
В текстовом. Сложно что-то поменять.
Вот и мне слабо верится, что я не смогу перенести сборку старого проекта под новый SDK за разумное время.
Ну, как бы, стоит признать, что смигрировать проект с .NET 2.0 на .NET 4.6 — гораздо менее тривиальная задача, чем пнуть пересборку докер-образов.
В текстовом. Сложно что-то поменять.
Вы недооцениваете изобретательность тех, кому поставлена задача "поменяй что-нибудь, чтобы появился повод всем переходить на новую версию" :-)
Ну, как бы, стоит признать, что смигрировать проект с .NET 2.0 на .NET 4.6 — гораздо менее тривиальная задача, чем пнуть пересборку докер-образов.
Там грабли есть только в кодировке конфиг-файлов, ну и в именах приватных полей у системных классов (которые, по-хорошему, не должны никого волновать). И ещё немного разницы в способах подключения стандарного тулчейна — но тут студия сама смигрирует как нужно, если файл проекта особо не корежили.
Вы недооцениваете изобретательность тех, кому поставлена задача «поменяй что-нибудь, чтобы появился повод всем переходить на новую версию» :-)
Осталось понять, кто эту задачу поставит. Дело в том, что 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, вероятно, норм смигрирует, что-то крупнее… Ну, не знаю.
Ну, хотя, пусть его. Сделаем вид, что я вам поверил.
И без консенсуса внутри организации какие-то breaking changes замутить для «авторов» проекта — самая верная попытка самовыпилиться.
То же самое применимо и для .NET Core: поломанная обратная совместимость — самый простой способ растерять пользователей, и на нее просто так авторы не пойдут.
Какие-то апи, наверняка, депрекейтнулись
Заобсолетились, если точнее (.net использует атрибут [Obsolete]). Но их всё ещё можно использовать.
Проблемы я ожидаю только от смены тулчейна. Но тут большинство проектов как раз тот самый "HelloWorld", то есть полностью стандартный тулчейн, и используют.
То же самое применимо и для .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]). Но их всё ещё можно использовать.
Иногда что-нибудь по мелочам ломается. Ссылки выше.
Не все безоблачно.
Описанное по обоим ссылкам — это не breaking changes в рантайме, а breaking changes в библиотеке. Старая версия библиотеки всё ещё доступна в nuget.
В добавок, описанные по первой ссылке изменения даже при обновлении библиотеки не вступят в силу если не написать строчку .SetCompatibilityVersion(CompatibilityVersion.Version_2_1)
Справедливости ради, во второй ссылке написано, что, например, Json.NET больше нет в базовой поставке ASP.NET Core. Т.е. «сам собой» проект со второго Core на третий не смигрирует, придется таки NuGet потрогать для начала.
В первой же ссылке предлагают ручками выставить EnableRangeProcessing в true, чтобы получить прежнее поведение кода. Ну, т.е. «тут надо быть внимательным», потому что имхо, когда «не собралось вообще» — все же лучше, чем «собралось и даже работает, только немного по-другому».
В первой же ссылке предлагают ручками выставить EnableRangeProcessing в true, чтобы получить прежнее поведение кода. Ну, т.е. «тут надо быть внимательным», потому что имхо, когда «не собралось вообще» — все же лучше, чем «собралось и даже работает, только немного по-другому».
Ну так задача-то была не на свежий ASP.NET Core смигрировать, а на свежий рантайм и свежий SDK. Не вижу причин, по которым я должен мигрировать на свежий ASP.NET Core в ситуации, когда (цитирую) "исходники надежно про… теряны, а работать должно сегодня".
Что же до EnableRangeProcessing — то по первой ссылке предлагают выставить EnableRangeProcessing в true, одновременно выставив CompatibilityVersion в Version_2_1. Первый совет в отрыве от второго избыточен.
Ну так задача-то была не на свежий ASP.NET Core смигрировать, а на свежий рантайм и свежий SDK.
Процитирую себя: «Не совсем верится, что проект NET2.0 можно тупо одной кнопочкой на автомате смигрировать на нормальный NET4.6»
Задача была именно переползти на новый стек. Рискну предположить, что исходники под .NET 2.0 на .NET Core не соберутся, к слову.
Ну, если речь идёт о переходе на новый стек — то докер тут вообще никак не поможет, ведь все докерфайлы придётся обновлять. И чем больше именно фишек самого докера было использовано — тем тяжелее будет все обновить.
Рискну предположить, что исходники под .NET 2.0 на .NET Core не соберутся, к слову.
Ну да, потому что .NET и .NET Core — это не две разные версии рантайма, а два разных рантайма.
Ну, если речь идёт о переходе на новый стек — то докер тут вообще никак не поможет
На самом деле, поможет. Чуть-чуть. В определенных ситуациях. Если, например, ваше приложение состоит из нескольких сервисов. Вы по тихой грусти переносите один из сервисов на новый рантайм, остальные крутятся на старом.
Плюсом вы можете не гасить старую версию, пока не убедились, что новая «фурычит». Запустили параллельно, потестили, потыкали в балансировщик, мол, пора бы уже и стрелки переводить. Ничего не упало, все работает — выключаем старую версию. Все упало? Тупо переводим стрелки балансировщика. Упала-то только новая версия, старая все еще работает.
ведь все докерфайлы придётся обновлять.
Ну не все же. Да и поменять одну строчку и запустить ребилд. Тем более если автоматизированный. Тут фишка в том, что есть целая тонна инструментария, превращающего это эпохальное событие «миграция на новый стек» во вполне рутинную скучную операцию.
И чем больше именно фишек самого докера было использовано — тем тяжелее будет все обновить.
Дык, нету там никаких «фишек». Там только «положить файл сюда» и «написать вот это в переменную окружения». Больше ничего нет, сложно сломать что-то.
Ну да, потому что .NET и .NET Core — это не две разные версии рантайма, а два разных рантайма.
Правильно, как и .NET 3.5 vs .NET 4.6. Даже больше того, 4.5 и 4.6 — разные рантаймы, вплоть до версии языка.
На самом деле, поможет. Чуть-чуть. [...]
Ну так без докера так тоже можно.
Ну не все же. Да и поменять одну строчку и запустить ребилд.
Дык, нету там никаких «фишек». Там только «положить файл сюда» и «написать вот это в переменную окружения». Больше ничего нет, сложно сломать что-то.
Вот пути до файлов сломать и можно. В каждой версии их можно менять :-)
А уж если формат конфига сменился...
Из опыта: использовали Монгу (MongoDB) — так там авторы в какой-то из версий поменяли формат передачи параметров в командной строке. Не то -- на /, не то / на --, уже не помню. Вот как тут ребилд образа помог бы?
Правильно, как и .NET 3.5 vs .NET 4.6. Даже больше того, 4.5 и 4.6 — разные рантаймы, вплоть до версии языка.
Вы ошибаетесь, трижды. Во-первых, .NET 3.5 и .NET 4.6 — это две разные версии одного рантайма, там есть обратная совместимость.
Во-вторых, 4.5 и 4.6 — это вообще один и тот же рантайм, отличается лишь версия стандартной библиотеки.
В-третьих, версия языка, хотя зачастую и сопровождается изменением циферок после слова .NET, от версии рантайма зависит слабо.
Так и хочется вам сказать, идите уже на… отдельный чат со своим .NET Core…
> Вот с этих слов обычно и начинаются проблемы…
А какие проблемы у вас были с обратной совместимостью в дотнете, особенно в рамках одной мажорной версии?
Я вот просто читаю, и ощущение, что докер нужен потому, что у вас остальной инструмент кривой, отсюда и желание «собрать и не трогать, пока что-то не отвалилось».
А какие проблемы у вас были с обратной совместимостью в дотнете, особенно в рамках одной мажорной версии?
Я вот просто читаю, и ощущение, что докер нужен потому, что у вас остальной инструмент кривой, отсюда и желание «собрать и не трогать, пока что-то не отвалилось».
Я вот просто читаю, и ощущение, что докер нужен потому, что у вас остальной инструмент кривой
Хм, читаю я вот вас, и ощущение такое, что опыт у вас специфический и узкоспециализированный. Дело в том, что любой, без исключения, инструмент — кривой. Дело только в степени кривизны.
При этом у нас есть две стороны процесса: экосистема разработки, в которой могут и разрабатывают в той среде, которая наиболее подходит для языковой среды, и экосистема эксплуатации, где принято применять методы, наиболее нативные в рамках выполняемой задачи. И вот эти экосистемы несколько разные, а желание иметь универсальный инструмент, позволяющий сгладить некоторые углы гетерогенных продуктов, а также гетерогенных сред эксплуатации — достаточно нормальная вещь.
> Дело только в степени кривизны.
То есть проблем с обратной совместимостью дотнета вы тоже не видели.
Конечно углы сглаживать нормально. Поэтому ненормально, когда виртуальная машина исполнения кода обратной совместимости не имеет и возникает желание тащить бета-версию в продакшн, навесив ради этого сверху докер
То есть проблем с обратной совместимостью дотнета вы тоже не видели.
Конечно углы сглаживать нормально. Поэтому ненормально, когда виртуальная машина исполнения кода обратной совместимости не имеет и возникает желание тащить бета-версию в продакшн, навесив ради этого сверху докер
То есть проблем с обратной совместимостью дотнета вы тоже не видели.
Ну йошкин кот, кто о чем, а вшивый о бане. docs.microsoft.com/ru-ru/dotnet/framework/migration-guide/net-framework-4-migration-issues — вот тут ласково намекают, что миграция не в 1 клик делается, а значит два фреймворка тащить за собой может понадобиться, что не есть хорошо.
Ну и, собственно, если вы разработчик .NET Framework — относительно докера можете смело проходить мимо, т.к. это не ваш инструмент. Собственно, докер на вашей целевой платформе (aka Windows) — явление достаточно странное и чужеродное, в жутко зачаточном состоянии.
А вот если вы на .NET Core пишете, тут вопрос другой.
docs.microsoft.com/ru-ru/aspnet/core/migration/21-to-22?view=aspnetcore-2.2&tabs=visual-studio — вот тут прямо говорят, как и откуда докер-образы брать. Отличная штука, если деплой-таргет для вас — кубернетс или какой-нибудь облачный провайдер контейнерной изоляции.
Поэтому ненормально, когда виртуальная машина исполнения кода обратной совместимости не имеет
Ну неправда же. Если виртуальная машина обратной совместимости не имеет — вполне нормальная и местами предпочтительная ситуация. Минималистичная шустрая ВМ под строго одну версию рантайма — это всяко лучше, чем монструозная фигота, обвешанная костылями вида
if(vm.version < 261) {...} else {...} Не говорите мне, пожалуйста, что костыли и заботливое бекпортирование багов из старых версий «для совместимости» — это хорошо. Вот ни разу.Вот, собственно, для таких вещей, где рантайм менее, кхм… универсален, скажем так, и пилят докер.
возникает желание тащить бета-версию в продакшн, навесив ради этого сверху докер
В продакшен может возникнуть желание затащить какую-нибудь легаси-фиготу, которая на сколько-нибудь свежем фреймворке работать отказывается. И вот тут лучше иметь инструмент запустить ее изолированно насколько это возможно, чтобы она не мешала более «современным» соседям, чем этого инструмента не иметь.
При чем тут миграция? Я могу еще мануал по миграции с плюсов на шарп найти. Это разные фреймворки, на машине стоят одновременно. Разные, понимаете? Вообще. Только название семейства общее.
Поэтому любая легаси хоть под .net 1.1 запускается как родная
всяко лучше, чем монструозная фигота
Понимаете, мало назвать фиготой, что бы этим использование другой монструозной фиготы обосновать.
что бы этим использование другой монструозной фиготы обосновать.
Ну, как бы, в сравнении с контейнерной изоляцией, которая, по факту, управлялка над механизмами изоляции ядра (cgroups, namespaces)… Ну, как бы, да, .NET Framework — монструозная фигота)
Т.е. на винде оно действительно монструозная фигота, но на виндоус никто на полном серьезе вам докер юзать и не предлагает. А на линуксах всяческих докер — это именно что управлялка над механизмами изоляции ядра. Ничего монструозного там нет.
И да, еще раз, если вы — разработчик .NET Framework, докер не для вас. Ну вот не пролазит windows-only фреймворк в концепцию, ничего не поделаешь. Так и запишите: «Конкретно в моем случае — не подходит, лишний геморрой и пятая нога для собаки». Только не кричите «докер плохой» и «контейнерная виртуализация нинужна», перефразируйте на «лично мне контейнерная виртуализация не подходит, очень жаль».
Это разные фреймворки, на машине стоят одновременно. Разные, понимаете?
Понимаю, что разные, отлично понимаю, только не нервничайте. Я вот только не понимаю, допустим, в случае, если у меня 10 серверов, на которых крутится 50 сервисов, 3 из которых просят .NET Framework 1.1 и планируются к замене в обозримом будущем… Вот реально, мне на все 10 серверов по .NET Framework 1.1 раскатать? Вы уверены, что «изолировать легаси» не будет лучшим решением?
Поэтому любая легаси хоть под .net 1.1 запускается как родная
Чтобы она запустилась «как родная», нужно сначала еще один фреймворк рядом вкорячить. А потом вдруг выяснить, что какой-то кусок легаси внутрях содержит unmanaged код, которому требуется версия библиотеки, которая роняет мой распрекрасный самый ультрасовременный .NET Framework самой что ни на есть стабильной версии.
Понимаете, конкретно для .NET Framework оно слабоприменимо, и юзать его нужно только в очень особенных конкретных случаях. Собственно, именно под вашу экосистему контейнерную изоляцию никто никогда не точил (да и не будет), первые подвижки начались буквально год-другой назад (сомнительной надобности, скорее хайповые). Инструмент более универсален, и очень полезен в тысяче и одном случае за пределами вашей экосистемы. Вы же приходите и кричите, что он не нужен.
Ну вот нужен, много кому нужен. Признайтесь, вам просто завидно, что другие пользуют и довольны, а вам все никак ко двору не приходится.
Перейдите хотя бы на .NET Core, тогда и смотрите, придется ли оно вам к месту. Сама экосистема разработки под .NET Framework старше, чем cgroups, поверх которых уже сильно потом контейнеры росли. Зря ругаетесь, вас уже не сломают, и лучше просто не следите за новостями, не портите себе нервы.
Ну, как бы, в сравнении с контейнерной изоляцией,
Сравнением чего? Одного костыля, который вы нашли? Нет, передергиванием докер тоже не оправдать.
Только не кричите «докер плохой» и «контейнерная виртуализация нинужна»
Это где вы такое у меня нашли? Или просто такой метод дискуссии, приписать мне что-то и с этим спорить?
Зачем докер нужен я понимаю. Зачем он нужен каждому — нет.
Вот реально, мне на все 10 серверов по .NET Framework 1.1 раскатать?
А раскатать докер с образами из тех же файлов чем именно проще? Напомню, версий там за 20 лет — по пальцам одной руки.
потом вдруг выяснить, что какой-то кусок легаси внутрях содержит unmanaged код, которому требуется
Я, почему-то, уверен, что смогу написать код, который не заработает в докере на линуксе старше таргета на 18 лет. Но да, если(!) мне в этой жизни встретится такое, что библиотека ломает фреймворк а винду гоняет в BSOD, а я эту хтонь нести на продакшн должен доверить… А что, в линуксе так часто?
Признайтесь, вам просто завидно, что другие пользуют и довольны
Удивительно, что вы одновременно доказываете, что он как собаке пятая нога лет дцать, но завидовать я должен изобретению костыля для решения давно отсутствующей у меня проблемы в другой экосистеме.
Нет, передергиванием докер тоже не оправдать.
Осталось понять, зачем его «оправдывать». Отличный инструмент, в оправданиях не нуждается.
Одного костыля, который вы нашли?
Ну вот видите, «костыль». Докер — не костыль, а средство доставки приложения.
Зачем он нужен каждому — нет
Ну вот теперь вы перечитайте, что я писал. Где же вы увидели, что докер нужен каждому. Я даже, более того, прямо написал, что разработчику на .NET Framework, например, он не только не нужен, а даже, скорее, противопоказан. Есть более другие разработчики, им нужен. А вы эгоцентрист, видимо.
А раскатать докер с образами из тех же файлов чем именно проще?
Тем, что не все задачи можно/стоит покрывать средствами одной языковой экосистемы. А докер — инструмент универсальный. Т.е. им можно покрыть и .NET Core, и PHP, и Node.js. И сделать это, с точки зрения доставки приложения на сервер, одинаково.
Я, почему-то, уверен, что смогу написать код, который не заработает в докере на линуксе старше таргета на 18 лет.
Я вот, почему-то, уверен, что докер в принципе не запустится на линуксе 18-летней давности, например.
Но да, если(!) мне в этой жизни встретится такое, что библиотека ломает фреймворк а винду гоняет в BSOD, а я эту хтонь нести на продакшн должен доверить… А что, в линуксе так часто?
Это не в линуксе, это в прекрасном мире энтерпрайза.
Удивительно, что вы одновременно доказываете, что он как собаке пятая нога лет дцать, но завидовать я должен изобретению костыля для решения давно отсутствующей у меня проблемы в другой экосистеме.
Ну вот, опять вы что-то выдумали. «я должен», «в другой экосистеме» — я же вам сразу сказал: «Вам в ваших задачах не подходит, проходите мимо».
Это не в линуксе, это в прекрасном мире энтерпрайза.
На винде? Часто? И до сих пор никто не спешит докер прикрутить, все молча страдают?
Ну ладно, на этой ноте поздравляю с появлением наконец универсальных средств доставки, работающих не везде, и, действительно, пойду.
На винде?
Платформо-агностически. Т.е. на «везде». Например, в 2015 году (насчет после не знаю, не работаю уже там) в некоторой достаточно крупной организации имелась необходимость крутить АРМ оператора, написанный на Clipper'е. DOS-only, последний стабильный релиз языка — 1997 год. И человек, вроде вас, утверждающий «все это говно, надо переписать, работать не будет» — тоже был. Ну, т.е. остановить прием платежей от населения на полгодика в масштабах области и переписать не спеша… Был. Уволили к хренам, потому что «энтерпрайз».
Часто?
Достаточно часто, достаточно масштабно, с различной степенью обоснованности подхода.
И до сих пор никто не спешит докер прикрутить, все молча страдают?
Чоэта страдают? Вот, пилят, например. И WSL пилят, причем тот же Microsoft, который нежно любимый вами .NET пилит. При этом под ASP.NET Core его даже очень рекомендуют… Видимо, это кому-нибудь нужно, ага. А страдать… Не, не страдают. Страдать — это к вам, остальным работу работать.
поздравляю с появлением наконец универсальных средств доставки, работающих не везде,
Кхм, вы на полном серьезе противопоставляете средства доставки в пределах программного стека средствам доставки в пределах экосистемы задач? Ну, Г-дь вам судья.
работающих не везде,
«Работающие везде» нереализуемо.
и, действительно, пойду
Действительно, идите. А то выглядите как дантист на слете сантехников, вопрошающий окружающих «а вот почему я должен в работе использовать газовый ключ, им же неудобно зубы рвать» в ответ на… на отсутствие призывов использовать инструменты сантехников в работе дантистов.
Кто-то слышал, что в 2015 было приложение, поэтому надо насаждать докер, ОК. У вас все аргументы «а вы на шкаф залезте».
Кхм, вы на полном серьезе противопоставляете средства доставки в пределах программного стека средствам доставки в пределах экосистемы задач?
Вы, видимо, не очень знакомы со средствами доставки на винде. Ну и ладно.
Кто-то слышал, что в 2015 было приложение
Не кто-то, а я. Не слышал, а видел…
поэтому надо насаждать докер
Поэтому в определенном спектре задач контейнерная изоляция дает весьма ощутимые плюшки. Если вы не решаете задачи из спектра, покрываемого контейнеризацией, «насаждать докер» не надо. Откуда вы постоянно берете, что я вас убеждаю всенепременно докер использовать? Вот откуда? Четыре сообщения подряд пишу «не используйте докер, лично вам он не подходит», нет, в каждом ответе вы обвиняете меня в том, что я вас к чему-то принуждаю…
У вас все аргументы «а вы на шкаф залезте».
У меня аргументы «если вы дантист, перестаньте шляться по сходкам сантехников в попытках убедить окружающих, что газовый ключ — говно».
Вы, видимо, не очень знакомы со средствами доставки на винде.
Вы, видимо, вообще не знакомы со средствами доставки за пределами винды… И?
> в определенном спектре задач контейнерная изоляция дает весьма ощутимые плюшки
И Ваш пример — в спектре доставки АРМ под DOS, внезапно ставший проблемой.
И Ваш пример — в спектре доставки АРМ под DOS, внезапно ставший проблемой.
И Ваш пример — в спектре доставки АРМ под DOS, внезапно ставший проблемой.
Мой пример иллюстрировал некорректность вашего высказывания «Но да, если(!) мне в этой жизни встретится такое, что библиотека ломает фреймворк а винду гоняет в BSOD, а я эту хтонь нести на продакшн должен доверить… А что, в линуксе так часто?» Линукс тут совершенно ни при чем, есть определенные задачи, которые нужно решать, а ваше «а у нас в .NET лучше» или «у нас такого треша нет» — дело строго второстепенное. Деньги платят за задачу, а не за экзерцисы с любимым стеком технологий.
Если хотите посмотреть на задачи, в которых контейнеры хороши — велкам. Есть серверы, 5 штук. На них надо хостить 50 мелких интернет-магазинов, которые работают на 10 версиях PHP и 2 версиях Django. При этом хочется отказоустойчивости и автомиграций.
Подскажете, что справится с этой задачей лучше контейнеризации?
Мой пример иллюстрировал некорректность вашего высказывания
То есть я вам пишу про библиотеку, ломающую фреймворк, а вы мне ответом про приложение под DOS показываете некорректность? Оок )
Интересно только зачем, если к контейнерам это отношения не имеет.
работают на 10 версиях PHP
ДЕСЯТЬ несовместимых версий. Как я скучно живу. Подозреваю, что эта коллекция вовсе не с 1997 года началась…
У нас готовое приложение на java, завёрнутое в докер весит не больше 200(!) мегабайт, хотя я и такого не смог найти. Не больше 150 выходит.
Но у нас микросервисы, которые не совсем и микро, просто разделены на функциональные компоненты и не повторяют костыли одного и того же, если уже есть сервис с нужным функционалом.
Все зависимости, абсолютно все, нужные для работы приложения уже включены в этот образ. И это при том, что используется довольно объёмный spring boot(который тянет за собой всё, что только можно).
Образ одного, так сказать, самого большого по количеству интеграций и функций, backend-приложения — 140мб. Из них 70мб — само приложение и 70 мб чисто окружения-alpine
Собственно, к чему это я — что у вас там за безумные приложения, что тянут за собой зависимости в 1гб(!) и при этом сам образ под гб доходит? Реально интересен функционал, который требует таких размеров?
Но у нас микросервисы, которые не совсем и микро, просто разделены на функциональные компоненты и не повторяют костыли одного и того же, если уже есть сервис с нужным функционалом.
Все зависимости, абсолютно все, нужные для работы приложения уже включены в этот образ. И это при том, что используется довольно объёмный spring boot(который тянет за собой всё, что только можно).
Образ одного, так сказать, самого большого по количеству интеграций и функций, backend-приложения — 140мб. Из них 70мб — само приложение и 70 мб чисто окружения-alpine
Собственно, к чему это я — что у вас там за безумные приложения, что тянут за собой зависимости в 1гб(!) и при этом сам образ под гб доходит? Реально интересен функционал, который требует таких размеров?
Вы забыли слезы разработчиков.
А если серьезно, то реальный оверхед добавляют разве что докеровские сети, но для большинства проектов даже он ничтожно мал.
А если серьезно, то реальный оверхед добавляют разве что докеровские сети, но для большинства проектов даже он ничтожно мал.
Что-то мимо вообще. По памяти и диску от докера оверхед настолько минимален, что его можно списать в статпогрешность.
Я бы понял, если бы вы на сеть жаловались. Там и x3 расход сокетов, и некоторые задержки от виртуализации таки есть, в некоторых случаях вообще на проце считает… Но тут уж просто замеряйте, хватает вам latency, или докер не для вас…
Я бы понял, если бы вы на сеть жаловались. Там и x3 расход сокетов, и некоторые задержки от виртуализации таки есть, в некоторых случаях вообще на проце считает… Но тут уж просто замеряйте, хватает вам latency, или докер не для вас…
> Зачем искать лень там, где этот вид работ можно устранить докером как класс?… девы перестают валять lдурака… девы начинают думать мозгами
Дайте угадаю, вы не дев?
Ну то есть, перекладывание с больной головы на здоровую? Теперь дурака валять могут админы.
Дайте угадаю, вы не дев?
Ну то есть, перекладывание с больной головы на здоровую? Теперь дурака валять могут админы.
Я был девом лет 15, но последние лет 5 поневоле стал кем-то вроде SRE / архитектора. И программерский опыт очень помогает понимать, как именно могут нашкодить девелоперы, особенно современные.
Трава зеленее, деревья выше, «были люди в наше время».
Не писать код и ходить с умным видом рассказывать как быть правильным программистом — дело не хитрое. Только почему-то как открываешь код богатырей былых лет — глаз дергается.
А внедрять девопс через боль, рассказывая как вы тут все молодежь шкодите, получайте…
Не писать код и ходить с умным видом рассказывать как быть правильным программистом — дело не хитрое. Только почему-то как открываешь код богатырей былых лет — глаз дергается.
А внедрять девопс через боль, рассказывая как вы тут все молодежь шкодите, получайте…
Я ведь не про идеальный код, а про доставку продукта и то, как докеризация её унифицирует. Это вне времени. А всяких художников, знающих лучше операционщиков, как их поделие должно запускаться и каких проблем в продакте не бывает, или наоборот, желающих писать только код, но не желающих даже задумываться, как оно в лайве будет работать — я уже навидался. В общем-то и сам таким по молодости был, в том и пойнт, что девелоперский опыт — мас хэв для SRE/DevOps, что бы ставить процесс.
Меня то удивил поинт про нанесение пользы и принуждение думать через внедрение неудобств при разработке. Индифферентно к докеру. Как только человек 2 недели код не пишет — опыт вытесняется и включается «да что ж вы так плохо/медленно/не так делаете», а мысли ставить процесс так, что бы минимизировать ущерб перестают считаться конструктивными.
Как доставка продукта происходила мне сложно оценить, а код этих гордых титанов прошлого остается.
Как доставка продукта происходила мне сложно оценить, а код этих гордых титанов прошлого остается.
а как поднять микросервисы без того-же lxc/docker и иже с ними?
виндузообразными чудо-дистрибами где все проги ставятся в отдельный каталог.
Если вы про NixOS и GuixSD, то они решают не только и не столько эти проблемы. Для начала, они требуют от пользователя отличного понимания принципов работы, но только уже не только Linux, а ещё и своей системы конфигурации и сборки пакетов. Более того, и nix, и guix вполне себе интегрированы с докером и взаимодополняются с ним. Взять тот же nix-bundle и nix-docker, и guix --compose. Если вы про ещё какие-то дистрибутивы, то можно поподробнее?
К счастью, рынок большой, помимо хипстоты, есть и более консервативные конторы или хотя бы отделы.
Сноба в тебе вижу я…
С точки зрения прогера-админа, docker «классическое нинужно», тем более он не первый, их как грязи было, есть и будет.
С точки зрения бекенд-разработчика докер «классическое нужно», я бы сказал. Хотя он не первый, их было и будет — ага. При этом порядковый номер технологии, как правило, мало говорит о ее полезности.
Всяких разных вариаций, начиная древними LXC, продолжая всякими snap-пакетами и виндузообразными чудо-дистрибами где все проги ставятся в отдельный каталог.
Что-то вы и LXC в старье запихали, и snap в ту же кучу замешали…
НЛО прилетело и опубликовало эту надпись здесь
Делал контейнер из Windows приложения и Wine. Такая себе штука этот ваш Docker. Мне лично показалось что проще было бы все поставить на целевой машине чем тащить в Docker.
Говорить, что Docker говно — все равно, что говорить: «отвертка — говно, так как хреново забивает гвозди!»
Есть инструмент — его нужно использовать там, где НУЖНО!
Из моего опыта — работа в студии… за день можно поработать с 3-мя проектами, которые используют разные базы, разные версии PHP, где-то Апач, где-то Нжинкс… я хз что бы делали без докера и докер-композера… а так: down/cahnge_project/up — и окружение полностью изменилось…
Есть инструмент — его нужно использовать там, где НУЖНО!
Из моего опыта — работа в студии… за день можно поработать с 3-мя проектами, которые используют разные базы, разные версии PHP, где-то Апач, где-то Нжинкс… я хз что бы делали без докера и докер-композера… а так: down/cahnge_project/up — и окружение полностью изменилось…
НЛО прилетело и опубликовало эту надпись здесь
На проде у него своя ниша. Это микросервисы плюс k8s, nomad и т.п.
Если тянуть на прод через docker-compose будет очень быстрое и простое первоначальное разворачивание приложения. И большие проблемы с деплоями.
Отдельного внимания базы данных + docker + k8s
Многие почему-то хотят этого. И теперь это уже почти возможно (то есть возмодно но неясно чтоб будет при падении базы данных — молча создасться нвоый экземпляр неизвестно на коком поде?) По-моему от связки базы данных + docker + k8s необходиом отказаться сразу и навсегда
Если тянуть на прод через docker-compose будет очень быстрое и простое первоначальное разворачивание приложения. И большие проблемы с деплоями.
Отдельного внимания базы данных + docker + k8s
Многие почему-то хотят этого. И теперь это уже почти возможно (то есть возмодно но неясно чтоб будет при падении базы данных — молча создасться нвоый экземпляр неизвестно на коком поде?) По-моему от связки базы данных + docker + k8s необходиом отказаться сразу и навсегда
И теперь это уже почти возможно (то есть возмодно но неясно чтоб будет при падении базы данных — молча создасться нвоый экземпляр неизвестно на коком поде?) По-моему от связки базы данных + docker + k8s необходиом отказаться сразу и навсегда
Вот так плодятся страшные мифы. Помимо того, что в k8s есть куча вещей для stateful подов, каждая база имеет возможности для кластеризации, которые успешно интегрируются со всем этим безобразием. Разумеется, один экземпляр бд так запускать нельзя, но репликации и прочие штуки творят чудеса.
Это вы так думаете, что репликая и прочие штуки творят чудеса. Проблематика в том, что существует куча легаси баз, которые не умеют в кворум и консенсус. Что с ними делать? Мучительно больно обмазывать очередными слоями абстракции, чтобы упихать в кубер? А не проще что-то типа RDS от Амазона использовать или любой другой managed инстанс и не ломать голову? Вот в результате и появляются мегаподелки вроде Stolon для постгрес (я, кстати, не говорю, что он плохой — скорее овер-усложненный). К сожалению, множество проектов пока не готово переехать на БД нового поколения типа Cockroach, да и то — там своих подводных камней хватит (точно проверяли на отказоустойчивость во всех сценариях отказов, split-brain etc?)
все зависит от задач, размеров, целей проекта. а хотите идеальную базу — аппаратный рейд 10, велкам.
Это вы так думаете, что репликая и прочие штуки творят чудеса.
Они не творят чудеса — они решают задачи. Если вас устраивает единая точка отказа, то, как бы, пожалуйста. Вот только потом окажется, что такую базу ни обновить, ни как либо обслуживать, ни даже конфигурацию логгирования подправить, потому что это все требует перезагрузки.
managed инстансы это тоже вариант, но по нормальному они внутри так же используют какие-то технологии кластеризации.
Вы не поняли, к сожалению, мой посыл. Как репликация вам поможет, если у вас нет отстрела мертвых нод кластера кубернетес? Повторюсь, что там еще придется кучей дополнительных решений обмазаться, чтобы это все работало хоть как-то надежно, да еще и в автоматическом режиме.
с чего Вы решили? Вы сами завели разговор про перенос баз в k8s. А там далеко не все так просто, как кажется.
Если вас устраивает единая точка отказа, то, как бы, пожалуйста.
с чего Вы решили? Вы сами завели разговор про перенос баз в k8s. А там далеко не все так просто, как кажется.
Для большого продакшена k8s, например, пилят. И даже используют. И даже успешно.
К слову, в k8s от самого докера — ничего. В смысле, вообще ничего. В кейсе k8s-продакшен докер используется как инструментарий для сборки образов, остальное у k8s свое.
Единственное, что действительно смущает во всей истории с linux-контейнерами — это как раз «средняя» ниша. Есть сам docker, который отлично работает в качестве инструмента сборки и тестирования в пределах 1-хостовой инсталляции. Есть k8s, который оправдан на мега-деплоях. А вот чего-то из разряда «у меня тут пара небольших серверов есть» надежного и обкатанного нет. Хоть оно и понятно, почему так.
К слову, в k8s от самого докера — ничего. В смысле, вообще ничего. В кейсе k8s-продакшен докер используется как инструментарий для сборки образов, остальное у k8s свое.
Единственное, что действительно смущает во всей истории с linux-контейнерами — это как раз «средняя» ниша. Есть сам docker, который отлично работает в качестве инструмента сборки и тестирования в пределах 1-хостовой инсталляции. Есть k8s, который оправдан на мега-деплоях. А вот чего-то из разряда «у меня тут пара небольших серверов есть» надежного и обкатанного нет. Хоть оно и понятно, почему так.
K8S это ведь не про размеры, это про автоматизацию. У нас он (k8s) на трёх небольших серверах крутится и мы его взяли не из-за размера, а так-как нам нужено было автоматизировать некоторые вещи и на чистом докере можно было бы тоже сделать, но уже намного сложнее.
K8S это ведь не про размеры, это про автоматизацию.
Про оркестрацию, я бы сказал. Это, все-таки, достаточно развесистый фреймворк оркестрации с достаточно высоким «порогом вхождения».
У нас он (k8s) на трёх небольших серверах крутится
Потому что кластер «должен иметь минимум 3 ноды, лучше если больше». С кубером, честно говоря, чем больше размер кластера, тем более очевиден «выхлоп» от внедрения k8s.
Для сетапов типа «два дублирующих сервера» и прочих средне-мелких инсталляций k8s — жесточайший оверхед, а альтернатив уровня «взрослости» k8s нет и, собственно, не предвидится по вполне очевидным причинам (потому что «а кому это надо», точнее «кто оплатит банкет»).
Т.е. именно «у меня тут пара небольших серверов есть»-кейс не покрыт ничем вменяемым, вот я про что.
а альтернатив уровня «взрослости» k8s нет и, собственно, не предвидится
В nomad есть много что нужно (хотя не все что есть в k8s)
Ничего не мешает запустить k8s в том же GKE. Расходов на мастера там нет и можно хоть одну ноду делать, вообще без разницы. Смысла в этом конечно мало, но все же можно, я делал :)
Из минусов — при обновлении кластера может быть простой. Но с одной нодой как бы… это нормально.
Из минусов — при обновлении кластера может быть простой. Но с одной нодой как бы… это нормально.
Смысла в этом конечно мало
Вот, оно!)))
Ну если очень хочется сделать проект на k8s, но у вас только блог на 50 человек? Это отличный первоначальный опыт, кстати :)
- для того чтобы мое приложение работало, нужен сам 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.
doсker отличнейший инструмент, просто
А. надо уметь его готовить
В. не запихивать его везде где можно, только потому, что могу.
а нужно ли всех слушать? у нас вот сидит тут девопс, который впервые в жизни графану у меня на мониторе увидел)
А. надо уметь его готовить
В. не запихивать его везде где можно, только потому, что могу.
Недавно (тройку месяцев назад), я поработал с DevOps командой, почти каждый участник которой, негативно относился к docker
а нужно ли всех слушать? у нас вот сидит тут девопс, который впервые в жизни графану у меня на мониторе увидел)
FreeBSD, Jail и Ansible — это все что нужно.
Докер удобен для разработки. Хорошо, когда скачал образ БД и он крутится локально, не нужен интернет. И еще я могу установить нужную мне БД с точностью до минорной версии, а не подключать PPA в виртуалке.
Как там вам собирать по 5-10 разных проектов с разными зависимостями и бинарными либами. Ставите максимум из этих либ на сервер или под каждый проект новый сервер? Или ждете, пока все накатится каждый раз с нуля?
а по мне так Nix Package Manager решает все эти проблемы без всяких контейнеров
Для меня как-то странно сравнивать docker и ansible. Это как утверждать что вилка отстой и надо пользоваться ложкой. А если ansible билдит, запускает и скейлит докер контейнеры… Да не, глупости…
Просто оставлю тут пару цитат из статьи выше:
Как хорошо что не придется занимать место еще сотней мегабайт и уже скачана на сервере нужна версия node/jre.
Так хотелось бы что бы docker-compose делал еще кофе по утрам.
Действительно, где это видано доки читать в 2019 году.
Ну тут очевидно виноват докер.
Хочу что бы по щучьему велению.
Обещаю что буду осторожен.
docker load
То ли дело ansible.
p.s. С нетерпением жду следующую статью.
В качестве виртуальной машины на локали можно использовать тот же 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, то:
- будьте предельно осторожны
Обещаю что буду осторожен.
если я хочу запустить свой (приватный) локально собранный образ на удаленном сервере, то мне нужен свой docker репозиторий,
docker load
90% что нужно пробросить какие нибудь ssh ключи, секретные данные, которые не хочется писать в docker образ.
То ли дело ansible.
p.s. С нетерпением жду следующую статью.
сарказм принят
Лучший комментарий из всех. Сложилось ровно такое же впечатление от статьи. «Не осилил забить отвёрткой гвоздь, нашёл долото… О, а им получилось!!1»
Действительно, где это видано доки читать в 2019 году.
Так хотелось бы что бы docker-compose делал еще кофе по утрам.
Я люблю читать тех информацию и применять ее в реальных проектах. Docker-compose это инструмент для запуска docker контейнеров, мне жалко тратить время на инструмент который я смогу применить в ограниченном круге, к тому же у него есть свои косяки и свое видение как должен выглядеть yml и как запускать контейнеры.
Ну тут очевидно виноват докер.
Нет, просто docker имеет низкий порог вхождения и к сожалению люди пишут криво
docker load
И эту процедуру нужно постоянно делать при каждом деплое?
Я люблю читать тех информацию и применять ее в реальных проектах. Docker-compose это инструмент для запуска docker контейнеров, мне жалко тратить время на инструмент который я смогу применить в ограниченном круге
Любой инструмент можно и нужно применять «в ограниченном круге». Ограниченном предназначением инструмента. Docker-compose — это инструмент для запуска docker-контейнеров, да. Было бы странным применять его за пределом «ограниченного круга» запуска контейнеров. У него, простите, и спецификация соответствующая — коротенькая такая, со вкусом, ничего лишнего, быстро «раскурить» можно.
к тому же у него есть свои косяки и свое видение как должен выглядеть yml
Не, тут вы наговариваете. Строго стандартный yml, в строгом соответствии со спецификацией.
и как запускать контейнеры.
Ну, тут, конечно, у всех свое видение. Собственно, можно и
docker run, никто не запрещает. А docker-compose, по факту, тупо берет совершенно обычный yaml-файл, совершенно обыденно парсит его в древовидную структуру в памяти, а затем тупо выполняет команды вроде docker run до просветления… Никто не запрещает сделать то же самое руками.Нет, просто docker имеет низкий порог вхождения и к сожалению люди пишут криво
Причисление низкого порога вхождения к недостаткам инструмента, простите, отдает снобизмом. Особенно для человека, который «мне жалко тратить время на инструмент который я смогу применить в ограниченном круге» (т.е. не осилил docker-compose).
И эту процедуру нужно постоянно делать при каждом деплое?
По разному можно. Можно, например, автоматизировать docker load. А можно и приватный репозиторий поднять, чтобы не scp-шить, например. Там тоже рокет-сайенса нет.
Ну а что вы хотели? Автор совсем недавно открыл туннелирование и ВПН и не хочет изучать документацию к инструменту с которым работает, а вы про yaml… Тоже, скорее всего, технология с ограниченным применением не заслуживающая изучения документации.
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. Он намного лучше json
Впн я давно использовал в компаниях где были админы и настраивали его сами. Про ssh туннели я не знал, да, но как то пользовался пробросом портов в `kubectl`, думал это специфичная штука кубера
Вопрос: Зачем изучать docker-compose если есть инструмент с более широким применением?
Далее, какие есть варианты запуска контейнера на удаленной машине? (вангую сейчас скажете про docker swarm и его поддержку docker compose формата)
Когда то нравился compose, но сейчас нет, потому что это оверхед над docker api. Натыкались на такие issue? github.com/docker/compose/issues/3574
а вы про yaml… Тоже, скорее всего, технология с ограниченным применением не заслуживающая изучения документации.
Мне нравится декларативное описание в yaml. Он намного лучше json
Автор совсем недавно открыл туннелирование и ВПН и не хочет изучать документацию к инструменту с которым работает,
Впн я давно использовал в компаниях где были админы и настраивали его сами. Про ssh туннели я не знал, да, но как то пользовался пробросом портов в `kubectl`, думал это специфичная штука кубера
Тоже самое использует 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 докеру, вообще никак. И для разработчика это такой лютый оверхед, что прям свят-свят с этим связываться.
Насчёт ансибла категорически не согласен. Да, возможно, что для "чистого" разработчика его его функциональность избыточна, но с той же стороны — кто мешает его товарищу, который больше шарит в ОПС части, настроить основное и показать, куда нужно вносить изменения в случае чего?
Да и "чисто" разработчики сейчас не в цене, а T-shaped персоны, которые имеют широкий кругозор, но и узкую специализацию
Насчёт ансибла категорически не согласен. Да, возможно, что для «чистого» разработчика его его функциональность избыточна
Не «возможно», а «совершенно точно»)
кто мешает его товарищу, который больше шарит в ОПС части, настроить основное и показать, куда нужно вносить изменения в случае чего?
Вижу 3 проблемы:
1. Надо сначала найти товарища, который «настроит основное и покажет». Это либо «повезло», либо это дополнительные финансовые траты.
2. Если вам «настроят основное», понимания процесса у вас не появится. Дальнейшие правки все равно неизбежны, т.е., опять же, придется либо изучать, либо крепко дружить с человеком, который «умеет» (на какой итерации «слушай, тут поправить надо чуть-чуть, посмотри, пожалуйста» ваша дружба закончится), либо платить.
3. Мы добавляем в проект совершенно избыточный, достаточно «комбайнерский» стек, с достаточно высоким порогом вхождения. И это при том, что на выходе мы все равно должны отдать собранный контейнер? И для этого есть инструменты сильно проще, а местами и тупо набором bash-скриптов обойтись можно…
Короче, ваш подход, он, возможно, оправдан, но исключительно в одном достаточно редком кейсе: относительно крупная разработческая контора, достаточно крупная для содержания пары ops-спецов, а лучше полноценного отдела эксплуатации. И вот если «эксплуатация» есть, и она вплотную использует ansible в своих задачах (т.е. есть действительно спецы в технологии) — тогда есть смысл «поделиться» с «разработкой» наработанными практиками.
В случае же, если сидят 3 программиста, один из которых считается «шарящим» в ансибле потому, что он доку 2 раза читал, а остальные только слышали название. Не, нет пути.
Да и «чисто» разработчики сейчас не в цене, а T-shaped персоны, которые имеют широкий кругозор, но и узкую специализацию
Вы эта… Широкий кругозор с узкой специализацией не смешивайте. Если ваш специалист самым краем своего «широкого кругозора» зацепил какую-то блестящую технологию, это совершенно не повод ее повсеместно внедрять. Внедрять нужно ту технологию, по которой спецы есть.
И да, и нет. Вы ещё скажите, что разработчики вагрант не должны знать :-) Между прочим, очень крутая штука, которая экономит кучу времени на разработку и отладку.
Вообще проблема в том, что если разработчик будет знать только как кодить, то он не нужен. Ну, напишет он что-то, а оно нагрузочные тесты не пройдет (еще вопрос имеются ли они в проекте). И что? Кто будет исправлять? «DevOps»? Тестировщики? Представьте сколько человеческих ресурсов уйдет вхолостую. А если бы у него был чуточку более широкий горизонт знаний, то проблема может быть и не возникла.
И, да, собирать образы ансиблом — такое себе удовольствие. Запускать — да, почему нет, если действительно в проекте что-то сложнее «docker run» с фиксированными аргументами.
Вообще проблема в том, что если разработчик будет знать только как кодить, то он не нужен. Ну, напишет он что-то, а оно нагрузочные тесты не пройдет (еще вопрос имеются ли они в проекте). И что? Кто будет исправлять? «DevOps»? Тестировщики? Представьте сколько человеческих ресурсов уйдет вхолостую. А если бы у него был чуточку более широкий горизонт знаний, то проблема может быть и не возникла.
И, да, собирать образы ансиблом — такое себе удовольствие. Запускать — да, почему нет, если действительно в проекте что-то сложнее «docker run» с фиксированными аргументами.
Вы ещё скажите, что разработчики вагрант не должны знать :-)
Вот, например, я действительно считаю, что vagrant разработчику знать совершенно не обязательно). Очень специфический инструмент, доложу я вам.
И, да, собирать образы ансиблом — такое себе удовольствие.
Совершенно верно. Очень такое себе.
Запускать — да, почему нет, если действительно в проекте что-то сложнее «docker run» с фиксированными аргументами.
Но для «запускать» есть более простые инструменты… Т.е. я о чем: если у вас в инфраструктуре ансибл задействован в миллионе мест — можно им еще и контейнеры попинать. Ничего предосудительного, у вас есть экспертиза в инструменте, его использовать логично, да и тянуть лишнюю технологию внутрь — зачем, если у вас уже есть то, что работает. Но вот идея притащить в проект ansible тупо с целью пинать контейнеры… Ну, я не знаю, Г-дь вам, видимо, судья.
Но вот идея притащить в проект ansible тупо с целью пинать контейнеры… Ну, я не знаю, Г-дь вам, видимо, судья.
Ну, вот идея притащить docker-compose, который вроде бы должен быть комбайном, умеющим все (сборка-запуск и пр.), но фактически сделан «как попало» — такое себе решение. И еще вопрос что хуже: docker-compose или ansible. Оба багованные.
Например, у меня было три кейса, которые с docker-compose не решаются в принципе:
1. шаблонизация docker-compose. Запуск разного количества контейнеров с разными параметрами в зависимости от… Решается наворачиванием jinja2 поверх. Либо можно сразу ansible (или любое другое)
2. шаблонизация docker-compose более сложная, чем просто подстановка переменных из ENV в нескольких местах. Опять же проще взять нормальный шаблонизатор типа jinja2, чем пытаться научить docker-compose чему-то новому. Можно там изворачиваться с override, extends, yaml anchor, но когнитивная сложность от этого не уменьшается.
3. запуск сервисов в определенном порядке. В рамках docker-compose можно костыльно решить через хелсчеки (ага, только во второй версии формата, т.к. только там есть depends_on: service_healthy). Либо docker-compose для описание списка сервисов и внешняя запускалка (bash? make?)
Как видите, все равно получается, что docker-compose не подходит как единственный инструмент, что сразу ставит вопрос, а зачем он нужен вообще.
Для чего он хорош — БЫСТРО и грязно запустить контейнер на машине разработчика.
Ну, вот идея притащить docker-compose, который вроде бы должен быть комбайном, умеющим все (сборка-запуск и пр.)
Это вы откуда взяли? В официально доке написано «Compose is a tool for defining and running multi-container Docker applications.» Переводим: «Тулза для определения(описания) и запуска мультиконтейнерных докер-приложений».
Описывает? Описывает. Запускает? Запускает. Выполняет фантазии пользователей — нет. Но он и не обещал.
шаблонизация docker-compose
Ну, видимо, не с той стороны зашли. Это примерно как шаблонизация json или xml. Тоже заранее утопичная идея. Распарсили в дерево, проставили нужные значения, сериализовали взад. А щаблонизировать не нужно, неудобно и больно.
шаблонизация docker-compose более сложная, чем просто подстановка переменных из ENV в нескольких местах
Вы это, видимо, еще и shell'ом делали. Гамак… Стоя… На лыжах…
запуск сервисов в определенном порядке. В рамках docker-compose можно костыльно решить через хелсчеки (ага, только во второй версии формата, т.к. только там есть depends_on: service_healthy). Либо docker-compose для описание списка сервисов и внешняя запускалка (bash? make?)
Официально так.
Как видите, все равно получается, что docker-compose не подходит как единственный инструмент, что сразу ставит вопрос, а зачем он нужен вообще.
Там же сразу так и написано: запустить мультиконтейнерное докер-приложение.
Для чего он хорош — БЫСТРО и грязно запустить контейнер на машине разработчика.
Воот, оно (плюс еще функция документирования запуска. Нормальный опс его прочитает и напишет вменяемый деплой. Не описание от разработчика в произвольной форме, а файл со спекой). А на сервер его тянуть не надо. Для оркестрации более другие методы есть.
Это вы откуда взяли? В официально доке написано «Compose is a tool for defining and running multi-container Docker applications.» Переводим: «Тулза для определения(описания) и запуска мультиконтейнерных докер-приложений».
разработчик продукта может писать что угодно. Например, что небо зеленое, а солнце черное. Только это к реальности отношения не имеет.
Ну, видимо, не с той стороны зашли. Это примерно как шаблонизация json или xml. Тоже заранее утопичная идея. Распарсили в дерево, проставили нужные значения, сериализовали взад. А щаблонизировать не нужно, неудобно и больно.
ну, почему нет? Что в этом плохого, что такая проблема встает снова и снова? Причем даже в рамках того, что предлагает docker-compose (запуск приложения, состоящего из связанного набора контейнеров).
Официально так.
это очередной костыль. Официально. Шикарно.
Воот, оно (плюс еще функция документирования запуска. Нормальный опс его прочитает и напишет вменяемый деплой. Не описание от разработчика в произвольной форме, а файл со спекой). А на сервер его тянуть не надо. Для оркестрации более другие методы есть.
Разрабы очень хотят видеть docker-compose на пре-продовых окружениях. А в идеале — и на проде (им же туда иногда нужно будет ходить, чтобы чинить баги).
Еще раз — думайте, что хотите. Понятно, почему так получилось — докер-компоуз пихался вперед самой Docker, Inc как способ описания контейнеров для сворма. Сворм не взлетел. Инвестировать в разработку обоих продкутов никто не будет. The End.
разработчик продукта может писать что угодно. Например, что небо зеленое, а солнце черное. Только это к реальности отношения не имеет.
Совершенно точно! Вы лучше, чем разработчик, знаете, какой функционал есть и должен быть у приложения! Никто даже не пытается оспаривать, ведь вы видите реальность, а остальные, не столь одаренные личности, тупо руководствуются документацией.
ну, почему нет? Что в этом плохого, что такая проблема встает снова и снова? Причем даже в рамках того, что предлагает docker-compose (запуск приложения, состоящего из связанного набора контейнеров).
Ужасная проблема! Прямо неразрешимая!
Вот с ходу набросал. Весь шаблонизатор, по факту, можете допилить, чего вам не хватает.
Тупо на вход даете путь до значения, которое нужно заменить и нужное значение. Типа
python templates-are-not-needed.py services.redis.image myAwesomeImage:3.0 — заменяет image в сервисе redis на новый. Чего не хватает? Проблему, блин, выдумали, и героически от нее страдаем.это очередной костыль. Официально. Шикарно.
Ну, если внимательно прочитать, для чего docker-compose предназначен, то все норм. А, точно! Вы же лучше знаете, что docker-compose — полноценный оркестратор (на самом деле — нет).
Разрабы очень хотят видеть docker-compose на пре-продовых окружениях. А в идеале — и на проде (им же туда иногда нужно будет ходить, чтобы чинить баги).
Я вот типа разраб. Я НЕ хочу видеть docker-compose не то на проде, но и близко на препродовом окружении. Для таких вещей есть более другие инструменты (которые, в свою очередь, тащить на машину разработчика — лютая ересь).
Вот с ходу набросал. Весь шаблонизатор, по факту, можете допилить, чего вам не хватает.
Отлично — вместо того, чтобы втащить в проект очередную зависимость типа j2cli (замечу — еще и качественную и отлаженную), Вы изобрели очередной велосипед. Браво!
А, точно! Вы же лучше знаете, что docker-compose — полноценный оркестратор (на самом деле — нет).
Не приписывайте мне не мои слова. Но, между прочим, да — docker-compose делался именно как способ декларативного описания контейнеров под swarm. Ах, да, так другого-то и нет!
Я вот типа разраб. Я НЕ хочу видеть docker-compose не то на проде, но и близко на препродовом окружении.
я тоже. Но это блокируется тем, что разрабы не хотят учить кубер и писать сразу нормальные манифесты. Да и кубик запустить локально не то, что сложно (в крайнем случае есть minikube и готовые образы вагранта), а скорее муторно и ресурсов есть поболе, чем просто запустить докер-контейнер.
Ужасная проблема! Прямо неразрешимая!
Тон свой сбавьте? Ваша ирония или сарказм и передергивания тут неуместны.
Отлично — вместо того, чтобы втащить в проект очередную зависимость типа j2cli (замечу — еще и качественную и отлаженную), Вы изобрели очередной велосипед. Браво!
Т.е. я правильно понимаю, что:
1. Вы жалуетесь, что вам не хватает шаблонизации в docker-compose конфигах.
2. Вы пытаетесь решить проблему генерации yaml (который, согласно официальной доке, is a human-readable data serialization language, т.е. человекочитаемый язык сериализации данных) шаблонами, у вас не выходит и вы сетуете на судьбу.
3. Вы серьезно уверены, что генерация «языка сериализации данных» из шаблона — хороший подход.
4. Вы считаете, что jinja каким-то образом решает проблему.
5. Извращенец здесь я.
Я все верно понял? Вместо того, чтобы работать с набором «словарей» как с данными (которыми они и являются), вы предпочитаете собрать текстовый шаблон (видимо, исходя из фразы «INI, YAML, JSON data sources supported» в доке. Точнее из знакомых букв YAML во фразе, игнорируя «data sources») и притащить шаблонизатор вместо инструмента управления данными в проект как совершенно необходимую зависимость — вот это то, чего не хватает docker-compose'у.
Ну, не знаю. Такое себе. Мой сниппет на десяток строк несколько более эффективно решает проблему, имхо. При этом с обработкой ошибок и сериализацией четко детерменированных данных вряд ли вылезет за пару сотен строк. Шаблонизатор же решает проблему… никак. Больше граблей.
Не приписывайте мне не мои слова. Но, между прочим, да — docker-compose делался именно как способ декларативного описания контейнеров под swarm. Ах, да, так другого-то и нет!
Я приписываю вам ровно ваши слова. «разработчик продукта может писать что угодно. Например, что небо зеленое, а солнце черное. Только это к реальности отношения не имеет.» — это ваше. Осталось только увидеть реальность, в которой docker-compose — полноценный инструмент оркестрации, которым вы его себе представляете, а не та запускалка, о которой говорится в официальной документации.
То, «как оно изначально задумывалось» — действительно не имеет общего с реальностью. Потому что изначальной задумке инструмент не соответствовал никогда, ни в единый момент времени. Наполеоновские планы разработчиков и расчет Docker.Inc на «взлет» Swarm — это хорошо, конечно, и никто не отрицает, что планы такие, очень вероятно, были. Но именно это отлично подходит под определение «влажные фантазии». Реальность, на которую вы так упираете говорит другое. В нашей существующей реальности в официальной доке написано, что компоуз — запускалка сгруппированных контейнеров по декларативному описанию. И ни одна из умелок компоуза этому не противоречит.
я тоже. Но это блокируется тем, что разрабы не хотят учить кубер и писать сразу нормальные манифесты. Да и кубик запустить локально не то, что сложно (в крайнем случае есть minikube и готовые образы вагранта), а скорее муторно и ресурсов есть поболе, чем просто запустить докер-контейнер.
Едрить, ну наконец-то! Область применения определена. Разраб, может быть, и написал бы манифест, но геморрой от развертывания локального кубера — это, если честно, совсем не то, чем стоит заниматься оплачиваемому разработчику. Есть более логичное применение его «талантам», и более эффективное с точки зрения КПД.
Сорян, конечно, но кубер, в сравнении с docker-compose выглядит примерно как космический шаттл рядом с телегой. Причем как по суммарной мощности аппарата, так и по потребляемым аппаратом ресурсам. Это вот прям тот инструмент, которому на машине разработчика не место.
Компоуз же — практически идеальный для девелоперских целей инструмент. 3 страницы документации суммарно, как-то работает, а для девелоперской среды зависимости можно разрешить тупыми задержками старта по эвристически вычисленным таймаутам.
Можно бесконечно обсуждать, чего на самом деле Docker.Inc хотелась добиться своим инструментом в идеале, но реальность (набор реально существующих и подтвержденных практикой обстоятельств) говорит нам, что compose — туповатая тулза, решающая ровно одну проблему. «Грязный запуск набора связанных контейнеров в дебажных целях» — единственная цель этого интрумента. Но именно в этой области применения ему равных-то и нет.
Вы мне, конечно, сейчас расскажете про идеального разработчика, который и в «кубер на атоме с гектаром оперативки развернуть» умеет. Практика же показывает, что в командах разработчиков от 3 голов и выше то, как это выглядит на проде, может интересовать примерно не более одного. Остальным нужна просто «запускалка». И это не делает их плохими разработчиками — вообще нет. Они могут писать охрененнейший оптимизированный идиоматичный код, и именно за это им платят. Просто в «девопсе» всегда кто-то больше «дев», а кто-то тяготеет в сторону «опса».
При росте команды девов (разработка) неизбежно выделяется опс-команда (эксплуатация). Просто потому, что растет экспертиза в эксплуатации, которая на старте тупо нулевая. И нет никакой сложной разработки и эксплуатации «для творцов попроще». Комплексность эксплуатации, по хорошему, сравнима, а местами и выше, чем комплексность разработки. Поэтому и инструменты соответствующие. В нормальной эксплуатации инструменты не менее сложны, чем стек непосредственно разработки, поэтому требовать от разработчика быть «опсом в довесок» — нечто, граничащее с маразмом.
Отсюда и docker-compose. Это инструмент для разраба. Он позволяет тупо запустить и потрогать без необходимости звать квалифицированного «эксплуататора». И здесь его область применения заканчивается — не надо его в прод тянуть. Но ничего лучше в этой нише нет — не надо тащить к разрабу на машину k8s, не нужен он там.
Вопрос: Зачем изучать docker-compose если есть инструмент с более широким применением?
Зачем пользоваться молотком, когда есть такой замечательный кухонный комбайн?
Далее, какие есть варианты запуска контейнера на удаленной машине? (вангую сейчас скажете про docker swarm и его поддержку docker compose формата)
Да миллион их. И вы ошиблись, ни docker swarm, ни docker-compose на проде я рекомендовать не буду. А оркестраторов — как конь… кхм… напривозил. Самое суровое решение — k8s. Самое простое — баш-скрипт по git-hook'у. Между ними — миллиард вариантов, выбирайте на вкус.
Когда то нравился compose, но сейчас нет, потому что это оверхед над docker api.
Вы путаете понятия «оверхед» и «враппер».
Натыкались на такие issue? github.com/docker/compose/issues/3574
И? Собственно, в простейшем варианте разработчики совершенно верно указали, что docker-compose pull && docker-compose up дает ровно тот же желаемый эффект. В варианте pull-policy внутри конфига, с конкуррентной докачкой и прочими прелестями это «с кондачка» не делается, о чем они тоже сообщили и известили всех, что «думаем, как это правильно реализовать». Достаточно разумно, собственно. В 4-й параллельной версии конфига никто не заинтересован. Что не так?
Мне нравится декларативное описание в yaml. Он намного лучше json
Чем, простите, оно лучше json?
Впн я давно использовал в компаниях где были админы и настраивали его сами. Про ssh туннели я не знал, да, но как то пользовался пробросом портов в `kubectl`, думал это специфичная штука кубера
Ну, т.е., с документацией и изучением полезных инструментов — это у вас не с docker-compose началось? Давняя проблема?)
Ну а зачем вы пишите статьи вида докер не нужен, если у вас:
А) нет адекватного и достаточно опыта его использования
Б) у вас нет достаточного уровня понимания и экспертизы для оценки инструмента
В) вы не собираетесь тратить время на развитие и изучение инструмента, но используете его под прослойкой из ансибля
Кстати, а что вы будете делать с вашим уровнем знания докера и не желанием изучать его достаточно глубоко, если в связке ансибль-докер что-то поломается?
docker-compose есть лишь конфигурация `docker run` в yml формате. Странная неприязнь.
не только. docker build, docker create network и куча его всего.
Самый эпик, что в докере действительно есть проблемы и странности, но с ними можно жить и как-то с ними бороться. docker-compose поверх этого навешивает еще свои проблемы и странности. Например, первая — наличие двух ограниченно совместимых параллельно развивающихся форматов 2.* и 3.*
Я уж не говорю про особенности с выделением сетей (ага, в компании, у которой вся сеть на 172.12.0.0/16) и вольюмов…
Самый эпик, что в докере действительно есть проблемы и странности, но с ними можно жить и как-то с ними бороться. docker-compose поверх этого навешивает еще свои проблемы и странности. Например, первая — наличие двух ограниченно совместимых параллельно развивающихся форматов 2.* и 3.*
Я уж не говорю про особенности с выделением сетей (ага, в компании, у которой вся сеть на 172.12.0.0/16) и вольюмов…
Не совсем так. Это отдельная тулза со своими особенностями. И если ты делаешь build через compose, то будь готов к подвохам. Например, DOCKER_BUILDKIT пока не поддерживается https://github.com/docker/compose/issues/6440
Главная мощь докера видна в ci/cd пайплайнах. Документацию всё-равно никто никогда не пишет. А наличие Dockerfile в проекте обеспечивает доки и работающую конфигурацию. Плюс не надо искать и пытать разработчиков вопросами — «а что там установить чтобы оно заработало?»))
Ох… какже я ненавижу энтерпрайз…
Но вот в
-не прислали список запуска? (ой да тут подправить 1 сек)
-не совпадает разрешенный лимит доступа? (ууупс, да ладно — всего +1 пермишн)
-не прошло заявленную проверку на 100% (никаких ой ща, минутку, допилим)
-*тут еще кучка, на первый взяляд тупых чеков*
Отправляетесь еще на недельку в окиян согласований типа *ну плииизз ну назначьте нам еще проверку мы все тперь точноточно поправили* :)))
Но вот в
такие
моменты прям обожаю:«а что там установить чтобы оно заработало?»
-не прислали список запуска? (ой да тут подправить 1 сек)
-не совпадает разрешенный лимит доступа? (ууупс, да ладно — всего +1 пермишн)
-не прошло заявленную проверку на 100% (никаких ой ща, минутку, допилим)
-*тут еще кучка, на первый взяляд тупых чеков*
Отправляетесь еще на недельку в окиян согласований типа *ну плииизз ну назначьте нам еще проверку мы все тперь точноточно поправили* :)))
Пока не решат дохлые томы в докере ничего не будет. В винде производительность садится на порядок.
Пример: symfony 4. Базовая страничка без ничего отдается через пол секунды. Клево, че. Это на 9900k и nvme 970 pro. Хуже обстоит дело если винда home и нет гипервизора. В этом случае страница отдается после 700+ мс.
Пример 2: magento 2. В среднем загрузка обычной страницы занимает до 8 секунд. Со всеми кэшами может сократиться до 3-4. А если поставить какой-нибудь i5 и hdd, то что, на обед ходить после f5?
Многие не выдерживают и переходят на линукс. Я посидел на Убунте пару лет и тоже не выдержал — вернулся на винду. ОС с по-настоящему быстрым интерфейсом без единого глюка, лага. ОС где 2080 через 5 минут может отображать 165гц на мониторе, а не после двухчасовой возни в конфигах и последующем переходе на хромиум (в хроме нет поддержки высокогерцовых мониторов) и довольствованием 80fps.
Линукс я люблю, но, как и родину, его лучше любить издалека. Решил вопрос покупкой интел нака и созданием локальной сети между пк и ним. Помимо некоторых проблем с сетью, получил желаемый интерфейс винды и отличный сервер.
Таков мой опыт.
Пример: symfony 4. Базовая страничка без ничего отдается через пол секунды. Клево, че. Это на 9900k и nvme 970 pro. Хуже обстоит дело если винда home и нет гипервизора. В этом случае страница отдается после 700+ мс.
Пример 2: magento 2. В среднем загрузка обычной страницы занимает до 8 секунд. Со всеми кэшами может сократиться до 3-4. А если поставить какой-нибудь i5 и hdd, то что, на обед ходить после f5?
Многие не выдерживают и переходят на линукс. Я посидел на Убунте пару лет и тоже не выдержал — вернулся на винду. ОС с по-настоящему быстрым интерфейсом без единого глюка, лага. ОС где 2080 через 5 минут может отображать 165гц на мониторе, а не после двухчасовой возни в конфигах и последующем переходе на хромиум (в хроме нет поддержки высокогерцовых мониторов) и довольствованием 80fps.
Линукс я люблю, но, как и родину, его лучше любить издалека. Решил вопрос покупкой интел нака и созданием локальной сети между пк и ним. Помимо некоторых проблем с сетью, получил желаемый интерфейс винды и отличный сервер.
Таков мой опыт.
довольствованием 80fps.
Какой ужас, всего 80fps! Глаза болят, ага.
Серьезно, ну посидел я у коллеги за настроенным 160Hz монитором. Никакой особой разницы не заметил. Разве что нагрузка на процессор и видеокарту у него побольше. Плавность интерфейса тоже особым преимуществом не назовешь — то, что у меня в настроенном и вылизанном линупсе происходит мгновенно, на винде может занимать 100-300мс из-за плавности и анимаций. Зачем мне это нужно?
Возможно, это всё привычка и в винде есть какие-то непонятные мне прелести. Но в 2019 году можно и потерпеть ужасно неплавный интерфейс и 80fps ради ОС, которая вся целиком представляет из себя удобную и настраиваемую IDE.
Вы не заметили особой разницы, значит ее нет.
На винде на нормальной машине все происходит моментально кроме некоторых заведомо кривых областей. Более того, на десятке даже на слабых пк (3ггц+) все будет работать не медленнее чем на xp, например. Я это тестировал на слабых мини-пк и не предполагаю о 100-300мс, а утверждаю.
Допускаю что в 2019 есть крутые и красивые дистрибутивы, но самый популярный из них — Убунта — так и не стала такой. Особенно gnome 3. Надолго запомнил невозможность перехода из контекстного меню, проблемы с панелью задач и сложную ситуацию со шрифтами. Видимо, не смог, да.
На винде на нормальной машине все происходит моментально кроме некоторых заведомо кривых областей. Более того, на десятке даже на слабых пк (3ггц+) все будет работать не медленнее чем на xp, например. Я это тестировал на слабых мини-пк и не предполагаю о 100-300мс, а утверждаю.
Допускаю что в 2019 есть крутые и красивые дистрибутивы, но самый популярный из них — Убунта — так и не стала такой. Особенно gnome 3. Надолго запомнил невозможность перехода из контекстного меню, проблемы с панелью задач и сложную ситуацию со шрифтами. Видимо, не смог, да.
Вы не заметили особой разницы, значит ее нет.
Нигде не утверждал, что её нет.
Я это тестировал на слабых мини-пк и не предполагаю о 100-300мс, а утверждаю.
Я это (windows 10) тестировал на своём рабоче-походном ноутбуке с i3-6600U и встройкой и тоже не предполагаю, а утверждаю. Пуск открывается около секунды, PS запускается даже дольше секунды, Firefox открывается около 4-5 секунд. У меня в Linux на том же ноуте: лаунчер (замена пуску) — меньше 100ms; терминал (с zsh, который ещё и удобнее PS) — меньше 100ms; firefox — две секунды.
Убунта — так и не стала такой
Вы сравниваете вылизанный и собранный под себя Linux с Linux для новичков (при этом с самой тормозной оболочкой). Проблема в том, что Linux вылизать можно, а вот Windows — не очень,
В винде производительность садится на порядок.
Это логично. Docker — достаточно эффективная абстракция над lxc (Linux Containers), которые, в свою очередь, обеспечивают изоляцию штатными механизмами ядра (namespaces + cgroups). Странно было бы, если бы оно завелось под Windows с той же производительностью…
Дык в 2019ой винде оно тоже на уровне ядра работает. Под трафиком докера ещё не тестил, но они заводятся, ASP.NET апликухи.
Windows-контейнеры — да, запилили ядерную изоляцию. Линукс-контейнеры, если верить доке, все так же на linux-виртуалке с пробросом портов и прочими прелестями.
Конечно, могу в чем-то ошибаться, никогда не рассматривал всерьез windows как платформу для контейнеризации, и мог какие-то новости пропустить. Но если оно «свежее», видимо, для прода пока еще не готово.
Конечно, могу в чем-то ошибаться, никогда не рассматривал всерьез windows как платформу для контейнеризации, и мог какие-то новости пропустить. Но если оно «свежее», видимо, для прода пока еще не готово.
Docker — достаточно эффективная абстракция над lxc (Linux Containers)
не надо это повторять. Это какая-то глупость, которая кочует из комментария в комментарий. docker — он работает параллельно с lxc/lxd, а не поверх него.
ОС с по-настоящему быстрым интерфейсом без единого глюка, лага
от души посмеялся, спасибо)
Используйте docker только на самом последнем этапе в вашем рабочем процессе
Так и представил:
— Пацаны, через неделю выходим в прод, давайте наконец прикрутим докер
Мужики, ну растолкуйте за докер и все это, уж очень интересна тема Ci/cd пайплайнов и тд, но пока что не могу даже устаканить мысли о докере.
Вот как я понимаю контейнеры умирают вместе с данными, (да я читал что там можно подключить разными способами что-то перстстентное, не об этом)
Теоретически я заворачиваю свой фротенд в контейнер, бекенд в контейнер, что мне делать с базой? Мне же страшно, чтобы там не умерли мои данные.
Поясните плз :)
Вот как я понимаю контейнеры умирают вместе с данными, (да я читал что там можно подключить разными способами что-то перстстентное, не об этом)
Теоретически я заворачиваю свой фротенд в контейнер, бекенд в контейнер, что мне делать с базой? Мне же страшно, чтобы там не умерли мои данные.
Поясните плз :)
Можно вместо Docker использовать LXC, и данные «не умрут».
Вот как я понимаю контейнеры умирают вместе с данными, (да я читал что там можно подключить разными способами что-то перстстентное, не об этом)
Именно об этом. Если вам нужно что-то персистентное, то и подключается оно как что-то персистентное. Т.е. база либо а) в стороне на отдельном сервере, либо б) в контейнере с подмонтированным персистентным var'ом.
Тогда вдогонку, допустим я изменил код проекта локально, а на хосте уже крутится контейнер, не могли бы вы подсказать из вашего опыта, если он имеется, как рациональнее всего осуществлять деплой? Работаю пока что в маленьких проектах и имею время играться, раньше писал удобные скрипты которые по ссш все делали, как это можно провернуть с контейнерами? Каждый раз менять имейдж на локально, дальше из него билдить каждый раз новый контейнер на хосте?
настройте один раз контейнер и пайплайн к нему. т.е. окружение(контейнер) не будет изменятся, а продукт в нем — по комиту нового кода.
Не надо так. По хорошему пайп должен работать так: коммит — сборка контейнера с приложением — пуш в приватную репу — пулл из приватной репы на проде. А апдейтить что-то внутри контейнера так себе идея, смысл докеризации пропадает.
На мой взгляд это имеет смысл только в Swarm. Сам по себе контейнер докера — ничем не отличим от других. Вы бы к примеру стали LXC каждый раз гонять?
Ну необязательно swarm. Любой другой оркестратор, будь то кубик или амазоновский ECS. Докер без оркестрации вещь в себе на самом деле.
Да, совершенно верно, с любыми оркестраторами. Но, вспомните первоначальную задачу в этой ветке, был подобран простейший вариант:
Вы все правильно заметили — предложенный вариант не best practice.
на хосте уже крутится контейнер
как рациональнее всего осуществлять деплой? Работаю пока что в маленьких проектах
Вы все правильно заметили — предложенный вариант не best practice.
Тогда вдогонку, допустим я изменил код проекта локально, а на хосте уже крутится контейнер, не могли бы вы подсказать из вашего опыта, если он имеется, как рациональнее всего осуществлять деплой?
Ну, скажем, для начала придется смириться с тем, что локальный код — это локальный код, т.е. штука, никак сама по себе не связанная с тем «что крутится на хосте».
Работаю пока что в маленьких проектах и имею время играться, раньше писал удобные скрипты которые по ссш все делали, как это можно провернуть с контейнерами?
Простой и быстрый способ — написать другие shell-скрипты, которые быстро по ssh все сделают)
Каждый раз менять имейдж на локально, дальше из него билдить каждый раз новый контейнер на хосте?
А «по науке» — смотреть на практики CI/CD. Обычно выглядит так:
1. Вы делаете локальные изменения кода.
2. Суете эти изменения в общий репозиторий.
3. При пуше в репозиторий отрабатывают гит-хуки, например, которые запускают специальный контейнер, в котором ваше приложение собирается.
4. Полученное приложение прогоняется по тестам.
5. Если тесты прошли, полученная сборка деплоится на сервер. В процессе деплоя, чаще всего, новая версия запускается параллельно существующей. Если новая версия стартанула (тут возможны какие-то health-чеки), старая гасится.
Но это «по науке», внедрять можно поэтапно.
Про докер я узнал года на два ранее, чем услышал слово DevOps.
На тот момент докер не вызвал у меня какого-либо интереса. По туториалам собрал и запустил свой первый контейнер, ни с какими проблемами не столкнулся — скукотища, как если бы взрослый дядя, пользуясь инструкцией, собирал бы детский конструктор.
Напомнили мне про докер разработчики, к которым я попал в качестве сисадмина в команду.
Эти люди (команда разрабов), когда падало какое-либо приложение, вместо разбора логов и поиска причин падения запускали пересборку апликухи без обновления кода. А все потому, что в билде были строчки останова и запуска приложения на стенде в процессе деплоя. Т.е. билд возвращал приложение в строй.
На мое искреннее удивление этим действиям они предложили решением докер, у которого, как они слышали, контейнеры сами оркеструются и билдить ради этого не требуется.
Так вот, к чему я это.
Если кто-то рассматривает докер, как некую магию, которая избавляет от решения проблем исполнения кода, то у меня для вас плохие новости… Меняйте себя, а не инструментарий.
На тот момент докер не вызвал у меня какого-либо интереса. По туториалам собрал и запустил свой первый контейнер, ни с какими проблемами не столкнулся — скукотища, как если бы взрослый дядя, пользуясь инструкцией, собирал бы детский конструктор.
Напомнили мне про докер разработчики, к которым я попал в качестве сисадмина в команду.
Эти люди (команда разрабов), когда падало какое-либо приложение, вместо разбора логов и поиска причин падения запускали пересборку апликухи без обновления кода. А все потому, что в билде были строчки останова и запуска приложения на стенде в процессе деплоя. Т.е. билд возвращал приложение в строй.
На мое искреннее удивление этим действиям они предложили решением докер, у которого, как они слышали, контейнеры сами оркеструются и билдить ради этого не требуется.
Так вот, к чему я это.
Если кто-то рассматривает докер, как некую магию, которая избавляет от решения проблем исполнения кода, то у меня для вас плохие новости… Меняйте себя, а не инструментарий.
>> Docker в CI
Судя по всему аффтор не стал даже читать как всё это работает.
Ну и если человеку «проще» поставить весь набор пакетов на сборочную ноду, чем поставить один докер и запускать для каждой сборки свой контейнер — то можно сделать вывод о масштабах проектов.
ЗЫ: Для явы возможно и нет смысла использовать докер т.к. код будет работать в ява контейнере который будет в докер контейнере который будет в опенстек ВМке в доме который построил Джек.
ЗЗЫ: ансибл ещё то чудо, в котором после каждого релиза что то деприкейтят, и в через релиз уже старые роли нифига не работают.
Судя по всему аффтор не стал даже читать как всё это работает.
Ну и если человеку «проще» поставить весь набор пакетов на сборочную ноду, чем поставить один докер и запускать для каждой сборки свой контейнер — то можно сделать вывод о масштабах проектов.
ЗЫ: Для явы возможно и нет смысла использовать докер т.к. код будет работать в ява контейнере который будет в докер контейнере который будет в опенстек ВМке в доме который построил Джек.
ЗЗЫ: ансибл ещё то чудо, в котором после каждого релиза что то деприкейтят, и в через релиз уже старые роли нифига не работают.
Docker нужен для запуска микросервисов в оркестраторе.
Микросервисы нужны только тогда, когда руководство разработки и разработка в целом четко понимает для чего они им нужны.
Если вы не знаете для чего конкретно вам нужен docker или микросервисы — они вам не нужны, если не смотря на это, вы хотите их применить — вы действуете не оптимально, и тогда docker для вас игрушка.
Микросервисы нужны только тогда, когда руководство разработки и разработка в целом четко понимает для чего они им нужны.
Если вы не знаете для чего конкретно вам нужен docker или микросервисы — они вам не нужны, если не смотря на это, вы хотите их применить — вы действуете не оптимально, и тогда docker для вас игрушка.
docker — это
1) средство упаковки и доставки софта и его окружения (последнее ключевое)
2) перенос многих вопросов, главным образом вопрос подготовки зависимостей на сторону разработчика, который лучше знает, что его софту нужно, тем самым КАРДИНАЛЬНО упрощая жизнь опсов
3) относительно единая среда запуска везде
4) документация среды в виде кода
5) относительная чистота среды исполнения
Всё это плюсы, которые получаешь без всякой оркестрации и микросервисов сразу же. Даже монолит в докере уже упорядочивает и упрощает многие вопросы обслуживания софта.
1) средство упаковки и доставки софта и его окружения (последнее ключевое)
2) перенос многих вопросов, главным образом вопрос подготовки зависимостей на сторону разработчика, который лучше знает, что его софту нужно, тем самым КАРДИНАЛЬНО упрощая жизнь опсов
3) относительно единая среда запуска везде
4) документация среды в виде кода
5) относительная чистота среды исполнения
Всё это плюсы, которые получаешь без всякой оркестрации и микросервисов сразу же. Даже монолит в докере уже упорядочивает и упрощает многие вопросы обслуживания софта.
По пунктам 1,2,3 подходят rpm/deb + systemd, которые, в отличии от docker, не добавляют целой пачки сущностей и не усложняют систему.
> 4) документация среды в виде кода
Dockerfile не самая удобочитаемая вещь в мире, тогда сюда же вполне ложится лобой configuration management tool или spec file.
> 5) относительная чистота среды исполнения
Точно так же зависит от приложения, если оно у вас stateless, то среда для него всегда будет чистая, независимо от того, что вокруг него, а если вы запускаете в докере на проде statefull workload, вероятно монтируя его volume'ми — вы значительно усложняете себе жизнь.
Про упрощение жизни опсов также не соглашусь, docker усложняет любой траблшутинг, всегда. Для большинства опсов docker является новой сущностью.
Если речь идет про предоставление единого интерфейса, то тут опять же гораздо лучше подходит systemd.
> 4) документация среды в виде кода
Dockerfile не самая удобочитаемая вещь в мире, тогда сюда же вполне ложится лобой configuration management tool или spec file.
> 5) относительная чистота среды исполнения
Точно так же зависит от приложения, если оно у вас stateless, то среда для него всегда будет чистая, независимо от того, что вокруг него, а если вы запускаете в докере на проде statefull workload, вероятно монтируя его volume'ми — вы значительно усложняете себе жизнь.
Про упрощение жизни опсов также не соглашусь, docker усложняет любой траблшутинг, всегда. Для большинства опсов docker является новой сущностью.
Если речь идет про предоставление единого интерфейса, то тут опять же гораздо лучше подходит systemd.
То есть вы реально считаете, что «rpm/deb + systemd» — это проще, чем Docker?
В том числе на Windows или Mac?
В том числе на Windows или Mac?
Сложность системы определяется количеством элементов в ней и количеством связей между ними.
Systemd и пакетный менеджер есть практически на любой системе, мы не вводим нового элемента.
Для локалхоста разработчиков, если им нужны dev стенды на локалхостах (что обычно не так), есть vagrant.
Поэтому да, rpm/deb + systemd — проще чем Docker.
Systemd и пакетный менеджер есть практически на любой системе
В контексте предыдущего вопроса «В том числе на Windows или Mac?» смотрится, как минимум, сверхоптимистично.
При этом разработчик может пользоваться той же ubuntu, а на прод оно может уйти в RHEL-инстанс… Ну, скажу я вам, такое себе, эти ваши гетерогенные среды.
Поэтому да, rpm/deb + systemd — проще чем Docker.
Поэтому вот нифига.
не могу согласиться от слова совсем.
systemd — действительно великая вещь, но реально зачастую возможны проблемы, когда в системе стоит библиотека версии А, а программе нужна Б, причем обе не могут быть установлены одновременно. Сюда же — нормальный менеджмент пакетов у многих экосистем (например, python) отсутствует от слова совсем. Можно извращаться с chroot'ом и еще как-то — но зачем, если есть контейнеризация?
есть такой момент, да. Но это характерно для любой современной системы, которая является совокупностью слоев абстракции. Чего уж тогда от виртуализации не отказаться и гонять все на баре-метал? Слоев абстракции меньше — траблшутинг проще (*** не всегда )
нормально он читается. Уж всяко лучше, чем переусложненный ruby DSL паппет-манифест или шеф-кукбук.
systemd — действительно великая вещь, но реально зачастую возможны проблемы, когда в системе стоит библиотека версии А, а программе нужна Б, причем обе не могут быть установлены одновременно. Сюда же — нормальный менеджмент пакетов у многих экосистем (например, python) отсутствует от слова совсем. Можно извращаться с chroot'ом и еще как-то — но зачем, если есть контейнеризация?
Про упрощение жизни опсов также не соглашусь, docker усложняет любой траблшутинг, всегда. Для большинства опсов docker является новой сущностью.
есть такой момент, да. Но это характерно для любой современной системы, которая является совокупностью слоев абстракции. Чего уж тогда от виртуализации не отказаться и гонять все на баре-метал? Слоев абстракции меньше — траблшутинг проще (*** не всегда )
Dockerfile не самая удобочитаемая вещь в мире, тогда сюда же вполне ложится лобой configuration management tool или spec file.
нормально он читается. Уж всяко лучше, чем переусложненный ruby DSL паппет-манифест или шеф-кукбук.
зачастую возможны проблемы, когда в системе стоит библиотека версии А, а программе нужна Б, причем обе не могут быть установлены
Статическая линковка для c/cpp? fat jar для java?
Или вы инфраструктурную обвязку в docker крутите? Этот вариант настолько же прекрасен в рамках процессов тестирования/разработки насколько плох в рамках процессов эксплуатации.
И если вы хотите, чтобы хорошо было всем, вам придется поддерживать 2 разных механизма развертывания.
| Сюда же — нормальный менеджмент пакетов у многих экосистем (например, python) отсутствует от слова совсем.
pip + requirements.txt, vitrualenv? не знаю чем вам менеджмент пакетов python не угодил.
есть такой момент, да. Но это характерно для любой современной системы, которая является совокупностью слоев абстракции. Чего уж тогда от виртуализации не отказаться и гонять все на баре-метал? Слоев абстракции меньше — траблшутинг проще (*** не всегда )
Принцип бритвы Оккама. Любая техническая задача, это задача математической оптимизации — минимизируем временные расходы, при заданных ограничениях.
У docker, как у любого инструмента есть свои применения (запуск stateless микросервисов в оркестраторе).
Я не буду спорить, можно и отверткой гвозди забивать при наличии энтузиазма, главное при этом иметь вид достаточно лихой, чтобы потом не спросили за потраченное время и выбитые выскользнувшей отверткой окна.
нормально он читается. Уж всяко лучше, чем переусложненный ruby DSL паппет-манифест или шеф-кукбук.
Разными людьми разные вещи читаются с разной эффективностью, но вы лукавите, говоря, что пачка bash скриптов с обратным слэшем перед переводом строки является эталоном читабельности.
pip + requirements.txt, vitrualenv? не знаю чем вам менеджмент пакетов python не угодил.
Потому что это не решение. Вы внутрь python-пакетов вообще заглядывали? А ничего,, то они часто за пределы экосистемы python выходят и начинают в систему тащить всякую всячь. И, да, многие pip-пакеты без компилятора gcc вообще не поставить в принципе. Ни о чем не говорит?
Разными людьми разные вещи читаются с разной эффективностью, но вы лукавите, говоря, что пачка bash скриптов с обратным слэшем перед переводом строки является эталоном читабельности.
Несомненно. Но, во-первых, у Dockerfile другая задача, чем у шеф-кукбука. И Вы сами про это знаете. И, во-вторых, никто не мешает конфигурировать содержимое Docker-образа через chef (так, например, Флант делает)
Статическая линковка для c/cpp? fat jar для java?
Ну, т.е. systemd + rpm/apt таки эту задачу не решают, от слова «совсем». Предложенный же вами вариант — ну, как бы, тоже trade-off. Вы «выкидываете» из цепочки пересборку докер-образов при обновлении базового слоя с зависимостями (например, при фиксах уязвимостей базовых библиотек). Что взамен? Очевидно, пересборка fat jar'ов, c/cpp проектов и т.д. «То на то» и выходит, конечно, с единственным нюансом: пересборка с зависимостями — отдельный инструментарий для каждого языка, пересборка докер-образов универсальна.
pip + requirements.txt, vitrualenv? не знаю чем вам менеджмент пакетов python не угодил.
Ну, тут три слабых места:
1. Он сам по себе сильно не идеален, и может попросить (как указал уже ваш собеседник в другом комментарии) еще и gcc с собой принести, а то и что-то дополнительно в систему вкорячить.
2. Он приемлемо решает вопрос доставки языковых зависимостей, но никак не решает вопрос их конфигурации и вопрос доставки инфраструктурных зависимостей.
3. Он не универсален.
Конкретно по 3 пункту. Вот есть у вас проект. На python, с venv и «всем вот этим». Дописали, стартанули новый. А он на js! Опачки, ваши «инженеры-эксплуатационщики» изучают npm, yarn, whatever. И тут приходит новая вещь: java-приложуха. И тот же самый бедолага инженер по тихой грусти изучает maven, gradle с задачей «автоматизируй это».
Имхо, достаточно логично, что разработчик «в стеке» свои инструменты знает. Эксплуатационщик же может (имеет полное право) не знать «языковых экосистемных тонкостей». Его задача — инстансы гонять. Просто потом этот же товарищ, вконец «уставший» от изучения концепций третьего языка программирования, на котором он никогда не будет писать, пойдет на другую работу. А там… Там, предположим, Ruby… Кхм.
Причина популярности всей этой возни с контейнеризацией, имхо, именно в том, что процесс эксплуатации проекта становится не зависим от стека, на котором проект разрабатывался. Т.е. мы имеем, условно, «lingua franca» — некоторый описательный язык, примерно понятный как разработчикам, так и «эксплуататорам».
А вот «бутылочное горлышко» в местах, где этот подход не дает столь же оптимистичных результатов, всегда можно разрулить аккуратно ручками. Но только те места, которые «горлышко», зачем все-то руками рулить?
минимизируем временные расходы, при заданных ограничениях.
Именно оно! Вы же понимаете, что есть человек, который «это написал», и человек, который «это использует», и в сколько-нибудь серьезном продакшене — это разные люди. Надеяться на «специалиста полного цикла» — утопическая штука.
Ну вот «контейнер» — это концепция, понятная обоим сторонам процесса. При этом разработчиков много хороших и разных, а эксплуатационщику, который поддерживает 50 проектов «на плаву», у которого на каждый проект лежит бумажка вида «не забудь, вот в этом месте должен лежать файлик вот с таким содержимым», все эти «нюансы разработки в определенном технологическом стеке» — как серпом по тестикулам. Контейнер же дает одинаковый унифицированный опыт эксплуатации вне зависимости от архитектуры проекта.
Поэтому и пользуются, поэтому и популярно. Где-то неизбежно получаются «просадки качества управления», но именно в том и подход, что решать вручную надо именно те места, где «просадка» случилась, а не все подряд. Все подряд руками оптимизировать — это тупо дорого.
пересборка докер-образов универсальна.
За иллюзию контроля платят дороже, чем за осознание ограничений своих инструментов на текущий момент времени.
три слабых места pip + venv
Производим артефакт с venv на этапе сборки, gcc остается только на сборочном агенте.
Для доставки есть другие инструменты.
Или вы считаете голый docker полноценным инструментом доставки?
Расскажите, как вы голым докером, без обвязки и оркестрации произведете бесшовное обновление.
«инженеры-эксплуатационщики» изучают npm,
опсы нажимают на кнопку.
Вы считаете, что запрятывание процесса в отдельный namespace избавляет опсов от необходимости понимания его работы?
бедолага инженер по тихой грусти изучает maven, gradle
Бедолагам инженерам в принципе полезно понимать какие бизнес-процессы они обеспечивают, вместо того, чтобы закрываться в своей комнатке, типа мы тут обеспечиваем инфраструктуру cicd.
процесс эксплуатации проекта становится не зависим от стека
Все та же иллюзия контроля, если вы положите предмет в шкаф, он от этого не станет шкафом, он станет предметом в шкафу. Если вы не могли обеспечить его качественную эксплуатацию без шкафа, то и со шкафом вы её не обеспечите.
зачем все-то руками рулить?
Разве я где-то писал про руление руками? Помимо docker есть масса инструментов, которыми вы кстати будете рулить и docker'ом, пока не поймете тленность его использования без оркестрации, но тут нужно учиться на своих ошибках и запороть пару проектов.
«контейнер» — это концепция, понятная обоим сторонам процесса.
systemctl start servicename
systemctl stop servicename
обе стороны процесса только что научились пользоваться systemd, сложнее чем docker?
«не забудь, вот в этом месте должен лежать файлик вот с таким содержимым»
Простите, а зачем?
За иллюзию контроля платят дороже, чем за осознание ограничений своих инструментов на текущий момент времени.
Кхм, vagrant, terraform, docker, k8s — тысячи их. У всех в каждый момент времени есть определенный набор ограничений. Что сказать-то хотели?
Производим артефакт с venv на этапе сборки, gcc остается только на сборочном агенте.
Для доставки есть другие инструменты.
Или вы считаете голый docker полноценным инструментом доставки?
Расскажите, как вы голым докером, без обвязки и оркестрации произведете бесшовное обновление.
Докер я считаю полноценным инструментом сборки. На девелоперском окружении можно прямо в нем с минимальной обвязкой гонять. В проде — есть инструменты оркестрации, тот же k8s. А я где-то говорил, что докер или докер-компоуз тот же — полноценные инструменты оркестрации? Я как раз ссылку на доку приводил, в которой написано «докер-компоуз — тупая запускалка взаимосвязанных контейнеров».
опсы нажимают на кнопку.
Вы считаете, что запрятывание процесса в отдельный namespace избавляет опсов от необходимости понимания его работы?
Избавляет ровно до тех пор, пока контейнер ведет себя в рамках спецификации. В остальном… Ну, ни один инструмент не избавит от необходимости понимания. При этом не каждый даст достаточную изоляцию.
Бедолагам инженерам в принципе полезно понимать какие бизнес-процессы они обеспечивают, вместо того, чтобы закрываться в своей комнатке, типа мы тут обеспечиваем инфраструктуру cicd.
Какое, простите, отношение maven с gradle к бизнес-процессам имеют?
Все та же иллюзия контроля, если вы положите предмет в шкаф, он от этого не станет шкафом, он станет предметом в шкафу. Если вы не могли обеспечить его качественную эксплуатацию без шкафа, то и со шкафом вы её не обеспечите.
Так точно. Однако умение автоматически перенести шкаф с уже разложенным «как надо» содержимым в соседнюю квартиру, не свалив содержимое в неудобоваримую кучу — это бонус.
Разве я где-то писал про руление руками? Помимо docker есть масса инструментов, которыми вы кстати будете рулить и docker'ом, пока не поймете тленность его использования без оркестрации, но тут нужно учиться на своих ошибках и запороть пару проектов.
Глупость сказали. Мы либо используем докер-без-оркестрации в целях сборки/отладки (это можно и нужно, чтобы получить непосредственно артефакт деплоя), либо крутим прод, где докер, в подавляющем числе случаев не используется. Я, кстати, где-то говорил о самодостаточности докера?
systemctl start servicename
systemctl stop servicename
обе стороны процесса только что научились пользоваться systemd, сложнее чем docker?
Вы лукавите. Юниты написать забыли. Пользоваться можно научить и оленя, использовать — только специалиста.
И, к слову, еще раз повторюсь, на всякий случай: systemd есть не везде. В alpine, например, нету. Или, если мы про кровавый энтерпрайз, в RHEL5, вроде, нету. А его (5-го) еще много.
В общем, вы меня извините, конечно, но systemd — это systemd. «Системный менеджер», вроде как, называется. Каким образом вы собираетесь с его помощью решать вопросы оркестрации и, тем более, доставки приложений — я не понимаю в принципе.
Простите, а зачем?
Например, «так надо».
Его задача — инстансы гонять. Просто потом этот же товарищ, вконец «уставший» от изучения концепций третьего языка программирования, на котором он никогда не будет писать, пойдет на другую работу. А там… Там, предположим, Ruby… Кхм.
Внезапно выясняется, что нужно работать и что-то сделать получается только кровью и потом, не, лучше запихаю все в контейнеры подальше от глаз, там не видно как оно работает, в волшебном докере фиксики шестеренки крутят и делают плохой софт хорошим.
Вы уж простите за сарказм, не сдержался.
Ничего, люблю выслушивать «сарказм», замешанный на юношеском максимализме.
Предлагаемая вами альтернатива, видимо, выкинуть плохой софт и написать хороший? Попробуйте представить себя на месте человека, который весь этот банкет оплачивает…
В общем, как всегда, «шашечки vs ехать». Причем контейнеризация — это та штука, к которой есть, конечно, вопросы, она не идеальная и все такое. Но, она, как бы, «едет». Причем с разумными расходами на перемещение в пространстве.
фиксики шестеренки крутят и делают плохой софт хорошим
Предлагаемая вами альтернатива, видимо, выкинуть плохой софт и написать хороший? Попробуйте представить себя на месте человека, который весь этот банкет оплачивает…
В общем, как всегда, «шашечки vs ехать». Причем контейнеризация — это та штука, к которой есть, конечно, вопросы, она не идеальная и все такое. Но, она, как бы, «едет». Причем с разумными расходами на перемещение в пространстве.
«Х нужно только тогда, когда нужно, и никогда больше»
У нас был монолит на Ruby on Rails, 150K строк кода, который не только лишь все могли у себя запустить. Потому что кто-то проапдейтил OSX, и вот уже какой-то Ruby Gem засивящий от C++ кода слетел. Docker все эти проблемы тоже отлично решил.
У нас был монолит на Ruby on Rails, 150K строк кода, который не только лишь все могли у себя запустить. Потому что кто-то проапдейтил OSX, и вот уже какой-то Ruby Gem засивящий от C++ кода слетел. Docker все эти проблемы тоже отлично решил.
запуск nginx для раздачи frontend и проксирования на backendИзолированный nginx можно запускать проще:
wasmer run nginx.wasm -- -p . -c nginx.confgithub.com/wasmerio/wasmer/tree/c8a71263db01365798ab5c05631ddc52a0b57198/examples/nginx
Там же есть примеры php, sqlite, lua и тд github.com/wasmerio/wasmer/tree/c8a71263db01365798ab5c05631ddc52a0b57198/examples
Вот еще в тему twitter.com/solomonstre/status/1111004913222324225
Типичный рассказ типичного разработчика, который не видел крупного проекта, который живёт в своем мирке из одного сервиса.
Хе, у меня докер на проде только в одном продукте от IBM, но уже надоело писать заявки ИБ чтобы открыли доступ в инет с боевого сервера «ко всему», иначе этот чертов докер не ставится-не обновляется, ибо до фига зависимостей и все эти бубны скачать с одной машины-сохранить-перенести вообще не реально сделать… Может быть с точки зрения разработчика удобно, но когда доходит до продакшина…
но уже надоело писать заявки ИБ чтобы открыли доступ в инет с боевого сервера «ко всему»
кхм, не в обиду, но вас нельзя допускать до сисадминства
Что вы там ставите? Что обновляете? Что с машины на машину переносите?
Худший вариант: поставить его на yum/apt — это доступ в интернет на один узел, учитывая, что у докера есть свои репо под оба этих пакетных менеджера.
Лучший вариант: стартануть CoreOS с игнишена (вообще в 2019-м пакеты и их зависимости в ОС звучат как дичь).
Так зачем вам «доступ в инет с боевого сервера «ко всему»»
Худший вариант: поставить его на yum/apt — это доступ в интернет на один узел, учитывая, что у докера есть свои репо под оба этих пакетных менеджера.
Лучший вариант: стартануть CoreOS с игнишена (вообще в 2019-м пакеты и их зависимости в ОС звучат как дичь).
Так зачем вам «доступ в инет с боевого сервера «ко всему»»
Иногда лучше почитать документацию, прежде, чем что-то сказать.
Вот такого уровня сейчас люди приходят на собеседования… На позицию тимлида…
Вот такого уровня сейчас люди приходят на собеседования… На позицию тимлида…
для того чтобы мое приложение работало, нужен сам docker на сервере. А зачем мне это, если мои приложения работают на jre или на nodejs и окружение для них уже есть на сервере?
Да? Вы уверены в этом? И версия JRE/NodeJS точно совпадает с тем, что тестировали QA?
Используйте docker только на самом последнем этапе в вашем рабочем процессе, не тащите его в проект в начале. Он не решит ваших бизнес проблем. Он только сдвинет проблемы на ДРУГОЙ уровень и будет предлагать свои варианты решения, вы будете делать двойную работу.
Это самый нелепый совет, который можно было дать.
Смысл DevOps в том, чтобы сделать очень плавным переход от IDE к продакшену (через все промежуточные стадии). А чтобы этого достигнуть, код должен быть изначально в том же состоянии, в каком будет в конце. И Docker — как раз гарантия этого состояния. В нем описано все, что необходимо сделать, чтобы работало так, как оно работало у разработчика.
Если вы включаете докер не в начале, значит вы вообще не поняли, зачем он нужен. Даже в минимальном приближении не поняли.
Если вы включаете докер не в начале, значит вы вообще не поняли, зачем он нужен. Даже в минимальном приближении не поняли.
Я не знаю что вы имеете ввиду под «началом» и спорить не буду. Я написал, что с docker знаком уже больше 3х лет, и с вашей стороны говорить, что я ничего не понимаю — это грубо.
В нем описано все, что необходимо сделать, чтобы работало так, как оно работало у разработчика.
Разработчики должны писать качественный код приложения. Думать как написать модульный, чистый код. Думать над версионированием, следить за коммитами и чтобы ничего не попало в git репозитории, делать тщательное ревью кода. У них огромная поляна работы в которой использование docker никак не поможет!
Да? Вы уверены в этом? И версия JRE/NodeJS точно совпадает с тем, что тестировали QA?
Это работа CI. Он делает git fetch, прогоняет тесты и билдит проект. Можно сделать так чтобы он паковал результаты работы в docker образ и запускаться в контейнере если вы хотите
Вы когда-нибудь задумывались, что и почему в слове DevOps делает слово Dev? Сможете объяснить концепцию?
Задумывался и спорил по этому много ни раз с другими людьми. И про CI/CD я спорил, что это такое и как должно работать. Но потом, когда устал спорить, я понял, что все это бессмысленно, потому что каждый понимает по своему.
Теперь я смотрю только на результат, без разницы какой термин у процесса. Так же как и на docker я смотрю сейчас, что он умеет делать и как добиться определенного результата.
Теперь я смотрю только на результат, без разницы какой термин у процесса. Так же как и на docker я смотрю сейчас, что он умеет делать и как добиться определенного результата.
Да дайте хоть одно любое описание концепции DevOps, пусть даже самое спорное.
Не так важно, на сколько ваше мнение отличается. Важно только, что в нем будет Dev, что и есть ответ на все вопросы.
___
И да, кстати, DevOps — это не гуманитарное понятие. Только у людей, которые не понимают его смысл, расходятся «мнения».
Термин был придуман и четко сформулирован Патриком Дебуа в 2009-м году. Все остальные люди, если хотят придумать новую смысловую нагрузку, должны для ее названия выбрать свободную комбинацию букв, а не DevOps.
Не так важно, на сколько ваше мнение отличается. Важно только, что в нем будет Dev, что и есть ответ на все вопросы.
___
И да, кстати, DevOps — это не гуманитарное понятие. Только у людей, которые не понимают его смысл, расходятся «мнения».
Термин был придуман и четко сформулирован Патриком Дебуа в 2009-м году. Все остальные люди, если хотят придумать новую смысловую нагрузку, должны для ее названия выбрать свободную комбинацию букв, а не DevOps.
А давайте вернемся в более реальный мир не гиков — да всем плевать что там придумал какой-то никому не известный Патрик :))))
Имеет лишь значение что услышала очередной ит-аналист с ит-манагером на очередном ит-митинге по диджитал ит текнолоджи от ИТ-супергигант.
PS Ну я надеюсь уже понятно что самым итшным там была точка доступа от длинка? :)
Имеет лишь значение что услышала очередной ит-аналист с ит-манагером на очередном ит-митинге по диджитал ит текнолоджи от ИТ-супергигант.
PS Ну я надеюсь уже понятно что самым итшным там была точка доступа от длинка? :)
А в более реальном мире «негиков» остались те самые проблемы, которые и были решены «никому неизвестным» Патриком. Так вот я и хотел услышать, знает ли об этих проблемах kondaurovDev или не знает.
Потому что он написал «У них огромная поляна работы в которой использование docker никак не поможет».
Вы можете выкинуть имя Патрик или термин DevOps из диалога. Но проблему, которую он решает, вы не выкинете. Так что это за проблема?
Потому что он написал «У них огромная поляна работы в которой использование docker никак не поможет».
Вы можете выкинуть имя Патрик или термин DevOps из диалога. Но проблему, которую он решает, вы не выкинете. Так что это за проблема?
Думать как написать модульный, чистый код. Думать над версионированием, следить за коммитами и чтобы ничего не попало в git репозитории, делать тщательное ревью кода. У них огромная поляна работы в которой использование docker никак не поможет!
Вот зря вы про «не поможет». Вся «мякотка» как раз в том, чтобы помогал. Причем «в процессе» разработки, а не после того, как все готово. Честно говоря, «оконтейнеривание» уже готового приложения дает чувствительно худшее соотношение с «ценой свеч».
Вы видели где-нибудь, чтобы разработчики ПО портировали свои продукты только в docker образе
Зато видим, что огромное количество продуктов поставляется и в виде докер образа тоже. Это фактически стандарт.
Мое личное мнение: docker полезен в данном проекте, если команда умеет им пользоваться, и если было произведено сравнение полезности с чем-нибудь еще, в пользу docker'а. Умение использовать — это, как минимум, рабочий Dockerfile, процедура деплоя путем пересборки и замены контейнера и отсутствие необходимости делать что-либо еще на хосте, кроме жонглирования с контейнерами и штатного обновления системы. В моем случае (сайт на Drupal, pet container с целой системой вместо разбивки на сервисы), оба критерия были провалены, команда к смене идеологии с pet на cattle не готова, и руководитель сказал «спасибо» за перевод с неправильно используемого docker'а на LXC, который куда лучше подходит для pet container'ов.
LXC, который куда лучше подходит для pet container'ов.А чем он лучше подходит?
Тем, что при рестарте LXC-контейнер ведет себя как виртуалка (не сбрасывается до исходного состояния). Нет ненужных абстракций в виде образов, репозиториев и томов. Просто клонирование, запуск, остановка и удаление, и еще настройки сети. Плюс еще бекап обычными утилитами вроде tar, как обычного каталога.
Практически согласен, за некоторыми нюансами (чисто справедливости ради):
Есть. Образы, репозитории и тома — все есть. (Не критика, это, скорее, хорошо).
Вот тут плюсов не вижу. Докер вполне можно бекапить совершенно аналогично. docker save/load — ровно тот же тар.
Нет ненужных абстракций в виде образов, репозиториев и томов.
Есть. Образы, репозитории и тома — все есть. (Не критика, это, скорее, хорошо).
Плюс еще бекап обычными утилитами вроде tar, как обычного каталога.
Вот тут плюсов не вижу. Докер вполне можно бекапить совершенно аналогично. docker save/load — ровно тот же тар.
Но это все и в докере есть.
Ну зря вы так. Докер пляшет от иммутабельных образов, т.е. "(не сбрасывается до исходного состояния)" — нету.
Там вся приколюха в том, что докер — это контейнер приложения. LXC (и LXD — отличная штука, очень рекомендую сторонникам LXC) — контейнер ОС. Т.е. «пнул билд — получил образ» vs «вкорячил систему, зашел по ssh, настроил как надо. Что получилось — то и образ». В некоторых моментах работает очень хорошо. Особенно при наличии некоторой экспертизы работы с «честной» виртуализацией.
Там вся приколюха в том, что докер — это контейнер приложения. LXC (и LXD — отличная штука, очень рекомендую сторонникам LXC) — контейнер ОС. Т.е. «пнул билд — получил образ» vs «вкорячил систему, зашел по ssh, настроил как надо. Что получилось — то и образ». В некоторых моментах работает очень хорошо. Особенно при наличии некоторой экспертизы работы с «честной» виртуализацией.
Докер пляшет от иммутабельных образов, т.е. "(не сбрасывается до исходного состояния)" — нету.Вы заблуждаетесь:
docker start, docker stop, docker restart — не сбрасывают контейнер к исходному образу.вкорячил систему, зашел по ssh, настроил как надо. Что получилось — то и образТочно также и на докере — запустите нужный контейнер (дистрибутив), подключаетесь, настраиваете все что нужно и используете сколько угодно — запуск/остановка/рестарт/клонирование/бекапы/перенос на другой хост и т.д. все есть без всяких сбросов до исходного образа.
И в этом плане у LXC никаких видимых преимуществ нет, поэтому переход Docker -> LXC — это просто даунгрейд.
Вы заблуждаетесь: docker start, docker stop, docker restart — не сбрасывают контейнер к исходному образу.
У вас `docker commit` отвалился. Без него в этих телодвижениях мало смысла.
Точно также и на докере — запустите нужный контейнер (дистрибутив), подключаетесь, настраиваете все что нужно и используете сколько угодно — запуск/остановка/рестарт/клонирование/бекапы/перенос на другой хост и т.д. все есть без всяких сбросов до исходного образа.
И в этом плане у LXC никаких видимых преимуществ нет, поэтому переход Docker -> LXC — это просто даунгрейд.
Ну, учитывая то, что docker и lxc — две надстройки над ровно одними и теми же механизмами, было бы странно, если бы они действительно существенно различались.
Справедливости же ради, стоит заметить, что обратная индукция примерно настолько же верна. Я ровно так же могу сделать на LXC все то, что привык делать в докере.
Просто «дефолтное» поведение докера таки `docker run`, т.е. «стартанул контейнер, пнул в нем приложение, дождался, пока оно сдохнет, убил контейнер в память о приложении». Дефолтное же поведение lxc — прикидываться виртуалкой. Т.е. делать этими инструментами можно, конечно, одно и то же, вопрос только в том, что «кесарю — кесарево». Кувалда и молоток — примерно одинаковые инструменты, но первой менее удобно забивать гвозди, вторым — вбивать костыли.
Конечно, строго по широте применения и наработанному инструментарию докер, безусловно, круче. Т.е. если вы уже юзаете докер во все поля, притаскивать новую сущность в виде LXC/LXD смысла особого нет. Но, собственно, если у вас определенные пайплайны, построенные на «честных» виртуальных машинах и соответствующий инструментарий поверх них имеется, а вы хотите оптимизировать расходы на содержание этой прелести — сори, докер для вас — оверхед и лишний геморрой.
Ох, какая статья даже подгорает. Конечно вам не нужен докер, вы же даже не можете почитать документацию.
Сейчас вполне есть возможность прокидывать безопасно любые секреты, которые не будут в конечном образе, а будут использоваться только при сборке. Так же есть кеширование и не нужно каждый раз при изменении кода и даже пакетов выкачивать все полностью.
Почти вся статься показывает, что 3 года знакомства с докером это docker ps и docker run.
Конечно вам не нужен докер, вы же даже не можете почитать документацию.
Я написал что не хочу а не не могу. Я знаком достаточно хорошо понимаю термины docker, например чем образ отличается от контейнера. Читать я умею, однако я получаю деньги не за docker а за программирование, мне приходится очень много копаться в коде проектов и на это я хочу тратить время а не на плюшки которые придумает docker.
Сейчас вполне есть возможность прокидывать безопасно любые секреты, которые не будут в конечном образе, а будут использоваться только при сборке.
Это вы про --ssh парамерт говорите который появился в 18.09? Я всегда пользовался multistage билдом чтобы убедиться что ничего не попало в слой. Добавление --ssh это просто маркетинг, но это мое мнение, не хочу затронуть чувства верующих.
Почти вся статься показывает, что 3 года знакомства с докером это docker ps и docker run.
Статья показывает мою боль с которой я столкнулся при использовании docker. Это моя история и ничего плохого в том что я делаюсь ей — нет.
Я игрался с k8s, c docker-swarm, с docker-daemon, docker-machine. Не подскажите какой там следующий docker-*?
Это вы про --ssh парамерт говорите который появился в 18.09? Я всегда пользовался multistage билдом чтобы убедиться что ничего не попало в слой. Добавление --ssh это просто маркетинг, но это мое мнение, не хочу затронуть чувства верующих.
соглашусь, что это костыль. А вообще оптимально собирать образы не docker build, а kaniko github.com/GoogleContainerTools/kaniko или buildah github.com/containers/buildah
У вас получилось какое-то странное сравнение теплого, мягкого и зеленого.
Docker, Ansible и ssh - это совсем разные инструменты, созданные в разное время и для разных целей. Docker - для создания и поддержки окружения, отличного от окружения на host-компьютере, Ansible - для выполнения задач системной администрации параллельно на большом количестве машин, а ssh - это средство защищенного доступа пользователей к удаленному компьютеру.
Я не знаю, кто из производителей серверного ПО "не поддерживает" Docker - но для тех же MySQL/Postgres/MongoDB есть официальные образы - как и для Python, Go, Dart и так далее.
Может, вы пытаетесь свой стек из scratch строить? Так бросайте это дело, найдите базовый образ близкий к желаемому, и добавьте только недостающее.
А две самых "крутых" "фичи" Docker - это а) возможность скачать какой-нибудь TensorFlow (который вы устанете компилировать, подбирая нужные версии драйверов GPU и 100500 библиотек) - сразу в "готовом к употреблению" виде, и б) возможность поменять всю инфраструктуру (дистрибутив и версию OS, любые библиотеки и утилиты) за пару минут, и экспериментировать с ней, не опасаясь что-то сломать - максимум, убьете этот контейнер и запустите такой же новый.
И последнее - если вы пишете на чем-то интерпретируемом (да и компилируемом тоже) - нет никакой нужды строить новый образ для каждого изменения. Просто сконфигурируйте контейнер так, чтобы он читал сорцы оттуда, где вы их пишете (включая удаленную машину - гуглите rsync или sshfs) - и "заворачивайте" в образ только релизы.
Docker — это игрушка или нет? Или всё-таки да?