I am running disource on aws ecs. When I am trying to run the application, the console tab in browser is failing with the below urls. Did I miss any configuration change?
I have given the above end point in database.yml file.
I deployed discourse in ECS using docker. When I try to access the application the network browser is fetching resources from below URLs instead of https://discuss-stage.tllms.com/
I’m putting my money on a misconfigured CDN.
Can you share your config/discourse.conf ?
And search your site settings for c0fbtc and see if you get hits.
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
(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 default.
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 app.yml therein.
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.
