давай ты скажешь сразу к чему ты клонишь =)

дробить можно повсякому интересен же именно твой случай, если одно приложение которое для разработки запускается в одну-две команды, то докер только для разработки будет избыточен. а так 1) docker-engine это простой способ описать как запустить проект 2) docker-compose описывает какие зависимости и на какие сервисы у проекта есть

не я знаю зачем всё это нужно

я просто не понимаю зачем именно докер для разработки, не запуска

вообще докер ни для того, ни для того не нужен

я просто не понимаю зачем именно докер для разработки, не запуска

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

есть виртуалки, в случае питона есть virtualenv

вообще докер ни для того, ни для того не нужен

коллега, у вас asyncio стандарт. ваше мнение очень важно для нас:)

толсто

коллега, у вас asyncio стандарт. ваше мнение очень важно для нас:)

разумеется, стандарт :) спасибо, приятно знать

так вот, докер - это заметание мусора под ковер

есть виртуалки, в случае питона есть virtualenv

поднимать приложение vagrant будет?

поднимать приложение vagrant будет?

ansible провиженинг же оно умеет

поднимать приложение vagrant будет?

можно через vagrant, можно виртуалку заспавнить в облаке, зависит от инфраструктуры

> с докером всё очень просто. всё всегда запускается в одном и том же контейнере. идемпотентность же. куда девается идемпотентность когда на проде и деве разные версии зависимостей. т.к. они могут различаться в requirements.txt и dev-requirements.txt, например? =)

можно через vagrant, можно виртуалку заспавнить в облаке, зависит от инфраструктуры

ок, спасибо, мне с докером в этом плане удобнее

ок, спасибо, мне с докером в этом плане удобнее

если на питоне писать - то редко не хватает virtualenv

с докером возни больше гораздо

> с докером всё очень просто. всё всегда запускается в одном и том же контейнере. идемпотентность же. куда девается идемпотентность когда на проде и деве разные версии зависимостей. т.к. они могут различаться в requirements.txt и dev-requirements.txt, например? =)

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

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

даже прямо из того же самого однажды собранного образа

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

а причем тут докер?

если на питоне писать - то редко не хватает virtualenv

ок, уточню еще раз, если у вас один замкнутый в вакуме проект, то да если для нормальной разработки надо еще пару тройку приложений/микросервисов/сервисов вот здесь и помогает докер*

а причем тут докер?

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

ок, уточню еще раз, если у вас один замкнутый в вакуме проект, то да если для нормальной разработки надо еще пару тройку приложений/микросервисов/сервисов вот здесь и помогает докер*

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

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

в этих конкретных виртуаленвах на этой конкретной машине

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

это должно быть крайне специфичное приложение, если оно от этого зависит

в этих конкретных виртуаленвах на этой конкретной машине

как вариант, да. А потом можно всегда собрать пакеты

это должно быть крайне специфичное приложение, если оно от этого зависит

да тот же pyyaml собираться будет с разными заголовочными файлами

да тот же pyyaml собираться будет с разными заголовочными файлами

и драйверы баз

да тот же pyyaml собираться будет с разными заголовочными файлами

ну так там нужен libyaml-dev, да, разумеется

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

приложение это не только python код, но еще и redis/posgtresql/nginx/varnish ...

приложение это не только python код, но еще и redis/posgtresql/nginx/varnish ...

согласен, но, опять же, причем тут докер?

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

согласен, но, опять же, причем тут докер?

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

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

если заменить docker на ansible или vagrant - ничего не изменится, а головной боли станет меньше

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

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

если заменить docker на ansible или vagrant - ничего не изменится, а головной боли станет меньше

вкусовщина же

если заменить docker на ansible или vagrant - ничего не изменится, а головной боли станет меньше

их нельзя заменить. они все три для разного;)

вкусовщина же

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

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

ну значит не понял)

их нельзя заменить. они все три для разного;)

ну, мы же про организацию рабочего окружения? они все помогают, так или иначе

их нельзя заменить. они все три для разного;)

ansible - провиженинг vagrant - управление состоянием вирталки docker (у многих из под вагранта запускаетя) - обеспечение окружения для конкретного приложения

ansible - провиженинг vagrant - управление состоянием вирталки docker (у многих из под вагранта запускаетя) - обеспечение окружения для конкретного приложения

ansible - не провижнинг, это система управления конфигурацией

больше технологий для бога технологий

провиженинг - это cobbler, например

ansible - не провижнинг, это система управления конфигурацией

вот видишь, ты сам всё знаешь:)

вот видишь, ты сам всё знаешь:)

именно :) так и зачем мне докер при разработке или деплое?

я так и не понимаю

я так и не понимаю

это нормально. не нужен, не используй.

ну, я пытаюсь понять логику людей :) всем он так нравится, а я не особо хорошо отношусь к этому поделию

может, не замечаю чего-то важного

может, не замечаю чего-то важного

это очевидно. тебе про это важное уже минут 20 в чате пишут же:)

это очевидно. тебе про это важное уже минут 20 в чате пишут же:)

например?

например?

перечитай.

покажи мне задачу, для которой он необходим

так я и перечитал, нет такого :)

покажи мне задачу, для которой он необходим

такой задачи нет

без него проще

такой задачи нет

вот-вот

более того, нет задачи для которой необходим venv или asyncio

более того, нет задачи для которой необходим venv или asyncio

это просто варианты решения, разумеется

есть гарантии, которые докер даёт.

но хайп-то есть

есть гарантии, которые докер даёт.

например?

идемпотентность. повторяемость. изоляция.

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

идемпотентность. повторяемость. изоляция.

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

ERROR: S client not available

> из докера в IDE не видно пакетов. хотя, а можно же замапить volume... вобщем моё недоумение вызывает только вот это. Просто про потенциальную возможность _запуска_ приложений можете не лечить, тут всё очевидно итак. Вопрос для меня только в разработке в докере.

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

на одинаковых версиях docker?

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

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

видел как контейнер собраный в убунте, отказывался работать в убунте, правда на разных версиях докера =))

на одинаковых версиях docker?

разумеется

там тогда были всякие терки насчет aufs/overlayfs еще

и оно тупо не работало

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

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

там тогда были всякие терки насчет aufs/overlayfs еще

ну ты вспомнил.;)

и оно тупо не работало

1.12 работает :)

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

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

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

смотря чего. в твоем намеке нет аргументации

я не знаю, что они там сейчас починили, но не забывай, что все это - просто чуточку кода, накрученного поверх cgroups в ядре

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

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

ну у всего есть trade-off. но докер удобнее виртуалок для запуска нескольких изолированных сервисов, тут не может быть вопросов. docker-compose на 20 строк за 10 минут поднимает мне проект на древенем питоне с древними версиями пакетов вместе с древней монгой 2.6. и всё работает.

я не знаю, что они там сейчас починили, но не забывай, что все это - просто чуточку кода, накрученного поверх cgroups в ядре

ну lxc давно уже многие любили;)

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

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

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

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

типа того;)

ну у всего есть trade-off. но докер удобнее виртуалок для запуска нескольких изолированных сервисов, тут не может быть вопросов. docker-compose на 20 строк за 10 минут поднимает мне проект на древенем питоне с древними версиями пакетов вместе с древней монгой 2.6. и всё работает.

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

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

докер? на голом железе? что?

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

в 95% случаев нужно ацкое окружение. более того, штук 4-5 на горячем переключении обычно

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

докер? на голом железе? что?

имелас в виду операционка на голом железе, не придирайся;) понятно же:)

в 95% случаев нужно ацкое окружение. более того, штук 4-5 на горячем переключении обычно

откуда цифра такая? мне в моей работе в 95% случаев даже близко ничего такого не надо было

имелас в виду операционка на голом железе, не придирайся;) понятно же:)

эээ. окей. тоже интересна статистика, но ладно

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

это громоздко и не нужно. я имел счастье перевести проект с vagrant+ansible на docker+docker-compose и ansible для конфигурации этого на проде - небо и земля

эээ. окей. тоже интересна статистика, но ладно

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

@Enchantner, ты используешь ансибл для настройки окружения прямо на машине разработчика или в виртуалках?

это громоздко и не нужно. я имел счастье перевести проект с vagrant+ansible на docker+docker-compose и ansible для конфигурации этого на проде - небо и земля

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

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

у нас в конторе есть и то и то :) нам надо, у нас датасаенс, он на виртуалках хуже себя ведет

@Enchantner, ты используешь ансибл для настройки окружения прямо на машине разработчика или в виртуалках?

в основном в виртуалках. Но не вижу проблем особых его использовать и там и там