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 によって行われた変更を加えて作成された新しいイメージを、各デプロイごとにブートストラップしているのでしょうか？それとも、単一のイメージを使用し、起動時にアセットをプリコンパイルするだけなのでしょうか？
技術的には、2 回プリコンパイルを行います。1 回目はベースイメージと当社の変更分に対して、2 回目は特定のプラグインを搭載した特定サイトを展開する際に行います。
ただし、当社の設定は、Discourse をビジネスとしてホストしている場合でなければ採用すべきものではありません。
Discourse をぜひ使いたいのですが、開発者たちがコンテナ技術を利用しているこの方法が、私を Discourse の使用から遠ざけています。コンテナのインストールをこれほど非移植的にしているプロジェクトはこれまで見たことがありません。これを解決するもっと良い方法はいくらでもあります。このプロジェクトは、コンテナに向かって有機的に発展してきたように見えますが、コンテナの正しい使い方を理解していないようです。その結果、このプロジェクトは過度に複雑で非移植的な解決策に縛られてしまっています。おそらく時間の制約もあり、適切な移植性のあるコンテナを作成する余裕はないのでしょう。
ぜひ、一貫した状態を構築する Dockerfile を提供してください。コンテナの動作を制御するためにユーザーが使用するべき環境変数をドキュメント化してください。また、単にエントリーポイントスクリプトを使用して、すべてのプロセスをランタイムで起動するようにしてください。コンテナの組み合わせは Docker Compose や Kubernetes で行うべきです。しかし、このようにするのは本当に微妙です。
私はこれを例えば Fedora CoreOS、CentOS 8、または Fedora 32 で実行しようとしています。しかし、それは不可能です。コンテナの標準規格では確かに可能はずです。しかし、これは事実上 Ubuntu LTS のみをサポートするように細工されたやり方です。一部のユーザーはすでに Docker から離れています（特にサービスを root として実行する場合など）。コンテナは標準化されているため、ユーザーは Docker か Podman かを選ぶことができます。しかし、このフランケンシュタインのような構成はそれを非常に困難にし、コンテナの概念や現代のコンテナセキュリティに反しています。
2014 年頃の状況を見てみてください。このプロジェクトが始まった当時、docker-compose はまだ一般的ではありませんでした。
その通りですね！もしかしたらあなたが修正できるかもしれません。コンテナのビルドや起動方法についてすべてを変更し、それが数千もの稼働中のサイトを壊さないことを確認するだけです。
あるいは、コンテナの正しい使い方を理解している人々が好む任意のツールで起動できるようにするコンテナを作成することもできます。Bitnami はそれを成功させています。ここでは多くの人が問題に直面し、助けを求める先がない状況について検索して見つけることができます。
簡単ではないことは承知しています。しかし、コンテナの目的は、一貫性のある移植可能な状態を実現することです。したがって、コンテナが本来あるべきように使用され、あなたにとって機能しているなら、そのコンテナを使用するすべての人にとっても機能する可能性はかなり高いでしょう。
ブートストラップ処理自体をホスト側ではなくコンテナ内部に移動させれば、移植性の向上においてすでに大きな進歩を遂げることができます。他のプロジェクトを終わらせたら、確認してみます。私もコンテナの専門家ではありませんが、いくつか構築した経験があります。ただし、欠点として、インストールに関するドキュメントが存在しないということですね。単に「これを実行してください」とスクリプトを渡すだけという状況です。スクリプトが何を行っているかを再現することはできますが、改善提案の余地はあまり残されていません。
したがって、コミュニティ、特にインストールの仕組みについて内部情報を持っている関係者の方々が助言や協力をする意思があれば、このイニシアチブを開始する用意があります。そうでなければ、求める品質には達しないでしょう。
目標は概ね以下の通りです：
- ローカルでのブートストラップ（コンテナ外）を行わず、セットアップのアトミックなビルドを実現する Dockerfile
- コンテナを root として実行する必要をなくすこと。最善策は fakeroot を使用し、capabilities を追加することです（これらはコマンドライン引数であり、ユーザーは依然として root としてコンテナを起動することを選べます…）
- 環境変数によって制御可能なエントリーポイントスクリプトを作成し、それらの変数を明確に文書化すること
podman-generate-systemdまたは同様の機能を使用して、コンテナの（再）起動や起動時の自動起動を行う systemd ユニットを作成すること（Podman の機能です。Docker にも類似のものがあるかもしれませんが、こちらはより統合的なアプローチです）
これが基本インストールの要件となります。スケーラブルなソリューションについては、docker-compose と Kubernetes のソリューションが必要になります。正直なところ、「すべてに当てはまる」解決策を見つけることは Discourse コミュニティの責任ではないと考えています。なぜなら、特に Kubernetes においては、これらは非常にきめ細かくカスタマイズ可能だからです。したがって、人々がすぐに使い始められるための基本的な compose ソリューションで十分だと考えます。
これにより、移植性が高く、より安全なソリューションが提供され、全体的な採用率と品質が向上します。その間、Discourse が私のコミュニティに本当に必要なものかどうかを確認します。必要であれば、当面は Ubuntu LTS システムを使用します。時間ができたら、そのようなセットアップに時間を投資する予定です。
こんにちは @AquaL1te さん、
ご提案いただいた内容の一部を実装しました。Podman、Kubernetes、または Docker を使用可能です。Rootless モードもサポートされています（fakeroot は除く）。構成は Nginx、Sidekiq、Redis、Ruby デーモンの 4 つのコンテナで構成されています。
一般的には、開発者向けのインストールドキュメントに従って進めることができます。
ただし、Discourse がアセットを扱う方法にはいくつかの厄介な側面がある点に留意してください。
ああ、そうですか。用語で混乱していました。最近 Singularity をよく使っていて、そこでは --fakeroot フラグを使用します。
確認してみます、とても良さそうです！私はこの用途には Fedora CoreOS を使うのが好きなので、コンテナ化された環境のセキュリティポテンシャルを最大限に引き出したいと考えています。しかし、現在の設定ではそれを容易に行うことはできません。
主要なソリューションが移植性を持たず、現代的な解決策への兆しが見られないことがまだ気になります。あなたの設定をより詳しく調べてみます。将来的には、必要であれば共同メンテナーとして連絡するかもしれません。もちろん、必要であればですが。あなたの取り組みと提案に感謝します！
この長大なスレッド全体を読み終えたところ、特にGkoerkの要望に強く共感しました。彼が2018年10月19日に上記でコメントし、Swarm環境でのDiscourseの自己ホスト化に関するサポートを求めていました。どうやら、彼が作成した壮大なdocker-swarm-cookbookに組み込むためだったようです。すばらしいコレクションですね。Gkoerk氏は40歳という若さで逝去されたとのことです。なんてことだ。本当に素晴らしい人物で、貢献者でもあったように思えます。