The discussion revolves around deploying Discourse in AWS ECS or similar container orchestration environments. lktmxjv is looking for a straightforward way to deploy Discourse using Terraform, with environment variables to connect to Postgres, Redis, SMTP, etc. However, codinghorror explains that Discourse requires control over its elements within its container for a successful setup, making it difficult to deploy in complex multiple container scenarios.
lktmxjv questions the need for a bootstrap script and suggests that the Discourse image could accept environment variables and create the necessary resources. codinghorror and pfaffman advise against this approach, citing the simplicity and cost-effectiveness of a single Docker install image.
schleifer provides an alternative solution, referencing the discourse_docker repository and the samples/web_only.yml file, which shows how to use external resources. The launcher script is also capable of building a custom Docker image with the bootstrap subcommand. This approach may be suitable for those who need to deploy Discourse in a cloud environment.
I’ve read threads like this and others, and it seems like to date, there’s no easy way to pop a Discourse image into something like ECS, or GKE or whatever container orchestration you like and have it work easily…
I use Terraform to manage an Elasticache cluster, an RDS instance, and an ECS cluster. I just want to be able to say, “Here’s my Discourse image, and here are the environment variables to connect to Postgres, Redis, SMTP, etc.”
Does anything like this exist in 2020? It seems like in all the conversations around this topic previously, no satisfying resolution was reached, and we’re still stuck with Discourse’s custom scripts that defy container conventions and break compatibility with the idiomatic way people use containers…
This is an incorrect assumption. All of those are elements of Discourse, and need to be controlled by Discourse within its container to guarantee successful setup.
If you get into complex multiple container scenarios, that’s only necessary for large customers with lots of $, and I’d refer you to our enterprise hosting service..
Why’s that require this weird bootstrap script that launches containers and acts as an orchestrator though?
Why can’t the Discourse image accept env variables and in its entrypoint reach out to all those resources and create the tables it needs, etc.? Other services / web apps that rely on external persistence tiers have been successfully containerized in this way. You just pop them into an ECS or EKS or whatever, tell them where to find the database, etc., and it all works great. Is this possible with Discourse?
It’s because we’re the opposite—a non-profit org without tons of budget—that we want to keep things as cheap as possible by throwing all our enterprise apps onto a single AWS ECS host. But that requires that the individual apps are neatly containerized and can be defined as ECS task definitions, i.e., self-contained Docker images.
Well, sort of – given that Discourse easily fits into a $5/month VPS as a straightforward single Docker install image, I’m not sure squeezing a few pennies out of that number – with a massive increase in install difficulty and ongoing maintenance complexity – is really worth the hassle? Keep it simple!
As the above link describes, you can build containers and launch them with kubernetes. I’ve done GKE deployments for some clients who insisted on it because they were tied to the platform.
If your goal is saving money then a $5 to $10/month is the way to go.