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: Install Discourse on Ubuntu or Debian 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 has been superseded by Podman for RHEL 8.
It sounds natural to start supporting Podman installation not to lose RHEL (and CentOS) customers.
From the Podman official site,
Simply put: ‘alias docker=podman’
showing high interoperability against docker.
ROI sounds good?
As the recommended install doesn’t use the repo-supplied docker package I’m not sure this is a consideration either way.
Until docker themselves drop support for a distro we’re fine.
I don’t exactly know how much effort it needs to support Podman, but I thought enterprise customers don’t like ‘probably fine’ support level.
If running RHEL (CentOS) 8+, you’d have to install Docker from an external repo, possibly side by side to Podman and that use case won’t be supported by RedHat, or simply use Podman to install the docker image but that isn’t supported by Discourse.
Hopefully it gets officially supported.
I reckon this gets more attention as CentOS 8 gets released.
Docker is already supported on CentOS 8 and by extension RHEL 8. I’m not aware of any scenarios where you would run the two side by side, am I missing something?
It’s probably inaccurate to say that docker has been superseded by podman, only that podman now ships by default. After all, who uses the version of docker which ships with the distro?
The onus of support has always been on docker, not Red Hat. As referenced above the recommendation has always been to use the docker package, not that which ships in the distro.
It’s the other way around but the linked RedHat page says,
The
dockerpackage is not shipped or supported by Red Hat for Red Hat Enterprise Linux (RHEL) 8.
The
podmancontainer engine replaceddockeras the preferred, maintained, and supported container runtime of choice for Red Hat Enterprise Linux 8 systems.
I don’t read this as Docker being ‘supported’ by RedHat.
If it means, dropping support for RHEL customers, that’s Discourse’s choice.
Check the docker repro, they don’t offer RHEL packages, only CentOS.
Podman is meant to be 100% compatible with docker, so really I am not sure we will need to do anything
Perhaps, edit the installation document a bit to add a reference to Podman installation (maybe just say it’s supported and you’re supposed to replace the command docker as podman somewhere at the beginning), so people don’t wonder if it’s supported or not?
We are not going to take any explicit stand till we test this out
As far as I know, nobody ever in the history of humanity tried installing discourse using podman
I think there is some confusion here. We know about Podman, and several people at the team are rooting for it to become successful because that will be good for the whole FOSS ecosystem, but:
It is not supported.
Our hosting uses Ubuntu / Debian. So we don’t have customers running RHEL at the moment.
Even if it’s proven working as-is I would be very wary of any notion of support.
Unless Docker abandons Centos/RHEL it’s unnecessary, and even if that were to happen Discourse/Docker wouldn’t be the first app which had requirements at the distro level.
What I find most frustrating here is the amount of speculation vs the amount of work done
If you started with this my reaction would be different
I have used the official Discourse Docker install for the last 30 days on podman, here are the nits I had, here is what I loved about the setup!
The whole premise here is, do work for us, I am unwilling to experiment, I am unwilling to do any work, this is going to be a big problem for you and the community
I dislike this a lot
That crystallises my response pretty well, we’re working with predictable technologies here, there’s no need or room for doomsday proclamations.
I’m not a huge fan of the back-and-forth either and should have probably bitten my tongue rather than engage.
With this statement, I was assuming you had to do some work to get it to work but if it’s supposed to be 100% compatible and is just a matter of replacing the command, that would be nice.
I was suggesting that you could guide those who got lost using podman instead of Docker.
I don’t exactly know your development model but I take it it’s a community driven one that users are supposed to work first.
약 30분 정도 이 작업을 시도해 보았습니다. Podman은 명령어 호환성은 있지만 출력 형식 호환성은 없기 때문에, launcher가 출력을 파싱하려고 할 때 혼란을 겪습니다. (두 가지를 구별하는 것은 어렵지 않습니다. docker --version을 실행하면 podman version 1.0.5라고 응답하므로 이는 심각한 장애물은 아닙니다.)
docker0 네트워크 장치가 없습니다. Podman의 기본 overlay 스토리지 드라이버는 기본적으로 overlay2 구현이며 이에 별칭으로 사용되지만, 출력에는 overlay2라고 표시되지 않고 docker info 명령의 출력도 약간 다릅니다. 저는 검사를 우회하기 위해 --skip-prereqs를 사용했습니다. 공유 디렉터리는 자동으로 생성되지 않았으며, 그 이유는 조사하지 않았습니다. 계속 진행하기 위해 mkdir -p /var/discourse/shared/standalone/log/var-log를 실행했습니다. 다음으로, SELinux가 강제 모드(enforcing)로 설정되어 있지만 /var/discourse에 대해 구성되지 않은 상태에서 권한 문제를 발견했습니다.
컨테이너에 디렉터리를 볼륨 마운트하고 :z 또는 :Z를 추가하면 컨테이너 엔진이 볼륨 하위의 콘텐츠를
container_file_t로 재레이블링합니다.
podman build 문서에는 다음과 같이 나와 있습니다:
z옵션은 두 컨테이너가 볼륨 콘텐츠를 공유한다는 것을 Podman에 알립니다. 결과적으로 Podman은 콘텐츠에 공유 콘텐츠 라벨을 붙입니다. 공유 볼륨 라벨을 사용하면 모든 컨테이너가 콘텐츠를 읽기/쓰기할 수 있습니다.Z옵션은 콘텐츠에 비공개(비공유) 라벨을 붙이도록 Podman에 지시합니다. 현재 컨테이너만 비공개 볼륨을 사용할 수 있습니다.
이 일회용 설치 환경에서는 나중에 다시 돌아올지 모르겠지만, 일단 소문자 setenforce 0으로 설정하기로 결정했습니다.:z를 사용하도록 volumes을 다음과 같이 변경했습니다:
volumes:
- volume:
host: /var/discourse/shared/standalone
guest: /shared:z
- volume:
host: /var/discourse/shared/standalone/log/var-log
guest: /var/log:z
이러한 작은 수정 사항을 통해 discourse의 부팅을 성공시켰습니다. Redis는 커널에서 투명 거대 페이지(transparent huge pages)가 지원되는 것에 대해 불만을 토로하며, 이를 비활성화하고 메모리 오버커밋 설정을 변경할 것을 제안합니다. 아마도 메가바이트 단위의 로그 출력 속에서 많은 다른 유용한 디버그 메시지가 지나갔을 것입니다!
./launcher start app
...
--restart 옵션은 지원되지 않습니다.
컨테이너 재시작에는 systemd 유닛 파일을 사용하십시오.
--restart를 사용하지 않도록 스크립트를 수정했고, start 모드에서도 --skip-prereqs가 필요하다는 것을 발견했으며, 이를 통해 마침내 docker run을 시도하게 되었습니다. 이때 다음과 같은 메시지가 나타났습니다:
./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 옵션은 현재 지원되지 않습니다.
따라서 기본적으로 작동하지 않는다는 것은 분명합니다. docker 또는 podman 중 하나와 함께 작동하도록 launcher를 수정하는 데 얼마나 많은 작업이 필요할지 저는 알지 못합니다. 사전 요구 사항 처리는 "그저 작동(just work)"할 것이며 podman에 대한 사전 체크를 추가하는 것은 아마도 너무 어렵지 않을 것입니다. 하지만 네트워크 설정에 대한 가정이 스택 하단의 구성까지 얼마나 깊이 관여하는지 모르겠고, 이 네트워크 모드는 podman에서 단순히 지원되지 않는 것으로 보입니다.
이러한 우려를 바탕으로, launcher가 podman에서 작동하도록 만드는 작업을 수행하지 않을 계획입니다. 저는 초기 빠른 실험의 결과만을 보고하는 것입니다.
그러나 더 잘 아는 사람에게 이는 어려운 작업이 아닐 것입니다. 저는 올봄에 Fedora 29에서 수동 개발 설치로 모든 개발 작업을 수행했으며, apt-get 대신 dnf를 사용하고 일부 패키지 이름 번역과 같은 사소한 조정만 했을 뿐, docker나 podman을 전혀 사용하지 않았습니다. podman을 잘 알고 discourse 기술 스택 전체의 일반 관리도 잘 아는 사람은 이를 상대적으로 쉬운 중등도 수준의 작업으로 판단할 가능성이 높습니다. 모든 작업 내용을 알았다면, 그것이 "부패(rot)"하여 지속적인 유지보수가 필요한 유형의 작업인지 아닌지에 대해 더 나은 감을 가질 수 있었을 것입니다. 하지만… 저는 모릅니다. 