Thanks!
This solution worked just fine for me, I wasn't using hooks.
I think Volumes should be for data instead of code (but maybe I'm over
reacting).
my Dockerfile:
FROM grahamdumpleton/mod-wsgi-docker:python-3.4
WORKDIR /app
RUN pip install Flask
RUN pip install eve
COPY . /app
RUN mod_wsgi-docker-build
EXPOSE 80
ENTRYPOINT [ "mod_wsgi-docker-start" ]
CMD [ "--working-directory", "main_server", \
"--url-alias", "/main_server/static", "static", \
"main_server.wsgi" ]
Now the script skips the requirements because are already installed, is
only installing modwsgi, and is fast enough to use it on development :)
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.
