Questa pagina descrive l'architettura in forma referenziale. Non contiene indirizzi, credenziali, path amministrativi, comandi root o istruzioni di deploy. Tali dettagli appartengono alla documentazione interna e non al sito pubblico.
CONTROLLO CENTRALE:
Conserva identità del servizio, assegnazione al nodo, configurazione gestita, relazioni con database e backup e stato delle richieste.
CHECKER DEL NODO:
Seleziona le richieste compatibili, valida configurazione e dati, effettua il claim e avvia il workflow operativo.
WORKFLOW OPERATIVO:
Coordina filesystem, web server, PHP-FPM, database e strumenti locali. Restituisce esito e diagnosi al checker o finalizza direttamente dove previsto.
HELPER:
Risolve responsabilità circoscritte, per esempio traversate filesystem sicure, parsing dello snapshot, estrazione dell'archivio e verifica Project ID.
STATO E CONFIGURAZIONE GESTITA:
Database centrale del pannello.
COMPORTAMENTO EFFETTIVO DEL NODO:
Codice operativo corrente e configurazione distribuita.
FOTOGRAFIA STORICA DEL BACKUP:
Snapshot protetto e artefatti associati.
STATO REALE DI PROCESSI, FILESYSTEM E SERVIZI:
Verifica locale al momento dell'operazione.
Nessuna fonte sostituisce automaticamente le altre. Lo stato centrale non prova che un processo locale sia terminato; un file presente non prova che la richiesta sia stata finalizzata.
Molti checker lavorano un record per invocazione. Alcuni workflow consegnano il servizio a una fase successiva, quindi la fine di un processo non coincide sempre con la fine dell'intero percorso.
LOCK DI CHECKER:
Evita due istanze dello stesso consumer quando implementato. Non blocca workflow differenti.
CLAIM CONDIZIONALE:
Impedisce la doppia acquisizione della stessa richiesta se tutti i consumer rispettano lo stato atteso.
GATE DEL PANNELLO:
Deve impedire nuove azioni incompatibili e la sovrascrittura dello stato precedente durante un lavoro.
LIMITE:
Non esiste oggi un lock per-servizio universale condiviso da ogni workflow. Preflight e controlli riducono conflitti noti ma non congelano qualsiasi modifica possibile per tutta la durata.
Gli errori applicativi vengono associati alla risorsa e al workflow. Gli step aiutano a localizzare la fase, mentre log tecnici conservano informazioni operative senza segreti.
Un crash può lasciare uno stato “in esecuzione”. La data di avvio del restore non è un heartbeat e non prova che il processo sia ancora vivo. Non sono presenti watchdog o retry automatici universali; la diagnosi manuale è la strategia corrente per gli stati stale.
Ogni ambiente ha pool e socket dedicati; il master della versione è condiviso. Nove parametri gestiti provengono dal database centrale e vengono validati.
CREAZIONE:
Genera il pool con modello dinamico e direttive di isolamento previste.
AGGIORNAMENTO:
Modifica soltanto le direttive gestite, conserva le altre, testa la configurazione e prevede rollback del file.
CAMBIO VERSIONE:
Copia il pool esistente, aggiorna socket e valori gestiti, modifica il vhost e testa le configurazioni. Conserva limiti di rollback e reload condivisi noti.
RESTORE:
Non modifica pool, socket o master e non ricarica PHP-FPM. La versione storica resta metadato.
Il servizio usa identità dedicate e policy distinte per public, log, temporanei e backup. La normalizzazione sicura lavora tramite descriptor e non segue symlink.
Project Quota assegna all'intero albero del servizio un identificatore stabile e limiti hard di spazio e inode. L'helper di normalizzazione non modifica o verifica questi attributi; il restore usa un controllo separato tramite filesystem per ogni inode non symlink.
I workflow ordinari creano, eliminano e duplicano schemi associati al servizio. Lo storico logico resta importante per il restore.
Il restore non inserisce nuove identità: usa la stessa riga storica, ricrea i TARGET con credenziali dello snapshot ed elimina gli EXTRA. Database e filesystem non condividono rollback globale.
Il backup cattura il set di database, produce archivio e dump compressi, finalizza uno snapshot protetto e pubblica il risultato soltanto dopo le verifiche. HOT e STOP hanno livelli di coerenza differenti.
Claim, creazione della riga backup e finalizzazione del servizio non sono una transazione distribuita unica. Un crash può lasciare backup non conclusi o stati da riconciliare manualmente.
Il restore segue le macrofasi:
VALIDAZIONE → ISOLAMENTO → DATABASE → FILE → NORMALIZZAZIONE → VERIFICA → PERSISTENZA → RIAPERTURA → FINALIZZAZIONE.
Prima della distruzione, il preflight controlla identità, artefatti, mapping, capacità e runtime. Dopo l'inizio, un errore può lasciare progressi parziali; il flusso tenta di mantenere l'ambiente isolato e registra diagnosi.
Backup e restore usano file temporanei protetti per le credenziali. Alcune catene storiche non sono ancora allineate allo stesso modello.
Il collegamento al database centrale richiede TLS. La modalità corrente cifra il canale; la verifica completa dell'identità dell'endpoint è una direzione futura subordinata a certificati e hostname adeguati.
Il codice sorgente operativo è condiviso e parametrizzato. Una modifica che cambia un'interfaccia deve distribuire insieme chiamante e componente chiamato. Formati backup e semantiche degli stati richiedono consumer compatibili prima di attivare il nuovo writer.
Il workspace documenta procedure interne di deploy, ma il sito pubblico non fornisce una guida per installare Fliclic Server. Non è presente un updater autonomo implementato.
