Traefik 3 en pymes: rutas, TLS y logs
Traefik puede ordenar dominios, certificados y registros de acceso si se instala con reglas, dueños, bitácora y pruebas de corte desde el primer día.
Dos dominios con TLS automático pueden salir más baratos que una tarde perdida buscando qué servidor recibe cada petición. En una pyme con ERP, intranet y portal de clientes, Traefik 3 opera de proxy inverso: recibe tráfico, aplica reglas, pide certificados y registra accesos. Esta guía explica qué dato vive en cada componente, quién cambia rutas y cómo probar un corte sin romper producción.
Dónde aparece el proxy sin dueño
La cifra que corrige la conversación aparece en la Stack Overflow Developer Survey 2025: más de 49.000 respuestas, 177 países y 314 tecnologías relevadas. El despliegue web dejó de ser una tarea aislada. Cada aplicación trae dominio, certificado, logs, redirecciones y permisos para tocar configuración. La documentación de Traefik HTTP routers define la pieza central: un router analiza reglas de la petición y, cuando encuentra coincidencia, la pasa por middlewares hacia un servicio. El antagonista aparece cuando esas reglas quedan repartidas entre un compose, un panel de DNS y un archivo que nadie revisa. En la sala de sistemas, una etiqueta con la frase “api viejo” pegada al patch panel alcanza para entender el costo social del desorden. Todos saben que existe. Nadie quiere apagarlo primero. La diferencia aparece cuando una ruta vieja tiene responsable, fecha de revisión y una prueba de baja antes del cambio real.
Cómo funciona por dentro
El flujo mínimo tiene seis pasos. Primero, DNS apunta cada dominio al servidor público. Segundo, Traefik escucha en entrypoints, por ejemplo web y websecure. Tercero, un provider lee etiquetas de Docker, archivos o Kubernetes y crea rutas dinámicas. Cuarto, el router compara Host, Path u otras reglas y elige un servicio. Quinto, un middleware aplica redirección HTTPS, autenticación externa, cabeceras o límite de tasa. Sexto, los logs guardan método, ruta, estado, duración y servicio para revisar fallas. Traefik recibe peticiones HTTP o TCP y entrega tráfico al servicio correcto. Docker entrega etiquetas y estados de contenedor. El archivo dinámico guarda rutas que no conviene atar a un contenedor. PostgreSQL queda fuera del camino de tráfico y puede guardar inventario de dominios, dueños, vencimientos y cambios aprobados. El backup copia configuración estática, archivo dinámico, acme.json, compose y bitácora de cambios. La página de ACME en Traefik muestra que el resolver guarda certificados en un archivo y renueva certificados de 90 días treinta días antes del vencimiento por defecto. Ese archivo necesita permiso restringido y respaldo probado. La página de logs y access logs permite salida común o JSON; para auditoría conviene JSON, retención y rotación explícitas.
Qué se instala o configura primero
El primer entregable verificable es un dominio de prueba con TLS válido, redirección HTTP a HTTPS, ruta a un contenedor, acceso registrado y rollback documentado. La pila mínima usa Traefik 3, Docker Compose, un archivo dinámico versionado, acme.json, firewall, backup y un tablero simple de dominios. Un servidor de USD 15 a USD 50 mensuales queda entre ARS 21.810 y ARS 72.700 al dólar vendedor de $1.454, sin incluir soporte ni alta disponibilidad. Antes de publicar servicios reales, conviene crear una tabla de dueños. Cada dominio tiene responsable funcional, responsable técnico, servicio destino, puerto, política de TLS, fecha de revisión y plan de salida. Sistemas administra Traefik y firewall. Desarrollo propone rutas. Administración solo consulta el tablero. Un proveedor externo no toca producción sin ticket aprobado. UMSA puede ayudar cuando la pyme ya tiene dominios dispersos y certificados emitidos por personas distintas. El primer trabajo es listar servicios, retirar rutas muertas y dejar un corte ensayado. Si el router falla, el operador debe saber qué archivo volver, qué contenedor reiniciar y qué certificado no borrar.
Dónde se rompe y cómo probarlo
El primer riesgo es publicar una ruta demasiado amplia. La señal aparece cuando /api responde desde un servicio que debía quedar interno. La prueba crea una URL interna, la llama desde fuera y confirma rechazo. El segundo riesgo es perder acme.json. La señal aparece cuando un servidor nuevo levanta Traefik, pero no tiene certificados previos. La prueba restaura ese archivo en un host temporal y verifica que Traefik lo lea con permisos correctos. El tercer riesgo es guardar logs sin retención. La señal aparece cuando un incidente de la semana anterior ya no tiene método, IP, ruta o estado. La prueba fuerza un error 404, un 502 y una petición correcta, luego busca los tres eventos en el archivo JSON. El cuarto riesgo es mezclar cambios de rutas con cambios de aplicación. La señal aparece cuando una caída no permite saber si falló el contenedor o el proxy. La prueba reinicia solo el servicio destino y revisa que Traefik marque 502 sin perder el resto de rutas. Un proxy queda ordenado cuando cada dominio tiene dueño, cada certificado vuelve desde backup y cada error deja una línea que alguien puede leer.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.