4 ms·
I'm general, it's an anti pattern since it's makes everything much more complicated. The typical reason to have it is so that there are dev tools in the dev con
by twunde 3y ago
I'm general, it's an anti pattern since it's makes everything much more complicated. The typical reason to have it is so that there are dev tools in the dev container (autoformatter, linter etc) or support for hot reloading and then the prod container is locked down. The other pattern you'll sometimes see is that the prod container will include an agent or a certificate bundle, although it's more common to use sidecars for this.
It becomes problematic because it then becomes easy for engineers to have a completely different container for dev then is used for prod. I recently found an issue where a dev container was using a completely different base and had a different version of node installed compared to the prod container
- hedora 3y agoMulti-stage docker files mostly solve this problem: https://docs.docker.com/build/building/multi-stage/ https://docs.docker.com/build/building/multi-stage/
- opello 3y agoI agree that multi-stage builds help address this, but that also means there are different images.
- never_inline 3y ago> It becomes problematic because it then becomes easy for engineers to have a completely different container for dev then is used for prod If the differences between dev and prod are also programmatic in nature (eg based on flag, and mostly configuration-like values), it should be fine.