michele/netgescon-day0
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
119f486bb8
netgescon-day0/docs/INSTALLAZIONE-NODO-LOCALE-0.9.md

5.1 KiB
Raw Blame History

NetGescon 0.9 - Installazione nodo locale da macchina vuota

Questo documento descrive la prova che ha senso fare adesso: una macchina Ubuntu nuova che installa NetGescon come nodo locale singolo, senza dipendere dai servizi cloud pubblici per funzionare nel quotidiano.

Obiettivo pratico:

  1. preparare una VM o macchina Ubuntu pulita;
  2. installare Docker e lo stack applicativo locale;
  3. avviare NetGescon come nodo singolo;
  4. ripristinare un backup proveniente dal sito;
  5. verificare che il nodo lavori in autonomia con DB, storage e servizi locali.

Cosa e incluso nel repository

Per questa prova sono pronti i seguenti file:

  • docker/docker-compose.node-local.yml
  • docker/.env.node-local.example
  • docker/install-node-local.sh
  • docker/restore-node-backup.sh
  • docker/provision-vm.sh

Questo stack non usa il multisito www/app/demo. Porta su un solo nodo applicativo con:

  • app PHP-FPM Laravel
  • nginx
  • mysql
  • redis

Cosa serve dalla macchina remota

Per procedere senza perdere tempo mi servono solo queste informazioni:

  1. IP della macchina oppure hostname raggiungibile in LAN/VPN.
  2. Utente SSH e porta SSH.
  3. Conferma versione Ubuntu (22.04 o 24.04 va bene).
  4. RAM, CPU e spazio disco disponibili.
  5. Path in cui vuoi installare il progetto, ad esempio /opt/netgescon.
  6. Se il nodo dovra rispondere solo in LAN o anche con DNS dedicato.
  7. Se hai gia pronto il backup da ripristinare:
    • dump SQL del DB applicativo;
    • archivio storage del sito;
    • eventuale archivio legacy MDB/Access da montare in LEGACY_ARCHIVES_PATH.

Bootstrap da macchina vuota

1. Copia repository sulla macchina

Se la macchina vede Gitea:

cd /opt
git clone ssh://git@192.168.0.53:2222/michele/netgescon-day0.git netgescon-day0
cd /opt/netgescon-day0

Se non vuoi usare Git direttamente sul nodo, puoi copiare un archivio del repository gia allineato.

2. Provision base Ubuntu

cd /opt/netgescon-day0/docker
chmod +x provision-vm.sh install-node-local.sh restore-node-backup.sh
./provision-vm.sh

Poi fai logout/login per applicare il gruppo Docker.

3. Prepara env locale del nodo

cd /opt/netgescon-day0
cp docker/.env.node-local.example docker/.env.node-local
nano docker/.env.node-local

Campi da impostare subito:

  • APP_URL
  • NODE_HTTP_PORT
  • DB_PASSWORD
  • DB_ROOT_PASSWORD
  • LEGACY_ARCHIVES_PATH

APP_KEY puo restare vuota: viene generata automaticamente da install-node-local.sh al primo avvio.

4. Installa e avvia lo stack

cd /opt/netgescon-day0/docker
./install-node-local.sh

Lo script:

  1. valida il compose;
  2. genera APP_KEY se manca;
  3. builda l immagine applicativa;
  4. avvia DB e Redis;
  5. avvia app e nginx;
  6. crea anche il database gescon_import per gli import legacy.

Restore backup del sito

Dopo aver copiato sul nodo il dump del database e l archivio storage:

cd /opt/netgescon-day0/docker
./restore-node-backup.sh --sql /percorso/backup.sql.gz --storage /percorso/storage.tar.gz

Note operative:

  • il dump SQL puo essere .sql oppure .sql.gz;
  • lo storage e opzionale, ma senza storage il nodo partira senza documenti/allegati storici;
  • l archivio storage deve essere un tar.gz estraibile con radice compatibile con /var/www/storage.

Verifiche minime dopo restore

cd /opt/netgescon-day0

docker compose --env-file docker/.env.node-local -f docker/docker-compose.node-local.yml ps
docker compose --env-file docker/.env.node-local -f docker/docker-compose.node-local.yml logs -f --tail=100

Controlli applicativi minimi:

  1. login backoffice;
  2. apertura dashboard;
  3. apertura di almeno una pagina contabile;
  4. verifica documenti/allegati storici;
  5. verifica accesso al DB applicativo;
  6. verifica che il nodo non dipenda da servizi cloud per il funzionamento base.

Spiegazione del messaggio visto su staging

Il pannello Supporto > Aggiornamento Nodo mostra due cose diverse:

  1. lo stato Git noto al nodo;
  2. l eventuale esecuzione dell update applicativo.

Per questo:

  • Ultima sync Git indica quando il nodo ha registrato l ultima sync Git;
  • Ultimo update resta - se non e mai stato lanciato un update applicativo da quella pagina.

Dopo il push su Gitea di oggi, il nodo che ho verificato mostra gia:

  • branch main
  • commit b3e626b
  • tracking ahead 0 / behind 0
  • working tree pulito

Quindi il problema non era un guasto Git: era solo assenza di un update applicativo registrato, mentre la parte Git ora e allineata.

Limiti attuali da tenere presenti

Questa prova locale serve per installazione e ripristino operativo. Restano fuori, salvo configurazione dedicata:

  • manifest distribution pubblico;
  • licensing per canali;
  • backup cloud esterni;
  • servizi Google/Gmail/Drive lato studio;
  • reverse proxy TLS pubblico multi-dominio.

Prossimo passo corretto

Appena mi dai i dati della macchina remota, facciamo in ordine:

  1. verifica accesso SSH e risorse;
  2. provisioning Docker;
  3. copia repository o clone da Gitea;
  4. creazione docker/.env.node-local;
  5. avvio stack;
  6. restore backup del sito;
  7. checklist di collaudo del nodo.