Size: a a a

DevOps — русскоговорящее сообщество

2021 April 29

AE

Ant0n Erem1n in DevOps — русскоговорящее сообщество
источник

А

Александр in DevOps — русскоговорящее сообщество
такое уже нашел да) запросы в гугл первую 10 я уже открыл :D изучаю
источник

DZ

Daniil Zobov in DevOps — русскоговорящее сообщество
бесшовно есть вариант только адаптируя приложение, можно попытаться по следующим шагам:
1) научить приложение работать с обеими СУБД
2) выделить таблицы, которые работают только на insert и сразу вставку и обращение к ним перевести на MongoDB
3) таблицы с активным update/delete - операции производить сразу в двух банках после первичной миграции с даунтаймом
4) перевести чтение на Mongo
источник

DZ

Daniil Zobov in DevOps — русскоговорящее сообщество
эти инструменты не помогут, если ты хочешь на живой базе мигрироваться
источник

DZ

Daniil Zobov in DevOps — русскоговорящее сообщество
даунтайм как ни крути будет
источник

А

Александр in DevOps — русскоговорящее сообщество
Да, примерно такой план и разработали по идее... только касательно апдейтов думали насчет триггеров в MySQL на них насколько мне подсказали можно повесить скрипт на любом языке, вот туда на апдейты и поставить скрипт который будет делать то же самое в монгу
источник

DZ

Daniil Zobov in DevOps — русскоговорящее сообщество
а смысл, если в приложении это все равно придется реализовывать?
источник

DZ

Daniil Zobov in DevOps — русскоговорящее сообщество
плюс есть шанс того, что в одной из СУБД произойдет ошибка операции и у тебя пойдет рассинхрон. А в приложении у тебя есть вариант это транзакциями разрулить и там и там
источник

А

Александр in DevOps — русскоговорящее сообщество
как раз чтобы в приложении не вносить изменения, а чисто по тригерам тягать из моськи, ибо там приложение на старом коде которое не очень хочется трогать если честно)
но касательно ошибки да... есть такой грешок.. возможен
источник

DZ

Daniil Zobov in DevOps — русскоговорящее сообщество
и как вы собираетесь не трогая код переехать в монгу?
источник

WD

Web Dev in DevOps — русскоговорящее сообщество
привет всем, скажите пожалуйста что лучше выбрать мне новичку для развертывания кубернетис кластера?

gitlab или openShift ?

либо я сравниваю теплое с мягким? Или у них похожие функции?
источник

DZ

Daniil Zobov in DevOps — русскоговорящее сообщество
теплое с мягким
источник

DZ

Daniil Zobov in DevOps — русскоговорящее сообщество
openshift уже под капотом имеет k8s
источник

А

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

DZ

Daniil Zobov in DevOps — русскоговорящее сообщество
gitlab это git, registry и ci/cd. Еще он умеет интеграцию с k8s кластером
а openshift - это платформа для запуска контейнеризированных приложений
источник

AE

Ant0n Erem1n in DevOps — русскоговорящее сообщество
источник

K

Konstantin in DevOps — русскоговорящее сообщество
Можно в ранчер попробовать
источник

K

Konstantin in DevOps — русскоговорящее сообщество
А цель какая?
источник

WD

Web Dev in DevOps — русскоговорящее сообщество
openshift может собирать образы и деплоить, гитлаб тоже умеет это

openshift может подтягивать с гит репозитория мои конфиги и деплоить, гитлаб сам почти гит, умеет хранить конфиги и деплоить
источник

WD

Web Dev in DevOps — русскоговорящее сообщество
мне нужно удобно разворачивать все, а то в консоли это делать задолбался
источник