People,
I know Discourse has standardised on Docker for distribution and support but it seems to me there are some reasonable arguments for also making Discourse available as a Podman container? I would be happy to have a go at producing something if at least one clued-up dev was prepared to help me . .
Regards,
Phil.
It is unlikely we can spend any time on it, but if you want to give it a go, go for it.
Thanks for the fast reply Jeff!
I will see if I can get some enthusiam going from the appropriate Fedora group . .
@codinghorror , Can you point me to a HOWTO for a completely manual install somewhere? - I have some familiarity with Rails etc . .
Here are the instructions: Beginners Guide to Install Discourse on Ubuntu for Development.
If you look at the install script in the Install Discourse Dependencies section of the guide, you’ll find the manual instructions there.
Thanks!
I will check it out . .
Docker è stato sostituito da Podman per RHEL 8.
Sembra naturale iniziare a supportare l’installazione di Podman per non perdere i clienti RHEL (e CentOS).
In parole povere: ‘alias docker=podman’
che mostra un’alta interoperabilità rispetto a Docker.
Il ROI sembra positivo?
Poiché l’installazione consigliata non utilizza il pacchetto Docker fornito dal repository, non sono sicuro che questa sia una considerazione in un senso o nell’altro.
Finché Docker stessa non smetterà di supportare una distribuzione, saremo a posto.
Non so esattamente quanto sforzo richieda il supporto per Podman, ma pensavo che i clienti enterprise non gradiscano un livello di supporto del tipo “probabilmente a posto”.
Se eseguite RHEL (CentOS) 8+, dovrete installare Docker da un repository esterno, eventualmente in parallelo a Podman, e tale caso d’uso non sarà supportato da RedHat, oppure potrete semplicemente usare Podman per installare l’immagine Docker, ma questo non è supportato da Discourse.
Speriamo che venga ufficialmente supportato.
Credo che questa questione attirerà più attenzione con il rilascio di CentOS 8.
Docker è già supportato su CentOS 8 e, di conseguenza, su RHEL 8. Non sono a conoscenza di scenari in cui si eseguiranno i due side by side; sto trascurando qualcosa?
È probabilmente impreciso affermare che Docker sia stato sostituito da Podman; è corretto dire piuttosto che Podman è ora incluso di default. Dopotutto, chi utilizza la versione di Docker fornita con la distribuzione?
La responsabilità del supporto è sempre stata di Docker, non di Red Hat. Come indicato sopra, la raccomandazione è sempre stata quella di utilizzare il pacchetto Docker, non quello fornito con la distribuzione.
È esattamente il contrario, ma la pagina di RedHat collegata afferma:
Il pacchetto
dockernon è fornito né supportato da Red Hat per Red Hat Enterprise Linux (RHEL) 8.
Il motore di container
podmanha sostituitodockercome runtime di container preferito, mantenuto e supportato per i sistemi Red Hat Enterprise Linux 8.
Non interpreto questo come Docker “supportato” da RedHat.
Se ciò significa rinunciare al supporto per i clienti RHEL, è una scelta di Discourse.
Controlla il repository Docker: non offrono pacchetti RHEL, solo CentOS.
Podman è progettato per essere completamente compatibile con Docker, quindi in realtà non sono sicuro che dovremo fare qualcosa.
Forse, modifica leggermente il documento di installazione per aggiungere un riferimento all’installazione di Podman (magari basta specificare che è supportato e che si deve sostituire il comando docker con podman in qualche punto all’inizio), così le persone non si chiederanno se è supportato o meno?
Non prenderemo alcuna posizione esplicita finché non avremo testato questa soluzione
Per quanto ne sappia, nella storia dell’umanità nessuno ha mai provato a installare Discourse utilizzando Podman
Credo ci sia un po’ di confusione qui. Conosciamo Podman e diverse persone del team fanno il tifo per il suo successo, perché ciò sarebbe positivo per l’intero ecosistema FOSS, ma:
Non è supportato.
La nostra infrastruttura di hosting utilizza Ubuntu / Debian. Quindi al momento non abbiamo clienti che eseguono RHEL.
Anche se fosse dimostrato che funziona così com’è, sarei molto diffidente verso qualsiasi idea di supporto.
A meno che Docker non abbandoni CentOS/RHEL, non è necessario, e anche se ciò dovesse accadere, Discourse/Docker non sarebbe la prima applicazione ad avere requisiti a livello di distribuzione.
Ciò che trovo più frustrante qui è la quantità di speculazioni rispetto al lavoro effettivamente svolto.
Se avessi iniziato con questo, la mia reazione sarebbe stata diversa:
Ho utilizzato l’installazione ufficiale di Discourse tramite Docker negli ultimi 30 giorni su Podman; ecco i piccoli problemi che ho riscontrato e ciò che mi è piaciuto di questa configurazione!
L’intera premessa qui è: fate il lavoro per noi, non sono disposto a sperimentare, non sono disposto a fare alcun lavoro, questo diventerà un grosso problema per voi e per la comunità.
Mi dispiace molto questo atteggiamento.
Quello riassume bene la mia risposta: stiamo lavorando con tecnologie prevedibili, non c’è né bisogno né spazio per profezie apocalittiche.
Non sono nemmeno un grande fan del tira e molla e avrei probabilmente dovuto mordermi la lingua piuttosto che impegnarmi.
Con questa affermazione, davo per scontato che dovessi svolgere del lavoro per farlo funzionare, ma se dovrebbe essere 100% compatibile e si tratta solo di sostituire il comando, sarebbe ottimo.
Stavo suggerendo che potresti guidare coloro che si sono persi usando Podman invece di Docker.
Non conosco esattamente il tuo modello di sviluppo, ma immagino sia guidato dalla comunità e che ci si aspetti che siano gli utenti a lavorare per primi.
Ho dato una prova per circa mezz’ora. Podman è compatibile a livello di comandi ma non a livello di output, quindi launcher si confonde quando tenta di analizzare l’output. (Non è difficile distinguerli: docker --version risponde con podman version 1.0.5, quindi non si tratta di un ostacolo serio.)
Non esiste il dispositivo di rete docker0. Il driver di storage overlay predefinito in Podman è sostanzialmente l’implementazione overlay2 ed è alias di quest’ultimo, ma l’output non riporta overlay2 e l’output del comando docker info è leggermente diverso. Ho utilizzato --skip-prereqs per bypassare i controlli. Le directory condivise non sono state create automaticamente; non ho indagato il motivo. Ho eseguito mkdir -p /var/discourse/shared/standalone/log/var-log per procedere. Successivamente ho riscontrato problemi di permessi dovuti al fatto che SELinux era in modalità enforcing ma non configurato per /var/discourse.
Se si monta un volume di una directory in un container e si aggiunge :z o :Z, i motori dei container rinominano il contenuto sotto i volumi a
container_file_t.
La documentazione di podman build afferma:
L’opzione
zindica a Podman che due container condividono il contenuto del volume. Di conseguenza, Podman etichetta il contenuto con un’etichetta condivisa. Le etichette dei volumi condivisi consentono a tutti i container di leggere e scrivere il contenuto. L’opzioneZindica a Podman di etichettare il contenuto con un’etichetta privata non condivisa. Solo il container corrente può utilizzare un volume privato.
Ho deciso di impostare Ho modificato i setenforce 0 per ora su questa installazione temporanea e riprenderlo in seguito, forse.volumes per utilizzare la versione in minuscolo :z in questo modo:
volumes:
- volume:
host: /var/discourse/shared/standalone
guest: /shared:z
- volume:
host: /var/discourse/shared/standalone/log/var-log
guest: /var/log:z
Con queste piccole modifiche, sono riuscito a far avviare Discourse. Redis non è soddisfatto perché le pagine trasparenti di grandi dimensioni (transparent huge pages) sono supportate nel kernel e suggerisce di disabilitarle, oltre a modificare le impostazioni di overcommit della memoria. Probabilmente molti altri messaggi di debug utili sono passati inosservati tra i megabyte di output del log!
./launcher start app
...
--restart option is not supported.
Use systemd unit files for restarting containers
Ho modificato lo script per non utilizzare --restart e ho scoperto la necessità di --skip-prereqs anche nella modalità start, il che mi ha finalmente portato a provare docker run, momento in cui:
./launcher start app --skip-prereqs
...
+ /usr/bin/docker run ... -e DOCKER_HOST_IP= --name app -t -p 80:80 -p 443:443 -v /var/discourse/shared/standalone:/shared:z -v /var/discourse/shared/standalone/log/var-log:/var/log:z --mac-address 02:9c:01:9b:0e:17 local_discourse/app /sbin/boot
--mac-address option not currently supported
Quindi non funziona sicuramente fuori scatola e non so quanto lavoro richiederebbe adattare launcher per funzionare con Docker o Podman. Gestire i prerequisiti sarebbe “semplice” e probabilmente non troppo difficile con un controllo preliminare per Podman, ma non so quanto profondamente le ipotesi sulla configurazione di rete siano incorporate nella configurazione dello stack sottostante, e sembra che questa modalità di rete non sia semplicemente supportata da Podman.
In base a questa preoccupazione, ho deciso di non svolgere il lavoro necessario per far funzionare launcher con Podman. Sto solo riportando i risultati di un esperimento iniziale rapido.
Detto questo, probabilmente non è un lavoro difficile per qualcuno che conosce meglio lo stack. Ho svolto tutto il mio lavoro di sviluppo questa primavera con un’installazione manuale di sviluppo su Fedora 29, apportando adattamenti banali come l’uso di dnf invece di apt-get e alcune traduzioni minori dei nomi dei pacchetti, senza utilizzare Docker o Podman. Mi aspetto che qualcuno che conosca bene Podman così come l’amministrazione normale dell’intero stack tecnologico di Discourse troverebbe probabilmente un lavoro moderato e relativamente semplice. Se conoscessi tutto il lavoro necessario, avrei una migliore idea di se si tratti di un tipo di lavoro che potrebbe “deteriorarsi” e richiedere manutenzione continua o meno. Ma… non lo so. 