Caso de estudio · Proyecto de aprendizaje autoalojado
De un repositorio Git a una aplicación desplegada.
Una plataforma autoalojada que reúne construcción, ejecución, routing y seguimiento de despliegues. Go y Temporal coordinan el trabajo; Next.js permite iniciarlo y seguir sus logs.
Demo pública no disponible
Desplegar requiere conectar varias operaciones: obtener código, construir una imagen, arrancar el contenedor y darle una ruta de acceso. Hangar intenta reunirlas en un proceso que pueda seguirse desde una interfaz y cuyo estado no dependa de mantener abierta una petición HTTP.
El ADR plantea conservar el control de la infraestructura y poder retomar workflows tras reinicios. Es el objetivo de diseño; aquí se explica la implementación disponible, sin atribuirle uso comercial ni disponibilidad comprobada.
El README lo plantea como una alternativa de aprendizaje para desarrolladores que quieren controlar su infraestructura de despliegue sin incorporar Kubernetes. No se presenta como un servicio con usuarios o clientes acreditados.
El dashboard crea una aplicación con nombre y URL Git. Al solicitar el despliegue, la API guarda un registro pending e inicia DeployWorkflow en Temporal; responde 202 sin esperar a que termine el build. El worker clona, construye y arranca. Traefik sirve el subdominio configurado, mientras los logs llegan al navegador por otro canal.
clone
Worker Go · CloneRepository: obtiene Git y busca el Dockerfile.
build
Worker Go · BuildDockerImage: construye con Docker Engine.
run
Worker Go · RunContainer: crea el contenedor con red y límites.
route
Traefik: aplica las etiquetas y red configuradas en RunContainer.
Secuencia conceptual del código. El routing forma parte de RunContainer; no es una actividad independiente de Temporal.
El dashboard solicita el despliegue a la API. La API registra la operación en PostgreSQL e inicia el workflow en Temporal. Un worker ejecuta las actividades que interactúan con Git y Docker.
Usuario
Inicia el despliegue
Next.js
Dashboard
Go / Fiber
API REST
Temporal
Workflow y worker
Docker
Build y contenedor
Petición HTTP
Subdominio de la app
Traefik
Regla Host en etiquetas Docker
Contenedor
Aplicación desplegada
Dos recorridos distintos: Temporal coordina el despliegue; Traefik dirige el tráfico hacia la aplicación. Los logs vuelven al dashboard por un canal separado.
PostgreSQL relaciona aplicaciones, despliegues y logs. Redis Pub/Sub comunica los nuevos mensajes entre las actividades y el handler WebSocket.
DeployWorkflow invoca las actividades en orden y espera sus resultados. Las operaciones de disco, red y Docker quedan fuera del workflow: esa separación permite mantener el determinismo que requiere Temporal.
pending
Registro creado
running
Actividades en ejecución
success / failed
Resultado del workflow
Valores del código, no mediciones de rendimiento.
Si CloneRepository, BuildDockerImage o RunContainer devuelve un error tras sus reintentos, el workflow intenta marcar failed y retorna el error. No hay rollback automático del conjunto: un contenedor o una red creados antes del fallo pueden requerir limpieza. Si falla la primera actualización a running, retorna el error sin esa transición a failed.
Temporal configura timeout y reintentos antes de invocar las actividades. Son valores de configuración, no tiempos de despliegue medidos.
Archivo fuente: api/internal/workflows/deploy_workflow.goGo · líneas 36–44 ao := workflow.ActivityOptions{
StartToCloseTimeout: 10 * time.Minute,
RetryPolicy: &temporal.RetryPolicy{
MaximumAttempts: 3,
InitialInterval: 5 * time.Second,
BackoffCoefficient: 2.0,
},
}
ctx = workflow.WithActivityOptions(ctx, ao)RunContainer registra una advertencia si no logra conectar con la red de Traefik y aun así retorna sin error. El estado success no equivale a una comprobación HTTP de la aplicación. Los errores al guardar el estado final también se ignoran en esta versión.
La unidad de separación del código es la aplicación: identificador, subdominio, contenedor y red bridge propios. Las rutas revisadas no incorporan autenticación de usuarios y el esquema no define propietarios ni organizaciones. La autenticación aparece como pendiente en el README; no se presenta multi-tenancy de usuarios como implementado.
Aplicación A
Red bridge de A
Aplicación B
Red bridge de B
Red compartida de Traefik
Ambos contenedores también se conectan aquí
Esquema de dos aplicaciones para explicar la topología, no clientes ni despliegues reales.
Configuración de Docker en RunContainer; no demuestra aislamiento bajo carga.
Estos argumentos de ContainerCreate fijan memoria y CPU, y conectan el contenedor a la red de la aplicación. La red compartida de Traefik se añade después.
Archivo fuente: api/internal/activities/deploy_activities.goGo · líneas 185–197 &containertypes.HostConfig{
Resources: containertypes.Resources{
Memory: 128 * 1024 * 1024, // 128 MB
CPUPeriod: 100000,
CPUQuota: 25000, // 25% de un core
},
RestartPolicy: containertypes.RestartPolicy{Name: "unless-stopped"},
},
&networktypes.NetworkingConfig{
EndpointsConfig: map[string]*networktypes.EndpointSettings{
appNetwork: {},
},
},Crear una red por aplicación no demuestra que los tenants no puedan comunicarse entre sí cuando también comparten otra red. El código revisado no basta para afirmar aislamiento lateral completo.
Las actividades registran mensajes del pipeline y la salida de docker build. El helper intenta guardarlos en PostgreSQL y publicarlos en Redis. Son logs del despliegue; el código revisado no implementa un stream general de stdout de la aplicación en ejecución.
Actividades
Mensajes y salida del build
Redis Pub/Sub
Canal por despliegue
WebSocket
Handler en Go / Fiber
Dashboard
Vista de logs en Next.js
PostgreSQL
Historial del despliegue
WebSocket
Envía primero los registros guardados
Dashboard
Recibe el historial antes de los mensajes nuevos
El backend comprueba periódicamente el estado del despliegue y envía done cuando termina. El navegador recibe los mensajes mediante WebSocket.
El handler lee el historial antes de suscribirse a Redis: existe una ventana entre ambos pasos. Además, el helper ignora errores de escritura y publicación. Este flujo no permite prometer entrega sin pérdidas ni recuperación automática de la conexión.
El handler se suscribe al canal del deployment y prepara la consulta periódica de estado. El historial ya se ha leído antes: esta secuencia no garantiza una transición sin pérdidas.
Archivo fuente: api/internal/handler/ws.goGo · líneas 90–105 // -- 2. Suscribe al canal Redis para logs en vivo --------------------
channel := rdb.LogChannel(deploymentID)
pubsub := h.redis.Subscribe(ctx, channel)
defer pubsub.Close()
h.log.Info("suscrito a redis",
zap.String("channel", channel),
zap.String("deployment_id", deploymentID),
)
// -- 3. Reenvía mensajes en tiempo real ----------------------------─
msgChan := pubsub.Channel()
// Ticker para verificar si el deployment terminó
// (por si el mensaje de "done" se perdió)
statusTicker := time.NewTicker(3 * time.Second)Decisiones del código que evitan esperas y trabajo innecesario. Son características de la implementación, no mediciones: no hay benchmarks publicados.
Cola de Temporal en lugar de esperar el build
TriggerDeploy inicia DeployWorkflow en la cola hangar-deploy y responde 202 de inmediato; el worker hace clone, build y run en segundo plano.
Logs en streaming, línea por línea
La salida de docker build se decodifica como flujo JSON con json.Decoder; cada línea se guarda en deploy_logs y se publica en el canal Redis hangar:logs:{id} sin esperar a que termine el build.
Historial primero, luego en vivo
El WebSocket envía los logs guardados y después se suscribe al canal de Redis; si el despliegue ya terminó, cierra tras el historial.
Contexto de build sin archivo temporal
El tar del contexto se genera en una tubería (io.Pipe) mientras Docker lo lee, y omite la carpeta .git.
Clonado superficial
CloneRepository usa git clone --depth=1: descarga solo el último commit.
Consultas indexadas y pool de conexiones
Índices en deployments(app_id) y deploy_logs(deployment_id), las columnas por las que se filtra; pgxpool reutiliza las conexiones a PostgreSQL.
El repositorio incluye tests de integración que llaman a la API y consultan PostgreSQL durante un despliegue. Requieren API, worker, Docker, PostgreSQL, Redis, Temporal y un repositorio local de prueba con Dockerfile.
NO VERIFICADO · Ejecución de la suite de Hangar
La suite requiere servicios activos y un repositorio de prueba local con Dockerfile. Ese fixture no está presente en este entorno; no se levantó la infraestructura ni se generó una salida de tests ficticia.
Comando documentado, no ejecutado en esta revisión: go test ./tests/... -v -timeout 120s -tags integration
Lo verificable aquí es la implementación y la existencia de estas comprobaciones. No se publican porcentajes de cobertura, tiempos de despliegue ni resultados de producción sin evidencia reproducible.
Los enlaces siguientes fijan la versión del código que sustenta este caso. Las limitaciones descritas corresponden a esa revisión.