Op 15-06-16 om 11:31 schreef Ionel Cristian Mărieș via Distutils-SIG:

... I wrote some ideas about that here https://blog.ionelmc.ro/2016/05/07/dealing-with-docker/#optimizing-the-build... if you have patience (it's a bit too long read).

I definitively have the patience for such a long read. Reading it definitively also made sure I won't ever see Docker as a potential magic bullet :-)

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)

src/* for the mr.developer checkouts and my_package_dir/ for the actual code. And take care when you're downloading/developing javascript stuff, too, as that might also be in another directory. Ok... I'll have to watch out. Good to have a potential working solution, though. Reinout -- Reinout van Rees http://reinout.vanrees.org/ reinout@vanrees.org http://www.nelen-schuurmans.nl/ "Learning history by destroying artifacts is a time-honored atrocity"

On Jun 15, 2016, at 7:53 AM, Jim Fulton wrote:

If you actually build programs as part of image building, then your image contains build tools, leading to image bloat and potentially security problems as the development tools provide a greater attack surface.

This isn’t strictly true, the layering in Docker works on a per RUN command basis, so if you compose a single command that installs the build tools, builds the thing, installs the thing, and uninstalls the build tools (and cleans up any cache), then that’s roughly equivalent to installing a single binary (except of course, in the time it takes). — Donald Stufft

Op 15-06-16 om 13:53 schreef Jim Fulton:

1. 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.

3. 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/)

5. 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 :-) Reinout -- Reinout van Rees http://reinout.vanrees.org/ reinout@vanrees.org http://www.nelen-schuurmans.nl/ "Learning history by destroying artifacts is a time-honored atrocity"

On 16 June 2016 at 05:01, Jim Fulton wrote:

I'm a fan of docker, but it seems to me that build workflow is a an unsolved problem if you need build tools that you don't want be included at run time.

For OpenShift's source-to-image (which combines builder images with a git repo to create your deployment image [1]), they tackled that problem by setting up a multi-step build pipeline where the first builder image created the binary artifact (they use a WAR file in their example, but it can be an arbitrary tarball since you're not doing anything with it except handing it to the next stage of the pipeline), and then a second builder image that provides the required runtime environment and also unpacks the tarball into the right place. For pure Python (Ruby, JavaScript, etc) projects you'll often be able to get away without the separate builder image, but I suspect that kind of multi-step model would be a better fit for the way buildout works. Cheers, Nick. [1] https://github.com/openshift/source-to-image -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On Wed, Jun 15, 2016 at 3:52 PM, Reinout van Rees wrote: [...]

It is a very valid point that seems to point solidly at wheels. As, if you use a virtualenv, you don't have access to system python packages. And that's one of the main reasons why the company I work for (still) uses buildout. Buildout has the "syseggrecipe" package that makes it easy to use specific system packages. So.... numpy, psycopg2, matplotlib, mapnik, scipy, hard-to-install packages like that.

So once you use a virtualenv, you're either in a hell because you're compiling all those hard-to-compile packages from scratch, or you're using binary wheels.

Of your list above, I know numpy and scipy now ship manylinux1 wheels, so you don't need to compile them. matplotlib has manylinux1 wheels posted to their mailing list for testing for a few weeks now -- I suspect they'll upload them on for real any day now. Maybe you should nag the psycopg2 and mapnik developers to get with the program (or offer to help) ;-).

Once you've chucked everything into a wheel, there's suddenly a bit less of a necessity for docker. At least, that might be the case.

On the other hand, I could imagine having a base 16.04 docker that we build to instead of a manylinux1 machine that we build to.

Using a manylinux1 image for building is necessary if you want to distribute wheels on PyPI, but if you're just building wheels to deploy to your own controlled environment then it's unnecessary. You can install manylinux1 wheels into a 16.04 docker together with your home-built 16.04 wheels. -n -- Nathaniel J. Smith -- https://vorpus.org

On Jun 15, 2016, at 7:54 PM, Ionel Cristian Mărieș via Distutils-SIG wrote:

A sound argument. However, none of that applies to a Docker image. You'd have a single set of dependencies, so what's the point of using unnecessary tools and abstractions. :-)​

Of course It still applies to Docker. You still have an operating system inside that container and unless you install zero Python using packages from the system then all of that can still conflict with your own application’s dependencies. — Donald Stufft

On Jun 15, 2016, at 8:10 PM, Ionel Cristian Mărieș wrote:

​You're correct, theoretically. But in reality is best to not stick a dozen services or apps in a single docker image.

It’s not really about services as it is about things that you might need *for the service*. For instance, maybe you want node installed so you can build some static files using node.js tooling, but node requires gyp which requires Python. Now you install a new version of setuptools that breaks the OS installed gyp and suddenly now you can’t build your static files anymore. A virtual environment costs very little and protects you from these things. Of course, if you’re not using the System python (for instance, the official Python images install their own Python into /usr/local) then there’s no reason to use a virtual environment because you’re already isolated from the system. — Donald Stufft

On Wed, Jun 15, 2016 at 5:10 PM, Ionel Cristian Mărieș wrote:

On Thu, Jun 16, 2016 at 2:57 AM, Donald Stufft wrote:

...

Of course It still applies to Docker. You still have an operating system inside that container and unless you install zero Python using packages from the system then all of that can still conflict with your own application’s dependencies.

You're correct, theoretically. But in reality is best to not stick a dozen services or apps in a single docker image. What's the point of using docker if you're having a single container with everything in it? Eg: something smells if you need to run a supervisor inside the container.

If we're talking about python packages managed by the os package manager ... there are very few situations where it makes sense to use them (eg: pysvn is especially hard to build), but other than that? Plus it's easier to cache some wheels than to cache some apt packages when building images, way easier.

The problem is that the bits of the OS that you use inside the container might themselves be written in Python. Probably the most obvious example is that on Fedora, if you want to install a system package, then the apt equivalent (dnf) is written in Python, so sudo pip install could break your package manager. Debian-derived distros also use Python for core system stuff, and might use it more in the future. So sure, you might get away with this, depending on the details of your container and your base image and if you religiously follow other best-practices for containerization and ... -- but why risk it? Using a virtualenv is cheap and means you don't have to know or care about these potential problems, so it's what we should recommend as best practice. -n -- Nathaniel J. Smith -- https://vorpus.org