Informazioni di contesto: il sito è lot.almost-dead.net, versione 2.8.0.beta4, ospitato su Google Cloud/Compute; ho seguito la guida ufficiale basata su Docker per configurarlo. (Sono esperto di tecnologie front-end per browser e conosco i principi generali dell’hosting cloud, ma sono familiare con AWS e non con Google.)
Causa preliminare: ho arrestato l’istanza VM e poi l’ho riavviata (tentando di modificare le variabili d’ambiente esposte a Discourse).
Quando la VM è tornata online e il sito è stato ripristinato, ho notato che le risorse JS andavano in timeout, insieme ad alcune avatar degli utenti. Nel pannello di amministrazione, l’area Salute della Comunità non si carica; il cursore continua a girare e, negli Strumenti per sviluppatori di Chrome, la scheda Rete mostra che tutte le richieste /message-bus/.../poll falliscono. La pagina di Aggiornamento (/admin/upgrade) fallisce quasi immediatamente e Chrome mostra il codice di errore ERR_FAILED. Navigando tra gli argomenti, vedo richieste POST fallire con ERR_CONNECTION_REFUSED e richieste GET avviate da JavaScript fallire con ERR_FAILED. (Questo è da un browser con cookie di accesso impostati per il mio account amministratore.)
Caricare il sito da una nuova istanza del browser mostra l’errore ERR_CONNECTION_REFUSED di Chrome.
Cosa ho provato:
Ricostruzione lato server — sudo ./launcher rebuild app sembra avere successo, ma non ci sono cambiamenti nel comportamento del sito
Ho anche provato a commentare i plugin e a ricostruire, senza alcun cambiamento
Modalità sicura — la richiesta di /safe-mode restituisce immediatamente la pagina di errore ERR_FAILED di Chrome
No, il tuo sito non è stato ripristinato, è completamente offline. Stai guardando parzialmente la cache. Per chi non ha mai visitato il tuo sito, non risponde affatto. Questo è probabilmente un problema a livello di rete/firewall, oppure nginx non si avvia o va in crash.
Una volta eseguito sudo ./launcher enter app, sembra che nginx sia in esecuzione…
root@adn-prod-app:/var/www/discourse# ps aux | grep nginx
root 548 0.0 0.0 2156 64 ? Ss 07:04 0:00 runsv nginx
root 558 0.0 0.1 55236 2524 ? S 07:04 0:00 nginx: master process /usr/sbin/nginx
www-data 567 0.0 0.2 55996 5068 ? S 07:04 0:00 nginx: worker process
www-data 568 0.0 0.0 55996 1628 ? S 07:04 0:00 nginx: worker process
www-data 569 0.0 0.0 55792 1680 ? S 07:04 0:00 nginx: cache manager process
root 23179 0.0 0.0 6140 884 pts/1 S+ 21:23 0:00 grep nginx
Non sono sufficientemente familiare con Google Cloud per sapere cosa cercare nelle sue impostazioni di rete/firewall… Ho notato che l’istanza della VM ha i tag “http-server” e “https-server” e che il suo sistema firewall sembra utilizzare questi tag per applicare le regole integrate “default-allow-http” e “default-allow-https” alle istanze con tali tag. Questo mi sembra corretto, e nslookup mostra che il sottodominio che sto usando risolve all’indirizzo IP esterno elencato nell’interfaccia utente di Google, ma il mondo esterno non riesce comunque ad accedere all’istanza.
Ciao,
è una lunga scommessa, ma l’ultima volta che ho visto un errore Redis era in qualche modo correlato (o meglio, rientrava nello stesso ambito) ai certificati SSL (mancanti?).
Forse ./launcher logs app potrebbe aiutare?
Sembra che il mio problema fosse dovuto al fatto che la VM è tornata online con un indirizzo IP diverso, e ho dovuto modificare il mio record A per puntare al nuovo indirizzo.
Il sito è di nuovo attivo, grazie per avermi ascoltato!
Sembra che il mio problema fosse dovuto al fatto che la VM è tornata online con un indirizzo IP diverso, e ho dovuto modificare il mio record A per puntare al nuovo indirizzo.