Remove VOLUME

[davidbarratt]

Docker does not provide a way to remove the VOLUME in docker-compose.yml or by extending this image in a Dockerfile. Because of this, the VOLUME should be removed so others can add it if they want.

[pnloyd]

I ran into this same problem, as a workaround just changed WORKDIR to something else (I used '/var/www/public'. docker-entrypoint.sh will copy/setup wordpress into PWD so your good to go!

[donnykurnia]

Or, make the VOLUME as ONBUILD

[donnykurnia]

@pnloyd you will also need to override the DocumentRoot in /etc/apache2/sites-available/000-default.conf

[pnloyd]

@donnykurnia actually using nginx on top of the wordpress fpm image.

[mikew]

Just to give examples why this VOLUME is annoying:

• Makes developing themes with docker-compose difficult, since docker-compose preserves volumes, if you docker-compose build && docker-compose up you'll still be using the old theme files, you must docker-compose rm -v before.
• Same with plugins
• Adding themes / plugins in Dockerfile gets hairy, because the VOLUME comes before any chown commands the person extending the image would write. This means chown doesn't take.

[rubidot]

I just spent hours trying to figure out issues with my config to discover this VOLUME instruction is at the root of it all. This also explains all those nameless volumes that keep popping up.

This VOLUME is rather unexpected and unhelpful; if this isn't going to be removed, can we at least get an explanation why it's there?

[tianon]

My comment from #246 (comment) today is relevant:

WordPress expects to self-update (and IMO anyone who doesn't allow it to do so these days is asking for trouble), so we simply recommend that users instead make the entire install a directory and be done with it. If you'd like a fresh install from an image to include pre-installed themes or plugins, simply add them to the source directory in /usr/src/wordpress (which is what gets copied into /var/www/html at runtime).

Applying a VOLUME in this way is consistent with how other official images handle their explicitly mutable state.

This definitely could do with some better documentation, which is over at https://github.com/docker-library/docs/blob/master/wordpress/content.md if anyone wanted to take a stab at writing something.

[rubidot]

Thanks @tianon, I appreciate the quick response. I wasn't expecting that. The idea of considering the entire install as mutable state makes sense to me, and now I have some thoughts on how to experiment with VOLUME to get a better understanding of how all this works ( as this is pushing the bounds of my Docker knowledge ). If I can get to a useful understanding, I'll see if I can figure out how to contribute some documentation.

[davidbarratt]

@tianon You don't need to make it a volume to auto-update it. In fact, it can prevent it. I could always let WordPress auto-update within the container, there isn't anything stopping that. However, if I were to disable auto updates and do a docker pull I would not get the latest version (as expected). Also, what if the user would rather just make their plugins and theme directory a volume (since that's the only thing they care about persisting)? There isn't a way for the user to cusotmize this at all, because VOLUME forces a volume to be created. :(

[davidbarratt]

@tianon TBF, I would be fine with the VOLUME if there was an easy way to override it, but afaik there isn't. :(

[davidbarratt]

@tianon IMHO, since volumes have to be named anyways (otherwise most users will get a bunch of unexpected duplicates), I think they should be runtime only (i.e. docker or docker-compose, but not Dockerfile)

[donnykurnia]

The problem with VOLUME in wordpress Dockerfile, there is no easy way to override this if we want to make a new image using this image as a base. So, making an alternative image that set VOLUME as ONBUILD could be a compromise. Those who want to use wordpress image as a base image can use the onbuild image instead. The VOLUME will be executed after the additional commands in child image have all been executed.

[jzaefferer]

WordPress expects to self-update (and IMO anyone who doesn't allow it to do so these days is asking for trouble), so we simply recommend that users instead make the entire install a directory and be done with it. If you'd like a fresh install from an image to include pre-installed themes or plugins, simply add them to the source directory in /usr/src/wordpress (which is what gets copied into /var/www/html at runtime).

Applying a VOLUME in this way is consistent with how other official images handle their explicitly mutable state.

Thank you, that was very helpful. I went a step further, copying files (mostly themes) to a separate folder, and symlinking those into /usr/src/wordpress/wp-content/themes. The symlink is then copied, while my theme files stay outside the volume, so that I can update the image to deploy theme changes.

I'm not quite done testing this, but if it indeed works I'd be happy to extend the docs accordingly.

[jzaefferer]

For anyone else trying to update files from the image, within the /var/www/html volume: https://gist.github.com/jzaefferer/9a47b2d0af58c43deb189267f5a963a6

The custom entrypoint (apache2-init.sh) uses wp-cli to install the theme and eventually calls apache2-foreground

[tianon]

Here's a simple approach for modifying the Apache-based images to use a directory that is not a VOLUME, which I think should cover what folks are asking for here:

FROM wordpress:4.9-php7.2-apache
RUN mkdir -p /my/new/dir \
	&& chown www-data:www-data /my/new/dir \
	&& find /etc/apache2 -name '*.conf' -type f -exec sed -ri -e 's!/var/www/html!/my/new/dir!g' -e 's!Directory /var/www/!Directory /my/new/dir!g' '{}' +
WORKDIR /my/new/dir

$ docker build --pull .
Sending build context to Docker daemon  2.048kB
Step 1/3 : FROM wordpress:4.9-php7.2-apache
4.9-php7.2-apache: Pulling from library/wordpress
Digest: sha256:e30aed2d17b33758544f0eaebee763a452b41ff5bc926d723566338b0137dd81
Status: Image is up to date for wordpress:4.9-php7.2-apache
 ---> 63b422244491
Step 2/3 : RUN mkdir -p /my/new/dir 	&& chown www-data:www-data /my/new/dir && find /etc/apache2 -name '*.conf' -type f -exec sed -ri -e 's!/var/www/html!/my/new/dir!g' -e 's!Directory /var/www/!Directory /my/new/dir!g' '{}' +
 ---> Running in f5966114a84c
Removing intermediate container f5966114a84c
 ---> ddaedd461bf2
Step 3/3 : WORKDIR /my/new/dir
Removing intermediate container 6bd52fc8018e
 ---> d82b38540969
Successfully built d82b38540969

$ docker run -dit --name test d82b38540969
a24709b479c3bd2572f84681aabf75d0441e758142b8ec38a186bd7591bbb939

$ docker logs test | head -n2
WordPress not found in /my/new/dir - copying now...
Complete! WordPress has been successfully copied to /my/new/dir

$ docker exec -it test bash
root@a24709b479c3:/my/new/dir# ls
index.php	 wp-blog-header.php    wp-includes	  wp-settings.php
license.txt	 wp-comments-post.php  wp-links-opml.php  wp-signup.php
readme.html	 wp-config-sample.php  wp-load.php	  wp-trackback.php
wp-activate.php  wp-content	       wp-login.php	  xmlrpc.php
wp-admin	 wp-cron.php	       wp-mail.php
root@a24709b479c3:/my/new/dir# exit

$ docker inspect -f '{{ .NetworkSettings.IPAddress }}' test
172.18.0.19

$ curl -fsSL 'http://172.18.0.19'
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
	<meta name="viewport" content="width=device-width" />
	<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
	<meta name="robots" content="noindex,nofollow" />
	<title>WordPress &rsaquo; Setup Configuration File</title>
	<link rel='stylesheet' id='buttons-css'  href='http://172.18.0.19/wp-includes/css/buttons.min.css?ver=4.9.8' type='text/css' media='all' />
<link rel='stylesheet' id='install-css'  href='http://172.18.0.19/wp-admin/css/install.min.css?ver=4.9.8' type='text/css' media='all' />
</head>
...

This should be reasonably easily adapted to adjust the PHP-FPM configuration instead if that's your base (easier even, since it doesn't have the additional <Directory /var/www/> configuration which Apache uses that we have to account for).

Combined with my comment over in #156 (comment) about trivially disabling auto-update via the new WORDPRESS_CONFIG_EXTRA, I think this solves the use case.

[davidbarratt]

That's not what I'm asking, the volume would still be created. There's no way to prevent volume creation once it's defined in the Dockerfile.

[tianon]

Sure, but it's a single directory which uses a single inode, and is a very common pattern across many images (not just the official images). The image has no other way to communicate to users where the "mutable state" of the image is expected to live.

[davidbarratt]

I mean I think it would be best if Docker (in Dockerfile) provided a way to remove the Volume without naming it. If you don't name the volume, Docker will recreate the volume everytime you start the container.

[tianon]

I agree totally that Docker ought to have a method to "undefine" a volume, but on the flip side I do think the current behavior is really mostly a minor irritation rather than a very serious problem (it would definitely make things like what I outlined above much, much simpler to accomplish).

[vitalyzhakov]

Hi everyone!
This code was copied to another repo and problem is increased.
@tianon , @J0WI , can your reopen issue?

Many reasons described in YOURLS/containers#36

[vitalyzhakov]

Hello!
@tianon , @J0WI ,
Can you approve solution in YOURLS/containers#36 (comment) ?