Dockerfile defines "VOLUME /var/www/html"

[t-hofmann]

To introduce such a volume leads to the problem that changes to that directory get ignored when commiting to an image. Use-case: spawn multiple joomla-containers from such a configured and hence ready to run image

Please remove that volume-definition from the buildfiles ("Dockerfile").

[mbabker]

Is there a best practice concerning this? Because honestly looking through the official Docker image library (of which this repo is a part of, just not "owned" by their organization), I see a mix definition of volumes and WORKDIR directives.

FWIW, this image is modeled off the WordPress image which does define the volume.

[t-hofmann]

in order to provide some more context, here is what the docker-refernce says to that: https://docs.docker.com/engine/reference/builder/#volume

IMHO without pressing needs it should not be used in order to build an image, and leave it to the user of an image to create a volume if necessary when instantiating a container from it. This would provide the maximum flexibility to the user and reduce the surprise-factor, because the side-effect is not obvious.

Besides of that in case of this Joomla-Image, a little enhancement could be to add a line to the docker-entrypoint.sh, like echo "Joomla is installed in /var/www/html, to gain access one may mount that as a volume"

2017-02-13 14:54 GMT+01:00 Michael Babker [email protected]:

Is there a best practice concerning this? Because honestly looking through the official Docker image library (of which this repo is a part of, just not "owned" by their organization), I see a mix definition of volumes and WORKDIR directives.

FWIW, this image is modeled off the WordPress image which does define the volume.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/joomla/docker-joomla/issues/17#issuecomment-279398190, or mute the thread https://github.com/notifications/unsubscribe-auth/AUQYdDQujMZOiaS9IiOhpBYOxU3Y5rMCks5rcGCBgaJpZM4L_N-Q . {"api_version":"1.0","publisher":{"api_key":" 05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity": {"external_key":"github/joomla/docker-joomla","title": "joomla/docker-joomla","subtitle":"GitHub repository","main_image_url":" https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88- 11e6-95fc-7290892c7bb5.png","avatar_image_url":"https:// cloud.githubusercontent.com/assets/143418/15842166/ 7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/joomla/docker-joomla"}}," updates":{"snippets":[{"icon":"PERSON","message":"@mbabker in #17: Is there a best practice concerning this? Because honestly looking through the official Docker image library (of which this repo is a part of, just not "owned" by their organization), I see a mix definition of volumes and WORKDIR directives.\r\n\r\nFWIW, this image is modeled off the WordPress image which does define the volume."}],"action":{"name":"View Issue","url":"https://github.com/joomla/docker-joomla/ issues/17#issuecomment-279398190"}}}

-- Thomas Hofmann

Master of Science & Dipl.-Inf. (FH)

Körnerstr. 22 4107 Leipzig Germany

phone +49 - 341 - 22 81 705 mobile +49 - 179 - 23 95 118

[t-hofmann]

also the Dockerfile of the underlying mysql has such a "Volume" statement, so that would prevent to "docker commit" the mysql-container.

I just setup a build-env for (apache-php7 and mysql/5.6), deleted the two "Volume"-statements, then configuring joomla via the webinterface and then "docker commiting" works. Obviously also "docker diff" then shows the differences.

Find attached two docker-compose files to build and run. The docker-compose.build.yml expects to find the Dockerfiles-files in respective subdirs, to create them: git clone https://github.com/joomla/docker-joomla.git docker-joomla git clone https://github.com/docker-library/mysql.git docker-mysql

Remove the "Volume"-statements in the used Dockerfiles

then build:

• docker-compose up -f docker-compose.build.yml
• configure joomla via http://localhost/
• docker commit the two containers and docker-rm them
• Readily configured containers can be run from those images by docker-compose up [-f docker-compose.yml] there also is a volume ./html:/var/www/html created to provide developers easy access.

I think in regard of this issue, that one has to clearly distinguish between build- and runtime. During runtime volumes are of many uses, e. g. prevent accidental commit/deletion of data when deleting a container, allow a developer to access relevant data, ...

HTH docker-compose.zip

[frankmayer]

@mbabker I am all for proceeding with the implementation of these changes (If they still apply).

[mbabker]

Admittedly, I honestly haven't worked with Docker in well over a year aside from maintaining this image. So at this point, I can't even say at any level what a "good" answer here is. With that said though, here is the concern that regardless of what the Dockerfile looks like needs to be able to be addressed.

If this image is used in a production build and a site has extensions installed, and a user updates the image, what happens with the filesystem and the state of the Joomla installation? If you do a full replacement of the web directory, you lose the extension files. If it's able to just update the filesystem with the core package files, the site is in a mixed state between versions as relevant database and filesystem updates aren't applied just by unzipping the package (https://gist.github.com/mbabker/d7bfb4e1e2fbc6b7815a733607f89281 can help with that).

If we can get to a state where the core Joomla package can be safely upgraded without losing user data by replacing the image, I'm all for whatever improvements it takes. Also, FWIW, I've said before this image is based heavily on how the WordPress image is structured since our distro models and environments are so close and I've still got it on my TODO list to try and port some of the changes from that image in the next few weeks (which would cover architecture related stuff and support for secrets at a minimum).

[Llewellynvdm]

This continues to be the best practice that we as maintainers note what folder should be used as the entry point and main mount volume.

Any number of volumes can be mounted, in any part of the container/image and our declaration should not effect that directly.

Yet making it part of our image Docker build files, give everyone the need knowledge that we control this area of the container, and that we will on deployment of the container move the Joomla files into this location. But even this does not limit the persistent mount option of this folder.

So for all intents and purposes I will close this issue, yet if you feel the need to more explicitly press the matter feel free to open a new issue with the new and directly "latest" Joomla image related feedback and concerns.