Piano di cambio del midserver: v2 → v3 in prod (Fase 8)¶
Bozza. Va completata in T8.1 con immagini, comandi e tempi reali, e provata per intero in dev (T8.2), compreso il rollback, prima di essere eseguita.
Strategia¶
- Sul posto, sulla stessa VM ServerIT (
170.10.0.108), mantenendo: 172.16.16.253:5000(HTTP dei box) e:1883(Mosquitto, stesse credenziali e stessi dati);- OME su
185.31.66.185con le stesse porte; - i nomi
api.bsqdev.uk,panel.bsqdev.uk,ome.bsqdev.ukdietro NPM; ewelink-integrationintatto su 8080.- I box non vengono toccati durante il cambio.
- Gli allarmi del sistema vecchio (Telegram) non dipendono dal midserver: durante la finestra continuano a funzionare. Si interrompono configurazione, comandi dal pannello, live e i flussi verso qAlarm.
Prerequisiti (GATE C)¶
Vedi checklist-gate.md. In particolare: GATE A superato, box allineati (T9.1, solo se P4 è confermata: A25), backup verificati, controlli manuali pianificati, prova generale in dev riuscita, finestra concordata e centrale avvisata.
Procedura¶
| # | Passo | Durata stimata | Verifica |
|---|---|---|---|
| 0 | Annunciare l'inizio alla centrale. Verificare che nessuna installazione nuova sia in corso. | — | — |
| 1 | Fotografia dello stato: numero di box online, versione, ultimi eventi (comandi in comandi-verifica.md). | 5 min | numeri annotati |
| 2 | Backup: dump MySQL, copia dump.rdb (dopo BGSAVE), copia di docker-compose.yml, .env.prod e cartella server_data, snapshot Proxmox manuale della VM 500. |
15 min | file presenti fuori dalla VM; snapshot visibile in Proxmox |
| 3 | Scaricare le immagini v3 da ECR (prima della finestra, se possibile). | — | docker images |
| 4 | Fermare solo midserver e celery_worker v2 (docker stop, non down). Mosquitto, Redis, MySQL e OME restano su. |
1 min | i box continuano a pubblicare su Mosquitto |
| 5 | Migrazione dei dati (T3.11), se necessaria. | da misurare in T8.2 | output dello script senza errori |
| 6 | Avviare la v3 con il compose di prod (T3.7), agganciata agli stessi servizi con stato e con la porta 5000 per i box. | 2 min | /health OK |
| 7 | Aggiornare NPM: api.bsqdev.uk verso la v3; pannello aggiornato alla versione compatibile (T3.4). |
5 min | pannello carica l'elenco dei box |
| 8 | Verifiche: tutti i box tornano online entro 2 intervalli di sync; un comando su un box di riferimento; live su un box; un evento nello stream; ewelink risponde. | 15 min | stessi numeri del passo 1 |
| 9 | Annunciare la fine alla centrale. Controlli manuali ripetuti (box online, comandi, video) per 24 ore. | — | — |
Criteri di rollback¶
Si torna indietro subito se, entro 30 minuti dal passo 6: - meno del 90% dei box online rispetto al passo 1, senza una causa nota e risolvibile in pochi minuti; - i comandi dal pannello falliscono su più box; - errori ripetuti nei log della v3 su endpoint chiamati dai box.
Rollback¶
| # | Passo |
|---|---|
| R1 | Fermare la v3 (docker stop). |
| R2 | Se il passo 5 ha modificato dati: ripristinare Redis (dump.rdb) e MySQL dal backup del passo 2. |
| R3 | Riavviare midserver e celery_worker v2 (docker start). |
| R4 | Ripristinare la configurazione di NPM e il pannello 1.8.0. |
| R5 | Verifiche come al passo 8. |
| R6 | Se nulla funziona: ripristinare lo snapshot Proxmox della VM 500 (ultima risorsa: perde tutto ciò che è successo dopo il passo 2). |
Tempo massimo di rollback da misurare in T8.2 e da scrivere qui.
Dopo il cambio¶
Osservazione di due settimane (T8.4), poi dismissione della v2 (T8.5). L'aggiornamento senza fermo vero e proprio (rolling update con Coolify e Traefik) arriva con T10.7.