Base Images & Volume & mkdir

[coderlol]

If the base image Dockerfile has a VOUME /var/lib directive, then an image derived from the base image cannot do a RUN mkdir -p /var/lib/somedir

The mkdir command has no effect. I think it is convenient to have the base image export a VOLUME and the derived images can create their own structure without having to explicitly calling their own VOLUME.

As-is, the base image must not issue the VOLUME /var/lib or the derived images won't be able to create a directory in /var/lib

[crosbymichael]

I'm not sure I understand what the expected behavior should be, can you give an example dockerfile to reproduce?

[crosbymichael]

I'm not sure I understand what the expected behavior should be, can you give an example dockerfile to reproduce?

[fdemmer]

i've run into this too and here's an example:

first Dockerfile:

FROM ubuntu:latest
VOLUME /etc

this Dockerfile is then used to build image "base":

# docker build -t base .
Uploading context  2.56 kB
Uploading context 
Step 0 : FROM ubuntu:latest
 ---> c0fe63f9a4c1
Step 1 : VOLUME /etc
 ---> Running in 8957e1485c31
 ---> 17879464e604
Successfully built 17879464e604
Removing intermediate container 8957e1485c31

... looks good, works.

second Dockerfile, should add more config and create a directory for later use in /etc:

FROM base
RUN mkdir /etc/ssl
ADD nginx.conf /etc/nginx/nginx.conf

again we build:

# docker build -t nginx .
Uploading context 3.072 kB
Uploading context 
Step 0 : FROM base
 ---> 17879464e604
Step 1 : RUN mkdir /etc/ssl
 ---> Running in ef0693690e0f
 ---> d94dba1a25f4
Step 2 : ADD nginx.conf /etc/nginx/nginx.conf
 ---> d4debccd60b9
Successfully built d4debccd60b9
Removing intermediate container ef0693690e0f
Removing intermediate container 3da3c324ab95

... looks good, but did not work:

# docker run -i -t nginx  bash
root@e158ee019e16:/# ls -la /etc/ssl
ls: cannot access /etc/ssl: No such file or directory
root@e158ee019e16:/# ls -la /etc/nginx/
total 8
drwxr-xr-x  2 root root 4096 Apr 22 21:11 .
drwxr-xr-x 57 root root 4096 Apr 22 21:12 ..
-rw-r--r--  1 root root    0 Apr 22 21:10 nginx.conf

as you see above, the ADD command worked (my sample nginx.conf is really empty, that's ok), but the RUN command to create the "ssl" directory was executed during the build (it seems), but then it is missing from the container when run.

edit: same problem with RUN rm. i was trying to remove the sites-enabled/default and use ADD my own site.conf, but default always remained. overwriting default with ADD works, but is not a very nice solution.

[fdemmer]

i've run into this too and here's an example:

first Dockerfile:

FROM ubuntu:latest
VOLUME /etc

this Dockerfile is then used to build image "base":

# docker build -t base .
Uploading context  2.56 kB
Uploading context 
Step 0 : FROM ubuntu:latest
 ---> c0fe63f9a4c1
Step 1 : VOLUME /etc
 ---> Running in 8957e1485c31
 ---> 17879464e604
Successfully built 17879464e604
Removing intermediate container 8957e1485c31

... looks good, works.

second Dockerfile, should add more config and create a directory for later use in /etc:

FROM base
RUN mkdir /etc/ssl
ADD nginx.conf /etc/nginx/nginx.conf

again we build:

# docker build -t nginx .
Uploading context 3.072 kB
Uploading context 
Step 0 : FROM base
 ---> 17879464e604
Step 1 : RUN mkdir /etc/ssl
 ---> Running in ef0693690e0f
 ---> d94dba1a25f4
Step 2 : ADD nginx.conf /etc/nginx/nginx.conf
 ---> d4debccd60b9
Successfully built d4debccd60b9
Removing intermediate container ef0693690e0f
Removing intermediate container 3da3c324ab95

... looks good, but did not work:

# docker run -i -t nginx  bash
root@e158ee019e16:/# ls -la /etc/ssl
ls: cannot access /etc/ssl: No such file or directory
root@e158ee019e16:/# ls -la /etc/nginx/
total 8
drwxr-xr-x  2 root root 4096 Apr 22 21:11 .
drwxr-xr-x 57 root root 4096 Apr 22 21:12 ..
-rw-r--r--  1 root root    0 Apr 22 21:10 nginx.conf

as you see above, the ADD command worked (my sample nginx.conf is really empty, that's ok), but the RUN command to create the "ssl" directory was executed during the build (it seems), but then it is missing from the container when run.

edit: same problem with RUN rm. i was trying to remove the sites-enabled/default and use ADD my own site.conf, but default always remained. overwriting default with ADD works, but is not a very nice solution.

[fdemmer]

so I ran into this again with a different scenario just now and it's making me doubt if i am using VOLUME and Dockerfiles right at all...

• i created a base image, that just installs openldap on top of an ubuntu image. in that dockerfile i set VOLUME /var/lib/ldap to have the database outside of the container root-fs.
• i then use this base image with FROM in another dockerfile to add some custom config (as recommended in method 2 here: #2022 (comment)). the custom config is set via -e parameters on run and applied inside using dpkg-reconfigure, which modifies the database (on the volume).

that causes all kinds of weird behaviour of the ldap server. eg. the domain reconfiguration is applied, but other default objects are not there in the new base dn. anyway, point is: as soon as i remove the VOLUME for the database path from my base image, everything works as expected.

volumes really sound great the way the docs and articles like this http://crosbymichael.com/advanced-docker-volumes.html describe them, but if i cannot modify their contents when "inheriting" them FROM other images, how is the "base image+config image"-pattern supposed to work?

[fdemmer]

so I ran into this again with a different scenario just now and it's making me doubt if i am using VOLUME and Dockerfiles right at all...

• i created a base image, that just installs openldap on top of an ubuntu image. in that dockerfile i set VOLUME /var/lib/ldap to have the database outside of the container root-fs.
• i then use this base image with FROM in another dockerfile to add some custom config (as recommended in method 2 here: #2022 (comment)). the custom config is set via -e parameters on run and applied inside using dpkg-reconfigure, which modifies the database (on the volume).

that causes all kinds of weird behaviour of the ldap server. eg. the domain reconfiguration is applied, but other default objects are not there in the new base dn. anyway, point is: as soon as i remove the VOLUME for the database path from my base image, everything works as expected.

volumes really sound great the way the docs and articles like this http://crosbymichael.com/advanced-docker-volumes.html describe them, but if i cannot modify their contents when "inheriting" them FROM other images, how is the "base image+config image"-pattern supposed to work?

[LK4D4]

+1 on this issue, I think this is clearly a bug

[LK4D4]

+1 on this issue, I think this is clearly a bug

[e-max]

I've made simplest example to demonstrate this issue:

Parent image - create file

[e-max@e-max docker]$ cat ./parent/Dockerfile 
FROM ubuntu
RUN mkdir /tmp/docker/
RUN echo "hello" > /tmp/docker/hello
VOLUME ["/tmp/docker/"]

Child image - remove file

[e-max@e-max docker]$ cat ./child/Dockerfile 
FROM parent
RUN rm /tmp/docker/hello

Build

[e-max@e-max docker]$ docker build -t parent ./parent/
Sending build context to Docker daemon  2.56 kB
Sending build context to Docker daemon 
Step 0 : FROM ubuntu
 ---> 5cf8fd909c6c
Step 1 : RUN mkdir /tmp/docker/
 ---> Using cache
 ---> 0925b684892f
Step 2 : RUN echo "hello" > /tmp/docker/hello
 ---> Using cache
 ---> c63b75c84ecc
Step 3 : VOLUME ["/tmp/docker/"]
 ---> Using cache
 ---> 71a00868d3a2
Successfully built 71a00868d3a2
[e-max@e-max docker]$ docker build -t child ./child/
Sending build context to Docker daemon  2.56 kB
Sending build context to Docker daemon 
Step 0 : FROM parent
 ---> 71a00868d3a2
Step 1 : RUN rm /tmp/docker/hello
 ---> Using cache
 ---> dcde5cf04e6b
Successfully built dcde5cf04e6b

And test - file still exist in child image.

[e-max@e-max docker]$ docker run -i -t --rm child cat /tmp/docker/hello
hello
[e-max@e-max docker]$

[e-max]

I've made simplest example to demonstrate this issue:

Parent image - create file

[e-max@e-max docker]$ cat ./parent/Dockerfile 
FROM ubuntu
RUN mkdir /tmp/docker/
RUN echo "hello" > /tmp/docker/hello
VOLUME ["/tmp/docker/"]

Child image - remove file

[e-max@e-max docker]$ cat ./child/Dockerfile 
FROM parent
RUN rm /tmp/docker/hello

Build

[e-max@e-max docker]$ docker build -t parent ./parent/
Sending build context to Docker daemon  2.56 kB
Sending build context to Docker daemon 
Step 0 : FROM ubuntu
 ---> 5cf8fd909c6c
Step 1 : RUN mkdir /tmp/docker/
 ---> Using cache
 ---> 0925b684892f
Step 2 : RUN echo "hello" > /tmp/docker/hello
 ---> Using cache
 ---> c63b75c84ecc
Step 3 : VOLUME ["/tmp/docker/"]
 ---> Using cache
 ---> 71a00868d3a2
Successfully built 71a00868d3a2
[e-max@e-max docker]$ docker build -t child ./child/
Sending build context to Docker daemon  2.56 kB
Sending build context to Docker daemon 
Step 0 : FROM parent
 ---> 71a00868d3a2
Step 1 : RUN rm /tmp/docker/hello
 ---> Using cache
 ---> dcde5cf04e6b
Successfully built dcde5cf04e6b

And test - file still exist in child image.

[e-max@e-max docker]$ docker run -i -t --rm child cat /tmp/docker/hello
hello
[e-max@e-max docker]$

[tiborvass]

@e-max Thanks. I could reproduce with master.

[tiborvass]

@e-max Thanks. I could reproduce with master.

[LK4D4]

Okay, I did little research and it seems that volume is non-mutable between Dockerfile instruction.
Here even smaller Dockerfile for testing:

FROM busybox

RUN mkdir /tmp/volume
RUN echo "hello" > /tmp/volume/hello
VOLUME ["/tmp/volume/"]
RUN [[ -f /tmp/volume/hello ]]
RUN rm /tmp/volume/hello
RUN [[ ! -e /tmp/volume/hello ]]

On each instruction we create new volume and copy content from original volume.

[LK4D4]

Okay, I did little research and it seems that volume is non-mutable between Dockerfile instruction.
Here even smaller Dockerfile for testing:

FROM busybox

RUN mkdir /tmp/volume
RUN echo "hello" > /tmp/volume/hello
VOLUME ["/tmp/volume/"]
RUN [[ -f /tmp/volume/hello ]]
RUN rm /tmp/volume/hello
RUN [[ ! -e /tmp/volume/hello ]]

On each instruction we create new volume and copy content from original volume.

[jessfraz]

@cpuguy83 is this fixed?

[jessfraz]

@cpuguy83 is this fixed?

[cpuguy83]

@jfrazelle No, see #7133

[cpuguy83]

@jfrazelle No, see #7133

[jessfraz]

ah ok bummmeerrrrr

[jessfraz]

ah ok bummmeerrrrr

[tomfotherby]

I just ran into this issue. I was trying to extend from the official mongodb image from the hub and seed the database with my apps skeleton data, but because the parent container uses VOLUME /data/db, any mongo data I add in my extended container doesn't persist the build. Shame 😞 .

( I blogged about my workaround)

[tomfotherby]

I just ran into this issue. I was trying to extend from the official mongodb image from the hub and seed the database with my apps skeleton data, but because the parent container uses VOLUME /data/db, any mongo data I add in my extended container doesn't persist the build. Shame 😞 .

( I blogged about my workaround)

[pmoust]

Relates #8647

[pmoust]

Relates #8647

[resouer]

@LK4D4 @cpuguy83 Can anyone explain why docker create a immediate container for every each instruction? why don't we use only one container to run all the instructions?

 docker build --rm=true -t test:v1  .
Sending build context to Docker daemon 4.608 kB
Sending build context to Docker daemon 
Step 0 : FROM busybox
 ---> 4986bf8c1536
Step 1 : RUN mkdir /tmp/volume
 ---> Running in 44d16cfe2789
 ---> 5b43e0b0bd25
Removing intermediate container 44d16cfe2789
Step 2 : RUN echo "hello" > /tmp/volume/hello
 ---> Running in 3bb06fc6430f
 ---> f6c2df31942d
Removing intermediate container 3bb06fc6430f
Step 3 : VOLUME /tmp/volume/
 ---> Running in 772ecf1b514b
 ---> 20c101f04d84
Removing intermediate container 772ecf1b514b
Step 4 : RUN [[ -f /tmp/volume/hello  ]]
 ---> Running in a7b3d25253c1
 ---> fdcb7ad521b4
Removing intermediate container a7b3d25253c1
Step 5 : RUN rm /tmp/volume/hello
 ---> Running in f7eacc6fe381
 ---> 81723d425b39
Removing intermediate container f7eacc6fe381
Step 6 : RUN [[ ! -e /tmp/volume/hello  ]]
 ---> Running in b3770d7a9e46
The command '/bin/sh -c [[ ! -e /tmp/volume/hello  ]]' returned a non-zero code: 1

[resouer]

@LK4D4 @cpuguy83 Can anyone explain why docker create a immediate container for every each instruction? why don't we use only one container to run all the instructions?

 docker build --rm=true -t test:v1  .
Sending build context to Docker daemon 4.608 kB
Sending build context to Docker daemon 
Step 0 : FROM busybox
 ---> 4986bf8c1536
Step 1 : RUN mkdir /tmp/volume
 ---> Running in 44d16cfe2789
 ---> 5b43e0b0bd25
Removing intermediate container 44d16cfe2789
Step 2 : RUN echo "hello" > /tmp/volume/hello
 ---> Running in 3bb06fc6430f
 ---> f6c2df31942d
Removing intermediate container 3bb06fc6430f
Step 3 : VOLUME /tmp/volume/
 ---> Running in 772ecf1b514b
 ---> 20c101f04d84
Removing intermediate container 772ecf1b514b
Step 4 : RUN [[ -f /tmp/volume/hello  ]]
 ---> Running in a7b3d25253c1
 ---> fdcb7ad521b4
Removing intermediate container a7b3d25253c1
Step 5 : RUN rm /tmp/volume/hello
 ---> Running in f7eacc6fe381
 ---> 81723d425b39
Removing intermediate container f7eacc6fe381
Step 6 : RUN [[ ! -e /tmp/volume/hello  ]]
 ---> Running in b3770d7a9e46
The command '/bin/sh -c [[ ! -e /tmp/volume/hello  ]]' returned a non-zero code: 1

[cpuguy83]

@simonvanderveldt I've attempted to fix this multiple times.
The last fix was fairly reasonable,imo, but was ultimately rejected.

Maybe a new attempt with a fresh set of eyes will help?

Volume is basically already a no-op, it's when RUN is called and it sees the Volume in the config that the volume is created like normal since RUN is basically the same thing as docker run.

[cpuguy83]

@simonvanderveldt I've attempted to fix this multiple times.
The last fix was fairly reasonable,imo, but was ultimately rejected.

Maybe a new attempt with a fresh set of eyes will help?

Volume is basically already a no-op, it's when RUN is called and it sees the Volume in the config that the volume is created like normal since RUN is basically the same thing as docker run.

[habfast]

Basically, don't declare VOLUME unless you are done with that directory.

Yes, but then we are quite screwed when it comes to extending official images. There might be the logic of not using official images, but I thought using official images was the recommended way to work? The proofs that this is broken are all the references from external git repositories to this issue. They had to remove their VOLUME declarations so that people could extend their Dockerfile.

In any case, +1 for this feature too.

[habfast]

Basically, don't declare VOLUME unless you are done with that directory.

Yes, but then we are quite screwed when it comes to extending official images. There might be the logic of not using official images, but I thought using official images was the recommended way to work? The proofs that this is broken are all the references from external git repositories to this issue. They had to remove their VOLUME declarations so that people could extend their Dockerfile.

In any case, +1 for this feature too.

[sirlatrom]

Here is a non-exhaustive list of VOLUME instructions in official images which prevent creating child images for use in e.g. integration tests, seeding data for developers, etc. in any trivial way.

Granted, some of them have instructions on how to work around this, but most involve copying over content from other non-VOLUME directories in your child image (such as the "Installing more tools" section of the Jenkins image page on Docker Hub), but it will often add unnecessarily to container startup time and probably other issues too.

• Jenkins
• Mongo
• MySQL
• Postgres
• Consul
• Registry
• Redis
• Elasticsearch
• Wordpress
• RabbitMQ
• MariaDB
• Cassandra
• Ghost
• RethinkDB
• Maven
• ...

[sirlatrom]

Here is a non-exhaustive list of VOLUME instructions in official images which prevent creating child images for use in e.g. integration tests, seeding data for developers, etc. in any trivial way.

Granted, some of them have instructions on how to work around this, but most involve copying over content from other non-VOLUME directories in your child image (such as the "Installing more tools" section of the Jenkins image page on Docker Hub), but it will often add unnecessarily to container startup time and probably other issues too.

• Jenkins
• Mongo
• MySQL
• Postgres
• Consul
• Registry
• Redis
• Elasticsearch
• Wordpress
• RabbitMQ
• MariaDB
• Cassandra
• Ghost
• RethinkDB
• Maven
• ...

[mlosev]

Being unable to override VOLUME from parent image in any child images - that is very annoying(
Hope it will be fixed soon

[mlosev]

Being unable to override VOLUME from parent image in any child images - that is very annoying(
Hope it will be fixed soon

[gotgenes]

@sirlatrom You can add JHipster to your list. See jhipster/generator-jhipster#4277.

[gotgenes]

@sirlatrom You can add JHipster to your list. See jhipster/generator-jhipster#4277.

[sirlatrom]

@gotgenes It doesn't look like jhister is an official image.

[sirlatrom]

@gotgenes It doesn't look like jhister is an official image.

[Neirda24]

+1 for this feature

[Neirda24]

+1 for this feature

[Wilfred]

Would it be feasible to error or at least warn in this situation? Silently failing is unfortunate.

[Wilfred]

Would it be feasible to error or at least warn in this situation? Silently failing is unfortunate.

[pjweisberg]

I've been relying on the behavior described in #21728 for several months; I had no idea it was a bug until helped a colleague figure out why the data he was putting in /var/lib/mysql was getting discarded. He spent hours trying to figure out what was blowing away his data.

He might end up having to just copy mysql's Dockerfile into his own instead of basing his image on theirs. Maybe I'm supposed to do the same, in case #21728 ever gets "fixed".

At minimum, child Dockerfiles should have a way to un-VOLUME a directory that was declared as a VOLUME by the parent. At least long enough to modify its contents.

[pjweisberg]

I've been relying on the behavior described in #21728 for several months; I had no idea it was a bug until helped a colleague figure out why the data he was putting in /var/lib/mysql was getting discarded. He spent hours trying to figure out what was blowing away his data.

He might end up having to just copy mysql's Dockerfile into his own instead of basing his image on theirs. Maybe I'm supposed to do the same, in case #21728 ever gets "fixed".

At minimum, child Dockerfiles should have a way to un-VOLUME a directory that was declared as a VOLUME by the parent. At least long enough to modify its contents.

[thaJeztah]

@pjweisberg see #3465 for that topic 👍

[thaJeztah]

@pjweisberg see #3465 for that topic 👍