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.
