È possibile installare Discourse senza gli script forniti?

Supporto Installazione
1

Ciao a tutti,

Sono di nuovo qui per chiedere una cosa un po’ strana :sparkles:

Sto ancora cercando di capire come installare Discourse per la mia Community Interna. In passato, ho chiesto come installare Discourse con un Redis esterno e un Postgres esterno, e come gestire il tutto in un cluster Kubernetes. Puoi trovare i dettagli qui.

Ora ho un altro dubbio perché mi è stato detto che devo anche creare la mia immagine container da utilizzare con Helm per il deployment e, di conseguenza, non potrò eseguire l’installazione seguendo la documentazione ufficiale usando gli script forniti nella guida all’installazione nel cloud. :cold_sweat:

Ho provato a costruire la mia immagine usando il comando bootstrap, ma non riesco ad avviare l’immagine Docker da solo perché cerca i template Ruby e restituisce un errore.

È possibile avviare l’immagine container senza utilizzare gli script forniti? Penso di aver bisogno di un po’ di aiuto perché ho provato a guardare lo script bash, ma sembra un po’ troppo avanzato per me. Speravo che forse qualcun altro si fosse trovato in una situazione simile e potesse darmi qualche consiglio.

Grazie ancora per tutto :revolving_hearts:

2

Per fornire maggiori contesto e dettagli:
Ho utilizzato lo script del launcher con il comando bootstrap per creare la mia immagine con le mie configurazioni.
La documentazione indica quindi di eseguire il launcher con il comando run per creare il contenitore dall’immagine.
Ispezionando il codice dello script ho scoperto che l’istruzione docker è questa:

$docker_path run --shm-size=512m $links $attach_on_run $restart_policy "${env[@]}" "${labels[@]}" -h "$hostname" \
        -e DOCKER_HOST_IP="$docker_ip" --name $config -t "${ports[@]}" $volumes $mac_address $user_args \
        $run_image $boot_command

Ma non riesco a tradurre tutte le variabili in un comando che potrei eseguire da solo senza lo script. O forse tutta questa strada che sto cercando di percorrere è sbagliata fin dall’inizio, ma volevo provare prima di chiedere, per verificare se riuscivo a risolvere il problema senza disturbare nessuno.

Quando provo a eseguire l’immagine docker da solo, il contenitore si arresta e guardando i log vedo questo:

Already up to date.
INFO -- : Loading --stdin
/pups/lib/pups/config.rb:23:in `initialize': undefined method `[]' for nil:NilClass (NoMethodError)
	from /pups/lib/pups/cli.rb:27:in `new'
	from /pups/lib/pups/cli.rb:27:in `run'
	from /pups/bin/pups:8:in `<main>'
3

Prova a eseguire ./launcher start-cmd app

3 Mi Piace
4

Grazie, è stato molto utile :sparkling_heart:

Questo comando era nella documentazione? Se sì, scusa per la domanda, non l’avevo visto.

Grazie mille per il tuo continuo aiuto :sparkles:

2 Mi Piace
5

Discourse dipende da PostgreSQL in esecuzione su un volume condiviso; molti altri file importanti si trovano in quel volume condiviso (immagini, file caricati, backup, log e altro).

Se mantieni l’integrità del file system del volume /shared, in base agli standard di configurazione di Discourse, puoi avviare e fermare un’immagine Docker di Discourse e l’applicazione container con facilità; tuttavia, non puoi costruire l’applicazione (per quanto ne so) senza gli script di Discourse (a meno che tu non faccia un’ingegneria inversa completa degli script e scriva il tuo script basato sugli script perfettamente funzionanti e supportati), perché gli script sono responsabili della costruzione di una sofisticata SPA EmberJS (tecnologia lato client) su Ruby on Rails (una tecnologia lato server), per non parlare della gestione della configurazione dell’applicazione principale e di tutti i plugin. A dire il vero, è un’applicazione piuttosto sofisticata.

Sì, puoi avviare un container Discourse o creare un container Discourse da un’immagine Discourse senza alcun script, se (e solo se) hai già costruito un’immagine Docker Discourse perfettamente funzionante che rispetta gli standard di configurazione di Discourse, inclusi i requisiti di archiviazione persistente per il database, le immagini e i caricamenti, i backup, i file di log, ecc. Ci sono molti file importanti richiesti da Discourse nel volume condiviso; quindi non puoi semplicemente “prendere un’immagine Docker Discourse standard” e avviala senza tutti i prerequisiti richiesti menzionati sopra (e non tutti sono stati menzionati sopra!)

Spero che questo sia d’aiuto.

6

Grazie per la risposta, è molto utile :slight_smile: Ieri stavo leggendo il motivo per cui sono necessari gli script in questo argomento e in altri pochi.

Grazie ancora per la tua spiegazione più approfondita, tutte queste informazioni mi aiutano a capire come creare il mio flusso di lavoro per rispettare gli standard necessari :slight_smile:

1 Mi Piace
7

Prego.

Può essere molto confuso per chiunque non sia (1) uno sviluppatore Ruby on Rails e (2) uno sviluppatore EmberJS.

In sostanza, stai costruendo un’applicazione Ruby on Rails per la produzione in ambiente Docker (la tecnologia lato server) che funge da base per un’applicazione SPA EmberJS di livello mondiale (l’applicazione principale per l’utente); e su tutto ciò, ottieni un sistema completo di gestione della configurazione open source per tutto il codice sorgente, mantenuto da un team molto talentuoso ed esperto di professionisti del web, che codificano in questo ambiente da molto tempo. Inoltre, puoi anche ottenere hosting professionale e sviluppo personalizzato all’interno dell’ecosistema aziendale di Discourse.

Che cosa fantastica, vero? :slight_smile:

2 Mi Piace
8

Ho appena incrociato questa informazione. Stai dicendo che non posso affatto eseguire l’applicazione e il database su host fisicamente diversi senza condividere nulla?

Nel mio caso questo sarebbe un blocco totale…

9

No, non è così. Esecuzione di Discourse con un database esterno dedicato è un caso d’uso supportato e documentato.

4 Mi Piace