pablinux
b0489739cf
✨ Nuevas funcionalidades: - API REST unificada en puerto 8080 (eliminado CORS) - WebSocket para logs en tiempo real desde journalctl - Integración completa con systemd para gestión de servicios - Escaneo automático de procesos Node.js y Python - Rate limiting (1 operación/segundo por app) - Interface web moderna con Tailwind CSS (tema oscuro) - Documentación API estilo Swagger completamente en español 🎨 Interface Web (todas las páginas en español): - Dashboard con estadísticas en tiempo real - Visor de escaneo de procesos con filtros - Formulario de registro de aplicaciones con variables de entorno - Visor de logs en tiempo real con WebSocket y sidebar - Página de selección de apps detectadas - Documentación completa de API REST 🏗️ Arquitectura: - Módulo models: ServiceConfig, ManagedApp, AppStatus - Módulo systemd: wrapper de systemctl, generador de .service, parser - Módulo orchestrator: AppManager, LifecycleManager con validaciones - Módulo api: handlers REST, WebSocket manager, DTOs - Servidor unificado en puerto 8080 (Web + API + WS) 🔧 Mejoras técnicas: - Eliminación de CORS mediante servidor unificado - Separación clara frontend/backend con carga dinámica - Thread-safe con Arc<DashMap> para estado compartido - Reconciliación de estados: sysinfo vs systemd - Validaciones de paths, usuarios y configuraciones - Manejo robusto de errores con thiserror 📝 Documentación: - README.md actualizado con arquitectura completa - EJEMPLOS.md con casos de uso detallados - ESTADO_PROYECTO.md con progreso de Fase 4 - API docs interactiva en /api-docs - Script de despliegue mejorado con health checks 🚀 Producción: - Deployment script con validaciones - Health checks y rollback capability - Configuración de sudoers para systemctl - Hardening de seguridad en servicios systemd
258 lines
10 KiB
Plaintext
258 lines
10 KiB
Plaintext
📋 PROMPT DE CONTINUACIÓN - Fase 4: Sistema de Control Local + Integración Cloud
|
|
|
|
===============================================================================
|
|
CONTEXTO ARQUITECTÓNICO CONFIRMADO
|
|
===============================================================================
|
|
|
|
┌─────────────────────────────────────────────────────┐
|
|
│ API Central Cloud (ya existe) │
|
|
│ https://api.siax-system.net │
|
|
│ - Dashboard público para analytics │
|
|
│ - Recibe reportes de estado de agents │
|
|
│ - NO controla directamente los procesos │
|
|
└─────────────────────────────────────────────────────┘
|
|
▲
|
|
│ POST /apps_servcs/apps
|
|
│ (reportes de estado)
|
|
│
|
|
┌────────────────────────┴─────────────────────────────┐
|
|
│ SIAX Agent (este proyecto) │
|
|
│ http://192.168.x.x:8080 (solo VPN) │
|
|
│ │
|
|
│ ✅ YA TIENE: │
|
|
│ - monitor.rs: Detecta procesos Node.js │
|
|
│ - interface.rs: Panel web local │
|
|
│ - logger.rs: Sistema de logs │
|
|
│ - config.rs: Gestión de apps monitoreadas │
|
|
│ │
|
|
│ 🎯 NECESITA (Fase 4): │
|
|
│ 1. Panel Web: Start/Stop/Restart procesos │
|
|
│ 2. Systemd: Gestionar servicios .service │
|
|
│ 3. Logs en Tiempo Real: journalctl streaming │
|
|
│ 4. Webhook (opcional): Recibir comandos externos │
|
|
│ 5. Evolución monitor.rs: Reconciliar systemd │
|
|
└───────────────────────────────────────────────────────┘
|
|
|
|
===============================================================================
|
|
REQUISITOS TÉCNICOS - FASE 4
|
|
===============================================================================
|
|
|
|
-------------------------------------------------------------------------------
|
|
A. SYSTEMD INTEGRATION (src/systemd/)
|
|
-------------------------------------------------------------------------------
|
|
|
|
Objetivo: Gestionar servicios systemd para Node.js y Python (FastAPI).
|
|
|
|
Funcionalidades:
|
|
|
|
1. service_generator.rs: Generar archivos .service dinámicamente
|
|
|
|
pub fn create_service(config: ServiceConfig) -> Result<(), SystemdError>
|
|
// Genera /etc/systemd/system/{app_name}.service
|
|
// Soporta Node.js y Python/FastAPI
|
|
|
|
2. systemctl.rs: Wrapper de comandos systemctl
|
|
|
|
pub fn start(service_name: &str) -> Result<(), SystemdError>
|
|
pub fn stop(service_name: &str) -> Result<(), SystemdError>
|
|
pub fn restart(service_name: &str) -> Result<(), SystemdError>
|
|
pub fn status(service_name: &str) -> ServiceStatus
|
|
pub fn enable(service_name: &str) -> Result<(), SystemdError>
|
|
|
|
3. parser.rs: Parsear salida de systemctl
|
|
|
|
pub fn parse_status_output(output: &str) -> ServiceStatus
|
|
// Detecta: active, inactive, failed, restarting
|
|
|
|
4. Manejo de permisos sudo:
|
|
- Detectar si comandos fallan por permisos
|
|
- Loggear claramente en UI si falta configuración sudoers
|
|
- Validaciones previas: verificar que script_path existe, user existe, working_dir válido
|
|
|
|
-------------------------------------------------------------------------------
|
|
B. ORCHESTRATOR (src/orchestrator/)
|
|
-------------------------------------------------------------------------------
|
|
|
|
Objetivo: Lógica de ciclo de vida de aplicaciones.
|
|
|
|
Funcionalidades:
|
|
|
|
1. app_manager.rs: CRUD de aplicaciones
|
|
|
|
pub fn register_app(config: ServiceConfig) -> Result<(), OrchestratorError>
|
|
pub fn unregister_app(app_name: &str) -> Result<(), OrchestratorError>
|
|
pub fn list_apps() -> Vec<ManagedApp>
|
|
|
|
2. lifecycle.rs: Control de estados
|
|
|
|
pub fn start_app(app_name: &str) -> Result<(), OrchestratorError>
|
|
pub fn stop_app(app_name: &str) -> Result<(), OrchestratorError>
|
|
pub fn restart_app(app_name: &str) -> Result<(), OrchestratorError>
|
|
|
|
3. Rate limiting: Máximo 1 operación por segundo por app (prevenir spam)
|
|
|
|
4. Recovery automático: Si estado inconsistente → intentar reconciliar
|
|
|
|
-------------------------------------------------------------------------------
|
|
C. API LOCAL (src/api/)
|
|
-------------------------------------------------------------------------------
|
|
|
|
Objetivo: Endpoints HTTP para el panel web local.
|
|
|
|
Funcionalidades:
|
|
|
|
1. handlers.rs: Endpoints REST
|
|
|
|
POST /api/apps/:name/start
|
|
POST /api/apps/:name/stop
|
|
POST /api/apps/:name/restart
|
|
GET /api/apps/:name/status
|
|
GET /api/apps
|
|
POST /api/apps/register // Crear nuevo servicio systemd
|
|
DELETE /api/apps/:name // Eliminar servicio
|
|
|
|
2. websocket.rs: LogStreamer en tiempo real
|
|
|
|
pub struct LogStreamer {
|
|
app_name: String,
|
|
process: Child, // journalctl -u {app_name} -f --output=json
|
|
}
|
|
|
|
// WS /logs/:app_name
|
|
// - Parsear JSON de journalctl
|
|
// - Enviar líneas vía WebSocket
|
|
// - Manejo de backpressure
|
|
// - Cleanup al desconectar
|
|
// - Límite de conexiones simultáneas por app
|
|
|
|
3. Webhook (opcional, análisis futuro):
|
|
|
|
POST /webhook/command
|
|
{
|
|
"action": "restart",
|
|
"app_name": "fidelizacion",
|
|
"secret": "..."
|
|
}
|
|
|
|
4. dto.rs: Schemas de validación (request/response)
|
|
|
|
-------------------------------------------------------------------------------
|
|
D. EVOLUCIÓN DE monitor.rs
|
|
-------------------------------------------------------------------------------
|
|
|
|
Objetivo: Reconciliar detección automática (sysinfo) vs systemd.
|
|
|
|
Cambios:
|
|
|
|
1. Doble detección:
|
|
|
|
for app in apps_to_monitor {
|
|
let process_detected = detect_in_sysinfo(&app.name);
|
|
let systemd_status = systemctl::status(&app.name);
|
|
|
|
let final_status = match (process_detected, systemd_status) {
|
|
(true, ServiceStatus::Active) => "running",
|
|
(false, ServiceStatus::Active) => "crashed", // ⚠️ Alerta
|
|
(false, ServiceStatus::Failed) => "failed",
|
|
(true, ServiceStatus::Inactive) => "zombie", // ⚠️ Alerta
|
|
_ => "unknown"
|
|
};
|
|
|
|
send_to_cloud(final_status);
|
|
}
|
|
|
|
2. Reportar discrepancias a logs y API central
|
|
|
|
3. Mantener compatibilidad con detección actual (no romper funcionalidad existente)
|
|
|
|
-------------------------------------------------------------------------------
|
|
E. INTERFACE WEB (evolucionar interface.rs)
|
|
-------------------------------------------------------------------------------
|
|
|
|
Objetivo: Panel de control completo sin eliminar funcionalidad actual.
|
|
|
|
Nuevas features:
|
|
|
|
1. Página de gestión de apps:
|
|
- Tabla con: App Name | Status | PID | CPU | RAM | Actions
|
|
- Botones: ▶️ Start | ⏹️ Stop | 🔄 Restart | 📊 Logs | 🗑️ Delete
|
|
- Indicador visual si falta sudo (banner amarillo)
|
|
|
|
2. Formulario de registro de apps:
|
|
- Campos: app_name, script_path, user, working_dir, environment vars
|
|
- Validación client-side y server-side
|
|
- Soporte para Node.js y Python
|
|
|
|
3. Visor de logs en tiempo real:
|
|
- Conectar vía WebSocket a /logs/:app_name
|
|
- Auto-scroll, filtros por nivel, búsqueda
|
|
- Botón de pause/resume
|
|
|
|
4. Mantener páginas actuales:
|
|
- /scan (escaneo de procesos)
|
|
- /select (selección de procesos)
|
|
- /logs (logs del sistema)
|
|
|
|
-------------------------------------------------------------------------------
|
|
F. TESTING (nuevo archivo tests/integration_test.rs)
|
|
-------------------------------------------------------------------------------
|
|
|
|
Objetivo: Tests de integración end-to-end.
|
|
|
|
Casos de prueba:
|
|
1. Registrar app de prueba (Node.js y Python)
|
|
2. Start → verificar PID existe
|
|
3. Stop → verificar PID desaparece
|
|
4. Restart → verificar nuevo PID
|
|
5. Leer logs vía WebSocket (primeras 10 líneas)
|
|
6. Eliminar app → verificar limpieza completa
|
|
7. Test de rate limiting
|
|
8. Test de validaciones (script inexistente, user inválido)
|
|
|
|
-------------------------------------------------------------------------------
|
|
G. DEPLOYMENT (desplegar_agent.sh)
|
|
-------------------------------------------------------------------------------
|
|
|
|
Objetivo: Script de instalación automática production-ready.
|
|
|
|
Funcionalidades:
|
|
1. Verificar dependencias (systemd, sudo, rust)
|
|
2. Compilar release
|
|
3. Configurar sudoers si es necesario:
|
|
|
|
# /etc/sudoers.d/siax-agent
|
|
siax-agent ALL=(ALL) NOPASSWD: /bin/systemctl
|
|
|
|
4. Crear servicio systemd para el agente mismo
|
|
5. Verificación post-deploy (health check)
|
|
6. Rollback automático si falla
|
|
|
|
===============================================================================
|
|
CRITERIOS DE ACEPTACIÓN
|
|
===============================================================================
|
|
|
|
✅ Panel web permite start/stop/restart desde UI
|
|
✅ Soporte Node.js y Python (FastAPI)
|
|
✅ Logs en tiempo real vía WebSocket
|
|
✅ Detección de apps crasheadas (reconciliación systemd)
|
|
✅ Validaciones de permisos, paths, users
|
|
✅ Rate limiting funcional
|
|
✅ Tests de integración pasando
|
|
✅ Script de deploy funcional
|
|
✅ Sin eliminar funcionalidad existente
|
|
|
|
===============================================================================
|
|
PRÓXIMOS PASOS
|
|
===============================================================================
|
|
|
|
1. Implementar src/models/ (ServiceConfig, ManagedApp, etc.)
|
|
2. Implementar src/systemd/ (service_generator, systemctl, parser)
|
|
3. Implementar src/orchestrator/ (app_manager, lifecycle)
|
|
4. Implementar src/api/ (handlers, websocket, dto)
|
|
5. Evolucionar monitor.rs (reconciliación systemd)
|
|
6. Evolucionar interface.rs (panel de control completo)
|
|
7. Crear tests/integration_test.rs
|
|
8. Crear desplegar_agent.sh
|
|
9. Actualizar Cargo.toml con nuevas dependencias
|
|
10. Testing completo y ajustes finales
|