1. Docker(5)——数据管理
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/backup.tar /data
这个命令首先利用 Ubuntu 镜像创建了一个容器 worker。又使用 --volumes-from mydata 参数来让 worker 容器挂载 mydata 容器的数据卷。接下来使用 -v $(pwd):/backup 参数来挂载本地的当前目录到 worker 容器的 /backup 目录。
在 worker 容器启动后，使用了 tar cvf /backup/backup.tar /data 命令来将 /data 下内容备份为容器内的 /backup/backup.tar，即宿主主机的当前目录下的backup.tar。
恢复
如果要恢复数据到一个容器，可以按照下面的操作。首先创建一个带有数据卷的容器 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/backup.tar
如果用户需要在容器之间共享一些持续更新的数据，最简单的方式是使用数据卷容器。数据卷容器其实就是一个普通的容器，专门用它提供数据卷供其他容器挂载。下面简单介绍其使用方法。
首先要创建一个数据卷容器 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 命令来指定同时删除关联的容器。
如何对已经运行的容器挂载目录？
https://blog.51cto.com/hjun169/2440799
手动修改mount挂载的json文件，狂神的那个视频里面也有写。
深刻理解Docker镜像大小
https://blog.csdn.net/shlazww/article/details/47375009
理解docker的分层镜像实现 base 镜像共享（DockerFile）
https://blog.csdn.net/lu_1110/article/details/106533490
2. 什么是数据持久化为什么要持久化
数据持久化就是将内存中的数据模型转换为存储模型,以及将存储模型转换为内存中的数据模型的统称. 数据模型可以是任何数据结构或对象模型,存储模型可以是关系模型、XML、二进制流等。cmp和Hibernate只是对象模型到关系模型之间转换的不同实现。
数据持久化对象的基本操作有：保存、更新、删除、查询等。
Hibernate框架中数据持久化机制：
在业务程序与数据库之间，Hibernate框架使用Session会话，来完成数据的提交、更新、删除、查询等等。
1、向数据库提交数据
在程序中保存对象时，会把数据保存到Session会话中，然后根据框架的配置文件，自动或手动决定什么时候把这种保存提交到数据库。
2、从数据库中查询数据
在查询数据之前，需要清理缓存（手动清理，或者通过配置文件框架自动清理）清理缓存的目的是为了使Session会话中的数据与数据库中的数据保持一致。然后程序只需要查询Session会话中的数据即可。
(2)容器数据的持久化存储扩展阅读：
使用数据持久化有以下好处：
1、程序代码重用性强，即使更换数据库，只需要更改配置文件，不必重写程序代码。
2、业务逻辑代码可读性强，在代码中不会有大量的sql语言，提高程序的可读性。
3、持久化技术可以自动优化，以减少对数据库的访问量，提高程序运行效率。
3. k8s中的Mysql数据库持久化存储
一、配置：
环境：
CentOS7
VMware
笔者配置了四台虚拟机：
K8S-Master节点: 3GB内存 2核CPU 20GB硬盘空间
K8S-node1节点: 2GB内存 2核CPU 30GB硬盘空间
K8S-node2节点: 2GB内存 2核CPU 30GB硬盘空间
镜像仓库节点: 2GB内存 2核CPU 50GB硬盘空间
二、节点规划：
使用三台虚拟机搭建K8S集群，使用一台虚拟机搭建镜像仓库。
每台虚拟机配置两块网卡，其中一块为“NAT模式”，用于拉取镜像等功能。
另外一块网卡为“仅主机模式”，用于集群节点间的通信。归划如下：
K8s-master节点:
仅主机模式：10.10.10.200
NAT模式： 192.168.200.130
K8S-node1节点:
仅主机模式：10.10.10.201
NAT模式： 192.168.200.131
K8S-node2节点:
仅主机模式：10.10.10.202
NAT模式： 192.168.200.132
镜像仓库节点:
仅主机模式：10.10.10.101
NAT模式： 192.168.200.150
三、版本信息
Linux内核版本：
Linux version 3.10.0-862.el7.x86_64 ([email protected])
(gcc version 4.8.5 20150623 (Red Hat 4.8.5-28) (GCC) )
#1 SMP Fri Apr 20 16:44:24 UTC 2018
K8s集群版本为1.15.0版本：
四、基于StatefulSet与PV/PVC的MySql持久化存储实验
1. 在每个节点安装nfs服务
在“镜像仓库”节点，执行以下命令：
yum install -y nfs-common nfs-utils rpcbind
在k8s集群，执行以下命令：
yum install -y nfs-utils rpcbind
2. 在“镜像仓库”节点下，配置nfs服务器
mkdir /nfs_mysql
Chmod 777 /nfs_mysql/
(在测试环境中，为了不考虑用户属性，暂时赋予777权限，但在生产环境不推荐这样做)
Chown nfsnobody /nfs_mysql/
echo “/nfs_mysql *(rw,no_root_squash,no_all_squash,sync)” >> /etc/exports
cat /etc/exports
/nfs_mysql *(rw,no_root_squash,no_all_squash,sync)
systemctl start rpcbind
systemctl start nfs
3. 测试nfs服务是否可用
mkdir /test
showmount -e 10.10.10.101
可见/nfs_mysql *已暴露于共享目录，接下来测试挂载是否可用：
在master节点下执行：
mount -t nfs 10.10.10.101:/nfs_mysql /test/
echo "hello-world">>/test/1.txt
在镜像仓库节点下查看1.txt是否存在，若存在则挂载成功：
可见nfs服务可以正常使用，接下来删除test目录和1.txt
在镜像仓库下：
[root@hub nfs_mysql]# rm -f 1.txt
在Master节点下:
[root@k8s-master ~]# umount /test/
[root@k8s-master ~]# rm -rf /test/
同理,依照以上步骤同时创建：（提供多个mysql副本进行挂载）
nfs_mysql1
nfs_mysql2
完成后需要重启nfs服务
systemctl restart rpcbind
systemctl restart nfs
最终效果：
4. 将nfs封装成pv
创建mysql_test文件夹，将yaml文件统一保存在此目录下
mkdir mysql_test
cd mysql_test
vim mysql-pv.yml
mysql-pv.yml配置如下：
apiVersion: v1
kind: PersistentVolume
metadata:
name: mysql-pv
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: nfs
nfs:
path: /nfs_mysql
server: 10.10.10.101
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: mysql-pv1
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: nfs
nfs:
path: /nfs_mysql1
server: 10.10.10.101
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: mysql-pv2
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: nfs
nfs:
path: /nfs_mysql2
server: 10.10.10.101
注意：
在k8s集群15版本中recycle回收策略已被删除，只能用retain策略或者Delete策略。这里我们使用 persistentVolumeReclaimPolicy: Retain
执行命令：
kubectl create -f mysql-pv.yml
kubectl get pv
如图所示，即为Pv创建成功。
5. 部署MySQL，在mysql_test目录下编写mysql.yml，配置文件如下
apiVersion: v1
kind: Service
metadata:
name: mysql
labels:
app: mysql
spec:
ports:
- port: 3306
name: mysql
clusterIP: None
selector:
app: mysql
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: mysql
spec:
selector:
matchLabels:
app: mysql
serviceName: "mysql"
replicas: 3
template:
metadata:
labels:
app: mysql
spec:
containers:
- name: mysql
image: mysql:5.6
env:
- name: MYSQL_ROOT_PASSWORD
value: password
ports:
- containerPort: 3306
name: mysql
volumeMounts:
- name: mysql-persistent-storage
mountPath: /var/lib/mysql
volumeClaimTemplates:
- metadata:
name: mysql-persistent-storage
spec:
accessModes: ["ReadWriteOnce"]
storageClassName: "nfs"
resources:
requests:
storage: 1Gi
执行以下命令，部署mysql服务：
kubectl create -f mysql.yml
如图可知，mysql按StatefulSet依次创建了mysql-0 mysql-1 mysql-2
查看各个Pod部在哪个节点：
6. 通过创建临时容器，使用MySQL客户端发送测试请求给MySQL master节点
注意：
主机名为mysql-0.mysql；跨命名空间的话，主机名请使用mysql-0.mysql. [NAMESPACE_NAME].如果没有指定命名空间，默认为default，即 mysql-0.mysql. default。
这里笔者打算关闭node2节点来模拟node2宕机，来测试是否实现数据的持久化存储，
所以我们向node2上的mysql1写入数据。
执行以下命令，访问mysql1：
kubectl run mysql-client --image=mysql:5.6 -it --rm --restart=Never -- mysql -h mysql-1.mysql.default -p password
创建数据库demo,并向messages表中写入hello-world
CREATE DATABASE demo;
CREATE TABLE demo.messages (message VARCHAR(250));
INSERT INTO demo.messages VALUES ('hello-world');
如图所示
接下来我们来关闭k8s-node2虚拟机，模拟宕机
查看nodes的运行状态，可知node2的状态已转变为NotReady
一段时间后，k8s将Pod MySql -1迁移到节点k8s-node1
由于时间过长，笔者把三个Pod都删除重启后，验证数据：
MySQL服务恢复，数据完好无损！
4. Linux里面什么是数据持久化
数据持久化顾名思义就是把程序中的数据以某种形式保存到某存贮介质中，以达到持久化的目的。当程序运行时，一些数据是临时保存在内存中，一旦退出系统，这些数据就丢失了。那么，使用某种手段将数据保存在硬盘上或者数据库中，这样即使退出系统后又重新启动系统，那么这些数据仍然可以重新找回来。
例如管理员向一个用户管理系统中添加了一个用户的资料，那么这个系统需要将新添加的资料保存到数据库中，否则系统退出或者电脑重启后该用户资料就会丢失。将数据从内存保存到数据库中，这便是数据的持久化。当然，数据库只是持久化方式中的一种，也可以保存在其他的永久存贮介质中。
图为数据持久化的过程示意图。
持久化（Persistence），即把数据（如内存中的对象）保存到可永久保存的存储设备中（如磁盘）。持久化的主要应用是将内存中的对象存储在数据库中，或者存储在磁盘文件中、XML数据文件中等等。
持久化是将程序数据在持久状态和瞬时状态间转换的机制。
DBC就是一种持久化机制。文件IO也是一种持久化机制。
日常持久化的方法
在一定周期内保持不变就是持久化,持久化是针对时间来说的。数据库中的数据就是持久化了的数据,只要你不去删除或修改。比如在浏览器中一次Session会话中Session对象变量也是不变的,是Session容器中持久化。对象持久化的方式有很多种,根据周期不同有,page,Session,Application。对象序列化机制对于需要将对象的状态保存到文件中，而后能够通过读入对象状态来重新构造对象，恢复程序状态. 对象序列化的过程是对象持久化的方法之一,把对象保存到文件中。
简单的理解持久化可以在二个层面：应用层和系统层、
应用层
如果关闭(shutdown)你的应用然后重新启动则先前的数据依然存在。
系统层
如果关闭(shutdown)你的系统（电脑）然后重新启动则先前的数据依然存在。
持久化是一种对象服务实现至少3个接口
，就是把内存中的对象保存到外存中，让以后能够取回。需要实现至少3个接口：
void Save(object o) 把一个对象保存到外存中
Object Load(object oid) 通过对象标识从外存中取回对象
boolExists(object oid) 检查外存中是否存在某个对象.
类似概念序列化
我们先跳开一下，看看另一个类似的有用概念：序列化Serialize也是一种对象服务，就是把内存中的对象序列化成流、或者把流反序列化成对象。需要实现2个接口：
void Serialize(Stream stream,object o) 把对象序列化到流中
object Deserialize(Stream stream) 把流反序列化成对象
序列化和持久化很相似，有些人甚至混为一谈，其实还是有区别的，序列化是为了解决对象的传输问题，传输可以在线程之间、进程之间、内存外存之间、主机之间进行。我之所以在这里提到序列化，是因为我们可以利用序列化来辅助持久化，可以说凡是可以持久化的对象都可以序列化，因为序列化相对容易一些（也不是很容易），所以主流的软件基础设施，比如.net和java，已经把序列化的框架完成了。
持久化方案可以分为关系数据库方案、文件方案、对象数据库方案、xml数据库方案
现今主流的持久化方案是关系数据库方案，
关系数据库方案不仅解决了并发的问题，更重要的是，关系数据库还提供了持久化服务之外的价值：统计分析功能。刚才我说到，凡是可以序列化的对象都可以持久化，极端的说，我们可以只建立一个表Object(OID,Bytes)，但基本上没有人这么做，因为一旦这样，我们就失去了关系数据库额外的统计分析功能。关系数据库和面向对象之间有一条鸿沟，因为二者模式不匹配，所以就存在一个OR映射问题。
Redis支持两种数据持久化方式：rdb方式和aof方式。前者会根据配置的规则定时将内存中的数据持久化到硬盘上，后者则是在每次执行写命令之后将命令记录下来。两种持久化方式可以单独使用，但是通常会将两者结合使用。
1、RDB方式
RDB方式的持久化是通过快照的方式完成的。当符合某种规则时，会将内存中的数据全量生成一份副本存储到硬盘上，这个过程称作”快照”，redis默认开启该持久化功能，具体配置如下：
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename mp.rdb
#文件名称
dir ./
#rdb文件存放路径
配置后系统会自动进行快照，save 60 10000表示60秒内有10000次写入，那么就会调用bgsave
除了系统自动进行快照外，我们也可以手动执行SAVE或BGSAVE命令主动进行快照操作：
执行SAVE或BGSAVE命令
执行FLUSHALL命令
2、AOF方式
在使用Redis存储非临时数据时，一般都需要打开AOF持久化来降低进程终止导致的数据丢失，AOF可以将Redis执行的每一条写命令追加到硬盘文件中，这一过程会降低Redis的性能。
默认情况下，Redis没有开启AOF（append only file）持久化功能，可以通过在配置文件中作如下配置启用：
appendonly no #是否开启aof，开启时将no改为yes
appendfilename "appendonly.aof" 持久化文件名称
auto-aof-rewrite-percentage 100
#当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程。
auto-aof-rewrite-min-size 64mb
#当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。
appendfsync :everysec (推荐配置)
#持久化策略
always (同步持久化，每次发生数据变更会被立即记录到磁盘，性能差但数据完整性比较好)
everysec (异步操作，每秒记录，如果一秒钟内宕机，有数据丢失)
no （将缓存回写的策略交给系统，linux 默认是30秒将缓冲区的数据回写硬盘的）
一般来说可以考虑同时使用两种持久化方案.