> а еще я сказал, что НАУЧИЛСЯ так дебажить

При этом ты создал кучу проблем, да и отладка у тебя может работать только с PyCharm-ом.

> Какие еще проблемы использования докера, кроме тех о которых я и сам рассказал?

Основная проблема в том что у тебя появляется лишняя сущность. По сути что бы запустить несколько процессов тебе приходится устанавливать демона, писать конфиги для docker-compose, возиться с контейнерами/образами, версионировать всё это и т.д. У тебя возникает дополнительная инфроструктура, её нужно администрировать, в идеале для этого тебе нужен дополнительный DevOps инженер.

> я его хорошо знаю и хорошо понимаю какую пользу могу извлечь из его использования.

Я как раз этого момента и не могу понять. В чём смысл тестирования кода под Docker-ом?

> У меня нет проблемы - docker-compose up и готово

Я рад за тебя.

ksimmi
Некоторое время назад взялся пиать скрипт, который хотел использовать так:

 ./debug_module.sh mod_crm

Ну так выложил бы его здесь.
Много слов, мало кода.

Rodegast
> При этом ты создал кучу проблем, да и отладка у тебя может работать только с PyCharm-ом.

Ты постоянно говоришь про КУЧУ проблем, а кучи нет. У пользователь PyCharm'а проблем нет вообще. Также я убежден, что ЛЮБАЯ современная IDE может работать с docker'ом.

Rodegast
> Основная проблема в том что у тебя появляется лишняя сущность. По сути что бы запустить несколько процессов тебе приходится устанавливать демона, писать конфиги для docker-compose, возиться с контейнерами/образами, версионировать всё это и т.д. У тебя возникает дополнительная инфроструктура, её нужно администрировать, в идеале для этого тебе нужен дополнительный DevOps инженер.

• Лишняя сущносность, это докер-демон с его зависимостями + docker-compose.yaml? - Пусть так, но ИМХО комбайн из скриптов на баше - точно такая же сущность и уж точно более сложная в поддержке, дебагге и актуализации.
  

• Версионировать ничего не нужно, ну разве что docker-compose.yaml в git-индекс добавить; Зачем версионировать? Тут я вас возможно не понял.
  

• Никаких DevOps-инженеров не нужно, вы себе, что-то слишком сложное представили. Тут же нет необходимости деплоить и оркестрировать контейнерами через Kubernetes. Под каждый процесс просто по контейнеру. Выучи базовые команды по запуску и останове контейнеров и будет счастье.
  

Ты говоришь “лишняя сущность - сложнее взаимодействовать с ситемой, докер не нужен в dev-среде!” и “пиши комбайн на баш-скриптах это все упрощает”. Я твою позицию понимаю, но тут тоже куча минусов и главный из них - баш. Баш - очень недружественная штука, во всей команде, можно сказать, что я единственный, кто на нем может не то, чтобы писать, а писать понятно. Есть еще пара ребят, кто что-то пишут на баше, но это так… В любом случае много кода на баше в ОДНОМ месте - это очень плохо просто потому что этот код трудно написать, трудно написать понятно, трудно поддерживать, расширять и т.д. Баш скрипты полезны, но я хочу, чтобы это были скрипты-помогайки, а не комбайн.

Вот смотри, на примере возникшей у меня проблемы с доставвкой protobuf-файлов до компонентов системы.
Эта проблема возникла у меня на раннем этапе, еще до того как я принял решение писать docker-compose, точнее в момент когда я выбирал между вариантом с баш-комбайном и docker-compose. На тот момент я делал первую версию прототипа с ВСЕГО 4-ю модулями: mod_cards, mod_deals, mod_services, mod_api.

1 Я описал для каждого модуля .proto структуры - ок.
2 Формирование прото пакетов, два возможных варианта:
2.1.1 Сначала СКОМПИЛИРОВАТЬ .proto-файлы в python-пакеты;
2.1.2 Доставить эти пакеты по модулям, по ВСЕМ модулям ВСЕ варианты пакетов, каждый модуль при этом лежит в разных папках;
2.2.1 Сначала доставить ВСЕ .proto-файлы по ВСЕМ модулям;
2.2.2 СКОМПИЛИРОВАТЬ .proto-файлы в python-пакеты на месте;
3 Чтобы поставленные пакеты были доступны процессам их потребляющим мне надо перезапустить КАЖДЫЙ процесс!

!!! Это уже слишком много геммора даже для ВСЕГО ЧЕТЫРЕХ компонентов, которых потом будет в разы больше.
А если учесть мою хотелку в dev-среде править .proto-файлы и сразу видеть результат изменений в runtime, то получается вообще сложно! Это надо ловить изменения в .proto и запускать алгоритм описанный выше заново.
Также после отработки этого скрипта я всегда имею артефакты от компиляции .proto-файлов, которые ВСЕГДА находтся в дирректории проекта. Конечно, я могу компилировть внутри /tmp-директории, чтобы артефакты компиляции не мозолили мне глаза, но python-пакеты то по процессу попадают в дирректорию проекта, где они мне нужны только в runtime, но не нужны в репозитории. Конечно, я могу добавить их в .gitignore, но глаза то они мозолят. Конечно, я могу расширить наш баш-комбайн таким образом, чтобы он еще и мусор подчищал, но зачем так сложно?

В итоге я сделал все через небольшой баш-скрипт-прото-компилятор и docker-compose:
0 ранее я писал, что в каждом контейнере есть процесс мониторящий изменение СВОЕГО исполняемого кода и перезапускающий основной процесс докера в случае изменений;
1 на dev-хосте есть папка с .proto-файлами примонтированная к каждому контейнеру через volumes. Это значит, что при каждой правке этих фалов разработчиком, ВСЕ контейнеры получают новые .proto
2 есть баш-скрипт, который очень тупенький, но прекрасно умеет решать одну задачу - компилировать .proto-файлы. Скрипт примонтирован как volume к каждому контейнеру;
3 в каждом контейнере есть процесс аналогичный тому, что в п.0 только он смотрит на proto-директорию и при каждом изменении запускает компиляцию .proto-файлов в python-пакеты;
4 процесс из п.0 видит, что кодовая база изменилась и отрабатывает.

Да я без лишнего гемора, получаю runtime-компиляцию .proto-файлов без лишнего геммора, просто по двум причинам:
1 все контейнеры стандартизированы по структуре, очень просты и тупы.
2 баш-скрипт очень простой и применим к каждому контейнеру.

Мне кажется, что это очень удобно!

py.user.next
Ну так выложил бы его здесь.
Много слов, мало кода.

Я выше сказал, что отложил этот скрипт незакончив.

> Ты постоянно говоришь про КУЧУ проблем, а кучи нет. У пользователь PyCharm'а проблем нет вообще.
>> Противники Pycharm создали свой альтернативный механизм запуска системы не использующий докеризацию, но вижу, что вторым шагом у них стал поиск аналогичного решения для их IDE'шек

Тебя точно ничего не смущает?

> Версионировать ничего не нужно

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

> никаких DevOps-инженеров не нужно, вы себе, что-то слишком сложное представили.

Я имел в виду скорее человека который всё это поддерживать будет. Но тут многое от размера проекта зависит.

> Баш - очень недружественная штука, во всей команде, можно сказать, что я единственный, кто на нем может не то, чтобы писать, а писать понятно.

Пиши скрипты не на Basch-е, а на Python-е. Это не принципиально.
ИХМО написать гуй который висит в трее и при необходимости процессы запускает/останавливает это день работы для одного человека.

Rodegast
> Ты постоянно говоришь про КУЧУ проблем, а кучи нет. У пользователь PyCharm'а проблем нет вообще.
>> Противники Pycharm создали свой альтернативный механизм запуска системы не использующий докеризацию, но вижу, что вторым шагом у них стал поиск аналогичного решения для их IDE'шек
…
Пиши скрипты не на Basch-е, а на Python-е. Это не принципиально.
ИХМО написать гуй который висит в трее и при необходимости процессы запускает/останавливает это день работы для одного человека.
…
Тебя точно ничего не смущает?

Ну а что меня должно смущать? Лично мне нравится то, что получается. Я, как инженер, предоставил во-первых прототип проекта, во-вторых - инструменты по управлению этим проектом. Инструменты, как я ранее говорил, возможно, плохие. Никому эти инструменты не навязываются. Хочешь используй и работай, хочешь - нет. Главное приноси пользу, если не можешь быть эффективным с существующими инструментами - напиши свои: хоть баш-скрипты, хоть python-скрипты, хоть gui. Это очевидно и это, элементано, наша работа как инженеров. GUI, я кстати, тоже планирую и вы не поверите, это будет GUI управляющая контейнерами проекта.

Rodegast
Это сейчас не нужно. Ты рано или поздно начнёшь вносить значительные изменения в образы, тогда и версионирование может появится.

Ты прав, но тут ничего страшного, это закономерно для микросервисов. Видимо ты имеешь в виду ситуацию, когда модули начинают раздельную поставку относительно друг друга и соответственно развиваться с разной скокростью и разным циклом поставки. До этой проблемы как до луны, пока не состоиться выход в продакшн. Я так работал уже, к моменту когда проблема себя явит dev-инструменты уже успеют смениться, ну или мы будем в срочном порядке их проектировать. Мне нравится как мы сделали на прошлой работе: после выхода в прод разрабов поделили на команды, каждая команда отвечала за 2-3 компонента системы, к остальным доступа не было. Доступ был только к docker-hub содержащему стабильные билды каждого модуля. Т.е. тег latest означал, что он на проде в данный момент. Мы просто делали pull на dev-машину, поднимали контейнера и работали с ними. Этим, кстати, тоже рулил docker-compose.

> Лично мне нравится то, что получается.

Речь идёт не лично про тебя, а про “команду”. Для части команды работа с контейнерами оказалась не приемлемой. Фактически существует как минимум две дублирующие системы, а это может повлечь определённые издержки.

> GUI, я кстати, тоже планирую и вы не поверите, это будет GUI управляющая контейнерами проекта.

GUI будет заточен только на этот проект или это будет универсальный фронтэнд лоя Docker-а?

Rodegast
>Речь идёт не лично про тебя, а про “команду”.

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

Rodegast
Для части команды работа с контейнерами оказалась не приемлемой.

100% команды никогда с докером не работало и вообще ничего кроме Джанги не видела, я в одном из первых постов говорил, что у ребят из опыта только - разработка сайтиков на Джанге. Они слабые, очень слабые, на таких нельзя равняться. Кто пошустрее тот осилит и останется. Меня вдохновляет то, что по большей части ребят невооруженным взглядом видно, что одни просто в восторге от новизны опыта, даже если не нравится докер, то им нравися изучать Nameko. Есть кстати и парочка ТОКСИЧНЫХ ребят, которым не нравится все, потому что Джангу они знали, а я им НЕДЖАНГУ дал. Если у них ничего не изменится, то я избавлюсь от них.

Rodegast
Фактически существует как минимум две дублирующие системы, а это может повлечь определённые издержки.

Это нормально, в конце концов останется только одна. Я выше писал, что в моем прошлом проекте было 7 таких дублирующих систем в момент когда я туда устроился. И это при команде в 15 человек! Это 1 одному способу запуска на двоих. Такой зоопарк царил 9 месяцев. Возможно такое разнообразие было связано с тем, что ребята фактически сидели в разных частях города поделенными на три группы. Потом, всех собрали вместе и в течении следующих 4-х месяцев неудачные варианты начали отмирать. Достаточно долго жили два варианта одновременно, потом остался один.

Rodegast
GUI будет заточен только на этот проект или это будет универсальный фронтэнд лоя Docker-а?

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

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

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

Когда людей мало, деньги идут непосредственно с разработки клиентам, то все докеры идут лесом, так как на это банально нет времени. 90% - это работа над логикой разработки приложения.

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

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

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

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

Докеры в dev-окружении сложились “исторически”, не смотря на то, что проект молодой. Мы с заказчиком знакомы давно, он был одним из крупнейших клиентов компании, в которой я был тимлидом до этого. Он с начала прошлого года стал пытаться меня схантить, мол “я не хочу отдавать процент со сделок твой компании, это слишком дофига - разработай мне такой же софт + больше”. Я долго не хотел связываться с ним, но затем он в августе сделал ну очень уж хорошее предложение и я решил рискнуть. Мне требовалось около двух месяцев, чтобы передать дела на прежней работе. В начале сентября он решил меня познакомить со “своими” программистами, т.е. с моей будущей командой. Я вообще удивился, что у него есть “свои” программисты, т.к. считал, что у него все его бизнесы - это 100% офлайн-бизнесы, но он оказывается давно пытается отцифроваться. До сих пор не понимаю зачем емы были нужны 12 Django-разработчиков при это еще и НЕЗНАКОМЫХ друг с другом. Т.е. это три маленьких команды, которые пилили для него параллельные проекты. Примерно тогда же я начал прощупывать, что же есть такого в Python, что из этого я хотел бы видеть в своем проекте? Я гуглил, спрашивал, В ТОМ ЧИСЛЕ ЗАДАЛ ВОПРОС НА ЭТОМ ФОРУМЕ! Разработку должны были начать в ноябре, но в октябре я понял, что мне ВНЕЗАПНО стыдно получать ЗП просто так. Выбрав Nameko я просто взял и собрал прототип первых четырех модулей. Это был мой первый опыт с RPC/gRPC, первый опыт с protobuf можно также сказать, что это был ПОЧТИ первый опыт c Python. У меня были некоторые трудности по использованию этого всего, потому что я по-сути учился. Так вышло, что в тот момент времени для меня “серебрянной пулей” оказался docker-compose.

Так вот, когда в ноябре мы собрались командой у нас уже был “исторически сложившийся” Docker.

А Вы стек технологий также выбираете?
Где будем хранить данные? Нууу…. Давайте в postgresql. Почему не в mongo, couchbase или vertika? Да так исторически сложилось.
Вам не кажется, что выбор должен быть обоснован?
Отказаться от плохого выбора на раннем этапе проще, чем, запустив приложуху в продакшн, пилить параллельно вторую версию.