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 ha sido reemplazado por Podman en RHEL 8.
Parece natural comenzar a soportar la instalación de Podman para no perder clientes de RHEL (y CentOS).
Desde el sitio oficial de Podman,
Simplemente: ‘alias docker=podman’
lo que demuestra una alta interoperabilidad con Docker.
¿El ROI parece bueno?
Como la instalación recomendada no utiliza el paquete de Docker proporcionado por el repositorio, no estoy seguro de que esto sea una consideración en ningún sentido.
Mientras Docker mantenga el soporte para una distribución, estaremos bien.
No sé exactamente cuánto esfuerzo requiere dar soporte a Podman, pero pensé que los clientes empresariales no les gusta un nivel de soporte de «probablemente estaremos bien».
Si ejecutas RHEL (CentOS) 8 o superior, tendrías que instalar Docker desde un repositorio externo, posiblemente junto con Podman, y ese caso de uso no será compatible con Red Hat, o simplemente usar Podman para instalar la imagen de Docker, pero eso no es compatible con Discourse.
Esperemos que se soporte oficialmente.
Creo que esto recibirá más atención cuando se lance CentOS 8.
Docker ya es compatible con CentOS 8 y, por extensión, con RHEL 8. No conozco ningún escenario en el que se ejecuten ambos simultáneamente; ¿estoy pasando por alto algo?
Probablemente sea inexacto afirmar que Docker ha sido reemplazado por Podman; más bien, Podman ahora se incluye de forma predeterminada. Después de todo, ¿quién utiliza la versión de Docker que se incluye en la distribución?
La responsabilidad del soporte siempre ha recaído en Docker, no en Red Hat. Como se mencionó anteriormente, la recomendación siempre ha sido utilizar el paquete de Docker, y no el que se incluye en la distribución.
Es al revés, pero la página vinculada de Red Hat dice:
El paquete
dockerno se incluye ni es compatible por parte de Red Hat para Red Hat Enterprise Linux (RHEL) 8.
El motor de contenedores
podmanreemplazó adockercomo el tiempo de ejecución de contenedores preferido, mantenido y compatible por defecto para los sistemas Red Hat Enterprise Linux 8.
Yo no interpreto esto como que Docker sea ‘compatible’ por parte de Red Hat.
Si eso significa dejar de dar soporte a los clientes de RHEL, es una decisión de Discourse.
Revisa el repositorio de Docker; no ofrecen paquetes RHEL, solo CentOS.
Podman está diseñado para ser 100% compatible con Docker, así que en realidad no estoy seguro de que necesitemos hacer nada.
Quizás, edites un poco el documento de instalación para añadir una referencia a la instalación de Podman (tal vez solo digas que es compatible y que debes reemplazar el comando docker por podman en algún lugar al principio), ¿así la gente no se preguntará si es compatible o no?
No vamos a tomar ninguna postura explícita hasta que probemos esto.
Que yo sepa, nadie en toda la historia de la humanidad ha intentado instalar Discourse usando Podman.
Creo que hay cierta confusión aquí. Conocemos a Podman y varias personas del equipo están apostando por su éxito, ya que eso sería beneficioso para todo el ecosistema de FOSS, pero:
No está soportado.
Nuestro hosting utiliza Ubuntu / Debian. Por lo tanto, en este momento no tenemos clientes ejecutando RHEL.
Incluso si se demuestra que funciona tal cual, tendría mucha precaución con cualquier noción de soporte.
A menos que Docker abandone CentOS/RHEL, esto es innecesario, e incluso si eso llegara a ocurrir, Discourse/Docker no sería la primera aplicación que tenga requisitos a nivel de distribución.
Lo que más me frustra aquí es la cantidad de especulación frente a la cantidad de trabajo realizado.
Si hubieras comenzado con esto, mi reacción habría sido diferente:
He utilizado la instalación oficial de Discourse con Docker durante los últimos 30 días en Podman; aquí están los detalles que me molestaron y lo que me encantó de la configuración.
Toda la premisa aquí es: hagan el trabajo por nosotros, no estoy dispuesto a experimentar, no estoy dispuesto a realizar ningún trabajo; esto será un gran problema para ti y para la comunidad.
Me desagrada mucho esto.
Eso resume muy bien mi respuesta: estamos trabajando con tecnologías predecibles, no hay necesidad ni espacio para proclamaciones apocalípticas.
Tampoco soy muy partidario de las discusiones interminables y probablemente debería haberme mordido la lengua en lugar de involucrarme.
Con esa afirmación, asumía que tenías que hacer algún trabajo para que funcionara, pero si se supone que debe ser 100% compatible y solo se trata de reemplazar el comando, eso sería genial.
Estaba sugiriendo que podrías guiar a quienes se perdieron usando podman en lugar de Docker.
No conozco exactamente tu modelo de desarrollo, pero entiendo que es impulsado por la comunidad y que se espera que los usuarios trabajen primero.
Lo intenté durante media hora más o menos. Podman es compatible a nivel de comandos, pero no a nivel de salida, por lo que launcher se confunde al intentar analizar la salida. (No es difícil distinguirlos: docker --version responde con podman version 1.0.5, así que esto no es un obstáculo grave.)
No existe el dispositivo de red docker0. El controlador de almacenamiento overlay predeterminado en Podman es básicamente la implementación overlay2 y está aliasado a él, pero la salida no dice overlay2 y la salida del comando docker info es ligeramente diferente. Usé --skip-prereqs para omitir las comprobaciones. Los directorios compartidos no se crearon automáticamente; no investigué por qué. Ejecuté mkdir -p /var/discourse/shared/standalone/log/var-log para seguir avanzando. A continuación, aparecieron problemas de permisos debido a que SELinux estaba en modo de aplicación pero no configurado para /var/discourse.
Si montas un volumen en un directorio dentro de un contenedor y agregas :z o :Z, los motores de contenedores reetiquetan el contenido bajo los volúmenes como
container_file_t.
La documentación de podman build indica:
La opción
zle indica a Podman que dos contenedores comparten el contenido del volumen. Como resultado, Podman etiqueta el contenido con una etiqueta de contenido compartido. Las etiquetas de volumen compartido permiten que todos los contenedores lean y escriban contenido. La opciónZle indica a Podman que etiquete el contenido con una etiqueta privada no compartida. Solo el contenedor actual puede usar un volumen privado.
Decidí ejecutar Cambié los setenforce 0 temporalmente en esta instalación desechable y volver a eso más tarde, quizás.volumes para usar la opción en minúsculas :z de esta manera:
volumes:
- volume:
host: /var/discourse/shared/standalone
guest: /shared:z
- volume:
host: /var/discourse/shared/standalone/log/var-log
guest: /var/log:z
Con esas pequeñas modificaciones, logré que Discourse se iniciara. Redis está molesto porque las páginas grandes transparentes están habilitadas en el kernel y sugiere desactivarlas, así como cambiar la configuración de sobrecompromiso de memoria. ¡Probablemente muchos otros mensajes de depuración útiles pasaron desapercibidos entre los megabytes de salida del registro!
./launcher start app
...
--restart option is not supported.
Use systemd unit files for restarting containers
Modifiqué el script para que no usara --restart y descubrí la necesidad de --skip-prereqs también en el modo start, lo que finalmente me llevó a intentar docker run, momento en el cual:
./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
Por lo tanto, definitivamente no funciona directamente fuera de la caja, y no sé cuánto trabajo sería necesario para ajustar launcher para que funcione con Docker o Podman. Gestionar el manejo de los requisitos previos sería “simplemente funcionar” y probablemente no sería muy difícil con una comprobación inicial de Podman, pero no sé hasta qué punto las suposiciones sobre la configuración de red se extienden en la configuración de la pila, y parece que este modo de red simplemente no es compatible con Podman.
Basado en esa preocupación, planeo no realizar el trabajo para hacer que launcher funcione bajo Podman. Solo estoy informando sobre el resultado de un experimento rápido inicial.
Dicho esto, probablemente no sea mucho trabajo para alguien que conozca mejor la pila. Todo mi trabajo de desarrollo esta primavera lo realicé en una instalación manual de desarrollo en Fedora 29 con ajustes triviales como usar dnf en lugar de apt-get y algunas traducciones menores de nombres de paquetes, sin usar Docker ni Podman en absoluto. Espero que alguien que conozca bien Podman, así como la administración normal de toda la pila tecnológica de Discourse, probablemente considere que es una cantidad moderada de trabajo relativamente fácil. Si supiera exactamente todo el trabajo que implica, tendría una mejor idea de si sería el tipo de trabajo que probablemente “se pudra” y requiera mantenimiento continuo o no. Pero… no lo sé. 