(modwsgi is only installed the first time) El jueves, 18 de junio de 2015, 21:42:42 (UTC-3), Graham Dumpleton escribió: > > 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] <javascript:>> > 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] <javascript:>. > To post to this group, send email to [email protected] <javascript:> > . > 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.
