CODEWITHSUNDEEP
pythondockerpipvirtualenv
Baily
Baily

Reputation: 1380

Docker Virtualenv

With containerized applications such as Docker, is it possible to use virtualenv such that the environment stays running from the build process, to when the image is finally run? It seems that creating a virtualenv via pip and running the environment never seems to work.

For example:

RUN pip3 install virtualenv
RUN virtualenv venv
RUN source venv/bin/activate

Would never seem to render a true virtual environment whereas following pip installs would be installed under the environment. The reason I need, or believe I need this setup, is that specific directories use dependencies that are different versions of neighboring directories: Folder B uses numpy version X, whereas Folder C uses numpy version Y.

With Docker, is there a tool or feature that I am forgetting that would allow me to use pip installs like a virtual environment, with different versions of the same dependency in different directories?

Upvotes: 3

Views: 2991

Answers (2)

OpenBSDNinja
OpenBSDNinja

Reputation: 1069

This might help. You just need to figure out how to start it with CMD or entrypoint. But this is how far I could get:

FROM ubuntu:xenial

RUN mkdir -p /usr/python-app
WORKDIR /usr/python-app

RUN apt-get update \
    && apt-get install -y python3-pip

RUN pip3 install virtualenv    

RUN virtualenv foo-env -p python3



COPY ./ /usr/python-app
RUN /bin/bash -c 'source /usr/python-app/foo-env/bin/activate'



CMD ["entry.sh"]

EXPOSE 8080

You will then be able to run it with something like this:

docker run -d -p 8000:8000 --name python-env-container python-env-container

You can open up a shell in the container with:

docker exec -it <container id you can get it from docker ps> bash

Let me know if this helps?

Upvotes: 0

Seer.The
Seer.The

Reputation: 487

Docker RUN is a build step. It creates a new layer upon previous, and essentially creates a new image. So the answer to your question is "No".

Consider using ENTRYPOINT and/or CMD, or compose a startup script for convenience.

Scripting your RUN might also suit your needs: RUN my_deploy_for_venv.sh will execute in one layer, so if you start venv in script, you shall have it during it's execution. You will have to start it again on container startup, though.

Upvotes: 2

Related Questions