FishHook

Вы серьезно? Вот это вот основной критерий выбора инструмента? “Давайте будем современными”!

Ну что вы как маленький? Что вы к оборотам цепляетесь? Само-собой это утрированно, много времени прошло я фактически не помню какие доводы приводили эти люди. Там и противники были и все это не так просто внедрялось. Были и разумные доводы “это удобно” и не очень разумные “зачем что-то новое, я уже так привык!”. Знаю, что в итоге новые инструменты всем понравились.

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

Зачем по вашему я написал? Чтобы проанализировать все эти пункты и сделать ПРАВИЛЬНЫЙ выбор. Мне не нужен кот в мешке.

не поинтересовались наличием кадров на рынке труда

Их никогда нет. НИКОГДА! По крайней мере в моем городе. Если я буду смотреть на наличие кадров, то тут даже не Джанга, тут на Ларавеле придется пилить. Я уже работал в таких условиях - это нормально. Вообще если бы этот вопрос зависил от меня, то я бы точно не выбрал Python, просто потому что у меня нет команды. Я бы мог собрать рубистов, ПХПшников, но тогда бы и вопроса на этом форуме не было. Инвестор нашел питонщиков, инвестор хочет на питоне… инвестор доверяет мне, потому что он знает, что я делал с нуля и возглавлял 3.5 года похожий проект. Он был согласен делать проект на Ruby с моей старой командой, но я считаю неэтичным по отношению к моему бывшему нанимателю уводить ключевых сотрудников из их компании, хочу сохранить хорошие отношения. Мы не сайт планируем, мы вообще в целом не веб планируем, по моей задумке будет всего 2 веб-модуля, на mvp вообще только 1, остальные системы хоть и будут обмениваться данными по http, они не будут иметь вебморды, там скорее всего даже класического роутинга не будет. При разработке такого специфического комбайна, вообще бессмысленно смотреть на “есть ли специалисты на рынке”, потому что их нет и на более простые задачи! Сами станем этими специалистами.

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

Чтобы мой пост не выглядел как просто список библиотек, мне придется немного описать компоненты системы. В данный момент, на dev-машине, проект представляет из себя несколько (не знаю как их обобщенно назвать) модулей/процессов/хостов?:

* Хост c postgres'ом 12-й версии;
* Хост с redis;
* Хост с rabbitMQ;
* Хост с Sentry;
* Хост с экземпляром CRM-системы ЗАКАЗЧИКА написанной на python-3.4. Это готовый софт заказчика с которым нужна интеграция;
* Хост со стабом прикидывающимся карточным проессингом и реализующим его API. Написан на ruby-2.1. Это готовый софт, который я взял с прошлого места работы;
* Хост со стабом прикидывающимся API QIWI. Написан на python-3.8 (Flask) разработан моей текущй командой;
* gw_proccessing - гейтвеей к API-карточного процессинга написанный на ruby-2.1. Это готовый софт, который я взял с прошлого места работы;
* gw_qiwi - гейтвеей к API аггрегатора услуг QIWI, написанный на python-3.4. Это готовый софт заказчика;
* mod_crm - модуль, который просто реализует обертку вокруг CRM'ки заказчика;
* mod_deals - модуль гарантирующий совершение сделки и отмену сделки между пользователем (mod_crm), карточным процессингом (mod_cards) и поставщиком услуги (mod_services).
* mod_cards - модуль интегрированный с процессингом (в будущем с несколькмим процессингами), оебспечивает AML-провекри при совершении пользователем оплаты картой, дает возможность привязать карту на постоянной основе к аккаунту (в mod_crm) клиента для проведения быстрых платежей.
* mod_services - осуществляет прием платежей за услуги поставщика с последуюшим начислением средств на счета поставщика. В данный момент речь идет только о бронировании/продажах билетов для мероприятий. В будущем будет реализована оплата прочих услуг, таких как: оплата за мобильную связь, оплата штрафов, комуналка. По-сути продажа чего угодно с обертками в других мобильных прложениях.
* mod_tickets - Модуль предоставляющий билеты на мероприятие, при этом он может является как владельцем билетов, если событие происходит на объектах заказчика, так и являтся шлюзом к внешней системе, если событие происходит у партнера.
* mod_events - Реестр мероприятий.
* mod_passport - управляет сессиями и выдачей прав посредством JWT. Он регулирует как уровень досутпа пользователя-человека к сервисам системы описанным в mod_api, так и регулирует уровень доступа модулей друг к другу;
* mod_api - Это единственный из mod_*, который доступен из интернета, он, как видно из названия, предоставляет API для взаимодействия с внешними системами.
* tickets_api - Это внешний модуль смотрящий только в mod_api и предоставляющий публичное API для мобилок iOS/ANdroid (Мобильное приложение пронирования билетов). Его задача предоставить только те сервисы, которые необходимы для совершения сделок по билетам;
* services_api - Это второй внешний модуль смотрящий только в mod_api и предоставляющий публичное API для мобилок iOS/Aтdroid (Мобильное приложение оплаты услуг). Его задача предоставить только те сервисы, которые необходимы для совершения сделок по услугам. Работы некоторое время велись, но этот проект, пока что, заморожен по моей просьбе. Мне удалось убедить заказчика не пытаться сделать все и сразу;

Итого: 19 компонентов, т.е. 19 докер-контейнеров. В данный момент готовы прототипы ВСЕХ компонентов.

Окружение разработчика по моему замыслу управляется посредством:
* docker/docker-compose - runtime-среда идеальная для каждого из компонентов;
* pyenv - для управления версиями python;
* poetry - для управления пакетами и их зависимостями.

При наличии docker'а Pyenv нужен просто для корректной работы poetry, а сам poetry нужен ТОЛЬКО для разрешения зависимостей. Правда в команде есть пара разрабов, которые не стали заниматься докеризацией, им для работы требуются и другие варианты использования Pyenv и poetry.

Docker-compose из коробки реализует все основные команды по запуску о остановке как всей системы, так и конкретного модуля в частности. Также для некоторых специфичных операций, таких как: заполнение БД seed-данными, либо снятие какого-то специфичного состояния БД (если вдруг надо переключиться в другую ветку для багфиксов, а затем обратно) пишутся bash-скрипты (пока что нет ни одного длинее 40-ка строк), асортимент которых растет.

Самое большое недовольство, которое я получил от команды, от такого подхода связано с неудобством дебага. Одного Sentry не достаточно, всегда есть необходимость поставить точку останова и разобраться с проблемой по факту, в месте ее возникновения. Но и тут мне удалось решить эту проблему для себя - многое от IDEшки зависит. Тем, кто использует Pycharm, я помог настроить IDE на использоание интерпритатора внутри docker-контейнеров. Теперь и я, и они дебажим просто из Pycharm, расставляя точки останова прям в IDE. Противники Pycharm создали свой альтернативный механизм запуска системы не использующий докеризацию, но вижу, что вторым шагом у них стал поиск аналогичного решения для их IDE'шек. Проблема дебага постепенно исходит на нет .

Теперь о самом стеке. Он не большой, но нарядный
* Все компоненты с префиксом mod_*, а также tickets_api и services_api реализованы на python 3.8;
* Все компоненты с префиксом mod_* реализованы с использованием событийно-ориентированного фреймворка Nameko. Этот фреймворк реализует rpc-вызовы через RabbitMQ, а также grpc-вызовы. На данный момент примерно 8 из 10 внутрисистемных вызовов являются grpc-вызовами, а 2 - rpc. Прекрасный дизайн Nameko позволяет разработчику программировать микросервисы так словно он находится в монолите, т.е. границы чувствуются минимально - очень крутой опыт для меня.
* tickets_api и services_api реализованы на Pyramid.
* mod_api также сделан на Pyramid, но также является и Nameko-based системой. Т.е. внешний мир вызвает сервисы по пирамидовскому роутингу, внутри же, в контроллерах, происходят rpc-вызовы внутренних Nameko-компонентов.
* Для работы с СУБД используется SQLAlchemy, но не ORM. От ORM отказался в пользу реализации Repository.

Спасибо за внимание.

> я помог настроить IDE на использоание интерпритатора внутри docker-контейнеров

А какой профит от Docker-а на машине разработчика?

Rodegast
А какой профит от Docker-а на машине разработчика?

Поднять локально какой-нибудь сервис, чем не юз-кейс то?

> Поднять локально какой-нибудь сервис

Запустить к примеру PostgreSQL в Dockere-е вполне модно, но они там держат код который тестируют. Не понимаю на хрена так делать…

В моем прошлом проекте к моменту (проекту было 9 месяцев), когда я присоеденился к той команде было 7 разных способов запустить систему, в т.ч. и на Docker, но без docker-compose, и еще через 4 месяца остался только 1 и это был вариант БЕЗ контейнеризации.

Я хочу сказать, что победит самый удобный способ. Выше я писал, что не все в команде используют докер, кому-то он не нравится и они пишут свой велосипед без докера - их право. Я описал СВОЙ вариант, вариант, который мне кажется самым уодбным. Я также пытаюсь его распространить.

Rodegast
> Поднять локально какой-нибудь сервисЗапустить к примеру PostgreSQL в Dockere-е вполне модно, но они там держат код который тестируют. Не понимаю на хрена так делать…

Docker-compose мне кажется идеальным инструментом, чтобы вести разработку одновременно в таком количестве компонентов. Мне кажется, что в таком виде система максимально похожа на монолит. Например, мне удалось очень круто расшарить через volumes protobuf-файлы и у меня есть еще идеи расшариванию части повторяющихся структур данных.

Почему тестируемый код плохо поднимать в контейнере? Чем это хуже чем обычный запуск того же на локалхосте? Я выше писал, что да - сначала было трудно дебажить, но сейчас уже все всесьма приятно. Сейчас “тестируемый” код помещается в контейнер через volumes. При этом это volumes не в Dockerfile, а в docker-compose.yml. В этом же docker-compose.yml для каждого контейнера описана команда, которая мониторит код на изменения и если разработчик переписал что-то, то сама перезапускает процесс в контейнере.

P.S. Проект разрабатывается чуть больше 2-х месяцев, если учесть январьские праздники, то и того меньше. Я понимаю, что мог ошибиться в принятии решений, но на текущем этапе мне кажется все очень радужным. Я сюда пришел не для того, чтобы скзать “Docker - это панацея, это то, что я искал”. Я пришел сказать, что я нашел pyenv+poetry, nameko-rpc, nameko-grpc и sqlachemy. Т.е. задавал свой вопрос для того, чтобы их найти и также не утверждаю, что это панацея.

Rodegast
> Поднять локально какой-нибудь сервисЗапустить к примеру PostgreSQL в Dockere-е вполне модно, но они там держат код который тестируют. Не понимаю на хрена так делать…

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

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

А в чём проблема их запустить локально?

> Почему тестируемый код плохо поднимать в контейнере? Чем это хуже чем обычный запуск того же на локалхосте?

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

ИХМО Docker это система контейнерной виртуализации, а не “запускалка сервисов”. Если нуден гибкий запуск/управление сервисами, то лучше сделать bash скрипт который будет запускать/останавливать всё что нужно.

Rodegast

Rodegast
> …Как минимум проблемой с отладкой, с чем собственно ты и столкнулся…

Ну какбы да, я САМ ВЫШЕ говорил об этом, а еще я сказал, что НАУЧИЛСЯ так дебажить. Какие еще проблемы использования докера, кроме тех о которых я и сам рассказал?

Rodegast
>… ИХМО Docker это система контейнерной виртуализации, а не “запускалка сервисов”. Если нуден гибкий запуск/управление сервисами, то лучше сделать bash скрипт который будет запускать/останавливать всё что нужно.

Возможно мы изменим свое решение в пользу баша. Когда, чуть выше, я рассказывал о прошлой работе, то из всех вариантов запуска микросервисов в итоге был выбран именно баш. Мы так работали больше трех лет. Использовал эти скрипты каждый, день, иногда писал их, но всегда хотел, что-то получше. Сейчас есть docker-compose просто потому что я делал протип всей системы в одиночку и это было тупо быстрее в тот момент времени. Текущее положение дел мне нравится куда больше чем в прошлый раз.

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

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

Другими словами:
1 Сейчас я продуктивен, хочется верить, что также про себя думает каждый член команды;
2 Если я перестану быть продуктивным из-за текущего окружения, то я его переделаю. Баш скриптами или чем-то еще - не важно.
3 Я тут писал не про Docker, а про pyenv+poetry, nameko-rpc, nameko-grpc и sqlachemy… Надеюсь, эти инструменты кого-нибудь заинтересуют. Обсуждение докера меня не интересует, я его хорошо знаю и хорошо понимаю какую пользу могу извлечь из его использования.

Rodegast
А в чём проблема их запустить локально?

У меня? У меня нет проблемы - docker-compose up и готово,
это у тебя какие-то проблемы с докером.