Instancias

Una instancia de Chinaski es un sitio completo: su propio proceso de aplicación, su propia base de datos, sus propios archivos, su propio conjunto de respaldos, su propio secreto. Ejecutar varios sitios significa ejecutar varias instancias; una al lado de la otra en el mismo servidor si así lo deseas. Esta página explica el modelo y, lo que es importante, qué está aislado y qué no.

Una instancia, un sitio

Cada instancia es una copia completa e independiente:

• Su propio proceso de aplicación admin (un servicio de systemd como chinaski@1, chinaski@prod, chinaski@staging: el mismo patrón de unidad ejecuta cualquier cantidad)
• Su propio archivo de base de datos SQLite: contenido, usuarios, formularios, registros, todo
• Su propio directorio de salida: los archivos estáticos que publica tu servidor web
• Su propio directorio de medios
• Su propio secreto maestro (en un archivo con permisos restringidos creado durante la instalación)
• Su propio puerto (3001, 3002, …; cada uno único en el host)
• Su propio directorio de respaldos y programación
• Sus propios dominios (a través del proxy inverso, o gestionados mediante el Manager)

Nada se comparte entre instancias: ni contenido, ni usuarios, ni formularios, ni registros, ni sesiones. Los sitios no pueden verse entre sí, y sus admins tampoco.

Por qué este diseño

La audiencia declarada del software hace evidente el razonamiento: "Agencias que gestionan varios sitios de clientes: una instancia por cliente, stack idéntico, despliegue reproducible, audit log limpio, sin dependencia del proveedor." Duplicar stacks completos es más disco y menos riesgo: una intrusión, un despliegue fallido o un único actor malicioso en una instancia afecta ese sitio y nada más. Cuando un cliente decide irse, le entregas su base de datos, su salida y su directorio de medios: todo está en una sola carpeta.

El aislamiento en la práctica

• El proceso: la aplicación de cada instancia queda aislada (sandbox) por systemd para leer/escribir únicamente su propio directorio; ni siquiera un bug en el código del CMS de un sitio puede tocar los archivos de otro.
• La base de datos: cada sitio tiene su propio archivo SQLite, almacenado con permisos de lectura solo para el usuario. No hay un servidor de base de datos compartido que vulnerar, y las credenciales de una instancia no sirven en otra.
• Secretos: cada instancia tiene un secreto maestro único; las credenciales filtradas quedan limitadas a un sitio.
• Sesiones: los inicios de sesión del admin viven por completo en la base de datos de una instancia y se firman con el secreto de esa instancia; un admin de un sitio simplemente no tiene sesión en otro.
• Puertos y dominios: cada instancia escucha en su propio puerto de loopback detrás del proxy; si se usa el Chinaski Manager opcional, la unicidad de puertos entre instancias la hace cumplir el propio Manager.
• Respaldos y despliegues: los respaldos y los trabajos de build/deploy son por instancia; un build fallido en un sitio nunca afecta a otro.

Ejecutar muchos sitios

Dos formas, y cooperan entre sí:

1. A mano: el patrón de unidad de systemd incluido más el instalador de un solo comando. Cada instalación es una instancia; actualiza los sitios de uno en uno con el script de deploy por instancia.
2. Con el Manager (producto aparte): un panel de control que aprovisiona instancias, ejecuta su ciclo de vida (build, deploy, rollback, iniciar/detener), adjunta dominios (regenerando la configuración del servidor web automáticamente), toma respaldos por instancia y supervisa la salud de las instancias. Su función Discovery encuentra instancias que ya corren en el servidor (configuradas con systemd, como las de arriba) y las importa para su gestión.

Existe una opción de eficiencia para hosts con muchas instancias: las dependencias de Perl pueden instalarse opcionalmente en una librería compartida para que el deploy de cada instancia no las descargue de nuevo (opt-in, y la unidad de cada instancia debe incluir la ruta).

Lo que "multi-tenancy" no significa aquí

• No hay una base de datos multi-tenant: cada sitio conserva su propio archivo de datos, según la declaración de diseño del propio proyecto ("una instancia por cliente"). Un nivel multi-tenant dentro de la aplicación con Postgres está en el roadmap y sin entregar.
• Los "tenants" del Manager son una agrupación a nivel de manager para organizar instancias y permisos; no pone varios sitios en una sola base de datos.

El resumen en una línea

Diez sitios = diez stacks pequeños, idénticos y aislados más un panel de control opcional; cada sitio puede respaldarse, restaurarse, actualizarse, desplegarse, transferirse o eliminarse individualmente, y un problema en uno nunca toma como rehenes a los demás.