Don’t know how to activate python Virtualenv in Dockerfile? We can help you.

To package Python application in a Docker image, we often use virtualenv. To use virtualenv, we need to activate it.

As part of our Docker Hosting Support, we assist our customers with several Docker queries.

Today, let us see an effective method to activate python virtualenv in Dockerfile.

Activate python Virtualenv in Dockerfile

We don’t have to use virtualenv inside a Docker Container.

Our goal is to prevent any dependencies or packages installed from leaking between applications. Docker achieves this.

Therefore, unless we run multiple apps in the same container, we don’t need to use virtualenv inside a Docker Container

For this to work, we need to architect our app in a better way and split them up into multiple containers.

The general solution is to blindly convert a shell script into a Dockerfile. The output will look right. However, it is actually broken:

FROM python:3.8-slim-buster
RUN python3 -m venv /opt/venv

# This is wrong!
RUN . /opt/venv/bin/activate

# Install dependencies:
COPY requirements.txt .
RUN pip install -r requirements.txt

# Run the application:
COPY myapp.py .
CMD [“python”, “myapp.py”]

Another method is to explicitly use the path to the binaries in the virtualenv.

In more complex situations, we need to repeat it. However, repetition is a source of error. As we add more calls to Python programs, it can forget to add the /opt/venv/bin/ prefix.

However, in most cases it might work:

FROM python:3.8-slim-buster

RUN python3 -m venv /opt/venv

# Install dependencies:
COPY requirements.txt .
RUN /opt/venv/bin/pip install -r requirements.txt

# Run the application:
COPY myapp.py .
CMD [“/opt/venv/bin/python”, “myapp.py”]

The problem here is that if any Python process launches a sub-process, it will not run in the virtualenv.

The most recommended solution, however, is to activate the virtualenv separately for each RUN as well as the CMD:

FROM python:3.8-slim-buster

RUN python3 -m venv /opt/venv

# Install dependencies:
COPY requirements.txt .
RUN . /opt/venv/bin/activate && pip install -r requirements.txt

# Run the application:
COPY myapp.py .
CMD . /opt/venv/bin/activate && exec python myapp.py
(The exec is there to get correct signal handling.)

What activating does?

We can see that activation does a number of things, including:

• Figures out what shell we are running.
• Adds a deactivate function to our shell and messes around with pydoc.
• Changes the shell prompt to include the virtualenv name.
• Do not set the PYTHONHOME environment variable, if someone happened to set it.
• Sets two environment variables: VIRTUAL_ENV and PATH.

Most of it irrelevant to Docker usage. However, some tools, for instance, the poetry packaging tool use it to detect whether we run inside virtualenv.

Setting PATH is an important task. It is a list of directories for commands to run. “activate” simply adds the virtualenv’s bin/ directory to the start of the list.

We can replace activate by setting the appropriate environment variables.

Our output will be the following Dockerfile:

FROM python:3.8-slim-buster

ENV VIRTUAL_ENV=/opt/venv
RUN python3 -m venv $VIRTUAL_ENV
ENV PATH=”$VIRTUAL_ENV/bin:$PATH”

# Install dependencies:
COPY requirements.txt .
RUN pip install -r requirements.txt

# Run the application:
COPY myapp.py .
CMD [“python”, “myapp.py”]

The virtualenv will now work for both RUN and CMD, without any repetition or need to remember anything.

[Stcuk with the procedures? We’d be happy to assist]

Conclusion

In short, to package Python application in a Docker image, we often use virtualenv. However, to use virtualenv, we need to activate it.