האם תמונת ה-Docker discourse/discourse נחשבת בטוחה ומוכנה לייצור?

Hello !
I registered just to say thanks a lot to all for your help, particularly @featheredtoast
I almost got it to work, but the mail sending wasn’t working.
I suppose it was because I have caddy as a reverse proxy.

So now I’m back to using discourse separately from all the other services on my docker compose setup.

Do you know how I could make it work with Caddy ? I suppose I have to make it use a socketed example, but I don’t know how to modify the app.yml inside the docker-compose discourse config.

All the best to you - Y

Unless you’re somehow having Caddy proxy your outgoing email, I don’t think it’s related.

You don’t have to make it socketed, you can just refer to the docker name and/or IP. Discourse working with jwilder /nginx proxy & acme-companion - #7 by Steve_Emerson talks about using the socketed template and a bunch of other stuff.

So, short answer, no, not through docker-compose on its own – it’s something I’d like to see, but the plan here is to allow anyone to create a customized base image that can be shared publicly to push the ball forward. Building a plugin involves cloning the plugin, bundle install, npm, and recompiling ember… This should not be done on boot.

So part of the idea here is to allow images to build just as discourse/discourse is – with the same app.yml as the supported Discourse versions are running.

As a sample, I’m building my personal image with resenha by updating the core app.yml to include the plugin here and then pushing it up to an external (public!) docker registry.

If you’re using an external mail service, I don’t think your caddy reverse proxy probably isn’t the problem. Unlike the current launcher builds, discourse/discourse will not nag you about setting up your email env vars (but it’s still necessary to do) – I’d check those first.

I have managed to change the upload size limit:

cat fix-upload-size.sh (which needs to be chmod +x):

#!/bin/sh
sed -i 's/client_max_body_size .*;/client_max_body_size 500m;/' /etc/nginx/conf.d/discourse.conf

in docker-compose.yml:

    volumes:
     - ./fix-upload-size.sh:/etc/runit/1.d/fix-upload-size

I’ve been able to build an image but “only” using the ESR version. When I use something newer than that, the build process does require a database and a redis instance. Is that intentional?

Is there any way to upgrade Discourse to the latest version when using this image?

I’m using it for my faculty’s research group forum and would like to update to the latest Discourse release, but the image hasn’t been updated since March. What would be the recommended way to upgrade?

That was an unintentional side effect of adding a call to clearing stuck web upgrades; I’m looking to resolve this soon via FIX: run clear_stuck_web_upgrades during precompile stage · Pull Request #1055 · discourse/discourse_docker

Awesome, thank you!

But I have another question, I’m using Azure for students and I am using Container Apps. If I somehow upgrade inside the app, I’m afraid that if the instance Discourse is running fails for some reason, it may render our forum in disarray, because when it restart it will probably be in a previous version.

Once again Thank You!

That is a risk - there’s unfortunately no good way around that other than making sure the image is up to date if you’re upgrading both in the app and updating by pulling images from the docker repo. I really wouldn’t recommend doing so.

Meantime, I’m still getting the docker repo sorted (there’s another issue to tackle here).