资讯专栏INFORMATION COLUMN

关于Docker Swarm,你可能需要了解更多实践经验

bitkylin / 3280人阅读

摘要:虽然可以使用相同的方式部署应用到云端,使用外部负载均衡器,但动态添加或者减少负载均衡节点依旧是痛点。这对使用外部负载均衡器帮助巨大。

数人云今天带来的本篇文章将分享Docker在应用程序生命周期每个阶段中所扮演的角色,以及迁移到Swarm集群时需要考虑的问题。

利用Docker来开发

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

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

docker run name_of_programe_you_need

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

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

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

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

例如,很常见的Docker-compose文件是这样:

version: "2"  
services:  
  web:
    build: .
    command: npm run dev
    ports: 
      - 8080:80

  redis:
    image: redis

  database:
    image: postgres

然后运行:

docker-compose up # --build if you want to rebuild

PostgreSQL访问地址:postgresql://database

Redis访问地址: http://redis

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

生产环境要求

生产环境非同一般。这里例举中等负载量的服务器要求——

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

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

易于部署和回滚。

收集日志和指标。

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

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

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

若遇到这个问题,配置好Ansible自动下载新版本的应用,然后自动部署到容器即可(Ansible配置文件:https://rock-it.pl/managing-m... )。
接下来查看列表——

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

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

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

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

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

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

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

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

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集群。

配置文件例子:

version: "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:
        condition: on-failure

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

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

结语

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

原文作者:Jakub Skałecki
原文链接: https://rock-it.pl/my-experie...

欢迎关注数人云微信公众号,如有后续文章,我们会在第一时间进行跟进

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/26903.html

相关文章

  • 生产环境中使用Docker Swarm的一些建议

    摘要:译者按实践中会发现,生产环境中使用单个节点是远远不够的,搭建集群势在必行。集群的网络通信服务发现,负载均衡以及容器间通信非常可靠。负载均衡也是由提供的。 译者按: 实践中会发现,生产环境中使用单个Docker节点是远远不够的,搭建Docker集群势在必行。然而,面对Kubernetes, Mesos以及Swarm等众多容器集群系统,我们该如何选择呢?它们之中,Swarm是Docker原...

    loonggg 评论0 收藏0
  • 老肖有话说:如期而至的Swarm新工具Crane开源解读

    摘要:更多技术栈的包容数人云技术团队为了帮助广大技术爱好者对新版本有快速直观的感受,制作了一款基于最新特性的容器管理工具,具备一定容器开发经验的开发者可以通过它在第一时间体验的新特性。可以说,数人云是在技术能否持续下去的争论中发布的工具。 showImg(https://segmentfault.com/img/bVD5g2?w=900&h=500);中秋节前, 数人云技术团队推出了一...

    andot 评论0 收藏0
  • 数人云容器管理工具 Crane 现已开源

    摘要:指导员明伯伯数人云工程师手记相关阅读基于的集群管理开发实践服务发现,负载均衡和 这是一个容器信息臃肿的时代。 Docker 鲸鱼鼓着圆圆的肚子在西雅图开了一场名为 DockerCon2016 的大会,全球 4000 人参加, 8 大看点留下对容器生态的更多畅想。 数人云一直专注于以企业级的 Mesos +容器技术栈,出于对容器新技术的热爱,我们在社区版的工具上小试牛刀,距 Docker...

    NeverSayNever 评论0 收藏0
  • Docker Swarm在生产环境中的进阶指南

    摘要:应该如何解决本文将给出若干提示,如何在生产环境中使用。路由匹配服务发现负载均衡跨容器通讯非常可靠。在单个端口上运行一个服务,节点的任意主机都可以访问,负载均衡完全在后台实现。 上周数人云给大家分享了——《你可能需要的关于Docker Swarm的经验分享》今天给大家带来这位作者大大的后续文章——《Docker Swarm在生产环境中的进阶指南》 当在本地开发环境中使用Docker,或者...

    galaxy_robot 评论0 收藏0
  • Docker Swarm集群初探

    摘要:既然要组集群那就涉及诸如的资源调度管理等等一系列问题。目前涉及集群的三个主要的技术无外乎三种。从本文开始作者将会一一实践这几种主要的集群技术,话不多说,现在开始。完全运行于内存中,体积小,启动快。 showImg(https://segmentfault.com/img/remote/1460000015723680); 前言 相信Docker技术大家都有所了解,单个Docker能发...

    MingjunYang 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<