Using pipenv and Docker#
I had a Django project that used pipenv
(in particular a Pipfile.lock
) to manage dependencies and I wanted to build a Docker container for it.
With the help of this article (for the PIPENV_VENV_IN_PROJECT
tip) I came up with the following:
1FROM python:3.6.15-slim-buster2
3RUN mkdir -p /app4WORKDIR /app5
6COPY . .7
8ENV PIPENV_VENV_IN_PROJECT=19
10RUN pip install pipenv11RUN pipenv sync12
13RUN pipenv run ./manage.py collectstatic --noinput14
15EXPOSE 800016
17CMD pipenv run gunicorn --bind 0.0.0.0:8000 --timeout 120 --workers 2 cbwg.wsgi
Ignore the base image - the project was an emergency port from Heroku and I didn’t have time to upgrade it from the ancient version of Python it was using (if you’re using a Pipfile.lock
file you need to keep your Python version stable unless you want to lock new versions).
The key lines here are these ones:
1RUN mkdir -p /app2WORKDIR /app3
4COPY . .5
6ENV PIPENV_VENV_IN_PROJECT=17
8RUN pip install pipenv9RUN pipenv sync
First we create a /app
directory and set that as the working directory.
COPY . .
copies ALL files and directories from the Dockerfile
directory into the new image, inside /app
.
ENV PIPENV_VENV_IN_PROJECT=1
is important: it causes the resuling virtual environment to be created as /app/.venv
. Without this the environment gets created somewhere surprising, such as /root/.local/share/virtualenvs/app-4PlAip0Q
- which makes it much harder to write automation scripts later on.
Then we install pipenv
and use RUN pipenv sync
to install all of the package versions from our Pipfile.lock
file (which was added by COPY . .
).
Alternative using pipenv sync —system#
You can avoid creating a virtual environment in your Docker image entirely using pipenv sync --system
, which instead installs the packages in the Docker container’s system Python:
1FROM python:3.6.15-slim-buster2
3RUN mkdir -p /app4WORKDIR /app5
6COPY . .7
8RUN pip install pipenv9RUN pipenv sync --system10
11RUN ./manage.py collectstatic --noinput12
13EXPOSE 800014
15CMD pipenv run gunicorn --bind 0.0.0.0:8000 --timeout 120 --workers 2 cbwg.wsgi
But this carries its own risks, as described here by Hynek Schlawack.
The key problem is that the operating system itself may have already installed specific package versions in site-packages
, and there’s a risk that these might conflict with the versions of those packages used by your own application.
So Hynek advises:
Do isolate your application server’s OS from its host using Docker […] But inside of them also do isolate your Python environment using virtualenv from unexpected surprises in the system site-packages.