Cómo alojar IT Tools por tu cuenta en 2026: TLS, despliegues stateless y actualizaciones

Alojar IT Tools por tu cuenta resulta interesante en el primer redeploy, no en el primer docker run. Si el proxy apunta al puerto incorrecto del contenedor o almacena en caché una versión antigua de la aplicación, Docker puede seguir mostrando un proceso perfectamente saludable. El despliegue siguiente se organiza en torno a un comportamiento observable: cargar la interfaz, generar un hash, decodificar un JWT y usar un conversor con la red del navegador desconectada después de almacenar en caché los assets.

El propósito de IT Tools es claro: ofrecer una colección de hashes, conversores, generadores y utilidades para desarrolladores. Esta descripción indica qué debe permanecer público, qué debería mantenerse privado y qué debe poder reconstruir una copia de seguridad.

Separa IT Tools de sus dependencias

Empieza por el espacio de nombres de red de IT Tools: su listener web está en el puerto 80, no en un puerto del host copiado de un tutorial para portátiles. La build estándar de IT Tools no necesita una base de datos ni un servicio de runtime persistente independiente. Mantén el contenedor web reemplazable y sitúa cualquier componente futuro de autenticación, colaboración o almacenamiento detrás de un límite documentado por separado.

Una vez cumplido el requisito, ejecuta el escenario completo —cargar la interfaz, generar un hash, decodificar un JWT y usar un conversor con la red del navegador desconectada después de almacenar en caché los assets—. Registra logs y mediciones de la memoria del navegador del cliente, la entrega de assets estáticos y la ausencia de trabajo de base de datos o cola en el servidor. Esta evidencia se convierte en la primera arquitectura conocida como válida y permite probar posteriores cambios entre la infraestructura de Dockup y un servidor conectado.

Crea un contenedor de IT Tools reemplazable

Un comando mínimo resulta útil cuando muestra qué gestionará la plataforma más adelante.

docker run -d \
  --name it-tools \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  corentinth/it-tools:latest

Aquí el puerto 80 sigue siendo privado para el host y todas las rutas necesarias están explícitas. Confirma el requisito local antes de exponerlo: no hay base de datos; solo un contenedor web pequeño. Verifica el arranque tanto con los logs como con la comprobación específica de la aplicación: carga la interfaz, genera un hash, decodifica un JWT y usa un conversor con la red del navegador desconectada después de almacenar en caché los assets. Una vez verificado, fija la versión de la imagen para que un reemplazo rutinario no cambie el comportamiento silenciosamente.

El TLS es sencillo; las URL generadas no

El límite público de IT Tools debería ser un único hostname canónico, TLS automático y un único destino interno en el puerto 80. Sirve la aplicación web estática mediante HTTPS para que los clientes vuelvan a una dirección que el servicio reconoce.

Si la transacción de aceptación falla, clasifica el primer error. Los problemas de DNS, certificados y 502 corresponden a la checklist de validación de TLS. La condición «el proxy apunta al puerto incorrecto del contenedor o almacena en caché una versión antigua de la aplicación» corresponde al lado de la aplicación, después de que una petición haya llegado correctamente a IT Tools.

Los volúmenes son solo la primera capa de recuperación

La recuperación de un IT Tools stateless es un ejercicio de reproducibilidad. No conserves datos en el servidor; mantén la configuración del despliegue; la capa escribible del contenedor no debería contener nada necesario después de un reemplazo.

Usa la imagen fijada y la configuración revisada para reconstruir IT Tools en una infraestructura vacía. El ejercicio se supera cuando un contenedor nuevo reproduce el mismo conjunto de herramientas, porque no hay estado de usuario en el servidor que recuperar. Sigue el flujo de despliegue de Git a producción para el artefacto reemplazable, mientras que cualquier servicio externo opcional mantiene un procedimiento de backup independiente.

Documenta el digest exacto y el input de aceptación. Esto permite al operador distinguir una regresión de la aplicación de la ausencia de estado y evita asociar un volumen meramente ceremonial que IT Tools nunca lee.

Cierra el acceso temporal de configuración

La seguridad de un IT Tools stateless empieza por los controles de supply chain y de ingress, no por una configuración de cuenta ficticia. No des por hecho que las herramientas del navegador hacen que pegar secretos sea seguro en un host que no es de confianza. El límite previsto consiste en servir una imagen upstream de confianza y recordar a los usuarios que alojar un servicio por tu cuenta no convierte en fiable un navegador comprometido.

Sirve IT Tools desde una imagen fijada y de confianza, añade autenticación de la plataforma si la audiencia es privada y expón únicamente el puerto 80 mediante HTTPS. Establece límites de recursos y de peticiones en torno a la memoria del navegador del cliente, la entrega de assets estáticos y la ausencia de trabajo de base de datos o cola en el servidor. Como esta configuración base no tiene ningún secreto integrado, mantén la política de acceso en la configuración de la ruta y pruébala desde un cliente no autorizado.

Ensaya el cambio de IT Tools más arriesgado

Supervisa el comportamiento, no solo el proceso: carga la interfaz, genera un hash, decodifica un JWT y usa un conversor con la red del navegador desconectada después de almacenar en caché los assets. Las señales de presión asociadas son la memoria del navegador del cliente, la entrega de assets estáticos y la ausencia de trabajo de base de datos o cola en el servidor. Ejecuta esta comprobación después del arranque y con una periodicidad que no pueda sobrecargar el servicio.

Una actualización solo puede promocionarse después de comprobar que una actualización de la imagen puede cambiar los algoritmos o las dependencias del lado del cliente; por eso, fija y verifica la build que procesa datos sensibles. Usa un candidato en paralelo, digests fijados e inputs conocidos; esta imagen base no tiene ninguna migración de schema que ensayar. Si el proxy apunta al puerto incorrecto del contenedor o almacena en caché una versión antigua de la aplicación, compara las dos versiones antes de modificar el ingress o añadir almacenamiento.

Registra un despliegue de IT Tools conocido como válido

No conviertas el tráfico del primer usuario en la prueba de aceptación de IT Tools. Prepara un estado de ejemplo inocuo y ejecuta la acción completa: «cargar la interfaz, generar un hash, decodificar un JWT y usar un conversor con la red del navegador desconectada después de almacenar en caché los assets». Anota la URL pública exacta, el resultado, la referencia de la imagen y el intervalo de logs asociados a la ejecución.

Reemplaza el contenedor y repite la prueba sin reconstruir los datos. Después, recupera el servicio en un host vacío; la condición de recuperación es que un contenedor nuevo reproduzca el mismo conjunto de herramientas, porque no hay estado de usuario en el servidor que recuperar. Observa la memoria del navegador del cliente, la entrega de assets estáticos y la ausencia de trabajo de base de datos o cola en el servidor en cada ejecución, y define una alerta en torno a la degradación de la transacción, no a las métricas de un contenedor inactivo.

Una última comprobación debería fallar deliberadamente: envía un input inocuo cerca del límite de recursos o de formato asociado a este límite: el proxy apunta al puerto incorrecto del contenedor o almacena en caché una versión antigua de la aplicación. Verifica que el mensaje resultante de IT Tools identifica el límite relevante en lugar de activar un borrado de datos o un reinicio infinito. Restablece la condición válida y confirma que la misma transacción de ejemplo vuelve a funcionar. Mantén este breve ejercicio en la checklist de release.

Un despliegue en Dockup también necesita una prueba de aceptación de IT Tools

Dockup puede desplegar la imagen fijada de IT Tools en la infraestructura de Dockup o en un servidor conectado por el cliente, dirigir el hostname público al puerto 80 y emitir TLS automáticamente. El contenedor estándar no tiene una base de datos de la aplicación, por lo que Dockup no debería asociar un volumen de datos sin sentido solo para imitar una plantilla stateful.

Después del despliegue, sirve la aplicación web estática mediante HTTPS. Dockup debería conservar la configuración del runtime de IT Tools mientras el operador confirma este requisito local: no hay base de datos; solo un contenedor web pequeño. Ejecuta la comprobación de salida conocida: carga la interfaz, genera un hash, decodifica un JWT y usa un conversor con la red del navegador desconectada después de almacenar en caché los assets. Si más adelante se añaden fuentes personalizadas, autenticación, colaboración o configuración, declara explícitamente esos componentes y su estado en lugar de integrarlos en la imagen web stateless. Así, el despliegue con un clic refleja con honestidad qué gestiona Dockup y qué almacena realmente IT Tools.

Preguntas frecuentes

¿Qué necesita IT Tools para un despliegue en producción?

Dirige el contenedor de IT Tools del puerto 80 a través de un único origen HTTPS. La build estándar de IT Tools no necesita una base de datos ni un servicio de runtime persistente independiente. No consideres que IT Tools está listo hasta que puedas cargar la interfaz, generar un hash, decodificar un JWT y usar un conversor con la red del navegador desconectada después de almacenar en caché los assets.

¿Qué datos de IT Tools deben incluirse en una copia de seguridad?

La imagen estándar de IT Tools no tiene ningún mount obligatorio para los datos de la aplicación. Conserva la configuración del despliegue y realiza el backup de cualquier estado conectado por separado; la recuperación se supera cuando un contenedor nuevo reproduce el mismo conjunto de herramientas, porque no hay estado de usuario en el servidor que recuperar.

¿IT Tools necesita HTTPS detrás de un reverse proxy?

Usa HTTPS para el origen público de IT Tools y mantén el puerto 80 en la ruta interna. Aplica correctamente la configuración de IT Tools: dirige la aplicación web estática mediante HTTPS. En IT Tools, HTTPS protege las credenciales o el contenido del usuario durante el tránsito y mantiene coherente el comportamiento del cliente sensible al origen.

¿Cómo se debe probar una actualización de IT Tools?

Despliega la imagen candidata de IT Tools junto a la actual y repite la transacción de aceptación con un input conocido. Presta especial atención porque una actualización de la imagen puede cambiar los algoritmos o las dependencias del lado del cliente; por eso, fija y verifica la build que procesa datos sensibles. El contenedor estándar no tiene migraciones de datos, así que conserva el digest anterior hasta superar las comprobaciones de salida y compatibilidad.