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 wurde für RHEL 8 durch Podman ersetzt.
Es erscheint sinnvoll, die Installation von Podman zu unterstützen, um RHEL- (und CentOS-)Kunden nicht zu verlieren.
Auf der offiziellen Podman-Website heißt es:
Einfach ausgedrückt: ‘alias docker=podman’
was eine hohe Interoperabilität gegenüber Docker zeigt.
Die Rentabilität (ROI) klingt vielversprechend?
Da die empfohlene Installation nicht das vom Repository bereitgestellte Docker-Paket verwendet, bin ich mir nicht sicher, ob dies in diesem Fall relevant ist.
Solange Docker selbst die Unterstützung für eine Distribution nicht einstellt, sind wir auf der sicheren Seite.
Ich weiß nicht genau, wie viel Aufwand es erfordert, Podman zu unterstützen, aber ich dachte, Unternehmenskunden mögen keinen Support auf dem Niveau von „wahrscheinlich in Ordnung".
Wenn Sie RHEL (CentOS) 8+ betreiben, müssten Sie Docker aus einem externen Repository installieren, möglicherweise parallel zu Podman, und dieser Anwendungsfall wird von Red Hat nicht unterstützt. Alternativ können Sie Podman verwenden, um das Docker-Image zu installieren, was jedoch von Discourse nicht unterstützt wird.
Hoffentlich wird dies offiziell unterstützt.
Ich vermute, dass dies mehr Aufmerksamkeit erhält, sobald CentOS 8 veröffentlicht wird.
Docker wird bereits auf CentOS 8 und damit auch auf RHEL 8 unterstützt. Mir ist kein Szenario bekannt, in dem man beide nebeneinander betreiben würde. Habe ich etwas übersehen?
Es ist wahrscheinlich ungenau zu sagen, dass Docker durch Podman ersetzt wurde; vielmehr wird Podman nun standardmäßig ausgeliefert. Immerhin, wer verwendet schon die Version von Docker, die mit der Distribution ausgeliefert wird?
Die Verantwortung für den Support lag schon immer bei Docker, nicht bei Red Hat. Wie oben erwähnt, wurde stets empfohlen, das Docker-Paket zu verwenden, nicht diejenige Version, die in der Distribution enthalten ist.
Es ist genau andersherum, aber die verlinkte RedHat-Seite besagt:
Das
docker-Paket wird von Red Hat für Red Hat Enterprise Linux (RHEL) 8 nicht ausgeliefert oder unterstützt.
Die
podman-Container-Engine hatdockerals bevorzugte, gewartete und unterstützte Container-Laufzeitumgebung für Red Hat Enterprise Linux 8-Systeme ersetzt.
Ich lese das nicht so, als ob Docker von Red Hat „unterstützt“ würde.
Wenn das bedeutet, den Support für RHEL-Kunden einzustellen, ist das eine Entscheidung von Discourse.
Überprüfe das Docker-Repository; sie bieten keine RHEL-Pakete an, sondern nur CentOS.
Podman soll zu 100 % mit Docker kompatibel sein, daher bin ich mir nicht sicher, ob wir überhaupt etwas tun müssen.
Vielleicht solltest du das Installationsdokument etwas anpassen und einen Hinweis auf die Podman-Installation hinzufügen (vielleicht einfach erwähnen, dass es unterstützt wird und dass du den Befehl docker durch podman ersetzen musst, und zwar irgendwo am Anfang), damit sich die Leute nicht fragen, ob es unterstützt wird oder nicht?
Wir werden keine explizite Stellungnahme beziehen, bis wir dies getestet haben.
Soweit ich weiß, hat noch nie jemand in der Geschichte der Menschheit versucht, Discourse mit Podman zu installieren.
Ich denke, es gibt hier ein Missverständnis. Wir sind über Podman informiert, und mehrere Mitglieder unseres Teams setzen darauf, dass es erfolgreich wird, da dies dem gesamten FOSS-Ökosystem zugutekommt. Allerdings:
Es wird nicht unterstützt.
Unser Hosting basiert auf Ubuntu/Debian. Daher haben wir derzeit keine Kunden, die RHEL nutzen.
Selbst wenn es so, wie es ist, als funktionierend erwiesen wird, wäre ich gegenüber jeglicher Vorstellung von Unterstützung sehr skeptisch.
Es sei denn, Docker gibt CentOS/RHEL auf, ist es unnötig, und selbst wenn dies geschehen würde, wären Discourse/Docker nicht die erste Anwendung, die Anforderungen auf Distributionsebene hat.
Was ich hier am frustrierendsten finde, ist das Missverhältnis zwischen Spekulation und geleisteter Arbeit.
Wenn du mit folgendem begonnen hättest, wäre meine Reaktion eine andere gewesen:
Ich habe die letzten 30 Tage die offizielle Discourse-Docker-Installation auf Podman verwendet. Hier sind die Kleinigkeiten, die mir aufgefallen sind, und hier ist, was mir an der Einrichtung gefallen hat!
Die gesamte Prämisse hier lautet: Arbeitet für uns. Ich bin nicht bereit zu experimentieren, ich bin nicht bereit, irgendetwas zu tun. Das wird für dich und die Community ein großes Problem werden.
Das missfällt mir sehr.
Das fasst meine Antwort ziemlich gut zusammen. Wir arbeiten hier mit vorhersehbaren Technologien, es besteht kein Bedarf und auch kein Raum für Apokalypse-Proklamationen.
Ich bin auch kein großer Fan von hin und her und hätte mir die Zunge eher beißen sollen, als mich darauf einzulassen.
Bei dieser Aussage ging ich davon aus, dass du etwas arbeiten musstest, damit es funktioniert. Wenn es jedoch zu 100 % kompatibel sein soll und es nur darum geht, den Befehl auszutauschen, wäre das natürlich schön.
Ich habe vorgeschlagen, dass du diejenigen unterstützen könntest, die sich mit Podman statt Docker verirrt haben.
Ich kenne dein Entwicklungsmodell nicht genau, aber ich nehme an, es ist ein community-getriebenes Modell, bei dem die Benutzer zuerst arbeiten sollen.
Ich habe es etwa eine halbe Stunde lang versucht. Podman ist kommando-kompatibel, aber nicht output-kompatibel, sodass launcher verwirrt wird, wenn es versucht, die Ausgabe zu parsen. (Es ist nicht schwer, sie zu unterscheiden: docker --version antwortet mit podman version 1.0.5, also ist dies kein ernsthaftes Hindernis.)
Es gibt kein Netzwerkgerät docker0. Der Standard-overlay-Speichertreiber in Podman ist im Wesentlichen die overlay2-Implementierung und darauf aliased, aber die Ausgabe sagt nicht overlay2, und die Ausgabe des Befehls docker info ist leicht unterschiedlich. Ich habe --skip-prereqs verwendet, um die Prüfungen zu umgehen. Die freigegebenen Verzeichnisse wurden nicht automatisch erstellt; ich habe nicht untersucht, warum. Ich habe mkdir -p /var/discourse/shared/standalone/log/var-log ausgeführt, um weiterzukommen. Als Nächstes sah ich Berechtigungsprobleme, weil SELinux aktiviert, aber nicht für /var/discourse konfiguriert war.
Wenn Sie ein Verzeichnis in einen Container einbinden und ein :z oder :Z hinzufügen, etikettieren die Container-Engines den Inhalt unter den Volumes auf
container_file_t.
Die Podman-Build-Dokumentation besagt:
Die Option
zteilt Podman mit, dass zwei Container den Volumeninhalt teilen. Infolgedessen etikettiert Podman den Inhalt mit einem geteilten Inhaltslabel. Geteilte Volumenlabels ermöglichen es allen Containern, den Inhalt zu lesen und zu schreiben. Die OptionZweist Podman an, den Inhalt mit einem privaten, nicht geteilten Label zu versehen. Nur der aktuelle Container kann ein privates Volumen verwenden.
Ich habe mich entschieden, Ich habe die setenforce 0 für diese vorübergehende Installation vorübergehend zu setzen und später vielleicht darauf zurückzukommen.volumes so geändert, dass sie das kleingeschriebene :z verwenden:
volumes:
- volume:
host: /var/discourse/shared/standalone
guest: /shared:z
- volume:
host: /var/discourse/shared/standalone/log/var-log
guest: /var/log:z
Mit diesen kleinen Änderungen habe ich es geschafft, dass Discourse hochgefahren wird. Redis ist unglücklich darüber, dass transparente große Seiten im Kernel unterstützt werden, und schlägt vor, dies zu deaktivieren sowie die Einstellungen für die Speicherüberbelegung zu ändern. Wahrscheinlich sind viele andere nützliche Debug-Meldungen an mir in den Megabytes an Logausgabe vorbeigeflogen!
./launcher start app
...
--restart option is not supported.
Use systemd unit files for restarting containers
Ich habe das Skript so angepasst, dass es --restart nicht verwendet, und festgestellt, dass auch im start-Modus --skip-prereqs erforderlich ist, was mich schließlich dazu brachte, docker run auszuprobieren, woraufhin:
./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
Es funktioniert also definitiv nicht aus der Box, und ich weiß nicht, wie viel Arbeit es wäre, launcher so anzupassen, dass es entweder mit Docker oder Podman funktioniert. Die Behandlung von Voraussetzungen wäre „einfach