验证 Swarm 数据持久性 - 每天5分钟玩转 Docker 容器技术(104)

上一节我们成功将 Rex-Ray Volume 挂载到了 Service。本节验证?Failover 时,数据不会丢失。

Scale Up

增加一个副本:

docker?service?update?--replicas?2?my_web

运行之前我们先推测一下,理想的结果应该是:swarm 在?swarm-worker2?上启动第二个副本,同时也将挂载 volume?my_web

对比一下实际的运行结果:

出现了一点复杂的状况:

  1. swarm 首先尝试在?swarm-worker2?上启动第二个副本,但在 mount volume 失败。
  2. 重试了三次都失败了。
  3. 最后在?swarm-worker1?成功启动第二个副本。

mount 失败的原因是:以 VirtualBox 为 backend 的 Rex-Ray volume 不支持同时 attach 到多个 Host。

需要注意:这实际上是 VirtualBox 的限制,而非 Rex-Ray。如果 backend 选择 Ceph RBD 就没有这个问题。

更新 Volume

更新 volume 的内容。

service 返回更新内容,数据已经同步到副本。

当前的实验环境如图所示:

Failover

现在模拟故障情况。shutdown 节点?swarm-worker1,过一会,所有副本都会迁移到?swarm-worker2

?

访问 service,以前更新的内容完整地保留了下来。

当前的实验环境如图所示:

Rex-Ray 作为 Swarm 的存储编排方案能够很好地支持跨主机 volume 管理,而且当容器在集群中迁移时 volume 也能够自动迁移。

Swarm 数据管理就讨论到这里,下一节我们学习 Service 的 Replicated Mode 和 Global Mode。

书籍:

1.《每天5分钟玩转Docker容器技术》
https://item.jd.com/16936307278.html

2.《每天5分钟玩转OpenStack》
https://item.jd.com/12086376.html

时间: 2024-11-03 22:16:48

验证 Swarm 数据持久性 - 每天5分钟玩转 Docker 容器技术(104)的相关文章

Swarm 如何存储数据?- 每天5分钟玩转 Docker 容器技术(103)

service 的容器副本会 scale up/down,会 failover,会在不同的主机上创建和销毁,这就引出一个问题,如果 service 有要管理的数据,那么这些数据应该如何存放呢? 选项一:打包在容器里. 显然不行.除非数据不会发生变化,否则,如何在多个副本直接保持同步呢? 选项二:数据放在 Docker 主机的本地目录中,通过 volume 映射到容器里. 位于同一个主机的副本倒是能够共享这个 volume,但不同主机中的副本如何同步呢? 选项三:利用 Docker 的 volum

如何共享数据?- 每天5分钟玩转 Docker 容器技术(41)

数据共享是 volume 的关键特性,本节我们详细讨论通过 volume 如何在容器与 host 之间,容器与容器之间共享数据. 容器与 host 共享数据 我们有两种类型的 data volume,它们均可实现在容器与 host 之间共享数据,但方式有所区别. 对于 bind mount 是非常明确的:直接将要共享的目录 mount 到容器.具体请参考前面 httpd 的例子,不再赘述. docker managed volume 就要麻烦点.由于 volume 位于 host 中的目录,是在

万能日志数据收集器 Fluentd - 每天5分钟玩转 Docker 容器技术(91)

前面的 ELK 中我们是用 Filebeat 收集 Docker 容器的日志,利用的是 Docker 默认的 logging driver json-file,本节我们将使用 fluentd 来收集容器的日志. Fluentd 是一个开源的数据收集器,它目前有超过 500 种的 plugin,可以连接各种数据源和数据输出组件.在接下来的实践中,Fluentd 会负责收集容器日志,然后发送给 Elasticsearch.日志处理流程如下: 这里我们用 Filebeat 将 Fluentd 收集到的

Swarm 如何实现 Failover?- 每天5分钟玩转 Docker 容器技术(98)

故障是在所难免的,容器可能崩溃,Docker Host 可能宕机,不过幸运的是,Swarm 已经内置了 failover 策略. 创建 service 的时候,我们没有告诉 swarm 发生故障时该如何处理,只是说明了我们期望的状态(比如运行3个副本),swarm 会尽最大的努力达成这个期望状态,无论发生什么状况. 以上一节我们部署的 Service 为例,当前 3 个副本分布在 swarm-worker1 和 swarm-worker2 上. 现在我们测试 swarm 的 failover 特

MySQL 如何使用 PV 和 PVC?- 每天5分钟玩转 Docker 容器技术(154)

本节演示如何为 MySQL 数据库提供持久化存储,步骤为: 创建 PV 和 PVC. 部署 MySQL. 向 MySQL 添加数据. 模拟节点宕机故障,Kubernetes 将 MySQL 自动迁移到其他节点. 验证数据一致性. 首先创建 PV 和 PVC,配置如下: mysql-pv.yml mysql-pvc.yml 创建 mysql-pv 和 mysql-pvc: 接下来部署 MySQL,配置文件如下: PVC mysql-pvc Bound 的 PV mysql-pv 将被 mount

如何访问 Service?- 每天5分钟玩转 Docker 容器技术(99)

前面我们已经学习了如何部署 service,也验证了 swarm 的 failover 特性.不过截止到现在,有一个重要问题还没有涉及:如何访问 service?这就是本节要讨论的问题. 为了便于分析,我们重新部署 web_server. ① docker service rm 删除 web_server,service 的所有副本(容器)都会被删除. ② 重新创建 service,这次直接用 --replicas=2 创建两个副本. ③ 每个 worker node 上运行了一个副本. 好了,

如何滚动更新 Service?- 每天5分钟玩转 Docker 容器技术(102)

在前面的实验中,我们部署了多个副本的服务,本节将讨论如何滚动更新每一个副本. 滚动更新降低了应用更新的风险,如果某个副本更新失败,整个更新将暂停,其他副本则可以继续提供服务.同时,在更新的过程中,总是有副本在运行的,因此也保证了业务的连续性. 下面我们将部署三副本的服务,镜像使用 httpd:2.2.31,然后将其更新到 httpd:2.2.32. 创建服务: docker service create --name my_web --replicas=3 httpd:2.2.31 将 serv

Secret 的使用场景 - 每天5分钟玩转 Docker 容器技术(109)

我们可以用 secret 管理任何敏感数据.这些敏感数据是容器在运行时需要的,同时我们不又想将这些数据保存到镜像中. secret 可用于管理: 用户名和密码. TLS 证书. SSH 秘钥. 其他小于 500 KB 的数据. secret 只能在 swarm service 中使用.普通容器想使用 secret,可以将其包装成副本数为 1 的 service. 这里我们再举一个使用 secret 的典型场景. 数据中心有三套 swarm 环境,分别用于开发.测试和生产.对于同一个应用,在不同的

hostPath Volume - 每天5分钟玩转 Docker 容器技术(148)

hostPath Volume 的作用是将 Docker Host 文件系统中已经存在的目录 mount 给 Pod 的容器.大部分应用都不会使用 hostPath Volume,因为这实际上增加了 Pod 与节点的耦合,限制了 Pod 的使用.不过那些需要访问 Kubernetes 或 Docker 内部数据(配置文件和二进制库)的应用则需要使用 hostPath. 比如 kube-apiserver 和 kube-controller-manager 就是这样的应用,通过 kubectl e