DOCKER - MATRIX
💬🐳 Chat propio con Matrix: Synapse, Element y HTTPS con Docker
En esta práctica se levanta un servidor de mensajería propio con Matrix, el protocolo abierto y descentralizado de comunicación en tiempo real, desplegando Synapse (la implementación de referencia del homeserver) junto con su base de datos, el cliente web Element y un proxy inverso con HTTPS, todo con Docker Compose.
El escenario parte de una necesidad habitual en cualquier equipo u organización: disponer de un canal de chat propio, sin depender de un proveedor externo ni de que las conversaciones vivan en la infraestructura de un tercero. A diferencia de otras plataformas de colaboración que exigen un proveedor de identidad externo para poder iniciar sesión, Matrix resuelve la autenticación con su propio sistema de cuentas locales, gestionado directamente por quien administra el servidor. El reto técnico principal no está en levantar el servidor en sí, sino en dejarlo accesible de forma directa por IP desde cualquier equipo de la red, sin depender de trucos del lado del cliente ni de un dominio público.
🧰 Tecnologías empleadas
Docker y Docker Compose Motor de contenedores que aloja las cuatro piezas del stack (base de datos, homeserver, cliente web y proxy inverso) como servicios independientes, con las credenciales gestionadas en un archivo .env separado del propio despliegue.
Synapse Implementación de referencia del homeserver de Matrix: gestiona las cuentas de usuario, las salas de conversación y el histórico de mensajes, y expone la API cliente-servidor que consume Element.
PostgreSQL Motor de base de datos donde Synapse persiste cuentas, salas y mensajes, desplegado como contenedor independiente con su propio volumen de datos.
Element Cliente oficial de Matrix, tanto en su versión web autoalojada como en su aplicación de escritorio, que permite iniciar sesión y conversar contra el homeserver propio.
Nginx como proxy inverso Pieza que sirve el certificado HTTPS y reparte el tráfico entrante según la ruta solicitada, entre el cliente web y la API del homeserver, bajo un único origen seguro.
Certificado autofirmado Certificado HTTPS generado localmente con OpenSSL para la IP del propio servidor, sin depender de una autoridad de certificación pública ni de un dominio, adecuado para un despliegue interno.
🎯 Objetivos de la práctica
El objetivo principal es demostrar que se puede levantar una plataforma de mensajería privada y funcional en una única tarde, sin depender de ningún proveedor de identidad externo y sin necesidad de un dominio público, cumpliendo aun así con los requisitos de seguridad que exige cualquier navegador moderno para un cliente de mensajería cifrada.
De forma más concreta, se busca desplegar Synapse y su base de datos con Docker Compose, generar la configuración inicial del homeserver, poner un proxy inverso con HTTPS delante para servir el cliente web de forma segura, crear las cuentas de usuario necesarias de forma controlada por un administrador, y validar el acceso completo tanto desde el navegador como desde la aplicación de escritorio.
🧩 Desarrollo de la práctica
Levantar la base de datos y el homeserver con Docker Se define el despliegue de PostgreSQL y Synapse en Docker Compose, con las credenciales aisladas en un archivo .env independiente, y se valida que ambos servicios arrancan en el orden correcto.
Generar la configuración del homeserver Se genera el archivo de configuración inicial de Synapse y se ajusta para que utilice la base de datos PostgreSQL desplegada, en lugar de la base de datos ligera que trae por defecto.
Configurar el proxy inverso con HTTPS propio Se despliega un proxy inverso que sirve un certificado autofirmado válido para la IP del servidor, y reparte el tráfico entre el cliente web y la API del homeserver bajo un único origen seguro, evitando así que el navegador rechace la aplicación por falta de un contexto seguro.
Crear las cuentas de usuario Se dan de alta las cuentas necesarias mediante el comando de administración del propio homeserver, sin habilitar el autorregistro abierto, de forma que solo el administrador pueda crear cuentas nuevas.
Verificación de extremo a extremo Se inicia sesión desde el navegador, aceptando el aviso de certificado autofirmado, y se confirma que el envío y la recepción de mensajes funcionan correctamente entre dos cuentas distintas, tanto desde el cliente web como desde la aplicación de escritorio.
🔍 ¿Por qué es importante esta práctica?
Disponer de un canal de mensajería propio, en lugar de depender de un proveedor externo, da control total sobre dónde vive la información y quién tiene acceso a ella. Al no exigir un proveedor de identidad de terceros para el inicio de sesión, la plataforma queda completamente autocontenida: ni las cuentas ni las conversaciones dependen de un servicio externo que pueda cambiar sus condiciones, sufrir una caída, o simplemente dejar de estar disponible.
Además, el reto de exponer el servicio con HTTPS sin un dominio público es una situación extremadamente habitual en cualquier despliegue interno real: la solución de un proxy inverso con certificado autofirmado no es una chapuza temporal, sino el mismo patrón que se usa en la mayoría de las organizaciones para sus servicios internos antes de contar con un certificado emitido por una entidad pública.
✅ Resultados esperados
Al finalizar la práctica, el homeserver Synapse desplegado en Docker gestiona cuentas de usuario locales y permite el intercambio de mensajes en tiempo real entre distintas cuentas, accesible de forma directa por la IP del servidor tanto desde el navegador como desde la aplicación de escritorio, sin depender de ningún proveedor de identidad externo.
🏢 Propuesta empresarial
Clockwork Computer necesita un canal de comunicación interno que no dependa de un proveedor externo de mensajería, y que pueda desplegarse y controlarse por completo dentro de su propia infraestructura.
El departamento de IT ha decidido desplegar un homeserver Matrix propio, aprovechando Docker para todo el stack (base de datos, homeserver, cliente web y proxy con HTTPS), de forma que la gestión de cuentas y la vigilancia del servicio queden bajo control directo de la organización.
📌 Escenario propuesto
Clockwork Computer dispone de un servidor con Docker donde levantar su plataforma de mensajería interna. El objetivo es que el servicio sea accesible desde cualquier equipo de la red interna, tanto desde el navegador como desde una aplicación de escritorio, sin depender de un dominio público ni de un proveedor de identidad externo, y con la posibilidad de ampliar en el futuro hacia un dominio propio si el servicio necesita salir fuera de la red local.
🎯 Requisitos técnicos solicitados por la empresa
La empresa solicita implementar las siguientes tareas:
Levantar el homeserver Matrix (Synapse) y su base de datos en Docker, con las credenciales gestionadas de forma segura y separadas del propio despliegue. Configurar un proxy inverso con HTTPS, aunque sea con un certificado autofirmado, para que el cliente web funcione correctamente en cualquier navegador moderno. Crear las cuentas de usuario necesarias de forma controlada por un administrador, sin autorregistro abierto. Verificar el envío y la recepción de mensajes entre distintas cuentas, tanto desde el navegador como desde la aplicación de escritorio. Dejar el despliegue preparado para ampliarse en el futuro con un dominio propio y un certificado válido, sin tener que rediseñar el montaje actual.
🔐 Justificación técnica y de seguridad
Clockwork Computer necesita evitar que la comunicación interna dependa de un proveedor externo de identidad o de mensajería, reduciendo así su exposición a cambios de condiciones, caídas de servicio, o el acceso de terceros a conversaciones internas. Mantener las cuentas de usuario bajo control directo del administrador, sin autorregistro abierto, evita que el servicio quede accesible a cualquiera que descubra su dirección.
Servir el cliente web bajo HTTPS, aunque sea con un certificado autofirmado mientras no exista un dominio público, es indispensable para que el navegador permita el funcionamiento completo de la aplicación, y sienta además la base para migrar sin fricciones a un certificado válido el día que el servicio deba ser accesible desde fuera de la red interna.
🧪 Validación esperada
Al finalizar la práctica, Clockwork Computer deberá comprobar que dos cuentas distintas, creadas por el administrador del homeserver, pueden iniciar sesión y conversar entre sí en tiempo real, tanto desde el navegador como desde la aplicación de escritorio, sin que en ningún momento haya sido necesario un proveedor de identidad externo ni un dominio público.
✅ Resultado empresarial esperado
Como resultado final, Clockwork Computer dispondrá de una plataforma de mensajería interna completamente autocontenida, con las cuentas de usuario y las conversaciones bajo su propio control, accesible de forma directa desde cualquier equipo de la red. El servicio quedará preparado para escalar en el futuro hacia un dominio propio y un certificado público, sin depender en ningún momento de un proveedor externo de identidad o de mensajería.
Comentarios
Publicar un comentario