Data Persistence - RamonPradoMoreno/learned-at-work GitHub Wiki

This is a summary for quick use, it is not the Bible. I hope it helps you! 😃

People will usually use the term volume to describe a mount because it is a bit confusing.

Mounts are the natural way of sharing and persisting information used by the containers.

Any data used in a container without any mount will disappear if the container is destroyed.

volumes are often a better choice than persisting data in a container’s writable layer, because a volume does not increase the size of the containers using it, and the volume’s contents exist outside the lifecycle of a given container.

• I need to store some info that will be shared between containers.
• I need a database that persists data so it won't die when a container is stopped.

• I store data that never changes in a volume "just in case".
• I don't care about the data produced by my container, I don't need a volume. Maybe you are producing a lot of trash data and your container is getting huge.

When you create a mount you have to choose between:

1. tmpfs Mounts: You will have local RAM memory reserved for the use of certain file or folder in the container. The perfect place for trash data.
2. bind Mounts: You will have a local file or folder that is synchronized with a folder or file in the container. If you change something locally it will change in the container and vice versa. Wanna change a local configuration file and affect the container?
3. Volumes: Completely managed by docker, data will be persisted but you cannot change how or where.

Docker says:

Volumes are the preferred mechanism for persisting data generated by and used by Docker containers.

This is probably because the other types of mount depend on the file system used. In other words, for different Operating Systems the behavior might be different and/or unexpected.

WARNING!: If you want something to work on Windows use only volumes!!!

There are two ways of using mounts in a docker-compose.yml file:

This syntax is quick and effective but, in my opinion, a bit confusing and configuration is limited:

<local_folder_or_file_path>:<container_folder_or_file_path>:<mode>.

• local_folder_or_file_path: relative to the docker-compose.yml
• container_folder_or_file_path: Cannot be relative!
• mode:
  1. read only → ro
  2. read-write → rw → default
  3. bind mount → z
  4. tmpfs mount → ?? → default

Real example:

version: '3.7'
services: 
    my_service:
        image: my_quarkus_service
        container_name: my_quarkus_service
        volumes:
            - ./conf/microservice/application.properties:/work/config/application.properties:z
...

This syntax has all options available and it is easy to understand:

volumes:
    - type: <type_of_mount>
      source: <local_folder_or_file_path>
      target: <container_folder_or_file_path>
...

• type_of_mount: the mount type volume, bind, tmpfs or npipe
• local_folder_or_file_path: relative to the docker-compose.yml
• container_folder_or_file_path: Cannot be relative!
• A lot of other options.

version: '3.7'
services: 
    elasticsearch:
        image: elasticsearch:7.6.1
        container_name: elasticsearch
        networks: 
            - elk_net
        volumes:
            # Volume for logs persistence
            - type: bind
              source: ./logs
              target: /usr/share/elasticsearch/data
...

If you want to make the volumes of a compose work on windows use the short syntax. I haven't found any documentation supporting this but it works:

version: '3.7'
services: 
    elasticsearch:
        image: elasticsearch:7.6.1
        container_name: elasticsearch
        networks: 
            - elk_net
        volumes:
            # Volume for logs persistence
            - ./logs:/usr/share/elasticsearch/data

1. Volumes and mounts in docker-compose.yml.
2. More on persisting data.