VOLUME /var/www/html/sites prevents further changes to sites folder

[cerisier]

Not sure it can be labeled as an issue as this can be a design decision but just FYI.

I use drush_make to download all the required modules,
I usually do that at build time in the Dockerfile.

With the previous version of your image, it used to work because you did not set any VOLUME.

With your new version it doesn't work anymore as any changes operated on the folder set as a volume is applied to the container filesystem and thus discarded at run time.

Personally I think that the VOLUME decision should be handed the end user. In my case it breaks what used to work.

Thanks for the image. Let me know.

[cerisier]

Just as an example, here is my Dockerfile https://gist.github.com/cerisier/b14c0f79d0a6ba2332dc
Here, any files downloaded by drush will be discarded at run time.

[funkyfuture]

loĺ, i just wanted to ask you for an example. :-)

[moul]

I also prefer to let the end-user decide to put a --volume on runtime

Why is this explicit VOLUME in Dockerfile useful for ?

Maybe we can try a workaround by using a symlink to keep a runtime VOLUME from one side and always being able to run drush commands at build time

[cerisier]

Just updated the Dockerfile.
Basically I do this to be able to version only custom modules and not all the dependencies.

[funkyfuture]

in a nutshell, the idea was to preserve the contents of an instance by default, as i don't expect anyone wants to lose any customization. so, to update the Drupal-version of an instance would simply be done with docker-compose pull && docker-compose up -d.

i didn't completely understand your situation yet, but do you think that using the EXTRA_SETUP_SCRIPT may be a way to go?

another idea was to add an ONBUILD-statement that reads a list of modules to be installed from a modules.txt.

[funkyfuture]

another idea was to add an ONBUILD-statement that reads a list of modules to be installed from a modules.txt.

bs, that would happen after the initial drush site-install.

[cerisier]

To me, Docker best practice stats that containers should be stateless.

As for EXTRA_SETUP_SCRIPT, it runs at run time only if the database doesn't exist.
In my case, I run the container with persistent mysql data mounted as a volume and I want to be able to update one of dependency module even if drupal is already installed.

One possible workaround would be to add another EXTRA_RUN_SCRIPT that always run at run time. That way I could drush make somewhere in the container at build time, and copy or move those files at run time to /var/www/html/sites/all/modules.

But to me, ideal solution is to let the end user decide of volumes like most of all official docker images do.

Let me know

[funkyfuture]

what about docker exec?

you can also change the entrypoint and call entrypoint.sh from there.

i haven't tested updating a module from the webinterface, but installing a module works, so should updating.

[cerisier]

I really don't want to update modules using docker exec or webinterface as then it will not persist...

drush_make is there to act like a requirements.txt would do for python.

When you add or update a dependency you want that to persist for other people who would want to build and run the container. (local development for instance)

Indeed changing the entrypoint can do it in my case but still, by letting the volume decision to end user, you allow both your case and my case. By forcing it you restrict the usage of this image.

[funkyfuture]

as then I will no trace of it.

i don't understand that semantically.

i see your point. my argument for a default-volume is still, that it is more accessible for people unfamiliar with the technologies.

i'm rather drunk and tired atm, so i'd like to take the time to rest and think about that. please post that drupal.make-file. thanks.

and thanks for notifying that the examples-folder seems rather useless.

ah, and something i'm not clear about atm. any idea whether an ONBUILD could be of help here?

[samos123]

I also don't like being forced to have to use a volume, no need to specify it in Dockerfile imo. User can still use a volume if he wants to using cli arguments. This kind of stuff may be better put in docker compose. This image should be as flexible as possible so people can use it as base image.

Quoting cerisier we are currentlying restricting the usage of this image by forcing volume in Dockerfile.

[funkyfuture]

we can also define the default in the sample docker-compose.yml. some clarification about the directories that should be volume'd to preserve an instance with its customizations and uploaded files in the documentation would be very helpful anyway.

but i still don't understand what the point is about flexibility. i see this changes the flexibility how to use this image as a base. but i don't see any disadvantage in this (yet):

FROM samos123/drupal:7.35

ADD drupal.make /contrib/
ADD modules/anjuna_helper /contrib/modules/
RUN echo "drush make --no-core /contrib/drupal.make ." > /run.sh \
 && echo "cp -a /contrib/modules/* ./sites/all/modules/" >> /run.sh \
 && echo "exec /entrypoint.sh" >> /run.sh
ENTRYPOINT /run.sh

if there is no other trade-off, i'd rather prefer having a good, working default.

[cerisier]

It all depends if you want this image to be a base image or not.

Base images should be as flexible as possible for any use case. If you take a look at nginx or php:apache official images you will see that there is no volume defined for workdirs.

This example you submitted works indeed but requires to download all the modules everytime you run the container, which is far from ideal.

You want the image your build to contain all the dependencies required to run your program.

[funkyfuture]

fyi, there are Docker-features somewhere on the road (1.7 is the current milestone for that) that would allow us to 'hardcode' a good default:

• Reset properties inherited from parent image moby/moby#3465
• Add Dockerfile instructions to reset properties inherited from parent image moby/moby#8177

[funkyfuture]

actually, referring to this documentation the behaviour you describe (the empty …/all/modules-folder in your Dockerfile), which i can reproduce, would rather be a bug:

The docker run command initializes the newly created volume with any data that exists at the specified location within the base image. (...) This Dockerfile results in an image that causes docker run, to create a new mount point at /myvol and copy the greating file into the newly created volume.

As the run-command wasn't invoked at the time of the build, there wouldn't be any volume intialized. and when this will happen, the content at the mount-point of the image will be copied into the volume. or am i getting something very wrong here?

[funkyfuture]

and somewhere else i read, that the VOLUME-directive wouldn't be inherited by sub-sub-images/-containers. so no sub-image would be forced to use any volume. while there is a proper default for the vanilla image. but that's also not true. i should dig that source.

[funkyfuture]

though commit 5b82ba4 solves this issue, i'd like to keep it open until i did some further research on that unclear behaviour described in two posts above.

[funkyfuture]

@samos123 to make this effective, please rebuild the image.

fyi, regarding the question of volumes while building, in short, here's what a Docker guy says:

1. does a RUN-directive in a Dockerfile do the same as a docker run?
2. if so, why would it be useful that it initializes volumes in the same way?

1. Yes, docker run and RUN in a Dockerfile are equivelent.
2. It's not useful and there have been a few attempts to resolve this, none of which have been particularly acceptable.

[funkyfuture]

@samos123 can you please rebuild and push the image?

[samos123]

Just rebuild the image.

On Sun, Apr 5, 2015 at 10:44 PM, Frank Sachsenheim <notifications@github.com

wrote:

@samos123 https://github.com/samos123 can you please rebuild and push
the image?

—
Reply to this email directly or view it on GitHub
#10 (comment)
.