Телеграмм чат группы ctodailychat страница 5064

2020 May 28

IV

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

manage.py migrate --noinput
exec gunicorn ….

источник

20:36пожаловаться #1

A

Andrey in ctodailychat

Artem Napolskih

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

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

Сейчас у нас сделано, через куб-джоб и его ожидание в инит-контейнере сервиса.
Нормально, но не идеально.

Вариант с хелм-хуками рассматривали, но не стали делать.

А может вам это дело в ансибл/ тераформ положить?

источник

21:02пожаловаться #2

VI

Vladimir Ivanov in ctodailychat

Artem Napolskih

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

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

Сейчас у нас сделано, через куб-джоб и его ожидание в инит-контейнере сервиса.
Нормально, но не идеально.

Вариант с хелм-хуками рассматривали, но не стали делать.

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

источник

21:04пожаловаться #3

VI

Vladimir Ivanov in ctodailychat

каким-нибудь флайвеем

источник

21:04пожаловаться #4

VI

Vladimir Ivanov in ctodailychat

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

источник

21:06пожаловаться #5

OB

Oleg Batashov in ctodailychat

Igor V

Я жил на eventstore долго

Тоже жил на нем, но недолго.
Пытаюсь вспомнить что заставило жалеть и думать что надо было хранить JSON событий в PostgreSQL и не мудрить
Кажется, это было связано с разрастанием логов, вопросами бекапа/администрирования в целом
У проекта уже был PostgreSQL, лишь один компонент с ES потащил за собой EventStore
Хороший админ SQL баз был в наличии, а комьюнити вокруг EventStore оставляло желать лучшего в плане быстро найти на SO ответ
Стартап не выстрелил, поэтому в эксплуатации EventStore провел месяцев 6 - вопросы пошли где-то на третьем месяце

Кто-нибудь сравнивал варианты "хранить JSON событий в SQL базе в столбце с JSON типом" vs "юзать базу заточенную под ES"?
Иными словами, что подтолкнуло брать EventStore?
С какими проблемами столкнулись, каких избежали?

Спасибо :)

источник

21:26пожаловаться #6

N

Nikita in ctodailychat

Igor V

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

manage.py migrate --noinput
exec gunicorn ….

А если миграция не выполнится?

источник

21:47пожаловаться #7

IV

Igor V in ctodailychat

Nikita

А если миграция не выполнится?

делать то же самое, что вы бы делали без контейнеров.

источник

21:48пожаловаться #8

IV

Igor V in ctodailychat

Oleg Batashov

Тоже жил на нем, но недолго.
Пытаюсь вспомнить что заставило жалеть и думать что надо было хранить JSON событий в PostgreSQL и не мудрить
Кажется, это было связано с разрастанием логов, вопросами бекапа/администрирования в целом
У проекта уже был PostgreSQL, лишь один компонент с ES потащил за собой EventStore
Хороший админ SQL баз был в наличии, а комьюнити вокруг EventStore оставляло желать лучшего в плане быстро найти на SO ответ
Стартап не выстрелил, поэтому в эксплуатации EventStore провел месяцев 6 - вопросы пошли где-то на третьем месяце

Кто-нибудь сравнивал варианты "хранить JSON событий в SQL базе в столбце с JSON типом" vs "юзать базу заточенную под ES"?
Иными словами, что подтолкнуло брать EventStore?
С какими проблемами столкнулись, каких избежали?

Спасибо :)

ES появился задолго до json типа в pg или кафки. В нашем случае это была главная причина почему использовали es

источник

21:51пожаловаться #9

Y

Yaroslav in ctodailychat

А можно для тупых, что вы подразумеваете под event storming db?

источник

21:51пожаловаться #10

IV

Igor V in ctodailychat

https://eventstore.com/

Event Store