Looks like a misconfiguration of your S3 bucket.
How did you install Discourse? Did you use Discourse official Standard Installation or perhaps was it Troubleshooting Bitnami Installations?
I’m putting my money on a misconfigured CDN.
Can you share your
And search your site settings for
c0fbtc and see if you get hits.
Ive installed it as a regular rails application. Below are the steps Ive followed.
- Cloned the github repo.
- Bundle installed the gems.
- Modified database.yml file to point to AWS RDS endpoint.
- Modified discourse.conf file for pointing to AWS Elasticache.
- Did not use S3 bucket configuration anywhere.
- Copied the code inside a docker container and deployed it on ECS.
I did not use the prebuilt docker image. Ive built a docker image myself.
That does not seem right. If I were you I would check if my database wasn’t actually local and has a weird name.
I think it should look like this:
# host address for db server
# This is set to blank so it tries to use sockets first
db_host = discourse-test.c0fbtc1q6bvm.ap-south-1.rds.amazonaws.com
# database name running discourse
db_name = default
What is S3 used for? And also do I need to create a separate discourse.conf file without changing anything in discourse_defaults.conf file?
This has nothing to do with S3.
The discourse.conf file is generated from your app.yml, you should make changes there and rebuild.
I cloned discourse from https://github.com/discourse/discourse I couldnt find app.yml file anywhere in the repo.
All the discourse setup is pointing to discourse_docker which I dont want to use. I want to build my own container.
(I must warn you for trying to reinvent a perfectly working wheel. Also, some people over here are not going to be very enthusiastic about supporting you since it does not benefit the community).
Whatever you do, eventually you should make sure that those values end up in your
discourse.conf correctly. If you edited it manually, you should at least put the AWS hostname in
db_host and leave db_name to
I am on the same team as Vijay. The specific use case we are trying to address here is to fork out Discourse and put in our company’s github. From here, we would build and deploy to AWS. The reason we want to have it in our github is to keep the flexibility of making changes as per our requirements. We would like to contribute back wherever applicable. Since we could not find a dockerfile in the discourse public repo, we ended up creating our own to build the docker image. Further, we use Github actions to deploy the docker to AWS ECS service.
Considering our requirement, do you think we could have taken any other approach?
Yes. My recommendation is to use the official discourse and discourse_docker repositories and implement all changes as plugins.
Using the official discourse_docker will save you from issues like the one in this topic, and not forking Discourse but keeping all your modifications in separate plugins save you from deviating from the main branch and having to put lots and lots of effort into porting all upstream changes back into your fork.
The learning curve of developing plugins will break even on the effort of merging upstream within a few weeks and from then on it is only more efficient.
When you are using the official Discourse repo then you can also consider managed hosting and people will be more enthusiastic (and/or less expensive) when they need to help you out.
Thanks for your inputs. Had a couple of follow-up questions:
- With the plug-in approach, is their a possibility that we might hit a bottleneck with some requirements which may not be possible through plug-ins? For instance, managing user roles in a very customized way?
- What would the end to end pipeline look like if we take the discourse_docker and deploy in our AWS account on ECS? As I mentioned, we use Github actions as of now to deploy to ECS in our AWS account. What deployment strategy can we use from public repo while still protecting our AWS credentials?
Always start with a copy of the discourse_docker repository. Create an
Use the bootstrap subcommand of the
launcher script in your working copy of discourse_docker to create a docker image. Push the docker image to a docker repository. Deploy that docker image anywhere you like.
Write plugins if you need to. List your custom plugins in the
app.yml like the other plugins.
@ashish_rawat @Vijay_Vantipalli How did you set up Discourse Docker in ECS? When I try on EC2 server, Discourse is loading fine. But when I push the Discourse Docker image to the ECR registry, and create a task from that image, the container is not running – I just get Exit Code 1. I’ve been stuck for more than a week now. I would love to hear your advise. Thank you!
Created a separate RDS instance and ElastiCache for Redis cluster for this.
Try examining the arguments present in
./launcher start-cmd app - there might be something in there that you’ve missed copying over to ECS.
Thank you for the fast response! I think I’m just missing something simple. I’ll try to do that.
Sorry if this is out of your scope. I tried adding the “-e” I found from start-cmd app, but there are other arguments like the following:
+ /usr/bin/docker run --shm-size=512m -d --restart=always
-h <server ip>
--name app -t -p 80:80
--mac-address <address> local_discourse/app /sbin/boot
-v really required?
Yes, those are volume mounts. It is absolutely required for Discourse to have storage available at
/shared inside the container.