Distribución de servicios, 20 octubre 2026¶

Revisión del 21 de octubre: propietarios PVE, cobertura HA, réplicas, acceso y pendientes contrastados en el informe actual. WP-Pulse CT281 quedó retirado el21oct a las17:31 (stopped/onboot0); el inventario Docker, diagrama y muestras de esta página conservan sus fechas. El informe enlazado contiene la distribución actual y el presupuesto N-1 posterior.

Nuevo epoch pmx50, 23:24:41 CEST: boot 10196fa7…, con firma watchdog; VM208 arrancó automáticamente y estaba running a las 23:25:55. El evento 10 documenta estado y límites. El layout y los conteos de abajo conservan sus horas anteriores: no se ha realizado otro inventario PVE/Docker ni acreditado recuperación end-to-end.

PVE observado a las18:59:32 CEST y Docker a las19:00:57 CEST del20 de octubre, después del noveno arranque de pmx50,18:45:05. Los28 invitados observados estaban running:26LXC y2VM, ocho en proxmox (pmx50) y20 en proxmox2 (pmx51), mismos IDs/propietarios/estados que15:06. Docker conserva90 IDs y la misma matriz de estados/proyectos que15:10: 47running,42exited y uno created. No descarta movimientos intermedios ni acredita failover, login, copias o salud funcional de aplicaciones.

El diagrama combina propietarios de esos28 invitados revalidados18:59 con funciones/rutas de fuentes versionadas y auditorías citadas abajo. No se han vuelto a comprobar túneles, VIP, HTTP, DNS ni el interior de otros invitados. La memoria, mounts y puertos históricos conservan sus fechas explícitas; no se han releído para esta actualización. El inventario genérico de reference/inventory.md no sustituye estas muestras. Ningún producto despertado, ningún job ni recuperación; hold RunWisp f7b3… intacto.

flowchart TB
  WAN[Internet / Cloudflare Access] --> CF[Túneles CT123 + CT219]
  LAN[LAN / DNS Pi-hole] --> VIP[Caddy VIP .250]
  CF --> VIP
  VIP --> C1[Caddy CT270 / pmx50]
  VIP --> C2[Caddy CT271 / pmx51]
  subgraph P50[pmx50 / proxmox]
    C1
    V208[VM208 · Docker compute/media
Immich · Paperless · Japón
ARR/Plundrio · AudioMuse · TRMNL]
    PBS[CT186 · PBS]
    O50[CT219 cloudflared2 · CT251 RAG/Kiwix
CT280 RemotePulse · CT281 WP-Pulse
CT305 Homelable]
  end
  subgraph P51[pmx51 / proxmox2]
    C2
    HA[VM171 Home Assistant · CT172 ha-ml]
    CTRL[CT212 maint/control · CT213 PocketID
CT214 Vaultwarden · CT215 avisos/Jev
CT216 MQTT/WoL/CUPS/pegamento]
    PERSONAL[CT218 personal
Navidrome · Audiobookshelf · MusicAssistant
Airplay · Pairdrop · JustEat y auxiliares]
    MEDIA[CT220 Jellyfin · CT110 TV gateway]
    OBS[CT217 observabilidad
Prometheus · Grafana · Loki · Alertmanager
Kuma · Healthchecks · Scrutiny · Pushgateway]
    O51[CT100 Vera · CT123 cloudflared · CT155 Wireguard
CT200 n8n · CT204 Pi-hole2
CT301 Warpgate · CT302 Trove · CT303 Argus]
  end
  V208 --> NAS[TerraMaster .20 · originales/NFS/media]
  PERSONAL --> NAS
  MEDIA --> NAS
  NAS --> SYN[Synology .160 · copias versionadas de originales]
  PBS --> NAS
  EXT[Fuera de Proxmox
Pi .204 DNS/QDevice · ASUS .1
Bazzite .141 RTX3080 bajo demanda]

Propietarios actuales y memoria histórica en PVE¶

La única consulta PVE de las 18:59:32,871951 CEST /16:59:32,871951 UTC seleccionó ID, nodo, tipo, estado y uptime. Conserva los28 invitados y exactamente sus propietarios/estados de15:06; no leyó configuraciones ni herramientas guest. Proyección privada SHA256 <REDACTED>. En la tabla, propietario/estado/uptime son de18:59; memoria es histórica15:06. La proyección antigua de memoria mantiene SHA256 <REDACTED>.

VM208 sigue en pmx50 y VM171 en pmx51. Uptime es el valor reportado por PVE, no disponibilidad de sus aplicaciones. No se ha validado N-1. HA sólo figura como metadata de VM171, sin acceso a su guest/API/shell; Vera sólo como CT100.

maxmem y mem son campos de la API, expresados aquí enGiB (2³⁰bytes). No son una nueva medición de RSS ni acreditan balloon efectivo, reserva N-1 o capacidad de failover. HA sólo se leyó como metadata de VM171: no hubo acceso a su guest, API, shell ni integraciones. Vera aparece únicamente como CT100.

Los máximos API6GiB de VM171 y8GiB de VM208 se conservaron al ajustar previamente sus targets balloon a5,5 y7,5GiB respectivamente; véase aplicación de RAM. Esta muestra no vuelve a acreditar esos efectivos. La evidencia de afinidad anterior registra110/172/217/218 restringidos a pmx51 y VM208 fuera del HA registrado: no se ha releído configuración HA; ubicación actual no prueba movilidad.

Planos y almacenamiento: qué está acreditado¶

El recibo publicado de alertas acredita Prometheus en CT217 con91reglas healthok en dos lecturas de 12:23:37/12:23:56 CEST. No es una comprobación nueva del resto de los diez servicios internos. El perfil de observabilidad conserva complete_recovery_spec: false; su inventario no es un Compose reconstruible ni prueba de restore. ADR0027 contiene intención y cortes ejecutados: la lista objetivo de migración no significa que Paperless, Japón o TRMNL ya estén en CT218; siguen en VM208 en la muestra actual. Las copias Docker paradas de componentes migrados no convierten VM208 en su propietario funcional.

Docker conservado en VM208¶

Estados revalidados después de E9:19:00 CEST¶

La lectura efectiva de las 19:00:57,389012 CEST /17:00:57,389012 UTC confirma90 IDs, nombres, proyectos y estados idénticos a15:10:47running, 42exited y uno created; cero paused/restarting y cero OOMKilled registrados. De los47running,23 declaran healthy y24 no tienen healthcheck; ninguno declara unhealthy. Las22 marcas unhealthy retenidas pertenecen a exited: no son una prueba actual de fallo funcional. RestartCount1 aparece en tres exited (am-flask,am-worker1,jellyfin-share); no identifica causa ni continuidad previa. Los running declaran StartedAt18:46:06,895506–18:46:09,264730 CEST.

Dieciséis parados pertenecen a nombres/grupos lazy positivos observados; los27 restantes carecen de esa evidencia positiva e incluyen copias migradas/legacy. Esto no autoriza arrancarlos ni demuestra por qué se detuvieron; tampoco se revalidó la configuración Caddy/Sablier activa. Se conserva la distinción entre política observada y permiso de acción. RunWisp mantiene hash exacto f7b3…, uid/gid1000, modo0600 e inode3426519, sin escribirlo.

El primer intento fue inválido por un ValueError del lector y no produjo inventario Docker; no era una avería de aplicaciones. Se corrigió el acceso opcional a Health con index, se probaron campos ausentes/null en fixtures locales y hubo un único pase efectivo correcto. No se forzó ningún healthcheck ni se llamó a productos, probes, colectores o jobs. Proyección privada seleccionada SHA256 <REDACTED>. Artefactos y límites.

Captura histórica15:10 y matriz de distribución¶

Los estados/proyectos de la matriz siguiente se revalidaron19:00; sus conteos de mounts continúan siendo los de15:10, sin nueva prueba de NFS. El resto de esta captura histórica conserva sus cifras y límites originales.

90 contenedores: 47 running, 42 exited y uno created; 26 proyectos Compose, a las 15:10:06.733 CEST, después del arranque de pmx50 registrado a las 13:35. La consulta seleccionó ID/nombre, estado, Running/Paused, StartedAt, RestartCount, ID de imagen y sólo el label de proyecto Compose. Los mounts se redujeron en memoria a conteos totales y bajo /mnt/nfs_media; no se guardaron ni publicaron sus rutas individuales. Sin Env, Labels completos, inspect completo, puertos, logs, HTTP ni healthchecks. Los IDs validaron el conjunto íntegro de la lectura y permanecen privados.

Los 47 contenedores running declaran StartedAt entre las 13:36:20.817 y las 13:36:35.054 CEST; no hay contenedores pausados. Cuatro contenedores declaran RestartCount 1 y los otros 86, 0: ese cero no prueba ausencia de reinicios ni continuidad anterior del proceso. Estos campos tampoco acreditan salud de la aplicación. La proyección privada seleccionada tiene SHA-256 <REDACTED>.

Los conteos 166/30 suman entradas de mounts por contenedor, sin deduplicar sources entre contenedores o binds; 30 entradas bajo NFS corresponden a 24 contenedores, no a 30 volúmenes independientes. No se recabó la política de ciclo de vida: exited/created por sí solo no acredita avería, migración o condición bajo demanda; running tampoco autoriza reiniciar.

Referencia histórica de las 12:25:32, sin revalidar puertos a las 15:10: Immich2283, Paperless8000, Japón8089, TRMNL8094, Sablier10000 y Dozzle9999. Son bindings del motor, no pruebas de acceso, autenticación ni exposición externa. Los contenedores con red de host o proxy sin puerto publicado pueden no aparecer en esta lista.

Respecto de las 12:25:32 se conservan los 90 contenedores y los 26 proyectos, pero running pasa de 60 a 47 y exited de 29 a 42; created sigue en uno. Los 13 que pasan de running a exited son los cuatro de AudioMuse, jellyfin-share y su base de datos, jellyseerr, tunarr, pinchflat, stirling-pdf y los tres de TRMNL. Esta comparación posterior al nuevo arranque del host no establece la causa individual ni quién detuvo o arrancó cada proceso. No se ha probado ni despertado ninguno, ni se ha cambiado el hold para obtener esta muestra.

Cobertura y límites operativos¶

• El hold intencional de watch/updater de VM208 continúa documentado en su recibo operativo; el mapa no lo levanta.
• No se volvió a descubrir Docker dentro de CT212/217/218/220 ni los otros CTs: funciones internas se atribuyen a fuentes fechadas, no a una nueva prueba de cada daemon. Tampoco se verificó el funcionamiento de los servicios de VM208.
• El grafo representa conexiones declaradas; los mounts contados no acreditan frescura, contención, contenido ni completitud de backups. No hubo NAS walk, consultas SQL, restore, wake, Sablier dinámico ni prueba HTTP a productos.
• Los resets de pmx50 y las observaciones térmicas siguen en sus informes de incidente/capacidad. Running en esta muestra no determina su causa ni demuestra estabilidad futura, movilidad HA o margen N-1.

Evidencia mínima privada: proyecciones JSON PVE/Docker con fecha UTC, modo0600, bajo el stage local de esta ronda. La fuente del documento no contiene dumps de configuración, credenciales, entornos ni IDs Docker. No hubo cambios de administración, reinicios, despliegues ni tareas manuales al preparar el mapa.