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, или вы просто используете один образ и выполняете компиляцию ассетов при его запуске?
Технически мы выполняем предварительную компиляцию дважды: один раз для базового образа с нашими изменениями, а второй раз — при развёртывании конкретных сайтов с определёнными плагинами.
Однако наша конфигурация не подходит для использования, если вы не занимаетесь хостингом Discourse как бизнесом.
Я очень хотел бы использовать Discourse, но подход этих разработчиков к использованию контейнерных технологий полностью отпугивает меня. Я никогда не видел проекта, который смог бы сделать установку в контейнере настолько непереносимой. Есть гораздо лучшие способы решить эту проблему. Мне кажется, что этот проект эволюционировал в сторону использования контейнеров, но разработчики до сих пор не до конца понимают, как их правильно применять. В результате проект застрял с чрезмерно сложным и непереносимым решением. Вероятно, ограничения по времени не позволят создать корректный переносимый контейнер.
Пожалуйста, предоставьте Dockerfile, который обеспечивает стабильное и предсказуемое состояние системы. Документируйте переменные окружения, которые пользователи должны использовать для настройки поведения контейнера. Просто используйте скрипт entrypoint, чтобы гарантировать корректный запуск всего необходимого во время выполнения. Объединение контейнеров можно реализовать с помощью Docker Compose или Kubernetes, но не так, как это сделано сейчас — это действительно посредственно.
Я пытаюсь запустить это, например, на Fedora CoreOS, CentOS 8 или Fedora 32, но это невозможно. Стандарты контейнеров это допускают, однако текущая реализация фактически поддерживает только Ubuntu LTS. Хотя некоторые пользователи уже отказались от Docker (особенно при запуске сервисов от root-пользователя). Контейнеры стандартизированы, поэтому люди могут выбрать Docker или Podman. Но этот «Франкенштейн» сильно усложняет такой выбор, что противоречит самой концепции контейнеров и современным принципам безопасности контейнерных сред.
Попробуйте посмотреть на ситуацию в 2014 году. Когда проект только начинался, docker-compose ещё не был широко известен.
Очень верно! Может быть, вы сможете это исправить. Всё, что нужно сделать, — это полностью изменить подход к сборке и запуску контейнеров и убедиться, что это не сломает тысячи работающих сайтов.
ИЛИ создайте контейнеры, которые позволят запускаться с помощью любого инструмента, который понравится тем, кто знает, как правильно использовать контейнеры. Похоже, Bitnami уже это сделала. Вы можете поискать здесь и найти множество людей, у которых возникли проблемы и которые не знают, куда обратиться за помощью.
Я понимаю, что это непростая задача. Однако цель контейнеров — обеспечить согласованное и переносимое состояние. Поэтому, если контейнеры используются по назначению и у вас всё работает, то с высокой долей вероятности они будут работать и у всех остальных, кто использует этот контейнер.
Если сам процесс инициализации (bootstrap) перенести внутрь контейнера, а не выполнять его на хост-системе, это уже значительно повысит его переносимость. Я могу заняться этим после завершения других проектов. Я тоже не эксперт в области контейнеров, но создавал несколько из них. Однако есть один недостаток: отсутствует документация по установке, верно? Всё сводится к тому, что вам просто дают скрипт и говорят: «Запустите его». Я могу попытаться воспроизвести то, что делает этот скрипт, но тогда у вас останется мало возможностей для внесения предложений по улучшению.
Таким образом, если сообщество, особенно люди, непосредственно вовлечённые в процесс и обладающие внутренней информацией о том, как должна работать установка, готовы дать совет или помочь, я готов начать эту инициативу. В противном случае качество не будет соответствовать вашим ожиданиям.
Цели будут примерно следующими:
- Dockerfile, обеспечивающий атомарную сборку конфигурации (без локального bootstrap вне контейнера);
- Отсутствие необходимости запускать контейнер от имени root; предпочтительно использовать fakeroot и добавлять capabilities (это аргументы командной строки, пользователи всё ещё могут при желании запускать контейнер от root…);
- Создание скрипта entrypoint, который можно настраивать с помощью переменных окружения, которые должны быть чётко задокументированы;
- Использование
podman-generate-systemdили аналогичного инструмента для создания systemd-юнита, позволяющего (пере)запускать контейнер или запускать его при загрузке системы (функция Podman; возможно, у Docker есть что-то похожее, но акцент делается на интеграцию этого процесса).
Это касается базовой установки. Для масштабируемого решения потребуется docker-compose и решение на базе Kubernetes. Честно говоря, я не считаю, что сообщество Discourse должно отвечать за создание универсального решения «под ключ». Поскольку такие вещи можно очень тонко настраивать, особенно в Kubernetes. Поэтому, полагаю, базовое решение на основе compose будет достаточно для того, чтобы пользователи могли быстро разобраться.
Это обеспечит переносимое и более безопасное решение, что в целом повысит уровень внедрения и качество. Тем временем я посмотрю, действительно ли Discourse нужен для моего сообщества. Если да, то пока я буду использовать Ubuntu LTS. Как только у меня появится больше времени, я займусь внедрением такой конфигурации.
Привет @AquaL1te,
Я выполнил часть ваших предложений. Решение поддерживает podman, k8s или docker. Поддерживается режим без прав root (но не fakeroot). Используется конфигурация из 4 контейнеров: nginx, sidekiq, redis и ruby-демон.
В целом можно следовать документации по установке для разработчиков.
Одно важное замечание: есть некоторые сложные моменты, связанные с тем, как Discourse обрабатывает статические ресурсы.
Ах, да. Я запутался в терминологии, последнее время я активно использую Singularity, который использует флаг --fakeroot.
Я посмотрю, звучит очень здорово! Поскольку я предпочитаю использовать Fedora CoreOS для этих целей, чтобы максимально реализовать потенциал безопасности контейнеризированной среды. В текущей конфигурации это пока не так просто сделать.
Меня всё ещё беспокоит, что основное решение не является переносимым, и нет никаких признаков движения к современному решению. Я более детально изучу вашу настройку и, возможно, в будущем свяжусь с вами, чтобы стать со-мэйнтейнером. Если, конечно, это потребуется. Спасибо за вашу работу и предложения!
Я только что дочитал эту огромную ветку до конца, и особенно откликнулись нужды Gkoerk, который комментировал выше 19 октября 2018 года, прося помощи в самостоятельном размещении Discourse в сваре — по-видимому, для включения в его «маму всех» docker-swarm-cookbook. Вау. Какой сборник! Gkoerk, как сообщается, скончался в молодом возрасте 40 лет. Чёрт. Казалось, действительно отличный парень и вкладчик.