I don’t mean to be snarky, but I feel like you didn’t actually read the post 'cause pretty much everything you’ve suggested is the opposite of what I was trying to say.
- A CLI to make things simple sounds nice, but given that the whole idea is to harmonise the develop/test/deploy process, writing a whole program to hide the differences is counterproductive.
- Config settings should be hard-coded into your docker-compose file and absolutely not stored in
.json
or.env
files. The litmus test here is: “How many steps does it take to get this project running?” If it’s more than 1 (docker compose up
) it’s too many. - Suggesting that one package Django into a single Lambda seems like an odd take on a post about Docker.
I feel like you must have read an entirely different post, which must be a failing in my writing.
I would never condone baking secrets into a compose file, which is why the values in
compose.yaml
aren’t secrets. The idea is that your compose file is used exclusively for testing and development, where the data isn’t real, and the priority is easing development. When you deploy, you don’t use that compose file because your environment is populated by whatever you use in production (typically Kubernetes these days).You should not store your development database password in a
.env
file because it’s not a secret. The AWS keys listed in the compose are meant to be exactly as they are there:XXX
, because LocalStack doesn’t care what these values are, only that they exist.As for the CLI thing, again I think you’ve missed the point. The idea is to start from a position of “I’m building images” and therefore neve have a “local app, (Django, sqlite)” because sqlite should not be used unless that’s what’s used in production. There should be little to no difference between development and production, so scripting a bridge between these doesn’t make a lot of sense to me.