Panel de Gestión de Bases de Datos (SvelteKit Migration)

Este proyecto es una migración moderna del panel de control legacy TransmitirAS, reconstruido utilizando SvelteKit 2.0 y Svelte 5 (Runes).

Características

• Tech Stack: SvelteKit, TypeScript, Node.js (MSSQL), Bootstrap 5.
• Server-Side Rendering (SSR): Todos los datos se cargan en el servidor para una carga inicial rápida y SEO/Performance óptimo.
• Base de Datos: Conexión a múltiples instancias SQL Server (Local, Remota, Azure).
• Diseño: Interfaz "Glassmorphism" portada fielmente del original.

Requisitos Previos

• Node.js: v18 o superior.
• SQL Server: Acceso a las instancias de base de datos definidas en .env.

docker build \
  -t dev.aduanasoft.com:8443/databases_a24c/frontend:latest \
  -f ./Dockerfile \
  ./

Subirlas a harbor

docker login dev.aduanasoft.com:8443
docker push dev.aduanasoft.com:8443/databases_a24c/frontend:latest

Configuración

1. Instalar dependencias:

   npm install
   

2. Variables de Entorno: El archivo .env ya ha sido configurado con las credenciales migradas. Asegúrese de que la máquina donde se ejecuta esto tenga acceso de red a las IPs:

   • 192.168.1.200 (Primaria)
   • 104.192.7.202 (Secundaria)
   • aduanasoft.database.windows.net (Azure)

3. Ejecutar en Desarrollo:

   npm run dev
   

   Abrir http://localhost:5173 en el navegador.

4. Construir para Producción:

   npm run build
   npm run preview
   

Estructura del Proyecto

• src/lib/server/db.ts: Lógica de conexión a base de datos (Pools).
• src/routes/+page.server.ts: Controlador principal. Realiza todas las consultas SQL y lectura de archivos antes de renderizar.
• src/routes/+page.svelte: Vista principal. Gestiona la navegación por pestañas y tablas.
• src/lib/components/: Componentes reutilizables (Navbar, Sidebar).
• src/app.css: Estilos globales y tema Glass.

Integración CloudRestoreAS

• Endpoints servicio-a-servicio bajo /api/restore/ (token CLOUDRESTORE_API_TOKEN en .env).
• Servidores de Restauración (/servidores-restauracion): admin de Alfa/Omega/Gamma y carpeta de entrada reportada por CloudRestoreAS (solo lectura).
• Contrato y prueba local: ver INTEGRACION_PANEL.md en el repo CloudRecoveryAS (mismo token en CLOUDRESTORE_API_TOKEN y en la config PANEL de CloudRestoreAS).

Versiones CRAS (/versiones-cras) — instalación y actualización remota

Distribución de los binarios del agente. Los artefactos se publican en el registro de paquetes genéricos de Gitea desde el build local del repo CloudRecoveryAS (build-all.sh --publish); el panel los descubre leyendo esa API y los despliega por SSH.

build local (WSL)  →  Gitea: ADUANASOFT/generic/cloudrestoreas/<version>
                          ↓  (el panel lee la API y guarda metadatos + sha256)
                      a24c.cras_releases  →  caché en CRAS_RELEASES_DIR
                          ↓  (SFTP + exec)
                      servidor de restauración

Flujo de operación:

1. Sincronizar con Gitea — registra las versiones publicadas en a24c.cras_releases. Nunca activa nada por su cuenta: publicar no debe equivaler a desplegar.
2. Activar — marca la versión que se instalará, una por plataforma+arquitectura (índice único parcial en la BD, para que Windows y Linux tengan cada una la suya).
3. Precargar (opcional) — descarga y verifica el artefacto antes de instalar, para separar el tiempo de descarga del de instalación.
4. Instalar / Actualizar por servidor — sube el paquete por SFTP, verifica el sha256 en el destino, corre el instalador que viene dentro del paquete y siembra config/.env con la URL, el token y la instancia: el servidor queda operativo sin configuración manual.

Detalles que importan:

• Los binarios no se guardan en Postgres (pesan ~270 MB); la BD solo tiene metadatos.
• El servidor destino no descarga nada de internet: el binario es autocontenido.
• El token del panel viaja al destino en un archivo 0600 por SFTP, nunca como argumento de un comando (sería visible en ps y en el historial del servidor).
• Se exige root o sudo -n en Linux (y cuenta administradora en Windows), validado antes de transferir el artefacto. No se le pasa la contraseña a sudo.
• El progreso se persiste paso a paso en a24c.cras_install_runs.steps; la UI lo consulta por polling en /versiones-cras/install-runs.
• No hay subida de archivos por el navegador a propósito: la fuente de verdad es Gitea.

Variables nuevas en .env: GITEA_BASE_URL, GITEA_OWNER, GITEA_TOKEN (scope read:package), CRAS_PACKAGE_NAME, CRAS_RELEASES_DIR, CRAS_CACHE_KEEP_VERSIONS, PANEL_PUBLIC_URL. Ver .env.example.

Esquema: migración e2f3a4b5c6d7 en el repo a24c (autoritativa), replicada en database/schema.sql y en el fallback ensureCrasSchema() de cras-releases.ts.

Notas de Migración

• DataTables: Se inicializan en el cliente dentro de onMount para mantener la compatibilidad con las tablas interactivas originales.
• Sistema de Archivos: La lectura de backups busca en BACKUP_PATH en el servidor donde corre Node.js (independiente de la carpeta que vigila CloudRestoreAS).