Utilizzo di un'immagine Docker creata con un launcher in docker-compose

Sviluppatore
21

Ehi Mike. Fondamentalmente, quello che fai è usare ./launcher bootstrap per costruire l’immagine, spingerla su un repository e poi usare ./launcher start-cmd per vedere quali variabili d’ambiente (ENV) devono essere passate a Docker per far partire tutto.

Il motivo per cui una guida del genere non esiste è che le persone che non hanno la conoscenza più basilare di nessuno dei componenti sottostanti la troverebbero, non riuscirebbero a capirla e poi si aspetterebbero un tutorial su come funziona l’ingress su qualsiasi sistema che loro pensano sia l’unica soluzione.

22

Chiamatemi pazzo, ma forse siete la prova vivente che abbiamo fatto le cose in quel modo per una ragione? :wink:

23

Grazie Jay - l’avevo già intuito. Alla fine sono riuscito a farlo funzionare.

  • Creerò un video e una guida con l’esatto procedimento che ho seguito, così la prossima volta non perderò tempo a cercare di capire come risolvere.

Credo che parte del problema sia che va controcorrente rispetto a tutte le altre immagini Docker disponibili. Non è proprio plug-and-play. Richiede più aggiustamenti, poi si collega e infine funziona.

Come ho detto, il launcher è uno strumento bellissimo e affidabile per ciò che fa.

Per una nota davvero positiva, la versione solo web funziona benissimo, è velocissima sul mio swarm e aggiornabile perché ho il server di build.

Quando avrò tempo, esplorerò la possibilità di impostare un server di build sul mio swarm che permetta la creazione di un’immagine Docker tramite interfaccia web.

Cose che ho provato e che hanno lasciato molto a desiderare…

  • Immagine Docker Bitnami: ha funzionato peggio di un cane senza zampe.
  • Dockerfile di indiehosts: non sono arrivato nemmeno alla fase di build - sembrava deciso a costruire tutto, credo stesse compilando Linux. Anche in questo caso deve esserci un modo più semplice!

Ok - grazie.

Mike.

24

Abbiamo quello svantaggio del primo movimento :sunglasses:

Lo script di avvio è stato creato prima dell’esistenza di docker-compose, docker-swarm, kubernetes e di tutto il resto, e… funziona ancora. Non c’è davvero alcuna ragione convincente per noi di passare a qualcos’altro. I “vantaggi” di questi sistemi non sono vantaggi per il principale utilizzatore di Discourse self-hosting, ovvero le installazioni con budget su VPS cloud.

25

Oh! Me lo sono sempre chiesto. E l’ultima volta che ho dato un’occhiata, installare docker-compose su Ubuntu richiedeva un passaggio in più. Sembra che non vogliano che la gente lo usi, a meno che non si usi Windows (o Mac?).

26

È un po’ triste sentire questa come risposta ufficiale del team di sviluppo. State essenzialmente dicendo che se non siete abbastanza bravi da capire questo processo non documentato per eseguire Discourse in produzione, forse non dovreste eseguire Discourse in produzione.

Beh, non tutti noi abbiamo un’esperienza approfondita in DevOps, purtroppo.

@Mike_Sutton sono d’accordo con te. Ho letto i forum nelle ultime settimane cercando di risolvere questo problema. Sei riuscito a realizzare un video su come hai risolto il problema?

27

Funzionerebbe? E che ne dici delle migrazioni del database?

28

In questo scenario, dovresti configurare bootstrap per eseguire le migrazioni mentre costruisce la nuova immagine del container.

29

Ciao @lucasbasquerotto,

Sì, puoi inviare le immagini Docker di Discourse a un repository e archiviare il resto di /var/discourse come discusso di seguito, ma non è un modo efficiente per procedere e non è ufficialmente supportato. L’ho testato completamente di recente:

30

Ma in questo caso, il passaggio di bootstrap deve essere eseguito sulla macchina di produzione, il che vanifica in un certo senso lo scopo di spingere un’immagine base su un registry di container, se non sbaglio (poiché ciò verrebbe fatto con l’intenzione di non dover eseguire il bootstrap di un’immagine in produzione, tranne forse per eseguire un passaggio di migrazione del database o qualcosa di simile).

Questo è ciò che faccio nei siti non Discourse che ospito: normalmente uso Flyway per eseguire le migrazioni nel database, insieme ad altre operazioni come svuotare la cache Redis, ma senza eseguire altri processi intensivi, specialmente quelli che dipendono da servizi esterni, come l’aggiornamento dei certificati HTTPS (lo farei in un cronjob, tranne la prima volta, il che va bene) o la modifica del codice sorgente (questo sarebbe statico nell’immagine, come pacchetti, librerie e altro). Sembra che Discourse utilizzi Rake, il che va bene, ma esegue anche altre operazioni come l’installazione di gem, la generazione di asset, l’aggiornamento del database MaxMind e forse altri servizi (il che potrebbe interrompere il passaggio di rebuild se, ad esempio, il servizio è offline o se modificano l’API, cosa rara ma possibile).

Non sto dicendo che Discourse dovrebbe fare in quel modo, ovviamente, ma generare un’immagine in un ambiente CI ed eseguire semplicemente un passaggio di migrazione del database sui server di staging/produzione, definendo anche le variabili d’ambiente, è ciò che mi aspetterei ed è facilmente realizzabile con altri software come WordPress, MediaWiki, Rocket.Chat, ecc. Discourse è il miglior software per forum, a mio avviso, e potrebbero avere buone ragioni per procedere come fanno, ma per ora utilizzerei solo l’installazione standard (o l’installazione multicontainer) per evitare mal di testa e sperare semplicemente che nulla vada storto durante i rebuild.

Sembra che il bootstrap debba comunque essere eseguito in un ambiente di produzione e non in un ambiente CI per generare un’immagine base da utilizzare sia in staging che in produzione. Inoltre, non essere un’installazione standard è un enorme campanello d’allarme, che potrebbe diventare un mal di testa in futuro man mano che il software riceve aggiornamenti.

31

Ciao Mike,

Alla fine hai documentato il tuo processo? Sarebbe fantastico vedere anche il video?

Saluti,