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 . .
O Docker foi substituído pelo Podman no RHEL 8.
Parece natural começar a oferecer suporte à instalação do Podman para não perder clientes do RHEL (e do CentOS).
Simplesmente: ‘alias docker=podman’
mostrando alta interoperabilidade em relação ao Docker.
O ROI parece bom?
Como a instalação recomendada não usa o pacote docker fornecido pelo repositório, não tenho certeza se isso é uma consideração em qualquer caso.
Até que o próprio Docker deixe de oferecer suporte a uma distribuição, estamos bem.
Não sei exatamente o quanto de esforço é necessário para dar suporte ao Podman, mas achei que clientes corporativos não gostam de um nível de suporte de “provavelmente bem”.
Se você estiver executando o RHEL (CentOS) 8+, terá que instalar o Docker a partir de um repositório externo, possivelmente em paralelo ao Podman, e esse caso de uso não será suportado pela Red Hat. Ou simplesmente use o Podman para instalar a imagem do Docker, mas isso não é suportado pelo Discourse.
Espero que isso receba suporte oficial.
Acredito que isso ganhará mais atenção com o lançamento do CentOS 8.
O Docker já é compatível com o CentOS 8 e, por extensão, com o RHEL 8. Não tenho conhecimento de nenhum cenário em que você executaria os dois lado a lado; estou perdendo algo?
Provavelmente é impreciso dizer que o Docker foi substituído pelo Podman; na verdade, o que acontece é que o Podman agora vem como padrão. Afinal, quem usa a versão do Docker que é fornecida com a distribuição?
A responsabilidade pelo suporte sempre foi do Docker, não da Red Hat. Como mencionado acima, a recomendação sempre foi usar o pacote do Docker, e não aquele que é fornecido com a distribuição.
Na verdade, é o contrário, mas a página vinculada da Red Hat afirma:
O pacote
dockernão é distribuído nem suportado pela Red Hat para o Red Hat Enterprise Linux (RHEL) 8.
O motor de contêineres
podmansubstituiu odockercomo o runtime de contêineres preferido, mantido e suportado para sistemas Red Hat Enterprise Linux 8.
Não interpreto isso como o Docker sendo “suportado” pela Red Hat.
Se isso significa abandonar o suporte aos clientes do RHEL, essa é uma decisão da Discourse.
Verifique o repositório do Docker; eles não oferecem pacotes RHEL, apenas CentOS.
O Podman tem como objetivo ser 100% compatível com o Docker, então realmente não tenho certeza de que precisaremos fazer qualquer coisa.
Talvez, edite um pouco o documento de instalação para adicionar uma referência à instalação do Podman (talvez apenas diga que é suportado e que você deve substituir o comando docker por podman em algum lugar no início), para que as pessoas não fiquem se perguntando se é suportado ou não?
Não vamos tomar nenhuma posição explícita até testarmos isso.
Até onde eu sei, ninguém na história da humanidade já tentou instalar o Discourse usando o Podman.
Acho que há alguma confusão aqui. Conhecemos o Podman, e várias pessoas da equipe torcem para que ele tenha sucesso, pois isso será bom para todo o ecossistema de FOSS, mas:
Não é suportado.
Nosso hospedamento usa Ubuntu/Debian. Portanto, no momento, não temos clientes executando RHEL.
Mesmo que funcione conforme está, eu teria muita cautela em relação a qualquer ideia de suporte.
A menos que o Docker abandone o CentOS/RHEL, isso é desnecessário, e mesmo que isso acontecesse, o Discourse/Docker não seria o primeiro aplicativo a ter requisitos no nível da distribuição.
O que mais me frustra aqui é a quantidade de especulação em comparação com o trabalho realizado.
Se você tivesse começado com isso, minha reação seria diferente:
Usei a instalação oficial do Discourse via Docker nos últimos 30 dias no Podman. Aqui estão os pequenos problemas que encontrei e o que adorei na configuração!
A premissa geral aqui é: faça o trabalho por nós. Eu não estou disposto a experimentar, não estou disposto a fazer qualquer trabalho. Isso será um grande problema para você e para a comunidade.
Eu detesto isso muito.
Isso resume muito bem minha resposta: estamos lidando com tecnologias previsíveis aqui, não há necessidade nem espaço para proclamações catastróficas.
Também não sou muito fã desse vai-e-vem e provavelmente deveria ter me calado em vez de me envolver.
Com essa afirmação, eu estava assumindo que você precisaria fazer algum trabalho para fazê-lo funcionar, mas se deveria ser 100% compatível e se trata apenas de substituir o comando, isso seria ótimo.
Eu estava sugerindo que você pudesse orientar aqueles que se perderam ao usar o Podman em vez do Docker.
Não sei exatamente qual é o seu modelo de desenvolvimento, mas imagino que seja um modelo impulsionado pela comunidade, no qual os usuários são os primeiros a trabalhar.
Eu tentei fazer isso por cerca de meia hora. O Podman é compatível em termos de comandos, mas não em termos de saída, então o launcher fica confuso ao tentar analisar a saída. (Não é difícil diferenciá-los: docker --version responde com podman version 1.0.5, então isso não é um impedimento sério.)
Não há dispositivo de rede docker0. O driver de armazenamento overlay padrão no Podman é basicamente a implementação overlay2 e está aliasado a ele, mas a saída não diz overlay2 e a saída do comando docker info é ligeiramente diferente. Usei --skip-prereqs para contornar as verificações. Os diretórios compartilhados não foram criados automaticamente; não investiguei o motivo. Executei mkdir -p /var/discourse/shared/standalone/log/var-log para continuar. Em seguida, vi problemas de permissão devido ao SELinux em modo de imposição, mas não configurado para /var/discourse.
Se você montar um diretório como volume em um contêiner e adicionar :z ou :Z, os motores de contêiner rotularão o conteúdo sob os volumes para
container_file_t.
A documentação de build do Podman diz:
A opção
zinforma ao Podman que dois contêineres compartilham o conteúdo do volume. Como resultado, o Podman rotula o conteúdo com uma etiqueta de conteúdo compartilhado. Etiquetas de volume compartilhado permitem que todos os contêineres leiam/gravem o conteúdo. A opçãoZinforma ao Podman para rotular o conteúdo com uma etiqueta privada não compartilhada. Apenas o contêiner atual pode usar um volume privado.
Decidi executar Alterei os setenforce 0 por enquanto nesta instalação descartável e voltar a isso mais tarde, talvez.volumes para usar o :z em minúsculo, assim:
volumes:
- volume:
host: /var/discourse/shared/standalone
guest: /shared:z
- volume:
host: /var/discourse/shared/standalone/log/var-log
guest: /var/log:z
Com essas pequenas modificações, consegui inicializar o Discourse. O Redis está insatisfeito com o fato de as páginas grandes transparentes (transparent huge pages) serem suportadas no kernel e sugere desativá-las, além de alterar as configurações de comprometimento de memória. Provavelmente, muitas outras mensagens úteis de depuração passaram despercebidas por mim entre os megabytes de saída de log!
./launcher start app
...
--restart option is not supported.
Use systemd unit files for restarting containers
Hackeiei o script para não usar --restart e descobri a necessidade de --skip-prereqs também no modo start, o que finalmente me levou a tentar docker run, momento em que:
./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
Portanto, definitivamente não funciona fora da caixa, e não sei quanto trabalho seria necessário para ajustar o launcher para funcionar com Docker ou Podman. Lidar com o gerenciamento de pré-requisitos seria “apenas funcionar” e provavelmente não seria muito difícil com uma verificação inicial para o Podman, mas não sei o quão profundas são as suposições sobre a configuração de rede na pilha de configuração, e parece que esse modo de rede simplesmente não é suportado pelo Podman.
Com base nessa preocupação, estou planejando não fazer o trabalho para fazer o launcher funcionar sob o Podman. Estou apenas relatando o resultado de um experimento rápido inicial.
Dito isso, provavelmente não é um trabalho difícil para alguém que conhece melhor a pilha. Fiz todo o meu trabalho de desenvolvimento nesta primavera em uma instalação manual de desenvolvimento no Fedora 29 com ajustes triviais, como usar dnf em vez de apt-get e algumas traduções menores de nomes de pacotes, sem usar Docker ou Podman de forma alguma. Espero que alguém que conheça bem o Podman, assim como a administração normal de toda a pilha de tecnologia do Discourse, provavelmente considere isso uma quantidade moderada de trabalho relativamente fácil. Se eu soubesse exatamente todo o trabalho envolvido, teria uma melhor noção de se seria o tipo de trabalho que provavelmente “apodreceria” e precisaria de manutenção contínua ou não. Mas… eu não sei. 