4 ms·
I don't understand his "Avoiding 2 Compose Files for Dev and Prod with an Override File" point. He just says it, but never justifies it.
by mdoms 5y ago
I don't understand his "Avoiding 2 Compose Files for Dev and Prod with an Override File" point. He just says it, but never justifies it.
- randompwd 5y agoIt's a terrible idea that's why. It comes with far more(&more dangerous) downsides than upsides. It's a rookie mistake for simple applications which most people learn to not do.
- reportt 5y agoThe idea is that you have a core structure that is used in both local/dev environment and the prod environment, with just the override applying changes. For example, your local override might have the "build" configuration, whereas the dev environment or production environment docker-compose should not have that configuration (assuming you are pulling from a private registry). That single core docker-compose.yml can be copied to any environment it needs and it should just run the app, but if you really, really need to override something for a specific reason, it's not hard to do it without modifying the core docker-compose.yml.
- trinovantes 5y agoProbably so you don't have duplicate settings in docker-compose.prod.yml and docker-compose.dev.yml when the only difference is probably just 1 line specifying NODE_ENV etc.
- nickjj 5y agoHi, It's mentioned on video and briefly in the blog post. It's so you don't have to duplicate a bunch of services between 2 files while you slightly change a bit of configuring for those services depending on the environment you're in, or even running different containers all together (which is the problem the override file solves).