Rebuilds are far from a common or regular practice. Most upgrades can be performed from /admin/upgrade
And for sites where any server error is a problem there are guides on how to present a holding page during the upgrade process.
I have to perform rebuilds when I add or remove plugins, and when they are mandated by the occasional upgrade (several times a year). But yes, it’s not a showstopper for a local community forum like mine, and /admin/upgrade works very well for regular updates.
I present a holding page during my rebuild upgrades for the benefit of users, but how would the Googlebot perceive this? To the bot, my homepage suddenly has no intra-site links, and all the pages the bot has previously indexed have their content replaced with the holding page.
If you’re catching all requests with a 302 to show the holding page there should be zero impact. Google confirmed a couple of years back that redirects don’t impact SEO/pagerank:
Gary is the “House Elf and Chief of Sunshine and Happiness at Google” (Webmaster Trends Analyst)
If you’ve just rebranded the 502 error page then yes, it will have an impact.
What you don’t understand is that most of the people deploying discourse don’t know what docker is, much less care about best practices.
If you want a docker image, just use pups to generate it yourself. Is that what you guys do, @sam? Do create a separate container image for each enterprise client with their plugins?
If you want to avoid downtime when you need to rebuild, make a 2 container configuration. You can search here or look in discourse-setup for a command line option that will build one for you. Then downtime is limited to the time it takes for the new container to boot up.
If you want zero downtime, configure haproxy with multiple web containers.
There’s a very large number of people running their own servers who are looking for this exactly. I know personally dozens of hobbyists who are looking for a forum which is truly self-hosted, not on a droplet or other VPS. Many self-hosting enthusiasts run multiple apps (think Nextcloud, Plex, Wikis, CMS/Blogs, etc.), whether they actually host them or run them on a VPS. Here’s my situation: I’m running docker swarm for dozens of apps. It seems to me at least that the way the tool works now it can’t be incorporated into a docker swarm with Traefik or HAProxy reverse-proxying requests.
Maybe (hopefully!) I’m mistaken and you can explain or point me to instructions on how to take your final, single completed container, reference it in a new docker-compose and run it in a swarm?
I understand that. But the developers of Discourse do, and they depend on it for their deployments. I apologize, I don’t know what pups is. Looks like it’s related to Ansible, which I don’t know.
Debt in the deployment management code & process. It is very complicated right now with lots of moving parts and things that are difficult to understand and support. One of docker’s primary draws is the encapsulation of prerequisite code and builds which complete prerequisite work with less risk of a user messing something up, especially if the whole thing is ultimately wrapped in a script to create/upgrade the installation. That gives those who don’t (and don’t need to) understand docker well a good solution, and gives engineers or “hobbyists” a solution as they could skip the wrapper and compose things the way they want.
One of the things I think overlooked here is that a major reason for self-hosting is control over data and backups, etc. Docker makes this especially convenient since you can bind volumes and back those up, and even run a container in the stack whose role is backing up the DB to a flat file in the backup location. When you can’t self-host it along with other docker apps, it effectively means you cannot self-host on your server, you need to purchase a VPS just for Discourse, rather than reusing the same hardware and ecosystem that works for the vast majority of apps which use docker in their deployment.
By way of disclaimer, I am not employed or compensated by any hardware vendor, Saas provider, or forum software developers.
Think about how many potentially unnecessary Digital Ocean, Linode, and VULTR subscriptions Discourse has been responsible for launching. Then consider that there are companies making a revenue stream hosting Discourse for others in part because it is too complex for them:
The Discourse forum software is fantastic, but quite hard to install and host it yourself. We think it’s too great a product to be limited to a technical audience only.
Then again, the way you’ve modeled your revenue-stream, it makes zero sense making things easier to install and run in simple to use containers which expose only necessary ports and bind mounts, using environment variables for everything else so that deployment is as simple as docker stack deploy or docker-compose up. Like I said - maybe and hopefully I’m the one mistaken, and there’s a way to take the final docker container and deploy it in a swarm or other compose environment with other apps and a reverse proxy.
This is exactly the point many folks have been making in this lengthy thread: Is there a solution for those who do know what nano is and can exit VI / VIM just fine? I trust you know your customer base better than I, but I have to imagine that such basic knowledge of Linux is the case for the overwhelming majority of those wanting to self-host open-source software on Linux.
Yes. Create a web_only.yml (there is a sample in discourse_docker) and use that to build your docker image with your plugins. Then add it to your swarm. Everything can be configured via environment variables; you can see them in the last line when you to a ./launcher start web_only. It’s not that hard, but you’re not going to get free support here to help you figure it out (and it’s not just you but a whole bunch of people with a zillion different definitions of Best Practices who would need much, much more help than you would).
I can probably help you figure out what you need to know in an hour or two of my time.
Recently I found the commands to fast forward a git clone depth 1:
git checkout --detach #avoid tangle with git tree state
git fetch --depth 1 -f -origin [branch|commit]
git checkout -f [branch|commit]
Thanks to archive.org team.
So would running ./launcher bootstrap mybase that had the bundle exec rake db:migrate; bundle exec rake assets:precompile added to the init script do something like that? Just run it against a test database, or maybe strip those rake tasks out of web.template.yml?
EDIT: Found this comment:
# this allows us to bootstrap on one machine and then run on another
which might answer my question.
Isso significa que vocês ainda inicializam uma nova imagem para cada deploy que é criada a partir da imagem base mais as alterações feitas pelo precompile assets, ou vocês apenas usam a imagem única e a inicializam quando ela é ativada?
Tecnicamente, pré-compilamos duas vezes. Uma vez para a imagem base mais nossas alterações. E uma segunda vez ao implantar sites específicos com plugins específicos.
No entanto, nossa configuração não é algo que você faria, a menos que estivesse hospedando o Discourse como um negócio.
Eu realmente gostaria de usar o Discourse. Mas a forma como esses desenvolvedores estão usando tecnologia de contêiner realmente me impede de utilizá-lo. Nunca vi um projeto capaz de tornar uma instalação em contêiner não portável como essa. Existem maneiras muito melhores de resolver isso. Para mim, parece que este projeto evoluiu organicamente em direção aos contêineres, mas não sabe realmente como eles devem ser usados. E agora o projeto está preso a essa solução excessivamente complexa e não portável. E provavelmente restrições de tempo não permitirão criar um contêiner portável adequado.
Por favor, forneça um Dockerfile que construa um estado consistente. Documente as variáveis de ambiente que as pessoas devem usar para manipular o comportamento do contêiner. E simplesmente use um script de entrypoint para garantir que tudo seja iniciado em tempo de execução. A combinação de contêineres pode ser feita com Docker Compose ou Kubernetes. Mas não assim, isso é realmente medíocre.
Tento executar isso, por exemplo, no Fedora CoreOS, CentOS 8 ou Fedora 32. Mas não é possível. Os padrões de contêiner certamente permitiriam. Mas isso é uma maneira bem afinada de basicamente suportar apenas o Ubuntu LTS. Enquanto algumas pessoas já migraram do Docker (especialmente ao executar um serviço como root). Mas os contêineres são padronizados, então as pessoas podem decidir usar Docker ou Podman. Mas essa Frankenstein tornaria isso muito difícil, o que vai contra o conceito de contêineres e a segurança moderna de contêineres.
Tente pesquisar por volta de 2014. Quando o projeto começou, o docker-compose nem era realmente uma coisa.
Muito verdade! Talvez você possa corrigir isso. Tudo o que precisa fazer é mudar tudo sobre como construir e iniciar um container e ver se isso não quebra milhares de sites funcionando.
OU, crie seus containers de forma que permitam o lançamento com qualquer ferramenta que as pessoas que sabem como os containers devem ser usados vão gostar. A Bitnami parece ter conseguido isso. Você pode pesquisar aqui e encontrar muitas pessoas que tiveram problemas e não tiveram para onde ir para obter ajuda.
Sei que não é uma tarefa fácil. Mas o propósito dos containers é ter um estado consistente e portátil. Então, se os containers forem usados como deveriam ser e funcionarem para você, há uma chance razoavelmente alta de que funcionem para todos que usam esse container.
Se o bootstrap fosse movido para dentro do container, em vez de ficar no host, você já teria avançado bastante em torná-lo portátil. Posso dar uma olhada depois de terminar outros projetos. Não sou especialista em containers também, mas já construí alguns. A desvantagem, no entanto, é que não há documentação de instalação disponível, certo? É só: “aqui está, basta executar este script”. Posso tentar replicar o que o script faz, mas isso não deixa muito espaço para sugestões de melhoria.
Então, se a comunidade, especialmente as pessoas envolvidas de perto e que têm informações internas sobre como a instalação deve funcionar, estiverem dispostas a aconselhar/ajudar, então estou disposto a iniciar essa iniciativa. Caso contrário, a qualidade não será o que você deseja ver.
Os objetivos seriam mais ou menos:
- Um Dockerfile que tenha uma construção atômica da configuração (sem bootstrap local fora do container)
- Nenhuma necessidade de executar o container como root; o ideal é usar fakeroot e adicionar capacidades (esses são argumentos de linha de comando; as pessoas ainda podem optar por iniciar um container como root…)
- Criar um script de entrypoint que possa ser influenciado por variáveis de ambiente, que devem ser claramente documentadas
podman-generate-systemdou algo similar pode ser usado para criar uma unidade systemd para (re)iniciar um container ou iniciar um container na inicialização (recurso do Podman; talvez o Docker tenha algo similar, mas é mais sobre integrar isso)
Isso seria para a instalação básica. Para uma solução escalável, é necessária uma solução docker-compose e Kubernetes. O que, francamente, não considero responsabilidade da comunidade Discourse encontrar uma solução que sirva para todos. Porque essas coisas podem ser muito bem adaptadas, especialmente no Kubernetes. Então, acho que uma solução compose básica seria suficiente para colocar as pessoas em dia.
Isso fornecerá uma solução portátil e mais segura, aumentando a adoção e a qualidade no geral. Enquanto isso, vou verificar se o Discourse é realmente algo que preciso para minha comunidade. Se for, usarei um sistema Ubuntu LTS por enquanto. Assim que tiver mais tempo, investirei tempo em tal configuração.
Olá @AquaL1te,
Fiz parte do que você sugeriu. É possível usar podman, k8s ou docker. O modo rootless é suportado (não é fakeroot). A configuração utiliza 4 containers: nginx, sidekiq, redis e o daemon Ruby.
Em geral, é possível seguir a documentação de instalação para desenvolvedores.
Um ponto a lembrar é que existem alguns aspectos complicados relacionados à forma como o Discourse lida com os assets.
Ah, sim. Eu estava confuso com a terminologia; tenho usado bastante o Singularity ultimamente, que usa a flag --fakeroot.
Vou dar uma olhada, parece muito bom! Como prefiro usar o Fedora CoreOS para isso, para maximizar o potencial de segurança de uma configuração containerizada. Isso não é facilmente possível no momento com a configuração atual.
Ainda me incomoda que a solução principal seja não portátil e não haja sinais de uma solução moderna. Vou examinar com mais detalhes sua configuração e, talvez no futuro, entrarei em contato para co-mantê-la. Se necessário, claro. Obrigado pelo seu trabalho e sugestões!
Acabei de terminar de ler este fio inteiro, que é uma verdadeira fera, e especialmente me identifiquei com as necessidades de Gkoerk, que comentou acima em 19 de outubro de 2018 buscando ajuda para hospedar o Discourse em um swarm — aparentemente para inclusão em seu docker-swarm-cookbook, o maior de todos. Uau. Que coleção incrível! Gkoerk faleceu prematuramente aos 40 anos. Que pena. Parecia ser um cara genuinamente ótimo e um grande contribuidor.