docker 容器的文件系统在宿主机上存在的方式很复杂,这会带来下面几个问题:
为了能够 保存(持久化) 数据以及 共享 容器间的数据,docker 引入了数据卷(volume) 机制。数据卷是存在于一个或多个容器中的特定文件或文件夹,它可以绕过默认的联合文件系统,以正常的文件或者目录的形式存在于宿主机上。
其生存周期独立于容器的生存周期。
容器中主要有 两种 管理数据方式: 数据卷(Data Volumes) , 数据卷容器(Data Volume Containers) 。
数据卷是一个可供容器使用的特殊目录,它绕过文件系统,可以提供很多有用的特性:
数据卷的使用类似 linux 下对目录或文件进行 mount *** 作,目前Docker提供了 三种 不同的方式将数据从宿主机挂载到容器中,分别是
其中 volume 、 bind mount 比较常用, tmpfs mount 基本不会用
volumes作为Docker管理宿主机文件系统的一部分 ,默认位于 /var/lib/docker/volumes 目录中,不是宿主机已有数据,而是新建的。
docker 专门提供了 volume 子命令来 *** 作数据卷:
先创建一个名称为 hello 的数据卷并通过 ls 命令进行查看:
然后可以使用 inspect 命令看看数据卷hello的详细信息
该数据卷使用的 Driver 为默认的 local ,表示数据卷使用宿主机的本地存储;
Mountpoint 是 volumes 的挂载点,默认是本机 /var/lib/docker/volumes 下的一个目录。
所有Container的数据都保存在了这个目录下边,由于没有在创建时指定卷,所以Docker帮我们默认创建许多匿名卷。
使用 -v 选项也可以指定挂载一个本地的已有目录到容器中去作为数据卷:
docker run -it –-name robot1 -v /var/data:/opt/mydata ros/kinetic /bin/bash
上面的命令挂载主机的 /var/data 目录到容器的 /opt/mydata 目录。
这个功能在测试的时候特别方便,比如用户可以放置一些程序或数据到本地目录中,然后在容器中使用。另外,本地目录的路径必须是绝对路径,如果目录不存在,Docker 会自动创建。
Docker 挂载数据卷的默认权限是可读写 rw ,用户也可以通过 ro 标记指定为只读:
docker run -it –-name robot1 -v /var/data:/opt/mydata:ro ros/kinetic /bin/bash
加了 :ro 之后,容器内挂载的数据卷内的数据就变成只读的了。
除了把数据卷中的数据存储在宿主机,docker 还允许我们通过指定 volume driver 的方式把数据卷中的数据存储在其它的地方,比如 Azrue Storge 或 AWS 。
通过 vieux/sshfs 驱动把数据卷的存储在云主机上,docker 默认是不安装 vieux/sshfs 插件的,我们可以通过下面的命令进行安装:
docker plugin install --grant-all-permissions vieux/sshfs
然后通过 vieux/sshfs 驱动创建数据卷,并指定远程主机的登录用户名、密码和数据存放目录:
注意:确保指定的远程主机上的挂载点 /home/nick/sshvolume 目录是存在的,否则在启动容器时会报错。
最后在启动容器时指定挂载这个数据卷:
在容器中 /world 目录下 *** 作的文件都存储在远程主机的 /home/nick/sshvolume 目录中。进入容器 testcon 然后在 /world 目录中创建一个文件,然后打开远程主机的 /home/nick/sshvolume 目录进行查看,新建的文件会出现在那里。
当使用 bind mounts 将主机上的目录挂载到容器中时,目录由其在主机上的完整或相对路径引用。
bind mount 和 volume 其实都是利用宿主机的文件系统,不同之处在于volume是docker自身管理的目录中的子目录,所以不存在权限引发的挂载的问题,并且目录路径是docker自身管理的,所以也不需要在不同的服务器上指定不同的路径,不需要关心路径
bind mounts 可以挂载在宿主机系统的任意位置 ,但 bind mount 在不同的宿主机系统是不可移植的,比如Windows和Linux的目录结构是不一样的, bind mount 所指向的 host 目录也不能一样。这也是为什么 bind mount 不能出现在Dockerfile中的原因,因为这样Dockerfile就不可移植了。
如果使用 Bind mounts 挂载 宿主机目录 到 容器内非空目录 ,那么 此容器中的非空目录中的文件会被隐藏 ,容器访问这个目录时能够访问到的文件均来自于宿主机目录。这也是Bind mounts模式和Volumes模式最大的行为上的不同。
挂载存储在宿主机系统的内存中,而不会写入宿主机的文件系统;
这张图说明 bind mount 和 volume 其实都是利用宿主机的文件系统, Bind mounts 模式是将宿主机上的任意文件或文件夹挂载到容器,而 Volumes 本质上是将Docker服务管理的一块区域(默认是 /var/lib/docker/volumes 下的文件夹)挂载到容器。所以 volume 不存在权限引发的挂载的问题,并且目录路径是docker自身管理的,所以也不需要在不同的服务器上指定不同的路径,不需要关心路径。
相对于 bind mount , volume 是Docker Engine在自己的“地盘”分配了一个路径作为挂载点,自己地盘的权限肯定是安排的明明白白。所以,以上挂载宿主机路径的问题都解决了。
在使用 volume 作为数据卷挂载到容器时,直接用 volume 名称代替宿主机路径名就行:
docker run -d -v test_vol:/var/data some_image
这样就将数据卷 test_vol 挂载到了容器内的 /var/data 目录下。
命名的容器挂载数据卷,其它容器通过挂载这个(父容器)实现数据共享,挂载数据卷的容器,称之为数据卷容器
可以利用数据卷容器对其中的数据卷进行备份、恢复,以实现数据的迁移。
备份
使用下面的命令来备份 mydata 数据卷容器内的数据卷:
sudo docker run --volumes-from mydata -v $(pwd):/backup –-name worker ubuntu tar cvf /backup/backuptar /data
这个命令首先利用 Ubuntu 镜像创建了一个容器 worker。又使用 --volumes-from mydata 参数来让 worker 容器挂载 mydata 容器的数据卷。接下来使用 -v $(pwd):/backup 参数来挂载本地的当前目录到 worker 容器的 /backup 目录。
在 worker 容器启动后,使用了 tar cvf /backup/backuptar /data 命令来将 /data 下内容备份为容器内的 /backup/backuptar,即宿主主机的当前目录下的backuptar。
恢复
如果要恢复数据到一个容器,可以按照下面的 *** 作。首先创建一个带有数据卷的容器 mydata2:
sudo docker run -v /data –-name mydata2 ubuntu /bin/bash
然后创建另一个新的容器,挂载 mydata2 的数据卷,并使用 tar 解压缩备份文件到所挂载的容器卷中:
sudo docker run --volumes-from mydata2 -v $(pwd):/backup busybox tar xvf /backup/backuptar
如果用户需要在容器之间共享一些持续更新的数据,最简单的方式是使用数据卷容器。数据卷容器其实就是一个普通的容器,专门用它提供数据卷供其他容器挂载。下面简单介绍其使用方法。
首先要创建一个数据卷容器 mydata,并在其中创建一个数据卷挂载到 /data 目录。
sudo docker run -it -v /data –-name mydata ubuntu
然后在其他容器中使用 --volumes-from 来挂载 mydata 容器中的数据卷。例如创建两个容器 mycon1 和 mycon2,并从 mydata 容器挂载数据卷:
sudo docker run -it --volumes-from mydata –-name mycon1 ubuntu
sudo docker run -it --volumes-from mydata –-name mycon2 ubuntu
(注意,命令中没有指定数据卷的信息,也就是说新容器中挂载数据卷的目录和源容器中是一样的。)
此时容器 mycon1 和 mycon2 都挂载同一个数据卷到相同的目录 /data。三个容器任何一个在该目录下写入数据其他容器都能看到。
可以多次使用 --volumes-from 参数来从多个容器挂载多个数据卷。还可以从其他已经挂载了容器的容器来挂载数据卷。并且使用 --volumes-from 参数所挂载数据卷的容器自身并不需要保持在运行状态。
但删除挂载了数据卷的容器时,数据卷并不会被自动删除。如果要删除一个数据卷,必须在删除最后一个还挂载着它的容器时显式的使用 docker rm -v 命令来指定同时删除关联的容器。
如何对已经运行的容器挂载目录?
>
理论上是不能把以前的表空间作为新数据库的表空间来使用的。如果原表空间的数据不是很重要的话就在新数据库中再创建一个一样的表空间吧。
如果很想恢复以前表空间的数据的话,按下列方式试试吧。
1、在新数据库中创建一个和以前一样的表空间。
2、用以前的数据文件来顶替新创建的数据文件。但系统的检查点变了数据库肯定不能启动。
3、要先脱机(Offline)数据文件,进行做一次介质恢复。数据库启动后再进行联机(Online)。
以上做法我没试过,关键在于介质恢复能否使检查点获得一致,或许会成功啊。
如果对MySQL比较熟悉,那么可以使用MySQL异机迁移的方法:
先确定MySQL的运行系统、发行版、版本号,以前的配置文件。
根据以上信息在Docker环境下新建一台全新的MySQL。
根据业务需要实施停机迁移/在线迁移,将数据迁入Docker内的MySQL。
停机迁移:直接拷贝数据文件(物理迁移)、全量Dump导出(逻辑备份迁移)、xtraback备份(物理备份迁移)
在线迁移:将新库作为从库加入集群,完成同步后fo切换,原主库下线。
如果对Docker比较熟悉,可以使用Docker整机迁移的方法:
整机虚拟化直接作为一个镜像在Docker内运行。
这种方法虽然简单,但过程漫长而且运行时性能损耗非常大,也容易出问题,不是很推荐。
以上就是关于Docker(5)——数据管理全部的内容,包括:Docker(5)——数据管理、web应用如何配置连接容器上的redis和数据库、重装系统后,新建oracle数据库,怎样挂载已有的表空间使用等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)