Um servidor para 2 comunidades Discourse?

É melhor que DigitalOcean e similares, então sim, é uma coisa boa.

Foi aceitável, mas eu também destaquei as restrições, os sites tinham tráfego e atividade muito baixos, se você espera atividade significativa nesses sites, você precisa de mais recursos, a utilização de recursos do Discourse aumenta à medida que você recebe mais atividades.

Isso realmente se resume a se você tem a necessidade de isolar alguns sites dos outros ou não. A hospedagem comercial do Discourse geralmente são apenas grandes clusters de múltiplos sites com algum tempero especial por cima para acomodar o sistema de faturamento deles, etc.

Bem, a menos que você tenha alguma configuração avançada implementada, todos os sites compartilharão as credenciais do site pai. Ou seja, sem alguma configuração avançada implementada, se o site pai estiver configurado para noreply@example.com como seu e-mail de noreply. Ele será usado pelos sites filhos também. Você precisará de alguma configuração adicional se quiser e-mails exclusivos por site.

Depende muito do que você classifica como “problemas”

1 curtida

Um único app.yml para multisite é viável, mas eu recomendaria mudar para uma instalação de 2 contêineres (web e dados separados) para um multisite.

Você terá que perseverar através de alguns desafios, alterar os caminhos nos arquivos yml e então iniciá-los. Essencialmente, como se /var/discourse-a tivesse sua própria configuração e /var/discourse-b tivesse a sua.

Apenas para constar, estes são conceitos bem tecnicamente envolvidos. Você realmente precisa de alguma experiência com o Discourse e seu funcionamento interno para conseguir hospedar multisite. Se você se sentir inseguro com isso, talvez considere uma hospedagem gerenciada para o Discourse ou peça para alguém configurá-lo profissionalmente para você. Isso reduzirá significativamente sua dor de cabeça com o tempo. Considere postar em Marketplace se você tiver um orçamento.

3 curtidas

Sim, mas é por isso que eu estava dizendo que, com o tempo, eu sempre posso fazer um upgrade para um plano superior com mais recursos. Nunca foi meu plano ficar nesse… plano… por muito tempo. Estou apenas tentando evitar custos desnecessários ao testar as águas, sabe?

Você pode apontar alguns motivos pelos quais eu gostaria que eles fossem separados, além dos recursos do servidor? No momento, não vejo um bom motivo para tê-los em servidores separados, mas estou sempre disposto a aprender algumas perspectivas diferentes sobre coisas que ainda não sei.

Esse é um ponto muito interessante, que eu não sabia. Então, parece que é realmente algo que tem sido feito e funciona. Bom saber.

O que você quer dizer com site pai? Cada instalação não seria independente? Qual seria considerado o pai?

Estou um pouco confuso, porque quando olho para o arquivo app.yaml, há uma parte dedicada ao e-mail e às credenciais do Brevo. Você disse que eu posso seguir o caminho de ter arquivos app.yaml individuais para cada comunidade. Então, isso não significaria que cada comunidade teria suas próprias credenciais Brevo, incluindo o e-mail de notificação?

Coisas que me impedirão de fazer backup corretamente, ou e-mails de notificação que não estão sendo enviados corretamente, coisas assim. Novamente, como um não especialista, e ainda novo no Discourse, há coisas que outras pessoas podem ver como um problema, mas eu ainda não vejo.

Sim, era isso que eu estava pensando. A única coisa compartilhada seria o servidor em si. Todo o resto funcionaria como uma instalação separada, daí a pergunta sobre o e-mail, acima.

Acho que os passos mais desafiadores para mim já foram dados, que foi mergulhar fundo na instalação do Discourse alguns meses atrás. Eu não tinha conhecimento algum sobre isso. Eu nem sabia o que “docker” significava. Neste ponto, tenho uma perspectiva muito mais clara, embora ainda me considere um “usuário básico do Discourse” quando se trata de auto-hospedagem. E com a ajuda desta comunidade e do ChatGPT/Claude, consegui aprender um pouco mais e fazer anotações sobre como as coisas funcionam e são instaladas. Eu lido bem com desafios, e sejamos honestos: isso é realmente apenas instalar software. Não é como se eu estivesse construindo uma bomba nuclear :laughing: Se algo der errado, apague tudo, volte para uma única instalação por servidor. Tudo certo :slight_smile:

Como mencionei, eu já tenho minha própria comunidade instalada, então acredito que a parte mais difícil já passou. Eu sou bom em seguir instruções e fazer perguntas, então, à medida que tento as coisas, posso sempre pausar e pesquisar, fazer anotações, etc.

Meu objetivo agora é mais entender a mecânica disso, os prós e contras, o que é possível e o que não é, para que eu possa tomar boas decisões das quais não me arrependa mais tarde e que me exijam gastar muito tempo consertando as coisas, sabe?

Então, todas essas informações que vocês estão compartilhando hoje são super valiosas, porque me dão uma boa ideia do que considerar. Especialmente quando você mencionou que a hospedagem gerenciada oferecida pela equipe do Discourse é um multisite. Isso realmente me fez ver que é possível. Talvez exija mais algumas etapas, mas tudo pode ser feito.

Agradeço muito o seu feedback :raising_hands:

3 curtidas

Você primeiro terá que decidir se deseja um único multisite ou um único servidor hospedando vários sites autônomos. Vou adiar responder a qualquer coisa que você perguntou acima antes que você decida entre um ou outro. Há muito a entender, apenas instalar o Discourse em uma máquina virtual não o torna automaticamente elegível para a dor de cabeça do multisite, por exemplo, levei 3 anos para aperfeiçoar a experiência de instalação do multisite para mim. É verdade que a documentação não era muito clara sobre muitas coisas e tive que descobrir muitas coisas para acertar. E estou usando o Discourse desde 2016-17 (quase 9-10 anos neste momento)

Então, por favor, dê um passo atrás e repense o que você está tentando alcançar e então poderemos nos concentrar em alcançar isso.

Mais uma vez, esteja ciente de que instalar o Discourse não é o maior obstáculo, ainda há muito a aprender e mesmo após 9 anos de uso e implantação do Discourse, ainda me considero aprendendo coisas novas todos os dias.

2 curtidas

Este sempre foi o meu objetivo. Eu não vejo nenhuma vantagem, para o que estou construindo, em ter um único multisite. Meu objetivo é apenas economizar custos usando um servidor com instalações independentes.

E eu entendo o que você quer dizer sobre as coisas serem complexas. É por isso que eu estava dizendo que, embora eu tenha conseguido instalar e agora consiga entender alguns dos conceitos, eu me considero um usuário básico quando se trata de instalação.

Depois de fazer música por quase 35 anos, eu ainda estou aprendendo coisas novas todos os dias, então tudo bem. Eu me dou bem em aprender todos os dias, e nunca espero não aprender :slight_smile: É por isso que estou aqui nesta comunidade. Para aprender coisas novas com vocês.

3 curtidas

Portanto, se você deseja apenas ter vários sites do Discourse no mesmo servidor, sem que eles compartilhem o código ou o contêiner, aqui está o que você pode tentar:

Leia o app.yml com atenção e entenda a seção de montagens (mounts). Você precisará de montagens diferentes e previsíveis para cada site; no mínimo, você terá que editar esses diretórios manualmente.

A única vez que fiz isso (e acho que fiz da maneira mais não ergonômica) foi clonar o código do Discourse em dois diretórios diferentes, o que pode não ser necessário, mas não tentei, então não tenho certeza.

Em cada diretório, executei ./discourse-setup com algumas sinalizações para ignorar a verificação de conectividade e a reconstrução. Isso me deu os arquivos app.yml de base. O próximo passo foi editar os dois arquivos manualmente; alterei as montagens, comentei a seção que expunha as portas e adicionei o template web.socketed para deixar meu nginx externo cuidar do ssl e dos encaminhamentos internos.

Então, foi tão simples quanto executar ./launcher rebuild app em cada diretório.

Honestamente, eu não era um grande fã dessa configuração, então desisti depois de alguns meses brincando com ela. Mas isso mostra que o que você está tentando fazer é de fato possível, só que você tem algumas coisas para descobrir.

Você também pode querer diminuir o número de workers (trabalhadores) etc. para dar a todos os sites uma chance justa de usar os recursos, mas isso é um experimento mental para quando você tiver o trabalho inicial estabelecido.

3 curtidas

Obrigado pelas informações detalhadas!
Ainda estou considerando a melhor opção e, mesmo que acabe usando esta opção, ainda preciso resolver algumas coisas.

[quote=“itsbhanusharma, post:30, topic:392692”]seção de montagens
[/quote]
Você quer dizer isto? Porque quando pesquisei pela palavra “mount” (montagem), nada apareceu, mas presumi que fosse algo relacionado aos volumes?

Se for isso, então é lá que eu crio caminhos diferentes como
var/discourse/shared/website1
var/discourse/shared/website2
etc
?

[quote=“itsbhanusharma, post:30, topic:392692”]Eu clonei o código do discourse em dois diretórios diferentes
[/quote]
Então, basicamente, você realizou uma instalação normal em um dos caminhos, por exemplo:
var/discourse/shared/website1
depois copiou esses arquivos para
var/discourse/shared/website2
?

Se for esse o caso, por que executar ./discourse-setup? Isso não sobrescreveria os arquivos?
Não seria melhor apenas realizar instalações normais em ambos os caminhos? Como duas instalações separadas completas? Para alguém como eu, especialmente quando você menciona as “flags” e tudo mais, isso são mais coisas com as quais eu teria que me preocupar, e talvez uma instalação normal fosse melhor, e depois editar manualmente os arquivos app.yaml em cada caminho?

EDIT: Deixa pra lá. Pesquisei um pouco e entendi o que você quer dizer com “clonar” neste contexto. Você clonou os arquivos do repositório. Eu pensei que você estava dizendo que instalou tudo em um “caminho” e depois copiou esses arquivos para outro “caminho”.

Você já tem uma instância do Discourse em execução? Você está neste fórum há algum tempo. Você está tentando configurar uma segunda instância em um servidor que já tem uma instância em execução?

A melhor maneira de aprender é tentar. Configure um VPS barato e tente. Se você ainda não estiver executando uma instância, apenas configure uma instalação regular auto-hospedada com suporte e aprenda a se virar. Você não terá visitantes reais e não terá motivo para salvar nada. Você pode simplesmente excluir a instalação e tentar repetidamente até dominar. Se você configurar duas ou até três instâncias rodando em um único VPS e todas estiverem recebendo tráfego (virtualmente) zero, eu apostaria que o VPS mais barato que existe provavelmente as executaria.

Se você conseguir fazer funcionar, poste um tutorial para o resto de nós aprender!

1 curtida

Sim, eu tenho. Eu quero instalar instâncias adicionais.

Como esta instalação ainda é nova e nenhum usuário se inscreveu, não há problemas com isso. Eu farei um backup primeiro e tentarei tudo neste servidor. Ainda não há risco real.

Com certeza farei isso. Espero que possa ajudar outros.

@itsbhanusharma Eu estava fazendo mais algumas perguntas tanto para o ChatGPT quanto para o Claude, porque eu estava pensando em renomear o caminho da instância atual de “discourse” para o nome do site, como “nome-do-site”, e ambos apontaram algumas coisas boas. Uma delas é que, como cada instalação requer 2GB de RAM, se eu instalar 5 no total, por exemplo, eu precisaria de 10GB, certo?

Se for esse o caso, então este plano provavelmente seria melhor:

CX43Intel ® / AMD
8 VCPU
16 GB RAM
160 GB NVMe SSD
20 TB Traffic incl.
€ 9.49 / mês

Ainda um preço muito bom para 5 instâncias, em vez de $5 x 5 = $25.

Quais são seus pensamentos sobre a necessidade de ter 2GB por instância? Isso é preciso neste cenário? Você acha que este plano que compartilhei seria adequado?

Por favor, não!

Tenho vários incidentes de clientes causando mais mal do que bem aos seus sites de discurso porque seguiram cegamente os conselhos do ChatGPT.

Isso é um pouco mais complexo e o tipo de coisa que não é tão direta quanto somar 2+2. E esta é em grande parte a razão pela qual a rota multissite é uma ideia melhor.

Mais uma vez, eu diria para parar, fazer uma pausa, recuar um pouco e repensar quais são suas necessidades. Existem bons recursos disponíveis aqui no meta e o único bot de IA em que eu confiaria para conselhos sobre Discourse é https://ask.discourse.org

5 curtidas

Concordo, mas verifique as informações lendo as fontes que o bot fornece. Dessa forma, você também garantirá que ele não inventou os links (acontece!).

6 curtidas

Isso é um pouco extremo… Ninguém está seguindo cegamente o conselho do ChatGPT (pelo menos eu não), é por isso que estou tendo esta conversa com todos vocês aqui. :slight_smile:

Eu uso essas ferramentas como ferramentas. Elas mencionam coisas que me permitem ver outros pontos de vista, então pesquiso na internet ou faço perguntas aqui na comunidade. Ao longo do caminho, elas também me mostram outros conceitos não estritamente relacionados ao Discourse, o que também é uma coisa boa. As ferramentas são tão boas quanto a pessoa que as utiliza.

E eu fiz muita coisa usando dicas do ChatGPT e do Claude. Não podemos descartar tudo o que eles dizem… cegamente :wink:

Você se importaria de compartilhar um pouco mais sobre isso? Se a informação que o ChatGPT / Claude fornece estiver incorreta, talvez você possa me iluminar, assim como outros que possam ler isso no futuro?

Não no meu caso, por alguns motivos (e a menos que eu esteja perdendo alguma coisa, aqui estão eles):

  • Eu quero poder fazer alterações personalizadas, se necessário, em cada instância, sem afetar as outras. Não que eu fazer, mas quero saber que posso se eu quiser.
  • Em um multisite, se o principal falhar, todos falham, correto?
  • Eu simplesmente gosto de ter as coisas independentes. A ideia de que 4-5 instâncias estão todas conectadas a algo que pode falhar em algum momento me incomoda.

Novamente, talvez minha perspectiva sobre como um multisite funciona esteja errada, mas pelo que entendo, não parece ser uma boa opção para mim.

No momento, minhas necessidades são:

  • Construir todas as comunidades que preciso
  • Gastar o mínimo de dinheiro possível, porque não sei se essas decisões de construir essas comunidades serão boas a longo prazo ou não (já passei por isso mais do que gostaria, gastando muito dinheiro em “experimentos”).

Eu não conhecia essa ferramenta, então obrigado por compartilhar. Marquei como favorito.
Tenho que dizer, no entanto, que não devemos cegamente (desculpe, tive que fazer isso de novo haha) descartar tudo o que o ChatGPT ou o Claude dizem, mesmo que o bot de IA do Discourse seja mais experiente, o que eu acredito que seja com tanto conteúdo disponível sobre o assunto. Eu uso o ChatGPT e o Claude também, porque às vezes certas coisas não estão apenas relacionadas ao Discourse e eu sempre gosto de aprender um pouco mais sobre outras coisas.

Independentemente disso, agradeço seu feedback e tempo. Já me ajudou muito.

3 curtidas

Pelo que consigo entender, você está mergulhado em pensar demais na sua configuração.

Fundamentalmente, você não deve buscar as 1000 ideias brilhantes de novas comunidades que você tem de uma só vez, iniciando tantas instâncias novas do Discourse (e, por extensão, de qualquer outro software) quanto possível.

Construir uma comunidade é um processo iterativo e precisa de foco; se você dividir seu foco entre mais de uma comunidade por vez, acabará com mais coisas para lidar do que pode gerenciar.

Minhas sugestões foram para reflexão, como mencionei anteriormente, quando fiz esses experimentos, eram apenas isso, um bando de amigos fazendo coisas porque podíamos.

Existe um (ou dois) motivo(s) pelo qual estas não são práticas comuns? Elas vêm com uma sobrecarga significativa de manutenção e gerenciamento que causará muitas dores de cabeça e noites sem dormir no futuro, você foi avisado.

Dados os seus objetivos, eu encerraria meu argumento com esta afirmação: o que você está tentando alcançar não é impossível, mas hoje não é o dia para alcançar tudo o que é possível. Concentre-se no que você tem em mãos, construa sua primeira comunidade, o resto pode vir quando for a hora certa.

Quanto a aprender por meio de experimentação, se reduzir custos é seu objetivo principal, a instalação multi-site é o caminho a seguir, com todos os compromissos que ela apresenta.

3 curtidas

Obrigado novamente pelo feedback.

Eu entendo o que você quer dizer e, acredite, se eu fosse construir todas as comunidades que preciso para tudo em que estou envolvido, não estaríamos falando de 4-5, mas sim de 15.

Consegui chegar a 3 que parecem ser realmente importantes e que devem ser construídas agora. Neste ponto, todas as 3 precisam de seu próprio espaço para dar aos usuários um lugar para discutir suas experiências com os produtos e serviços que eu tenho ou estou construindo.

Como eu disse, um multisite onde todos dependem um do outro, não parece certo para mim e, para ser honesto, as dores de cabeça e as noites sem dormir que você menciona, são provavelmente mais propensas a existir nesse caso (pelo menos para mim e minha experiência em outras áreas onde as coisas dependiam umas das outras), em uma configuração de multisite. Eu não sei… é um daqueles casos em que meu instinto diz “não faça isso” e eu estou confiando nele. Talvez eu esteja errado e serei provado errado ao longo do caminho, mas estou confiando no meu instinto primeiro.

De qualquer forma, obrigado novamente pelo seu tempo e ajuda. Agradeço :raising_hands:

2 curtidas

Então, desejo-lhe sorte, senhor! Tudo de bom para sua nova aventura.

1 curtida

Olá amigos e feliz ano novo!

Este é um tópico oportuno para mim, pois estou justamente no processo de ajustar minha própria configuração para economizar tempo e dinheiro. Tenho três pequenos sites privados que recebem muito pouco tráfego, mas todos são importantes para mim. Também quero poder criar mais sites para testar novas ideias. Portanto, o multisite acho que será de meu interesse.

Dito isso, acabei de migrar um dos meus sites do DigitalOcean para o Hetzner e fiquei surpreso com a economia de custos. É apenas $3,49/mês pela oferta cx23 menor deles, que por acaso é quase ideal para um único site pequeno. Eu estava pagando $15,60 no DigitalOcean por uma configuração semelhante.

Depois de ler este e outros tópicos relacionados, meu principal obstáculo com o multisite é que quero usar e-mail de entrega direta para todos os meus sites, usando o nome de domínio do site como nome de domínio do e-mail para que seja facilmente reconhecido e confiável pelos membros do site. As instruções para configurar isso não parecem muito diretas.

Portanto, no momento, estou concluindo que talvez seja melhor para mim simplesmente manter os sites autônomos e migrá-los todos para o Hetzner. Vou economizar dinheiro, mas não tanto tempo, considerando quanto tempo de ficar olhando para o relógio está envolvido na configuração de sites autônomos.

3 curtidas

Você pode fazer isso, mas somente se todos usarem as mesmas credenciais de smtp.

Como seu novo Hetzner é muito mais barato, você ainda sairá ganhando com três sites do que com apenas um na taxa antiga.

Eu não recomendaria multisite com apenas 1 GB de RAM, e dá mais trabalho para configurá-lo, embora a nova configuração de ambiente de alias de nome de host resolva um dos maiores problemas.

2 curtidas

O cx23 tem 4gb de ram. Estou movendo meus outros dois sites para seus servidores cx23 separados, então veremos como isso se desenrola, mas minha sensação é que ficará tudo bem.

Estou confuso com isso, pois o mail-receiver é apenas sobre receber e-mail e não há credenciais smtp.

Você está falando de e-mail de entrada ou de saída? Com e-mail de saída, cada site não tem suas próprias credenciais smtp configuradas em app.yml?

3 curtidas

Não. O receptor de e-mail é separado. Se você estiver usando multisite, haverá apenas um arquivo YML e é lá que as credenciais de envio SMTP são definidas. Se você estiver usando o receptor de e-mail, você tem um problema diferente, pois você precisa de um receptor de e-mail para cada site (pelo menos, essa é a única solução que encontrei).

3 curtidas