你可能需要的关于Docker Swarm的经验分享

内容简介：你可能需要的关于Docker Swarm的经验分享

▼点击下方收听音频

你可能需要的关于Docker Swarm的经验分享 来自百度VR

Docker Swarm

利用 Docker 来开发

﹀

﹀

﹀

Docker让工作更轻松。如需要一个部署安装 MySQL 数据库，或者安装Ghost,又或者 Redis 数据库，PostgreSQL，Ruby等。实际上这些都已经被Docker化和镜像化。

只需要一条命令即可运行：

下载(镜像)—使用完—丢掉，没有其他程序搞乱本地开发环境。

扩展现有的容器十分简单，只要拥有足够的Docker基础知识，就能判定从网上下载的Docker镜像是否是有用的镜像。

Docker是开发人员的利器，添加到开发环境中好处无需多言。

若熟悉Docker,会经常使用Docker-compose一条命令来启动整个开发环境栈。

version: '2'

services:

web:

build: .

command: npm run dev

ports:

- 8080:80

docker-compose up

这是一种极为简便的方法，整个开发环境栈用几行代码描述（ development stack as a code ），并且内置版本控制功能。下面来讲下生产环境。

Docker Swarm

生产环境要求

﹀

﹀

﹀

可用性：必须所有的时间点上，服务都是可用的，尽可能减少宕机时间。

性能：服务器需要处理大量的访客请求，故而性能也很重要。

易于部署和回滚。

收集日志和指标。

负载均衡：如果有某些服务或者服务器失败了，我们期望网站可以正常访问。

Docker作为一个准生产的解决方案，实际上被非常多的人低估了。 约一年前，我选择把PvP Center（https://beta.pvpc.eu/）过程中，因Docker文件系统问题，也经历了一些失败（目前，使用Overlay2文件系统，问题不复存在），现在回头想一下，这是很好的决定。

生产部署是使用原始Docker命令还是 Docker-compose

若遇到这个问题，配置好Ansible自动下载新版本的应用，然后自动部署到容器即可（Ansible配置文件： ）。

接下来查看列表——

• 性能：Docker进程，是正常的内核进程，不会产生显著的资源开销。

• 易于部署：一键部署。因Ansible要检查多个判断条件,不仅仅是判断容器版本，所以需要花费一点时间。

• 回滚:所有的容器镜像都使用不同的标签后，保存在容器仓库中。对数据库迁移做了向后兼容，回滚会很容易。

但以上的做法也会产生问题：

1、不能满足一些非常规要求（在要求部署应用的时候服务器零宕机）因为要维护后端动态的负载均衡节点，不能轻易的扩容到多台服务器上。

2、需要极聪明的手段和方法才能整合持续集成/持续部署系统（CI/CD）。

3、如果分别存放特定应用程序，满足部署依赖在不同的架构仓库内 。当配置文件发生变化时，回滚变得非常困难。

坚持了这种做法一段时间，没有任何问题，但是总感觉缺失了什么东西，因为快速部署以及配置文件需要太多修改， Ansible部署也刺激到了我（太慢了）。但是，真正促使 往Docker Swarm迁移的决定性原因是——扩容到一台服务器以的特性 。 虽然可以使用相同的方式部署应用到云端，使用外部负载均衡器，但动态添加或者减少负载均衡节点依旧是痛点。把特定应用的配置文件从Ansible中移除，转而把这些配置文件发到应用仓库中。

Docker Swarm

Docker Swarm

﹀

﹀

﹀

Docker Swarm设计的目的是方便地使用Docker命令来管理多台服务器之间的容器调度，是相当前沿的新功能新特性（从Docker 1.12版本开始）。

要点 ：要点：允许同时连接到多台运行Docker的服务器上。

比较简单 ：对比Kubernetes，Docker Swarm上手更快。

高可用 –集群中有两种不同类型的节点： Master节点和Worker节点。

其中的一个Master节点是Leader,如果当前Leader宕机不可用，其他健康的Master中的一台会自动成为Leader 。如果Worker节点宕机不可用，宕机节点上的容器实例会被重新调度到其他健康的Worker节点上。

声明式配置 ：只需明确发布什么应用以及多少份实例副本，调度系统会自动调度发布这些应用实例，并且遵循指定的限制条件等。

滚动更新 ：Swarm保存了发布容器时候的配置。若更新了配置文件，容器也会批量更新，所以服务会是一直是可用的。

内置服务发现和负载均衡 ：与Docker-compose实现的负载均衡类似。可以通过参考服务名，容器跑在哪里哪台服务器上已经完全不重要，这些负载均衡节点都会接收前端导过来的流量，默认是轮询策略。

Overlay网络 ：如果容器暴露了一个服务端口，这个服务端口在集群内都可以被访问。这对使用外部负载均衡器帮助巨大。

在什么时候才应该考虑使用Docker Swarm

在考虑使用Docker Swarm前，先过一遍下面5个问题——

• 应用是否需要扩容到两台以上的服务器上？多台服务器总是比单台服务器复杂，或者只是想购买更高配置的单台服务器（译者注:纵向扩展）？

• 应用是否有高可用的要求？

• 应用容器化后是否真的是无状态化的？在Swarm下跑容器不应该使用存储卷，虽然理论上是可以使用存储卷，但是在测试使用的时候，它依旧不是稳定可靠的。可以考虑把多媒体文件移到亚马逊S3上，而把数据库运行在Docker Swarm之外。

• 是否需要集中日志系统，例如ELK (这个适用于所有分布式系统)。

• 是否需要已经存在于其他更成熟解决方案（如Kubernetes）中的高级功能和特性?谨记，熟悉Kubernetes比熟悉Docker Swarm要难得多。

生产环境使用Docker Swarm经验

截止目前，应用跑在Swarm上面已经有六个月的时间，从Docker-compose迁移到Swarm花去一周的时间（包括学习如何迁移等）。需要调整配置文件，以便让应用容器完全是无状态的，使用外部集中式日志和指标收集。高峰时，共运行了35个节点。对集群的管理十分方便。

例如：

docker service scale name_of_service=30 or docker service update --env-add SECRET_ENV=youdontneedtoknowit name_of_service

截屏如下：

部署流程如下图：

在Deploy区域内，使用最新Docker-compose v3版的语法和Docker stack deploy命令。把发布应用容器的配置文件存储为VCS这项工作变得前所未有的简单。无需要手工修改任何配置，轻松地部署应用容器到Swarm集群。

配置文件例子：

v ersion: '3'

services :

web :

image : registry.gitlab.com/example/example # you need to use external image

command : npm run prod

ports :

- 80:80

deploy :

replicas : 6

update_config :

parallelism : 2

delay : 10s

restart_policy :

整个部署命令只有一行： dockerstack deploy application .当然，这里使用了Gitlab.com的流程，结果如下图所示：

可以在Web界面上进行回滚操作，甚至在手机上执行回滚操作。

Docker Swarm

结语

﹀

﹀

﹀

以上都是个人对Docker Swarm的观点。之前考虑过使用其他选项，如果想让应用容器化，进而伸缩扩容到多台服务器上，目前这种方法是最好的选择。

原文作者：Jakub Skałecki

以上所述就是小编给大家介绍的《你可能需要的关于Docker Swarm的经验分享》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！

查看所有标签

猜你喜欢:

• 你可能需要 SPI 了
• 你很可能需要知道这个调试小技巧
• 【译】你可能不需要Moment.js
• (译)你可能不需要Redux：Flutter版
• 为什么你可能不需要无服务器
• 企业需要意识到公共云可能出现安全漏洞

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。