Installazione nuova su nuova istanza EC2 con configurazione standard fallisce. Ho avviato un’istanza EC2 su AWS con Ubuntu 20.04.3, applicando tutti gli aggiornamenti più recenti di Ubuntu. Ho eseguito l’installazione standard semplice descritta qui.
sudo -s
git clone https://github.com/discourse/discourse_docker.git /var/discourse
cd /var/discourse
./discourse-setup
L’unica particolarità è che durante l’esecuzione di setup non è stato possibile connettersi al server tramite HTTP(S): avevo dimenticato di aprire le due porte in entrata su AWS. Quindi ho configurato manualmente il file app.yml e ho eseguito ./launcher rebuild app dopo aver aperto le porte nel gruppo di sicurezza di AWS.
Il browser non riesce a connettersi e il log di produzione mostra quanto segue.
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/message_bus-3.3.6/lib/message_bus.rb:729:in `block in new_subscriber_thread'
Job exception: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
Job exception: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
Job exception: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
Job exception: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
Job exception: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
Job exception: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL) subscribe failed, reconnecting in 1 second. Call stack /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:384:in `rescue in establish_connection'
Ho avviato una nuova istanza EC2 perché stavo utilizzando un server riutilizzato, anch’esso con Ubuntu 20.04.3, che presentava esattamente lo stesso problema quando ho installato Discourse. Gli stessi errori nel log di produzione. Quindi ho pensato: ricominciamo da zero e rendiamo tutto semplice.
OK, ora sono abbastanza convinto che ci sia un problema con l’installer di Discourse quando si utilizza Ubuntu 20.04.3 con gli ultimi aggiornamenti. Ho appena eseguito nuovamente l’installer e questa volta ho assicurato che le porte fossero aperte, quindi non ho mai dovuto configurare manualmente il file app.yml (eliminando l’errore umano). Tutto sembrava procedere senza intoppi, l’installazione ha trovato il dominio e così via. Tuttavia… nessun sito. Il log di produzione mostra
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/message_bus-3.3.6/lib/message_bus.rb:729:in `block in new_subscriber_thread'
Job exception: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL) subscribe failed, reconnecting in 1 second. Call stack /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:384:in `rescue in establish_connection'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:365:in `establish_connection'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.4.0/lib/redis/client.rb:117:in `block in connect'
Questa volta è troppo semplice perché io abbia fatto qualcosa di sbagliato; ho eseguito solo gli script.
Ecco le informazioni su RAM e swap. Si tratta di un’istanza AWS nuova di zecca, senza modifiche, con tutti gli aggiornamenti standard di Ubuntu. È un’istanza EC2 di tipo t2.small. Non è stato apportato alcun cambiamento, aggiunta, configurazione o modifica. Gli unici comandi utilizzati per aggiornare prima dell’installazione sono stati i comandi di base sudo apt update e sudo apt upgrade. Al terzo tentativo, ho provato l’installazione vanilla di Discourse su due istanze separate con lo stesso sistema operativo (Ubuntu 20.04.3). Per questo motivo, credo che possa esserci un problema con il programma di installazione e la versione recente.
$ free -h
total used free shared buff/cache available
Mem: 1.9Gi 973Mi 131Mi 36Mi 875Mi 855Mi
Swap: 2.0Gi 0.0Ki 2.0Gi
Spazio su disco, nel caso fosse rilevante.
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 39G 7.8G 31G 20% /
Ho appena eseguito un’installazione su un nuovo droplet Digital Ocean e ha funzionato correttamente. Non è un problema dell’installer.
La mia migliore ipotesi, anche se non ha molto senso che tu abbia l’errore di Redis, è che tu abbia eseguito l’installer abbastanza volte da raggiungere il limite di richieste di Let’s Encrypt, e questo è il vero problema.
Riprova con un nome di dominio diverso (ad esempio, forum2.esempio.com).
Ok, quindi ho dovuto ricostruire molto perché stavo testando il trasferimento di un forum da un vecchio server.
Come diavolo posso risolvere questo problema? Non uso nemmeno Let’s Encrypt. Dopo l’installazione riuscita, ho aggiornato il file app.yml per cambiare il dominio e ho assicurato che il template di Let’s Encrypt fosse commentato in app.yml, poi ho ricostruito, ma questo non ha aiutato e ho lo stesso problema: errore di Redis. Sono bloccato perché la chiamata a Let’s Encrypt è integrata nell’installer?
A meno che tu non stia utilizzando un reverse proxy per fornire HTTPS, non puoi farlo. Devi avere HTTPS. E se rimuovi Let’s Encrypt, devi anche rimuovere il modello HTTPS (qualunque sia il suo nome).
Non capisco molto bene perché tu stia ottenendo l’errore di Redis; forse hai commentato Redis quando hai commentato Let’s Encrypt? È la mia migliore ipotesi.
Beh, se leggi attentamente la discussione, si è trattato di un’installazione semplice su una nuova istanza, quindi non potevo commentare nulla: è l’installer, in base alle domande poste, a creare il file app.yml. Quindi il fallimento di Redis è direttamente correlato al limite di frequenza di Let’s Encrypt. Se questo può aiutare il team di sviluppo, tanto meglio.
Sto utilizzando un proxy, o meglio Cloudflare, per fornire il certificato SSL e connettermi/consegnare solo traffico HTTPS.
Ho provato a commentare il template HTTPS “templates/web.ssl.template.yml” ed eseguito un launcher rebuild app, naturalmente con anche il template di Let’s Encrypt commentato, ed è successo la stessa cosa: errore di Redis. Quindi immagino di essere bloccato, giusto? Che decisione pessima da parte dell’installer, non aver previsto un modo per bypassare le chiamate a Let’s Encrypt. A meno che tu non possa suggerirmi qualcos’altro da provare, dovrò esercitare molta pazienza in questa situazione. Apprezzo davvero molto tutto il tuo aiuto. Rimango, con umiltà, frustrato.
Ciò rende le cose molto più difficili e avrai altri problemi in seguito, a meno che non ti informi attentamente su come usare Cloudflare senza rompere Discourse.