الانتقال من حاوية مستقلة إلى حاويات ويب وبيانات منفصلة

[5minpause]

هذا إعداد متقدم. لا تتبعه إلا إذا كنت خبيرًا في إدارة خوادم Linux و Docker. تحتاج أيضًا إلى إيلاء اهتمام وثيق لـ commits إلى discourse_docker للتأكد من ملاحظة أي زيادة في إصدار postgres أو redis.

تحويل الإعداد الحالي الخاص بك

تمكنت من الترحيل إلى حاويتين. إذا احتاج أي شخص آخر إلى إرشادات، فإليك كيف سارت الأمور بالنسبة لي.
تتضمن العملية النسخ الاحتياطي، وإعداد حاويات ويب وبيانات منفصلة، واستعادة البيانات.

1. انسخ نسخة احتياطية من مثيل discourse الخاص بك وقم بتنزيل النسخة الاحتياطية. يمكنك اتباع الدليل البسيط أو النسخ الاحتياطي والاستعادة يدويًا لاحقًا.

2. أوقف الحاوية المستقلة الحالية
   ./launcher stop app

3. انسخ web_only.yml و data.yml من samples/ إلى containers/ وقم بإعادة تسميتهما إلى أي شيء تريده، على سبيل المثال، web_rocks.yml و data2.yml.

4. إذا قمت بإعادة تسميتهما، يرجى الانتباه إلى الإدخالات volumes: في data.yml و web_only.yml
   إذا قمت بإعادة تسمية web_only.yml إلى web_rocks.yml، فستحتاج إلى تعديل الإدخال في Web_rocks.yml كالتالي:

volumes:
  - volume:
      host: /var/discourse/shared/web_rocks
      guest: /shared
  - volume:
      host: /var/discourse/shared/web_rocks/log/var-log
      guest: /var/log

وبالمثل، قم بإجراء تعديل مماثل في data.yml أيضًا.

إعداد حاوية البيانات

ابدأ بـ data.yml وقم بتعيين كلمة مرور لقاعدة البيانات. ثم:

• انتقل إلى المجلد الجذر للحاوية /var/discourse
• قم بتشغيل ./launcher bootstrap data2 (data2 أو أي اسم جديد أطلقته عليه)
• قم بتشغيل ./launcher start data2 (باستخدام الاسم الجديد مرة أخرى)
• إذا سار كل شيء بسلاسة، يمكنك الاتصال بالحاوية عبر: ./launcher enter data2 (باستخدام الاسم الجديد مرة أخرى)
• اخرج من الحاوية عن طريق exit.

إعداد حاوية الويب

لنقم بتعديل web_only.yml.

أولاً، قم بتغيير القالب وكشف المنافذ كما يفعل app.yml الخاص بك.

ثانيًا، تأكد من أنك تربط بحاوية البيانات الصحيحة. إذا قمت بإعادة تسمية data.yml إلى ‘something_else’ فقم بوضعه لـ ‘name’.

# استخدم مفتاح 'links' لربط الحاويات معًا، أي استخدم علامة Docker --link.
links:
  - link:
      name: data
      alias: data

على الرغم من أننا لا نريد كشف ssh أو أي منافذ أخرى بعد الآن، إلا أنك ستحتاج إلى كشف المنفذين 80 و 443 للوصول إلى الويب. يعتمد هذا على ما إذا كان لديك nginx يعمل في المقدمة وكيفية توصيل الحاوية به.

في مكان ما هناك ستجد هذه الكتلة:

  DISCOURSE_DB_USERNAME: discourse
  DISCOURSE_DB_PASSWORD: mypassword
  DISCOURSE_DB_HOST: data
  DISCOURSE_REDIS_HOST: data

• أدخل كلمة المرور التي قمت بتعيينها داخل حاوية البيانات.
• أدخل اسم مستعار لحاوية البيانات الذي كتبته للتو. لـ DB_HOST و REDIS_HOST. يجب أن يتطابق مع كتلة الروابط التي ذكرناها.
• من المحتمل أنك لم تغير DB_USERNAME.

ستجد القيم لـ DISCOURSE_DEVELOPER_EMAILS و DISCOURSE_HOSTNAME والعديد من القيم الأخرى. لديك بالفعل هذه القيم في app.yml الخاص بك. انسخها من هناك.

في قسم الخطافات (hooks) تذكر تعيين أي إضافات إضافية تستخدمها بالفعل داخل app.yml

الآن يجب أن تكون جاهزًا للتمهيد:
./launcher bootstrap web_only (مرة أخرى بالاسم الجديد/الخاص بك)

بمجرد التمهيد، يمكنك بدء تشغيل web_only (استخدم اسمك الجديد):
./launcher start web_only

عندما يصبح Discourse جاهزًا، قم بتسجيل الدخول واستعادة موقعك.

بعد ذلك، عمل كل شيء مرة أخرى بالنسبة لي وكان تثبيت discourse الخاص بي يعمل مرة أخرى، ولكن الآن في حاويتين منفصلتين.

كيفية التحديث عند استخدام حاويات ويب وبيانات منفصلة

إذا لم تهتم ببضع دقائق من التوقف عن العمل - أو عندما تحتاج البيانات إلى الترقية. التغييرات على postgres و redis نادرة، ويسمح ترك حاوية البيانات قيد التشغيل ببناء حاوية web_only جديدة بينما تعمل الحاوية القديمة.

./launcher stop web_only && ./launcher rebuild data && ./launcher rebuild web_only

هذا يعمل لترقية طفيفة لـ Postgres و/أو ترقية redis.

إذا كنت تهتم بكل دقيقة من التوقف عن العمل و لا تحتاج البيانات إلى الترقية (وهو الحال في معظم الأوقات):

ترقية web_only فقط:

./launcher bootstrap web_only && ./launcher destroy web_only && ./launcher start web_only

يكفي إعادة بناء web_only وتخطي data إلا عندما يكون هناك ترقية لـ postgres أو redis. تحدث هذه الترقية مرة واحدة تقريبًا في السنة وسترى إعلانًا مثل PostgreSQL 15 update عندما يحدث ذلك، على الرغم من أن الترقيات إلى redis وتحديثات postgres الطفيفة ليست معلنة بوضوح.

تتطلب إعادة بناء البيانات وقت توقف عن العمل (لنفس السبب الذي يجعل الإصدار ذي الحاوية الواحدة يتطلب ذلك - لا يمكنك ترقية postgres بينما تقوم عملية أخرى بالوصول إلى نفس ملفات قاعدة البيانات. أيضًا، عند إنشاء حاوية بيانات جديدة، يجب عليك تدمير وبدء تشغيل حاوية web_only لأنها ستحاول الاتصال بالحاوية القديمة).

لست بحاجة غالبًا إلى إعادة بناء حاوية البيانات (وهذا هو السبب في أن هذه الطريقة توفر وقت التوقف عن العمل). تحتاج إلى الانتباه إلى متى يكون هناك ترقية في postgres أو redis؛ الواجهة الأمامية لن تعرف؛ هذا إعداد متقدم يتطلب مزيدًا من الاهتمام من حاوية واحدة.

إدارة تثبيت ذي حاويتين

سيقوم @pfaffman بإنشاء موضوع حول هذا الأمر يومًا ما، ولكن حتى ذلك الحين، هناك هذا: Managing a Two-Container Installation - Documentation - Literate Computing Support

[downey (Michael Downey)]

This … didn’t work as expected.

(The instructions are a bit off but I followed the update at https://meta.discourse.org/t/faster-rebuilds/40341/4.)

Should the new 2-container installation present an empty/fresh site? I was assuming it would copy all of my settings & data from my app container, but it was brand new.

Edit: I did a restore from a backup made just before the process, and it seemed to restore everything. So probably this just needs to be made clear.

[fantasticfears (Erick Guan)]

I updated the guide. Hope it reflects your process.

[downey (Michael Downey)]

When someone like @sam puts out instructions to rebuild the “app” container for fixes like this one, is it safe to assume it’s generally going to be in the web_only container?

ImageMagick CVE-2016–3714

Fixed per: https://github.com/discourse/discourse_docker/commit/d47aa69bb72dea153b6901866bb66afe2cca6915 I will also rebuild the entire image next week when Image Magick do a new point release. To take advantage of the fix: cd /var/discourse ./launcher rebuild app

[sam (Sam Saffron)]

Yes, anything that mixes in the template I hacked get this.

[pmusaraj (Penar Musaraj)]

Sorry for the bump on this old conversation, but I had a related issue.

While doing server upgrades that included docker daemon upgrades, docker restarted, but when it did restart, it also restarted the standalone app container, which brought the site back to what it was pre-transitioning to separate containers. After panicking, I stopped the app container, and then started web_only again, and site is back to normal.

But how can I fix this permanently? I tried moving the app.yml file away from the containers folder, but the app docker container still restarts. Should I run ./launcher destroy app ?

P.S. I am mentioning this here, because I did successfully move from a standalone app container to separate data/web_only containers as described here.

[tophee (Christoph)]

Excuse my ignorance but could someone explain to me why this is not the default setup (or an optional setup) in the 30 min install guide?

I understand that using two containers minimizes the downtime during rebuilds and since nobody likes downtime, it seems like everyone would want two containers…

In other words: what’s the catch?

[jomaxro (Joshua Rosenfeld)]

@tophee

In other words: what’s the catch?

It’s more complicated to set up? More has to be done during setup? More potential points of failure? Harder to debug if you don’t understand Docker?

[pfaffman (Jay Pfaffman)]

@tophee

In other words: what’s the catch?

For people like you and me, there is none.

When the 30 minute install was conceived, it involved editing app.yml with a tool like nano (I’m an Emacs user and even I prefer vi to nano). Having people edit copy and edit two files and bootstrap and start both of them in the right order is on the order of 10 times more complicated. Now that ./discourse-setup is how most people configure Discourse, the setup part could be exactly the same for a two-container setup. I’ve looked in to doing just that & it wouldn’t be very hard.

But even still, with two containers, there would then be a bunch of problems with the data container wasn’t running and then no one would say which way their site was configured and that would be a lot more complicated to help out. Most of the time the web-based upgrade works just fine, and so unless you’re changing your plugin config, there’s not that much of a win for the two-container setup.

I think soon that I’ll start offering a two-container setup along side of my $99 install, but I’ve not gotten around to it.

[tophee (Christoph)]

@pfaffman

For people like you and me, there is none

So is everyone here just pretending that they’re running one container but privately they’re running two?

Well, I guess, maybe even for “people like you and me” it is more convenient with one container, given that you don’t change plugins so often.

On the other hand, on standard troubleshooting advice that keeps coming up is obviously “disable all apps and re-enable them onr by one” and unless you do that by just disabling them under settings, this will give you plenty of downtime with one container…

And when I see that people are talking about 10,000 visits per day, that is quite a few annoyed users, even for half an hour downtime.

Anyway, thanks for explaining. And, yes, you should offer the 2-container install, if only to make it better known

[pfaffman (Jay Pfaffman)]

@tophee

So is everyone here just pretending that they’re running one container but privately they’re running two?

No. Usually if someone posts a problem and they’re running multiple containers, they’ll mention that (probably because it’s a problem specifically with multiple containers), but mostly, if you know how to have multiple containers, it won’t make any difference that you do.

FWIW, it took me nearly 2 years to (bother to) figure it out. And six months of that time I was earning all of my income from Discourse consulting (not to say that the income I earned was a living all of that time).

I’d guess that the vast majority of people running Discourse have a single container. I’d guess that the vast majority of people* who earn some of their income from managing or hosting it* and/or would identify as a “system administrator” run two.

[net_deamon]

@tophee

In other words: what’s the catch?

It is not that hard too. You have app.yml file which contains both the properties of datasource and web related(which port discourse should run eg 9000, or the plugins config and the custom commands)

So you just divide the app.yml into data.yml and web.yml.
Data.yml will contain the datasources part from app.yml
While the web.yml will contain rest of config.

I usually use nginx webserver infront of discourse.
So I can rebuild another web contianer at say 9001, and reverse proxy to it from nginx.
Then I safely stop the previous web container running at 9000.
This swapping is done in few seconds… So there is no downtime.

[Berto]

Could use some help here:

@5minpause

Start with data.yml and set a password for the database. Then:

This is confusing. It states to do a step (set a password) but doesn’t state how to do that aforementioned step… and immediately says “then” do some other stuff. Are we missing instructions on setting this password here?

So I didn’t change any password because I don’t know how or what OP is talking about, but did run ./launcher boostrap data and got the following response:

[...bootstrap command running...]
Successfully bootstrapped, to startup use ./launcher start data

prompt$ ./launcher enter data
Error: No such container: data

Note that I didn’t rename anything, only copied the files. I simply have data.yml and web_only.yml in my /var/discourse/containers directory.

Thanks!

[5minpause]

I wrote this “guide” in May 2015. I do not use Discourse any more (stopped soon after). I do not know if any of these instructions still work or how things are done nowadays.

[Berto]

Thanks, people are still linking to it, going to just hire some help. Cheers!

[codinghorror (Jeff Atwood)]

Thanks for getting it started, we will take it from here!

[TheBestPessimist]

Is this still the good tutorial?

Or should follow

Configure Discourse to use a separate PostgreSQL server

Let’s say you’re using AWS RDS, or an existing PostgreSQL server managed elsewhere. It’s fairly straightforward to get Discourse to use such a setup, without needing to grant superuser privileges to anything that Discourse itself runs. Here’s how. Prerequisites Discourse requires PostgreSQL 13; if you try to run on a newer or older version, it might work, but we don’t guarantee it, and if something breaks in the future, you get to keep both pieces. We also require some extensions that are di…

or

Multisite configuration with Docker

While multisite is supported in the Discourse application, this is an advanced sysadmin setup. If you don’t know what you’re doing, do not set up multisite. The Discourse team is unable to provide multisite configuration support. If you wish to host multiple domains on a singled Docker setup, you’ll need a multisite configuration. Here are the basic building blocks for one. Understand hooks Multisite is a fairly advanced topic. Before attempting a multisite build, spend some time…

Right now both of those tutorials still leave me with questions :-/.

[Falco]

The 3 tutorials apply to 3 different situations, so pick the one that applies to what you want.

Running Discourse with a separate PostgreSQL server is for when you have an external PostgreSQL running somewhere else, like AWS RDS.

Multisite configuration with Docker is about running multiple Discourse instances inside the same container.

And this topic is about using different containers for data and web.

The three guides are for advanced users, and we recommend sticking to defaults for people who aren’t familiar with Discourse, containers and the whole sysadmin lingo.

[TheBestPessimist]

well, what i want is to be able to host 3 discourse forums on my own VM.

From that i understand that i need to

1. Separate the data and web containers (this also brings speedup when rebuilding the app)
2. Configure 2 other discourse instances (somehow?) for my 2 other forums.

So this is why i don’t know exactly how to approach this situation.

[fefrei (Felix Freiberger)]

@TheBestPessimist

Separate the data and web containers (this also brings speedup when rebuilding the app)

You may want to do that (mainly to reduce rebuild times), but this is not required, and doesn’t really have anything to do with running multiple sites.

To run three sites, you can either bootstrap them separately (which is rather easy, but triples resource requirements), or use these instructions for setting up multisite:

Multisite configuration with Docker

While multisite is supported in the Discourse application, this is an advanced sysadmin setup. If you don’t know what you’re doing, do not set up multisite. The Discourse team is unable to provide multisite configuration support. If you wish to host multiple domains on a singled Docker setup, you’ll need a multisite configuration. Here are the basic building blocks for one. Understand hooks Multisite is a fairly advanced topic. Before attempting a multisite build, spend some time…

I’m running a setup like this (i.e. multisite, but without separating data and web containers or any other fanciness), and this works fine, but setup is indeed a bit tricky.