178 lines
5.1 KiB
Markdown
178 lines
5.1 KiB
Markdown
# 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:
|
|
|
|
```bash
|
|
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
|
|
|
|
```bash
|
|
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
|
|
|
|
```bash
|
|
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
|
|
|
|
```bash
|
|
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:
|
|
|
|
```bash
|
|
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
|
|
|
|
```bash
|
|
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.
|