dockerswarm放弃,docker swarm stack 区别

Docker Swarm

Swarm 是使用 SwarmKit 构建的 Docker 引擎内置（原生）的集群管理和编排工具。 Docker Swarm 是 Docker 官方三剑客项目之一，提供 Docker 容器集群服务，是 Docker 官方对容器云生态进行支持的核心方案。

使用它，用户可以将多个 Docker 主机封装为单个大型的虚拟 Docker 主机，快速打造一套容器云平台。Swarm mode 内置 kv 存储功能，提供了众多的新特性，比如：具有容错能力的去中心化设计、内置服务发现、负载均衡、路由网格、动态伸缩、滚动更新、安全传输等。使得 Docker 原生的 Swarm 集群具备与 Mesos 、 Kubernetes 竞争的实力。使用 Swarm 集群之前需要了解以下几个概念。

运行 Docker 的主机可以主动初始化一个 Swarm 集群或者加入一个已存在的 Swarm 集群，这样这个运行 Docker 的主机就成为一个 Swarm 集群的节点 (node) 。节点分为 管理 (manager) 节点和工作 (worker) 节点 。

管理节点用于 Swarm 集群的管理， docker swarm 命令基本只能在管理节点执行（节点退出集群命令 docker swarm leave 可以在工作节点执行）。一个 Swarm 集群可以有多个管理节点，但只有一个管理节点可以成为 leader ，leader 通过 raft 协议实现。

工作节点是任务执行节点，管理节点将服务 ( service ) 下发至工作节点执行。管理节点默认也作为工作节点。你也可以通过配置让服务只运行在管理节点。来自 Docker 官网的这张图片形象的展示了集群中管理节点与工作节点的关系。

任务（Task） 是 Swarm 中的最小的调度单位，目前来说就是一个单一的容器； 服务（Services） 是指一组任务的集合，服务定义了任务的属性。服务有两种模式：

两种模式通过 docker service create 的 --mode 参数指定。来自 Docker 官网的这张图片形象的展示了容器、任务、服务的关系。

我们这里利用上一节的 docker machine 来充当集群的主机，首先先创建一个 manager 节点，然后在该节点上执行初始化集群命令：

执行 docker swarm init 命令的节点自动成为管理节点。

管理节点初始化完成后，然后同样的用 docker-machine 创建工作节点，然后将其加入到管理节点之中去即可：

我们可以看到上面的提示信息： This node joined a swarm as a worker. ，表明节点已经加入到 swarm 集群之中了。

经过上边的两步，我们已经拥有了一个最小的 Swarm 集群，包含一个管理节点和两个工作节点。

管理节点使用 docker node ls 查看集群:

使用 docker service logs 来查看某个服务的日志。

使用 docker service rm 来从 Swarm 集群移除某个服务:

正如之前使用 docker-compose.yml 来一次配置、启动多个容器，在 Swarm 集群中也可以使用 compose 文件（docker-compose.yml）来配置、启动多个服务。

上一节中，我们使用 docker service create 一次只能部署一个服务，使用 docker-compose.yml 我们可以一次启动多个关联的服务。

我们以在 Swarm 集群中部署 WordPress 为例进行说明：（docker-compose.yml）

其中 constraints: [node.role == manager] 是调度策略，文档地址：

在 Swarm 集群管理节点新建该文件，其中的 visualizer 服务提供一个可视化页面，我们可以从浏览器中很直观的查看集群中各个服务的运行节点。

在 Swarm 集群中使用 docker-compose.yml 我们用 docker stack 命令，下面我们对该命令进行详细讲解。

部署服务使用 docker stack deploy ，其中 -c 参数指定 compose 文件名。

要移除服务，使用 docker stack down :

该命令不会移除服务所使用的 数据卷 ，如果你想移除数据卷请使用 docker volume rm 。

使用docker-compose.yml在swarm中部署应用

一.首先docker-compose.yml的版本必须在version3之上有的必须在3.4之上

二.为支持在swarm上部署应用，docker-compose.yml语法新增的功能模块是deploy。

A.新增模块名称：deploy模块：

B.新增模块参数为：

[1] endpoint_mode:? vip? /dnsrr

vip: Docker为服务分配了一个虚拟IP（VIP），该虚拟IP充当客户端访问网络上服务的前端。Docker在客户端和服务的可用工作节点之间路由请求，而无需客户端知道有多少节点正在参与服务或其IP地址或端口。（ 这是默认设置 ）

dnsrr:DNS轮询（DNSRR）服务发现不使用单个虚拟IP。Docker设置服务的DNS条目，以便对服务名称的DNS查询返回IP地址列表，并且客户端直接连接到其中之一。在想要使用自己的负载平衡器或混合Windows和Linux应用程序的情况下，DNS轮询很有用

[2] labels： 指定服务标签。这些标签 仅 在服务上设置， 而不 在服务的任何容器上设置

[3] mode: global/replicated

global:? 不能使用scale扩展应用，只能被部署到指定的docker上

replicated:可以上用scale扩展，默认情况

[4]placement:指定约束和首选项的位置

[5]replicas:?请指定在任何给定时间应运行的容器数。

[6]resources:??配置资源约束

[7]restart_policy:配置是否以及如何在退出容器时重新启动容器

condition：其一none，on-failure或者any（默认值：any）。

delay：重新启动尝试之间等待的 时间 ,指定为 持续时间 (默认值:0)。

max_attempts：放弃之前尝试重新启动容器的次数（默认值：永不放弃）。如果重新启动未在configure内成功完成?window，则此尝试不会计入配置max_attempts值。例如，如果max_attempts设置为“ 2”，并且第一次尝试重启失败，则可能会尝试两次以上重启。

window：决定重新启动是否成功之前要等待的 时间 ，指定为 持续时间 （默认值：立即决定）。

[8]update_config:配置应如何更新服务。对于配置滚动更新很有用

parallelism：一次更新的容器数。

delay：在更新一组容器之间等待的时间。

failure_action：如果更新失败，该怎么办。其中一个continue，rollback或者pause?（默认：pause）。

monitor：更新每个任务以监视失败后的持续时间(ns|us|ms|s|m|h)（默认为0s）。

max_failure_ratio：更新期间可以容忍的故障率。

order：更新期间的操作顺序。其中一个stop-first（旧任务，开始新的一个前停止），或者start-first（新的任务首先启动，并且正在运行的任务简单重叠）（默认stop-first） 注 ：仅支持V3.4及更高版本。

三.docker-compose.yml 详细内容：

此次部署的是wordpress-mysql的服务：

重点关注deploy的参数说明 。

注意image不能使用build参数 。

四.在swarm中使用docker-compose.yml需要使用的命令是

docker stack ----- docker的版本必须高于1.25

1)创建服务：

docker stack deploy 服务名称 --compose-file=docker-compose.yml

2)查看stack中的任务：

3）查看服务：

4）?列表stack

5)移除一个或多个stack

六.可视化容器：

docker swarm网络问题

docker主机内部网络正常，与其它主机的连接失效，其它主机不能连接docker主机上映射的端口，docker内部也无法连接外部主机。

添加配置

执行 sysctl -p 生效

再次查看docker info，警告消失，主机上的docker网络恢复正常。

我所使用的服务器是阿里云服务器

如果你的集群使用的默认端口4789，那么你可能遇到跟我一样的问题。

阿里云的帮助文档中有这样一句话：

在19.03及之后的版本，docker在swarm init之上增加了–data-path-port uint32 的配置项用于更改docker swarm的VXLAN端口。

修改端口之后成功解决问题

查看docker日志（journalctl -u docker -n 20 -f ）发现 ：

出现这个原因是因为宿主机没有加载ip_vs模块。在各个节点加载ip_vs模块后重启docker即可。

【swarm】Docker swarm 的负载均衡

Docker Swarm 的负载均衡分为两种：

Swarm集群内的service之间的相互访问需要做负载均衡，称为内部负载均衡（Internal LB）

从Swarm集群外部访问服务的公开端口，也需要做负载均衡，称外部部负载均衡(Exteral LB or Ingress LB)

内部负载均衡就是服务发现，集群内部通过DNS访问service时，Swarm默认通过VIP（virtual IP）、iptables、IPVS转发到某个容器。

当在docker swarm集群模式下创建一个服务时，会自动在服务所属的网络上给服务额外的分配一个虚拟IP，当解析服务名字时就会返回这个虚拟IP，对虚拟IP的请求会通过overlay网络自动的负载到这个服务所有的健康任务上。

这个方式也避免了客户端的负载均衡，因为只有单独的一个IP会返回到客户端，docker会处理虚拟IP到具体任务的路由，并把请求平均的分配给所有的健康任务。

swarm中服务还有另外一种负载均衡技术可选DNS round robin (DNS RR) （在创建服务时通过–endpoint-mode配置项指定），在DNSRR模式下，docker不再为服务创建VIP，docker DNS服务直接利用轮询的策略把服务名称直接解析成一个容器的IP地址。

Exteral LB 又可以称为Ingress LB 或者 Swarm Mode Routing Mesh。

看名字就知道，这个负载均衡方式和提到的Ingress网络有关。

Swarm网络要提供对外访问的服务就需要打开公开端口，并映射到宿主机。

Ingress LB就是外部通过公开端口访问集群时做的负载均衡。

当创建或更新一个服务时，你可以利用–publish选项把一个服务暴露到外部，在docker swarm模式下发布一个端口意味着在集群中的所有节点都会监听这个端口，这时当访问一个监听了端口但是并没有对应服务运行在其上的节点会发生什么呢？?

接下来就该我们的路由网格（routing mesh）出场了，路由网格是docker1.12引入的一个新特性，它结合了IPVS和iptables创建了一个强大的集群范围的L4层负载均衡，它使所有节点接收服务暴露端口的请求成为可能。

当任意节点接收到针对某个服务暴露的TCP/UDP端口的请求时，这个节点会利用预先定义过的Ingress overlay网络，把请求转发给服务对应的虚拟IP。

ingress网络和其他的overlay网络一样，只是它的目的是为了转换来自客户端到集群的请求，它也是利用我们前一小节介绍过的基于VIP的负载均衡技术。

启动服务后，你可以为应用程序创建外部DNS记录，并将其映射到任何或所有Docker swarm节点。你无需担心你的容器具体运行在那个节点上，因为有了路由网这个特性后，你的集群看起来就像是单独的一个节点一样。

上面这个图表明了路由网是怎么工作的：

1. 服务（app）拥有两份复制，并把端口映射到外部端口的8000

2. 路由网在集群中的所有节点上都暴露出8000

3. 外部对服务app的请求可以是任意节点，在本例子中外部的负载均衡器将请求转发到了没有app服务的主机上

4. docker swarm的IPVS利用ingress overlay网路将请求重新转发到运行着app服务的节点的容器中

Docker Swarm管理节点高可用分析

Docker Swarm服务调度分析

Docker Reference Architecture: Universal Control Plane Service Discovery and Load Balancing for Swarm

?

docker里面swarm是什么？

Swarm 实现分布式数据存储的概念早在 2015 年初就提出来了。由以太坊创始人 Vitalik Buterin，Gavin Wood 和 Jeffrey Wilcke 推动，Swarm 的协议标签 bzz 和 shh 都是 Vitalik 创造的。所以 Swarm 可以说是以太坊项目官方的一部分，主要是由以太坊基金会开发，允许矿池存储、带宽和算力资源来支持基于以太坊网络的应用。