Sto cercando di configurare Discourse per la mia organizzazione su Kubernetes. Tuttavia, sto riscontrando alcuni problemi.
Quando provo a distribuire l’immagine bootstrap su Kubernetes, tenta di eseguire operazioni come git pull pups e git pull discourse, che non funzionano poiché sono in una rete privata senza accesso a Internet. Di conseguenza, il container non si avvia. Esiste un modo per saltare queste fasi in modo da poter procedere con la distribuzione?
Sei sicuro di stare distribuendo un’immagine già avviata? Sembra che tu abbia caricato l’immagine sbagliata nel tuo registro.
Oh, davvero? Sto usando l’immagine creata da ./launcher bootstrap app
Quindi stai dicendo che l’immagine finale bootstrap non dovrebbe avere tali dipendenze?
No, non le avrà. Dopo l’avvio, ci sarà un’immagine local_discourse/app. Quella è quella che devi caricare nel registro e utilizzare altrove.
Un ultimo dubbio: sembra che abbia inviato l’immagine sbagliata, mia colpa. Quindi, dopo aver inviato l’immagine corretta, posso modificare le variabili d’ambiente durante il deployment in Kubernetes, giusto? Tipo DISCOURSE_DB_HOST, ecc.? Perché ho un cluster PostgreSQL separato e un cluster Redis!
Ci sono passato anch’io, fatto e rifatto. Non preoccuparti, è un errore molto comune. Per questo l’ho chiesto ![]()
Beh, è complicato.
Anche se puoi sovrascrivere facilmente quelle, basta aggiungere le variabili ENV necessarie all’avvio del container; durante il bootstrap eseguiamo le migrazioni. Se provi a puntare l’immagine a un database diverso dopo il bootstrap, lo schema del database risulterà completamente errato. Fare questo ti porterebbe ben oltre nel territorio delle #installazioni-non-supportate.
Quindi ho già un’istanza di Discourse in esecuzione, ma è su bare metal; voglio spostarla su k8s e collegarla allo stesso database utilizzato da quella su bare metal.
O, se possibile, posso eseguire di nuovo il bootstrap impostando DISCOURSE_DB_HOST e DISCOURSE_DB_NAME in modo che puntino allo stesso database utilizzato dall’infrastruttura bare metal?
Dovrebbe funzionare!
Potresti voler fermare il contenitore Discourse corrente collegato al database mentre esegui questa operazione, poiché le migrazioni potrebbero farlo comportare in modo errato.
Se creo un nuovo database vuoto e lo avvio da zero, è possibile migrare i dati tramite l’interfaccia utente (usando l’interfaccia della vecchia istanza di Discourse e quella nuova), ad esempio tramite /admin/backups? Voglio evitare di corrompere il vecchio database, poiché è utilizzato da molti utenti.
Non è possibile eseguire la migrazione dall’interfaccia utente.
Vedi Introduzione alla migrazione post-deploy. Questo ti permette di migrare il database in modo che funzioni sia per il vecchio che per il nuovo container, per poi eseguire le migrazioni finali dopo il deploy.
Bene, ho provato quanto detto (ho pushato l’immagine bootstrap), ma sembra che riceva ancora lo stesso errore.
fatal: unable to access 'https://github.com/discourse/pups.git/': Failed to connect to github.com port 443: Connection timed out
Sono su una rete privata, quindi non posso accedere a github.com
@pfaffman @Falco, è questo il comportamento atteso? Lo sto eseguendo su k8s
Significa che hai inviato di nuovo l’immagine sbagliata.
Modificherei il file interno /etc/hosts per simulare le risorse desiderate… poi aggiungerei quanto necessario.
Ancora più semplice… inserisci un modem/router con connessione 4G/sim. Fai in modo che la rete riconosca quel dispositivo come router predefinito per la tua rete interna… connettiti… esegui il lavoro… disconnettiti.
È abbastanza semplice.
Saluti
Keith John Hutchison - Ceiteach Seán Mac Úistin
Bringing Data to Life Pty. Ltd. (BD2L)
Questa volta sembra che ne sono abbastanza sicuro
C’è la possibilità che qualcosa vada in errore durante
./launcher bootstrap app
Inoltre, ho persino provato a utilizzare l’immagine attuale di Discourse, che viene eseguita su bare metal e ospita il nostro sito Discourse corrente, e l’ho usata su k8s, ma anche in quel caso si verifica lo stesso errore di cui sopra.
Anche sulla mia macchina locale, quando eseguo
docker run local_discourse/app
senza connessione a internet, sembra che ottenga l’errore sopra indicato