#Docker, by default, doesn’t come with persistent storage, which presents an issue to some workloads customers that want to run in containers – however, there are ways to achieve persistent storage #Container technology provides a great way to create, manage and run applications with a high degree of efficiency. A physical host running Docker, for example, can manage hundreds of containers at the same time, through efficient use of scheduling and memory resources.
A container is effectively a collection of processes needed to run an application that uses features of the underlying operating system to access networking and storage functions.
Operating characteristics such as cgroups and namespaces provide process isolation between containers, making it appear to each container that it is the only instance running on the server.
The initial intention was for containers to be transient or temporary in nature, spun up to manage a particular demand or workload. While this is an efficient way to run applications for the time they are needed, the fact a container (by default) loses all of its data when deleted represents a problem for running applications like databases, where persistent storage is essential, rather than just desirable.
Docker provides mechanisms to enable persistent data across the lifetime of a container. (This article refers to features up to and including Docker 1.12. The Docker ecosystem is rapidly changing and new features are released all the time, so be sure to check which version runtime you are using).
There are four ways to provide persistent storage to Docker containers: data volumes, data volume containers, mounting a host directory and Docker storage plugins.
Docker data volumes
A data volume is a directory within the file system of the host that is used to store persistent data for a container (typically under /var/lib/docker/volumes). The directory appears as a mount point specified by the administrator when starting the container up (eg /data).
By default, volumes are given 64-character randomly generated UUIDs, unless a friendlier name is provided.
Pro tip: It is definitely worth providing a friendly name that relates to the name of the associated container, as this becomes especially helpful when doing clean-up on orphan volumes.
Docker data volumes created in this way will persist across the container being started and stopped. Details of the volumes attached to a container can be found by running docker inspect against the container. Attached volumes are shown in the “Mounts” section. A list of volumes can be found using the docker volume ls command, however there’s no direct way to show a container associated with a volume using the docker volume commands.
Information written to a data volume is managed outside the storage driver that is normally used to manage Docker images. This means the volume is accessed much faster than it would be when writing to a directory within the container. This is because the storage driver doesn’t have to maintain update/change differences from the container image itself.
Unfortunately, data volumes aren’t really that useful because existing volumes can’t be attached to either a running or a new container. This can lead to orphan volumes (volumes with no associated container) and be an issue to clean up, especially when friendly volume names haven’t been used.
Data volume containers
An alternative to volumes is to create a container used specifically to manage volumes. This container doesn’t run any code, but instead acts as a single access point from which other containers can access a data volume.
http://www.computerweekly.com/feature/Docker-storage-how-to-get-persistent-storage-in-Docker
No comments:
Post a Comment