Hi.
I’m searching for a solution that don’t make me rebuild my Discourse when I install a new plugin, which cause a long downtime.
On some forum scripts (like PHPBB, FluxBB, etc…), we can install a plugin without causing a downtime.
I’m also looking for a solution to set a message when the users visits my rebuilding Discourse who says that the forum is currently in maintainance (instead of the web browser error).
Thanks!
「いいね!」 1
It’s really not possible to install a plugin without rebuilding afaik.
This can be done by setting up an offline page while rebuilding here is a guide:
This guide is intended for advanced users, who are already using nginx outside the docker container. By following this guide you make your setup more complicated and will loose some speed benefits like HTTP2 if you’re not running Ubuntu 16.04 or later. Proceed with caution!
When Discourse is rebuilding or starting up, your users will usually either see an error message from their browser…
[image]
…or a not-so-nice 502 error message from Nginx:
[image]
If you’re a perfectionist l…
「いいね!」 2
pfaffman
(Jay Pfaffman)
2018 年 5 月 30 日午後 2:32
3
The solution is to use a two-container install. This will let you build a new image while the old one keeps running. The amount of downtime is just what it takes to shutdown the old container and start the new one.
「いいね!」 7
Thanks, I will follow your solution.
A more advanced version can include a load balancer in front of the application container(s) to reduce downtime to a bare minimum right?
「いいね!」 1
pfaffman
(Jay Pfaffman)
2018 年 5 月 31 日午後 6:46
6
Yes, I’ve experimented with having HAproxy in front of two containers, so it should be possible to leave the old server running, crank up the new one, shut down the old one with no downtime. I’ve not yet gotten it working correctly, however.
「いいね!」 1
Can you tell me what kind of issues you had?
「いいね!」 1
pfaffman
(Jay Pfaffman)
2018 年 6 月 1 日午前 3:57
8
I’ll need to crank it up again and document it. It’ll take a while to figure it out again.
「いいね!」 1
klh
(Maciej Sopyło)
2020 年 7 月 22 日午後 12:01
9
スレッドの掘り起こしで申し訳ありませんが、この投稿が Google で上位に表示されているため、私も同じ「問題」に直面しました。Docker コンテナ内での操作が必要になるため、何をしているか分からない場合は本番環境での実施はお勧めしません。サーバーに SSH で接続した後の手順は以下の通りです:
サポートされていない操作を行います。いかなる保証もいたしません!
# cd /var/discourse
# ./launcher enter app
# su discourse
$ cd /var/www/discourse/plugins
$ git clone <plugin_git_url>
$ exit
# exit
# docker restart app
コンテナの起動中は少しダウンタイムが発生しますが、フルリビルドに比べるとはるかに高速です(最小構成の DigitalOcean ドロップレットでも数分ではなく数秒)。
「いいね!」 3
MakaryGo
(Makary Gołosz)
2020 年 7 月 22 日午後 2:34
10
こんにちは!
おそらく、こちらをお探しのようです:
Per Advanced Troubleshooting with Docker , the database is actually stored outside the container(s).
AFAIK the main advantage of separating containers (if you’re changing nothing else about the default install) is reducing downtime when you’re running ./launcher rebuild app. However it’s a bit outside my knowledge and not something I’ve attempted doing, so I wouldn’t be surprised if there were more reasons to do it.
As far as I can tell, this guide is lots of words around:
back up
create a completely new discourse instance, with more words but the same results as just running discourse_setup 2container
restore
Why wouldn’t you just move or copy /var/discourse/shared/standalone/{postgres,redis}* into /var/discourse/shared/data after a clean shutdown and before starting up two new containers from separate containers/*.yml files? A backup/restore seems like a really heavy-weight way to move all that data ac…
「いいね!」 1
pfaffman
(Jay Pfaffman)
2020 年 7 月 22 日午後 2:34
11
コンテナ内で
sv restart unicorn
を実行することもできます。これはコンテナ自体を再起動するよりもわずかに高速です。
また、一部のプラグインではデータベースのマイグレーションが必要になります。
「いいね!」 3