What stack should be used to organize the deployment and clustering of such a project?

Question

Clustering

There is a project with this architecture:

Frontend communicates with api via http requests and receives realtime updates via constant websocket connections. Api servers have a single database, and also communicate with each other via redis (mainly for delivering realtime updates via websockets).

The project is not very large. Most likely, one real server for the frontend, one for the api and one for the database will be enough (at first everything will be on the same server). In this regard, the following questions arise:

1. What is the best and easiest way in this case to organize continuous deployment and clustering of the frontend and api. Do I need to resort to using, say, kubernetes in this case, or is pm2 enough?
   
2. If you use socket.io to implement an uninterrupted connection, then how to configure the balancer so that there are no problems with long polling support?
   

Answer 1

one.

best and easiest

is a subjective matter. For me, it's easier without K8S, but for sure, young people will say that it's easier with him.

Most likely, one real server for the frontend, one for the api and one for the database will be enough (at first everything will be on the same server)

If you still want clustering, then probably still look at K8S. Its advantage is that the architecture will be very similar both on a single real server today and on a cluster in the future. To suffer once and set up ingres - and then you can migrate somewhere relatively easily.
If for a start we want to quickly deploy everything on one server, then of course without it, just install nginx, API engine, Database and Redis.
By the way, if the frontend is angular / react, etc., then it’s easier to deploy them to a service for static pages - S3, etc. (if clouds are considered).
2. You need to look at a specific balancer and app server.
The general idea is this:
a) mark the server as inactive
b) wait until all sessions are over
c) update
d) return to the balancer
f) move to the next server