Unless I am confused by what you are asking, there isn't a virtual environment.
The images have a separate Python installation from any system Python installation so it can ensure is latest version and when you are doing a pip install it is installing into the separate Python installation, not a virtual environment constructed from the Python installation. So the build scripts aren't setting up a virtual environment and that therefore isn't the issue. The issue is more that the build scripts support you being able to specify hooks to perform actions and set extra environment variables dynamically, which need to be done before the pip install can be run. If you aren't using the build hooks, then technically you could do a pip install direct from the Docker file, however not when inheriting from the on build image. Instead you would want to copy the intent of the on build into your Dockerfile, actually dropping the on build and then insert your pip installs. So instead use something like: FROM grahamdumpleton/mod-wsgi-docker:python-2.7 WORKDIR /app RUN pip install mypackage COPY . /app RUN mod_wsgi-docker-build EXPOSE 80 ENTRYPOINT [ "mod_wsgi-docker-start" ] Any particular reason volumes would be an issue? FWIW, when I had some time I was going to play with wheel deploys was a variant of some ideas described in: https://glyph.twistedmatrix.com/2015/03/docker-deploy-double-dutch.html That is, use one docker container once to build all the wheels in and then the results would be copied into final image to speed up its build. Graham On 19/06/2015, at 10:23 AM, Eibriel Inv <[email protected]> wrote: > Hi Graham, thanks for your response. > > I want to use docker for Development to be sure I'm running under the same > conditions that Production. > I'm using "onbuild" images, you can see the code here: > https://github.com/Eibriel/widu-community-server/blob/master/Dockerfile > > I've no problem rebuilding the container each time (avoiding Volumes if > possible), if the build time is short enough. > > I'm wondering, Why the virtual environment is needed? Without it we will be > able to just pip install on Dockerfile. > > Thanks!! > > > El martes, 16 de junio de 2015, 3:09:32 (UTC-3), Graham Dumpleton escribió: > I am just doing a final build and push of updated images which will permit > the volume mounting trick. > > Besides that, there is one other thing one can do which is not to avoid > running pip, but to use a manual step to first prebuild Python wheels for all > the packages from inside Docker back into a local directory on the host. You > then setup the build hook script to check for a cache directory of wheels and > set an environment variable so pip knows where it is. When you want to build > the image using the cache, you would mount as a volume the local cache > directory with the wheels into the location which pip is being setup to grab > them from. > > By using Python wheels you would speed things up significantly as it avoids > needing to download packages from the network and recompile them if C > extensions. > > I will work on a recipe for that, but if you can let me know the scenario you > are targeting which is the problem do still let me know. > > Graham > > > On 16 June 2015 at 11:07, Graham Dumpleton <[email protected]> wrote: > > On 16/06/2015, at 10:16 AM, Eibriel Inv <[email protected]> wrote: > > > Hi! > > I've noticed that every time I make a change on the code I need to rebuild > > the container and the build script install the pip requirements (which is > > time consuming). > > > > How can I install my own requirements from Dockerfile to prevent that? > > Is the issue with this because you are trying to use the docker image during > development and so are making fast turn around changes? > > The reason you are seeing what you are seeing is because the 'onbuild' docker > image is written as: > > FROM grahamdumpleton/mod-wsgi-docker:python-2.7 > > WORKDIR /app > > ONBUILD COPY . /app > ONBUILD RUN mod_wsgi-docker-build > > EXPOSE 80 > ENTRYPOINT [ "mod_wsgi-docker-start" ] > > Because the requirements.txt file is a part of the directory that needs to be > copied into the docker image, then any change to the project directory will > result in the latter build phase being triggered. It is the build phase that > pip is run from to install the requirements. > > This sort of arrangement is quite typical for Python docker images. > > If you weren't using this image with the mod_wsgi-docker-build script and > doing things explicitly, you could probably get away with using something > like: > > WORKDIR /app > > COPY requirements.txt /app/requirements.txt > > RUN pip install -r requirements.txt > > COPY . /app > > With this, because the requirements.txt file is copied separately, so long as > that file along isn't changed, the pip wouldn't be run. > > The whole point with mod_wsgi-docker-build though is that it does other stuff > before pip is run to properly set up the environment. This means it cannot be > split out in that way. > > If the problem is because you are trying to use it for quick turnaround > changes in a development environment, there may be a better way, although I > would have to tweak how the images work. > > What one other person did, perhaps due to also wanting to do things in a > development environment, was to copy my docker images and change them to have > the application directory mounted in as a volume. > > They possibly weren't thinking of the pip install problem, but wanted to be > able to modify code on the fly, touch the WSGI script file and have the > mod_wsgi in the docker instance automatically reload it. > > In other words, wouldn't be necessary to stop the container. > > Rather than copy my docker images and change them, notionally you could > achieve the same thing by doing: > > docker build -t myapp . > docker run -it -v `pwd`:/app myapp > > That is, build the docker image once, which will result in all the packages > being installed, and then run it, with it using the live code from your host. > You would only need to do a rebuild if you change the requirements.txt file. > > Unfortunately, as written this will not work. > > The problem is that the docker images themselves stored various stuff inside > of the /app directory and what is in it isn't just your application code. > Thus the script to start everything up isn't found. > > What I could do though is change the images such that the special stuff from > the base image isn't stored under /app where your application is placed, and > puts it somewhere else. > > If I do that, then the mounting volume trick should work and allow for this > sort of behaviour. > > So can you explain the scenario of where this is a problem so I can > understand better the needs you have and whether this change would work? > > Thanks. > > Graham > > > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/modwsgi. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
