On Wed, Jun 15, 2016 at 12:07 PM, Reinout van Rees email@example.com wrote:
Now local development: it is normal to mount the current directory as /code/, so that now is overlayed over the originally-added-to-the-docker /code/.
This means that anything done inside /code/ is effectively discarded in development. So a "bin/buildout" run has to be done again, because the bin/, parts/, eggs/ etc directories are gone.
Think of it like this: if you don't mount ./ as /code in the container then you practically have to rebuild the image all the time. This is fine for toy projects, but bigger ones have lots of files (eg: templates, images, css, tons of js 1-line modules etc). That means you get a big context that is slow to send (exacerbated in situations that have remote docker daemons like osx/windows docker clients).
Another compound problem: if you rebuild the image for every code change the new context will invalidate the docker image cache - everything will be slow, all the time. Ideally you'd have a stack of images, like a base image that takes big context (with code/assets) + smaller images that build from that but have very small contexts. I wrote some ideas about that here https://blog.ionelmc.ro/2016/05/07/dealing-with-docker/#optimizing-the-build-process if you have patience (it's a bit too long read).
Basically what I'm saying is that you got no choice but to mount stuff in a development scenario :-)
Regarding the buildout problem, I suspect a src-layout can solve the problem:
- you only mount ./src inside container - you can happily run buildout inside the container (assuming it don't touch any of the code in src)
I suspect you don't need to run buildout for every code change so it's fine if you stick that into the image building.
Thanks, -- Ionel Cristian Mărieș, http://blog.ionelmc.ro