Good stuff.
A few things I’d change:
- A CLI to simplify local vs docker vs cloud operations. Reduces chance of operator error. Have had good luck with python click library.
- Moving config settings into separate JSON and .env files to avoid loading too many config and secrets in the docker-compose file.
- For AWS, I’d go with CDK. That way, cloud deployment is all in python (or typescript).
- For cloud, you can also package Django into a single lambda, with dependencies inside a lambda layer. Not sure I’d use it in heavy production, but for small apps, really handy.
- Inside Django settings, you can switch DB and services whether running local (sqlite, Redis), docker (postgres, RabbitMQ), or cloud (RDS, SQS).
OK, you wanted a conversation… :-)
I did read the post, but I assumed it was the starting point of a system or mechanism, not the end-point. Wanting to just run “docker compose up” is fine, but there is more to developing and deploying to production (and continuing post-launch).
That’s why I mentioned the CLI. It lets you go from a simple local app (Django on sqlite) to a Docker one (postgres, celery, redis, etc.), to all the way out to the cloud (ECS/EKS/serverless lambda/RDS), without having to remember what commands do what or managing lots of separate docker-compose files.
I can see we are VERY far apart on how docker should be used in moving toward a production-ready system.
For one thing, recommending putting secrets inside docker-compose is an instantly disqualifying piece of advice. There’s a whole ‘secrets’ section of docker compose that is there to prevent people from inadvertently including those in cleartext and baking them into images: https://docs.docker.com/compose/how-tos/use-secrets/.
Github itself has a secret scanning mechanism to prevent leakage: https://docs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning. For gitlab, there’s also Blackbox or HashiCorp vault. Putting AWS key/secret inside a repo can be VERY expensive and open one to legal liability if the account is misused. Repeated infractions could lead to AWS banning one’s account.
I really recommend you take down that part of your post, instead of proliferating bad practices.
As for the rest, to each their own.