Алгоритм деплоя приложения fastapi + react + postgres?

Question

[Natebash]

Хочу разобраться с алгоритмом деплоя приложения на сервер, буду рад если кто-то подкинет статью, видео, доку, либо что-то иное. На работе писал фронт\бэк, юзал докер + jenkins, немного gitlab ci\cd. Но никогда не разбирался как все это работает в связке + настраивается.

Что имею:
Написал простенькое приложение (тудушку) для того что бы разобраться в деплое фулл приложения.

Фронт - next
Бэк - fastapi
БД - postgresql

В докер контейнеры не заворачивал, пока что приложение лежит в виде монорепы на гитхабе, в одной папке вида -

./client 
./server
./git

и крутится на локалхосте.

Есть большое количество вопросов как теперь поставить все это на правильные рельсы, и задеплоить.

Собственно некоторые из вопросов:
Стоит ли использовать архитектуру монорепы, или же все таки разбить фронт \ бэк по разным репозиториям для удобства?
Какой сервер использовать? Сойдет ли дешевый VPS из какого нибудь бегета? Нормально ли там все работает учитывая на сервер нужно прокидывать postgres.
Нужен ли Jenkins?
Можно ли для начала обойтись без докера и просто сливать на сервер build фронта, и поднятый сервер питона.

Comments

[Модератор]

Вопрос нарушает а.3.1, 3.2, 3.4, 3.6, 5.15 Регламента. Причем это повторяется из вопроса в вопрос.
Когда вы регистрировались, вы обещали выполнять Регламент.
Если вы будете продолжать нарушать Регламент, ваши вопросы могут быть удалены, а аккаунт заблокирован модераторами временно или навсегда.
Регламент надо изучить, вопрос надо исправить.
Будьте благоразумны.

[szQocks]

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

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

[mayton2019]

Стоит ли использовать архитектуру монорепы, или же все таки разбить фронт \ бэк по разным репозиториям для удобства?

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

Нужен ли Jenkins?

Ты не можешь гадать нужен или не нужен. Дженкинс - это автоматизация сборки крупного проекта в условиях команды. Если этих условий нет - то тогда выбрось эту идею. Как только у тебя "пригорит" - тогда бери дженкинс
и не спрашивай хабр. Никто не осудит твой выбор.

Можно ли для начала обойтись без докера и просто сливать на сервер build фронта, и поднятый сервер питона.

Да можно. Нужен ли докер или кубернетис. Возьми простую метрику - скорость развертывания и скорость
отката назад в случае если что-то пошло не так. В обычном правильно настроенном проекте откат
ошибочной конфигурации происходит изменением лишь одной версии проекта в конфиге. Даже
заказчик не заметит особенно если у тебя Blue-Green deployment.

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

Answer 1

[Vitaly Karasik]

Все просто - в целом деплой не сильно отличается от деплоя на вашем лаптопе.
Для начала просто возьмите VPS, и добавьте Github Actions который будет строить FE и BE и и копировать их на сервер. Jenkins вам не нужен. Пример - https://fullstackopen.com/en/part11/getting_starte..., или любой пост/видео - есть множество.
Дальше можно думать об улучшениях:
- для монорепо разделить деплой BE и FE
- чтобы дейлой FE был более похож на "настоящий", задеплоить его в AWS S3 или что-то аналогичное
- добавить тесты, static code scanning (SonarCloud например)