skip to Main Content

For automated testing we can’t use a DB Docker container with a defined volume. Just wondering if there would be available an "offical" Postgres image with no mounted volume or volume definitions.

Or if someone has a Dockerfile that would create a container without any volume definitions, that would be very helpful to see or try to use one.

Or is there any way to override a defined volume mount and just use datafile inside of to be created Docker container with running DB.

2

Answers


  1. Chosen as BEST ANSWER

    "You could just copy one of the dockerfiles used by the postgres project, and remove the VOLUME statement. github.com/docker-library/postgres/blob/… – Nick ODell Nov 26, 2022 at 18:05"

    answered Nick abow.

    And that edited Dockerfile would build "almost" Docker Official Image.


  2. I think you are mixing up volumes and bind mounts.
    https://docs.docker.com/storage/

    VOLUME Dockerfile command: A volume with the VOLUME command in a Dockerfile is created into the docker area on the host that is /var/lib/docker/volumes/.

    I don’t think it is possible to run docker without it having access to this directory or it would be not advisable to restrict permission of docker to these directories, these are dockers own directories after all.

    So postgres dockerfile has this command in dockerfile, for example: https://github.com/docker-library/postgres/blob/master/15/bullseye/Dockerfile

    line 186: VOLUME /var/lib/postgresql/data

    This means that the /var/lib/postgresql/data directory that is inside the postgres container will be a VOLUME that will be stored on the host somewhere in /var/lib/docker/volumes/somerandomhashorguid..... in a directory with a random name.

    You can also create a volume like this with docker run:

    docker run --name mypostgres -e POSTGRES_PASSWORD=password -v /etc postgres:15.1

    This way the /etc directory that is inside the container will be stored on the host in the /var/lib/docker/volumes/somerandomhashorguid.....

    This volume solution is needed for containers that need extra IO, because the files of the containers (that are not in volumes) are stored in the writeable layer as per the docs: "Writing into a container’s writable layer requires a storage driver to manage the filesystem. The storage driver provides a union filesystem, using the Linux kernel. This extra abstraction reduces performance as compared to using data volumes, which write directly to the host filesystem."

    So you could technically remove the VOLUME command from the postgres dockerfile and rebuild the image for yourself and use that image to create your postgres container but it would have lesser performance.

    Bind mounts are the type of data storage solution that can be mounted to anywhere on the host filesystem. For example if you would run:

    docker run --name mypostgres -e POSTGRES_PASSWORD=password -v /tmp/mypostgresdata:/var/lib/postgresql/data postgres:15.1

    (Take not of the -v flag here, there is a colon between the host and the container directory while previously in the volume version of this flag there was no host directory and no colon either.)

    then you would have a directory created on your docker host machine /tmp/mypostgresdata and the directory of the container of /var/lib/postgresql/data would be mapped here instead of the docker volumes internal directory /var/lib/docker/volumes/somerandomhashorguid.....

    My general rule of thumb would be to use volumes – as in /var/lib/docker/volumes/ – whenever you can and deviate only if really necessary. Bind mounts are not flexible enough to make an image/container portable and the writable container layer has less performance than docker volumes.

    You can list docker volumes with docker volume ls but you will not see bind mounted directories here. For that you will need to do docker inspect containername

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search