Dockerfile: Resolve deps using pipenv/Pipefile(.lock)

[javabrett]

Been experimenting with pipenv for reproducible Docker image builds and came-up with this approach for httpbin.

It makes a couple of Docker cacheability improvements - mainly because Pipfile and Pipfile.lock are added on their own before deps are installed, so changes to the rest of the source-code won't cause a cache-miss and re-download of all the dependencies.

I'm curious as to whether this is an intended use of pipenv ... it seems to help solve the problems for installing as Applications (versus Libraries) with pinned versions for dependencies for a specific build.

With reference to #493, with this change the built Docker image should contain greenlet version 0.14.3 (the locked version), and not the latest 0.14.4 which would be resolved by setup.py.

Fixed #493.

[steffenschroeder]

I wonder why the was moved here? (Also the ‘WORKDIR’). Couldn’t we move them again to top so we can avoid adding additional docker layers for these if ‘Pipfile.lock’ changes?

[javabrett]

Thanks @steffenschroeder. Are you referring to the EXPOSE or the RUN pip3 (there might be a word missing from your question)?

In ordering statements, I tend to put things that folks might want to change locally more-frequently (e.g. as part of some dev/test cycle), that would cause little change themselves, towards the bottom of the file. That way if they need to be changed for some time, they only evict cache after them, which in this case is almost nothing as EXPOSE and CMD layers are almost free. Also the EXPOSE 80 belongs with the port 80 on the next line, since they will change together. EXPOSE is really only documentation anyway - nothing depends on it, so it should be late in the file.

WORKDIR could be avoided and is a behaviour change - prior to this the container default dir is /, this makes it /httpbin, which makes more sense to me. Either a WORKDIR or a cd /httpbin is required (in the first pip3 command) so that pipenv is in the correct directory containing Pipfile*.

This change does create extra layers, for the benefit of better Docker build-cache stick, which is only of real importance in a development-context. If Pipfile.lock changes then it follows that the dependencies layer needs to be rebuilt, along with all those after it. But splitting these means that changing only say core.py will no-longer invalidate the expensive download-and-install dependencies layer, which only depends on Pipfile and Pipfile.lock.

Note that the second pip3 command now only installs httpbin itself, since all the dependencies are already resolved.

[steffenschroeder]

Thanks @javabrett for clarification. Now, as I understand your intends better, I completely agree with it.
Splitting the installation of the dependencies and httpbin itself is very good.
The EXPOSE 80 makes, with your explaination, also sense for me.
👍