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.
이것은 각 배포 시마다 기본 이미지와 precompile assets를 통해 이루어진 변경 사항이 포함된 새로운 이미지를 생성하여 부트스트랩한다는 뜻인가요? 아니면 단일 이미지를 사용하다가 부팅 시점에 precompile을 수행하는 방식인가요?
기술적으로 우리는 두 번 사전 컴파일합니다. 첫 번째는 기본 이미지와 우리의 변경 사항을 위해, 두 번째는 특정 플러그인을 갖춘 특정 사이트를 배포할 때입니다.
다만, 우리의 설정은 Discourse를 비즈니스로 운영하는 경우가 아니라면 일반적으로 하지 않는 방식입니다.
저는 정말로 Discourse를 사용하고 싶습니다. 하지만 이 개발자들이 컨테이너 기술을 사용하는 방식 때문에 Discourse를 사용하는 것을 막고 있습니다. 컨테이너 설치를 이렇게 비이식적으로 만들 수 있는 프로젝트는 본 적이 없습니다. 이 문제를 해결하는 훨씬 더 나은 방법들이 있습니다. 저에게 이 프로젝트는 컨테이너를 향해 유기적으로 발전해 왔지만, 실제로 어떻게 사용해야 하는지 제대로 알지 못하는 것 같습니다. 그리고 이제 이 프로젝트는 과도하게 복잡하고 비이식적인 솔루션에 발이 묶여 있습니다. 아마도 시간 제한 때문에 제대로 된 이식 가능한 컨테이너를 만들 수 없을 것입니다.
일관된 상태로 빌드되는 Dockerfile을 제공해 주세요. 컨테이너 동작을 조작하기 위해 사용자가 설정해야 하는 환경 변수를 문서화해 주세요. 그리고 단순히 entrypoint 스크립트를 사용하여 런타임에 모든 것이 시작되도록 보장하세요. 컨테이너를 결합하는 것은 Docker Compose나 Kubernetes를 통해 수행할 수 있습니다. 하지만 지금처럼은 안 됩니다. 이건 정말로 별로입니다.
저는 예를 들어 Fedora CoreOS, CentOS 8 또는 Fedora 32에서 이걸 실행해 보고 있습니다. 하지만 불가능합니다. 컨테이너 표준이라면 분명히 가능해야 합니다. 하지만 이것은 기본적으로 Ubuntu LTS만 지원하도록 정밀하게 맞춰진 방식입니다. 일부 사람들은 이미 Docker를 떠나고 있습니다(특히 루트 권한으로 서비스를 실행하는 경우). 하지만 컨테이너는 표준화되어 있으므로, 사용자는 Docker를 사용할지, 아니면 Podman을 사용할지 결정할 수 있어야 합니다. 하지만 이 프랑켄슈타인 같은 구성은 그 일을 매우 어렵게 만들며, 이는 컨테이너의 개념과 현대적인 컨테이너 보안에 반합니다.
2014년 전후로 돌아가 보세요. 이 프로젝트가 시작될 당시 docker-compose는 실제로 존재하지 않았습니다.
정말 그렇습니다! 어쩌면 여러분이 이를 수정할 수 있을지도 모릅니다. 컨테이너를 빌드하고 실행하는 방식을 전부 변경해야 하며, 그렇게 하면 수천 개의 정상적으로 작동하는 사이트가 깨지지 않는지 확인해야 합니다.
아니면, 컨테이너 사용법을 아는 사람들이 좋아할 어떤 도구를 사용하여 실행할 수 있도록 컨테이너를 만들어 보세요. Bitnami는 이를 잘 해낸 것 같습니다. 여기에서 검색해 보면 문제를 겪고 도움받을 곳도 없는 사람들이 많다는 것을 발견할 수 있습니다.
쉬운 일이 아니라는 것을 잘 알고 있습니다. 하지만 컨테이너의 목적은 일관되고 이동 가능한 상태를 갖는 것입니다. 따라서 컨테이너가 의도된 대로 사용되고, 사용자에게 잘 작동한다면, 해당 컨테이너를 사용하는 모든 사람에게도 작동할 가능성이 상당히 높습니다.
부트스트랩만 호스트가 아닌 컨테이너 내부로 이동시켜도 이동성을 크게 높일 수 있습니다. 다른 프로젝트들을 마무리한 후에 한번 살펴볼 수 있을 것 같습니다. 저도 컨테이너 전문가라고 할 수는 없지만, 몇 개는 만들어 본 경험이 있습니다. 다만 단점은 설치 문서가 제공되지 않는다는 점입니다. 그냥 '이 스크립트를 실행하세요’라고만 되어 있는 것이죠. 스크립트가 하는 일을 재현해 볼 수는 있지만, 그렇게 되면 개선 제안을 할 여지가 거의 없습니다.
따라서 커뮤니티, 특히 설치 과정이 어떻게 작동해야 하는지에 대한 내부 정보를 가진 밀접하게 관련된 분들이 조언이나 도움을 주실 의사가 있다면, 저는 이 이니셔티브를 시작할 준비가 되어 있습니다. 그렇지 않으면 여러분이 보고 싶어 하는 수준의 품질을 기대하기 어려울 것입니다.
목표는 대략 다음과 같습니다:
- 설정의 원자적 빌드(컨테이너 외부의 로컬 부트스트랩 없음)를 포함하는 Dockerfile
- 컨테이너를 루트 권한으로 실행할 필요 없이, fakeroot를 사용하고 capabilities를 추가하는 것이 가장 좋습니다 (이것들은 커맨드 라인 인수로, 여전히 루트로 컨테이너를 시작하는 것을 선택할 수 있습니다…)
- 환경 변수로 영향을 받을 수 있고, 명확히 문서화되어야 하는 엔트리포인트 스크립트 생성
podman-generate-systemd또는 유사한 도구를 사용하여 컨테이너를 (재)시작하거나 부팅 시 컨테이너를 시작하기 위한 systemd 유닛을 생성 (Podman 기능, Docker에도 유사한 기능이 있을 수 있지만 여기서는 통합에 더 중점을 둠)
이것은 기본 설치에 대한 것입니다. 확장 가능한 솔루션을 위해서는 docker-compose와 Kubernetes 솔루션이 필요합니다. 솔직히 말씀드리자면, 일괄 적용 가능한(one size fits all) 솔루션을 찾는 것은 Discourse 커뮤니티의 책임이라고 생각하지 않습니다. 이러한 것들은 특히 Kubernetes의 경우 매우 세밀하게 조정될 수 있기 때문입니다. 따라서 사람들이 빠르게 시작할 수 있도록 기본적인 compose 솔루션이면 충분할 것이라고 생각합니다.
이것은 휴대 가능하고 더 안전한 솔루션을 제공하여 전반적인 채택률과 품질을 높일 것입니다. 그 동안 저는 Discourse가 제 커뮤니티에 정말 필요한지 살펴보겠습니다. 필요하다면, 당분간 Ubuntu LTS 시스템을 사용하겠습니다. 시간이 더 생기면 이러한 설정에 시간을 투자하겠습니다.
안녕하세요 @AquaL1te,
제안해 주신 사항 중 일부는 이미 구현했습니다. podman, k8s 또는 docker를 사용할 수 있습니다. 루트리스(Rootless) 모드가 지원되며(fakeroot는 아님) nginx, sidekiq, redis, ruby 데몬으로 구성된 4개 컨테이너 설정을 사용합니다.
일반적으로 개발자용 설치 문서를 따를 수 있습니다.
다만, discourse가 에셋(assets)을 처리하는 방식에는 몇 가지 까다로운 부분이 있다는 점을 염두에 두어야 합니다.
아, 그렇군요. 용어를 혼동하고 있었습니다. 요즘 Singularity를 많이 사용하는데, 이쪽은 --fakeroot 플래그를 사용하거든요.
한번 살펴보겠습니다. 아주 좋아 보입니다! 저는 컨테이너화된 환경의 보안 잠재력을 최대한 활용하기 위해 이 용도로 Fedora CoreOS를 사용하는 편을 선호합니다. 하지만 현재 설정에서는 이를 쉽게 구현할 수 없습니다.
아직도 주요 솔루션이 이식성이 없으며, 현대적인 솔루션으로의 전환 움직임이 보이지 않는다는 점이 마음에 걸립니다. 여러분의 설정을 좀 더 자세히 살펴보고, 미래에 공동 유지보수를 위해 연락을 드릴 수도 있습니다. 물론 필요할 경우에만요.你们的 작업과 제안에 감사드립니다!
이 거대한 스레드를 끝까지 읽었고, 특히 Gkoerk님의 필요에 깊이 공감했습니다. Gkoerk 님은 2018년 10월 19일에 Swarm 환경에서 Discourse를 셀프 호스팅하는 데 도움이 필요하다고 위에 댓글을 남기셨는데, 이는 아마도 본인의 docker-swarm-cookbook에 포함시키기 위함이었습니다. 정말 대단한 컬렉션이네요. Gkoerk 님은 안타깝게도 40세라는 젊은 나이에 별세하셨다고 합니다. 정말 슬프네요. 진심으로 훌륭하고 기여도 많았던 분으로 기억됩니다.