[🛠] Operations Automation #3: Migración de la automatización heredada de vacaciones al NAS y conexión HTTPS externa

✨ Resumen de GPT-5.6 Sol

Un registro del traslado de las funciones y los datos existentes de gestión de vacaciones a un nuevo entorno NAS, y de la corrección de los defectos de interfaz que aparecieron en un dispositivo móvil real tras conectar el acceso HTTPS externo.

Llevé las funciones y los datos de la automatización heredada de vacaciones a un nuevo entorno NAS y conecté la ruta por la que las solicitudes HTTPS externas llegan hasta la aplicación dentro del NAS. No se trataba solo de levantar un container, sino de trasladar un flujo de trabajo existente a un nuevo entorno operativo.

Sin embargo, que la nueva pantalla se abriera no bastaba para dar por terminada la migración. Debían aparecer los datos de empleados y vacaciones, y tanto los destinatarios de los avisos como el texto de los mensajes tenían que coincidir con el sistema anterior. Los mensajes que superaran el límite diario de 130 debían pasar al día siguiente, y la queue de envío y el historial también tenían que continuar. Si faltaba una sola pieza, sería otro servicio con el mismo nombre.

Cuando antes volví a separar la automatización comercial de la administración de personal, decidí reproducir primero las funciones existentes de gestión de vacaciones y trasladarlas después. Al comenzar, ese orden resultó ser aún más importante. Aplacé durante un tiempo el deploy en el NAS.

Reproducción local de funciones y restauración de datos

Primero ejecuté FastAPI, Next.js y MariaDB en un entorno Compose local y aislado. Para evitar conflictos con el servicio existente, también separé port, network, volume y credential. Inicié sesión como administrador, abrí los datos de empleados y vacaciones y comparé con el flujo anterior los destinatarios de los avisos, el texto generado, los envíos programados por encima del límite de 130, la queue y el historial.

No quería tocar directamente la DB de producción. Restauré el backup SQL existente en otra instancia de MariaDB y comparé el schema y el recuento de las table principales. También comprobé que los datos siguieran allí después de reiniciar el backend. Solo entonces tuve una referencia de funcionamiento local. Si más adelante algo fallaba en el NAS, podría distinguir si el código había cambiado o si el problema estaba en la image o en la network.

Que el backup estuviera restaurado tampoco significaba que la transición operativa hubiera terminado. Ni la cuenta de administrador, ni el teléfono de trabajo, ni los SMS reales habían pasado todavía por la nueva ruta.

Doble límite en la ruta de envío real de SMS

El siguiente bloqueo fue el envío real de SMS. Sin enviar un mensaje, no podía recorrer hasta el final la ruta que llega al teléfono Android de trabajo. Pero tampoco podía dejar abierto el envío de production para hacer una prueba.

Por eso dividí el mode de envío del server en tres opciones.

NO_SEND
ALLOWLIST_SEND
PRODUCTION

El estado habitual es NO_SEND. Solo durante una prueba añadí a un destinatario autorizado a ALLOWLIST_SEND. En lugar de utilizar el número de teléfono en texto plano, identifiqué al destinatario con un hash SHA-256 y limité a uno el número de mensajes que el server podía reclamar. Dentro de la aplicación Android añadí otro budget independiente de un mensaje. Quería que, aunque se manejara mal el server o la aplicación, no pudiera salir un segundo SMS.

No di por válido este estado con solo leer el código. Abrí la pantalla real de administración mediante Computer Use y comprobé NO_SEND, la cantidad que podía reclamarse en ese momento, la queue y el historial. En la misma pantalla comparé el resultado del trabajo de Codex con el código implementado.

También preparé un package de prueba independiente para no tocar directamente la aplicación operativa. En el dispositivo Android conectado por USB utilicé adb reverse para enlazar el endpoint local. Así, un SMS real terminó en SUCCESS y pude verlo llegar al dispositivo receptor.

También apareció un resultado ambiguo. El usuario recibió el mensaje, pero no se capturó el delivery callback de Android. SUCCESS significaba que el operador había aceptado la solicitud de envío, no que el delivery callback hubiera terminado. Si trataba la recepción real y el estado del callback como un mismo éxito, después sería todavía más confuso decidir qué hacer con los casos UNKNOWN.

Después de observar un mensaje, volví inmediatamente a NO_SEND. Android readiness quedó en 0 y el claim del server devolvió 204 No Content. Terminé la prueba en un estado en el que una pulsación accidental adicional no podía enviar otro mensaje.

Migración de imágenes Docker linux/amd64 al NAS

En el NAS instalé únicamente el servicio de automatización de vacaciones, no toda la plataforma de automatización. En vez de volver a build el source en el NAS, creé las image linux/amd64 en el Mac, comprobé sus hash y las trasladé. También separé el project de Compose del stack existente. Así, sustituir un solo backend no volvería a crear MariaDB y el Frontend al mismo tiempo.

Conexión del HTTPS externo y el Reverse Proxy

La pantalla de inicio de sesión se abrió en la nueva dirección y también aparecieron los datos existentes de empleados y vacaciones. Sin embargo, con una explicación escrita no se veía de un vistazo cómo llegaban las solicitudes desde un navegador externo hasta MariaDB. En especial, al explicar si 3101 era un port abierto a Internet o uno usado solo dentro del NAS, los límites se mezclaban continuamente. Convertí la ruta de la solicitud en un diagrama.

Al verlo en un diagrama, quedó claro que desde el exterior solo hacía falta HTTPS 443. El Router reenvía 443 al NAS y el reverse proxy del NAS comprueba el hostname y envía la solicitud al Frontend en 127.0.0.1:3101. Backend 8000 y MariaDB 3306 se comunican únicamente dentro de la Docker network. Como 3101 también está vinculado solo al loopback del NAS, no se puede acceder a él directamente desde Internet.

Dejé Cloudflare fuera de la ruta principal por el mismo motivo. Ya disponía de authoritative DNS, una IP pública fija y control directo del Router. Añadir solo el A record del servicio y gestionar el certificado en el NAS permitía eliminar un componente intermedio. A cambio, debo ocuparme directamente de la renovación del certificado y del port forwarding. Salvo el port 80 usado para emitir y renovar el certificado, las solicitudes reales del servicio entran únicamente por 443.

Verificación en un dispositivo móvil real y corrección de la interfaz responsive

Que la dirección HTTPS externa se abriera no significaba que la migración hubiera terminado. Desde un dispositivo Android real conectado por USB accedí a la nueva dirección mediante la red móvil y recorrí directamente el inicio de sesión, el dashboard, la lista de empleados, el historial de SMS y la gestión de vacaciones. Las pantallas se abrían, pero no estaban listas para usarse tal como estaban.

Los problemas que no había visto al limitarme a estrechar el navegador del PC aparecieron todos a la vez en el dispositivo real. En el dashboard, la sidebar de escritorio ocupaba casi toda la pantalla y comprimía las card y el texto en columnas verticales.

En todas las comparaciones siguientes, la izquierda corresponde a antes de la corrección y la derecha a después.

En la lista de empleados, los títulos y los button se cortaban carácter por carácter, y una table ancha quedaba forzada dentro de un espacio estrecho. Mantuve el flujo horizontal del título y la zona de acciones, y permití que la table se desplazara horizontalmente cuanto fuera necesario en vez de aplastar el contenido.

Los filter del historial de SMS y de la gestión de vacaciones tenían el mismo problema. Varios campos y un intervalo de fechas estaban comprimidos en una sola línea. En pantallas pequeñas los organicé principalmente en dos columnas y moví el intervalo de fechas a otra fila para que cada elemento se pudiera leer y pulsar.

Después de las correcciones, volví a desplegar una nueva Docker image e inicié sesión otra vez en el mismo teléfono. Abrí el menú, recorrí las pantallas y observé directamente cada filter y table para confirmar que hubieran desaparecido los defectos iniciales. Lo que empezó como una comprobación de que la network externa llegaba al container del NAS acabó corrigiendo la interfaz que se iba a utilizar de verdad.

Estado de la migración por etapas y verificación de la interfaz de administración/E2E

Después de enlazar la migración al NAS, el acceso externo y un SMS interno, volví a desplegar el roadmap completo y vi que había superado las etapas 1 a 3. El punto actual era la etapa 4: desplegar la interfaz de administración mejorada como una nueva image y volver a revisar todas las page mediante ADB y el dispositivo real.

Al añadir este diagrama, también quedó claro el siguiente límite del trabajo. El acceso externo ya había pasado la prueba, pero no podía comenzar el dogfooding en la sede hasta terminar la nueva verificación de las pantallas de administración en un dispositivo real. Por eso, el siguiente paso no era añadir más funciones, sino comprobar hasta el final que la interfaz corregida mantuviera el mismo flujo de trabajo tanto en escritorio como en móvil.

Estado seguro y rollback antes de la transición operativa

Por ahora, el nuevo stack está configurado deliberadamente para no hacer nada de forma automática.

ENABLE_SCHEDULER=False
SMS_SEND_MODE=NO_SEND
SMS_ALLOWLIST_MAX_CLAIMS=0

No escribí las credential de administrador en Compose ni en las image. En el NAS las proporcioné mediante un secret file con permisos 0600, y en el Mac las guardé en Keychain.

Ya podía iniciar sesión en la nueva dirección y leer los datos, y bajo condiciones limitadas también llegó un SMS. En una red móvil externa comprobé todo el recorrido desde el inicio de sesión hasta la consulta de datos y el uso de las pantallas. Aun así, antes de eliminar el servicio antiguo de mensajes de vacaciones todavía falta definir cómo recuperar los envíos sin delivery callback y obtener la aprobación de las condiciones de envío reales.

Por eso detuve los container y volume existentes, pero los dejé intactos. Lo siguiente que necesito no es ampliar la configuración. Debo decidir cómo recuperar los envíos sin callback y abrir después el envío real, empezando por una cantidad limitada y bajo condiciones aprobadas.

Al margen de la migración técnica, escribí en Cuando sabes usar la IA de forma activa, lo que puedes hacer parece no tener límites sobre el cambio que sentí al permitir que la IA observara conmigo el teléfono real y las pantallas de administración del Router y el NAS.