4 ms·

Wtf are you talking about? I've been running docker in production for 3 years (30+ microservice platform) with litterallly 0 of those problems. Caching works,

Wtf are you talking about? I've been running docker in production for 3 years (30+ microservice platform) with litterallly 0 of those problems. Caching works, hence why you need to clean your disk space. And multi stage builds are awesome for many circumstances. It sounds like you don't really understand how to use docker all that well.

cdoxsey 8y ago
You've never had docker do anything weird in production? It didn't happen often, but we definitely had problems. We're running kubernetes clusters with several hundred nodes. Caching is very crude. When building its based on lines in the dockerfile which means adding a dependency means redownloading everything. You also can't mount a directory for builds. Multi stage builds are very limited in what they can do and often aren't powerful enough to implement efficient builds. You end up either having 20 minute builds or complex make files to work around the inefficient default workflow. FWIW an intelligent caching mechanism should not require manual cleanup. Thankfully kubernetes does this for us in production... but the crazy 1 GB images you end up with for a moderately complex python app make it hard. (especially when people use :latest and then there are 12 versions of the app laying around)
- kinghajj 8y ago
  On our CI server, I setup an apt-cache container, and have a 'base' image derived from bitnami/minideb that sets the container's apt proxy to apt-cache. There's also Squid for HTTP caching, Archiva for Java artifacts, and Devpi for Python ones. So, sure, changes will require re-downloads, but they're pretty fast since everything's local. For getting multi-stage builds to work nicely, I just use a Makefile, defining separate targets for 'builder' images and 'runtime ones', and COPY artifacts from the former into the latter to form the final application images.

cdoxsey 8y ago

You've never had docker do anything weird in production? It didn't happen often, but we definitely had problems. We're running kubernetes clusters with several hundred nodes. Caching is very crude. When building its based on lines in the dockerfile which means adding a dependency means redownloading everything. You also can't mount a directory for builds. Multi stage builds are very limited in what they can do and often aren't powerful enough to implement efficient builds. You end up either having 20 minute builds or complex make files to work around the inefficient default workflow. FWIW an intelligent caching mechanism should not require manual cleanup. Thankfully kubernetes does this for us in production... but the crazy 1 GB images you end up with for a moderately complex python app make it hard. (especially when people use :latest and then there are 12 versions of the app laying around)

kinghajj 8y ago
On our CI server, I setup an apt-cache container, and have a 'base' image derived from bitnami/minideb that sets the container's apt proxy to apt-cache. There's also Squid for HTTP caching, Archiva for Java artifacts, and Devpi for Python ones. So, sure, changes will require re-downloads, but they're pretty fast since everything's local. For getting multi-stage builds to work nicely, I just use a Makefile, defining separate targets for 'builder' images and 'runtime ones', and COPY artifacts from the former into the latter to form the final application images.