Usando uma imagem Docker construída por um launcher no docker-compose

Dev
21

Ei, Mike. Basicamente, o que você faz é usar ./launcher bootstrap para construir a imagem, enviá-la para um repositório e, em seguida, usar ./launcher start-cmd para ver quais variáveis de ambiente (ENV) precisam ser passadas para o Docker para iniciar tudo.

O motivo de não existir um guia assim é que pessoas que não têm o entendimento mais básico de nenhuma das peças subjacentes vão encontrá-lo, não conseguirão entendê-lo e, em seguida, esperarão um tutorial sobre como o ingress funciona em qualquer sistema que eles acham ser a única solução.

22

Chame-me de maluco, mas talvez você seja a prova viva de que fizemos as coisas do jeito que fizemos por um motivo?:wink:

23

Obrigado, Jay — já tinha chegado a essa conclusão. Finalmente consegui fazer funcionar.

  • Vou criar um vídeo e um guia com exatamente o que fiz, para que o próximo eu não perca tempo tentando descobrir isso.

Acho que parte do problema é que isso vai contra a corrente da maioria das outras imagens Docker disponíveis. Não é tão “plug and play”. É mais “ajustar, conectar e depois rodar”.

Como disse, o launcher é algo lindo e confiável para o que faz.

Em uma nota realmente positiva, a versão apenas para web funciona maravilhosamente bem, é super rápida no meu swarm e atualizável, pois tenho o servidor de build.

Quando tiver tempo, vou explorar a criação de um servidor de build no meu swarm que permita a construção de uma imagem Docker via navegador.

Coisas que tentei e que deixaram muito a desejar…

  • imagem Docker da Bitnami — rodou como um cachorro sem pernas.
  • Dockerfile da IndieHosts — nem cheguei ao ponto de construir; parecia determinado a compilar tudo, acho que estava compilando o Linux. Novamente, tem que haver uma maneira mais fácil!

Ok — obrigado.

Mike.

24

Tivemos aquela desvantagem do primeiro movimento :sunglasses:

O script do launcher foi criado antes do docker-compose, docker-swarm, kubernetes e de tudo isso existir, e… ainda funciona. Não há realmente nenhuma razão convincente para mudarmos para outra coisa. As “vantagens” desses sistemas não são vantagens para o maior consumidor de auto-hospedagem do Discourse, que são instalações com orçamento limitado em VPSs na nuvem.

25

Ah! Eu sempre me perguntei. E da última vez que verifiquei, era necessário um passo extra para instalar o docker-compose no Ubuntu. É como se não quisessem que as pessoas o usassem, a menos que essas pessoas usassem Windows (ou Mac?)

26

É um pouco triste ouvir isso como resposta oficial da equipe de desenvolvimento. Você está basicamente dizendo que, se você não é bom o suficiente para descobrir esse processo não documentado de rodar o Discourse em produção, talvez não devesse estar rodando o Discourse em produção.

Bem, nem todos nós temos experiência extensa em DevOps, infelizmente.

@Mike_Sutton, estou na mesma página que você. Tenho lido os fóruns nas últimas semanas tentando resolver esse problema. Você conseguiu fazer um vídeo sobre como resolveu o problema?

27

Isso funcionaria? E quanto às migrações do banco de dados?

28

Neste cenário, você faria o bootstrap executar as migrações enquanto constrói a nova imagem do contêiner.

29

Olá @lucasbasquerotto

Sim, você pode enviar as imagens do Docker do Discourse para um repositório e arquivar o restante de /var/discourse como na discussão abaixo, mas não é uma maneira eficiente de fazer as coisas e não é oficialmente suportado. Testei isso completamente recentemente:

30

Mas, nesse caso, a etapa de bootstrap precisaria ser feita na máquina de produção, o que, se não me engano, anula o propósito de empurrar uma imagem base para um registro de containers (já que a intenção é justamente evitar o bootstrap da imagem em produção, exceto talvez para executar uma etapa de migração de banco de dados ou algo semelhante).

É assim que faço em sites que hospedo, exceto os Discourse: normalmente uso o Flyway para rodar migrações no banco de dados, junto com outras tarefas, como esvaziar o cache do Redis, mas sem executar outros processos intensivos, especialmente aqueles que dependem de serviços externos, como a atualização de certificados HTTPS (isso eu faria em um cronjob, exceto na primeira vez, o que é aceitável) ou a alteração do código-fonte (que seria estático na imagem, como pacotes, bibliotecas e outras coisas). Parece que o Discourse usa o Rake, o que é bom, mas ele também executa outras tarefas, como instalar gems, gerar assets, atualizar o banco de dados MaxMind e talvez outros serviços (o que quebraria a etapa de rebuild se, por exemplo, o serviço estiver fora do ar ou se houver uma mudança na API, o que é raro, mas pode acontecer).

Não estou dizendo que o Discourse deveria fazer assim, é claro, mas gerar uma imagem em um ambiente de CI e apenas executar uma etapa de migração de banco de dados nos servidores de staging/produção, além de definir as variáveis de ambiente, é o que eu esperaria, e isso é facilmente alcançável com outros softwares como WordPress, MediaWiki, Rocket.Chat, etc. O Discourse é o melhor software para fóruns, na minha opinião, e eles podem ter boas razões para fazer do jeito que fazem, mas, por enquanto, eu usaria apenas a instalação padrão (ou a instalação multicontainer) para evitar dores de cabeça e torcer para que nada dê errado nos rebuilds.

Parece que o bootstrap ainda deve ser feito em um ambiente de produção e não em um ambiente de CI para gerar uma imagem base a ser usada tanto em staging quanto em produção. Além disso, não ser uma instalação padrão é um grande sinal de alerta, o que pode se tornar uma dor de cabeça no futuro à medida que o software receber atualizações.

31

Oi Mike,

Você chegou a documentar seu processo no final? Seria ótimo ver o vídeo também?

Atenciosamente,