Эффективный деплой Node.js приложения

Всем привет. Есть Git репозиторий, в котором монолитное Node.js приложение (Express / MongoDB) и 5 отдельных фронтенд приложений (Vue проекты, отправляют запросы на Node.js сервер). Сайт растет и думаю что скоро прийдется заниматься мастшабированием, но есть вопросы как это делать правильно и эффективно.

Сейчас это все работает на одном VPS, одновременно запущен сервер через pm2, mongodb, redis и nginx, который проксирует API запросы и раздает статику. Деплой делается путем пуша комита на master, а на сервере есть скрипт который слушает вебхуки от репозитория и запускает pull и ребилд всего этого дела, но часто делается деплой вручную (git pull + build).

Как сделать так чтобы с легкостью можно было деплоить все приложение на несколько серверов, с почти нулевым downtime-ом?

Нашел рекомендации использовать Kubernetes + Docker, однако не до конца понимаю "прелесть" контейнеров и как их использовать на продакшене. Буду рад услышать советы/гайды как все это дело настроить. Хочу сделать пару важных замечаний, условия которых должны выполняться при том или ином подходе:

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

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

3. Node.js приложение загружает файлы от пользователей в локальную папку - как это сделать с Docker контейнером, так и еще чтобы можно было легко ее бекапить / изменять / удалять файлы?

4. Пока что не стоит конечная цель "контейнерезировать" весь проект, а просто продумать эффективный деплой на несколько машин. Хостинг позволяет сохранить образ всего VPS и потом на основе его плодить сколько угодно серверов, однако это все равно будут машины которые требуют администрирования.

Заранее спасибо за любую помощь.

0

Сообщение от MrOnlineCoder Сайт растет и думаю что скоро прийдется заниматься мастшабированием

Можно просто поменять железо на более мощное (т.е. лучше проц, больше рам и т.п.), не обязательно "при первом чувстве" браться переписывать код и т.п... Нужно конкретно производить бэнчи, оценивать разные возможности, смотреть где-что больше нагружено и т.п... в конце концов всё сводиться к деньгам, а затраты на перепись под другую экосистему могут быть выше чем просто улучшение железа.

Сообщение от MrOnlineCoder Сейчас это все работает на одном VPS

Второй вариант это купить ещё 1-н VPS и поставить балансировщик перед ними..

Сообщение от MrOnlineCoder но часто делается деплой вручную

А вот этого стоит избегать от слова совсем. Особенно если вы хотите расширяться горизонтально, а не вертикально (увеличением рам или проца)... автоматизация процесса - единственный способ избежать человеческого фактора при мануальном деплое и чем больше и сложнее ваше приложение, тем более вероятна эта "человеческая ошибка", сам сталкивался кучу раз с этим.

Сообщение от MrOnlineCoder Как сделать так чтобы с легкостью можно было деплоить все приложение на несколько серверов, с почти нулевым downtime-ом?

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

Сообщение от MrOnlineCoder не до конца понимаю "прелесть" контейнеров и как их использовать

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

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

Сообщение от MrOnlineCoder настроить конфиги без пересборки контейнера

Это немного не так работает, будете изучать докер поймёте.

Сообщение от MrOnlineCoder так как каждое из этих 5 отдельных фронтенд приложений работает на отдельном домене с разной конфигурацией.

для каждого приложения свой докер файл со своей конфигурацией...

Сообщение от MrOnlineCoder в какой-то реестр -, однако проект коммерческий и исходный код/ ресурсы/ конфиги публиковать нельзя.

да, в реестр обычно нужно, но это может быть и приватный реестр хранящийся на vps..

Сообщение от MrOnlineCoder в локальную папку - как это сделать с Docker контейнером, так и еще чтобы можно было легко ее бекапить / изменять / удалять файлы?

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

Сообщение от MrOnlineCoder а просто продумать эффективный деплой на несколько машин.

Наймите специального человека для этого. Можно как фрилансера, так и на постоянку и т.п., но посыл вот в чём: если сами не знаете как и хотите сами этому обучиться и готовы потратить, ну скажем, пол года - год на оттачивание навыков и т.п. - то можете сами.. Если нет - нанимайте человека (devops, администратор) который всё грамотно настроит и т.п.

2

muxahuk1214, спасибо за развернутый ответ, все таки дождался

Рад буду еще получить уточнения по таким пунктам:

1. Докер это "маст-хев" в таком случае? Я понимаю что это отдельная легковесная среда для приложения, и пробовал с ним локально экспериментировать, перечитал не один гайд / документ относительно работы с ним, но уже стопорнулся на том этапе что мне для работы приложения нужен Redis + MongoDB, и в сети советуют засунуть их в отдельные контейнеры, с чем еще больше возни, всякие там Docker Compose... Т.е. мне проще запустить и настроить бд и редис ручками с полным контролем над ситуацией)

2. До полноценного горизонтального масштабирования еще далеко - начать можно пока с улучшением "железа", потом вынести бд на отдельный сервер с достаточным количеством рам и это решение думаю устроит еще на долгое время. Однако, если все таки дойдет до докупки серверов для самой node.js, то можно воспользоваться функционалом хостинга, создать "снапшот" настроенного сервера и расплодить таких серверов сколько нужно. Однако, в этом случае нужен хороший CI/CD, чтобы обновление сразу на всех сервера приходило. Посоветуйте подходящий набор инструментов для такой задачи - как уже говорил раньше, сейчас это реализовано самописным скриптом который слушает вебхуки от удаленного репозитория, однако сдается мне что такое решение не лучшее. Пробовал Jenkins, однако он прожорлив и настроить все до конца не получилось. Желательно чтобы была возможность отката на предыдущую версию.

Сообщение от muxahuk1214 для каждого приложения свой докер файл со своей конфигурацией

А в этом случае каждый контейнер будет иметь nginx сервер или как? Ведь деплой фронтенд приложения сводиться к npm install, npm run build, и подальшей раздачей статических файлов с папки dist/. Как это засунуть в докер? И как тогда управлять SSL сертификатами, настройкой конфига (тот же Lets Encrypt)?

0

Сообщение от MrOnlineCoder Докер это "маст-хев" в таком случае?

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

Сообщение от MrOnlineCoder Т.е. мне проще запустить и настроить бд и редис ручками с полным контролем над ситуацией)

Если всё таки решишь использовать докер, то нужно будет выносить всё в докер, по крайней мере на сервере.. я локально обычно устанавливаю для девелопмента всё на систему, но знаю и тех, кто использует compose - кстати очень удобно пользоваться.. (кстати, из под винды очень легко поднимать всякие редис или монго, если установить докер клиент/сервер)

По сути можно рассуждать о докере как об "отдельной виртуальной машине", ну т.е. каждый докер имедж это "своя OS" с тем, что ты накидаешь сверху - сервер или редис или монго... суть, если читать оф. доку, сводиться к тому, что они говорят что правильным паттерном является что бы каждый имедж делал только одну задачу (separation of consern).
Крч. Докер файл это инструкция как собрать "виртуальную машину", какие библиотеки установить, какие файлы куда положить и какую программу запустить при старте. (поищи в сети примеры докер файла с комментами и должно стать понятнее.. COPY команда используется для копирования файлов)

Сообщение от MrOnlineCoder Посоветуйте подходящий набор инструментов для такой задачи

тут, как говориться, на вкус и цвет фломастеры разные..
Лучше опишу что у нас есть на проекте и как я это настраивал:
1) Репозиторий, ветка мастер при обновлении посылает сигнал в bamboo.
2) Bamboo выкачивает последние изменения и ранит стадию билда.
3) В билде проверяется качество кода сначала, затем ранятся сканеры и т.п. и создаётся билд докер имеджа. Он сохраняется как артифакт данного билда. (docker build команда вызывается). Внутри докер файла мы делаем npm install, npm build и т.п... и скомпилированный код помещаем в определённую папку и говорим что бы докер запускал "node src/index.js" при его старте.
4) после того, как билд закончился он тригеррит deploy на dev (тут можно ставить, можно не ставить автодеплой, у нас так, что бы не забывать)
5) [нужно заметить, что это шаг отдельный и настраивается отдельно от билда] в деплое мы берём артифакт который был создан в билде и сохраняем его в приватном репозитории
6) далее мы подключаемся к кубернетису, делаем замену версии "сохранённого в репозитории имеджа" и раним команду что бы обновить это всё дело (kubectl apply -k kube/server/dev)

это что касается k8s, если же его нет, то на пункте 6 мы логинимся к серверу через ssh и вызываем команды что бы остановить старый имедж, и запустить новый (если не ошибаюсь типо docker stop #id и docker start #image_name) вообщем запускаем нужный имедж.

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

Сообщение от MrOnlineCoder А в этом случае каждый контейнер будет иметь nginx сервер или как?

да, грубо говоря, как я уже говорил ранее представь что докер имедж это виртуалка.. ты берёшь исходный образ скажем nginx-alpine или что-то типо из docker hub, помещаешь свои файлы в папку и затем загружаешь nginx config файл в нужное место с нужными путями до твоей папки с нужными проксями и редиректами конкретно для этого приложения. (как будто бы на чистую vds ставишь)

Сообщение от MrOnlineCoder Как это засунуть в докер?

на стадии билда ты будешь копировать исходный код в докер имедж и там ранить npm install, npm build и т.п. (наверно не сказал, делается инсталл и т.п. в докере, что бы библиотеки которые ты ставишь были совместимы с "системой докера", а то бывают косяки, когда npm install делаешь на ubuntu, а докер имедж раниться на alpine linux и пакеты могут быть не совместимы, по этому делаем install и build внутри имеджа)

Сообщение от MrOnlineCoder И как тогда управлять SSL сертификатами, настройкой конфига (тот же Lets Encrypt)?

а вот это уже немного другое, как правильно это делать не скажу, т.к. я не девопс. Но, какие у нас вообще есть варианты:
1) запускать докер имедж в нетворке доступном из вне (0.0.0.0) т.е. обращаясь на прямую из вне к серверу на определённый порт мы будем попадать на докер имедж на прямую (такой способ не рекомендуют)
2) запускать имедж в локалхосте (127.0.0.1) и тогда к нему доступ из вне закрыт. И что бы был доступ мы поднимаем на хосте nginx с нашими сертефикатами и ssh и т.п., а затем используя reverse proxy проксируем запросы на адрес докер имеджа (тут же делается и балансировка, т.е. запускаем имедж на разных портах и через ngix лодбалансер на эти 2 порта).

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

В кубернетисе там есть "модуль" ingress в котором это настраивается и проксируется и т.п...

Честно скажу, что разобраться в k8s сложно, я примерно 2 недели потратил что бы понять как и что к чему и как это правильно работает и то не со всем разобрался ещё (т.к. менять конфиги не часто надо)... и да, в k8s лучше не лезть без понимания docker...

ЗЫ: когда я рассказывал про бамбу - остальные тулы работают +- по такому же принципу jenkinss, gitlab ci/cd, azure и т.п...

1

muxahuk1214, спасибо еще раз!

Сообщение от muxahuk1214 а вот это уже немного другое, как правильно это делать не скажу, т.к. я не девопс. Но, какие у нас вообще есть варианты: 1) запускать докер имедж в нетворке доступном из вне (0.0.0.0) т.е. обращаясь на прямую из вне к серверу на определённый порт мы будем попадать на докер имедж на прямую (такой способ не рекомендуют) 2) запускать имедж в локалхосте (127.0.0.1) и тогда к нему доступ из вне закрыт. И что бы был доступ мы поднимаем на хосте nginx с нашими сертефикатами и ssh и т.п., а затем используя reverse proxy проксируем запросы на адрес докер имеджа (тут же делается и балансировка, т.е. запускаем имедж на разных портах и через ngix лодбалансер на эти 2 порта).

Только вот это все как-то сложнее, чуть ли не overengineering какой-то, два сервера чтобы раздавать статические файлы... Не говорю что "это неправильно и не нужно", просто с моей стороны не видно каких-то очевидных плюсов такого подхода

Сообщение от muxahuk1214 Если всё таки решишь использовать докер, то нужно будет выносить всё в докер, по крайней мере на сервере

А та же монго будет хранить данные в докер контейнере? данные базы будут "зашиты" в имедж или там как-то "маппиться" реальная файловая система самой машины к ФС контейнера? И не страдает ли от этого производительность на таком важном компоненте как база даныых - от дополнительного уровня виртуализации? (понимаю, что докер - не ВМ как таковая, а легковесный контейнер, но все же)

И в общем, что делать если автоматизировать деплой нужно "здесь и сейчас" сделать рядовому бекенд инженеру, без возможности потратить год на изучение DevOps, а поиск/найм дополнительного персонала требует больше времени чем есть в наличии?

0

Сообщение от MrOnlineCoder просто с моей стороны не видно каких-то очевидных плюсов такого подхода

когда речь идёт не об одном хосте, а о 10-100, тогда такое имеет смысл.. делаем 1 имедж, а дальше на любую машину одной и той же командой запускаем - типо горизонтальное расширение...

Сообщение от MrOnlineCoder А та же монго будет хранить данные в докер контейнере? данные базы будут "зашиты" в имедж или там как-то "маппиться" реальная файловая система самой машины к ФС контейнера?

Угу, получается, если нужно что бы данные не стерались при перезапуске имеджа нужно монтировать файловую систему в докер имедж.. ну т.е. папку с хоста в папку на имедж и файлы будут сохранятся с имеджа на хост ФС.

Сообщение от MrOnlineCoder И в общем, что делать если автоматизировать деплой нужно "здесь и сейчас" сделать рядовому бекенд инженеру, без возможности потратить год на изучение DevOps, а поиск/найм дополнительного персонала требует больше времени чем есть в наличии?

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

1