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 script) للتأكد من تشغيل كل شيء أثناء وقت التشغيل. يمكن دمج الحاويات باستخدام Docker Compose أو Kubernetes، لكن ليس بهذه الطريقة؛ فهذا أمر مخيب للآمال حقًا.
أحاول تشغيل هذا على أنظمة مثل Fedora CoreOS أو CentOS 8 أو Fedora 32، لكن ذلك غير ممكن. معايير الحاويات بالتأكيد تسمح بذلك، لكن هذا الأسلوب المصمم بدقة يهدف في الأساس إلى دعم إصدارات Ubuntu LTS فقط. بينما انتقل بعض الأشخاص بالفعل بعيدًا عن Docker (خاصة عند تشغيل خدمة بصلاحيات الجذر). لكن الحاويات موحدة، لذا قد يقرر الناس استخدام Docker أو Podman. لكن هذا الكائن الهجين (Frankenstein) سيجعل ذلك صعبًا للغاية، وهو ما يتعارض مع مفهوم الحاويات وأمن الحاويات الحديث.
حاول البحث حول عام 2014. عندما بدأ المشروع، لم يكن docker-compose موجودًا فعليًا.
صحيح جدًا! ربما يمكنك إصلاحه. كل ما عليك فعله هو تغيير كل شيء حول كيفية بناء وتشغيل حاوية، ورؤية أن ذلك لا يكسر آلاف المواقع العاملة.
أو، اصنع حاوياتك التي تتيح لك التشغيل بأي أداة يحبها الأشخاص الذين يعرفون كيف يجب استخدام الحاويات. يبدو أن Bitnami قد فعلت ذلك. يمكنك البحث هنا والعثور على العديد من الأشخاص الذين واجهوا مشاكل ولم يجدوا مكانًا للحصول على المساعدة.
أعلم أن هذا ليس بالأمر السهل. لكن الغرض من الحاويات هو توفير حالة متناسقة وقابلة للنقل. لذا، إذا تم استخدام الحاويات كما ينبغي، وهي تعمل معك، فهناك فرصة جيدة جدًا أن تعمل مع كل من يستخدم تلك الحاوية.
إذا تم نقل عملية التمهيد (bootstrap) نفسها داخل الحاوية بدلاً من استضافتها على المضيف (host)، فستكون قد قطعت شوطًا طويلاً في جعلها قابلة للنقل. يمكنني إلقاء نظرة بعد أن أنهي مشاريعي الأخرى. لست خبيرًا في الحاويات أيضًا، لكنني قمت ببناء بعض منها. ومع ذلك، فإن العيب هو عدم وجود وثائق تثبيت متاحة، أليس كذلك؟ الأمر ببساطة: ها هو، فقط شغل هذا السكربت. يمكنني محاولة تكرار ما يفعله السكربت، لكن ذلك لا يترك مجالًا كبيرًا لاقتراحات التحسين.
لذا، إذا كان المجتمع، وخاصة الأشخاص المتورطون بشكل وثيق والذين يمتلكون معلومات داخلية حول كيفية عمل التثبيت، مستعدين لتقديم النصيحة أو المساعدة، فأنا مستعد لبدء هذه المبادرة. وإلا فلن تكون الجودة كما تريد رؤيتها.
ستكون الأهداف تقريبًا كما يلي:
- ملف Dockerfile يحتوي على بناء ذري للإعداد (بدون تمهيد محلي خارج الحاوية)
- عدم الحاجة لتشغيل الحاوية بصلاحيات الجذر (root)، والأفضل استخدام fakeroot وإضافة الميزات (capabilities) (هذه هي وسيطات سطر الأوامر، ويمكن للأشخاص اختيار تشغيل الحاوية بصلاحيات الجذر…)
- إنشاء سكربت نقطة الدخول (entrypoint) الذي يمكن التأثير عليه عبر متغيرات البيئة، والتي يجب توثيقها بوضوح
- يمكن استخدام
podman-generate-systemdأو ما شابه لإنشاء وحدة systemd لـ (إعادة) تشغيل الحاوية، أو تشغيل الحاوية عند بدء التشغيل (ميزة Podman، ربما يكون لدي Docker شيء مشابه، لكنه يركز أكثر على دمج هذه الوظيفة)
هذا سيكون للإعداد الأساسي. أما بالنسبة للحل القابل للتوسع، فهناك حاجة إلى حل docker-compose وحل Kubernetes. وأنا بصراحة لا أرى أن ذلك من مسؤولية مجتمع Discourse إيجاد حل واحد يناسب الجميع. لأن هذه الأمور يمكن تكييفها بدقة شديدة، خاصة على Kubernetes. لذا، أعتقد أن حل Compose أساسي سيكون كافيًا لإشراك الناس في البداية.
سيوفر هذا حلًا قابلًا للنقل وأكثر أمانًا، مما سيزيد من الاعتماد والجودة بشكل عام. وفي الوقت نفسه، سأرى ما إذا كان Discourse حقًا ما أحتاجه لمجتمعي. إذا كان كذلك، فسأستخدم نظام Ubuntu LTS حاليًا. وبمجرد أن أجد وقتًا أكثر، سأستثمر الوقت في إعداد مثل هذا النظام.
مرحبًا @AquaL1te،
لقد قمت ببعض ما اقترحته. يمكن استخدام Podman أو K8s أو Docker. يتم دعم وضع الجذر (rootless) (وليس fakeroot). يستخدم إعدادًا مكونًا من 4 حاويات: nginx و sidekiq و redis وخدمة Ruby.
بشكل عام، يمكن اتباع وثائق التثبيت الخاصة بالمطورين.
يجب الانتباه إلى أن هناك بعض الجوانب المعقدة المتعلقة بكيفية تعامل Discourse مع الأصول.
آه، نعم. لقد كنت مُربكًا بسبب المصطلحات، فقد استخدمتُ Singularity بكثرة مؤخرًا والذي يستخدم علمًا باسم --fakeroot.
سأقوم بمراجعة الأمر، يبدو رائعًا جدًا! لأنني أفضل استخدام Fedora CoreOS لهذا الغرض، لتعظيم إمكانات الأمان في إعداد محمول (containerized setup). وهذا غير ممكن بسهولة في الوقت الحالي في الإعداد الحالي.
ما زال يزعجني أن الحل الرئيسي غير قابل للنقل، ولا توجد مؤشرات نحو حل حديث. سأقوم بإلقاء نظرة أكثر تفصيلاً على إعدادك، وربما في المستقبل أتواصل معك للمشاركة في صيانته. إذا لزم الأمر بالطبع. شكرًا لك على عملك واقتراحاتك!
لقد انتهيت للتو من قراءة هذا الموضوع الضخم، وتوافق بشكل خاص مع احتياجات Gkoerk الذي علّق في 19 أكتوبر 2018 طالبًا المساعدة في استضافة discourse ذاتيًا ضمن swarm — على ما يبدو لإدراجه في docker-swarm-cookbook الذي يُعدّ من أشمل الكتب. واو! ما هذه المجموعة! تُفيد التقارير أن Gkoerk توفي في سن مبكرة عن عمر 40 عامًا. يا لهول. بدا وكأنه شخص رائع حقًا ومساهم فاعل.