Op 15-06-16 om 13:53 schreef Jim Fulton:
- Creating production docker images works best when all you're doing
is installing a bunch of binary artifacts (e.g. .debs, eggs, wheels).
That's where pip and its "everything is in requirements.txt anyway" has an advantage. The buildouts I use always have most/all dependencies mentioned in the setup.py with version pins in the buildout config. So I need the setup.py and so I need my full source code as the setup.py won't work otherwise.
I *do* like to specify all "install_requires" items in my setup.py, so this is something I need to think about.
- IMO, you're better off separating development and image-building
workflows, with development feeding image building. Unfortunately, AFAIK, there aren't standard docker workflows for this, although I haven't been paying close attention to this lately.
docker-compose helps a little bit here in that you can "compose" your docker into several scenarios. It *does* mean you have to watch carefully what you're doing, as one of the goals of docker, as far as I see it, is to have a large measure of "production/development parity" as per the "12 factor app" manifesto (http://12factor.net/)
- As far as setting up a build environment goes, just mounting a host
volume is simple and works well and even works with docker-machine. It's a little icky to have linux build artifacts in my Mac directories, but it's a minor annoyance. (I've also created images with ssh servers that I could log into and do development in. Emacs makes this easy for me and provides all the development capabilities I normally use, so this setup works well for me, but probably doesn't work for non-emacs users. :) )
I, like any deranged (and effective) human being, have memorized lots of emacs shortcuts and will use it till the day I die. Sadly I have colleagues that are a little bit more sane :-)