| |
| modul:m347:learningunits:lu05:lu05a [2025/03/07 11:50] – angelegt dgaravaldi | modul:m347:learningunits:lu05:lu05a [2025/03/07 11:58] (aktuell) – dgaravaldi |
|---|
| * read write layers which hold temporary or volatile data. | * read write layers which hold temporary or volatile data. |
| |
| <figure> | {{:modul:m347:learningunits:lu05:storage_3.png?500|Fig-2: Read only layer}} |
| <img style=width: 400px; src=themen/05/img/Storage_3.png> | |
| <figcaption><small>Fig-2: read only layer</small></figcaption> | |
| </figure> | |
| |
| If a container stops or dies, the volatile data vanishes. | If a container stops or dies, the volatile data vanishes. |
| |
| <figure> | {{:modul:m347:learningunits:lu05:storage_4.png?500|Fig-3: Read-Write layer}} |
| <img style=width: 400px; src=themen/05/img/Storage_4.png> | |
| <figcaption><small>Fig-3: read-write layer</small></figcaption> | |
| </figure> | |
| |
| We need to back up the important data from the volatile read write layer of the container. Now the next question is where to store the data? Well, just anywhere. Do you want to store it on some machine which hosts docker? Go ahead. Do you want to store it to another server? Go ahead. Do you want to store it on cloud? Go ahead as well. And the last and genuine question which comes to my mind is. | We need to back up the important data from the volatile read write layer of the container. Now the next question is where to store the data? Well, just anywhere. Do you want to store it on some machine which hosts docker? Go ahead. Do you want to store it to another server? Go ahead. Do you want to store it on cloud? Go ahead as well. And the last and genuine question which comes to my mind is. |
| <br''Volumes'' are storage objects of docker which are mounted to containers. In terms of implementation, ''volumes'' are dedicated directories on hosts file system. If a containerized app is shipped along with the ''volume'', people apart from the developer himself using the app will end up creating such a directory on their own docker hosts. | <br''Volumes'' are storage objects of docker which are mounted to containers. In terms of implementation, ''volumes'' are dedicated directories on hosts file system. If a containerized app is shipped along with the ''volume'', people apart from the developer himself using the app will end up creating such a directory on their own docker hosts. |
| |
| <figure> | |
| <img style=width: 400px; src=themen/05/img/Storage_5.png> | |
| <figcaption><small>Fig-4: Volume as storage type</small></figcaption> | |
| </figure> | |
| |
| | {{:modul:m347:learningunits:lu05:storage_5.png?500|Fig-4: Volume as storage type}} |
| |
| Container provides data to docker engine and user provides commands to store the data in the ''volume''or to manage the data in the same. Although what container knows is just the name of the ''volume'', not the path on the host. The translation takes place on docker machines end, so external applications having access to containers will have no means to access ''volumes'' directly.This isolation maintains the integrity and security of hosts and containers. | Container provides data to docker engine and user provides commands to store the data in the ''volume''or to manage the data in the same. Although what container knows is just the name of the ''volume'', not the path on the host. The translation takes place on docker machines end, so external applications having access to containers will have no means to access ''volumes'' directly.This isolation maintains the integrity and security of hosts and containers. |
| Second option is ''bind mount'' that allows to use any directory on docker host to store the data. While this might be convenient in some cases, it also exposes the storage location of the container which can have negative impact on the overall security of the application and the host itself. Apart from that other users may not have such path on their host and creating so may not be under their privileges. | Second option is ''bind mount'' that allows to use any directory on docker host to store the data. While this might be convenient in some cases, it also exposes the storage location of the container which can have negative impact on the overall security of the application and the host itself. Apart from that other users may not have such path on their host and creating so may not be under their privileges. |
| |
| <figure> | {{:modul:m347:learningunits:lu05:storage_6.png?500|Fig-5: Bind mount as storage type}} |
| <img style=width: 400px; src=themen/05/img/Storage_6.png> | |
| <figcaption><small>Fig-5: Bind mount as storage type</small></figcaption> | |
| </figure> | |
| |
| |
| Finally we have ''tempfs'' or temporary file system. Volumes and bind mount let you share the files between host machine and container so that you can persist the data, even after the container is stopped. If you are running docker on Linux you have 3rd option: ''tempfs'' mounts. When you create a container with ''tempfs'' mount the container can create files outside the containers writable layer. As opposed to volumes and bind mounts, a ''tempfs'' mount is temporary persisted in the host memory, not in storage. | Finally we have ''tempfs'' or temporary file system. Volumes and bind mount let you share the files between host machine and container so that you can persist the data, even after the container is stopped. If you are running docker on Linux you have 3rd option: ''tempfs'' mounts. When you create a container with ''tempfs'' mount the container can create files outside the containers writable layer. As opposed to volumes and bind mounts, a ''tempfs'' mount is temporary persisted in the host memory, not in storage. |
| |
| <figure> | {{:modul:m347:learningunits:lu05:storage_7.png?500|Fig-6: ''tempfs'' as storage type}} |
| <img style=width: 400px; src=themen/05/img/Storage_7.png> | |
| <figcaption><small>Fig-6: ''tempfs'' as storage type</small></figcaption> | |
| </figure> | |
| |
| When the container stops, the ''tempfs'' mount is removed and the files written there won't be persisted. The only sensible use case which comes to my mind for ''tempfs'' is to store sensitive files which you don't want to persist once the application gets deleted. Something like the browsing history which gets deleted if we use the Incognito tab. Tempfs mounts have their limitations. | When the container stops, the ''tempfs'' mount is removed and the files written there won't be persisted. The only sensible use case which comes to my mind for ''tempfs'' is to store sensitive files which you don't want to persist once the application gets deleted. Something like the browsing history which gets deleted if we use the Incognito tab. Tempfs mounts have their limitations. |