Тестировать вручную 50 микросервисов из-за минорного обновления одной либы?

не рабочий сервис из-за минорного обновления, вот это звучит безумие

Тестировать вручную 50 микросервисов из-за минорного обновления одной либы?

Да что ты знаешь об патчах на ядро?

Допустим у вас есть 50+ микросервисов и вам надо обновить либу для логгирования. Вы будете каждый микросервис вручную тестировать? Или откажетесь от идеи обновления либы вообще?

обновлю вместе с другими изменниями. ради либы релиз не буду делать если конечно сервис развивается

не рабочий сервис из-за минорного обновления, вот это звучит безумие

Да с чего бы он станет полностью не рабочим? Можно использовать canary-testing. Да, можно какое-то кол-во ошибок получить в проде и сразу откатиться. Но ручное тестирование тоже полностью от такого сценария не избавляет

обновлю вместе с другими изменниями. ради либы релиз не буду делать если конечно сервис развивается

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

каждый сервис пусть решает сам

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

если не секьюрити, можно и забить на апдейт

если не секьюрити, можно и забить на апдейт

Ну не всегда можно забить на обновление. Может быть общая инфраструктура, которая используется микросервисами, и которая периодически может меняться. И микросервисы должны эти изменения поддерживать

общая инфраструктура для микросервисов - боль. Ты должен предусмотреть что они не обновятся одновременно

общая инфраструктура для микросервисов - боль. Ты должен предусмотреть что они не обновятся одновременно

Они и так не обновляются одновременно. А без общей инфраструктуры как может быть?

каждому микросервису свой инстанс rabbitmq, например?

Ну общая инфраструктура должна быть минимизирована, ага

каждому микросервису свой инстанс rabbitmq, например?

А что, у него что-то меняется?

Я понимаю, переезд на новый формат логов

Короче, если надо - обновляем.

А что, у него что-то меняется?

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

Какого сервера?

Я понимаю, переезд на новый формат логов

ну и этот пример хороший, да

Какого сервера?

ну давай возьмем для примера Elasticsearch

У них общих ресурсов должен быть минимум, рэббит, логи и всё

ну давай возьмем для примера Elasticsearch

Ну это просто база. Она относится к какому-то сервису

под каждый микросервис отдельный кластер elasticsearch держать?

Почему у всех микросервисов эластик?

Напрямую в базу ходить - антипаттерн

Напрямую в базу ходить - антипаттерн

а как приложение должно ходить в базу?

В свою базу напрямую. В чужую базу - вообще не знать о её существовании, а обращаться к сервису

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

А. Все юзают один инстанс эластика

это антипаттерн, я согласен

да

Со своими индексами?

да

Ну тогда да. Обновление сервера - тяжело

Хотя протокол там хттп, вроде обратно совместим

Хотя протокол там хттп, вроде обратно совместим

нет, запросы могут быть несовместимы

формат некоторых запросов формируется в драйвере

Драйвере?

и может отличаться в разных версиях

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

ну давай назовем это клиентской либой

Короче, это уже не минорное обновление о котором ты начал

А редкий переезд.

просто некоторые называют это драйвером. Например разрабы кассандры называют клиентскую либу Python Cassandra Driver

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

Поднимать новый инстанс и туда мигрировать по одному

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

Ну понятно что они не в один момент выкатываться будут. Но тем не менее в какой-то ограниченный промежуток времени

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

Короче, это уже не минорное обновление о котором ты начал

Могут быть и более мелкие изменения в либах, которые надо обновить

ну вот от ситуации и надо плясать

нет универсального ответа

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

pipenv?

например

Хай, народ Где можно почитать/смотреть туториалы по kivy? Вчера весь день искал и почти ничего не нашел

да сдался тебе он

да сдался тебе он

Питоничненько

киви фуу

если пилить под ондроеды то тут путхлоном не обойдешся

учи java

и качай Android Studio

или kotlin

Подскажите, есть же какая-то библиотекак TaskManager для сервера, чтобы можно было передать туда метод, параметры и каким-то простым способом получать оттуда состояния и ответ? Это, наверное, должна быть какая-то обертка вокруг multiprocessing.

Подскажите, есть же какая-то библиотекак TaskManager для сервера, чтобы можно было передать туда метод, параметры и каким-то простым способом получать оттуда состояния и ответ? Это, наверное, должна быть какая-то обертка вокруг multiprocessing.

ProcessPoolExecutor не подходит?

Ребята, привет. У меня короче код исполняется через asyncio, нужно чтобы если в потоке произошло исключение - падал и основной процесс, дабы супервизор потом все перезапустил. Сейчас делаю так: lp = asyncio.get_event_loop() lp.set_exception_handler(partial(exc_handler, log=app['logger'])) lp.create_task(consume_callback(channel, body, envelope, properties, app)) Чтобы все исключения из consume_callback попадали в : def exc_handler_panic(loop, context, log: logging.Logger): log.error(context, extra={'stack': True}, exc_info=True) raise Exception('Panic thread error, need close main process') И падал основной процесс

Но походу это не рабайтан

ERROR: S client not available

pipenv?

почему не pip и requirements, ведь пофиг что у тебя на машине установленно, тебе всё равно придётся файл конфигурации для прода менять. почему бы это руками не поменять просто в файле requirements

почему не pip и requirements, ведь пофиг что у тебя на машине установленно, тебе всё равно придётся файл конфигурации для прода менять. почему бы это руками не поменять просто в файле requirements

Как отслеживать все неявные зависимости?

Как отслеживать все неявные зависимости?

Так же pip freeze

Так же pip freeze

А как отделять dev-зависимости?

А как отделять dev-зависимости?

а это что?

чтобы, например, установленный локально ipython не попадал в requirements.txt

А как отделять dev-зависимости?

Так же как и в pipenv , свой конфиг свой раздел

Так же как и в pipenv , свой конфиг свой раздел

Можно пример? Я при локальной разработке клонирую репу, делаю pip install -r requirements.txt, потом ставлю, например, ipython для удобства разрабтки. В процессе разработки решаю добавить новую либу в requirements.txt. Делаю pip freeze > requirements.txt и в нем оказывается ipython

Я вижу выход только в создании нового чистого virtualenv'а каждый раз когда мне надо что-то добавить или изменить в requirements.txt

Можно пример? Я при локальной разработке клонирую репу, делаю pip install -r requirements.txt, потом ставлю, например, ipython для удобства разрабтки. В процессе разработки решаю добавить новую либу в requirements.txt. Делаю pip freeze > requirements.txt и в нем оказывается ipython

Как тебе в этом сценарии может помочь pipenv?

Просто не надо делать pip freeze > requirements.txt

надо pip freeze -r requirements.txt

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

Как тебе в этом сценарии может помочь pipenv?

Можно сделать pipenv install ipython --dev, тогда она попадет в секцию dev Pipfile'а. Если мне нужно, чтобы вообще никуда не попадало, то можно сделать pip install ipython, возможно это как-то и pipenv'ом можно сделать

Можно сделать pipenv install ipython --dev, тогда она попадет в секцию dev Pipfile'а. Если мне нужно, чтобы вообще никуда не попадало, то можно сделать pip install ipython, возможно это как-то и pipenv'ом можно сделать

Я правильно понимаю что в секцию дев запишется ipython со всеми зависимостями?

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

Нет, от этого же зависит только порядок вывыдимых зависимостей

Я правильно понимаю что в секцию дев запишется ipython со всеми зависимостями?

Если сделать pipenv install ipython --dev, то да

если сделать `pip install ipython`, то вообще никуда не запишется

Если сделать pipenv install ipython --dev, то да

Согласен тут с тобой, просто через pip будет не так удобно

Нет, от этого же зависит только порядок вывыдимых зависимостей

ок, тогда надо немного седа, чтобы отфильтровать все то, чего там нет

Согласен тут с тобой, просто через pip будет не так удобно

Да ,это просто вопрос удобства. С pip freeze тоже можно вполне жить, но чуть больше манипуляций делать придется.

мне проще, я свой requirements.txt поддерживаю руками

потому что у меня еще есть requirements-dev.txt например

ок, тогда надо немного седа, чтобы отфильтровать все то, чего там нет

Не очень представляют как это должно работать

Допустим у нас есть requirements.txt. Помимо зависимостей в нем, у меня в окружении стоят dev-зависимости. Теперь я решил добавить в проект, например, aiohttp. Что я должен сделать?

pip freeze -r requirements.txt печатает сначала что в requirements.txt, потом пустую строчку, потом коммент "это добавлено pip freeze-ом"

а потом остальное

надо взять requirements.txt, вписать туда aiohttp

потом pip install -U -r requirements.txt

так, а дальше?

потому что у меня еще есть requirements-dev.txt например

Установил ты дев , потом добавляешь новую либу, как ты это добавишь в прод requirements ?

как получить потом нужный requirements.txt, в котором будут все зависимости aiohttp?