Aloje múltiples aplicaciones React en un VPS

#Dé un límite a cada aplicación

Asigne a cada aplicación un directorio de lanzamiento, un proceso supervisado, un puerto local y sus propias variables de entorno. Un proxy inverso compartido selecciona el destino por dominio. Los reinicios deben apuntar a un servicio identificable sin afectar a los demás.

Para diferentes clientes, examine también las cuentas de servicio y los permisos. Los procesos que comparten una cuenta pueden acceder a archivos legibles por esa cuenta. Un puerto separado no es un aislamiento de seguridad. Es posible que se necesiten contenedores o máquinas separadas para el límite requerido.

#Planificar dominios y puertos locales

Esta tabla ilustra una disposición. Reemplace los nombres de ejemplo.com con sus dominios. Los puertos locales no son URL públicas: el navegador se conecta al proxy.

Cada dominio necesita un certificado válido y una configuración adecuada. Verifique enlaces absolutos, devoluciones de llamadas de autenticación y cookies para ese dominio. Compartir un dominio en rutas separadas requiere una configuración de activos y prefijos adicionales. Los subdominios suelen evitar ese acoplamiento.

#Presupuesto para picos que se superponen

Registre la carga inactiva, ordinaria y el uso máximo representativo de cada servicio. Agregue servicios compartidos, el sistema operativo y el margen de implementación. Cuente una base de datos compartida una vez en el presupuesto total, con su propio pico.

Luego cargue dos aplicaciones al mismo tiempo. Las pruebas aisladas pueden perder la competencia por CPU, conexiones de disco y de base de datos. Si un equipo presenta demostraciones en horario laboral, los periodos de actividad pueden coincidir.

Construya un presupuesto de memoria a partir de sus mediciones

#Establecer límites explícitos de recursos

En un sistema con los controladores necesarios, systemd puede monitorear y restringir un grupo de procesos. En un acceso directo al servicio probado, MemoryHigh introduce presión de recuperación, mientras que MemoryMax establece un límite estricto que puede conducir a la terminación. CPUQuota limita el tiempo CPU.

Este fragmento ilustra la sintaxis. Reemplace los valores después de medir; No se recomienda la talla Next.js. Una aplicación que alcanza su límite puede ralentizarse o fallar, así que inspeccione la latencia, los eventos de memoria y los registros. El límite debe cubrir los procesos secundarios además del padre.

[Service]
MemoryAccounting=yes
MemoryHigh=512M
MemoryMax=768M
CPUQuota=100%

#Evite que las compilaciones abrumen a las aplicaciones vecinas

Planifique las compilaciones y la limpieza por separado de los procesos activos. Cuando sea posible, incorpore CI compatible e implemente un artefacto verificado. De lo contrario, incluya la compilación en el presupuesto de recursos compartidos y evite costosas compilaciones simultáneas.

Utilice un directorio por versión y verifíquelo antes de cambiar. Las conexiones existentes y los recursos que necesitan las pestañas ya abiertas requieren atención. Las copias de seguridad de las bases de datos permanecen separadas de los archivos de las aplicaciones; pruebe periódicamente la restauración utilizando datos de prueba.

#Evaluar el sueño para proyectos intermitentes.

PRNext puede liberar la memoria de los trabajadores inactivos a costa de tener que despertarlos. Eso puede ayudar cuando los períodos de inactividad son prolongados y las visitas iniciales pueden aceptar el retraso. Los sondeos frecuentes o las solicitudes en segundo plano pueden cambiar el comportamiento.

Antes de agregar proyectos, pruebe también los despertares simultáneos. La sonda de memoria publicada por PRNext cubre una pequeña aplicación; no establece un recuento de sitios garantizado. Las bases de datos, el proxy, el sistema y los cachés conservan sus propios requisitos.

Comprender los entornos de sueño y sus limitaciones.

Verificar la implementación pública de cada aplicación