Web-only - preciso de uma imagem separada para cada container?

Olá pessoal.

Algo trivial que pensei, mas não consegui encontrar uma resposta clara, por isso estou perguntando aqui.

Com contêineres apenas para web - como criar e usar uma imagem que esses contêineres compartilhariam/deveriam compartilhar?
Isso certamente faz sentido - esse contêiner “leve” de discurso com tudo fora (particularmente em um orçamento de homem pobre em VMs XS) cada um com sua própria imagem docker… não faz sentido na minha mente, certo?

Espero que eu esteja perdendo alguma documentação/tutorial “óbvio” sobre um cenário tão simples (e comum/popular?).
Muito obrigado.

Sim, você pode usar um único postgres para vários sites Discourse, mas a menos que você vá usar multisite (veja Multisite configuration with Docker), cada um precisa do seu próprio redis.

Você precisaria criar outro banco de dados e configurar o segundo contêiner web para usá-lo em vez do chamado Discourse.

1 curtida

Obrigado por dedicar tempo, por tentar, no entanto… não é o que estou perguntando.
Vou tentar novamente, me perdoe se falhar… de novo
Quando eu:

  • $ ./launcher bootstrap a.forum.xyz # ou similar
    então o processo cria:
- $ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
local_discourse/a.forum.xyz latest d7a7b6509811 2 horas atrás 4.19GB

e isso acontece com cada launcher executado para um fórum diferente/novo.
Então acabo com várias imagens do mesmo discourse - sou só eu e o resultado deveria ser diferente?
Se não sou só eu e esse é o resultado desejado e esperado, então, com certeza não sou um desenvolvedor e não tenho conhecimento dos processos envolvidos - é bastante, realmente, extremamente desperdiçador (talvez particularmente com contêineres apenas para web) - não?

O que eu esperava - quando tentei o discourse pela primeira vez - era, praticamente, o que todo o resto, qualquer outro software dockerizado faz, a saber - obter essa única imagem e executar muitos contêineres a partir dela. O discourse não é capaz de fazer isso?

Se você quiser usar o mesmo contêiner com configurações diferentes para sites diferentes, você pode

./launcher start-cmd

Para obter os parâmetros para iniciá-lo. Você pode alterá-los para os outros sites que deseja executar. Você ainda precisará de um banco de dados e um redis para cada um.

2 curtidas

Ele contém cópias exclusivas dos temas do seu site, que incluem JS, CSS e outros tipos de ativos.

Também a combinação exclusiva de seus plugins e suas dependências.

É uma longa história, mas o Discourse e a maioria das ferramentas são anteriores a coisas como o Docker compose.

Nós enviamos um contêiner “gordo” que contém tudo, e há várias trocas para isso. Como uma delas, o contêiner com estado permite recursos como nosso atualizador de um clique baseado na web.

Vindo de uma abordagem mais moderna para como os contêineres são geralmente implantados hoje, é de fato uma grande discrepância. Isso é discutido longamente em O Discourse pode enviar imagens Docker frequentes que não precisam ser inicializadas? e vale a pena ler.

No final, nosso status quo atual funciona bem para pessoas que são apenas ligeiramente inclinadas tecnicamente, que podem copiar e colar comandos em uma sessão SSH e configurar DNS, mas não são mestres de contêineres Linux.

E para os mestres de contêineres Linux por aí, podemos dizer a eles que podem pegar essa imagem inicializada, enviá-la para um registro e reutilizá-la em seu software de orquestração de contêineres favorito.

Pessoas entre as duas personas acima, no entanto, sentem a dor mais intensamente.

2 curtidas

Eu não encontrei uma explicação sobre como usar um Redis para várias instâncias nesse guia, mas isso parece funcionar de imediato quando a configuração multisite está disponível?

Eu entendi corretamente?
a) Multisite executa a mesma imagem docker para vários fóruns, usando um servidor redis e um servidor postgres.
b) Usar um redis para várias instâncias do discourse (usando a mesma imagem ou não) não é possível, pois sem ativar o multisite, nenhum prefixo será adicionado às chaves do redis.
c) Não há outra maneira de impor um prefixo de chave redis.
d) Impor prefixos de chave redis diferentes para imagens do discourse diferentes permitiria o uso de um servidor redis.
e) O suporte geral para impor um prefixo redis geral exigiria várias alterações principais.