Scribd
Upload
12 views17 pages

Part 4 - Docker Storage

Uploaded by

Daniel Pepuho
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
12 views17 pages

Part 4 - Docker Storage

Uploaded by

Daniel Pepuho
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 17

Part 4

Docker storage
Manage Data
- Data doesn’t persist when container no longer exists
- Difficult to get data out of container
- Container’s writable layer is tightly coupled with the host machine
- Data storage options
- Volumes
- Bind mounts
- Tmpfs (storing file in memory, not persisted)
Docker storage
- Bind mount
- Volume
- Stored at /var/lib/docker/volumes
- tmpfs
Good Use
- Volumes : Sharing data among multiple containers, when container stops or
removed, the volume still exists
- Bind mounts : sharing configuration files from host machine to containers
Case 1
- Create volume name volume1
- Start containers
- Instance1
- Instance2
- Both shares a volume and mounted inside in directory /mydata
- Write number 1 until 1000 to file number.txt in /mydata from instance1
- Check on /mydata on instance2
- Destroy both containers (instance1 and instance 2)
- Run another container (instance3), check whether number.txt is still there
Create volume, and inspect

Volume1 location on
filesystem
Run instance 1
Run instance1 and write number.txt in /mydata
Run instance 2
Run instance1 and write number.txt in /mydata
Start another container
- Remove instance1 and instance2
“docker rm -f instance1 instance2”
- Start instance3
- docker run -it --rm --name instance3 -v volume1:/mydata
alpine:3.18 ls -la /mydata/number.txt
Case 2
- From the previous case we have volume1
- Backup content of volume1 into file backup.zip into local filesystem ( backup )
- Create another volume (volume2)
- Start another container, restore the backup to volume2
- Make local directory for storing backup

- Run container named backup1


- Mount to volume1
- Provide another bind mount to local directory
(backup)

- Execute backup process by tar with gzip and


store to internal mount point
- The result backup.zip can be available in
local directory
- Create volume2
- Run container restore1
- Mounted to volume2 on /mydata
- Mounted to backup location on local directory on
/backup
- Exec extraction from backup.zip in / (because
backup.zip is already in /mydata)
Case 3
- Sharing data between containers run on cross subnet overlay network
- Using mylab3 (192.168.20.0/24) from previous docker networking case
- C1 will run as
- Container provides ssh service on port 9022
- Using bind mount to local directory /shareddata
- Mount inside container /shareddata
- User login is user1 with password user1qwerty
- C2 and C3 will run a container
- Shares volume on C1
- Mounted in directory /shareddata using sshfs
Case 3

C1 C2
C3

mylab3
192.168.20.0/24
192.168.20.254
Cross
subnet

Docker host 1 Docker host 2 Docker host 3


- Run c1 on docker host 1
On c1 - Run c1 with entrypoint /config/install.sh
- Run c1 on network mylab3
- Run automated script to:
- Install openssh server
- Add user user1 and set the password
- Run sshd on foreground
- C1 now can serve ssh on port 9022
- Local directory shareddata will be mounted
inside container on /shareddata
Containing files :
- testing
- testing2
On c2 - Run C2 on docker host 2
- Connect to network mylab3
- On startup c2 will run sshfs
and mount remotely to c1
- It will be located on
/shareddata
On c2
Inside c2, we can see directory shared data
Has the same content with sharedata on c1

On c3 ???

You might also like