>>1905490

> где-то на серваках стартует несколько экземпляров одного нодовского приложения, обращающихся к одной и той же бд

В SQL базах есть такое понятие, как гарантия атомарности. Если ты пошлешь одновременно 2 запроса на запись - ты не сломаешь базу, они просто выполнятся последовательно.

> ничё хорошего из этого не получится

Почему? Запросы не приведут к конфликтам и ошибкам, если ты об этом.

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

Нет, почему? Практики разные бывают, но в общем случае - добавляется реплика сервиса, накатывает миграции, а затем постепенно деплоятся остальные реплики, заменяя старые. Естественно это все нужно самому настраивать либо использовать готовые решения. Миграции в scalable приложениях - это целая отдельная тема

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

Нет, лол. Просто миграции специально делают не ломающими предыдущую схему. Например тебе нужно поменять у поля тип, вместо того, чтобы тупо удалить нахуй колонку и заменить новой - ты делаешь это в 2 этапа. Первая миграция - добавление новой колонки, вторая миграция - удаление старой и переименование новой. Второй этап происходит после того, как поды (реплики) старого приложения были полностью заменены на новые. Это очень кратко и базово, существуют различные техники. Но да, как в монолите с одним инстансом уже не получится просто хуякнуть миграцию и забыть. Вообще при микросервисной/растущим в ширь скейлингом приходит и много новых проблем, таких как shared state, лоадбалансинг и т.д. и т.п.

> Потом запускать экземпляры нового приложения и в один момент как-то переключать пользователей на эти новые экземпляры. Или как?

Объясню на пальцах: у тебя есть один инстанс (пусть будет процесс, грубо говоря приложение одно), ты туда направляешь все запросы (не важно, пусть будет nginx). Теперь ты задумался, что хорошо бы два инстанса сделать, чтобы на каждый из них меньше нагрузка была, соответственно увеличив пропускную способность твоего сайтика (пусть будет просто сайт пока). Тебе нужно какое-то подобие лоадбалансера, т.е. балансировщика нагрузки, который будет запросы от юзера направлять на каждое приложение равномерно, самый простейший - это прописать в NS записях твоего домена разные айпишники/порты твоих двух сервисов, правда тут уже не лоадбалансер, а тупо рандом, более сложные штуки - это умные лоадбалансеры, которые направляют запросы на менее нагруженные инстансы. Не буду вдаваться в подробности. Короче в итоге у тебя все запросы не напрямую в твой инстанс шлются, а в некий gateway лоад балансер, а он уже полностью копирует их и передает на конкретный из двух инстансов, а затем ответ от них также отдает обратно. Естественно писать логику лоадбалансера и спавнить инстансы приложения руками - это слишком долго и муторно. Для этого придумали кучу инструментов, например в том-же кубернетесе есть external service с функциями лоадбалансера, или тот-же traefik, да дохуя их. Кубернетес еще и автоматически умеет спавнить реплики под нужную нагрузку, умеет их убивать и ты можешь прописать различные правила для всего этого. Это и есть девопс.

> Как всё это делать правильно, без гемора и по фэншую?

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

>>1902319 (OP)
Давеча прочитал пост одного хуя, на хабре(так получилось), который сетовал на то, что мол ухх, перевелись нынче девопс инженеры, кадровый дифицит и вообще какие джуны и вкатывальщики криворукие. Только вот хуепутало совсем позабыл одну вещь. Охуевшие галеры хотят себе сразу синьера или мидла, девопс трейни и джуны нахуй не нужны, а
вакансий на них хуй да нихуя, а если и есть, то требования на них такие же как и на мидлов, пиздец. Чтобы попасть просто на ебаного стажера, который будет бесплатно сидеть на жопе полгода и слушать курсы, то нужно знать GitHub и Actions и вообще понимать CI/CD, иметь представление о ООП, разбираться в sql и nosql, шарить за bash\python, уметь в unix\windows на уровне эникейщика(т,е. знать что такое AD, DNS как минимум, траблшутинг утилиты), шарить в вебстеке, apache, nginx, html, разбираться в TCP/IP, разбираться в контейнерах, разбираться в облаках и иметь уровень английского английского языка Intermediate и выше. Это блядь стажер. Ещё один забавный момент, что под понимать и разбираться, галеры имеют ввиду реальное владение инструментами без углубленного понимания. А это я вам хочу сказать не так то уж просто, как минимум нужно просидеть, например несколько месяцев за докером\кубером и перечитать пятаху книг, чтобы только разобраться что да как. И это только контейнеризация, одна маааленькая крупица того, о чем нужно ИМЕТЬ ПРЕДСТАВЛЕНИЕ. Я вкатился в девопс примерно полтора год назад. 6 месяцев я хуярил на епамовских курсах, так это хуйня, чтобы сюда попасть я проходил трехмесячеые курсы по докеру и куберу от другой галеры, с тасками и проверкой, все как положено. При этом у меня изначально был нормальный английский(А2), но этого было блядь недостаточно и я ещё около месяца ходил на курсы языка, при этом у меня за плечами пятилетний опыт системного администратора. Так сука вопрос, откуда взяться девпосам, если их никто не готовит? Если ты сисадмин, то тебе до ебаной матери нужно знать сверху, если ты девелопер, то опять же, тебе до ебаной матери нужно знать сверху. Сейчас я на позиции джуна и не понимаю чем я отличаюсь от мидла, кроме ЗП. Самое смешное что все плачут что нет спецов, но никто не хочет их обучать. Их бля нигде не готовят, так откуда им взяться? Может кто пояснить за такую ситуацию или я просто кипиша нагнял?
инбифо: простыню не читал