Swarm

Swarm

【腾讯云】#容器团队#高级容器研发#招聘

Shirleyee 发表了文章 • 1 个评论 • 217 次浏览 • 2019-05-24 10:33 • 来自相关话题

高级容器研发工程师 工作职责 负责公有云/私有云中 Kubernetes/Devops 等产品技术方案设计与研发工作;负责 Kubernetes 相关前沿技术规划和调研工作,从技术上保证产品的竞争力;负责与产品及客户沟通,判定需求的合理 ...查看全部
高级容器研发工程师
工作职责
  1. 负责公有云/私有云中 Kubernetes/Devops 等产品技术方案设计与研发工作;
  2. 负责 Kubernetes 相关前沿技术规划和调研工作,从技术上保证产品的竞争力;
  3. 负责与产品及客户沟通,判定需求的合理性,找出最合适的方式解决客户问题。
工作要求
  1. 3 年以上后端开发经验,Coding、Debug 能力强, 有丰富的架构设计经验;
  2. 熟悉 C/C++/Go/Java/Python/Ruby 等至少二种编程语言;
  3. 熟悉 Docker/Kubernetes/Swarm/Mesos 等技术;
  4. 熟悉 Jenkins/ELK/Prometheus 等技术优先;
  5. 熟悉 AWS/Google Cloud 等云计算厂商产品优先。


有意请戳:
Wechat:13723737494
Email:Shirleyeee@foxmail.com

房多多容器化和容器云实践

阿娇 发表了文章 • 0 个评论 • 745 次浏览 • 2019-04-25 22:56 • 来自相关话题

#背景和意义 房多多是国内首家移动互联网房产交易平台。作为迅速崛起的行业新生力量,房多多通过移动互联网工具,为开发商、经纪公司、买房卖房者搭建了一个高效的、可信赖的O2O房产交易平台。 房地产行业的复杂性和业务创新环 ...查看全部
#背景和意义

房多多是国内首家移动互联网房产交易平台。作为迅速崛起的行业新生力量,房多多通过移动互联网工具,为开发商、经纪公司、买房卖房者搭建了一个高效的、可信赖的O2O房产交易平台。

房地产行业的复杂性和业务创新环境注定了房多多的产品特点是不断持续创新和持续高速迭代的,在不断探索业务的可能性的过程中,提高持续快速交付价值的能力和创新能力是必不可少的。

软件行业没有所谓的“银弹”,房多多在业务解耦微服务化以后,服务指数型的增长带来了许多运维方面的困扰。

在我们内部比较突出的矛盾有:

* 虚拟机的资源依靠维护文档人肉调度,机器调度效率低。
* 维护测试、预发布、生产等环境的成本高。
* 某个业务的稳定太依赖某台物理机的稳定性,且难以快速扩容。
* 业务需求变化快导致雪花服务器增多,难以维护;
* CI/CD脚本复杂,新的需求难以快速交付。

在2018年房多多技术团队开始了服务容器化和容器云的建设,调研后选择了 Swarm 作为了容器集群。

可能很多人看到这儿就会关掉,"都9012年了还有人用Swarm?"

虽然在Swarm在和Kubernetes的竞争中已处于下风,但是Swarm的灵活性、性能和易用性促进了我们的容器化推进,且在我们落地过程中没有出现过系统级的bug和线上故障,目前已经在生产环境支撑数百个服务的运行,每日300次左右的变更。

容器和调度编排系统的引入给难以运维的微服务架构带来了质的改变,但是服务容器化和容器云在推进过程中也踩过不少坑和积累了一些经验,希望给大家带来启发。
#选型

在容器集群的选择上,Kubernetes事实上已成为容器届编排的标准,但是为什么我们选择了小众的 Docker Swarm呢?

房多多的生产环境硬件基础设施基本都在IDC机房,物理机器数量大概有几百台,实际可以供业务迭代用的机器大概在一半左右,且没有很多空闲机器可供使用、新建容器云的机器需要腾挪现有业务。

根据上述的自身的情况,我们做容器平台调研时,主要从以下三点考虑:

* 性能:用户可以在多短的时间内启动并大规模运行容器?系统在大负载情况下响应速度如何?
* 易用性:起步时的学习曲线是什么?维持运转是否复杂?系统中有多少不定项?
* 灵活性:是否可以和我当前的环境和工作流相整合?应用从开发到测试再到生产,是否可以无缝衔接?会不会被限制在某个平台上?

从性能看:房多多是自建机房,每一台物理机的利用率是比较高的。在我们测试调研过程中发现,Swarm通常可以在一秒内启动一台容器,调度效率和容器启动速度其实比Kubernetes快很多。如下图(50%负载下,1000节点 启动每一个容器的平均时间):
1.jpg

从灵活性来看:Swarm的API比较简单,可以很快的和现有的DevOps流程打通。且因为Swarm相当于Kubernetes的子集,如果后面机器规模继续扩展,业务有大量编排需求,我们可以花不多的时间就可以迁移到Kubernetes上。其实只要我们的服务容器化了,后续更换什么容器集群其实问题都不大。

从易用性来看:API使用简单,资源抽象简单,可以快速启动上手。我们使用Swarm比较多的功能其实是调度功能,编排功能暂时没有大规模使用。Swarm的结构比较简单,在最新的版本中内置分布式k-v数据库代替了etcd,内置DNS用来服务发现。在规模中等情况下,几乎没有基础设施运维负担。
#容器云架构

Swarm的实现和Kubernetes相似,最近的版本也在慢慢模仿Kubernetes的思想。

想了解如何搭建集群的操作可以查阅 Swarm 官网的文档。

因为Manager节点只负责调度集群的Task,配置要求不高,所以我们用虚拟化Xenserver虚拟了3台低配置机器(在不同的物理机上)作为Manager节点,根据Raft算法,3台可以容许1台机器出问题,5台可以允许2台机器出问题,大家可以按需求部署。Worker节点的作用是运行业务容器,我们选择了直接用物理机来部署已达到最好的性能和资源利用。同时,在Manager和Worker节点上,会以容器方式部署机器监控和日志收集,上面还需要运行网络和存储插件。

都加入到集群之后,Swarm会提供网络管理、负载均衡、基于DNS容器发现、集群状态管理、扩容缩容等功能,我们在DevOps流程层面,可以组合成发布、回滚应用、查看服务的状态、日志、终端,更改发布配置(例如环境变量、默认副本数等)等功能。这个层面我们引入了Portainer这个开源项目,提供了更好用集群管理的UI界面和类似Kubernetes Apiserver设计的Docker集群API接口服务。
2.jpg

Docker Swarm的资源抽象比较简单,在没有容器编排的情况下,我们主要使用Services,这个和Kubernetes上的Services有些不一样,可以理解为Services和Deployment的合体,用来管理和定义容器的调度和扩容等,也可以直接做端口映射,在容器集群里任意IP都可以访问。

下图可以比较简单的描述我们是怎么把服务让外部和内部调用的:
3.jpg

外部调用我们目前是通过Nginx做反向代理到集群的节点,因为Ingress的特性我们可以转发到任何一台Worker或者Manager节点上,然后通过内置的routing mesh的Load Balancer通过LVS转发请求到Service的其中一个副本,一个值得注意的点是,就算这台Node上没有运行这个Service的容器Load Balancer也会找到其他机器上存在的副本,这个主要是通过 内置的DNS加LVS转发实现。

内部调用我们是走我们的Envoy Mesh网关,通过自研的xds-service来自动发现加路由,本质是走容器之间互通的Overlay网络或者Macvlan网络。
#网络

网络我们主要解决两个问题:

  1. 容器间互相通信,容器直接互相调用打通,并且可以作为基础的容器网卡,以支持容器集群的routing mesh功能。
  2. 容器和外部网络互相通信,类似使用了Dubbo服务容器化,在虚拟机和容器并存的迁移过程中,必须要让容器和外部网络互通,不然会导致在容器集群外部的虚拟机调用不通容器。虽然也可以通过其他方法实现,但是打通容器和外部网络互相通信是较可行也是稳定的一种方法。

下图是我们主要的容器网络架构。
4.jpg

容器间互通的解决方案是我们在容器集群中创建Overlay网络,并将网络附加到容器容器上,容器中就有了名为Overlay的网卡(图中的 eth0),每个容器的eth0都会经过宿主机的docker0网卡和eth0与别的宿主机的网络进行交互。

容器与外部网络互通的解决方案是Macvlan。其工作原理是通过为物理网卡创建Macvlan子接口,允许一块物理网卡拥有多个独立的MAC地址和IP地址。虚拟出来的子接口将直接暴露在底层物理网络中。从外界看来,就像是把网线分成多股,分别接到了不同的主机上一样,这样也可以拥有近似物理机直连的性能。

公有云一般会限制Macvlan,不一定可以实施。因为我们是自建机房,所以没有这方面的限制,只要让网络工程师在交换机上配置好网段,我们就可以在此网段下分配容器的IP了。

具体使用方法是,在容器Worker节点创建一个config-only的Network,写划分的网段和网关,例子:
docker network create --config-only --subnet=10.0.127.0/20 --gateway=10.0.112.1 --ip-range=10.0.112.0/25 -o parent=bond0 pub_net_config
# bond0 为指定的依附的物理机网卡

然后在Manager节点创建Network,例子:
docker network create -d macvlan --scope swarm --config-from pub_net_config pub_net

然后只需要把网络附加到Service上即可:
docker service update m-web --network-add pub_net

#容器化

容器化首先是要把业务代码build成镜像,我们内部的技术栈主要以Node和Java为主。

我们容器化迁移是先从Node服务开始,因为Node服务普遍比较新且项目都按照规范创建,没有很多历史债务且基本都是无状态的,这样我们就可以写出一个比较通用的Dockerfile让开发在迭代需求是时候顺便加上,基本只需要改一下暴露的端口号和监控检查URL就可以完成容器化。

Java的构建工具主要以Maven和Gradle为主,我们使用了Google开源的Jib 工具来把构建Docker镜像并上传的工作集成到Maven和Gradle中,实际操作只需要改一下pom文件或者build.gradle,加入Jib Plugins就可以了。

实际推广过程中,如果是还在迭代的项目,因为操作简单且容易理解,业务开发还是比较容易推动的。如果是历史项目且还运行在线上,可以让业务运维帮忙逐个操作,然后重新发布,测试,上线。
#优化和Tips

##镜像大小优化

镜像大小是容器化很重要的一个问题。镜像越小,容器发布和调度就越快,宿主机磁盘用量也不会过大。

除了大家常用的镜像优化手段比如减少层级等,我们优化基础镜像baseimage使用了alpine 3.9版本,并对使用到的基础库做了选择,比如使用最新的musl 1.1.21等,最终基础镜像控制42M,最终降低80%镜像大小到300M以内。
##信号量优化

当容器的启动脚本是一个Shell脚本时,因为Shell不响应退出信号的特性,会导致容器无法正常退出,只能等超时后自动杀死进程,这样在我们的实践中会导致物理机上有很多僵尸进程。所以我们的解决方案是消除进程树中的Shell进程,我们改用了一个tini这个来作为主进程,在基础镜像中添加ENTRYPOINT ["/tini", "—"]即可,虽然不等子进程返回的方式可能不太优雅,但是可以快速stop容器带来的灵活性足以弥补这个缺点,当然特殊应用可以特殊处理。
##Java容器化问题

Java容器化的坑比较多,JDK我们使用了 OpenJDK 8(version "1.8.0_191"),JVM opts我们加上了-XX:+UseContainerSupport -XX:MaxRAMPercentage=75.00,这个版本Java已经可以获取到正确的CPU资源和内存资源,默认使用75%的Cgroup空间为heap memory,留25%空间给stack memory。防止因为heap memory加stack memory太大导致容器内存使用超出Cgroup限制被Kill掉。

除此之外,我们还优化了随机数生成的原理:
echo "securerandom.source=file:/dev/urandom" >> /usr/lib/jvm/default-jvm/jre/lib/security/java.security

##DNS Performance(Lookup Failed)

两方面原因:

一方面,Docker自身的DNS允许并发数太低,已经提issue并修复了:docker Increase max concurrent requests for DNS from 100 to 1024。

另一方面,musl的代码在DNS解析的实现上有些问题,如果有IPv6的A记录那么解析性能不会出现问题,如果只有AAAA的IPv4记录,那么解析可能会出现卡死的情况,等待2.5s才返回,所以要添加一个break代码防止出现等待,在最新的musl的版本解决了(没有发布,需要自行编译)。
5.jpg

最后,这个问题其实是因为业务服务大多数是使用HTTP/1.x导致产生多条TCP连接造成的,现在房多多已经全站使用HTTP 2多路复用长连接,这个瓶颈其实也就不存在了。
##流量突然增高Slab分配失败导致机器负载高

容器平台集群不定期的报slab memory malloc的错误。

系统负载高时,服务器内核大量报Slab cache错误,升级CentOS 7.5新内核862解决。值得一提的是,在容器时代,大家对内核的要求越来越高也越来越依赖内核的功能,很多公司其实都走在了内核迭代的前列,发现了很多bug并对社区做出了贡献。
##物理机配置问题导致容器网络不通

我们有出现过一次交付物理机Restart Network后没有开启ipv4_forward导致的改物理机上的容器Overlay网络挂的问题。

我们的解决方法是在启动容器前通过ping网关的方式检查DNS服务和网络是否打通。
#发布系统改造

##构建流程自定义

在容器化的过程中,我们也把构建流程做了优化,引入了Jenkins Pipeline功能。Pipeline对于我们的最重要的好处是可以把构建流程DSL代码化,并可以针对每一个项目自定义构建流程,当然我们有提供一个大体的框架,用户只需要更改自己所需要的就可以了,如下图:
6.jpg

7.jpg

最终会生成一个Jenkinsfile并在每次构建的时候都回去调用项目对应的Jenkinsfile。有了这样的功能,开发就可以根据自己的需求,轻松的更改自己项目的构建流程。
##Web Terminal

我们根据业务开发的需求开发了Web进入Docker容器的功能。原理是转发docker exec命令到对应的物理机上,并转发输入输出。支持快捷键和高亮,体验良好。
8.jpg

##Log

日志我们通过在转发docker logs请求获取最新的2000条(默认,可配置)日志打印到Web页面上,支持自动刷新和滚动。
9.jpg

#日志收集

我们会把项目输出的日志通过Volume都挂载到每台宿主机的固定目录下,并用global模式部署filebeat进行采集,输出到我们的Elastic集群上,然后在ELK平台上查询日志。最近我们也在测试环境尝试Grafana Loki 项目,他和Elastic的原理相反,只索引必要的字段,可以节省大量的机器资源,如果是用来做"distribute grep"的话就很合适。
10.jpg

#监控

监控我们使用了Swarmprom开源项目,监控项比较丰富,覆盖了机器基础指标,容器指标,可以较快的定位问题,当时当容器集群出现宕机等情况时,监控会暂时失效,所以我们在容器集群外也部署了针对机器的基础监控。具体效果如下:
11.jpg

12.jpg

#推广

容器的推广需要业务开发和业务运维的支持,不然很难推动。

推广首先要让开发和运维感受到红利:

* 容器相对于虚拟机更轻量化,可以实现秒级启动。
* 测试、预发布、线上的容器部署配置、环境 完全一致。
* 可以根据 CPU、内存或者QPS和延时快速扩容,提升服务能力。
* 服务crash会自动启动,自带高可用。

这四个特性的组合,可以给业务带来更大的灵活度和更低的计算成本。

我们团队是把这个容器平台当成一个产品来运作,业务开发就是我们的用户。

在推进容器化的过程中,我们还会做如下的事情:

* 通过培训让开发了解我们的产品优势(对比虚拟机)。
* 提供使用文档、接入文档等使得产品的易用度增加。
* 在迁移时给予开发更高优先级的支持。
* 资源尽量都加入容器集群,停止并减少虚拟机的供给。

#总结

从传统的虚拟机架构到现在的基于云原生的容器云架构,带来了秒级部署、秒级扩缩容、简化了CI/CD 流程、提供Service Mesh微服务治理能力。

如果按虚拟机时代运维人肉调度服务,人肉管理资源,在新虚拟机部署一个新应用或者扩容一个应用的时间在10分钟以上,和现在的按秒计算时间是质的变化,这是招再多的业务运维人员也达不到的,无形中省去了很多人力成本。

通过容器云的落地,我们得到了一个面向服务的平台,把机器资源抽象,屏蔽了和发布无关的机器细节、部署细节,开发不用再了解自己的应用在哪一台物理机上面。运维也可以从茫茫多的管理表格中解脱出来,只需要关注集群利用率,添加机器资源即可。这样有利于公司DevOps的推行,提高开发效率和开发个体的创造力不再被运维限制,大大提升团队生产力。

接下来,我们还会根据自身的需求迭代服务治理、容器编排的功能,把管理集群的常规操作平台化,尽量做到日常操作可以不登录物理机去操作。

原文链接:房多多容器化和容器云实践(作者:王开)

Docker Swarm 在持续集成测试中的应用

Andy_Lee 发表了文章 • 0 个评论 • 1124 次浏览 • 2018-10-21 16:10 • 来自相关话题

#背景 敏捷(Agile)模式被广泛应用,测试显得尤为重要。由于需要频繁发布新的版本,我们需要更加频繁的执行测试用例,以确保没有新的 bug 被引入到版本中。 一个完整的测试流程所需要占用的时间和资源也不可忽视,包括 ...查看全部
#背景

敏捷(Agile)模式被广泛应用,测试显得尤为重要。由于需要频繁发布新的版本,我们需要更加频繁的执行测试用例,以确保没有新的 bug 被引入到版本中。

一个完整的测试流程所需要占用的时间和资源也不可忽视,包括对测试结果的分析都要占用大量的资源。如何在更短时间内,提供完整、全面的测试以保证质量,是我们急于解决的问题,也是保证敏捷开发能顺利进行的关键。

Jenkins 实现了无人值守的测试流程,开发结束后,一旦在测试环境部署成功,下游的测试任务就会即刻执行。

Jenkins 的应用在一定程度上节省了人力资源,而 Docker 技术可以实现容器 (Container) 快速的拓展,从而节省了大量的设备资源和时间,快速的完成测试。这在 Jenkins Pipeline(代码流水线管理)中是非常重要的一个环节,如图 1 所示:
1.png

图 1. Jenkins Pipeline

本文主要介绍如何利用 Docker Swarm 集群功能和 Selenium Grid 脚本分发功能,来搭建一个可以动态扩容的 Selenium 自动化脚本执行环境。相比于用真实的机器作为 Selenium 自动化脚本执行环境,使用此套环境可以极大的减少对执行环境的维护工作,比如各种浏览器类型的管理和版本的管理。也能极大的减少对脚本执行环境的物质投入,节省各类资源。
#搭建 Docker Swarm 集群

##Swarm 简介

Swarm 是 Docker 官方提供的一款集群管理工具,用来管理 Docker 集群,它将若干台 Docker 主机抽象为一个整体,并且通过一个入口统一管理这些 Docker 主机上的各种 Docker 资源。

Swarm 只是一个调度器(Scheduler)加路由器(Router),Swarm 自己不运行容器,它只是接受 Docker 客户端发送过来的请求,调度适合的节点来运行容器,这意味着,即使 Swarm 由于某些原因挂掉了,集群中的节点也会照常运行,当 Swarm 重新恢复运行之后,它会收集重建集群信息。

Swarm 和 Kubernetes 比较类似,但是更加轻,具有的功能也较 Kubernetes 更少一些。
##环境准备

为了搭建 Docker Swarm 集群环境,我在示例中准备了两台机器。一台作为 manager 节点,同时也作为一个 worker 节点,另一台只作为一个 worker 节点。

这里假设我们的两个机器 IP 信息如下:

* M1:10.13.181.1
* M2:10.13.181.2

Docker Engine 从 V1.12.0 版本开始,原生集成了 Docker Swarm,所以只要在每台机器上安装 Docker,就可以直接使用 Docker Swarm。在这里,关于 Docker 的安装不再详细介绍,请按照官方 Docker Swarm 文档进行安装。安装完成后,在每台机器上将 Docker 服务启动。

提示:

注意:最好关闭机器上的防火墙,否则可能会出现 Swarm 集群网络连接问题。

关闭防火墙的命令:systemctl stop firewalld.service

禁止防火墙开机启动命令:systemctl disable firewalld.service
##步骤

1、创建管理节点。

我们将机器 M1 作为 manager 节点,在这台机器上执行命令来初始化集群环境。命令如下:
sudo docker swarm init --advertise-addr 10.13.181.1

执行此命令后,会返回一个用于加入集群的令牌(Token),以便其他 worker 加入此集群。

清单 1. 加入集群令牌示例:
docker swarm join --token SWMTKN-1-5p3kzxhsvlqonst5wr02hdo185kcpdajcu9omy4z5dpmlsyrzj-
3phtv1qkfdly2kchzxh0h1xft 10.13.181.1:2377

如果想再次获取加入集群的命令,可以通过执行以下命令获取:
sudo docker swarm join-token worker

2、将机器 M1 也作为 worker 节点添加到集群。

在 manager 节点机器上运行清单 1 的命令,即可将机器 M1 也作为 worker 加入 swarm 集群当中。

3、将另一台机器 M2 作为 worker 节点添加到集群。

在机器 M2 上执行上述清单 1 中的命令,即可实现 M2 加入集群的功能。

4、运行如下命令创建集群网络:
sudo docker network create -d overlay seleniumnet

这里,seleniumnet 即是我们所创建的集群网络名称。

5、在新建的集群网络上创建 Selenium Grid 服务。

a. 创建 Selenium Grid Hub 服务。基于集群网络 seleniumnet,将 4444 端口映射到集群的 4444 端口,将 timeout 时间设置为 120 秒,可以增大或减少 timeout 时间,如清单 2 所示。

清单 2. 创建 Selenium Grid Hub 服务:
sudo docker service create --name selenium-hub --network seleniumnet -p 4444:4444 -e 
GRID_TIMEOUT=120 selenium/hub

b. 创建 Selenium Grid Firefox 节点服务并连接到刚创建 Hub 服务。如清单 3 所示。

清单 3. 创建 Selenium Grid Firefox 节点服务:
sudo docker service create \
--name node-firefox \
--replicas 5 \
-p 7900:5900 \
--network seleniumnet \
-e HUB_PORT_4444_TCP_ADDR=selenium-hub \
-e HUB_PORT_4444_TCP_PORT=4444 \
selenium/node-firefox-debug bash -c 'SE_OPTS="-host $HOSTNAME" /opt/bin/entry_point.sh'

参数说明:

-p: 7900:5900 将 Docker 内部 VNC5900 暴露到宿主机的 7900 端口,使得用户可以通过 VNC 从外面监控 Docker 内部的执行情况。

c. 创建 Selenium Grid Chrome Node 服务并连接到刚创建 Hub 服务。如清单 4 所示。

清单 4. 创建节点服务:
sudo docker service create \
--name node-chrome \
--replicas 3 \
-p 7901:5900 \
--network seleniumnet \
-e HUB_PORT_4444_TCP_ADDR=selenium-hub \
-e HUB_PORT_4444_TCP_PORT=4444 \
selenium/node-chrome-debug bash -c 'SE_OPTS="-host $HOSTNAME"
/opt/bin/entry_point.sh'

参数说明:

-p: 7901:5900 将 Docker 内部 VNC5900 暴露到宿主机的 7901 端口,使得用户可以通过 VNC 从外面监控 Docker 内部的执行情况。

6、检查环境搭建是否成功。在机器 M1 上执行以下命令,查看每个服务是否启动成功:
sudo docker service ls

可以看到 Selenium Hub 和 Firefox 节点、Chrome 节点都已经成功启动。Firefox 的节点副本是 5,Chrome 的节点副本是 3,如图 2 所示。
2.png

图 2. Docker 服务清单

我们再通过任意一台机器的 IP 加 4444 端口来打开 Selenium Hub URL 来查看已启动的 Firefox 和 Chrome 节点是否已经成功挂载到 Hub 节点上,如图 3 所示。

Hub url: 10.13.181.1:4444
image003.png

图 3. Selenium Hub 的界面图

从图 3 可以看出,5 个 Firefox 节点和 3 个 Chrome 节点都已经成功挂载到 Hub 节点上。说明此时 Docker Swarm 环境里已经提供了 5 个 Firefox 节点和 3 个 Chrome 节点可以用来执行 Selenium 自动化测试脚本。
##扩容方法

用户可以根据脚本执行数量,随时动态的扩容各个节点的数量,提高自动化脚本的执行效率,例如我们需要 10 个可以运行 Firefox 浏览器的 Container,对应的命令如下:
sudo docker service scale node-firefox=10

#在 Docker Swarm 运行 Jenkins Job

用户在 Docker Swarm 中运行 Jenkins Job,并不需要在 Jenkins 做多余的配置,而是需要在对应的自动化脚本中调用 Selenium Hub,从而以远程的方式调用 WebDriver。这样就实现了在 Docker Container 中运行 Selenium 脚本。

以本文中的场景为例,只需要在自动化脚本中调用远程 Selenium Hub 即可,如下所示:
http://9.111.139.104:4444/wd/hub

#在 Selenium Grid 中运行自动化脚本

##基本概念

Selenium Grid,用于分布式自动化测试,也就是说一套 Selenium 代码可在不同的环境上运行,这样做可以方便的将应用运行在 Docker 所提供的不同 Container 中。

Selenium Grid 有两个概念:

* Hub:主节点,你可以看作总调度中心。
* Node:分支节点,你可以看作是真正执行任务的 worker。

也就是说在 Selenium Grid 中只能有一个主 Hub,但可以在本地或远程建立 N 多个分支节点,测试脚本指向主 Hub,由主 Hub 分配给本地/远程节点运行测试用例。
##实现方式

要实现在 Selenium Grid 中运行自动化脚本,首先我们要创建一个 remote driver 的对象,可以通过图 4 源码实现,截图中所对应的输入参数 selhub 是 Selenium hub 的 URL:
http://9.111.139.104:4444/wd/hub

image004.png

图 4. 自动化脚本的代码截图

通过调用上述的 driver,就可以实现将自动化脚本运行在 Docker Container 中。
#结束语

在持续集成测试中,将测试部署到 Docker Swarm 中,通过 Selenium Grid 自动分配执行测试的节点,可以提升测试效率,增大测试的范围,在快速迭代中能够更好的保证所交付的产品质量,节省测试资源。

原文链接:https://www.ibm.com/developerworks/cn/devops/d-docker-swarm-ci-test-application/index.html

Swarm真垃圾,各种问题

回复

我活了这小半辈子 发起了问题 • 1 人关注 • 0 个回复 • 1092 次浏览 • 2018-08-08 16:57 • 来自相关话题

容器中的MySQL迁移RDS,会话却“爆了”

尼古拉斯 发表了文章 • 0 个评论 • 2253 次浏览 • 2018-05-03 12:37 • 来自相关话题

Swirl:Docker Swarm 集群管理的新选择

cuigh 发表了文章 • 2 个评论 • 2331 次浏览 • 2018-03-14 12:21 • 来自相关话题

# SWIRL GitHub 地址:https://github.com/cuigh/swirl [Swirl](https://github.com/cuigh/swirl) 是一个 Docker 管理工具 ...查看全部
# SWIRL

GitHub 地址:https://github.com/cuigh/swirl

[Swirl](https://github.com/cuigh/swirl) 是一个 Docker 管理工具,专注于 Swarm 集群。

主要功能

* Swarm 各组件管理,包括服务、网络、任务等
* 镜像与容器管理
* Compose 管理与部署
* 服务状态监控(基于 Prometheus)
* 服务自动伸缩
* 支持 LDAP 认证
* 基于 RBAC 完整的权限控制模型
* 支持横向扩展部署
* 多语言支持
* 更多功能...

Snapshots

# 首页



# 服务列表



# 服务监控



# 服务编排管理



# 系统设置



配置

# 使用配置文件

所有选项都可以通过 `config/app.yml` 配置文件来设置。

```yaml
name: swirl
banner: false

web:
address: ':8001'
authorize: '?'

swirl:
db_type: mongo
db_address: localhost:27017/swirl
# docker_endpoint: tcp://docker-proxy:2375

log:
loggers:
- level: info
writers: console
writers:
- name: console
type: console
layout: '[{L}]{T}: {M}{N}'
```

# 使用环境变量

3 个主要的设置支持通过环境变量来设置,便于以 Docker 方式部署。

| Name | Value |
| --------------- | ------------------------------------------------|
| DB_TYPE | mongo |
| DB_ADDRESS | localhost:27017/swirl |
| DOCKER_ENDPOINT | tcp://docker-proxy:2375 |

# 使用 Swarm 的 Config 功能

Docker 从 v17.06 版本起,内置了配置管理模块,服务可以直接挂载存储在集群中的配置文件,因此你也可以通过这种方式来挂载 Swirl 的配置文件。

部署

# 独立部署

编译后把 swirl 执行文件和 config/assets/views 这 3 个目录复制到服务器任意目录中,直接运行即可。

```bash
./swirl
```

# Docker 方式

```bash
docker run -d -p 8001:8001 \
--mount type=bind,src=/var/run/docker.sock,dst=/var/run/docker.sock \
-e DB_TYPE=mongo \
-e DB_ADDRESS=localhost:27017/swirl \
--name=swirl \
cuigh/swirl
```

# Docker Swarm 方式

```bash
docker service create \
--name=swirl \
--publish=8001:8001/tcp \
--env DB_ADDRESS=localhost:27017/swirl \
--constraint=node.role==manager \
--mount=type=bind,src=/var/run/docker.sock,dst=/var/run/docker.sock \
cuigh/swirl
```

# Docker Compose 方式

Swirl 项目中已经包含了一个简单的 Compose 部署文件,你可以使用 Docker 的 stack 命令直接部署

```bash
docker stack deploy -c compose.yml swirl
```

高级特性

Swirl 使用服务标签来实现一些高级的管理功能,下表中的标签是目前已经支持的。

名称 | 描述 | 示例
--- | --- | ---
swirl.scale | 用于控制服务自动伸缩 | `swirl.scale=min=1,max=5,cpu=30:50`

从源码构建

Swirl 使用 `dep` 作为依赖管理工具,下载源代码后,你可以使用如下两行简单的命令来构建。

```sh
$ dep ensure
$ go build
```

许可证

This product is licensed to you under the MIT License. You may not use this product except in compliance with the License. See LICENSE and NOTICE for more information.

Swarm中容器的负载均衡

anoyi 回复了问题 • 2 人关注 • 1 个回复 • 2845 次浏览 • 2018-02-04 09:40 • 来自相关话题

新特性初探:Docker for Mac喜迎Kubernetes支持能力

hokingyang 发表了文章 • 0 个评论 • 9709 次浏览 • 2018-01-10 10:01 • 来自相关话题

【编者的话】很高兴内置支持Docker Swarm和Kubernetes的Mac版Docker发布了,本文将会回顾一下此工具简史,然后看看新功能的第一印象。 #为什么对开发者很重要? ...查看全部
【编者的话】很高兴内置支持Docker Swarm和Kubernetes的Mac版Docker发布了,本文将会回顾一下此工具简史,然后看看新功能的第一印象。
1.png

#为什么对开发者很重要?
Docker CE(简称Docker)是一款易用简便的容器工具,是给用户带来自主和硬件无关性体验的软件。Mac版Docker并不是从一开始就支持Kubernetes,我们看看它的简史:

Docker发端于DotCloud公司,一开始并不支持Windows和Mac,只能运行在Linux上。
#Docker简史
##虚机
最开始,如果Mac或者Linux用户想使用容器技术,就需要在Linux主机中安装如VirtualBox或者VMWare Workstation/Player之类的虚拟机工具,并设置共享目录。为了使用统一CLI工具,用户不得不采用Hashicorp公司的Vagrant

使用场景:这种方式都是过时的技术,并不建议采用。
##Docker Machine
Docker Machine是进化的第二步,采用boot2docker镜像在本地或者远程环境部署虚机,并提供可写磁盘空间,也是朝易用性迈出的一大步。一旦基于SSL认证的VM生成,Docker客户端就可以通过TCP/IP工具访问它,可以同时支持多个Docker版本构成的集群。

优点:

  • 同一主机支持多个容器后端
  • 只支持Linux
  • 使用boot2docker镜像
  • 模块化支持各家云提供商插件
缺点:
  • 命令行方式操作
  • 不支持Windows和Mac
使用场景:使用Windows 7或者Windows 10 Home,需要在本地运行一套集群,或者需要在云端运维一套集群。##Docker for Mac/WindowsDocker Machine需要太多手工操作(通过docker-machine env),为了采用TLS,有时还需要重建。Docker for Mac/Windows(简称DfM)本着造福广大使用者的初衷,内建UI和菜单支持,推出了功能有限的beta版本,刚开始主要是Twitter使用它。优点:
  • 安装简便
  • 自动配置命令行
  • 图形化界面配置
  • 一键启停作业
缺点:
  • 共享卷时性能很差
  • 高耗能降低电池使用时间
  • 支持Windows 10 pro或者enterprise
使用场景:可用,但是需要本地安装Docker Swarm或者Kubernetes。##MinikubeMinikube跟docker-machine非常类似,也依靠boot2docker,初衷是创建内含可用于开发的Docker主机的单节点Kubernetes集群。
2.png
Mac上的minikube输出案例如下:
$ minikube startStarting local Kubernetes v1.8.0 cluster...  Starting VM...  Getting VM IP address...  Moving files into cluster...  Setting up certs...  Connecting to cluster...  Setting up kubeconfig...  Starting cluster components...  Kubectl is now configured to use the cluster.  Loading cached images from config file.
优点:
  • 本地环境易于访问
  • Kubernetes可用
缺点:
  • Kubernetes在空闲时耗费大量电力
  • 感觉还是跟docker-machine很类似
  • 内置Docker版本严重滞后
  • 有些功能尚不支持,例如RBAC(role-based authentication control)
  • 需要使用minikube start/stop
使用场景:需要本地Kubernetes场景但是不必关注Docker版本。以上总结了各阶段优缺点,下面看看最新内置Kubernetes功能的DfM第一印象。#第一印象以下是我更新DfM后,使用它得到的第一印象。##开始需要Docker 17.12或者更高版本以获得Kubernetes支持,然后就是通过UI界面花几分钟下载新版本。
3.png
##上下文和命名空间如果以前安装了minikube,需要转换到DfM上下文,否则kubectl会挂起。
kubectl config use-context docker-for-desktop

如果发现有太多输出内容,Kubernetes社区有一个叫kubectx的工具可以改善输出状况。

Docker Swarm和Kubernetes之间一个不同是命名空间的支持。默认地,Kubernetes生态容器运行在称为system的隐藏命名空间,可以通过以下命令查看`kubectl get all --all-namespaces`:
4.png
输出有很多默认运行的服务,和Docker Swarm一样,区别是对用户隐藏,运行在几个固定二进制代码中,而不是分散运行的服务。以下命令可以查看Kubernetes版本:
$kubectl versionClient Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.2", GitCommit:"bdaeafa71f6c7c04636251031f93464384d54963", GitTreeState:"clean", BuildDate:"2017-10-24T19:48:57Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"darwin/amd64"}  Server Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.2", GitCommit:"bdaeafa71f6c7c04636251031f93464384d54963", GitTreeState:"clean", BuildDate:"2017-10-24T19:38:10Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} 
看起来是1.8.2版本,尽管不是最新版本但也包含了所有重要功能。##整合DockerDocker希望Kubernetes更加易用,因此整合了Docker stacks和Kubernetes原生部署服务。Kubernetes是很容易扩展的,Docker使用Custom Resource Definitions (CRDs)引入了对“栈(stack)”概念的支持. 可以验证如下:
$kubectl get stacksNo resources found.$ kubectl get crdNAME                        AGE  stacks.compose.docker.com   24d
看看对compose文件的效果:
$ docker stack deploy prometheus -c ./docker-compose.yml Stack prometheus was created  Waiting for the stack to be stable and running...   - Service exporter has one container running - Service grafana has one container running - Service prom has one container runningStack prometheus is stable and running 
CRD验证:
$ kubectl get stacksNAME         AGE  prometheus   1m
创建了几个Pods:
$kubectl get pods  NAME                        READY     STATUS             RESTARTS   AGE  exporter-66c7bbfcc6-r5sq4   1/1       Running            0          2m  grafana-7c5f5f6b75-rfgzp    1/1       Running            0          2m  prom-76b4f584f7-qckc9       0/1       CrashLoopBackOff   4          2m
Prometheus有一个bug,可以用这个命令debug:$kubectl logs pod/prom-76b4f584f7-qckc9。如果仍然使用docker-compose开发和生产,现在可以直接转向Kubernetes了。##内置工作流我们期望内置工作流能够实现:
  • kubectl apply 支持YAML
  • helm
  • RBAC激活

下面部署OpenFaaS-Serverless功能(采用Docker和Kubernetes实现起来很简单)。
$ mkdir -p go/src/github.com/openfaas/ && \
cd go/src/github.com/openfaas/ && \
git clone https://github.com/openfaas/faas-netes && \
cd faas-netes && \
kubectl apply -f ./yaml


如果碰到命名空间错误,可以在faas-netes目录下执行kubectl apply -f ./namespaces.yml ,然后再尝试一遍。



OpenFaaS会在localhost:31112启动图形界面,并启用了RBAC和两个命名空间(openfaas / openfaas-fn),输出如下:
service "alertmanager" created  
deployment "alertmanager" created
configmap "alertmanager-config" configured
service "faas-netesd" created
deployment "faas-netesd" created
deployment "gateway" created
service "gateway" created
service "nats" created
deployment "nats" created
service "prometheus" created
deployment "prometheus" created
configmap "prometheus-config" configured
deployment "queue-worker" created
serviceaccount "faas-controller" configured
role "faas-controller" configured
rolebinding "faas-controller-fn" configured

服务也创建完毕。验证如下:
$ kubectl get all --namespace openfaas

然后打开UI,部署一个应用功能:

http://localhost:31112
5.png

然后选择Figlet - figlet是Linux下二进制文件可以产生ASCII 文本logos。
6.png

查看产生的Function/Pod:
$ kubectl get all --namespace openfaas-fn
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
deploy/figlet 1 1 1 1 8m

NAME DESIRED CURRENT READY AGE
rs/figlet-676c995d66 1 1 1 8m

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
deploy/figlet 1 1 1 1 8m

NAME DESIRED CURRENT READY AGE
rs/figlet-676c995d66 1 1 1 8m

NAME READY STATUS RESTARTS AGE
po/figlet-676c995d66-rqjpn 1/1 Running 0 8m

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
svc/figlet ClusterIP 10.101.45.157 8080/TCP 8m


相对于Docker Swarm,Kubernetes使用更多对象形成服务。



激活服务查看结果:
7.png

作业运行很顺畅,而且简单易用。对于社区维护和内置OpenFaaS整合很有帮助。

之前提过需要helm(一个类似OpenFaaS的分布式软件管理器),在Docker Swarm中没有类似的概念。

写这篇博客之前,我在Tweet上看有消息说helm也已经被支持了。

Just setup #kubernetes on the @Docker for Mac beta and did a #helm install... this is so so great!!
Adnan Abdulhussein (@prydonius) December 15, 2017

#总结
其实不仅是简单的DfM整合了“栈”,应该说在现有工具外层实现了简单化,提高了速度,更加易用。相信Docker Swarm用户都会使用这种整合,而且迁移到Kubernetes。



Docker Swarm 已死?作为Docker Captains用户组成员,我并没有更多内部消息,但是因为Docker Swarm仍然有很多用户,因此仍然会被支持。例如:最原始可以运行在容器内的Swarm仍然被Docker's UCP product支持。



如果读了developer reactions on Hacker News,可以看到Swarm仍然有很多粉丝,如果Kubernetes想吸引他们,那么on-prem安装维护过程需要提高。

因此我的第一印象总结如下:很多新功能令人振奋,尤其是对DfM的更新以及内部新元素使得它看起来更像一个LinuxKit了。
##推荐阅读
强烈推荐阅读Docker Swarm和Kubernetes不同,推荐如下博客:

* Blog - What you need to know: Docker Swarm and Kubernetes
* Read the docs on the Docker and Kubernetes integration
* Star: Award-winning OpenFaaS - serverless functions you can run yourself on Kubernetes or Docker Swarm

原文链接:First impressions: Docker for Mac with Kubernetes(翻译:杨峰)

Swarm的进化和在阿里的大规模应用实践

尼古拉斯 发表了文章 • 0 个评论 • 3191 次浏览 • 2017-10-12 18:34 • 来自相关话题

【编者的话】目前在容器编排领域,Kubernetes、Mesos以及Swarm呈现“三分天下”的格局,各自都有着不同的应用场景。短期内,很难看到“一统天下”的局面,本文,来自阿里云高级专家陈萌辉将带你了解阿里内部在推行容器化过程中的一些着力点,同时,他将深刻剖 ...查看全部
【编者的话】目前在容器编排领域,Kubernetes、Mesos以及Swarm呈现“三分天下”的格局,各自都有着不同的应用场景。短期内,很难看到“一统天下”的局面,本文,来自阿里云高级专家陈萌辉将带你了解阿里内部在推行容器化过程中的一些着力点,同时,他将深刻剖析Swarm的进化史以及在阿里云的大规模应用,最后,他给出三个案例,供大家参考。

阿里从前年开始就已经在集团内部大规模地推行容器化和运用Swarm来做应用的发布、集群管理等事情。特别值得注意的是去年,阿里云跟Docker达成了一项深度合作的协议,从中我们不难窥探阿里的容器战略。本文将从三个方面阐述“Swarm的进化和大规模应用”,第一, Swarm架构;第二,Swarm Mode的编排;第三是Swarm在阿里的应用。
#Swarm架构
1.jpg

图1 Swarm架构

我们先看一下Swarm是什么?Swarm,是Docker官方推出的,它的特点就是跟Docker本身有很好的集成,另外,它也是一个非常简单易用的工具,所以目前吸引了很多开发者在用。

Swarm是Docker公司继Docker Engine之后推出的很重要的集群管理系统和容器编排与调度系统。架构底层是集群的机器资源,可以是一些物理机也可以是一些虚拟机,上面经过Swarm这一层把容器调度和部署到这些机器上去,它对外提供跟Docker类似的API。

具体来看,Swarm的框架分成三块,第一块是Engine,第二是Manager,第三是KV store。它有几个特点,第一依赖外部存储来完成节点发现并保证一致性;第二,Manager只跟Daemon通信,不跟Agent通信;第三,Manager可以有多副本,这是为高可用设计的,采用一主多热备模式,所有manager都同时连接所有Daemon,备转发请求至主,另外,它依赖外部KV选主。
##API
Swarm提供的API,主要是有这么几类:

* 集群类:info events
* 容器类:get/list、create、start/stop等
* 镜像类:get/list、push、pull、tag等
* 数据卷类:get/list、create、delete
* 网络类:get/list、create、delete等

##调度
资源维度层面有三个: CPU 、Memory、 端口,CPU / Memory支持超卖;调度策略有两种:spread / binpack,另外,它不支持优先级、抢占。

它比较有特点的一些功能有两个,一个是叫节点约束,约束可以有两种类型,比如说你可以约束我这个节点是哪一个,你可以给节点去一个名字或者打一个标签什么的,另外一个可以通过打标签去选择一种机器,你在部署的时候,可以指定这些容器部署到哪些机器上去。

节点约束:

* 节点名:constraint:node==XXX
* 标签:constraint:key==value

亲和性也有两种,一种是image,一种是service,比如我有一个应用镜像很大,我不希望它在集群各个地方去部署,我希望他部署下来已经下载镜像的地方,这样的话可以减少一些启动的时间和下载的过程,你可以说我这个服务不是跟某个镜像做亲和,也可以跟某个服务做亲和。

亲和性:

* 镜像:affinity:image==foo
* 服务:affinity:service==foo

总结一下Swarm这个产品,Swarm整体来说有几个特点,第一个是部署简捷,只有三个模块,外部的依赖只有KV Store和Docker Daemon这两个,所有组件都容器化。第二高效友好的用户交互,高度兼容Docker Engine API,可直接使用Docker Client。第三是灵活的约束与亲和性描述,可以在一定程度上弥补调度策略的不足。

同时,我们也看到它有一些不足的地方,首先一个不足的地方就是它是容器级别的API,所有的API都是针对单个容器的,抽象层次较低。其次,响应式设计,不方便执行常驻后台的操作,它在内存中不保存任何的状态,所有的状态都是从Docker上统计过来的。有一个好处,它一旦挂掉了,能够很方便地恢复状态,但也有一些坏处,比如你要跑一个离线的任务,就不太好做。除此之外,它依赖定期同步跟Docker Engine保持一致状态。
#Swarm Mode
针对Swarm这个产品的一些不足,从1.12版本开始,Docker就提供了Swarm Mode的功能,这个功能是将Swarm的集群管理、容器调度功能集成进Docker Engine,并且提供Service级别抽象和自带的负载均衡,它从容器级别的调度器进化到了服务级别的调度器。
##架构
2.jpg

图2 Swarm Mode架构

它的架构比Swarm更简单一些,首先就是它没有任何的外部依赖,只要你装 Docker Engine,它就可以构成一个容器集群,DockerDaemon本身会兼Engine、Manager、Agent三职。Managers之间通过RAFT协议组成分布式强一致性KV Store,Manager与Worker的Daemon不通信。

同时,它也是有高可用设计的,Manager数量需要大于等于3才可以实现高可用,它也是一主多热备,另外也可以动态添加/删除Manager,如果有的机器宕机或者挂掉了,你不需要把这个机器再恢复起来,很多系统对Manager控制器的机器是有依赖的。如果一旦挂掉了你只能把它修好之后再上来,但是这个是不需要的,你可以任意在里面编程。这样他会通过RAFT协议把原来集群状态信息统一到Manager上去,这样有实现了高可用。
##Swarm Mode API
在刚才Swarm的API之上,多提供了两类的API:

集群管理类:

* init、join、leave
* token

服务类:

* get/list
* create、delete、update
* inspect、ps

同时,Swarm的API有两个特点,它分两类,一类是像Swarm、Service、Network类,只有Manager能处理的。还有一类容器、镜像、数据卷类,所有节点都能处理。另外它的API还是高度兼容旧的API,你可以拿低版本的去访问Swarm mode的集群。
##Service

我们来看一下Swarm Service的概念,它提供了三级的概念:

* Service:相同功能的一组容器
* Task:任务调度单元,由Manager生成,同步至Worker
* Container:Task落地

另外,还提供Rolling Update功能。

在Swarm mode里面Service分为两类,一类是有Replicated Service,一类是Global Service。

Replicated Service:

* 用户指定副本数
* Reconciled:自动确保副本数
* constraint

node.id node.hostname:

* node.role
* node.labels engine.labels

Global Service:

* 每个节点有且仅有一个容器
* 添加加点时自动扩展
* 可附加constraint

网络模型方面,支持overlay网络,同一网络内,服务名、容器名可解析;一个服务一个网络;服务发现支持不同服务可加入同一个网络。
##Routing Mesh
下面我们看一下Swarm自带的负载均衡,它取的名字叫做Routing Mesh,Service自带的负载均衡是基于LVS,主要有两种模式,

VIP模式:每个服务一个VIP,通过LVS实现;服务名解析至VIP;

DNS模式:服务名解析至容器IP,RoundRobin方式。另外,服务发生变化时,自动调整后端。

总结一下Swarm Mode的产品,第一个它是无任何依赖,可以安装Engine+一个命令,无中心架构。第二个它可以部署高可用服务,你可以在集群这边进行访问的,比如说你的容器只布在了三台机器,这个集群所有的机器都可以访问到这个服务,这样的话就很容易做成高可用的。再一个Secure by default,自带证书颁发、更新功能,Manager与Worker之间通过SSL连接。

当然它也有一些不足的地方,第一个只有Service级抽象,Stack级抽象仍无API,另外,部署有状态服务比较复杂。第二,Service API有很多容器特性不支持,如host network、host pid、privileged等。还有一个缺点,它无法自举,是需要手工init的。
#Swarm在阿里内部的应用
上面介绍了Docker Swarm的产品相关的东西。下面我就来介绍一下Swarm在阿里内部的应用,这个也是大家更关心的一个地方,有几个方面。第一是阿里内部的容器化,可能大家都知道,阿里内部有一支非常强大的运维团队,除非查问题的时候,一般开发人员是不接触现代的机器的,所有的应用部署、升级这些都是运维人员来做的。强大的运维团队也导致了一些问题,它的应用的部署和升级往往是很个性化的,可能这个运维人员他在支持这个应用的时候,通过写一些脚本或者用一些工具,实现业务的部署的自动化,而另外的运维人员运用另外的工具和另外的脚本,导致了很多应用的升级部署不是一个标准化的方式。这样的话,比如说这个人员他转岗了,新来的人首先要去熟悉那个部署的工具,这个运维任务比较大,所以应该是从去年、前年阿里内部开始推容器化,由Swarm来统一管理我们的集群,应用的话就是容器化之后,由Swarm去统一做部署,这样的话就会形成一个跟业务无关的统一的部署平台。运维人员不再去关心应用如何地去部署,他只要关心把这个应用部署上去就可以了,所有的应用都是一样的方式,即使有新的人接替他学起来也非常地方便。
3.jpg

图3 阿里云容器服务整体架构

另外是阿里云的专有云输出,因为专有云这个东西一旦部署到用户的机房之后,你升级就变得非常麻烦,有了容器之后,它的镜像的管理和升级就非常方便了。还有一个优点,它可以实现管控部署的资源优化,因为原来可能所有的管控都是独占机器的,这样的话比如说你布很多服务就会占很多机器,有了容器之后管控就可以共享机器了,减少了管控所占的资源,提高了用户能使用的资源的数量。

第二是阿里云的容器服务,这是我们在阿里云公有云上推出的一款产品,作用是帮用户管理集群和部署应用,当然还提供更多高级别的服务。

第三是阿里云高性能计算 HPC也会用到容器,在高计算领域,它的安装很复杂、很麻烦,经常比如说你拿到一个带显卡的机器,你在上面部署基础的应用,可能得花掉你一周的时间,如果你的应用是容器化的,这个事情就可以放到容器里面去,你只要关心自己的应用就可以了,可以大大地提高应用部署的效率。

下面重点介绍一下阿里云容器服务的一些特性,我们先看一下整体的架构,整体来说,阿里云容器服务是一个集群托管的模式,机器是用户的,但是管控是我们提供的。现在相当于我们帮用户管理他的机器,我们通过某一些界面化、某一些API的信息让用户去管理集群以及管理他的应用。

用户的机器下面会装Engine、下面会跑容器,我们这边的管控提供一个控制台,提供集群的创建和扩容这样的功能,然后提供服务、注册和发现的功能,提供应用生命周期管理和使用调度的功能。同时我们还会把很多阿里云上的服务都集成进来,比如说我们集成了SLB、ECS等功能,达到的目标让用户只关心我的应用,而不需要关心底下的机器。

我们可以看一下我们提供的功能,从四个角度讲。

第一个是集群的管理,这是最基本的功能,我们可以帮用户一键创建出一个容器集群,同时支持公有云、专有云、混合云以及敏捷版,公有云包括GPU的机器,专有云是部署在用户机房的,混合云就是你可以一部分集群管控在我们的机房,但是真正的用户机器在你自己的机房。你可以实现应用跨云的统一部署。另外还支持bare metal敏捷版。

第二是镜像服务,这是对容器化很重要的服务,我们支持公有和私有的仓库,你可以有自己的私有仓库,同时支持DockerHub的加速,我们提供这个加速的功能可以让你像访问国内的机器一样,另外可以连接第三方代码库,这样,其实你可以当成CICD系统的最重要的环节,你可以从代码到最终生成镜像,甚至到最后部署把它全自动打通。

第三是应用生命周期的管理,支持Swarm和Swarm Mode两种模式。

同时支持Rolling Update、蓝绿发布、离线与定时任务。

最后是微服务的支持,微服务它不是为容器而生,但是有了容器之后它的实现会变得更简单一些,为了微服务的支持,我们提供了一些很重要的基础的功能。包括服务发现、负载均衡、弹性伸缩、集成监控与日志、集成共享存储。

这是在阿里云上部署一个nginx应用的一个例子,这是用的3.0的模板,用Engine来部署,它可以通过8080端口来访问到。
4.jpg

图4 负载均衡案例
version: ”3.0”  #支持v1 v2 v3 compose模板
services:
nginx:
image: nginx:latest
deploy:
mode: replicated
replicas: 3
ports:
- 8080:80
labels:
aliyun.lb.port_8080`: tcp://slbtest:8080 #负载均衡
aliyun.log_store_dbstdout: stdout #日志收集
aliyun.log_store_varlog: /var/log/*.log
volumes:
- 'website:/usr/share/nginx/html'
volumes:
website:
driver: ossfs #共享存储数据卷,支持oss、nas
driver_opts:
bucket: acs-sample

自动扩容的事例,简单来说,你只要声明一下,当CPU超过70%了就扩展出两个容器来,我们的做法是通过监控平台把数据收集上去,之后,如果当它超过了70%的时候会调用集群管理的API,给它扩出容器来,同时会把负载均衡的后端再挂到新的容器上,这样就实现了自动扩容。
5.jpg

图5 自动扩容案例

声明式自动扩容
aliyun.auto_scaling.max_cpu: 70 
aliyun.auto_scaling.step: 2

监控插件

* 输入:Nagios、Apache、Docker、UDP……
* 输出:InfluxDB、Prometheus、Kafka

蓝绿发布的事例,如图6,蓝色的应用要进行升级,怎么做呢?首先部署一个新的应用,这两个是同时在线的,它会通过SLB给它分流量,比如80%和20%,之后做验证,验证之后,发布完成,系统就会把原来老的删掉。
6.jpg

图6 蓝绿发布案例

机器学习案例,假如你的集群是稳步的,有GPU机器和非GPU机器,你可以在你的Service里面注明需要两个GPU,系统会把你调度到有GPU的集群,同时把你的应用绑到GPU卡上去。
7.jpg

图7 机器学习案例
version: '2'
services:
inception:
image: acs_sample/inception:demo
volumes:
- inception_model/inception_model
labels:
- aliyun.gpu=2
ports:
- "9000:9000"
volumes:
inception_model:
driver: nas


原文链接:Swarm的进化和大规模应用

几种常见的微服务架构方案——ZeroC IceGrid、Spring Cloud、基于消息队列、Docker Swarm

尼古拉斯 发表了文章 • 0 个评论 • 3230 次浏览 • 2017-09-29 19:08 • 来自相关话题

微服务架构是当前很热门的一个概念,它不是凭空产生的,是技术发展的必然结果。虽然微服务架构没有公认的技术标准和规范草案,但业界已经有一些很有影响力的开源微服务架构平台,架构师可以根据公司的技术实力并结合项目的特点来选择某个合适的微服务架构平台,以此稳妥地实施项目 ...查看全部
微服务架构是当前很热门的一个概念,它不是凭空产生的,是技术发展的必然结果。虽然微服务架构没有公认的技术标准和规范草案,但业界已经有一些很有影响力的开源微服务架构平台,架构师可以根据公司的技术实力并结合项目的特点来选择某个合适的微服务架构平台,以此稳妥地实施项目的微服务化改造或开发进程。

本文盘点了四种常用的微服务架构方案,分别是ZeroC IceGrid、Spring Cloud、基于消息队列与Docker Swarm。
#ZeroC IceGrid微服务架构

ZeroC IceGrid作为一种微服务架构,它基于RPC框架发展而来,具有良好的性能与分布式能力,如下所示是它的整体示意图。
1.jpg

IceGrid具备微服务架构的如下明显特征。

首先,微服务架构需要一个集中的服务注册中心,以及某种服务发现机制。IceGrid服务注册采用XML文件来定义,其服务注册中心就是Ice Registry,这是一个独立的进程,并且提供了HA高可用机制;对应的服务发现机制就是命名查询服务,即LocatorService提供的API,可以根据服务名查询对应的服务实例可用地址。

其次,微服务架构中的每个微服务通常会被部署为一个独立的进程,当无状态服务时,一般会由多个独立进程提供服务。对应在IceGrid里,一个IceBox就是一个单独的进程,当一个IceBox只封装一个Servant时,就是一个典型的微服务进程了。

然后,微服务架构中通常都需要内嵌某种负载均衡机制。在 IceGrid 里是通过客户端API内嵌的负载均衡算法实现的,相对于采用中间件Proxy转发流量的方式,IceGrid的做法更加高效,但增加了平台开发的工作量与难度,因为采用各种语言的客户端都需要实现一遍负载均衡的算法逻辑。

最后,一个好的微服务架构平台应该简化和方便应用部署。我们看到 IceGrid提供了grid.xml来描述与定义一个基于微服务架构的Application,一个命令行工具一键部署这个Application,还提供了发布二进制程序的辅助工具——icepatch2。下图显示icepatch2的工作机制,icepatch2server类似于FTP Sever,用于存放要发布到每个Node上的二进制代码与配置文件,而位于每个Node上的icepatch2client则从icepatch2server上拉取文件,这个过程中采用了压缩传输及差量传输等高级特性,以减少不必要的文件传输过程。客观地评价,在Docker技术之前,icepatch2这套做法还是很先进与完备的,也大大减少了分布式集群下微服务系统的运维工作量。
2.jpg

如果基于IceGrid开发系统,则通常有三种典型的技术方案,下图展示了这三种技术方案。
3.jpg

其中方案一是比较符合传统Java Web项目的一种渐进改造方案,Spring Boot里只有Controller组件而没有数据访问层与Service对象,这些Controller组件通过Ice RPC方式调用部署在IceGrid里的远程的Ice微服务,面向前端包装为REST服务。此方案的整体思路清晰,分工明确。Leader在开源项目中给出了这种方式的一个基本框架以供参考:https://github.com/MyCATApache/mycat-ice。

方案二与方案三则比较适合前端JavaScript能力强的团队,比如很擅长Node.js的团队可以考虑方案二,即用JavaScript来替代Spring Boot实现REST服务。主要做互联网App的系统则可以考虑方案三,浏览器端的JavaScript以HTML5的WebSocket技术与Ice Glacier2直接通信,整体高效敏捷。

IceGrid在3.6版本之后还增加了容器化的运行方式,即Ice Node与Ice Registry可以通过Docker容器的方式启动,这就简化了IceGrid在Linux上的部署。对于用Java编写的Ice微服务架构系统,我们还可以借助Java远程类加载机制,让每台Node自动从某个远程HTTP Server下载指定的Jar包并加载相关的Servant类,从而实现类似Docker Hub的机制。下图显示了前面提到mycat-ice开源项目时给出的具体实现方案。
4.jpg

#Spring Cloud微服务架构

Spring Cloud是基于Spring Boot的一整套实现微服务的框架,因此它只能采用Java语言,这是它与其他几个微服务框架的最明显区别。Spring Cloud是一个包含了很多子项目的整体方案,其中由Netflix开发后来又并入Spring Cloud的Spring Cloud Netflix是Spring Cloud微服务架构的核心项目,即可以简单地认为Spring Cloud微服务架构就是Spring Cloud Netflix,后面我们用Spring Cloud时如果不特意声明,就是指Spring Cloud Netflix。

首先,Spring Cloud中的服务注册中心是Eureka模块,它提供了一个服务注册中心、服务发现的客户端,还有一个简单的管理界面,所有服务使用Eureka的服务发现客户端来将自己注册到Eureka中,如下所示为相关示意图,你会发现它很像之前第4章中的某个图。
5.jpg

那么Spring Cloud是如何解决服务的负载均衡问题的呢?由于Spring Cloud的微服务接口主要是基于REST协议实现的,因此它采用了传统的HTTP Proxy机制。如下图所示,Zuul类似一个Nginx的服务网关,所有客户端请求都通过这个网关来访问后台的服务。
6.jpg

Zuul从Eureka那里获取服务信息,自动完成路由规则的映射,无须手工配置,比如上图中的URL路径/customer/*就被映射到Customer这个微服务上。当Zuul转发请求到某个指定的微服务上时,会采用类似ZeroC IceGrid的客户端负载均衡机制,被称为Ribbon组件,下图给出了Zuul与Eureka的关系及实现服务负载均衡的示意图。
7.jpg

如下所示是Spring Cloud微服务架构平台的全景图。我们看到它很明显地继承了Spring Framework一贯的思路——集大成!
8.jpg

从图中来看,Spring Cloud 微服务架构平台集成了以下一些实际项目开发中常用的技术与功能模块。

基于Spring Security的OAuth模块,解决服务安全问题。

提供组合服务(Composite Services)的能力。

电路断路器 Hystrix,实现对某些关键服务接口的熔断保护功能,如果一个服务没有响应(如超时或者网络连接故障),则Hystrix可以在服务消费方中重定向请求到回退方法(fallback method)。如果服务重复失败,则Hystrix会快速失败(例如直接调用内部的回退方法,不再尝试调用服务),直到服务重新恢复正常。

监控用的Dashboard,可以简化运维相关的开发工作量。

总体来说,Spring Cloud是替代Dubbo的一种好方案,虽然Spring Cloud是基于REST通信接口的微服务架构,而Dubbo以RPC通信为基础。对于性能要求不是很高的Java互联网业务平台,采用Spring Cloud是一个门槛相对较低的解决方案。
#基于消息队列的微服务架构

除了标准的基于RPC通信(以及类RPC的通信如Http Rest、SOAP等)的微服务架构,还有基于消息队列通信的微服务架构,这种架构下的微服务采用发送消息(Publish Message)与监听消息(Subscribe Message)的方式来实现彼此之间的交互。下图是这种微服务架构下各个组件之间的交互示意图,我们看到消息中间件是关键,它负责连通各个微服务与UI组件,担任了整个系统互联互通的重任。
9.jpg

基于消息队列的微服务架构是全异步通信模式的一种设计,各个组件之间没有直接的耦合关系,也不存在服务接口与服务调用的说法,服务之间通过消息来实现彼此的通信与业务流程的驱动,从这点来看,基于消息队列的微服务架构非常接近Actor模型。实际上,分布式的Actor模型也可以算作一种微服务架构,并且在微服务概念产生之前就已经存在很久了。下面是一个购物网站的微服务设计示意图,我们看到它采用了基于消息队列的微服务架构。
10.jpg

网易的蜂巢平台就采用了基于消息队列的微服务架构设计思路,如下图所示,微服务之间通过RabbitMQ传递消息,实现通信。
11.jpg

与上面几种微服务架构相比,基于消息队列的微服务架构并不多,案例也相对较少,更多地体现为一种与业务相关的设计经验,各家有各家的实现方式,缺乏公认的设计思路与参考架构,也没有形成一个知名的开源平台。因此,如果需要实施这种微服务架构,则基本上需要项目组自己从零开始去设计实现一个微服务架构基础平台,其代价是成本高、风险大,因此决策之前需要架构师“接地气”地进行全盘思考与客观评价。
#Docker Swarm微服务架构

Docker Swarm其实是Docker公司“高仿”Google开源的Kubernetes微服务架构平台的一个产品,但一直无法跟上对手的脚步,在业界始终缺乏影响力。2016年发布Docker 1.12时,Docker Swarm就被强行集成到了Docker Engine中而不再作为单独的工具发布了,这类似当年微软推广IE浏览器的做法。不过即使这样,也难以掩盖Docker Swarm还没成名就已经陨落的事实。

Docker Swarm的最初目标是将一些独立的Docker主机变成一个集群,如下图所示,我们通过简单的Docker命令行工具就能创建一个Swarm集群。
12.jpg

后来随着Kubernetes微服务架构平台越来越火,Docker 公司开始努力让Swarm向着Kubernetes的方向靠拢,即变成一个基于容器技术的微服务平台。下面给出了Swarm集群的结构图。
13.jpg

从图中我们看到一个Swarm集群中有两种角色的节点。

Swarm Manager:负责集群的管理、集群状态的维持及调度任务(Task)到工作节点(Swarm Node)上等。

Swarm Node:承载运行在Swarm集群中的容器实例,每个Node主动汇报其上运行的任务(Task)并维持同步状态。

上图中的Docker Compose是官方编排(Orchestration)项目,它提供了一个YAML格式的文件,用于描述一个容器化的分布式应用,并且提供了相应的工具来实现一键部署的功能。下图给出了两节点的Couchbase集群对应的YAML文件定义,此Couchbase集群随后被部署到了Swarm集群中的两个Node节点上。
14.jpg

注意上图左边YAML文件中的Services定义,Swarm manager节点给每个Service分配唯一的DNS名字,因此可以通过最古老又简单的DNS轮询机制来实现服务的发现与负载均衡,这明显借鉴了Kubernetes的做法。
由于Docker Swarm高仿了前辈Kubernetes的设计,而且在微服务架构中并没有太多的影响力,所以我们在此并未做深入介绍。

原文链接:http://www.broadview.com.cn/article/348

房多多容器化和容器云实践

阿娇 发表了文章 • 0 个评论 • 745 次浏览 • 2019-04-25 22:56 • 来自相关话题

#背景和意义 房多多是国内首家移动互联网房产交易平台。作为迅速崛起的行业新生力量,房多多通过移动互联网工具,为开发商、经纪公司、买房卖房者搭建了一个高效的、可信赖的O2O房产交易平台。 房地产行业的复杂性和业务创新环 ...查看全部
#背景和意义

房多多是国内首家移动互联网房产交易平台。作为迅速崛起的行业新生力量,房多多通过移动互联网工具,为开发商、经纪公司、买房卖房者搭建了一个高效的、可信赖的O2O房产交易平台。

房地产行业的复杂性和业务创新环境注定了房多多的产品特点是不断持续创新和持续高速迭代的,在不断探索业务的可能性的过程中,提高持续快速交付价值的能力和创新能力是必不可少的。

软件行业没有所谓的“银弹”,房多多在业务解耦微服务化以后,服务指数型的增长带来了许多运维方面的困扰。

在我们内部比较突出的矛盾有:

* 虚拟机的资源依靠维护文档人肉调度,机器调度效率低。
* 维护测试、预发布、生产等环境的成本高。
* 某个业务的稳定太依赖某台物理机的稳定性,且难以快速扩容。
* 业务需求变化快导致雪花服务器增多,难以维护;
* CI/CD脚本复杂,新的需求难以快速交付。

在2018年房多多技术团队开始了服务容器化和容器云的建设,调研后选择了 Swarm 作为了容器集群。

可能很多人看到这儿就会关掉,"都9012年了还有人用Swarm?"

虽然在Swarm在和Kubernetes的竞争中已处于下风,但是Swarm的灵活性、性能和易用性促进了我们的容器化推进,且在我们落地过程中没有出现过系统级的bug和线上故障,目前已经在生产环境支撑数百个服务的运行,每日300次左右的变更。

容器和调度编排系统的引入给难以运维的微服务架构带来了质的改变,但是服务容器化和容器云在推进过程中也踩过不少坑和积累了一些经验,希望给大家带来启发。
#选型

在容器集群的选择上,Kubernetes事实上已成为容器届编排的标准,但是为什么我们选择了小众的 Docker Swarm呢?

房多多的生产环境硬件基础设施基本都在IDC机房,物理机器数量大概有几百台,实际可以供业务迭代用的机器大概在一半左右,且没有很多空闲机器可供使用、新建容器云的机器需要腾挪现有业务。

根据上述的自身的情况,我们做容器平台调研时,主要从以下三点考虑:

* 性能:用户可以在多短的时间内启动并大规模运行容器?系统在大负载情况下响应速度如何?
* 易用性:起步时的学习曲线是什么?维持运转是否复杂?系统中有多少不定项?
* 灵活性:是否可以和我当前的环境和工作流相整合?应用从开发到测试再到生产,是否可以无缝衔接?会不会被限制在某个平台上?

从性能看:房多多是自建机房,每一台物理机的利用率是比较高的。在我们测试调研过程中发现,Swarm通常可以在一秒内启动一台容器,调度效率和容器启动速度其实比Kubernetes快很多。如下图(50%负载下,1000节点 启动每一个容器的平均时间):
1.jpg

从灵活性来看:Swarm的API比较简单,可以很快的和现有的DevOps流程打通。且因为Swarm相当于Kubernetes的子集,如果后面机器规模继续扩展,业务有大量编排需求,我们可以花不多的时间就可以迁移到Kubernetes上。其实只要我们的服务容器化了,后续更换什么容器集群其实问题都不大。

从易用性来看:API使用简单,资源抽象简单,可以快速启动上手。我们使用Swarm比较多的功能其实是调度功能,编排功能暂时没有大规模使用。Swarm的结构比较简单,在最新的版本中内置分布式k-v数据库代替了etcd,内置DNS用来服务发现。在规模中等情况下,几乎没有基础设施运维负担。
#容器云架构

Swarm的实现和Kubernetes相似,最近的版本也在慢慢模仿Kubernetes的思想。

想了解如何搭建集群的操作可以查阅 Swarm 官网的文档。

因为Manager节点只负责调度集群的Task,配置要求不高,所以我们用虚拟化Xenserver虚拟了3台低配置机器(在不同的物理机上)作为Manager节点,根据Raft算法,3台可以容许1台机器出问题,5台可以允许2台机器出问题,大家可以按需求部署。Worker节点的作用是运行业务容器,我们选择了直接用物理机来部署已达到最好的性能和资源利用。同时,在Manager和Worker节点上,会以容器方式部署机器监控和日志收集,上面还需要运行网络和存储插件。

都加入到集群之后,Swarm会提供网络管理、负载均衡、基于DNS容器发现、集群状态管理、扩容缩容等功能,我们在DevOps流程层面,可以组合成发布、回滚应用、查看服务的状态、日志、终端,更改发布配置(例如环境变量、默认副本数等)等功能。这个层面我们引入了Portainer这个开源项目,提供了更好用集群管理的UI界面和类似Kubernetes Apiserver设计的Docker集群API接口服务。
2.jpg

Docker Swarm的资源抽象比较简单,在没有容器编排的情况下,我们主要使用Services,这个和Kubernetes上的Services有些不一样,可以理解为Services和Deployment的合体,用来管理和定义容器的调度和扩容等,也可以直接做端口映射,在容器集群里任意IP都可以访问。

下图可以比较简单的描述我们是怎么把服务让外部和内部调用的:
3.jpg

外部调用我们目前是通过Nginx做反向代理到集群的节点,因为Ingress的特性我们可以转发到任何一台Worker或者Manager节点上,然后通过内置的routing mesh的Load Balancer通过LVS转发请求到Service的其中一个副本,一个值得注意的点是,就算这台Node上没有运行这个Service的容器Load Balancer也会找到其他机器上存在的副本,这个主要是通过 内置的DNS加LVS转发实现。

内部调用我们是走我们的Envoy Mesh网关,通过自研的xds-service来自动发现加路由,本质是走容器之间互通的Overlay网络或者Macvlan网络。
#网络

网络我们主要解决两个问题:

  1. 容器间互相通信,容器直接互相调用打通,并且可以作为基础的容器网卡,以支持容器集群的routing mesh功能。
  2. 容器和外部网络互相通信,类似使用了Dubbo服务容器化,在虚拟机和容器并存的迁移过程中,必须要让容器和外部网络互通,不然会导致在容器集群外部的虚拟机调用不通容器。虽然也可以通过其他方法实现,但是打通容器和外部网络互相通信是较可行也是稳定的一种方法。

下图是我们主要的容器网络架构。
4.jpg

容器间互通的解决方案是我们在容器集群中创建Overlay网络,并将网络附加到容器容器上,容器中就有了名为Overlay的网卡(图中的 eth0),每个容器的eth0都会经过宿主机的docker0网卡和eth0与别的宿主机的网络进行交互。

容器与外部网络互通的解决方案是Macvlan。其工作原理是通过为物理网卡创建Macvlan子接口,允许一块物理网卡拥有多个独立的MAC地址和IP地址。虚拟出来的子接口将直接暴露在底层物理网络中。从外界看来,就像是把网线分成多股,分别接到了不同的主机上一样,这样也可以拥有近似物理机直连的性能。

公有云一般会限制Macvlan,不一定可以实施。因为我们是自建机房,所以没有这方面的限制,只要让网络工程师在交换机上配置好网段,我们就可以在此网段下分配容器的IP了。

具体使用方法是,在容器Worker节点创建一个config-only的Network,写划分的网段和网关,例子:
docker network create --config-only --subnet=10.0.127.0/20 --gateway=10.0.112.1 --ip-range=10.0.112.0/25 -o parent=bond0 pub_net_config
# bond0 为指定的依附的物理机网卡

然后在Manager节点创建Network,例子:
docker network create -d macvlan --scope swarm --config-from pub_net_config pub_net

然后只需要把网络附加到Service上即可:
docker service update m-web --network-add pub_net

#容器化

容器化首先是要把业务代码build成镜像,我们内部的技术栈主要以Node和Java为主。

我们容器化迁移是先从Node服务开始,因为Node服务普遍比较新且项目都按照规范创建,没有很多历史债务且基本都是无状态的,这样我们就可以写出一个比较通用的Dockerfile让开发在迭代需求是时候顺便加上,基本只需要改一下暴露的端口号和监控检查URL就可以完成容器化。

Java的构建工具主要以Maven和Gradle为主,我们使用了Google开源的Jib 工具来把构建Docker镜像并上传的工作集成到Maven和Gradle中,实际操作只需要改一下pom文件或者build.gradle,加入Jib Plugins就可以了。

实际推广过程中,如果是还在迭代的项目,因为操作简单且容易理解,业务开发还是比较容易推动的。如果是历史项目且还运行在线上,可以让业务运维帮忙逐个操作,然后重新发布,测试,上线。
#优化和Tips

##镜像大小优化

镜像大小是容器化很重要的一个问题。镜像越小,容器发布和调度就越快,宿主机磁盘用量也不会过大。

除了大家常用的镜像优化手段比如减少层级等,我们优化基础镜像baseimage使用了alpine 3.9版本,并对使用到的基础库做了选择,比如使用最新的musl 1.1.21等,最终基础镜像控制42M,最终降低80%镜像大小到300M以内。
##信号量优化

当容器的启动脚本是一个Shell脚本时,因为Shell不响应退出信号的特性,会导致容器无法正常退出,只能等超时后自动杀死进程,这样在我们的实践中会导致物理机上有很多僵尸进程。所以我们的解决方案是消除进程树中的Shell进程,我们改用了一个tini这个来作为主进程,在基础镜像中添加ENTRYPOINT ["/tini", "—"]即可,虽然不等子进程返回的方式可能不太优雅,但是可以快速stop容器带来的灵活性足以弥补这个缺点,当然特殊应用可以特殊处理。
##Java容器化问题

Java容器化的坑比较多,JDK我们使用了 OpenJDK 8(version "1.8.0_191"),JVM opts我们加上了-XX:+UseContainerSupport -XX:MaxRAMPercentage=75.00,这个版本Java已经可以获取到正确的CPU资源和内存资源,默认使用75%的Cgroup空间为heap memory,留25%空间给stack memory。防止因为heap memory加stack memory太大导致容器内存使用超出Cgroup限制被Kill掉。

除此之外,我们还优化了随机数生成的原理:
echo "securerandom.source=file:/dev/urandom" >> /usr/lib/jvm/default-jvm/jre/lib/security/java.security

##DNS Performance(Lookup Failed)

两方面原因:

一方面,Docker自身的DNS允许并发数太低,已经提issue并修复了:docker Increase max concurrent requests for DNS from 100 to 1024。

另一方面,musl的代码在DNS解析的实现上有些问题,如果有IPv6的A记录那么解析性能不会出现问题,如果只有AAAA的IPv4记录,那么解析可能会出现卡死的情况,等待2.5s才返回,所以要添加一个break代码防止出现等待,在最新的musl的版本解决了(没有发布,需要自行编译)。
5.jpg

最后,这个问题其实是因为业务服务大多数是使用HTTP/1.x导致产生多条TCP连接造成的,现在房多多已经全站使用HTTP 2多路复用长连接,这个瓶颈其实也就不存在了。
##流量突然增高Slab分配失败导致机器负载高

容器平台集群不定期的报slab memory malloc的错误。

系统负载高时,服务器内核大量报Slab cache错误,升级CentOS 7.5新内核862解决。值得一提的是,在容器时代,大家对内核的要求越来越高也越来越依赖内核的功能,很多公司其实都走在了内核迭代的前列,发现了很多bug并对社区做出了贡献。
##物理机配置问题导致容器网络不通

我们有出现过一次交付物理机Restart Network后没有开启ipv4_forward导致的改物理机上的容器Overlay网络挂的问题。

我们的解决方法是在启动容器前通过ping网关的方式检查DNS服务和网络是否打通。
#发布系统改造

##构建流程自定义

在容器化的过程中,我们也把构建流程做了优化,引入了Jenkins Pipeline功能。Pipeline对于我们的最重要的好处是可以把构建流程DSL代码化,并可以针对每一个项目自定义构建流程,当然我们有提供一个大体的框架,用户只需要更改自己所需要的就可以了,如下图:
6.jpg

7.jpg

最终会生成一个Jenkinsfile并在每次构建的时候都回去调用项目对应的Jenkinsfile。有了这样的功能,开发就可以根据自己的需求,轻松的更改自己项目的构建流程。
##Web Terminal

我们根据业务开发的需求开发了Web进入Docker容器的功能。原理是转发docker exec命令到对应的物理机上,并转发输入输出。支持快捷键和高亮,体验良好。
8.jpg

##Log

日志我们通过在转发docker logs请求获取最新的2000条(默认,可配置)日志打印到Web页面上,支持自动刷新和滚动。
9.jpg

#日志收集

我们会把项目输出的日志通过Volume都挂载到每台宿主机的固定目录下,并用global模式部署filebeat进行采集,输出到我们的Elastic集群上,然后在ELK平台上查询日志。最近我们也在测试环境尝试Grafana Loki 项目,他和Elastic的原理相反,只索引必要的字段,可以节省大量的机器资源,如果是用来做"distribute grep"的话就很合适。
10.jpg

#监控

监控我们使用了Swarmprom开源项目,监控项比较丰富,覆盖了机器基础指标,容器指标,可以较快的定位问题,当时当容器集群出现宕机等情况时,监控会暂时失效,所以我们在容器集群外也部署了针对机器的基础监控。具体效果如下:
11.jpg

12.jpg

#推广

容器的推广需要业务开发和业务运维的支持,不然很难推动。

推广首先要让开发和运维感受到红利:

* 容器相对于虚拟机更轻量化,可以实现秒级启动。
* 测试、预发布、线上的容器部署配置、环境 完全一致。
* 可以根据 CPU、内存或者QPS和延时快速扩容,提升服务能力。
* 服务crash会自动启动,自带高可用。

这四个特性的组合,可以给业务带来更大的灵活度和更低的计算成本。

我们团队是把这个容器平台当成一个产品来运作,业务开发就是我们的用户。

在推进容器化的过程中,我们还会做如下的事情:

* 通过培训让开发了解我们的产品优势(对比虚拟机)。
* 提供使用文档、接入文档等使得产品的易用度增加。
* 在迁移时给予开发更高优先级的支持。
* 资源尽量都加入容器集群,停止并减少虚拟机的供给。

#总结

从传统的虚拟机架构到现在的基于云原生的容器云架构,带来了秒级部署、秒级扩缩容、简化了CI/CD 流程、提供Service Mesh微服务治理能力。

如果按虚拟机时代运维人肉调度服务,人肉管理资源,在新虚拟机部署一个新应用或者扩容一个应用的时间在10分钟以上,和现在的按秒计算时间是质的变化,这是招再多的业务运维人员也达不到的,无形中省去了很多人力成本。

通过容器云的落地,我们得到了一个面向服务的平台,把机器资源抽象,屏蔽了和发布无关的机器细节、部署细节,开发不用再了解自己的应用在哪一台物理机上面。运维也可以从茫茫多的管理表格中解脱出来,只需要关注集群利用率,添加机器资源即可。这样有利于公司DevOps的推行,提高开发效率和开发个体的创造力不再被运维限制,大大提升团队生产力。

接下来,我们还会根据自身的需求迭代服务治理、容器编排的功能,把管理集群的常规操作平台化,尽量做到日常操作可以不登录物理机去操作。

原文链接:房多多容器化和容器云实践(作者:王开)

Docker Swarm 在持续集成测试中的应用

Andy_Lee 发表了文章 • 0 个评论 • 1124 次浏览 • 2018-10-21 16:10 • 来自相关话题

#背景 敏捷(Agile)模式被广泛应用,测试显得尤为重要。由于需要频繁发布新的版本,我们需要更加频繁的执行测试用例,以确保没有新的 bug 被引入到版本中。 一个完整的测试流程所需要占用的时间和资源也不可忽视,包括 ...查看全部
#背景

敏捷(Agile)模式被广泛应用,测试显得尤为重要。由于需要频繁发布新的版本,我们需要更加频繁的执行测试用例,以确保没有新的 bug 被引入到版本中。

一个完整的测试流程所需要占用的时间和资源也不可忽视,包括对测试结果的分析都要占用大量的资源。如何在更短时间内,提供完整、全面的测试以保证质量,是我们急于解决的问题,也是保证敏捷开发能顺利进行的关键。

Jenkins 实现了无人值守的测试流程,开发结束后,一旦在测试环境部署成功,下游的测试任务就会即刻执行。

Jenkins 的应用在一定程度上节省了人力资源,而 Docker 技术可以实现容器 (Container) 快速的拓展,从而节省了大量的设备资源和时间,快速的完成测试。这在 Jenkins Pipeline(代码流水线管理)中是非常重要的一个环节,如图 1 所示:
1.png

图 1. Jenkins Pipeline

本文主要介绍如何利用 Docker Swarm 集群功能和 Selenium Grid 脚本分发功能,来搭建一个可以动态扩容的 Selenium 自动化脚本执行环境。相比于用真实的机器作为 Selenium 自动化脚本执行环境,使用此套环境可以极大的减少对执行环境的维护工作,比如各种浏览器类型的管理和版本的管理。也能极大的减少对脚本执行环境的物质投入,节省各类资源。
#搭建 Docker Swarm 集群

##Swarm 简介

Swarm 是 Docker 官方提供的一款集群管理工具,用来管理 Docker 集群,它将若干台 Docker 主机抽象为一个整体,并且通过一个入口统一管理这些 Docker 主机上的各种 Docker 资源。

Swarm 只是一个调度器(Scheduler)加路由器(Router),Swarm 自己不运行容器,它只是接受 Docker 客户端发送过来的请求,调度适合的节点来运行容器,这意味着,即使 Swarm 由于某些原因挂掉了,集群中的节点也会照常运行,当 Swarm 重新恢复运行之后,它会收集重建集群信息。

Swarm 和 Kubernetes 比较类似,但是更加轻,具有的功能也较 Kubernetes 更少一些。
##环境准备

为了搭建 Docker Swarm 集群环境,我在示例中准备了两台机器。一台作为 manager 节点,同时也作为一个 worker 节点,另一台只作为一个 worker 节点。

这里假设我们的两个机器 IP 信息如下:

* M1:10.13.181.1
* M2:10.13.181.2

Docker Engine 从 V1.12.0 版本开始,原生集成了 Docker Swarm,所以只要在每台机器上安装 Docker,就可以直接使用 Docker Swarm。在这里,关于 Docker 的安装不再详细介绍,请按照官方 Docker Swarm 文档进行安装。安装完成后,在每台机器上将 Docker 服务启动。

提示:

注意:最好关闭机器上的防火墙,否则可能会出现 Swarm 集群网络连接问题。

关闭防火墙的命令:systemctl stop firewalld.service

禁止防火墙开机启动命令:systemctl disable firewalld.service
##步骤

1、创建管理节点。

我们将机器 M1 作为 manager 节点,在这台机器上执行命令来初始化集群环境。命令如下:
sudo docker swarm init --advertise-addr 10.13.181.1

执行此命令后,会返回一个用于加入集群的令牌(Token),以便其他 worker 加入此集群。

清单 1. 加入集群令牌示例:
docker swarm join --token SWMTKN-1-5p3kzxhsvlqonst5wr02hdo185kcpdajcu9omy4z5dpmlsyrzj-
3phtv1qkfdly2kchzxh0h1xft 10.13.181.1:2377

如果想再次获取加入集群的命令,可以通过执行以下命令获取:
sudo docker swarm join-token worker

2、将机器 M1 也作为 worker 节点添加到集群。

在 manager 节点机器上运行清单 1 的命令,即可将机器 M1 也作为 worker 加入 swarm 集群当中。

3、将另一台机器 M2 作为 worker 节点添加到集群。

在机器 M2 上执行上述清单 1 中的命令,即可实现 M2 加入集群的功能。

4、运行如下命令创建集群网络:
sudo docker network create -d overlay seleniumnet

这里,seleniumnet 即是我们所创建的集群网络名称。

5、在新建的集群网络上创建 Selenium Grid 服务。

a. 创建 Selenium Grid Hub 服务。基于集群网络 seleniumnet,将 4444 端口映射到集群的 4444 端口,将 timeout 时间设置为 120 秒,可以增大或减少 timeout 时间,如清单 2 所示。

清单 2. 创建 Selenium Grid Hub 服务:
sudo docker service create --name selenium-hub --network seleniumnet -p 4444:4444 -e 
GRID_TIMEOUT=120 selenium/hub

b. 创建 Selenium Grid Firefox 节点服务并连接到刚创建 Hub 服务。如清单 3 所示。

清单 3. 创建 Selenium Grid Firefox 节点服务:
sudo docker service create \
--name node-firefox \
--replicas 5 \
-p 7900:5900 \
--network seleniumnet \
-e HUB_PORT_4444_TCP_ADDR=selenium-hub \
-e HUB_PORT_4444_TCP_PORT=4444 \
selenium/node-firefox-debug bash -c 'SE_OPTS="-host $HOSTNAME" /opt/bin/entry_point.sh'

参数说明:

-p: 7900:5900 将 Docker 内部 VNC5900 暴露到宿主机的 7900 端口,使得用户可以通过 VNC 从外面监控 Docker 内部的执行情况。

c. 创建 Selenium Grid Chrome Node 服务并连接到刚创建 Hub 服务。如清单 4 所示。

清单 4. 创建节点服务:
sudo docker service create \
--name node-chrome \
--replicas 3 \
-p 7901:5900 \
--network seleniumnet \
-e HUB_PORT_4444_TCP_ADDR=selenium-hub \
-e HUB_PORT_4444_TCP_PORT=4444 \
selenium/node-chrome-debug bash -c 'SE_OPTS="-host $HOSTNAME"
/opt/bin/entry_point.sh'

参数说明:

-p: 7901:5900 将 Docker 内部 VNC5900 暴露到宿主机的 7901 端口,使得用户可以通过 VNC 从外面监控 Docker 内部的执行情况。

6、检查环境搭建是否成功。在机器 M1 上执行以下命令,查看每个服务是否启动成功:
sudo docker service ls

可以看到 Selenium Hub 和 Firefox 节点、Chrome 节点都已经成功启动。Firefox 的节点副本是 5,Chrome 的节点副本是 3,如图 2 所示。
2.png

图 2. Docker 服务清单

我们再通过任意一台机器的 IP 加 4444 端口来打开 Selenium Hub URL 来查看已启动的 Firefox 和 Chrome 节点是否已经成功挂载到 Hub 节点上,如图 3 所示。

Hub url: 10.13.181.1:4444
image003.png

图 3. Selenium Hub 的界面图

从图 3 可以看出,5 个 Firefox 节点和 3 个 Chrome 节点都已经成功挂载到 Hub 节点上。说明此时 Docker Swarm 环境里已经提供了 5 个 Firefox 节点和 3 个 Chrome 节点可以用来执行 Selenium 自动化测试脚本。
##扩容方法

用户可以根据脚本执行数量,随时动态的扩容各个节点的数量,提高自动化脚本的执行效率,例如我们需要 10 个可以运行 Firefox 浏览器的 Container,对应的命令如下:
sudo docker service scale node-firefox=10

#在 Docker Swarm 运行 Jenkins Job

用户在 Docker Swarm 中运行 Jenkins Job,并不需要在 Jenkins 做多余的配置,而是需要在对应的自动化脚本中调用 Selenium Hub,从而以远程的方式调用 WebDriver。这样就实现了在 Docker Container 中运行 Selenium 脚本。

以本文中的场景为例,只需要在自动化脚本中调用远程 Selenium Hub 即可,如下所示:
http://9.111.139.104:4444/wd/hub

#在 Selenium Grid 中运行自动化脚本

##基本概念

Selenium Grid,用于分布式自动化测试,也就是说一套 Selenium 代码可在不同的环境上运行,这样做可以方便的将应用运行在 Docker 所提供的不同 Container 中。

Selenium Grid 有两个概念:

* Hub:主节点,你可以看作总调度中心。
* Node:分支节点,你可以看作是真正执行任务的 worker。

也就是说在 Selenium Grid 中只能有一个主 Hub,但可以在本地或远程建立 N 多个分支节点,测试脚本指向主 Hub,由主 Hub 分配给本地/远程节点运行测试用例。
##实现方式

要实现在 Selenium Grid 中运行自动化脚本,首先我们要创建一个 remote driver 的对象,可以通过图 4 源码实现,截图中所对应的输入参数 selhub 是 Selenium hub 的 URL:
http://9.111.139.104:4444/wd/hub

image004.png

图 4. 自动化脚本的代码截图

通过调用上述的 driver,就可以实现将自动化脚本运行在 Docker Container 中。
#结束语

在持续集成测试中,将测试部署到 Docker Swarm 中,通过 Selenium Grid 自动分配执行测试的节点,可以提升测试效率,增大测试的范围,在快速迭代中能够更好的保证所交付的产品质量,节省测试资源。

原文链接:https://www.ibm.com/developerworks/cn/devops/d-docker-swarm-ci-test-application/index.html

容器中的MySQL迁移RDS,会话却“爆了”

尼古拉斯 发表了文章 • 0 个评论 • 2253 次浏览 • 2018-05-03 12:37 • 来自相关话题

新特性初探:Docker for Mac喜迎Kubernetes支持能力

hokingyang 发表了文章 • 0 个评论 • 9709 次浏览 • 2018-01-10 10:01 • 来自相关话题

【编者的话】很高兴内置支持Docker Swarm和Kubernetes的Mac版Docker发布了,本文将会回顾一下此工具简史,然后看看新功能的第一印象。 #为什么对开发者很重要? ...查看全部
【编者的话】很高兴内置支持Docker Swarm和Kubernetes的Mac版Docker发布了,本文将会回顾一下此工具简史,然后看看新功能的第一印象。
1.png

#为什么对开发者很重要?
Docker CE(简称Docker)是一款易用简便的容器工具,是给用户带来自主和硬件无关性体验的软件。Mac版Docker并不是从一开始就支持Kubernetes,我们看看它的简史:

Docker发端于DotCloud公司,一开始并不支持Windows和Mac,只能运行在Linux上。
#Docker简史
##虚机
最开始,如果Mac或者Linux用户想使用容器技术,就需要在Linux主机中安装如VirtualBox或者VMWare Workstation/Player之类的虚拟机工具,并设置共享目录。为了使用统一CLI工具,用户不得不采用Hashicorp公司的Vagrant

使用场景:这种方式都是过时的技术,并不建议采用。
##Docker Machine
Docker Machine是进化的第二步,采用boot2docker镜像在本地或者远程环境部署虚机,并提供可写磁盘空间,也是朝易用性迈出的一大步。一旦基于SSL认证的VM生成,Docker客户端就可以通过TCP/IP工具访问它,可以同时支持多个Docker版本构成的集群。

优点:

  • 同一主机支持多个容器后端
  • 只支持Linux
  • 使用boot2docker镜像
  • 模块化支持各家云提供商插件
缺点:
  • 命令行方式操作
  • 不支持Windows和Mac
使用场景:使用Windows 7或者Windows 10 Home,需要在本地运行一套集群,或者需要在云端运维一套集群。##Docker for Mac/WindowsDocker Machine需要太多手工操作(通过docker-machine env),为了采用TLS,有时还需要重建。Docker for Mac/Windows(简称DfM)本着造福广大使用者的初衷,内建UI和菜单支持,推出了功能有限的beta版本,刚开始主要是Twitter使用它。优点:
  • 安装简便
  • 自动配置命令行
  • 图形化界面配置
  • 一键启停作业
缺点:
  • 共享卷时性能很差
  • 高耗能降低电池使用时间
  • 支持Windows 10 pro或者enterprise
使用场景:可用,但是需要本地安装Docker Swarm或者Kubernetes。##MinikubeMinikube跟docker-machine非常类似,也依靠boot2docker,初衷是创建内含可用于开发的Docker主机的单节点Kubernetes集群。
2.png
Mac上的minikube输出案例如下:
$ minikube startStarting local Kubernetes v1.8.0 cluster...  Starting VM...  Getting VM IP address...  Moving files into cluster...  Setting up certs...  Connecting to cluster...  Setting up kubeconfig...  Starting cluster components...  Kubectl is now configured to use the cluster.  Loading cached images from config file.
优点:
  • 本地环境易于访问
  • Kubernetes可用
缺点:
  • Kubernetes在空闲时耗费大量电力
  • 感觉还是跟docker-machine很类似
  • 内置Docker版本严重滞后
  • 有些功能尚不支持,例如RBAC(role-based authentication control)
  • 需要使用minikube start/stop
使用场景:需要本地Kubernetes场景但是不必关注Docker版本。以上总结了各阶段优缺点,下面看看最新内置Kubernetes功能的DfM第一印象。#第一印象以下是我更新DfM后,使用它得到的第一印象。##开始需要Docker 17.12或者更高版本以获得Kubernetes支持,然后就是通过UI界面花几分钟下载新版本。
3.png
##上下文和命名空间如果以前安装了minikube,需要转换到DfM上下文,否则kubectl会挂起。
kubectl config use-context docker-for-desktop

如果发现有太多输出内容,Kubernetes社区有一个叫kubectx的工具可以改善输出状况。

Docker Swarm和Kubernetes之间一个不同是命名空间的支持。默认地,Kubernetes生态容器运行在称为system的隐藏命名空间,可以通过以下命令查看`kubectl get all --all-namespaces`:
4.png
输出有很多默认运行的服务,和Docker Swarm一样,区别是对用户隐藏,运行在几个固定二进制代码中,而不是分散运行的服务。以下命令可以查看Kubernetes版本:
$kubectl versionClient Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.2", GitCommit:"bdaeafa71f6c7c04636251031f93464384d54963", GitTreeState:"clean", BuildDate:"2017-10-24T19:48:57Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"darwin/amd64"}  Server Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.2", GitCommit:"bdaeafa71f6c7c04636251031f93464384d54963", GitTreeState:"clean", BuildDate:"2017-10-24T19:38:10Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} 
看起来是1.8.2版本,尽管不是最新版本但也包含了所有重要功能。##整合DockerDocker希望Kubernetes更加易用,因此整合了Docker stacks和Kubernetes原生部署服务。Kubernetes是很容易扩展的,Docker使用Custom Resource Definitions (CRDs)引入了对“栈(stack)”概念的支持. 可以验证如下:
$kubectl get stacksNo resources found.$ kubectl get crdNAME                        AGE  stacks.compose.docker.com   24d
看看对compose文件的效果:
$ docker stack deploy prometheus -c ./docker-compose.yml Stack prometheus was created  Waiting for the stack to be stable and running...   - Service exporter has one container running - Service grafana has one container running - Service prom has one container runningStack prometheus is stable and running 
CRD验证:
$ kubectl get stacksNAME         AGE  prometheus   1m
创建了几个Pods:
$kubectl get pods  NAME                        READY     STATUS             RESTARTS   AGE  exporter-66c7bbfcc6-r5sq4   1/1       Running            0          2m  grafana-7c5f5f6b75-rfgzp    1/1       Running            0          2m  prom-76b4f584f7-qckc9       0/1       CrashLoopBackOff   4          2m
Prometheus有一个bug,可以用这个命令debug:$kubectl logs pod/prom-76b4f584f7-qckc9。如果仍然使用docker-compose开发和生产,现在可以直接转向Kubernetes了。##内置工作流我们期望内置工作流能够实现:
  • kubectl apply 支持YAML
  • helm
  • RBAC激活

下面部署OpenFaaS-Serverless功能(采用Docker和Kubernetes实现起来很简单)。
$ mkdir -p go/src/github.com/openfaas/ && \
cd go/src/github.com/openfaas/ && \
git clone https://github.com/openfaas/faas-netes && \
cd faas-netes && \
kubectl apply -f ./yaml


如果碰到命名空间错误,可以在faas-netes目录下执行kubectl apply -f ./namespaces.yml ,然后再尝试一遍。



OpenFaaS会在localhost:31112启动图形界面,并启用了RBAC和两个命名空间(openfaas / openfaas-fn),输出如下:
service "alertmanager" created  
deployment "alertmanager" created
configmap "alertmanager-config" configured
service "faas-netesd" created
deployment "faas-netesd" created
deployment "gateway" created
service "gateway" created
service "nats" created
deployment "nats" created
service "prometheus" created
deployment "prometheus" created
configmap "prometheus-config" configured
deployment "queue-worker" created
serviceaccount "faas-controller" configured
role "faas-controller" configured
rolebinding "faas-controller-fn" configured

服务也创建完毕。验证如下:
$ kubectl get all --namespace openfaas

然后打开UI,部署一个应用功能:

http://localhost:31112
5.png

然后选择Figlet - figlet是Linux下二进制文件可以产生ASCII 文本logos。
6.png

查看产生的Function/Pod:
$ kubectl get all --namespace openfaas-fn
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
deploy/figlet 1 1 1 1 8m

NAME DESIRED CURRENT READY AGE
rs/figlet-676c995d66 1 1 1 8m

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
deploy/figlet 1 1 1 1 8m

NAME DESIRED CURRENT READY AGE
rs/figlet-676c995d66 1 1 1 8m

NAME READY STATUS RESTARTS AGE
po/figlet-676c995d66-rqjpn 1/1 Running 0 8m

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
svc/figlet ClusterIP 10.101.45.157 8080/TCP 8m


相对于Docker Swarm,Kubernetes使用更多对象形成服务。



激活服务查看结果:
7.png

作业运行很顺畅,而且简单易用。对于社区维护和内置OpenFaaS整合很有帮助。

之前提过需要helm(一个类似OpenFaaS的分布式软件管理器),在Docker Swarm中没有类似的概念。

写这篇博客之前,我在Tweet上看有消息说helm也已经被支持了。

Just setup #kubernetes on the @Docker for Mac beta and did a #helm install... this is so so great!!
Adnan Abdulhussein (@prydonius) December 15, 2017

#总结
其实不仅是简单的DfM整合了“栈”,应该说在现有工具外层实现了简单化,提高了速度,更加易用。相信Docker Swarm用户都会使用这种整合,而且迁移到Kubernetes。



Docker Swarm 已死?作为Docker Captains用户组成员,我并没有更多内部消息,但是因为Docker Swarm仍然有很多用户,因此仍然会被支持。例如:最原始可以运行在容器内的Swarm仍然被Docker's UCP product支持。



如果读了developer reactions on Hacker News,可以看到Swarm仍然有很多粉丝,如果Kubernetes想吸引他们,那么on-prem安装维护过程需要提高。

因此我的第一印象总结如下:很多新功能令人振奋,尤其是对DfM的更新以及内部新元素使得它看起来更像一个LinuxKit了。
##推荐阅读
强烈推荐阅读Docker Swarm和Kubernetes不同,推荐如下博客:

* Blog - What you need to know: Docker Swarm and Kubernetes
* Read the docs on the Docker and Kubernetes integration
* Star: Award-winning OpenFaaS - serverless functions you can run yourself on Kubernetes or Docker Swarm

原文链接:First impressions: Docker for Mac with Kubernetes(翻译:杨峰)

Swarm的进化和在阿里的大规模应用实践

尼古拉斯 发表了文章 • 0 个评论 • 3191 次浏览 • 2017-10-12 18:34 • 来自相关话题

【编者的话】目前在容器编排领域,Kubernetes、Mesos以及Swarm呈现“三分天下”的格局,各自都有着不同的应用场景。短期内,很难看到“一统天下”的局面,本文,来自阿里云高级专家陈萌辉将带你了解阿里内部在推行容器化过程中的一些着力点,同时,他将深刻剖 ...查看全部
【编者的话】目前在容器编排领域,Kubernetes、Mesos以及Swarm呈现“三分天下”的格局,各自都有着不同的应用场景。短期内,很难看到“一统天下”的局面,本文,来自阿里云高级专家陈萌辉将带你了解阿里内部在推行容器化过程中的一些着力点,同时,他将深刻剖析Swarm的进化史以及在阿里云的大规模应用,最后,他给出三个案例,供大家参考。

阿里从前年开始就已经在集团内部大规模地推行容器化和运用Swarm来做应用的发布、集群管理等事情。特别值得注意的是去年,阿里云跟Docker达成了一项深度合作的协议,从中我们不难窥探阿里的容器战略。本文将从三个方面阐述“Swarm的进化和大规模应用”,第一, Swarm架构;第二,Swarm Mode的编排;第三是Swarm在阿里的应用。
#Swarm架构
1.jpg

图1 Swarm架构

我们先看一下Swarm是什么?Swarm,是Docker官方推出的,它的特点就是跟Docker本身有很好的集成,另外,它也是一个非常简单易用的工具,所以目前吸引了很多开发者在用。

Swarm是Docker公司继Docker Engine之后推出的很重要的集群管理系统和容器编排与调度系统。架构底层是集群的机器资源,可以是一些物理机也可以是一些虚拟机,上面经过Swarm这一层把容器调度和部署到这些机器上去,它对外提供跟Docker类似的API。

具体来看,Swarm的框架分成三块,第一块是Engine,第二是Manager,第三是KV store。它有几个特点,第一依赖外部存储来完成节点发现并保证一致性;第二,Manager只跟Daemon通信,不跟Agent通信;第三,Manager可以有多副本,这是为高可用设计的,采用一主多热备模式,所有manager都同时连接所有Daemon,备转发请求至主,另外,它依赖外部KV选主。
##API
Swarm提供的API,主要是有这么几类:

* 集群类:info events
* 容器类:get/list、create、start/stop等
* 镜像类:get/list、push、pull、tag等
* 数据卷类:get/list、create、delete
* 网络类:get/list、create、delete等

##调度
资源维度层面有三个: CPU 、Memory、 端口,CPU / Memory支持超卖;调度策略有两种:spread / binpack,另外,它不支持优先级、抢占。

它比较有特点的一些功能有两个,一个是叫节点约束,约束可以有两种类型,比如说你可以约束我这个节点是哪一个,你可以给节点去一个名字或者打一个标签什么的,另外一个可以通过打标签去选择一种机器,你在部署的时候,可以指定这些容器部署到哪些机器上去。

节点约束:

* 节点名:constraint:node==XXX
* 标签:constraint:key==value

亲和性也有两种,一种是image,一种是service,比如我有一个应用镜像很大,我不希望它在集群各个地方去部署,我希望他部署下来已经下载镜像的地方,这样的话可以减少一些启动的时间和下载的过程,你可以说我这个服务不是跟某个镜像做亲和,也可以跟某个服务做亲和。

亲和性:

* 镜像:affinity:image==foo
* 服务:affinity:service==foo

总结一下Swarm这个产品,Swarm整体来说有几个特点,第一个是部署简捷,只有三个模块,外部的依赖只有KV Store和Docker Daemon这两个,所有组件都容器化。第二高效友好的用户交互,高度兼容Docker Engine API,可直接使用Docker Client。第三是灵活的约束与亲和性描述,可以在一定程度上弥补调度策略的不足。

同时,我们也看到它有一些不足的地方,首先一个不足的地方就是它是容器级别的API,所有的API都是针对单个容器的,抽象层次较低。其次,响应式设计,不方便执行常驻后台的操作,它在内存中不保存任何的状态,所有的状态都是从Docker上统计过来的。有一个好处,它一旦挂掉了,能够很方便地恢复状态,但也有一些坏处,比如你要跑一个离线的任务,就不太好做。除此之外,它依赖定期同步跟Docker Engine保持一致状态。
#Swarm Mode
针对Swarm这个产品的一些不足,从1.12版本开始,Docker就提供了Swarm Mode的功能,这个功能是将Swarm的集群管理、容器调度功能集成进Docker Engine,并且提供Service级别抽象和自带的负载均衡,它从容器级别的调度器进化到了服务级别的调度器。
##架构
2.jpg

图2 Swarm Mode架构

它的架构比Swarm更简单一些,首先就是它没有任何的外部依赖,只要你装 Docker Engine,它就可以构成一个容器集群,DockerDaemon本身会兼Engine、Manager、Agent三职。Managers之间通过RAFT协议组成分布式强一致性KV Store,Manager与Worker的Daemon不通信。

同时,它也是有高可用设计的,Manager数量需要大于等于3才可以实现高可用,它也是一主多热备,另外也可以动态添加/删除Manager,如果有的机器宕机或者挂掉了,你不需要把这个机器再恢复起来,很多系统对Manager控制器的机器是有依赖的。如果一旦挂掉了你只能把它修好之后再上来,但是这个是不需要的,你可以任意在里面编程。这样他会通过RAFT协议把原来集群状态信息统一到Manager上去,这样有实现了高可用。
##Swarm Mode API
在刚才Swarm的API之上,多提供了两类的API:

集群管理类:

* init、join、leave
* token

服务类:

* get/list
* create、delete、update
* inspect、ps

同时,Swarm的API有两个特点,它分两类,一类是像Swarm、Service、Network类,只有Manager能处理的。还有一类容器、镜像、数据卷类,所有节点都能处理。另外它的API还是高度兼容旧的API,你可以拿低版本的去访问Swarm mode的集群。
##Service

我们来看一下Swarm Service的概念,它提供了三级的概念:

* Service:相同功能的一组容器
* Task:任务调度单元,由Manager生成,同步至Worker
* Container:Task落地

另外,还提供Rolling Update功能。

在Swarm mode里面Service分为两类,一类是有Replicated Service,一类是Global Service。

Replicated Service:

* 用户指定副本数
* Reconciled:自动确保副本数
* constraint

node.id node.hostname:

* node.role
* node.labels engine.labels

Global Service:

* 每个节点有且仅有一个容器
* 添加加点时自动扩展
* 可附加constraint

网络模型方面,支持overlay网络,同一网络内,服务名、容器名可解析;一个服务一个网络;服务发现支持不同服务可加入同一个网络。
##Routing Mesh
下面我们看一下Swarm自带的负载均衡,它取的名字叫做Routing Mesh,Service自带的负载均衡是基于LVS,主要有两种模式,

VIP模式:每个服务一个VIP,通过LVS实现;服务名解析至VIP;

DNS模式:服务名解析至容器IP,RoundRobin方式。另外,服务发生变化时,自动调整后端。

总结一下Swarm Mode的产品,第一个它是无任何依赖,可以安装Engine+一个命令,无中心架构。第二个它可以部署高可用服务,你可以在集群这边进行访问的,比如说你的容器只布在了三台机器,这个集群所有的机器都可以访问到这个服务,这样的话就很容易做成高可用的。再一个Secure by default,自带证书颁发、更新功能,Manager与Worker之间通过SSL连接。

当然它也有一些不足的地方,第一个只有Service级抽象,Stack级抽象仍无API,另外,部署有状态服务比较复杂。第二,Service API有很多容器特性不支持,如host network、host pid、privileged等。还有一个缺点,它无法自举,是需要手工init的。
#Swarm在阿里内部的应用
上面介绍了Docker Swarm的产品相关的东西。下面我就来介绍一下Swarm在阿里内部的应用,这个也是大家更关心的一个地方,有几个方面。第一是阿里内部的容器化,可能大家都知道,阿里内部有一支非常强大的运维团队,除非查问题的时候,一般开发人员是不接触现代的机器的,所有的应用部署、升级这些都是运维人员来做的。强大的运维团队也导致了一些问题,它的应用的部署和升级往往是很个性化的,可能这个运维人员他在支持这个应用的时候,通过写一些脚本或者用一些工具,实现业务的部署的自动化,而另外的运维人员运用另外的工具和另外的脚本,导致了很多应用的升级部署不是一个标准化的方式。这样的话,比如说这个人员他转岗了,新来的人首先要去熟悉那个部署的工具,这个运维任务比较大,所以应该是从去年、前年阿里内部开始推容器化,由Swarm来统一管理我们的集群,应用的话就是容器化之后,由Swarm去统一做部署,这样的话就会形成一个跟业务无关的统一的部署平台。运维人员不再去关心应用如何地去部署,他只要关心把这个应用部署上去就可以了,所有的应用都是一样的方式,即使有新的人接替他学起来也非常地方便。
3.jpg

图3 阿里云容器服务整体架构

另外是阿里云的专有云输出,因为专有云这个东西一旦部署到用户的机房之后,你升级就变得非常麻烦,有了容器之后,它的镜像的管理和升级就非常方便了。还有一个优点,它可以实现管控部署的资源优化,因为原来可能所有的管控都是独占机器的,这样的话比如说你布很多服务就会占很多机器,有了容器之后管控就可以共享机器了,减少了管控所占的资源,提高了用户能使用的资源的数量。

第二是阿里云的容器服务,这是我们在阿里云公有云上推出的一款产品,作用是帮用户管理集群和部署应用,当然还提供更多高级别的服务。

第三是阿里云高性能计算 HPC也会用到容器,在高计算领域,它的安装很复杂、很麻烦,经常比如说你拿到一个带显卡的机器,你在上面部署基础的应用,可能得花掉你一周的时间,如果你的应用是容器化的,这个事情就可以放到容器里面去,你只要关心自己的应用就可以了,可以大大地提高应用部署的效率。

下面重点介绍一下阿里云容器服务的一些特性,我们先看一下整体的架构,整体来说,阿里云容器服务是一个集群托管的模式,机器是用户的,但是管控是我们提供的。现在相当于我们帮用户管理他的机器,我们通过某一些界面化、某一些API的信息让用户去管理集群以及管理他的应用。

用户的机器下面会装Engine、下面会跑容器,我们这边的管控提供一个控制台,提供集群的创建和扩容这样的功能,然后提供服务、注册和发现的功能,提供应用生命周期管理和使用调度的功能。同时我们还会把很多阿里云上的服务都集成进来,比如说我们集成了SLB、ECS等功能,达到的目标让用户只关心我的应用,而不需要关心底下的机器。

我们可以看一下我们提供的功能,从四个角度讲。

第一个是集群的管理,这是最基本的功能,我们可以帮用户一键创建出一个容器集群,同时支持公有云、专有云、混合云以及敏捷版,公有云包括GPU的机器,专有云是部署在用户机房的,混合云就是你可以一部分集群管控在我们的机房,但是真正的用户机器在你自己的机房。你可以实现应用跨云的统一部署。另外还支持bare metal敏捷版。

第二是镜像服务,这是对容器化很重要的服务,我们支持公有和私有的仓库,你可以有自己的私有仓库,同时支持DockerHub的加速,我们提供这个加速的功能可以让你像访问国内的机器一样,另外可以连接第三方代码库,这样,其实你可以当成CICD系统的最重要的环节,你可以从代码到最终生成镜像,甚至到最后部署把它全自动打通。

第三是应用生命周期的管理,支持Swarm和Swarm Mode两种模式。

同时支持Rolling Update、蓝绿发布、离线与定时任务。

最后是微服务的支持,微服务它不是为容器而生,但是有了容器之后它的实现会变得更简单一些,为了微服务的支持,我们提供了一些很重要的基础的功能。包括服务发现、负载均衡、弹性伸缩、集成监控与日志、集成共享存储。

这是在阿里云上部署一个nginx应用的一个例子,这是用的3.0的模板,用Engine来部署,它可以通过8080端口来访问到。
4.jpg

图4 负载均衡案例
version: ”3.0”  #支持v1 v2 v3 compose模板
services:
nginx:
image: nginx:latest
deploy:
mode: replicated
replicas: 3
ports:
- 8080:80
labels:
aliyun.lb.port_8080`: tcp://slbtest:8080 #负载均衡
aliyun.log_store_dbstdout: stdout #日志收集
aliyun.log_store_varlog: /var/log/*.log
volumes:
- 'website:/usr/share/nginx/html'
volumes:
website:
driver: ossfs #共享存储数据卷,支持oss、nas
driver_opts:
bucket: acs-sample

自动扩容的事例,简单来说,你只要声明一下,当CPU超过70%了就扩展出两个容器来,我们的做法是通过监控平台把数据收集上去,之后,如果当它超过了70%的时候会调用集群管理的API,给它扩出容器来,同时会把负载均衡的后端再挂到新的容器上,这样就实现了自动扩容。
5.jpg

图5 自动扩容案例

声明式自动扩容
aliyun.auto_scaling.max_cpu: 70 
aliyun.auto_scaling.step: 2

监控插件

* 输入:Nagios、Apache、Docker、UDP……
* 输出:InfluxDB、Prometheus、Kafka

蓝绿发布的事例,如图6,蓝色的应用要进行升级,怎么做呢?首先部署一个新的应用,这两个是同时在线的,它会通过SLB给它分流量,比如80%和20%,之后做验证,验证之后,发布完成,系统就会把原来老的删掉。
6.jpg

图6 蓝绿发布案例

机器学习案例,假如你的集群是稳步的,有GPU机器和非GPU机器,你可以在你的Service里面注明需要两个GPU,系统会把你调度到有GPU的集群,同时把你的应用绑到GPU卡上去。
7.jpg

图7 机器学习案例
version: '2'
services:
inception:
image: acs_sample/inception:demo
volumes:
- inception_model/inception_model
labels:
- aliyun.gpu=2
ports:
- "9000:9000"
volumes:
inception_model:
driver: nas


原文链接:Swarm的进化和大规模应用

几种常见的微服务架构方案——ZeroC IceGrid、Spring Cloud、基于消息队列、Docker Swarm

尼古拉斯 发表了文章 • 0 个评论 • 3230 次浏览 • 2017-09-29 19:08 • 来自相关话题

微服务架构是当前很热门的一个概念,它不是凭空产生的,是技术发展的必然结果。虽然微服务架构没有公认的技术标准和规范草案,但业界已经有一些很有影响力的开源微服务架构平台,架构师可以根据公司的技术实力并结合项目的特点来选择某个合适的微服务架构平台,以此稳妥地实施项目 ...查看全部
微服务架构是当前很热门的一个概念,它不是凭空产生的,是技术发展的必然结果。虽然微服务架构没有公认的技术标准和规范草案,但业界已经有一些很有影响力的开源微服务架构平台,架构师可以根据公司的技术实力并结合项目的特点来选择某个合适的微服务架构平台,以此稳妥地实施项目的微服务化改造或开发进程。

本文盘点了四种常用的微服务架构方案,分别是ZeroC IceGrid、Spring Cloud、基于消息队列与Docker Swarm。
#ZeroC IceGrid微服务架构

ZeroC IceGrid作为一种微服务架构,它基于RPC框架发展而来,具有良好的性能与分布式能力,如下所示是它的整体示意图。
1.jpg

IceGrid具备微服务架构的如下明显特征。

首先,微服务架构需要一个集中的服务注册中心,以及某种服务发现机制。IceGrid服务注册采用XML文件来定义,其服务注册中心就是Ice Registry,这是一个独立的进程,并且提供了HA高可用机制;对应的服务发现机制就是命名查询服务,即LocatorService提供的API,可以根据服务名查询对应的服务实例可用地址。

其次,微服务架构中的每个微服务通常会被部署为一个独立的进程,当无状态服务时,一般会由多个独立进程提供服务。对应在IceGrid里,一个IceBox就是一个单独的进程,当一个IceBox只封装一个Servant时,就是一个典型的微服务进程了。

然后,微服务架构中通常都需要内嵌某种负载均衡机制。在 IceGrid 里是通过客户端API内嵌的负载均衡算法实现的,相对于采用中间件Proxy转发流量的方式,IceGrid的做法更加高效,但增加了平台开发的工作量与难度,因为采用各种语言的客户端都需要实现一遍负载均衡的算法逻辑。

最后,一个好的微服务架构平台应该简化和方便应用部署。我们看到 IceGrid提供了grid.xml来描述与定义一个基于微服务架构的Application,一个命令行工具一键部署这个Application,还提供了发布二进制程序的辅助工具——icepatch2。下图显示icepatch2的工作机制,icepatch2server类似于FTP Sever,用于存放要发布到每个Node上的二进制代码与配置文件,而位于每个Node上的icepatch2client则从icepatch2server上拉取文件,这个过程中采用了压缩传输及差量传输等高级特性,以减少不必要的文件传输过程。客观地评价,在Docker技术之前,icepatch2这套做法还是很先进与完备的,也大大减少了分布式集群下微服务系统的运维工作量。
2.jpg

如果基于IceGrid开发系统,则通常有三种典型的技术方案,下图展示了这三种技术方案。
3.jpg

其中方案一是比较符合传统Java Web项目的一种渐进改造方案,Spring Boot里只有Controller组件而没有数据访问层与Service对象,这些Controller组件通过Ice RPC方式调用部署在IceGrid里的远程的Ice微服务,面向前端包装为REST服务。此方案的整体思路清晰,分工明确。Leader在开源项目中给出了这种方式的一个基本框架以供参考:https://github.com/MyCATApache/mycat-ice。

方案二与方案三则比较适合前端JavaScript能力强的团队,比如很擅长Node.js的团队可以考虑方案二,即用JavaScript来替代Spring Boot实现REST服务。主要做互联网App的系统则可以考虑方案三,浏览器端的JavaScript以HTML5的WebSocket技术与Ice Glacier2直接通信,整体高效敏捷。

IceGrid在3.6版本之后还增加了容器化的运行方式,即Ice Node与Ice Registry可以通过Docker容器的方式启动,这就简化了IceGrid在Linux上的部署。对于用Java编写的Ice微服务架构系统,我们还可以借助Java远程类加载机制,让每台Node自动从某个远程HTTP Server下载指定的Jar包并加载相关的Servant类,从而实现类似Docker Hub的机制。下图显示了前面提到mycat-ice开源项目时给出的具体实现方案。
4.jpg

#Spring Cloud微服务架构

Spring Cloud是基于Spring Boot的一整套实现微服务的框架,因此它只能采用Java语言,这是它与其他几个微服务框架的最明显区别。Spring Cloud是一个包含了很多子项目的整体方案,其中由Netflix开发后来又并入Spring Cloud的Spring Cloud Netflix是Spring Cloud微服务架构的核心项目,即可以简单地认为Spring Cloud微服务架构就是Spring Cloud Netflix,后面我们用Spring Cloud时如果不特意声明,就是指Spring Cloud Netflix。

首先,Spring Cloud中的服务注册中心是Eureka模块,它提供了一个服务注册中心、服务发现的客户端,还有一个简单的管理界面,所有服务使用Eureka的服务发现客户端来将自己注册到Eureka中,如下所示为相关示意图,你会发现它很像之前第4章中的某个图。
5.jpg

那么Spring Cloud是如何解决服务的负载均衡问题的呢?由于Spring Cloud的微服务接口主要是基于REST协议实现的,因此它采用了传统的HTTP Proxy机制。如下图所示,Zuul类似一个Nginx的服务网关,所有客户端请求都通过这个网关来访问后台的服务。
6.jpg

Zuul从Eureka那里获取服务信息,自动完成路由规则的映射,无须手工配置,比如上图中的URL路径/customer/*就被映射到Customer这个微服务上。当Zuul转发请求到某个指定的微服务上时,会采用类似ZeroC IceGrid的客户端负载均衡机制,被称为Ribbon组件,下图给出了Zuul与Eureka的关系及实现服务负载均衡的示意图。
7.jpg

如下所示是Spring Cloud微服务架构平台的全景图。我们看到它很明显地继承了Spring Framework一贯的思路——集大成!
8.jpg

从图中来看,Spring Cloud 微服务架构平台集成了以下一些实际项目开发中常用的技术与功能模块。

基于Spring Security的OAuth模块,解决服务安全问题。

提供组合服务(Composite Services)的能力。

电路断路器 Hystrix,实现对某些关键服务接口的熔断保护功能,如果一个服务没有响应(如超时或者网络连接故障),则Hystrix可以在服务消费方中重定向请求到回退方法(fallback method)。如果服务重复失败,则Hystrix会快速失败(例如直接调用内部的回退方法,不再尝试调用服务),直到服务重新恢复正常。

监控用的Dashboard,可以简化运维相关的开发工作量。

总体来说,Spring Cloud是替代Dubbo的一种好方案,虽然Spring Cloud是基于REST通信接口的微服务架构,而Dubbo以RPC通信为基础。对于性能要求不是很高的Java互联网业务平台,采用Spring Cloud是一个门槛相对较低的解决方案。
#基于消息队列的微服务架构

除了标准的基于RPC通信(以及类RPC的通信如Http Rest、SOAP等)的微服务架构,还有基于消息队列通信的微服务架构,这种架构下的微服务采用发送消息(Publish Message)与监听消息(Subscribe Message)的方式来实现彼此之间的交互。下图是这种微服务架构下各个组件之间的交互示意图,我们看到消息中间件是关键,它负责连通各个微服务与UI组件,担任了整个系统互联互通的重任。
9.jpg

基于消息队列的微服务架构是全异步通信模式的一种设计,各个组件之间没有直接的耦合关系,也不存在服务接口与服务调用的说法,服务之间通过消息来实现彼此的通信与业务流程的驱动,从这点来看,基于消息队列的微服务架构非常接近Actor模型。实际上,分布式的Actor模型也可以算作一种微服务架构,并且在微服务概念产生之前就已经存在很久了。下面是一个购物网站的微服务设计示意图,我们看到它采用了基于消息队列的微服务架构。
10.jpg

网易的蜂巢平台就采用了基于消息队列的微服务架构设计思路,如下图所示,微服务之间通过RabbitMQ传递消息,实现通信。
11.jpg

与上面几种微服务架构相比,基于消息队列的微服务架构并不多,案例也相对较少,更多地体现为一种与业务相关的设计经验,各家有各家的实现方式,缺乏公认的设计思路与参考架构,也没有形成一个知名的开源平台。因此,如果需要实施这种微服务架构,则基本上需要项目组自己从零开始去设计实现一个微服务架构基础平台,其代价是成本高、风险大,因此决策之前需要架构师“接地气”地进行全盘思考与客观评价。
#Docker Swarm微服务架构

Docker Swarm其实是Docker公司“高仿”Google开源的Kubernetes微服务架构平台的一个产品,但一直无法跟上对手的脚步,在业界始终缺乏影响力。2016年发布Docker 1.12时,Docker Swarm就被强行集成到了Docker Engine中而不再作为单独的工具发布了,这类似当年微软推广IE浏览器的做法。不过即使这样,也难以掩盖Docker Swarm还没成名就已经陨落的事实。

Docker Swarm的最初目标是将一些独立的Docker主机变成一个集群,如下图所示,我们通过简单的Docker命令行工具就能创建一个Swarm集群。
12.jpg

后来随着Kubernetes微服务架构平台越来越火,Docker 公司开始努力让Swarm向着Kubernetes的方向靠拢,即变成一个基于容器技术的微服务平台。下面给出了Swarm集群的结构图。
13.jpg

从图中我们看到一个Swarm集群中有两种角色的节点。

Swarm Manager:负责集群的管理、集群状态的维持及调度任务(Task)到工作节点(Swarm Node)上等。

Swarm Node:承载运行在Swarm集群中的容器实例,每个Node主动汇报其上运行的任务(Task)并维持同步状态。

上图中的Docker Compose是官方编排(Orchestration)项目,它提供了一个YAML格式的文件,用于描述一个容器化的分布式应用,并且提供了相应的工具来实现一键部署的功能。下图给出了两节点的Couchbase集群对应的YAML文件定义,此Couchbase集群随后被部署到了Swarm集群中的两个Node节点上。
14.jpg

注意上图左边YAML文件中的Services定义,Swarm manager节点给每个Service分配唯一的DNS名字,因此可以通过最古老又简单的DNS轮询机制来实现服务的发现与负载均衡,这明显借鉴了Kubernetes的做法。
由于Docker Swarm高仿了前辈Kubernetes的设计,而且在微服务架构中并没有太多的影响力,所以我们在此并未做深入介绍。

原文链接:http://www.broadview.com.cn/article/348

Docker 管理工具的选择:Kubernetes 还是 Swarm?

kurtzhong 发表了文章 • 0 个评论 • 29642 次浏览 • 2017-07-31 02:42 • 来自相关话题

【编者的话】选择Kubernetes 或者 Swarm 就像在将 Linux 桌面发行版的范围缩小到两个后选出一个最喜欢的。哪个更满足你的需要如何才是决定因素。 【3 天烧脑式基于Docker的CI/CD实战训练营 | 北京站】本次培 ...查看全部
【编者的话】选择Kubernetes 或者 Swarm 就像在将 Linux 桌面发行版的范围缩小到两个后选出一个最喜欢的。哪个更满足你的需要如何才是决定因素。

【3 天烧脑式基于Docker的CI/CD实战训练营 | 北京站】本次培训围绕基于Docker的CI/CD实战展开,具体内容包括:持续集成与持续交付(CI/CD)概览;持续集成系统介绍;客户端与服务端的 CI/CD 实践;开发流程中引入 CI、CD;Gitlab 和 CI、CD 工具;Gitlab CI、Drone 的使用以及实践经验分享等。

Docker 容器技术已经成为推动云技术发展最重要的技术之一。如果你还没有使用容器技术,那么你很可能很快就会使用到它,不管以什么样的方式。

使用这种技术有两个步骤。首先,你需要理解容器的概念。然后你需要有一个编排工具来处理容器的调度和管理。最终选择谁取决于技术偏好和需求。

Docker是一种高级技术,能给用户带来很多计算方面的优势。这篇入门介绍是该复杂的计算机进程的一个概要。将使用简单直接的方式呈现它的基础知识。

Docker是一个容器的软件平台。容器将一个计算任务 - 或者一系列任务 - 所有需要的东西打包然后在隔离的环境中运行它们。简单来说,容器能为一个软件包提供运行的平台,而不需要一个完整的操作系统的支持。

这个简单的描述让容器听起来就像一个被吹嘘的虚拟机。但是这并不正确。一个VM可以部署很多的服务,并在一个计算机上运行不同的计算进程。然后这个宽泛的解释基本上一样适用于容器,它们的不同点在于部署方式。

例如,这两种方式的一个本质区别是用来运行它们的裸机(bare metal)。VM需要一个宿主计算机,并且必须要能共享它的资源。VM 运行在 hypervisor 上,其充当管理工具的功能。结果,不是所有的计算机都能支持虚拟复制。

这个支持取决与计算机的处理器。这个限制是巨大的。要在一个计算机上运行很多的VM会话或者服务器受到宿主机器资源富裕量的限制。

虚拟机需要依赖于一个安装好的操作系统才能运行。而容器,只需要操作系统的某些部分就能运行。这意味着容器的运行效率更高、资源占用更少,使得它们相较于VM更实用,发挥更好的计算作用。

另外一个重要的差别是VM可以在隔离的环境下运行应用,而容器没有独立运作的能力并因此遭致问题。因为容器没有操作系统或者 hypervisor,它们需要有自己的管理系统。

目前有两个流行的开源技术在这个容器控制领域进行竞争。Docker开发了Swarm,现在将它整合进了 Docker Toolbox。另外一个更加成熟的容器管理器是 Google 的Kubernetes。它们都解决了缺乏独立运行能力的问题,通过提供一个能跨多主机、多数据中心、多云环境运行的系统。

选择权在你手里。不管你选了哪一个,Docker都能运行的很好。决定那个工具最好,首先是要理解它们的不同点。
# Kubernetes
Kubernetes是一个开源的可以用来自动部署、伸缩和管理容器化应用的系统。Kubernetes集群包含一些基本组成部分。这里是简要的概括一下:

  • Kubernetes成组地部署和调度容器,这个组叫Pod,常见的Pod包含一个到五个容器,它们协作来提供一个 Service。
  • Kubernetes默认使用扁平的网络模式。通过让在一个相同 Pod 中的容器共享一个 IP 并使用 localhost 上的端口,允许所有的 Pod 彼此通讯。
  • Kubernetes 使用 Label 来搜索和更新多个对象,就好像对一个集合进行操作一样。
  • Kubernetes 会搭设一个 DSN 服务器来供集群监控新的服务,然后可以通过名字来访问它们。
  • Kubernetes 使用 Replication Controller 来实例化的 Pod。作为一个提升容错性的机制,这些控制器对一个服务的中运行的容器进行管理合监控。
# SwarmDocker的开发者现在将Docker Machine、Compose 和 Swarm 整合进了 Docker Toolbox 中。你可以对这三驾马车进行配置来让它们负责容器的配置、管理或者集群化容器。Docker Swarm,现在作为一个 beta 版本,是一个 Docker 的集群化工具。它通过使用一个或者多个 Docker 主机来组成一个 Swarm 集群。 Swarm 的设计是将容器打包到主机上,所以它能为更大的容器预留其他的主机资源。较之于随机地将容器调度到集群中的一个主机上,这种集群的组成方式能取得更加经济的伸缩性能。下面是 Swarm 和 Kubernetes 关键的不同点:
  • Swarm 有能将一组 Docker 引擎转变为一个虚拟的 Docker 引擎的原生能力。
  • 一个 swarm 只包含两个组件:agent 和 manager。
  • 一个集群有一个主机来运行一个 Swarm agent,另外一个主机来运行 Swarm manager。
  • 这对于运作来说是必要的,因为 manager 负责容器在主机上的编排和调度。
  • Swarm 使用一个发现机制来处理主机的发现和向集群的添加。
  • Swarm 提供了标准的 Docker API。这使得它提供了开箱即用的能力,能让所有既有的 Docker 管理工具 - 包括第三方的产品- 能自动地、透明地在多个主机上进行伸缩。

# 细微的不同点
两种方式 - Kubernetes 和 Swarm 都能处理同一种类型的工作负载,以云原生应用的方式。然而,一个很大的不同点是如何处理伸缩。

在Kubernetes中,每一个应用层被定义成一个 Pod。一次部署或者复制控制器可以手工地或自动地处理伸缩。在Swarm中,对于单个容器的伸缩定义在 Compose 文件中。

其他的不同点在于管理器系统如何处理高可用、负载均衡、应用滚动更新和回滚、日志和监控、存储、网络、服务发现以及性能合伸缩性上。
# 结论
Kubernetes 和 Swarm 都能大规模构建虚拟的容器。它们提供了用来取得同样目标的两个方式。它们有不同的运作方法,提供了可能更加适合你特定需求的功能。

不要仅仅因为 Docker Swarm 是Docker Toolkit 自带的就是用它作为解决方案。首先,让你的 IT 团队的成员上手熟悉两种工具。然后让 IT 团队根据自己公司的情况来建言,哪一种方式配置和部署更加容易。

用最简单的比喻来说,选择Kubernetes 或者 Swarm 就像在将 Linux 桌面发行版的范围缩小到两个后选出一个最喜欢的。哪个更满足你的需要如何才是决定因素。

原文链接:Choose your Docker Management Tool: Kubernetes or Swarm(翻译:钟最龙)

Docker Swarm vs Kubernetes

adolphlwq 发表了文章 • 0 个评论 • 5608 次浏览 • 2017-06-17 15:22 • 来自相关话题

【编者的话】文章介绍了Docker Swarm和Kubernetes间的不同,以及优缺点。 【3 天烧脑式容器存储网络训练营 | 深圳站】本次培训以容器存储和网络为主题,包括:Docker Plugin、Docker storage ...查看全部
【编者的话】文章介绍了Docker Swarm和Kubernetes间的不同,以及优缺点。

【3 天烧脑式容器存储网络训练营 | 深圳站】本次培训以容器存储和网络为主题,包括:Docker Plugin、Docker storage driver、Docker Volume Pulgin、Kubernetes Storage机制、容器网络实现原理和模型、Docker网络实现、网络插件、Calico、Contiv Netplugin、开源企业级镜像仓库Harbor原理及实现等。

容器化已经改变我们部署软件和微服务开发的方式。如果你刚听说容器,这篇博客帮你入门。
# 什么是容器编排
容器能够把服务打包成基本单元,你可以把它部署到任何地方:本地机器、测试环境或者生产系统。但是在生产环境中,你却不能把所有容器都运行在一台机器上,因为会用光系统的资源。你需要多个机器(或者节点)以集群(不同机器通过网络通信)的方式运行,然后把容器部署到集群中。现在问题变成,如果我有多个机器/节点组成的集群,我该如何决定容器运行在哪台机器上呢?有了编排软件,你只需要告诉它我要部署容器,剩下的事情交给编排软件即可。

编排软件负责以下几点:

  • 选择最适合部署容器的机器。最适合指的是拥有最多空闲资源,或者说如果容器能获得更多的运行内存,比如Redis。
  • 发生机器故障,能自动把故障机器上的容器部署到其它节点。
  • 如果集群添加了新的机器,重新平衡容器的分配情况。
  • 如果容器故障了,重启它。
  • ...
现在你已经理解为什么需要容器编排了,下面我们一起看下当下最流行的两个选择以及它们间的对比。# Docker SwarmSwarm是为Docker开发原生的集群管理引擎。任何适配Docker container的工具、服务或软件都可以很好地兼容Swarm。下面是一些Docker Swarm的优缺点:##优点
  • 容易上手,“开箱即用”的用户体验。
  • 零“单点故障”(single-point-of-failure)架构。
  • 自动生成证书,默认提供安全机制。
  • 向后兼容组件。
  • 开源
##缺点
  • 处于项目启动/早期开发阶段。我们不推荐商业应用上使用。随着时间推移,它会更加成熟。
  • 功能简单有限。
# KubernetesKubernetes是一个Google主导的生产就绪、企业级、成熟的编排平台。它的利弊有:##优点
  • 生产就绪、企业级。它被很多公司用于规模生产环境。
  • 相比Docker Swarm,它更成熟。
  • 可用于公有云、私有云、混合云等多种云环境。
  • 模块化。
  • 自愈能力:自动布局、自动重启、自动备份、自动伸缩。
  • 开源。
  • 因为模块化设计,可被用于部署任何架构。
##缺点
  • 难于部署。如果不使用云服务商Azure,Google或者Amazon,在你的集群中搭建Kubernetes环境非常困难。大部分云服务商都提供了一键安装功能。
  • 比Docker Swarm更陡峭的学习曲线。它不使用Docker CLI。

CloudBoost生产环境使用了60节点的Kubunertes集群,我们是无服务+BaaS(backend as a service)架构,开发者不用关心重复的任务像:认证、通知、邮件服务、管理和扩展数据库、文件、缓存等,这减少了一半的开发时间。我们使用MongoDB和Redis集群做数据存储,NodeJS支撑我们大部分微服务。CloudBoost完全开源,遵循Apache 2 License开源协议,所以你可以随意修改代码,在你的服务器上免费安装。GitHub地址点这里

我们还提供了一个Docker Cloud/Compose file,你可以直接使用它安装CloudBoost。

如果你希望深入了解我们如何在生产环境使用Kubernetes。可以阅读这篇博客

如果你希望快速启动集群,不运行关键应用,或者快速入门编排工具,我推荐Docker Swarm。如果你的场景接近商业环境,你应该考虑Kubernetes。

原文链接:Docker Swarm vs Kubernetes(翻译:卢文泉)

餐饮圈APP后端容器化实践

肥祺王 发表了文章 • 1 个评论 • 4123 次浏览 • 2017-05-15 13:59 • 来自相关话题

【编者的话】记录餐饮圈APP后端容器化技术选型,以及实践过程。 【深圳站|3天烧脑式Kubernetes训练营】培训内容包括:Kubernetes概述、架构、日志和监控,部署、自动驾驶、服务发现、网络方案等核心机制分析,进阶篇——Ku ...查看全部
【编者的话】记录餐饮圈APP后端容器化技术选型,以及实践过程。

【深圳站|3天烧脑式Kubernetes训练营】培训内容包括:Kubernetes概述、架构、日志和监控,部署、自动驾驶、服务发现、网络方案等核心机制分析,进阶篇——Kubernetes调度工作原理、资源管理及源码分析等。
#项目介绍
简单介绍一下餐饮圈项目规模,以及团队配置,用以作为技术选型和实践的参考条件。
# 餐饮圈介绍
餐饮圈是专注于餐饮行业社交,招聘的APP。 后端采用微服务的设计思想,将不同的业务放在不同服务中。 随着业务的发展,目前后端服务有20多个。

容器化之前,采用的是传统的负载均衡(阿里云负载均衡)、多台服务器(阿里云ECS)、数据库(阿里云RDS)模式。
# 团队规模介绍
研发团队3~5人,同时负责前端APP和后端的研发和运维。日常的开发流程采用敏捷开发的Scrum方法。
#一个简单的目标——不断提升生产力
不断提升生产力是促使团队尝试容器化后端的主要动力。

随着后端服务的增多,在服务管理方面投入的时间增多, 团队注意到用于发布,调试和监控服务的时间越来越多。 因为之前采用的是单一Tomcat运行所有服务,导致每一个服务的变更都需要重启整个Tomcat。 Tomcat也占用了大量的服务器内存。

于是,列出了希望提升的几个点:

  • 更简化的发布部署方法
  • 更灵活管理服务对资源的使用
  • 更高效的管理服务器资源,实现快速弹性伸缩
基于以上三点,团队开始考虑容器化后端,使用容器编排平台来管理服务。

注意:容器化后端,并不是解决上面问题的唯一选择。后来的实践中也渐渐体会到,容器化后端是很重大的决定,改变的是整个后端的基础架构。之所以没有过多犹豫就选择容器化方案,是因为团队内有人熟悉容器,而且现有后端基础架构相对简单。

## 第一张架构总览项目后端在阿里云上,持久化存储用的全部是阿里云的服务。 数据库使用RDS, 图片等静态文件使用OSS, Redis使用云数据库Redis,所以容器化过程不存在应用服务器有持久化数据的问题, 只需要保证容器平台可以顺利链接阿里云服务器即可。 :应用服务器无状态化是容器化之前很关键的点,如果应用服务器上存有数据,例如图片、缓存等,需要先将这些数据转移到云平台的存储服务中, 可以参考12 Factor App这篇文章。下面是第一张架构总览,简单的从逻辑层面描述了容器化后的后端架构。
Architecture-Overview-containerlize-inferstructure.jpg
可以看到容器编排平台是架构的核心,所以选择一个适合的容器编排平台是容器化后端的关键。## 容器编排平台的选择我们选择了三个容器编排平台作为备选方案:
  • Docker Swarm
  • Kubernetes
  • Rancher
Docker Swarm作为Docker自家出品的容器编排服务,和Docker无缝连接,实施简单,学习曲线平滑,了解Docker使用的程序员可以很容掌握。而且,阿里云容器服务也采用了Docker Swarm作为基础。Kubernetes,很多大厂用它实现了PaaS服务, 在企业级解决方案中Kubernetes也经常被采用作为PaaS平台的基础,可以侧面体现出Kubernetes的可靠性,稳定性等优势。作为Google自家集群管理工具的开源版本,Kubernetes有很高的呼声。Rancher相对于前两个选择,有着开箱即用的特性,提供了完整的UI控制台。在集群管理方面有多种选择,可以选择Kubernetes,Docker Swarm来做容器编排。 但是因为国内相关实践例子不多,很快就被从选项中去掉。 # 尝试阿里云容器服务——Docker Swarm第一个POC是在阿里云容器服务上做的,因为阿里云容器服务采用Docker Swarm基础, 而且提供了一套完成的UI控制界面。 借助官方提供的文档,一天内完成了三台服务器节点的测试集群搭建,并发布了几个测试服务。一切进行的很顺利。第二天,陆续将全部服务都部署上去,并开始性能和压力测试。 阿里云容器服务架构如下(来自官方文档):
aliyun-container-service.png
## 第一个问题在测试过程中,遇到了第一个问题,响应时间不稳定。 有些服务第一次请求响应时间在几千毫秒到几百毫秒波动, 并不稳定。翻阅了路由部分的文档,找到了请求如何在平台内路由的示意图如下:
aliyun-container-routing.png
可以看到Routing容器起到了服务发现和路由转发的作用, 负载之后所有请求都会经过Routing容器。 容器内是HAProxy做请求转发。因为请求经过负载,又经过Routing容器,然后由虚拟网络层在集群内转发到提供服务的容器。 此过程,在请求到达服务容器之前都没有日志可以跟踪,始终无法知道延迟出现在哪一步。 再后来的实施中这个问题随着增加服务容器实例的个数得到缓解,但是始终没有找问题的根本原因(并不能排除应用层本身有的问题的可能)。## 雪崩压力测试过程中,集群出现了第一次雪崩,三个节点全部掉线,并且无法SSH登录。 调查雪崩原因有两个: ## 结论优势
  • 阿里云容器服务,提供了类似Rancher的开箱即用的特性,只需要将云服务器配置到集群中就可以自动完成集群的部署。 并且可以通过控制台界面,快速完成阿里云日志服务,云监控等功能的集成。 对于没有专门运维人员的小团队,能节省很多维护时间。
  • Docker Swarm作为基础架构,开发团队学习曲线平滑,只需要掌握docker基本知识就可以上手使用。
有待解决的问题
  • 集群使用的etcd作为一个外部服务独立提供,对于用户不可见,也不可控。
  • 请求链路不完全透明,链路跟踪有难度。
  • 技术支持需要在群里喊。 当然群里管理员很负责,阿里云工程师都很专业,问题基本可以很快解决。但感觉技术支持的流程还不是太规范。
#尝试Kubernetes集群虽然Kubernetes提供了在AWS等云上的部署的驱动,但是对于阿里云,目前并没有集成进去。 所以,我们参考了阿里云初扬的《当 Kubernetes 遇到阿里云 之 快速部署1.6.1版本》做POC。 对于刚刚接触Kubernetes的人来说,这很有挑战。 依然从三节点的测试集群开始,但马上遇到了虚拟网络层的问题, 在`经典网络`模式下始终无法在集群内联通虚拟网络。 几次尝试未果后,转移到`VPC`网络,成功建立了集群,并打通了虚拟网络。## 集群成功运行——只是个开始经过两天的折腾,Kubernetes集群搭建完成。 但是还有很多东西需要完善, 控制台UI界面、服务发现、日志、监控。 很显然这些都不在Kubernetes的核心中。 所有都需要借助其他开源项目来搭建,需要投入更多的人力和时间去完善。 对于小团队来说,希望将Kubernetes用于微服务架构的生产环境,挑战很大。咨询过一些前辈后,了解到在Kubernetes上部署`Spring Cloud`是一个用于微服务的选择,但是并没有继续尝试。## 结论优势Kubernetes优势很多,比如大厂都在用, 社区很活跃。 但我们最终并没有完整实践Kubernetes,所以没有办法谈对这些优势的体会。对于小团队来说的挑战
  • 阿里云上部署需要了解很多Kubernetes的基础组件,其中『虚拟网络层』搭建挑战很大。
  • 如果希望用于生产环境,需要自行搭建高可用架构,并且搭建控制台,服务发现, 日志等应用。 (可以参考在阿里云上部署生产级别Kubernetes集群了解部署高可用集群的方法,但文章中也没有提到微服务相关的工具如何搭建)
  • 微服务平台相关组件都需要自行部署和配置
#选择——阿里云容器服务经过对两个平台的POC,我们最后选择了提供了更多工具的`阿里云容器服务`作为容器化后端的方案。 对于小团队来说,容器化是为了提高生产力,开始选择容器编排平台时,我们忽略了微服务平台这个概念,将容器编排平台等同于了微服务平台。 在POC阶段,逐渐认识到了两者的不同,微服务平台可以构建在容器编排平台之上,也可以直接在云服务器上部署。 选择阿里云容器服务,其实是选择了一套微服务平台,并不单单是Docker Swarm。 坚持容器化后端,也是因为基于Docker的DevOps可以不局限于某种后端技术,更灵活的隔离应用运行环境,和控制应用对资源的使用。## 第二张 Architecture Overview目前实施的架构总览:
Architecture-Overview-with-aliyun-containerlize-inferstructure.jpg
# 后记## 在容器化后端过程中到我们底在选择什么最初我们希望通过容器化后端架构来实现提高生产力这一目标。 在技术选型的开始阶段,“选择一个适合的容器编排平台”被定义为关键技术问题。 但随着POC的深入,只选择容器编排平台并不能解决提高生产力的目标,甚至容器编排平台本身并不能直接提高生产力,对于小团队来说反而需要投入更多的人力去维护。 我们认识到, 对于一个3~5人的小团队来说,我们更需要的是一套微服务治理平台,这个平台是建立在IT基础架构之上的应用平台。而容器编排平台更像是IT基础架构针对容器的一层抽象,并不能直接满足小团队提高生产力的目标。 下图大概说明了,应用、微服务平台、容器编排平台、IT基础架构的关系。
layers.jpg
所以,在容器化后端技术选型的后半程,我们更多的考量的是如何选择一个适合的微服务平台。最后基于阿里云容器服务,实现了我们的后端容器化的第一阶段。 因为Docker Swarm和Docker的无缝连接, 开发团队并没有花费太多精力去学习新的概念,快速的将发布运维一系列工具迁移到了容器上。 在一个月之内,保证日常业务变更的前提下,完成了后端容器化,实现了提高生产力的目标。 ## 还没做的事情
  • 继续调研微服务平台
  • 测试弹性伸缩

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

Fundebug 发表了文章 • 0 个评论 • 5494 次浏览 • 2017-05-10 08:56 • 来自相关话题

【编者的话】实践中会发现,生产环境中使用单个Docker节点是远远不够的,搭建Docker集群势在必行。然而,面对Kubernetes,Mesos以及Swarm等众多容器集群系统,我们该如何选择呢?它们之中,Swarm是Docker原生的,同时也是最简单,最易 ...查看全部
【编者的话】实践中会发现,生产环境中使用单个Docker节点是远远不够的,搭建Docker集群势在必行。然而,面对Kubernetes,Mesos以及Swarm等众多容器集群系统,我们该如何选择呢?它们之中,Swarm是Docker原生的,同时也是最简单,最易学,最节省资源的,至少值得我们多了解一下。本文将介绍一些非常实用的建议。

【深圳站|3天烧脑式Kubernetes训练营】培训内容包括:Kubernetes概述、架构、日志和监控,部署、自动驾驶、服务发现、网络方案等核心机制分析,进阶篇——Kubernetes调度工作原理、资源管理及源码分析等。

如果你在单个生产节点上用过Docker,然后发现单个节点的资源不够用,那么你会怎么做呢?我也遇到过这种情况! 关于在生产环境中使用Docker Swarm,我会为你提供一些建议,也许能够帮到你。这些都是我一年来积累的一些经验。

另外,如果你对Docker Swam不熟悉的话,可以参考我之前的博客My experience with Docker Swarm - when you may need it?

# 1. 阅读官方文档
我并不打算重复官方文档。尽管文档非常短,但是通过它可以了解Swarm的基本知识。另外,我也不会写如何搭建Swarm集群,这方面的资料太多了,你可以查看 Digital Ocean或者自己谷歌。PS:我是使用Ansible搭建Swarm集群的。
# 2. Docker Swarm要点
Swarm的负载非常低。据我观察,Swarm进行调度和通信的CPU负载非常低。因此,Swarm的管理节点(Manager)可以同时作为工作节点(Worker)。如果你需要搭建一个非常大的集群(1000+ 节点),管理节点需要更多资源,但是对于中小型集群来说,管理节点需要的资源可以忽略不计。另外,这篇博客介绍了Swarm3k(一个4700节点的Swarm集群的实验),不妨了解一下。

Swarm集群的网络通信(服务发现,负载均衡以及容器间通信)非常可靠。当你开启一个服务的端口之后,在Swarm集群中的任何一个节点都可以访问它。负载均衡也是由Swarm提供的。后文会提到一些之前遇到的问题,但是Docker 1.13之后,这些问题都解决了。

使用Swarm只需要掌握少量命令。下面是我每天需要用到的所有命令:
bash
# 创建服务
docker service create \
--image nginx \
--replicas 2 \
nginx

# 更新服务
docker service update \
--image nginx:alpine \
nginx

# 删除服务
docker service rm nginx

# 减少服务实例(这比直接删除服务要好)
docker service scale nginx=0

# 增加服务实例
docker service scale nginx=5

# 查看所有服务
docker service ls

# 查看服务的容器状态
docker service ps nginx

# 查看服务的详细信息。
docker service inspect nginx

实现零宕机部署也非常简单。这样也可以方便地实现持续部署:
bash
# 构建新镜像
docker build -t hub.docker.com/image .

# 将新镜像上传到Docker仓库
docker push hub.docker.com/image

# 更新服务的镜像
docker service update --image hub.docker.com/image service

Swarm非常容易入门。分布式系统通常是非常复杂的。与其他容器集群系统(Mesos、Kubernetes)相比,Swarm的学习曲线最低。在没有任何Swarm知识的情况下,我只花了一周时间,就把服务从单个Docker主机迁移到20个节点的Docker集群上。

更新服务要慎重。 你的容器同时运行在多个主机上。更新服务时,只需要更新Docker镜像。合理的测试和部署流程是保证成功的关键。
# 3. 决定哪些容器部署在Swarm集群
并非所有服务都应该部署在Swarm集群内。数据库以及其他有状态服务就不适合部署在Swarm集群内。理论上,你可以通过使用labels将容器部署到特定节点上,但是这样的话,Swarm集群外的节点就很难访问它们了(Docker 1.12没有很好的方法,但是1.13之后可以使用attachable network)。如果你允许集群外的节点访问数据库,则所有节点都可以访问它,这显然不符合你的需求。另外,Docker Swarm的跨节点数据卷(cross-host mounted volumes)并不可靠,一个简单的文件上传都可能引起问题。

无状态的容器就非常适合部署在Swarm集群中,它们可以由环境变量进行配置(使用ENV指令)。建议为开源工具构建镜像,例如,可以将Nginx的配置文件放到Docker镜像中。

下面是我部署在Swarm集群中的服务:

  • Django channels(网页应用)
  • Nginx(代理)
  • Celery(周期性任务)
  • Sensu(监控)
下面是我部署在Swarm集群之外的容器:
  • Postgres(数据库)
  • Redis(缓存)

由于一个获取真正IP的问题,我很可能会将Nginx运行在Swarm集群之外,或者采用host模式。
# 4. 配置Docker仓库
Docker仓库,你值得拥有!你可以自己搭建一个,或者使用Docker仓库服务,比如DockerHub或者GitLab Container Registry。不要在服务器上直接构建Docker镜像,因为你有多个节点(在每个节点上构建镜像非常麻烦),而且在创建服务的时候你需要指定镜像(这个镜像所有节点都应该可以下载)。如果你配置了私有Docker仓库,则需要指定`--with-registry-auth`,否则这些节点将无法下载镜像。

另外,你应该为Docker镜像设置版本,这样更加易于回滚。
# 5. 将半无状态的服务变得完全无状态
所谓半无状态服务,就是容器需要依赖一些不太重要的外部文件。你可以使用数据卷(volume),但是更好的选择是使用S3或者其他云存储服务。记住,想要获得扩展性,云是最好的选择。

例如,我不得不构建Nginx镜像,将配置文件放到镜像中。使用数据卷挂载Nginx配置文件不是很方便。
# 6. 配置日志收集服务
使用分布式系统时,集中管理日志是非常必要的。我们有很多方案,包括开源工具或者SaaS服务,比如ELK,Grafana, Graylog...自己搭建完整的系统是非常复杂的,所以我建议搭建先使用SaaS服务(比如Loggly, Logentries ),当费用太高时,则自己搭建一个系统。ELK可以这样配置:
bash
docker service update \
--log-driver gelf \
--log-opt gelf-address=udp://monitoring.example.com:12201 \
--log-opt tag=example-tag \
example-service

# 7. 创建attachable network
attachable network是一个非常重要的特性。你最好使用它,否则`docker run`创建的容器将无法接入Swarm集群的网络。这是Docker 1.13之后的版本才有的功能,也许你需要升级。

创建attachable network的命令如下:
bash
docker network create --driver=overlay --attachable core

# 8. 先使用环境变量,再考虑Secrets API
如果你按照How to write excellent Dockerfiles构建Docker镜像,你很可能会使用环境变量去配置很多东西。如果你这样做的话,则迁移到Swarm集群时问题会少很多。示例命令如下:
bash
# 创建服务时指定环境变量
docker service create \
--env VAR=VALUE \
--env-file FILENAME \
...

# 增加、删除环境变量
docker service update \
--env-add VAR=NEW_VALUE \
--env-rm VAR \
..

下一步是使用Secrets API 。简单地说,你可以将私密数据(比如密码,SSL证书等)以文件的形式挂载到容器中。虽然我还没有用过Secrets API,但是我觉得值得尝试一下。
# 9. 设置合理的服务容器个数以及并行更新的容器个数
一方面,你需要保证足够多的容器数来处理负载以及作为灾备,另一方面,太多的容器会导致CPU和内存资源不足。因此,你需要配置合理的服务容器个数,也就是说,某个服务,需要运行合理个数的容器。

另外,默认的`update-parallelism` 值是1,这就意味着更新服务时,每次只更新1个容器。通常,这个值太小了。我的建议是将它设为 `服务容器数 / 2`.。

相关命令
bash
# 将同时更新的容器数设为10
docker service update \
--update-parallelism 10 \
webapp

# 同时增加多个服务的容器数
docker service scale redis=1 nginx=4 webapp=20

# 查看服务状态
docker service ls

# 查看服务的详情(排除关闭的容器)
docker service ps webapp | grep -v "Shutdown"

# 10. 将Swarm配置代码化
最佳方式是使用Docker Compose v3 语法,这样可以将服务的所有配置选项代码化。我将 `docker-compose.yml`用于开发环境, `docker-compose.prod.yml`用于生产环境。使用docker-compose文件部署服务的话,需要使用 `docker stack deploy` 命令(参考docker stack

docker-compose文件示例
# docker-compose.prod.yml
version: '3'
services:
webapp:
image: registry.example.com/webapp
networks:
- ingress
deploy:
replicas: ${WEBAPP_REPLICAS}
mode: replicated
restart_policy:
condition: on-failure

proxy:
image: registry.example.com/webapp-nginx-proxy
networks:
- ingress
ports:
- 80:80
- 443:443
deploy:
replicas: ${NGINX_REPLICAS}
mode: replicated
restart_policy:
condition: on-failure

networks:
ingress:
external: true

部署命令:
export NGINX_REPLICAS=2 WEBAPP_REPLICAS=5

docker login registry.example.com
docker stack deploy \
-c docker-compose.prod.yml\
--with-registry-auth \
frontend

另外,docker-compse文件支持环境变量(${VARIABLE}),这样你可以动态地调整配置。
# 11. 设置资源限制
根据我的经验,你需要限制所有服务的CPU使用。这样可以防止单个容器占用主机的所有的CPU资源。

`reserve-cpu` 选项也非常有用。当我希望平均地将所有容器部署到各个主机时,我会使用`reserve-cpu` ,它可以保证每个容器都有足够地资源。示例:
bash
# 限制服务占用的CPU资源
docker service update
--limit-cpu 0.25
--reserve-cpu 0.1
webapp

# 12. 监控网络连接
我遇到过Swarm网络方面的问题。有时候所有的请求都被转发到某一个容器,然而还有9个其他容器正在运行。这时,可以尝试减少/增加实例个数,或者改变路由类型(使用`--endpoint-mode`选项)。

如果没有监控日志的话,这样的问题很难被发现。因此,搭建监控系统是非常必要的。

欢迎加入我们FundebugDocker技术交流群: 305097057

原文链接:Tips for using Docker Swarm mode in production(译者: Fundebug

为了保证可读性,本文采用意译而非直译。另外,本文版权归原作者所有,翻译仅用于学习

Swarm真垃圾,各种问题

回复

我活了这小半辈子 发起了问题 • 1 人关注 • 0 个回复 • 1092 次浏览 • 2018-08-08 16:57 • 来自相关话题

Swarm中容器的负载均衡

回复

anoyi 回复了问题 • 2 人关注 • 1 个回复 • 2845 次浏览 • 2018-02-04 09:40 • 来自相关话题

swarm版本的问题

回复

apple9915 回复了问题 • 1 人关注 • 1 个回复 • 1679 次浏览 • 2017-08-28 18:03 • 来自相关话题

docker swarm 网络性能问题

回复

Dockergo 回复了问题 • 3 人关注 • 5 个回复 • 6127 次浏览 • 2017-07-25 09:52 • 来自相关话题

docker swarm 使用calico网络无法映射端口

回复

justinmjc 回复了问题 • 2 人关注 • 2 个回复 • 4350 次浏览 • 2017-07-12 16:42 • 来自相关话题

docker swarm 内部容器无法访问

回复

justinmjc 回复了问题 • 1 人关注 • 1 个回复 • 2266 次浏览 • 2017-07-11 09:06 • 来自相关话题

swarm mode docker ps

回复

muicoder 回复了问题 • 2 人关注 • 1 个回复 • 1953 次浏览 • 2017-06-27 12:51 • 来自相关话题

docker swarm 灾备问题

回复

Dorian 回复了问题 • 2 人关注 • 2 个回复 • 1990 次浏览 • 2017-06-07 09:58 • 来自相关话题

swarm 集群环境下如何实现服务间调用

回复

田浩浩 回复了问题 • 3 人关注 • 1 个回复 • 3183 次浏览 • 2017-06-03 11:09 • 来自相关话题

搭建好了swarm集群,如何结合使用compose管理集群容器

回复

lucas 回复了问题 • 3 人关注 • 2 个回复 • 2712 次浏览 • 2017-05-08 17:22 • 来自相关话题

【腾讯云】#容器团队#高级容器研发#招聘

Shirleyee 发表了文章 • 1 个评论 • 217 次浏览 • 2019-05-24 10:33 • 来自相关话题

高级容器研发工程师 工作职责 负责公有云/私有云中 Kubernetes/Devops 等产品技术方案设计与研发工作;负责 Kubernetes 相关前沿技术规划和调研工作,从技术上保证产品的竞争力;负责与产品及客户沟通,判定需求的合理 ...查看全部
高级容器研发工程师
工作职责
  1. 负责公有云/私有云中 Kubernetes/Devops 等产品技术方案设计与研发工作;
  2. 负责 Kubernetes 相关前沿技术规划和调研工作,从技术上保证产品的竞争力;
  3. 负责与产品及客户沟通,判定需求的合理性,找出最合适的方式解决客户问题。
工作要求
  1. 3 年以上后端开发经验,Coding、Debug 能力强, 有丰富的架构设计经验;
  2. 熟悉 C/C++/Go/Java/Python/Ruby 等至少二种编程语言;
  3. 熟悉 Docker/Kubernetes/Swarm/Mesos 等技术;
  4. 熟悉 Jenkins/ELK/Prometheus 等技术优先;
  5. 熟悉 AWS/Google Cloud 等云计算厂商产品优先。


有意请戳:
Wechat:13723737494
Email:Shirleyeee@foxmail.com

房多多容器化和容器云实践

阿娇 发表了文章 • 0 个评论 • 745 次浏览 • 2019-04-25 22:56 • 来自相关话题

#背景和意义 房多多是国内首家移动互联网房产交易平台。作为迅速崛起的行业新生力量,房多多通过移动互联网工具,为开发商、经纪公司、买房卖房者搭建了一个高效的、可信赖的O2O房产交易平台。 房地产行业的复杂性和业务创新环 ...查看全部
#背景和意义

房多多是国内首家移动互联网房产交易平台。作为迅速崛起的行业新生力量,房多多通过移动互联网工具,为开发商、经纪公司、买房卖房者搭建了一个高效的、可信赖的O2O房产交易平台。

房地产行业的复杂性和业务创新环境注定了房多多的产品特点是不断持续创新和持续高速迭代的,在不断探索业务的可能性的过程中,提高持续快速交付价值的能力和创新能力是必不可少的。

软件行业没有所谓的“银弹”,房多多在业务解耦微服务化以后,服务指数型的增长带来了许多运维方面的困扰。

在我们内部比较突出的矛盾有:

* 虚拟机的资源依靠维护文档人肉调度,机器调度效率低。
* 维护测试、预发布、生产等环境的成本高。
* 某个业务的稳定太依赖某台物理机的稳定性,且难以快速扩容。
* 业务需求变化快导致雪花服务器增多,难以维护;
* CI/CD脚本复杂,新的需求难以快速交付。

在2018年房多多技术团队开始了服务容器化和容器云的建设,调研后选择了 Swarm 作为了容器集群。

可能很多人看到这儿就会关掉,"都9012年了还有人用Swarm?"

虽然在Swarm在和Kubernetes的竞争中已处于下风,但是Swarm的灵活性、性能和易用性促进了我们的容器化推进,且在我们落地过程中没有出现过系统级的bug和线上故障,目前已经在生产环境支撑数百个服务的运行,每日300次左右的变更。

容器和调度编排系统的引入给难以运维的微服务架构带来了质的改变,但是服务容器化和容器云在推进过程中也踩过不少坑和积累了一些经验,希望给大家带来启发。
#选型

在容器集群的选择上,Kubernetes事实上已成为容器届编排的标准,但是为什么我们选择了小众的 Docker Swarm呢?

房多多的生产环境硬件基础设施基本都在IDC机房,物理机器数量大概有几百台,实际可以供业务迭代用的机器大概在一半左右,且没有很多空闲机器可供使用、新建容器云的机器需要腾挪现有业务。

根据上述的自身的情况,我们做容器平台调研时,主要从以下三点考虑:

* 性能:用户可以在多短的时间内启动并大规模运行容器?系统在大负载情况下响应速度如何?
* 易用性:起步时的学习曲线是什么?维持运转是否复杂?系统中有多少不定项?
* 灵活性:是否可以和我当前的环境和工作流相整合?应用从开发到测试再到生产,是否可以无缝衔接?会不会被限制在某个平台上?

从性能看:房多多是自建机房,每一台物理机的利用率是比较高的。在我们测试调研过程中发现,Swarm通常可以在一秒内启动一台容器,调度效率和容器启动速度其实比Kubernetes快很多。如下图(50%负载下,1000节点 启动每一个容器的平均时间):
1.jpg

从灵活性来看:Swarm的API比较简单,可以很快的和现有的DevOps流程打通。且因为Swarm相当于Kubernetes的子集,如果后面机器规模继续扩展,业务有大量编排需求,我们可以花不多的时间就可以迁移到Kubernetes上。其实只要我们的服务容器化了,后续更换什么容器集群其实问题都不大。

从易用性来看:API使用简单,资源抽象简单,可以快速启动上手。我们使用Swarm比较多的功能其实是调度功能,编排功能暂时没有大规模使用。Swarm的结构比较简单,在最新的版本中内置分布式k-v数据库代替了etcd,内置DNS用来服务发现。在规模中等情况下,几乎没有基础设施运维负担。
#容器云架构

Swarm的实现和Kubernetes相似,最近的版本也在慢慢模仿Kubernetes的思想。

想了解如何搭建集群的操作可以查阅 Swarm 官网的文档。

因为Manager节点只负责调度集群的Task,配置要求不高,所以我们用虚拟化Xenserver虚拟了3台低配置机器(在不同的物理机上)作为Manager节点,根据Raft算法,3台可以容许1台机器出问题,5台可以允许2台机器出问题,大家可以按需求部署。Worker节点的作用是运行业务容器,我们选择了直接用物理机来部署已达到最好的性能和资源利用。同时,在Manager和Worker节点上,会以容器方式部署机器监控和日志收集,上面还需要运行网络和存储插件。

都加入到集群之后,Swarm会提供网络管理、负载均衡、基于DNS容器发现、集群状态管理、扩容缩容等功能,我们在DevOps流程层面,可以组合成发布、回滚应用、查看服务的状态、日志、终端,更改发布配置(例如环境变量、默认副本数等)等功能。这个层面我们引入了Portainer这个开源项目,提供了更好用集群管理的UI界面和类似Kubernetes Apiserver设计的Docker集群API接口服务。
2.jpg

Docker Swarm的资源抽象比较简单,在没有容器编排的情况下,我们主要使用Services,这个和Kubernetes上的Services有些不一样,可以理解为Services和Deployment的合体,用来管理和定义容器的调度和扩容等,也可以直接做端口映射,在容器集群里任意IP都可以访问。

下图可以比较简单的描述我们是怎么把服务让外部和内部调用的:
3.jpg

外部调用我们目前是通过Nginx做反向代理到集群的节点,因为Ingress的特性我们可以转发到任何一台Worker或者Manager节点上,然后通过内置的routing mesh的Load Balancer通过LVS转发请求到Service的其中一个副本,一个值得注意的点是,就算这台Node上没有运行这个Service的容器Load Balancer也会找到其他机器上存在的副本,这个主要是通过 内置的DNS加LVS转发实现。

内部调用我们是走我们的Envoy Mesh网关,通过自研的xds-service来自动发现加路由,本质是走容器之间互通的Overlay网络或者Macvlan网络。
#网络

网络我们主要解决两个问题:

  1. 容器间互相通信,容器直接互相调用打通,并且可以作为基础的容器网卡,以支持容器集群的routing mesh功能。
  2. 容器和外部网络互相通信,类似使用了Dubbo服务容器化,在虚拟机和容器并存的迁移过程中,必须要让容器和外部网络互通,不然会导致在容器集群外部的虚拟机调用不通容器。虽然也可以通过其他方法实现,但是打通容器和外部网络互相通信是较可行也是稳定的一种方法。

下图是我们主要的容器网络架构。
4.jpg

容器间互通的解决方案是我们在容器集群中创建Overlay网络,并将网络附加到容器容器上,容器中就有了名为Overlay的网卡(图中的 eth0),每个容器的eth0都会经过宿主机的docker0网卡和eth0与别的宿主机的网络进行交互。

容器与外部网络互通的解决方案是Macvlan。其工作原理是通过为物理网卡创建Macvlan子接口,允许一块物理网卡拥有多个独立的MAC地址和IP地址。虚拟出来的子接口将直接暴露在底层物理网络中。从外界看来,就像是把网线分成多股,分别接到了不同的主机上一样,这样也可以拥有近似物理机直连的性能。

公有云一般会限制Macvlan,不一定可以实施。因为我们是自建机房,所以没有这方面的限制,只要让网络工程师在交换机上配置好网段,我们就可以在此网段下分配容器的IP了。

具体使用方法是,在容器Worker节点创建一个config-only的Network,写划分的网段和网关,例子:
docker network create --config-only --subnet=10.0.127.0/20 --gateway=10.0.112.1 --ip-range=10.0.112.0/25 -o parent=bond0 pub_net_config
# bond0 为指定的依附的物理机网卡

然后在Manager节点创建Network,例子:
docker network create -d macvlan --scope swarm --config-from pub_net_config pub_net

然后只需要把网络附加到Service上即可:
docker service update m-web --network-add pub_net

#容器化

容器化首先是要把业务代码build成镜像,我们内部的技术栈主要以Node和Java为主。

我们容器化迁移是先从Node服务开始,因为Node服务普遍比较新且项目都按照规范创建,没有很多历史债务且基本都是无状态的,这样我们就可以写出一个比较通用的Dockerfile让开发在迭代需求是时候顺便加上,基本只需要改一下暴露的端口号和监控检查URL就可以完成容器化。

Java的构建工具主要以Maven和Gradle为主,我们使用了Google开源的Jib 工具来把构建Docker镜像并上传的工作集成到Maven和Gradle中,实际操作只需要改一下pom文件或者build.gradle,加入Jib Plugins就可以了。

实际推广过程中,如果是还在迭代的项目,因为操作简单且容易理解,业务开发还是比较容易推动的。如果是历史项目且还运行在线上,可以让业务运维帮忙逐个操作,然后重新发布,测试,上线。
#优化和Tips

##镜像大小优化

镜像大小是容器化很重要的一个问题。镜像越小,容器发布和调度就越快,宿主机磁盘用量也不会过大。

除了大家常用的镜像优化手段比如减少层级等,我们优化基础镜像baseimage使用了alpine 3.9版本,并对使用到的基础库做了选择,比如使用最新的musl 1.1.21等,最终基础镜像控制42M,最终降低80%镜像大小到300M以内。
##信号量优化

当容器的启动脚本是一个Shell脚本时,因为Shell不响应退出信号的特性,会导致容器无法正常退出,只能等超时后自动杀死进程,这样在我们的实践中会导致物理机上有很多僵尸进程。所以我们的解决方案是消除进程树中的Shell进程,我们改用了一个tini这个来作为主进程,在基础镜像中添加ENTRYPOINT ["/tini", "—"]即可,虽然不等子进程返回的方式可能不太优雅,但是可以快速stop容器带来的灵活性足以弥补这个缺点,当然特殊应用可以特殊处理。
##Java容器化问题

Java容器化的坑比较多,JDK我们使用了 OpenJDK 8(version "1.8.0_191"),JVM opts我们加上了-XX:+UseContainerSupport -XX:MaxRAMPercentage=75.00,这个版本Java已经可以获取到正确的CPU资源和内存资源,默认使用75%的Cgroup空间为heap memory,留25%空间给stack memory。防止因为heap memory加stack memory太大导致容器内存使用超出Cgroup限制被Kill掉。

除此之外,我们还优化了随机数生成的原理:
echo "securerandom.source=file:/dev/urandom" >> /usr/lib/jvm/default-jvm/jre/lib/security/java.security

##DNS Performance(Lookup Failed)

两方面原因:

一方面,Docker自身的DNS允许并发数太低,已经提issue并修复了:docker Increase max concurrent requests for DNS from 100 to 1024。

另一方面,musl的代码在DNS解析的实现上有些问题,如果有IPv6的A记录那么解析性能不会出现问题,如果只有AAAA的IPv4记录,那么解析可能会出现卡死的情况,等待2.5s才返回,所以要添加一个break代码防止出现等待,在最新的musl的版本解决了(没有发布,需要自行编译)。
5.jpg

最后,这个问题其实是因为业务服务大多数是使用HTTP/1.x导致产生多条TCP连接造成的,现在房多多已经全站使用HTTP 2多路复用长连接,这个瓶颈其实也就不存在了。
##流量突然增高Slab分配失败导致机器负载高

容器平台集群不定期的报slab memory malloc的错误。

系统负载高时,服务器内核大量报Slab cache错误,升级CentOS 7.5新内核862解决。值得一提的是,在容器时代,大家对内核的要求越来越高也越来越依赖内核的功能,很多公司其实都走在了内核迭代的前列,发现了很多bug并对社区做出了贡献。
##物理机配置问题导致容器网络不通

我们有出现过一次交付物理机Restart Network后没有开启ipv4_forward导致的改物理机上的容器Overlay网络挂的问题。

我们的解决方法是在启动容器前通过ping网关的方式检查DNS服务和网络是否打通。
#发布系统改造

##构建流程自定义

在容器化的过程中,我们也把构建流程做了优化,引入了Jenkins Pipeline功能。Pipeline对于我们的最重要的好处是可以把构建流程DSL代码化,并可以针对每一个项目自定义构建流程,当然我们有提供一个大体的框架,用户只需要更改自己所需要的就可以了,如下图:
6.jpg

7.jpg

最终会生成一个Jenkinsfile并在每次构建的时候都回去调用项目对应的Jenkinsfile。有了这样的功能,开发就可以根据自己的需求,轻松的更改自己项目的构建流程。
##Web Terminal

我们根据业务开发的需求开发了Web进入Docker容器的功能。原理是转发docker exec命令到对应的物理机上,并转发输入输出。支持快捷键和高亮,体验良好。
8.jpg

##Log

日志我们通过在转发docker logs请求获取最新的2000条(默认,可配置)日志打印到Web页面上,支持自动刷新和滚动。
9.jpg

#日志收集

我们会把项目输出的日志通过Volume都挂载到每台宿主机的固定目录下,并用global模式部署filebeat进行采集,输出到我们的Elastic集群上,然后在ELK平台上查询日志。最近我们也在测试环境尝试Grafana Loki 项目,他和Elastic的原理相反,只索引必要的字段,可以节省大量的机器资源,如果是用来做"distribute grep"的话就很合适。
10.jpg

#监控

监控我们使用了Swarmprom开源项目,监控项比较丰富,覆盖了机器基础指标,容器指标,可以较快的定位问题,当时当容器集群出现宕机等情况时,监控会暂时失效,所以我们在容器集群外也部署了针对机器的基础监控。具体效果如下:
11.jpg

12.jpg

#推广

容器的推广需要业务开发和业务运维的支持,不然很难推动。

推广首先要让开发和运维感受到红利:

* 容器相对于虚拟机更轻量化,可以实现秒级启动。
* 测试、预发布、线上的容器部署配置、环境 完全一致。
* 可以根据 CPU、内存或者QPS和延时快速扩容,提升服务能力。
* 服务crash会自动启动,自带高可用。

这四个特性的组合,可以给业务带来更大的灵活度和更低的计算成本。

我们团队是把这个容器平台当成一个产品来运作,业务开发就是我们的用户。

在推进容器化的过程中,我们还会做如下的事情:

* 通过培训让开发了解我们的产品优势(对比虚拟机)。
* 提供使用文档、接入文档等使得产品的易用度增加。
* 在迁移时给予开发更高优先级的支持。
* 资源尽量都加入容器集群,停止并减少虚拟机的供给。

#总结

从传统的虚拟机架构到现在的基于云原生的容器云架构,带来了秒级部署、秒级扩缩容、简化了CI/CD 流程、提供Service Mesh微服务治理能力。

如果按虚拟机时代运维人肉调度服务,人肉管理资源,在新虚拟机部署一个新应用或者扩容一个应用的时间在10分钟以上,和现在的按秒计算时间是质的变化,这是招再多的业务运维人员也达不到的,无形中省去了很多人力成本。

通过容器云的落地,我们得到了一个面向服务的平台,把机器资源抽象,屏蔽了和发布无关的机器细节、部署细节,开发不用再了解自己的应用在哪一台物理机上面。运维也可以从茫茫多的管理表格中解脱出来,只需要关注集群利用率,添加机器资源即可。这样有利于公司DevOps的推行,提高开发效率和开发个体的创造力不再被运维限制,大大提升团队生产力。

接下来,我们还会根据自身的需求迭代服务治理、容器编排的功能,把管理集群的常规操作平台化,尽量做到日常操作可以不登录物理机去操作。

原文链接:房多多容器化和容器云实践(作者:王开)

Docker Swarm 在持续集成测试中的应用

Andy_Lee 发表了文章 • 0 个评论 • 1124 次浏览 • 2018-10-21 16:10 • 来自相关话题

#背景 敏捷(Agile)模式被广泛应用,测试显得尤为重要。由于需要频繁发布新的版本,我们需要更加频繁的执行测试用例,以确保没有新的 bug 被引入到版本中。 一个完整的测试流程所需要占用的时间和资源也不可忽视,包括 ...查看全部
#背景

敏捷(Agile)模式被广泛应用,测试显得尤为重要。由于需要频繁发布新的版本,我们需要更加频繁的执行测试用例,以确保没有新的 bug 被引入到版本中。

一个完整的测试流程所需要占用的时间和资源也不可忽视,包括对测试结果的分析都要占用大量的资源。如何在更短时间内,提供完整、全面的测试以保证质量,是我们急于解决的问题,也是保证敏捷开发能顺利进行的关键。

Jenkins 实现了无人值守的测试流程,开发结束后,一旦在测试环境部署成功,下游的测试任务就会即刻执行。

Jenkins 的应用在一定程度上节省了人力资源,而 Docker 技术可以实现容器 (Container) 快速的拓展,从而节省了大量的设备资源和时间,快速的完成测试。这在 Jenkins Pipeline(代码流水线管理)中是非常重要的一个环节,如图 1 所示:
1.png

图 1. Jenkins Pipeline

本文主要介绍如何利用 Docker Swarm 集群功能和 Selenium Grid 脚本分发功能,来搭建一个可以动态扩容的 Selenium 自动化脚本执行环境。相比于用真实的机器作为 Selenium 自动化脚本执行环境,使用此套环境可以极大的减少对执行环境的维护工作,比如各种浏览器类型的管理和版本的管理。也能极大的减少对脚本执行环境的物质投入,节省各类资源。
#搭建 Docker Swarm 集群

##Swarm 简介

Swarm 是 Docker 官方提供的一款集群管理工具,用来管理 Docker 集群,它将若干台 Docker 主机抽象为一个整体,并且通过一个入口统一管理这些 Docker 主机上的各种 Docker 资源。

Swarm 只是一个调度器(Scheduler)加路由器(Router),Swarm 自己不运行容器,它只是接受 Docker 客户端发送过来的请求,调度适合的节点来运行容器,这意味着,即使 Swarm 由于某些原因挂掉了,集群中的节点也会照常运行,当 Swarm 重新恢复运行之后,它会收集重建集群信息。

Swarm 和 Kubernetes 比较类似,但是更加轻,具有的功能也较 Kubernetes 更少一些。
##环境准备

为了搭建 Docker Swarm 集群环境,我在示例中准备了两台机器。一台作为 manager 节点,同时也作为一个 worker 节点,另一台只作为一个 worker 节点。

这里假设我们的两个机器 IP 信息如下:

* M1:10.13.181.1
* M2:10.13.181.2

Docker Engine 从 V1.12.0 版本开始,原生集成了 Docker Swarm,所以只要在每台机器上安装 Docker,就可以直接使用 Docker Swarm。在这里,关于 Docker 的安装不再详细介绍,请按照官方 Docker Swarm 文档进行安装。安装完成后,在每台机器上将 Docker 服务启动。

提示:

注意:最好关闭机器上的防火墙,否则可能会出现 Swarm 集群网络连接问题。

关闭防火墙的命令:systemctl stop firewalld.service

禁止防火墙开机启动命令:systemctl disable firewalld.service
##步骤

1、创建管理节点。

我们将机器 M1 作为 manager 节点,在这台机器上执行命令来初始化集群环境。命令如下:
sudo docker swarm init --advertise-addr 10.13.181.1

执行此命令后,会返回一个用于加入集群的令牌(Token),以便其他 worker 加入此集群。

清单 1. 加入集群令牌示例:
docker swarm join --token SWMTKN-1-5p3kzxhsvlqonst5wr02hdo185kcpdajcu9omy4z5dpmlsyrzj-
3phtv1qkfdly2kchzxh0h1xft 10.13.181.1:2377

如果想再次获取加入集群的命令,可以通过执行以下命令获取:
sudo docker swarm join-token worker

2、将机器 M1 也作为 worker 节点添加到集群。

在 manager 节点机器上运行清单 1 的命令,即可将机器 M1 也作为 worker 加入 swarm 集群当中。

3、将另一台机器 M2 作为 worker 节点添加到集群。

在机器 M2 上执行上述清单 1 中的命令,即可实现 M2 加入集群的功能。

4、运行如下命令创建集群网络:
sudo docker network create -d overlay seleniumnet

这里,seleniumnet 即是我们所创建的集群网络名称。

5、在新建的集群网络上创建 Selenium Grid 服务。

a. 创建 Selenium Grid Hub 服务。基于集群网络 seleniumnet,将 4444 端口映射到集群的 4444 端口,将 timeout 时间设置为 120 秒,可以增大或减少 timeout 时间,如清单 2 所示。

清单 2. 创建 Selenium Grid Hub 服务:
sudo docker service create --name selenium-hub --network seleniumnet -p 4444:4444 -e 
GRID_TIMEOUT=120 selenium/hub

b. 创建 Selenium Grid Firefox 节点服务并连接到刚创建 Hub 服务。如清单 3 所示。

清单 3. 创建 Selenium Grid Firefox 节点服务:
sudo docker service create \
--name node-firefox \
--replicas 5 \
-p 7900:5900 \
--network seleniumnet \
-e HUB_PORT_4444_TCP_ADDR=selenium-hub \
-e HUB_PORT_4444_TCP_PORT=4444 \
selenium/node-firefox-debug bash -c 'SE_OPTS="-host $HOSTNAME" /opt/bin/entry_point.sh'

参数说明:

-p: 7900:5900 将 Docker 内部 VNC5900 暴露到宿主机的 7900 端口,使得用户可以通过 VNC 从外面监控 Docker 内部的执行情况。

c. 创建 Selenium Grid Chrome Node 服务并连接到刚创建 Hub 服务。如清单 4 所示。

清单 4. 创建节点服务:
sudo docker service create \
--name node-chrome \
--replicas 3 \
-p 7901:5900 \
--network seleniumnet \
-e HUB_PORT_4444_TCP_ADDR=selenium-hub \
-e HUB_PORT_4444_TCP_PORT=4444 \
selenium/node-chrome-debug bash -c 'SE_OPTS="-host $HOSTNAME"
/opt/bin/entry_point.sh'

参数说明:

-p: 7901:5900 将 Docker 内部 VNC5900 暴露到宿主机的 7901 端口,使得用户可以通过 VNC 从外面监控 Docker 内部的执行情况。

6、检查环境搭建是否成功。在机器 M1 上执行以下命令,查看每个服务是否启动成功:
sudo docker service ls

可以看到 Selenium Hub 和 Firefox 节点、Chrome 节点都已经成功启动。Firefox 的节点副本是 5,Chrome 的节点副本是 3,如图 2 所示。
2.png

图 2. Docker 服务清单

我们再通过任意一台机器的 IP 加 4444 端口来打开 Selenium Hub URL 来查看已启动的 Firefox 和 Chrome 节点是否已经成功挂载到 Hub 节点上,如图 3 所示。

Hub url: 10.13.181.1:4444
image003.png

图 3. Selenium Hub 的界面图

从图 3 可以看出,5 个 Firefox 节点和 3 个 Chrome 节点都已经成功挂载到 Hub 节点上。说明此时 Docker Swarm 环境里已经提供了 5 个 Firefox 节点和 3 个 Chrome 节点可以用来执行 Selenium 自动化测试脚本。
##扩容方法

用户可以根据脚本执行数量,随时动态的扩容各个节点的数量,提高自动化脚本的执行效率,例如我们需要 10 个可以运行 Firefox 浏览器的 Container,对应的命令如下:
sudo docker service scale node-firefox=10

#在 Docker Swarm 运行 Jenkins Job

用户在 Docker Swarm 中运行 Jenkins Job,并不需要在 Jenkins 做多余的配置,而是需要在对应的自动化脚本中调用 Selenium Hub,从而以远程的方式调用 WebDriver。这样就实现了在 Docker Container 中运行 Selenium 脚本。

以本文中的场景为例,只需要在自动化脚本中调用远程 Selenium Hub 即可,如下所示:
http://9.111.139.104:4444/wd/hub

#在 Selenium Grid 中运行自动化脚本

##基本概念

Selenium Grid,用于分布式自动化测试,也就是说一套 Selenium 代码可在不同的环境上运行,这样做可以方便的将应用运行在 Docker 所提供的不同 Container 中。

Selenium Grid 有两个概念:

* Hub:主节点,你可以看作总调度中心。
* Node:分支节点,你可以看作是真正执行任务的 worker。

也就是说在 Selenium Grid 中只能有一个主 Hub,但可以在本地或远程建立 N 多个分支节点,测试脚本指向主 Hub,由主 Hub 分配给本地/远程节点运行测试用例。
##实现方式

要实现在 Selenium Grid 中运行自动化脚本,首先我们要创建一个 remote driver 的对象,可以通过图 4 源码实现,截图中所对应的输入参数 selhub 是 Selenium hub 的 URL:
http://9.111.139.104:4444/wd/hub

image004.png

图 4. 自动化脚本的代码截图

通过调用上述的 driver,就可以实现将自动化脚本运行在 Docker Container 中。
#结束语

在持续集成测试中,将测试部署到 Docker Swarm 中,通过 Selenium Grid 自动分配执行测试的节点,可以提升测试效率,增大测试的范围,在快速迭代中能够更好的保证所交付的产品质量,节省测试资源。

原文链接:https://www.ibm.com/developerworks/cn/devops/d-docker-swarm-ci-test-application/index.html

容器中的MySQL迁移RDS,会话却“爆了”

尼古拉斯 发表了文章 • 0 个评论 • 2253 次浏览 • 2018-05-03 12:37 • 来自相关话题

Swirl:Docker Swarm 集群管理的新选择

cuigh 发表了文章 • 2 个评论 • 2331 次浏览 • 2018-03-14 12:21 • 来自相关话题

# SWIRL GitHub 地址:https://github.com/cuigh/swirl [Swirl](https://github.com/cuigh/swirl) 是一个 Docker 管理工具 ...查看全部
# SWIRL

GitHub 地址:https://github.com/cuigh/swirl

[Swirl](https://github.com/cuigh/swirl) 是一个 Docker 管理工具,专注于 Swarm 集群。

主要功能

* Swarm 各组件管理,包括服务、网络、任务等
* 镜像与容器管理
* Compose 管理与部署
* 服务状态监控(基于 Prometheus)
* 服务自动伸缩
* 支持 LDAP 认证
* 基于 RBAC 完整的权限控制模型
* 支持横向扩展部署
* 多语言支持
* 更多功能...

Snapshots

# 首页



# 服务列表



# 服务监控



# 服务编排管理



# 系统设置



配置

# 使用配置文件

所有选项都可以通过 `config/app.yml` 配置文件来设置。

```yaml
name: swirl
banner: false

web:
address: ':8001'
authorize: '?'

swirl:
db_type: mongo
db_address: localhost:27017/swirl
# docker_endpoint: tcp://docker-proxy:2375

log:
loggers:
- level: info
writers: console
writers:
- name: console
type: console
layout: '[{L}]{T}: {M}{N}'
```

# 使用环境变量

3 个主要的设置支持通过环境变量来设置,便于以 Docker 方式部署。

| Name | Value |
| --------------- | ------------------------------------------------|
| DB_TYPE | mongo |
| DB_ADDRESS | localhost:27017/swirl |
| DOCKER_ENDPOINT | tcp://docker-proxy:2375 |

# 使用 Swarm 的 Config 功能

Docker 从 v17.06 版本起,内置了配置管理模块,服务可以直接挂载存储在集群中的配置文件,因此你也可以通过这种方式来挂载 Swirl 的配置文件。

部署

# 独立部署

编译后把 swirl 执行文件和 config/assets/views 这 3 个目录复制到服务器任意目录中,直接运行即可。

```bash
./swirl
```

# Docker 方式

```bash
docker run -d -p 8001:8001 \
--mount type=bind,src=/var/run/docker.sock,dst=/var/run/docker.sock \
-e DB_TYPE=mongo \
-e DB_ADDRESS=localhost:27017/swirl \
--name=swirl \
cuigh/swirl
```

# Docker Swarm 方式

```bash
docker service create \
--name=swirl \
--publish=8001:8001/tcp \
--env DB_ADDRESS=localhost:27017/swirl \
--constraint=node.role==manager \
--mount=type=bind,src=/var/run/docker.sock,dst=/var/run/docker.sock \
cuigh/swirl
```

# Docker Compose 方式

Swirl 项目中已经包含了一个简单的 Compose 部署文件,你可以使用 Docker 的 stack 命令直接部署

```bash
docker stack deploy -c compose.yml swirl
```

高级特性

Swirl 使用服务标签来实现一些高级的管理功能,下表中的标签是目前已经支持的。

名称 | 描述 | 示例
--- | --- | ---
swirl.scale | 用于控制服务自动伸缩 | `swirl.scale=min=1,max=5,cpu=30:50`

从源码构建

Swirl 使用 `dep` 作为依赖管理工具,下载源代码后,你可以使用如下两行简单的命令来构建。

```sh
$ dep ensure
$ go build
```

许可证

This product is licensed to you under the MIT License. You may not use this product except in compliance with the License. See LICENSE and NOTICE for more information.

新特性初探:Docker for Mac喜迎Kubernetes支持能力

hokingyang 发表了文章 • 0 个评论 • 9709 次浏览 • 2018-01-10 10:01 • 来自相关话题

【编者的话】很高兴内置支持Docker Swarm和Kubernetes的Mac版Docker发布了,本文将会回顾一下此工具简史,然后看看新功能的第一印象。 #为什么对开发者很重要? ...查看全部
【编者的话】很高兴内置支持Docker Swarm和Kubernetes的Mac版Docker发布了,本文将会回顾一下此工具简史,然后看看新功能的第一印象。
1.png

#为什么对开发者很重要?
Docker CE(简称Docker)是一款易用简便的容器工具,是给用户带来自主和硬件无关性体验的软件。Mac版Docker并不是从一开始就支持Kubernetes,我们看看它的简史:

Docker发端于DotCloud公司,一开始并不支持Windows和Mac,只能运行在Linux上。
#Docker简史
##虚机
最开始,如果Mac或者Linux用户想使用容器技术,就需要在Linux主机中安装如VirtualBox或者VMWare Workstation/Player之类的虚拟机工具,并设置共享目录。为了使用统一CLI工具,用户不得不采用Hashicorp公司的Vagrant

使用场景:这种方式都是过时的技术,并不建议采用。
##Docker Machine
Docker Machine是进化的第二步,采用boot2docker镜像在本地或者远程环境部署虚机,并提供可写磁盘空间,也是朝易用性迈出的一大步。一旦基于SSL认证的VM生成,Docker客户端就可以通过TCP/IP工具访问它,可以同时支持多个Docker版本构成的集群。

优点:

  • 同一主机支持多个容器后端
  • 只支持Linux
  • 使用boot2docker镜像
  • 模块化支持各家云提供商插件
缺点:
  • 命令行方式操作
  • 不支持Windows和Mac
使用场景:使用Windows 7或者Windows 10 Home,需要在本地运行一套集群,或者需要在云端运维一套集群。##Docker for Mac/WindowsDocker Machine需要太多手工操作(通过docker-machine env),为了采用TLS,有时还需要重建。Docker for Mac/Windows(简称DfM)本着造福广大使用者的初衷,内建UI和菜单支持,推出了功能有限的beta版本,刚开始主要是Twitter使用它。优点:
  • 安装简便
  • 自动配置命令行
  • 图形化界面配置
  • 一键启停作业
缺点:
  • 共享卷时性能很差
  • 高耗能降低电池使用时间
  • 支持Windows 10 pro或者enterprise
使用场景:可用,但是需要本地安装Docker Swarm或者Kubernetes。##MinikubeMinikube跟docker-machine非常类似,也依靠boot2docker,初衷是创建内含可用于开发的Docker主机的单节点Kubernetes集群。
2.png
Mac上的minikube输出案例如下:
$ minikube startStarting local Kubernetes v1.8.0 cluster...  Starting VM...  Getting VM IP address...  Moving files into cluster...  Setting up certs...  Connecting to cluster...  Setting up kubeconfig...  Starting cluster components...  Kubectl is now configured to use the cluster.  Loading cached images from config file.
优点:
  • 本地环境易于访问
  • Kubernetes可用
缺点:
  • Kubernetes在空闲时耗费大量电力
  • 感觉还是跟docker-machine很类似
  • 内置Docker版本严重滞后
  • 有些功能尚不支持,例如RBAC(role-based authentication control)
  • 需要使用minikube start/stop
使用场景:需要本地Kubernetes场景但是不必关注Docker版本。以上总结了各阶段优缺点,下面看看最新内置Kubernetes功能的DfM第一印象。#第一印象以下是我更新DfM后,使用它得到的第一印象。##开始需要Docker 17.12或者更高版本以获得Kubernetes支持,然后就是通过UI界面花几分钟下载新版本。
3.png
##上下文和命名空间如果以前安装了minikube,需要转换到DfM上下文,否则kubectl会挂起。
kubectl config use-context docker-for-desktop

如果发现有太多输出内容,Kubernetes社区有一个叫kubectx的工具可以改善输出状况。

Docker Swarm和Kubernetes之间一个不同是命名空间的支持。默认地,Kubernetes生态容器运行在称为system的隐藏命名空间,可以通过以下命令查看`kubectl get all --all-namespaces`:
4.png
输出有很多默认运行的服务,和Docker Swarm一样,区别是对用户隐藏,运行在几个固定二进制代码中,而不是分散运行的服务。以下命令可以查看Kubernetes版本:
$kubectl versionClient Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.2", GitCommit:"bdaeafa71f6c7c04636251031f93464384d54963", GitTreeState:"clean", BuildDate:"2017-10-24T19:48:57Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"darwin/amd64"}  Server Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.2", GitCommit:"bdaeafa71f6c7c04636251031f93464384d54963", GitTreeState:"clean", BuildDate:"2017-10-24T19:38:10Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} 
看起来是1.8.2版本,尽管不是最新版本但也包含了所有重要功能。##整合DockerDocker希望Kubernetes更加易用,因此整合了Docker stacks和Kubernetes原生部署服务。Kubernetes是很容易扩展的,Docker使用Custom Resource Definitions (CRDs)引入了对“栈(stack)”概念的支持. 可以验证如下:
$kubectl get stacksNo resources found.$ kubectl get crdNAME                        AGE  stacks.compose.docker.com   24d
看看对compose文件的效果:
$ docker stack deploy prometheus -c ./docker-compose.yml Stack prometheus was created  Waiting for the stack to be stable and running...   - Service exporter has one container running - Service grafana has one container running - Service prom has one container runningStack prometheus is stable and running 
CRD验证:
$ kubectl get stacksNAME         AGE  prometheus   1m
创建了几个Pods:
$kubectl get pods  NAME                        READY     STATUS             RESTARTS   AGE  exporter-66c7bbfcc6-r5sq4   1/1       Running            0          2m  grafana-7c5f5f6b75-rfgzp    1/1       Running            0          2m  prom-76b4f584f7-qckc9       0/1       CrashLoopBackOff   4          2m
Prometheus有一个bug,可以用这个命令debug:$kubectl logs pod/prom-76b4f584f7-qckc9。如果仍然使用docker-compose开发和生产,现在可以直接转向Kubernetes了。##内置工作流我们期望内置工作流能够实现:
  • kubectl apply 支持YAML
  • helm
  • RBAC激活

下面部署OpenFaaS-Serverless功能(采用Docker和Kubernetes实现起来很简单)。
$ mkdir -p go/src/github.com/openfaas/ && \
cd go/src/github.com/openfaas/ && \
git clone https://github.com/openfaas/faas-netes && \
cd faas-netes && \
kubectl apply -f ./yaml


如果碰到命名空间错误,可以在faas-netes目录下执行kubectl apply -f ./namespaces.yml ,然后再尝试一遍。



OpenFaaS会在localhost:31112启动图形界面,并启用了RBAC和两个命名空间(openfaas / openfaas-fn),输出如下:
service "alertmanager" created  
deployment "alertmanager" created
configmap "alertmanager-config" configured
service "faas-netesd" created
deployment "faas-netesd" created
deployment "gateway" created
service "gateway" created
service "nats" created
deployment "nats" created
service "prometheus" created
deployment "prometheus" created
configmap "prometheus-config" configured
deployment "queue-worker" created
serviceaccount "faas-controller" configured
role "faas-controller" configured
rolebinding "faas-controller-fn" configured

服务也创建完毕。验证如下:
$ kubectl get all --namespace openfaas

然后打开UI,部署一个应用功能:

http://localhost:31112
5.png

然后选择Figlet - figlet是Linux下二进制文件可以产生ASCII 文本logos。
6.png

查看产生的Function/Pod:
$ kubectl get all --namespace openfaas-fn
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
deploy/figlet 1 1 1 1 8m

NAME DESIRED CURRENT READY AGE
rs/figlet-676c995d66 1 1 1 8m

NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
deploy/figlet 1 1 1 1 8m

NAME DESIRED CURRENT READY AGE
rs/figlet-676c995d66 1 1 1 8m

NAME READY STATUS RESTARTS AGE
po/figlet-676c995d66-rqjpn 1/1 Running 0 8m

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
svc/figlet ClusterIP 10.101.45.157 8080/TCP 8m


相对于Docker Swarm,Kubernetes使用更多对象形成服务。



激活服务查看结果:
7.png

作业运行很顺畅,而且简单易用。对于社区维护和内置OpenFaaS整合很有帮助。

之前提过需要helm(一个类似OpenFaaS的分布式软件管理器),在Docker Swarm中没有类似的概念。

写这篇博客之前,我在Tweet上看有消息说helm也已经被支持了。

Just setup #kubernetes on the @Docker for Mac beta and did a #helm install... this is so so great!!
Adnan Abdulhussein (@prydonius) December 15, 2017

#总结
其实不仅是简单的DfM整合了“栈”,应该说在现有工具外层实现了简单化,提高了速度,更加易用。相信Docker Swarm用户都会使用这种整合,而且迁移到Kubernetes。



Docker Swarm 已死?作为Docker Captains用户组成员,我并没有更多内部消息,但是因为Docker Swarm仍然有很多用户,因此仍然会被支持。例如:最原始可以运行在容器内的Swarm仍然被Docker's UCP product支持。



如果读了developer reactions on Hacker News,可以看到Swarm仍然有很多粉丝,如果Kubernetes想吸引他们,那么on-prem安装维护过程需要提高。

因此我的第一印象总结如下:很多新功能令人振奋,尤其是对DfM的更新以及内部新元素使得它看起来更像一个LinuxKit了。
##推荐阅读
强烈推荐阅读Docker Swarm和Kubernetes不同,推荐如下博客:

* Blog - What you need to know: Docker Swarm and Kubernetes
* Read the docs on the Docker and Kubernetes integration
* Star: Award-winning OpenFaaS - serverless functions you can run yourself on Kubernetes or Docker Swarm

原文链接:First impressions: Docker for Mac with Kubernetes(翻译:杨峰)

Swarm的进化和在阿里的大规模应用实践

尼古拉斯 发表了文章 • 0 个评论 • 3191 次浏览 • 2017-10-12 18:34 • 来自相关话题

【编者的话】目前在容器编排领域,Kubernetes、Mesos以及Swarm呈现“三分天下”的格局,各自都有着不同的应用场景。短期内,很难看到“一统天下”的局面,本文,来自阿里云高级专家陈萌辉将带你了解阿里内部在推行容器化过程中的一些着力点,同时,他将深刻剖 ...查看全部
【编者的话】目前在容器编排领域,Kubernetes、Mesos以及Swarm呈现“三分天下”的格局,各自都有着不同的应用场景。短期内,很难看到“一统天下”的局面,本文,来自阿里云高级专家陈萌辉将带你了解阿里内部在推行容器化过程中的一些着力点,同时,他将深刻剖析Swarm的进化史以及在阿里云的大规模应用,最后,他给出三个案例,供大家参考。

阿里从前年开始就已经在集团内部大规模地推行容器化和运用Swarm来做应用的发布、集群管理等事情。特别值得注意的是去年,阿里云跟Docker达成了一项深度合作的协议,从中我们不难窥探阿里的容器战略。本文将从三个方面阐述“Swarm的进化和大规模应用”,第一, Swarm架构;第二,Swarm Mode的编排;第三是Swarm在阿里的应用。
#Swarm架构
1.jpg

图1 Swarm架构

我们先看一下Swarm是什么?Swarm,是Docker官方推出的,它的特点就是跟Docker本身有很好的集成,另外,它也是一个非常简单易用的工具,所以目前吸引了很多开发者在用。

Swarm是Docker公司继Docker Engine之后推出的很重要的集群管理系统和容器编排与调度系统。架构底层是集群的机器资源,可以是一些物理机也可以是一些虚拟机,上面经过Swarm这一层把容器调度和部署到这些机器上去,它对外提供跟Docker类似的API。

具体来看,Swarm的框架分成三块,第一块是Engine,第二是Manager,第三是KV store。它有几个特点,第一依赖外部存储来完成节点发现并保证一致性;第二,Manager只跟Daemon通信,不跟Agent通信;第三,Manager可以有多副本,这是为高可用设计的,采用一主多热备模式,所有manager都同时连接所有Daemon,备转发请求至主,另外,它依赖外部KV选主。
##API
Swarm提供的API,主要是有这么几类:

* 集群类:info events
* 容器类:get/list、create、start/stop等
* 镜像类:get/list、push、pull、tag等
* 数据卷类:get/list、create、delete
* 网络类:get/list、create、delete等

##调度
资源维度层面有三个: CPU 、Memory、 端口,CPU / Memory支持超卖;调度策略有两种:spread / binpack,另外,它不支持优先级、抢占。

它比较有特点的一些功能有两个,一个是叫节点约束,约束可以有两种类型,比如说你可以约束我这个节点是哪一个,你可以给节点去一个名字或者打一个标签什么的,另外一个可以通过打标签去选择一种机器,你在部署的时候,可以指定这些容器部署到哪些机器上去。

节点约束:

* 节点名:constraint:node==XXX
* 标签:constraint:key==value

亲和性也有两种,一种是image,一种是service,比如我有一个应用镜像很大,我不希望它在集群各个地方去部署,我希望他部署下来已经下载镜像的地方,这样的话可以减少一些启动的时间和下载的过程,你可以说我这个服务不是跟某个镜像做亲和,也可以跟某个服务做亲和。

亲和性:

* 镜像:affinity:image==foo
* 服务:affinity:service==foo

总结一下Swarm这个产品,Swarm整体来说有几个特点,第一个是部署简捷,只有三个模块,外部的依赖只有KV Store和Docker Daemon这两个,所有组件都容器化。第二高效友好的用户交互,高度兼容Docker Engine API,可直接使用Docker Client。第三是灵活的约束与亲和性描述,可以在一定程度上弥补调度策略的不足。

同时,我们也看到它有一些不足的地方,首先一个不足的地方就是它是容器级别的API,所有的API都是针对单个容器的,抽象层次较低。其次,响应式设计,不方便执行常驻后台的操作,它在内存中不保存任何的状态,所有的状态都是从Docker上统计过来的。有一个好处,它一旦挂掉了,能够很方便地恢复状态,但也有一些坏处,比如你要跑一个离线的任务,就不太好做。除此之外,它依赖定期同步跟Docker Engine保持一致状态。
#Swarm Mode
针对Swarm这个产品的一些不足,从1.12版本开始,Docker就提供了Swarm Mode的功能,这个功能是将Swarm的集群管理、容器调度功能集成进Docker Engine,并且提供Service级别抽象和自带的负载均衡,它从容器级别的调度器进化到了服务级别的调度器。
##架构
2.jpg

图2 Swarm Mode架构

它的架构比Swarm更简单一些,首先就是它没有任何的外部依赖,只要你装 Docker Engine,它就可以构成一个容器集群,DockerDaemon本身会兼Engine、Manager、Agent三职。Managers之间通过RAFT协议组成分布式强一致性KV Store,Manager与Worker的Daemon不通信。

同时,它也是有高可用设计的,Manager数量需要大于等于3才可以实现高可用,它也是一主多热备,另外也可以动态添加/删除Manager,如果有的机器宕机或者挂掉了,你不需要把这个机器再恢复起来,很多系统对Manager控制器的机器是有依赖的。如果一旦挂掉了你只能把它修好之后再上来,但是这个是不需要的,你可以任意在里面编程。这样他会通过RAFT协议把原来集群状态信息统一到Manager上去,这样有实现了高可用。
##Swarm Mode API
在刚才Swarm的API之上,多提供了两类的API:

集群管理类:

* init、join、leave
* token

服务类:

* get/list
* create、delete、update
* inspect、ps

同时,Swarm的API有两个特点,它分两类,一类是像Swarm、Service、Network类,只有Manager能处理的。还有一类容器、镜像、数据卷类,所有节点都能处理。另外它的API还是高度兼容旧的API,你可以拿低版本的去访问Swarm mode的集群。
##Service

我们来看一下Swarm Service的概念,它提供了三级的概念:

* Service:相同功能的一组容器
* Task:任务调度单元,由Manager生成,同步至Worker
* Container:Task落地

另外,还提供Rolling Update功能。

在Swarm mode里面Service分为两类,一类是有Replicated Service,一类是Global Service。

Replicated Service:

* 用户指定副本数
* Reconciled:自动确保副本数
* constraint

node.id node.hostname:

* node.role
* node.labels engine.labels

Global Service:

* 每个节点有且仅有一个容器
* 添加加点时自动扩展
* 可附加constraint

网络模型方面,支持overlay网络,同一网络内,服务名、容器名可解析;一个服务一个网络;服务发现支持不同服务可加入同一个网络。
##Routing Mesh
下面我们看一下Swarm自带的负载均衡,它取的名字叫做Routing Mesh,Service自带的负载均衡是基于LVS,主要有两种模式,

VIP模式:每个服务一个VIP,通过LVS实现;服务名解析至VIP;

DNS模式:服务名解析至容器IP,RoundRobin方式。另外,服务发生变化时,自动调整后端。

总结一下Swarm Mode的产品,第一个它是无任何依赖,可以安装Engine+一个命令,无中心架构。第二个它可以部署高可用服务,你可以在集群这边进行访问的,比如说你的容器只布在了三台机器,这个集群所有的机器都可以访问到这个服务,这样的话就很容易做成高可用的。再一个Secure by default,自带证书颁发、更新功能,Manager与Worker之间通过SSL连接。

当然它也有一些不足的地方,第一个只有Service级抽象,Stack级抽象仍无API,另外,部署有状态服务比较复杂。第二,Service API有很多容器特性不支持,如host network、host pid、privileged等。还有一个缺点,它无法自举,是需要手工init的。
#Swarm在阿里内部的应用
上面介绍了Docker Swarm的产品相关的东西。下面我就来介绍一下Swarm在阿里内部的应用,这个也是大家更关心的一个地方,有几个方面。第一是阿里内部的容器化,可能大家都知道,阿里内部有一支非常强大的运维团队,除非查问题的时候,一般开发人员是不接触现代的机器的,所有的应用部署、升级这些都是运维人员来做的。强大的运维团队也导致了一些问题,它的应用的部署和升级往往是很个性化的,可能这个运维人员他在支持这个应用的时候,通过写一些脚本或者用一些工具,实现业务的部署的自动化,而另外的运维人员运用另外的工具和另外的脚本,导致了很多应用的升级部署不是一个标准化的方式。这样的话,比如说这个人员他转岗了,新来的人首先要去熟悉那个部署的工具,这个运维任务比较大,所以应该是从去年、前年阿里内部开始推容器化,由Swarm来统一管理我们的集群,应用的话就是容器化之后,由Swarm去统一做部署,这样的话就会形成一个跟业务无关的统一的部署平台。运维人员不再去关心应用如何地去部署,他只要关心把这个应用部署上去就可以了,所有的应用都是一样的方式,即使有新的人接替他学起来也非常地方便。
3.jpg

图3 阿里云容器服务整体架构

另外是阿里云的专有云输出,因为专有云这个东西一旦部署到用户的机房之后,你升级就变得非常麻烦,有了容器之后,它的镜像的管理和升级就非常方便了。还有一个优点,它可以实现管控部署的资源优化,因为原来可能所有的管控都是独占机器的,这样的话比如说你布很多服务就会占很多机器,有了容器之后管控就可以共享机器了,减少了管控所占的资源,提高了用户能使用的资源的数量。

第二是阿里云的容器服务,这是我们在阿里云公有云上推出的一款产品,作用是帮用户管理集群和部署应用,当然还提供更多高级别的服务。

第三是阿里云高性能计算 HPC也会用到容器,在高计算领域,它的安装很复杂、很麻烦,经常比如说你拿到一个带显卡的机器,你在上面部署基础的应用,可能得花掉你一周的时间,如果你的应用是容器化的,这个事情就可以放到容器里面去,你只要关心自己的应用就可以了,可以大大地提高应用部署的效率。

下面重点介绍一下阿里云容器服务的一些特性,我们先看一下整体的架构,整体来说,阿里云容器服务是一个集群托管的模式,机器是用户的,但是管控是我们提供的。现在相当于我们帮用户管理他的机器,我们通过某一些界面化、某一些API的信息让用户去管理集群以及管理他的应用。

用户的机器下面会装Engine、下面会跑容器,我们这边的管控提供一个控制台,提供集群的创建和扩容这样的功能,然后提供服务、注册和发现的功能,提供应用生命周期管理和使用调度的功能。同时我们还会把很多阿里云上的服务都集成进来,比如说我们集成了SLB、ECS等功能,达到的目标让用户只关心我的应用,而不需要关心底下的机器。

我们可以看一下我们提供的功能,从四个角度讲。

第一个是集群的管理,这是最基本的功能,我们可以帮用户一键创建出一个容器集群,同时支持公有云、专有云、混合云以及敏捷版,公有云包括GPU的机器,专有云是部署在用户机房的,混合云就是你可以一部分集群管控在我们的机房,但是真正的用户机器在你自己的机房。你可以实现应用跨云的统一部署。另外还支持bare metal敏捷版。

第二是镜像服务,这是对容器化很重要的服务,我们支持公有和私有的仓库,你可以有自己的私有仓库,同时支持DockerHub的加速,我们提供这个加速的功能可以让你像访问国内的机器一样,另外可以连接第三方代码库,这样,其实你可以当成CICD系统的最重要的环节,你可以从代码到最终生成镜像,甚至到最后部署把它全自动打通。

第三是应用生命周期的管理,支持Swarm和Swarm Mode两种模式。

同时支持Rolling Update、蓝绿发布、离线与定时任务。

最后是微服务的支持,微服务它不是为容器而生,但是有了容器之后它的实现会变得更简单一些,为了微服务的支持,我们提供了一些很重要的基础的功能。包括服务发现、负载均衡、弹性伸缩、集成监控与日志、集成共享存储。

这是在阿里云上部署一个nginx应用的一个例子,这是用的3.0的模板,用Engine来部署,它可以通过8080端口来访问到。
4.jpg

图4 负载均衡案例
version: ”3.0”  #支持v1 v2 v3 compose模板
services:
nginx:
image: nginx:latest
deploy:
mode: replicated
replicas: 3
ports:
- 8080:80
labels:
aliyun.lb.port_8080`: tcp://slbtest:8080 #负载均衡
aliyun.log_store_dbstdout: stdout #日志收集
aliyun.log_store_varlog: /var/log/*.log
volumes:
- 'website:/usr/share/nginx/html'
volumes:
website:
driver: ossfs #共享存储数据卷,支持oss、nas
driver_opts:
bucket: acs-sample

自动扩容的事例,简单来说,你只要声明一下,当CPU超过70%了就扩展出两个容器来,我们的做法是通过监控平台把数据收集上去,之后,如果当它超过了70%的时候会调用集群管理的API,给它扩出容器来,同时会把负载均衡的后端再挂到新的容器上,这样就实现了自动扩容。
5.jpg

图5 自动扩容案例

声明式自动扩容
aliyun.auto_scaling.max_cpu: 70 
aliyun.auto_scaling.step: 2

监控插件

* 输入:Nagios、Apache、Docker、UDP……
* 输出:InfluxDB、Prometheus、Kafka

蓝绿发布的事例,如图6,蓝色的应用要进行升级,怎么做呢?首先部署一个新的应用,这两个是同时在线的,它会通过SLB给它分流量,比如80%和20%,之后做验证,验证之后,发布完成,系统就会把原来老的删掉。
6.jpg

图6 蓝绿发布案例

机器学习案例,假如你的集群是稳步的,有GPU机器和非GPU机器,你可以在你的Service里面注明需要两个GPU,系统会把你调度到有GPU的集群,同时把你的应用绑到GPU卡上去。
7.jpg

图7 机器学习案例
version: '2'
services:
inception:
image: acs_sample/inception:demo
volumes:
- inception_model/inception_model
labels:
- aliyun.gpu=2
ports:
- "9000:9000"
volumes:
inception_model:
driver: nas


原文链接:Swarm的进化和大规模应用

几种常见的微服务架构方案——ZeroC IceGrid、Spring Cloud、基于消息队列、Docker Swarm

尼古拉斯 发表了文章 • 0 个评论 • 3230 次浏览 • 2017-09-29 19:08 • 来自相关话题

微服务架构是当前很热门的一个概念,它不是凭空产生的,是技术发展的必然结果。虽然微服务架构没有公认的技术标准和规范草案,但业界已经有一些很有影响力的开源微服务架构平台,架构师可以根据公司的技术实力并结合项目的特点来选择某个合适的微服务架构平台,以此稳妥地实施项目 ...查看全部
微服务架构是当前很热门的一个概念,它不是凭空产生的,是技术发展的必然结果。虽然微服务架构没有公认的技术标准和规范草案,但业界已经有一些很有影响力的开源微服务架构平台,架构师可以根据公司的技术实力并结合项目的特点来选择某个合适的微服务架构平台,以此稳妥地实施项目的微服务化改造或开发进程。

本文盘点了四种常用的微服务架构方案,分别是ZeroC IceGrid、Spring Cloud、基于消息队列与Docker Swarm。
#ZeroC IceGrid微服务架构

ZeroC IceGrid作为一种微服务架构,它基于RPC框架发展而来,具有良好的性能与分布式能力,如下所示是它的整体示意图。
1.jpg

IceGrid具备微服务架构的如下明显特征。

首先,微服务架构需要一个集中的服务注册中心,以及某种服务发现机制。IceGrid服务注册采用XML文件来定义,其服务注册中心就是Ice Registry,这是一个独立的进程,并且提供了HA高可用机制;对应的服务发现机制就是命名查询服务,即LocatorService提供的API,可以根据服务名查询对应的服务实例可用地址。

其次,微服务架构中的每个微服务通常会被部署为一个独立的进程,当无状态服务时,一般会由多个独立进程提供服务。对应在IceGrid里,一个IceBox就是一个单独的进程,当一个IceBox只封装一个Servant时,就是一个典型的微服务进程了。

然后,微服务架构中通常都需要内嵌某种负载均衡机制。在 IceGrid 里是通过客户端API内嵌的负载均衡算法实现的,相对于采用中间件Proxy转发流量的方式,IceGrid的做法更加高效,但增加了平台开发的工作量与难度,因为采用各种语言的客户端都需要实现一遍负载均衡的算法逻辑。

最后,一个好的微服务架构平台应该简化和方便应用部署。我们看到 IceGrid提供了grid.xml来描述与定义一个基于微服务架构的Application,一个命令行工具一键部署这个Application,还提供了发布二进制程序的辅助工具——icepatch2。下图显示icepatch2的工作机制,icepatch2server类似于FTP Sever,用于存放要发布到每个Node上的二进制代码与配置文件,而位于每个Node上的icepatch2client则从icepatch2server上拉取文件,这个过程中采用了压缩传输及差量传输等高级特性,以减少不必要的文件传输过程。客观地评价,在Docker技术之前,icepatch2这套做法还是很先进与完备的,也大大减少了分布式集群下微服务系统的运维工作量。
2.jpg

如果基于IceGrid开发系统,则通常有三种典型的技术方案,下图展示了这三种技术方案。
3.jpg

其中方案一是比较符合传统Java Web项目的一种渐进改造方案,Spring Boot里只有Controller组件而没有数据访问层与Service对象,这些Controller组件通过Ice RPC方式调用部署在IceGrid里的远程的Ice微服务,面向前端包装为REST服务。此方案的整体思路清晰,分工明确。Leader在开源项目中给出了这种方式的一个基本框架以供参考:https://github.com/MyCATApache/mycat-ice。

方案二与方案三则比较适合前端JavaScript能力强的团队,比如很擅长Node.js的团队可以考虑方案二,即用JavaScript来替代Spring Boot实现REST服务。主要做互联网App的系统则可以考虑方案三,浏览器端的JavaScript以HTML5的WebSocket技术与Ice Glacier2直接通信,整体高效敏捷。

IceGrid在3.6版本之后还增加了容器化的运行方式,即Ice Node与Ice Registry可以通过Docker容器的方式启动,这就简化了IceGrid在Linux上的部署。对于用Java编写的Ice微服务架构系统,我们还可以借助Java远程类加载机制,让每台Node自动从某个远程HTTP Server下载指定的Jar包并加载相关的Servant类,从而实现类似Docker Hub的机制。下图显示了前面提到mycat-ice开源项目时给出的具体实现方案。
4.jpg

#Spring Cloud微服务架构

Spring Cloud是基于Spring Boot的一整套实现微服务的框架,因此它只能采用Java语言,这是它与其他几个微服务框架的最明显区别。Spring Cloud是一个包含了很多子项目的整体方案,其中由Netflix开发后来又并入Spring Cloud的Spring Cloud Netflix是Spring Cloud微服务架构的核心项目,即可以简单地认为Spring Cloud微服务架构就是Spring Cloud Netflix,后面我们用Spring Cloud时如果不特意声明,就是指Spring Cloud Netflix。

首先,Spring Cloud中的服务注册中心是Eureka模块,它提供了一个服务注册中心、服务发现的客户端,还有一个简单的管理界面,所有服务使用Eureka的服务发现客户端来将自己注册到Eureka中,如下所示为相关示意图,你会发现它很像之前第4章中的某个图。
5.jpg

那么Spring Cloud是如何解决服务的负载均衡问题的呢?由于Spring Cloud的微服务接口主要是基于REST协议实现的,因此它采用了传统的HTTP Proxy机制。如下图所示,Zuul类似一个Nginx的服务网关,所有客户端请求都通过这个网关来访问后台的服务。
6.jpg

Zuul从Eureka那里获取服务信息,自动完成路由规则的映射,无须手工配置,比如上图中的URL路径/customer/*就被映射到Customer这个微服务上。当Zuul转发请求到某个指定的微服务上时,会采用类似ZeroC IceGrid的客户端负载均衡机制,被称为Ribbon组件,下图给出了Zuul与Eureka的关系及实现服务负载均衡的示意图。
7.jpg

如下所示是Spring Cloud微服务架构平台的全景图。我们看到它很明显地继承了Spring Framework一贯的思路——集大成!
8.jpg

从图中来看,Spring Cloud 微服务架构平台集成了以下一些实际项目开发中常用的技术与功能模块。

基于Spring Security的OAuth模块,解决服务安全问题。

提供组合服务(Composite Services)的能力。

电路断路器 Hystrix,实现对某些关键服务接口的熔断保护功能,如果一个服务没有响应(如超时或者网络连接故障),则Hystrix可以在服务消费方中重定向请求到回退方法(fallback method)。如果服务重复失败,则Hystrix会快速失败(例如直接调用内部的回退方法,不再尝试调用服务),直到服务重新恢复正常。

监控用的Dashboard,可以简化运维相关的开发工作量。

总体来说,Spring Cloud是替代Dubbo的一种好方案,虽然Spring Cloud是基于REST通信接口的微服务架构,而Dubbo以RPC通信为基础。对于性能要求不是很高的Java互联网业务平台,采用Spring Cloud是一个门槛相对较低的解决方案。
#基于消息队列的微服务架构

除了标准的基于RPC通信(以及类RPC的通信如Http Rest、SOAP等)的微服务架构,还有基于消息队列通信的微服务架构,这种架构下的微服务采用发送消息(Publish Message)与监听消息(Subscribe Message)的方式来实现彼此之间的交互。下图是这种微服务架构下各个组件之间的交互示意图,我们看到消息中间件是关键,它负责连通各个微服务与UI组件,担任了整个系统互联互通的重任。
9.jpg

基于消息队列的微服务架构是全异步通信模式的一种设计,各个组件之间没有直接的耦合关系,也不存在服务接口与服务调用的说法,服务之间通过消息来实现彼此的通信与业务流程的驱动,从这点来看,基于消息队列的微服务架构非常接近Actor模型。实际上,分布式的Actor模型也可以算作一种微服务架构,并且在微服务概念产生之前就已经存在很久了。下面是一个购物网站的微服务设计示意图,我们看到它采用了基于消息队列的微服务架构。
10.jpg

网易的蜂巢平台就采用了基于消息队列的微服务架构设计思路,如下图所示,微服务之间通过RabbitMQ传递消息,实现通信。
11.jpg

与上面几种微服务架构相比,基于消息队列的微服务架构并不多,案例也相对较少,更多地体现为一种与业务相关的设计经验,各家有各家的实现方式,缺乏公认的设计思路与参考架构,也没有形成一个知名的开源平台。因此,如果需要实施这种微服务架构,则基本上需要项目组自己从零开始去设计实现一个微服务架构基础平台,其代价是成本高、风险大,因此决策之前需要架构师“接地气”地进行全盘思考与客观评价。
#Docker Swarm微服务架构

Docker Swarm其实是Docker公司“高仿”Google开源的Kubernetes微服务架构平台的一个产品,但一直无法跟上对手的脚步,在业界始终缺乏影响力。2016年发布Docker 1.12时,Docker Swarm就被强行集成到了Docker Engine中而不再作为单独的工具发布了,这类似当年微软推广IE浏览器的做法。不过即使这样,也难以掩盖Docker Swarm还没成名就已经陨落的事实。

Docker Swarm的最初目标是将一些独立的Docker主机变成一个集群,如下图所示,我们通过简单的Docker命令行工具就能创建一个Swarm集群。
12.jpg

后来随着Kubernetes微服务架构平台越来越火,Docker 公司开始努力让Swarm向着Kubernetes的方向靠拢,即变成一个基于容器技术的微服务平台。下面给出了Swarm集群的结构图。
13.jpg

从图中我们看到一个Swarm集群中有两种角色的节点。

Swarm Manager:负责集群的管理、集群状态的维持及调度任务(Task)到工作节点(Swarm Node)上等。

Swarm Node:承载运行在Swarm集群中的容器实例,每个Node主动汇报其上运行的任务(Task)并维持同步状态。

上图中的Docker Compose是官方编排(Orchestration)项目,它提供了一个YAML格式的文件,用于描述一个容器化的分布式应用,并且提供了相应的工具来实现一键部署的功能。下图给出了两节点的Couchbase集群对应的YAML文件定义,此Couchbase集群随后被部署到了Swarm集群中的两个Node节点上。
14.jpg

注意上图左边YAML文件中的Services定义,Swarm manager节点给每个Service分配唯一的DNS名字,因此可以通过最古老又简单的DNS轮询机制来实现服务的发现与负载均衡,这明显借鉴了Kubernetes的做法。
由于Docker Swarm高仿了前辈Kubernetes的设计,而且在微服务架构中并没有太多的影响力,所以我们在此并未做深入介绍。

原文链接:http://www.broadview.com.cn/article/348

Docker 管理工具的选择:Kubernetes 还是 Swarm?

kurtzhong 发表了文章 • 0 个评论 • 29642 次浏览 • 2017-07-31 02:42 • 来自相关话题

【编者的话】选择Kubernetes 或者 Swarm 就像在将 Linux 桌面发行版的范围缩小到两个后选出一个最喜欢的。哪个更满足你的需要如何才是决定因素。 【3 天烧脑式基于Docker的CI/CD实战训练营 | 北京站】本次培 ...查看全部
【编者的话】选择Kubernetes 或者 Swarm 就像在将 Linux 桌面发行版的范围缩小到两个后选出一个最喜欢的。哪个更满足你的需要如何才是决定因素。

【3 天烧脑式基于Docker的CI/CD实战训练营 | 北京站】本次培训围绕基于Docker的CI/CD实战展开,具体内容包括:持续集成与持续交付(CI/CD)概览;持续集成系统介绍;客户端与服务端的 CI/CD 实践;开发流程中引入 CI、CD;Gitlab 和 CI、CD 工具;Gitlab CI、Drone 的使用以及实践经验分享等。

Docker 容器技术已经成为推动云技术发展最重要的技术之一。如果你还没有使用容器技术,那么你很可能很快就会使用到它,不管以什么样的方式。

使用这种技术有两个步骤。首先,你需要理解容器的概念。然后你需要有一个编排工具来处理容器的调度和管理。最终选择谁取决于技术偏好和需求。

Docker是一种高级技术,能给用户带来很多计算方面的优势。这篇入门介绍是该复杂的计算机进程的一个概要。将使用简单直接的方式呈现它的基础知识。

Docker是一个容器的软件平台。容器将一个计算任务 - 或者一系列任务 - 所有需要的东西打包然后在隔离的环境中运行它们。简单来说,容器能为一个软件包提供运行的平台,而不需要一个完整的操作系统的支持。

这个简单的描述让容器听起来就像一个被吹嘘的虚拟机。但是这并不正确。一个VM可以部署很多的服务,并在一个计算机上运行不同的计算进程。然后这个宽泛的解释基本上一样适用于容器,它们的不同点在于部署方式。

例如,这两种方式的一个本质区别是用来运行它们的裸机(bare metal)。VM需要一个宿主计算机,并且必须要能共享它的资源。VM 运行在 hypervisor 上,其充当管理工具的功能。结果,不是所有的计算机都能支持虚拟复制。

这个支持取决与计算机的处理器。这个限制是巨大的。要在一个计算机上运行很多的VM会话或者服务器受到宿主机器资源富裕量的限制。

虚拟机需要依赖于一个安装好的操作系统才能运行。而容器,只需要操作系统的某些部分就能运行。这意味着容器的运行效率更高、资源占用更少,使得它们相较于VM更实用,发挥更好的计算作用。

另外一个重要的差别是VM可以在隔离的环境下运行应用,而容器没有独立运作的能力并因此遭致问题。因为容器没有操作系统或者 hypervisor,它们需要有自己的管理系统。

目前有两个流行的开源技术在这个容器控制领域进行竞争。Docker开发了Swarm,现在将它整合进了 Docker Toolbox。另外一个更加成熟的容器管理器是 Google 的Kubernetes。它们都解决了缺乏独立运行能力的问题,通过提供一个能跨多主机、多数据中心、多云环境运行的系统。

选择权在你手里。不管你选了哪一个,Docker都能运行的很好。决定那个工具最好,首先是要理解它们的不同点。
# Kubernetes
Kubernetes是一个开源的可以用来自动部署、伸缩和管理容器化应用的系统。Kubernetes集群包含一些基本组成部分。这里是简要的概括一下:

  • Kubernetes成组地部署和调度容器,这个组叫Pod,常见的Pod包含一个到五个容器,它们协作来提供一个 Service。
  • Kubernetes默认使用扁平的网络模式。通过让在一个相同 Pod 中的容器共享一个 IP 并使用 localhost 上的端口,允许所有的 Pod 彼此通讯。
  • Kubernetes 使用 Label 来搜索和更新多个对象,就好像对一个集合进行操作一样。
  • Kubernetes 会搭设一个 DSN 服务器来供集群监控新的服务,然后可以通过名字来访问它们。
  • Kubernetes 使用 Replication Controller 来实例化的 Pod。作为一个提升容错性的机制,这些控制器对一个服务的中运行的容器进行管理合监控。
# SwarmDocker的开发者现在将Docker Machine、Compose 和 Swarm 整合进了 Docker Toolbox 中。你可以对这三驾马车进行配置来让它们负责容器的配置、管理或者集群化容器。Docker Swarm,现在作为一个 beta 版本,是一个 Docker 的集群化工具。它通过使用一个或者多个 Docker 主机来组成一个 Swarm 集群。 Swarm 的设计是将容器打包到主机上,所以它能为更大的容器预留其他的主机资源。较之于随机地将容器调度到集群中的一个主机上,这种集群的组成方式能取得更加经济的伸缩性能。下面是 Swarm 和 Kubernetes 关键的不同点:
  • Swarm 有能将一组 Docker 引擎转变为一个虚拟的 Docker 引擎的原生能力。
  • 一个 swarm 只包含两个组件:agent 和 manager。
  • 一个集群有一个主机来运行一个 Swarm agent,另外一个主机来运行 Swarm manager。
  • 这对于运作来说是必要的,因为 manager 负责容器在主机上的编排和调度。
  • Swarm 使用一个发现机制来处理主机的发现和向集群的添加。
  • Swarm 提供了标准的 Docker API。这使得它提供了开箱即用的能力,能让所有既有的 Docker 管理工具 - 包括第三方的产品- 能自动地、透明地在多个主机上进行伸缩。

# 细微的不同点
两种方式 - Kubernetes 和 Swarm 都能处理同一种类型的工作负载,以云原生应用的方式。然而,一个很大的不同点是如何处理伸缩。

在Kubernetes中,每一个应用层被定义成一个 Pod。一次部署或者复制控制器可以手工地或自动地处理伸缩。在Swarm中,对于单个容器的伸缩定义在 Compose 文件中。

其他的不同点在于管理器系统如何处理高可用、负载均衡、应用滚动更新和回滚、日志和监控、存储、网络、服务发现以及性能合伸缩性上。
# 结论
Kubernetes 和 Swarm 都能大规模构建虚拟的容器。它们提供了用来取得同样目标的两个方式。它们有不同的运作方法,提供了可能更加适合你特定需求的功能。

不要仅仅因为 Docker Swarm 是Docker Toolkit 自带的就是用它作为解决方案。首先,让你的 IT 团队的成员上手熟悉两种工具。然后让 IT 团队根据自己公司的情况来建言,哪一种方式配置和部署更加容易。

用最简单的比喻来说,选择Kubernetes 或者 Swarm 就像在将 Linux 桌面发行版的范围缩小到两个后选出一个最喜欢的。哪个更满足你的需要如何才是决定因素。

原文链接:Choose your Docker Management Tool: Kubernetes or Swarm(翻译:钟最龙)

swarm overlya 和 Fannel配置

mgnetwork 发表了文章 • 0 个评论 • 3165 次浏览 • 2017-07-18 21:17 • 来自相关话题

docker swarm overlya 和 flannel 这里就不普及flannel原理了,网上N多,再不行去官网 环境 centos 7 我使用的默认的yum源 不改 ...查看全部
docker swarm overlya 和 flannel


这里就不普及flannel原理了,网上N多,再不行去官网

环境 centos 7
我使用的默认的yum源 不改

192.168.1.108
192.168.1.107
关防火墙 selinux


192.168.1.108
Yum install -y etcd docker flannel
192.168.1.107
Yum install -y docker flannel

搭建doccker swarm

启动docker (开机启动、现在启动)

docker swarm init

如果宿主机有多个IP 请加--advertise-addr 指定IP
生成token
分两种 一种为manager,另一种worker
Docker swin-toke --help 自己查看

在107主机上启动docker
把108上的token CP到107上执行 (不知道请查看官方文档)

回到108上

Docker node ls 查看docker swarm

1.png



Docker network ls 查看docker swarm的网络 支持桥、overlya 、host的
2.png




Ip add查看宿主机docker 网络


3.png


Down镜像 我使用的国内的 (怪我哦,国内下载快)
我这里比较懒 没有做私有仓库,就在两台宿主机上下载了同一个镜像

Docker swarm创建一个服务 看一下两个容器的ip
新建设一个overlay网络,在创建一个服务

4.png


5.png



两台宿主机上运行了容器



6.png

7.png





进入两个容器,查看IP,并PING一下,


8.png

9.png




Fannel配置

好了现在配置etcd

10.png


启动etcd,并执行下面的命令 创建一个172.30的网络
11.png




Flannel配置 两台主机配置
12.png




启动flanneld 但先关了docker ,启动后ip a查看宿主IP 可以发现有一个172.30刚刚自己创建的网段


13.png


14.png


创建一个服务, 不指定网络


15.png





猜一下 容器会使用哪个网络



试试能不能ping通