数人云

数人云

数人云官网
用户手册

用户手册

数人云用户手册
Mesos中文文档

Mesos中文文档

开源, 欢迎大家修改优化

centos7 搭建Docker Registry

zhaoshaolin 发表了文章 • 0 个评论 • 755 次浏览 • 2016-04-22 15:47 • 来自相关话题

registry2.x版本比1版本的速度快而且加了认证

环境规划:

192.168.0.167 Registry
192.168.0.168 client

192.168.0.167

1.安装并启动docker

1
2
3
4
5
6
7
8
9
10
11
12
13
#添加yum源
[root@Registry ~]# sudo tee /etc/yum.repos.d/docker.repo <<-'EOF'
[dockerrepo]
name=Docker Repository
baseurl=
enabled=1
gpgcheck=1 
gpgkey=
 EOF
#安装Docker
[root@Registry ~]# yum install docker-engine
#启动Dcoekr
[root@Registry ~]# service docker start

2.拉取本地私有仓库registry    #registry:2.1.1是2版本

1
[root@Registry ~]# docker pull registry:2.1.1

3.基于私有仓库镜像运行容器

1
[root@Registry ~]# docker run -d -v /opt/registry:/var/lib/registry -p 5000:5000 --restart=always --name registry registry:2.1.1

5.访问私有仓库

1
2
[root@Registry ~]# curl 127.0.0.1:5000/v2
{"num_results": 0, "query": "", "results": []}    #私有仓库为空,没有提交新镜像到仓库中

6.从Docker HUB 上拉取一个镜像测试

1
[root@Registry ~]# docker pull busybox

7.创建镜像链接为基础镜像打个标签

1
[root@Registry ~]#  docker tag busybox 192.168.0.167:5000/busybox

8.修改docker配置文件,指定私有仓库url

1
2
3
4
5
#修改配置文件
[root@Registry ~]#  vim /lib/systemd/system/docker.service 
ExecStart=/usr/bin/docker daemon -H fd://  --insecure-registry 192.168.0.98:5000
#重启Docker
[root@Registry ~]# systemctl daemon-reload  && systemctl restart docker

9.上传镜像到本地私有仓库

1
docker push 192.168.0.167:5000/busybox

10.查看私有仓库是否有对应的镜像

1
浏览器访问 192.168.0.167:5000/v2/_catalog

192.168.0.168

1.安装并启动docker

····省略

2.修改docker配置文件,指定私有仓库url

1
2
3
4
[root@localhost ~]# vim /lib/systemd/system/docker.service 
修改此行
ExecStart=/usr/bin/docker daemon -H fd://  --insecure-registry 192.168.0.98:5000'
[root@localhost ~]# systemctl daemon-reload  && systemctl restart docker

3.测试,下载刚才上传的镜像

1
[root@localhost ~]# docker pull 192.168.0.167:5000/busybox 查看全部
registry2.x版本比1版本的速度快而且加了认证

环境规划:

192.168.0.167 Registry
192.168.0.168 client

192.168.0.167

1.安装并启动docker

1
2
3
4
5
6
7
8
9
10
11
12
13
#添加yum源
[root@Registry ~]# sudo tee /etc/yum.repos.d/docker.repo <<-'EOF'
[dockerrepo]
name=Docker Repository
baseurl=
enabled=1
gpgcheck=1 
gpgkey=
 EOF
#安装Docker
[root@Registry ~]# yum install docker-engine
#启动Dcoekr
[root@Registry ~]# service docker start

2.拉取本地私有仓库registry    #registry:2.1.1是2版本

1
[root@Registry ~]# docker pull registry:2.1.1

3.基于私有仓库镜像运行容器

1
[root@Registry ~]# docker run -d -v /opt/registry:/var/lib/registry -p 5000:5000 --restart=always --name registry registry:2.1.1

5.访问私有仓库

1
2
[root@Registry ~]# curl 127.0.0.1:5000/v2
{"num_results": 0, "query": "", "results": []}    #私有仓库为空,没有提交新镜像到仓库中

6.从Docker HUB 上拉取一个镜像测试

1
[root@Registry ~]# docker pull busybox

7.创建镜像链接为基础镜像打个标签

1
[root@Registry ~]#  docker tag busybox 192.168.0.167:5000/busybox

8.修改docker配置文件,指定私有仓库url

1
2
3
4
5
#修改配置文件
[root@Registry ~]#  vim /lib/systemd/system/docker.service 
ExecStart=/usr/bin/docker daemon -H fd://  --insecure-registry 192.168.0.98:5000
#重启Docker
[root@Registry ~]# systemctl daemon-reload  && systemctl restart docker

9.上传镜像到本地私有仓库

1
docker push 192.168.0.167:5000/busybox

10.查看私有仓库是否有对应的镜像

1
浏览器访问 192.168.0.167:5000/v2/_catalog

192.168.0.168

1.安装并启动docker

····省略

2.修改docker配置文件,指定私有仓库url

1
2
3
4
[root@localhost ~]# vim /lib/systemd/system/docker.service 
修改此行
ExecStart=/usr/bin/docker daemon -H fd://  --insecure-registry 192.168.0.98:5000'
[root@localhost ~]# systemctl daemon-reload  && systemctl restart docker

3.测试,下载刚才上传的镜像

1
[root@localhost ~]# docker pull 192.168.0.167:5000/busybox

数人云 | 分布式架构实践的深圳之约,不负春光不负卿

宁静胡同 发表了文章 • 0 个评论 • 246 次浏览 • 2016-04-14 13:02 • 来自相关话题

数人云技术分享课从第一期的 “ Hold 住高并发,唯架构与运维不可辜负” 到第二期的 “ 进阶百万并发背后的架构实践 ”,邀请了一线互联网金融、电商的架构、运维大牛来分享实践经验,旨在为开发者提供最接地气的观点和干货。

世界那么大,小数决定出去看看那些未曾谋面的技术小伙伴,不能让友谊的小船说翻就翻:) 4月23日,数人云技术分享课将来到深圳,邀请了平安科技、Coding 的技术大牛以及运维界大拿老王(王津银)一起聊聊分布式架构实践的那些事儿。

 与大牛面对面  

王津银,优维科技创始人
07 年进入腾讯公司接触运维,经历服务器从百到万的运维历程,先后在 YY 和 UC 参与不同业务形态的运维,期间带过前端运维、数据存储运维、YY 语音、游戏 运维、运维研发等多种运维团队,对运维有着全面的理解。极力倡导互联网价值运维理念,即面向用户的价值是由自动化平台交付传递,同时由数据化来提炼和衡量。现创办优维科技公司,旨在缩短企业到达互联网运维的路径。

陈秋浩,平安科技资深中间件工程师
Padis 平安分布式平台项目经理,2011年加入平安科技,先后活跃于基础架构部的服务交付和事件处理一线。平时喜欢钻研工作中遇到的技术难题,也爱好学习开源技术,开发自动化小工具。

孙宇聪,Coding CTO
现负责 Coding.net 平台的技术方案与架构。 曾任 Google  SeniorSiteReliblity  Engineer (2007-2014)  就职于 Moutain View 总部,  曾参与设计维护 Youtube 视频转码/存储/直播管理系统(系统吞吐量超过1Peta bytes/月), 参与研发管理全球 Youtube CDN 网络(峰值流量~10Tbps), 后就职于 Google 内部云计算部门开发维护全球百万台服务器生命周期管理系统及任务管理系统。

谢乐冰,数人云 COO   
在德国工作十年,回国后加入惠普电信运营商部门,拥有多年项目经验和创业公司工作经验。在数人云负责产品售前和运营,专注行业的技术应用领域,为金融、电信、电商等行业提供服务。

 议程安排  
13:30 - 14:00    签到
14:00 - 14:15    开场
14:15 - 14:55  《Mesos在传统金融企业的实践——平安科技 Padis 平台的成长史》陈秋浩
14:55 - 15:35  《基于 Mesos+Docker 的分布式架构实践》谢乐冰 
15:35 - 16:15  《Google Borg 系统 与 Coding Docker 实践》孙宇聪
16:15 - 16:45  《DevOps 全栈运维平台的设计与实现 》王津银
 
时间:4月23日(周六) 13:00 - 17:00
 
深圳 3W 咖啡源兴店
深圳市南山区科技园北区松坪山路 1 号源兴科技大厦东座 1 层(北环大道与松坪山路交汇口)





 
活动报名链接:http://www.huodongxing.com/event/9330304410200#rd 查看全部

数人云技术分享课从第一期的 “ Hold 住高并发,唯架构与运维不可辜负” 到第二期的 “ 进阶百万并发背后的架构实践 ”,邀请了一线互联网金融、电商的架构、运维大牛来分享实践经验,旨在为开发者提供最接地气的观点和干货。

世界那么大,小数决定出去看看那些未曾谋面的技术小伙伴,不能让友谊的小船说翻就翻:) 4月23日,数人云技术分享课将来到深圳,邀请了平安科技、Coding 的技术大牛以及运维界大拿老王(王津银)一起聊聊分布式架构实践的那些事儿。

 与大牛面对面  

王津银,优维科技创始人
07 年进入腾讯公司接触运维,经历服务器从百到万的运维历程,先后在 YY 和 UC 参与不同业务形态的运维,期间带过前端运维、数据存储运维、YY 语音、游戏 运维、运维研发等多种运维团队,对运维有着全面的理解。极力倡导互联网价值运维理念,即面向用户的价值是由自动化平台交付传递,同时由数据化来提炼和衡量。现创办优维科技公司,旨在缩短企业到达互联网运维的路径。

陈秋浩,平安科技资深中间件工程师
Padis 平安分布式平台项目经理,2011年加入平安科技,先后活跃于基础架构部的服务交付和事件处理一线。平时喜欢钻研工作中遇到的技术难题,也爱好学习开源技术,开发自动化小工具。

孙宇聪,Coding CTO
现负责 Coding.net 平台的技术方案与架构。 曾任 Google  SeniorSiteReliblity  Engineer (2007-2014)  就职于 Moutain View 总部,  曾参与设计维护 Youtube 视频转码/存储/直播管理系统(系统吞吐量超过1Peta bytes/月), 参与研发管理全球 Youtube CDN 网络(峰值流量~10Tbps), 后就职于 Google 内部云计算部门开发维护全球百万台服务器生命周期管理系统及任务管理系统。

谢乐冰,数人云 COO   
在德国工作十年,回国后加入惠普电信运营商部门,拥有多年项目经验和创业公司工作经验。在数人云负责产品售前和运营,专注行业的技术应用领域,为金融、电信、电商等行业提供服务。

 议程安排  
13:30 - 14:00    签到
14:00 - 14:15    开场
14:15 - 14:55  《Mesos在传统金融企业的实践——平安科技 Padis 平台的成长史》陈秋浩
14:55 - 15:35  《基于 Mesos+Docker 的分布式架构实践》谢乐冰 
15:35 - 16:15  《Google Borg 系统 与 Coding Docker 实践》孙宇聪
16:15 - 16:45  《DevOps 全栈运维平台的设计与实现 》王津银
 
时间:4月23日(周六) 13:00 - 17:00
 
深圳 3W 咖啡源兴店
深圳市南山区科技园北区松坪山路 1 号源兴科技大厦东座 1 层(北环大道与松坪山路交汇口)

793055168495142026.jpg

 
活动报名链接:http://www.huodongxing.com/event/9330304410200#rd

报名倒计时 | 北京 Mesos User Group No.4 聚会

宁静胡同 发表了文章 • 0 个评论 • 225 次浏览 • 2016-04-14 13:01 • 来自相关话题

Hello,北京的 Mesos 爱好者们,时隔 4 个月,让我们愉快的进行第四次聚会吧,生活不止眼前的苟且,还有诗和远方的代码......
活动全程由老肖(肖德时,前红帽 Engineering Service 部门内部工具组 Team Leader,Docker/Mesos 社区代码贡献者,现数人云 CTO)主持并分享实战经验,约下老肖?就在北京 Mesos User Group No.4 聚会:)

看看谁带来了分享

马达,IBM 工程师,Mesos 代码贡献者

Agenda

K8S/Swarm/Mesos Introduction

Why integrates with Mesos?

Architecture Overview

K8S/Swarm on Mesos

Challenges

IBM Mesos on EGO

庞铮,数人云运维负责人

15 年以上运维工作经验。就职过宏碁戏谷、第三波、SQUARE ENIX CO., LTD.等。2015年加入数人云,从事数人云平台运维管理。

徐磊,去哪儿网高级运维开发工程师

负责实时日志平台的建设和维护工作,对 Mesos 有深入研究,参与《Mesos 中文文档》的翻译和整理工作,曾任职于Red Hat。

张晓光,OneAPM软件工程师

目前就职于公司基础架构部从事 Java、Scala 开发,负责公司公共服务研发以及DevOps实践。之前在业务部门带领团队完成了公司多条产品线,积累了丰富的研发和运维经验。


议程安排

13:30 - 14:00    签到
14:00 - 14:15    开场
14:15 - 14:55   《Kubernetes/Swarm on Mesos》马达
14:55 - 15:35   《基于Mesos+Docker的分布式百万并发测试实践》庞铮 
15:35 - 16:15   《从运维角度思考Mesos Framework的部署方式》徐磊
16:15 - 16:45    《基于 Marathon Event Bus 的服务发现组件》 张晓光
16:45 - 17:15    《老肖有话说》肖德时



时间:4月17日 14:00 - 17:15
地点:P2 联合创业办公社 • 北京市海淀区中关村 e 世界 A 座 B2
点击链接进入活动报名页面:
http://www.huodongxing.com/event/7329683300200#rd 查看全部

Hello,北京的 Mesos 爱好者们,时隔 4 个月,让我们愉快的进行第四次聚会吧,生活不止眼前的苟且,还有诗和远方的代码......
活动全程由老肖(肖德时,前红帽 Engineering Service 部门内部工具组 Team Leader,Docker/Mesos 社区代码贡献者,现数人云 CTO)主持并分享实战经验,约下老肖?就在北京 Mesos User Group No.4 聚会:)

看看谁带来了分享

马达,IBM 工程师,Mesos 代码贡献者

Agenda

K8S/Swarm/Mesos Introduction

Why integrates with Mesos?

Architecture Overview

K8S/Swarm on Mesos

Challenges

IBM Mesos on EGO

庞铮,数人云运维负责人

15 年以上运维工作经验。就职过宏碁戏谷、第三波、SQUARE ENIX CO., LTD.等。2015年加入数人云,从事数人云平台运维管理。

徐磊,去哪儿网高级运维开发工程师

负责实时日志平台的建设和维护工作,对 Mesos 有深入研究,参与《Mesos 中文文档》的翻译和整理工作,曾任职于Red Hat。

张晓光,OneAPM软件工程师

目前就职于公司基础架构部从事 Java、Scala 开发,负责公司公共服务研发以及DevOps实践。之前在业务部门带领团队完成了公司多条产品线,积累了丰富的研发和运维经验。


议程安排

13:30 - 14:00    签到
14:00 - 14:15    开场
14:15 - 14:55   《Kubernetes/Swarm on Mesos》马达
14:55 - 15:35   《基于Mesos+Docker的分布式百万并发测试实践》庞铮 
15:35 - 16:15   《从运维角度思考Mesos Framework的部署方式》徐磊
16:15 - 16:45    《基于 Marathon Event Bus 的服务发现组件》 张晓光
16:45 - 17:15    《老肖有话说》肖德时



时间:4月17日 14:00 - 17:15
地点:P2 联合创业办公社 • 北京市海淀区中关村 e 世界 A 座 B2
点击链接进入活动报名页面:
http://www.huodongxing.com/event/7329683300200#rd

创业技术联盟 | 【北京】公有云(O2O、电商、社交平台)案例分享会,CTO,纯技术,硬通货,成员募集中

gyo629 发表了文章 • 0 个评论 • 260 次浏览 • 2016-04-01 17:52 • 来自相关话题

【街区活动】
活动主题:公有云实践沙龙
活动时间:4月9日 14:00-17:00(13:30开始签到)
活动地点:Binggo Cafe一层大厅
活动介绍:爱大厨、tutu、家居在线CTO,分享公有云选型实战经验
参会请联系QQ:3383070003
 
【街区活动】
活动主题:公有云实践沙龙
活动时间:4月9日 14:00-17:00(13:30开始签到)
活动地点:Binggo Cafe一层大厅
活动介绍:爱大厨、tutu、家居在线CTO,分享公有云选型实战经验
参会请联系QQ:3383070003
 

PPT分享 | 数人云“百万并发” 背后的架构实践

宁静胡同 发表了文章 • 0 个评论 • 482 次浏览 • 2016-03-28 19:13 • 来自相关话题

3 月 27 日,“百万并发” 升级 2.0 讨论,数人云邀请小米、唯品会、云智慧的资深工程师一起分享支撑 “百万并发” 背后的架构实践。更加精彩的议题,更加干货的内容,依旧座无虚席的现场,小数邀你共享这场技术的盛宴——


PPT下载地址:http://pan.baidu.com/s/1pLIfWSV













嘉宾分享

《小米:OpenFalcon 应对并发的一些手段》






秦晓辉,小米运维研发技术负责人

互联网公司监控解决方案  OpenFalcon 主程,国内第一套开源 PaaS 平台 DINP 主程,企业级业务监控 Minos 作者,Gopher,现负责小米运维平台的搭建。关注运维自动化、PaaS 领域。

内容框架:

* OpenFalcon简介
* OpenFalcon中的并发场景及应对手段
* 数据采集的推拉抉择
* 中间节点快速转发与容错
* 一致性哈希分片提高吞吐容量
* 监控数据与报警策略的快速匹配
* 数据延迟写入减少rrd文件打开次数
* 报警事件按优先级入队列缓冲
* 通过限制worker数目保护后端发送接口
* 小总结

《数人云:分布式百万并发测试实践》








庞铮,数人云运维负责人

15 年以上运维工作经验。就职过宏碁戏谷、第三波、SQUARE ENIX CO., LTD.等。2015年加入数人云,从事数人云平台运维管理,在 Mesos+Docker 应用实践方面有深入研究。

内容框架:

* 什么是OCP
* 为什么要做百万压测
* 基础部署
* 发布压测应用
* 资源不够百万压测怎么办
* HA单机非超线程
* HA单机超线程
* HA超线程非 Docker 化
* 单机 Nginx + Lua NAT 模式
* 向百万继续前进

《唯品会:分布式服务框架实践与容器化演进》








邱戈川,唯品会分布式架构平台产品经理

16 个年头的 IT 老兵,除了销售和老板角色,做过 IT 中的各种角色,游走于架构与产品间。关注 Docker,  Mesos 等容器化技术领域的实践。主导的分布式服务框架已经广泛用于唯品会各大核心业务系统,以高性能、低延迟广受好评。现任唯品会( VIP.COM )基础架构部分布式服务框架、定时任务调度系统以及容器化管理平台产品经理。

内容框架:

* Part I: 分布式服务框架实践
* 什么是服务化/微服务
* 开源RPC/REST框架与服务化框架的Gap
* 注册与发现
* VIP服务化实践心得
* Binary RPC Vs. HTTP/JSON
* 调优“黑科技”
* Zookeeper的大规模部署
* Part II: 容器化演进
* VIP容器化平台概貌
* 容器化流程

《云智慧:应用系统“承压”测试实践》








陈书德,云智慧技术中心(Technical Center)资深技术咨询经理

在加入云智慧之前,拥有超过 6 年的 IT 行业咨询和项目管理经验,企业级方案顾问。拥有政企、旅游、医疗、教育和电商行业咨询经验,是资深的行业IT、云计算和应用性能解决方案顾问。现负责云智慧技术咨询的工作。

内容框架:

* 背景
* “双11 电商压力测试”
* 基于云的压力测试
* 新模式下的产品测试及发布过程
* 20用户并发性能指标汇总
* 单个请求的平均响应时间和带宽流量
* 测试指标分析-错误详情
* 典型案例分析
* 统计交易失败的种类和数量



 
活动花絮













大家提问积极踊跃








茶歇讨论依然火热










数人云CEO王璞(左)与唯品会嘉宾进行交流

另外,嘉宾演讲实录也将在近期陆续放出,敬请关注! 查看全部


3 月 27 日,“百万并发” 升级 2.0 讨论,数人云邀请小米、唯品会、云智慧的资深工程师一起分享支撑 “百万并发” 背后的架构实践。更加精彩的议题,更加干货的内容,依旧座无虚席的现场,小数邀你共享这场技术的盛宴——



PPT下载地址:http://pan.baidu.com/s/1pLIfWSV



现场总1.JPG


现场总2.JPG


嘉宾分享

《小米:OpenFalcon 应对并发的一些手段》

嘉宾1.JPG


秦晓辉,小米运维研发技术负责人

互联网公司监控解决方案  OpenFalcon 主程,国内第一套开源 PaaS 平台 DINP 主程,企业级业务监控 Minos 作者,Gopher,现负责小米运维平台的搭建。关注运维自动化、PaaS 领域。

内容框架:

* OpenFalcon简介
* OpenFalcon中的并发场景及应对手段
* 数据采集的推拉抉择
* 中间节点快速转发与容错
* 一致性哈希分片提高吞吐容量
* 监控数据与报警策略的快速匹配
* 数据延迟写入减少rrd文件打开次数
* 报警事件按优先级入队列缓冲
* 通过限制worker数目保护后端发送接口
* 小总结

《数人云:分布式百万并发测试实践》


嘉宾2.JPG



庞铮,数人云运维负责人

15 年以上运维工作经验。就职过宏碁戏谷、第三波、SQUARE ENIX CO., LTD.等。2015年加入数人云,从事数人云平台运维管理,在 Mesos+Docker 应用实践方面有深入研究。

内容框架:

* 什么是OCP
* 为什么要做百万压测
* 基础部署
* 发布压测应用
* 资源不够百万压测怎么办
* HA单机非超线程
* HA单机超线程
* HA超线程非 Docker 化
* 单机 Nginx + Lua NAT 模式
* 向百万继续前进

《唯品会:分布式服务框架实践与容器化演进》


嘉宾4.JPG



邱戈川,唯品会分布式架构平台产品经理

16 个年头的 IT 老兵,除了销售和老板角色,做过 IT 中的各种角色,游走于架构与产品间。关注 Docker,  Mesos 等容器化技术领域的实践。主导的分布式服务框架已经广泛用于唯品会各大核心业务系统,以高性能、低延迟广受好评。现任唯品会( VIP.COM )基础架构部分布式服务框架、定时任务调度系统以及容器化管理平台产品经理。

内容框架:

* Part I: 分布式服务框架实践
* 什么是服务化/微服务
* 开源RPC/REST框架与服务化框架的Gap
* 注册与发现
* VIP服务化实践心得
* Binary RPC Vs. HTTP/JSON
* 调优“黑科技”
* Zookeeper的大规模部署
* Part II: 容器化演进
* VIP容器化平台概貌
* 容器化流程

《云智慧:应用系统“承压”测试实践》


嘉宾3.JPG



陈书德,云智慧技术中心(Technical Center)资深技术咨询经理

在加入云智慧之前,拥有超过 6 年的 IT 行业咨询和项目管理经验,企业级方案顾问。拥有政企、旅游、医疗、教育和电商行业咨询经验,是资深的行业IT、云计算和应用性能解决方案顾问。现负责云智慧技术咨询的工作。

内容框架:

* 背景
* “双11 电商压力测试”
* 基于云的压力测试
* 新模式下的产品测试及发布过程
* 20用户并发性能指标汇总
* 单个请求的平均响应时间和带宽流量
* 测试指标分析-错误详情
* 典型案例分析
* 统计交易失败的种类和数量



 
活动花絮


提问2.JPG


提问1.JPG



大家提问积极踊跃



交流2.JPG


茶歇讨论依然火热



交流1.JPG




数人云CEO王璞(左)与唯品会嘉宾进行交流

另外,嘉宾演讲实录也将在近期陆续放出,敬请关注!

致产品经理: 持续集成、持续交付、持续部署和DevOps

宁静胡同 发表了文章 • 8 个评论 • 383 次浏览 • 2016-03-28 14:34 • 来自相关话题

即使产品经理每周都在与开发团队讨论新功能,团队协作紧密无间,在不断的PUSH下,新功能比以往看起来上线和更新速度快多了。但换个角度,从用户层面,其实仍然是一个缓慢的过程。那对比Flickr 和 Google这样的公司能够现在一天实现100次的更新迭代频率,这到底是怎么做到的呢?

毋庸置疑,这就是通过CI/CD在实际生产环境下带来的好处和便利,作为产品经理, 对于CI/CD概念已经并不陌生,但即使想要通过它们来给现有产品更新带来改变,仍然充满担忧顾虑和担心。 那么下面的内容,将帮助产品经理打消疑虑。

持续集成(Continuous Integration ,CI)

在传统软件开发过程中,集成通常发生在每个人都完成了各自的工作之后。在项目尾声阶段,通常集成还要痛苦的花费数周或者数月的时间来完成。持续集成是一个将集成提前至开发周期的早期阶段的实践方式,让构建、测试和集成代码更经常反复地发生。

持续集成意味着一个在家用笔记本编写代码的开发人员(嘿,史蒂夫)和另一个在办公室编程的开发人员(嘿,安妮)可以为同样的产品分别地编写软件,将其改动整合在一个叫做源存储库的地方。他们可以从各自编写的部分构建出组合的软件,并且按照他们期望的方式来测试软件。

开发人员通常使用一种叫做IC Server 的工具来做构建和集成。持续集成要求史蒂夫和安妮能够自测代码。分别测试各自代码来保证它能够正常工作,这些测试通常被称为单元测试(Unit tests)。

代码集成以后,当所有的单元测试通过,史蒂夫和安妮就得到了一个绿色构建(green build)。这表明他们已经成功地集成在一起,代码正按照测试预期地在工作。然而,尽管集成代码能够成功地一起工作了,它仍未为生产做好准备,因为它没有在类似生产的环境中测试和工作。在下面持续交付部分你可以了解到持续集成后面发生了什么。






考虑到实践持续集成,史蒂夫和安妮必须频繁地登记主代码仓库、集成和测试他们的代码。通常一小时很多次,并且每天最少一次。

持续集成的好处是,集成不再是个头疼事。软件在一直被编写和集成。在持续集成之前,集成发生在创建过程的结尾阶段,一次性完成,并且不知道要耗时多久。而现在持续集成,每天都融入到了工作方式当中。

持续交付(Continuous Delivery,CD)

让我们说回到我们的两位开发人员,史蒂夫和安妮。持续交付意味着每次史蒂夫或安妮修改、整合和构建代码时,也同时在类似于生产环境中自动测试了这段代码。我们通常将这个在不同环境发布和测试的过程叫做部署流水线。通常部署流水线有一个开发环境,一个测试环境,一个准生产环境,但是这些阶段会根据不同的团队、产品和组织而变化。例如,Mingle团队有一个阶段叫做“纸杯蛋糕”的准生产环境,而Etsy的准生产环境叫做“公主”。






在不同的环境下,安妮和史蒂夫写的代码被分别进行测试。当代码部署到生产环境它就开始了工作,这给予了他们更多的信心。并且只有当代码通过前一个环境的测试才会进入到下一个部署流水线的环境当中去。通过这种方式,安妮和史蒂夫将会从每个环境中测试并得到新的反馈,如果有失败,他们也可以在代码被应用到生产环境之前更加容易地发现问题并且修正它。

持续学习

这个过程对于业务决策者来说非常重要。它意味着如果安妮的代码通过了所有环境的测试,并将准备投入生产当中。你需要决定你的用户是否立即能够用上它。我们是否希望这个绿色构建现在投入生产?是的!一旦你的开发者完成了构建,那么一个全新的、充分测试的、可以工作的应用已经为你的用户准备好了。

持续部署(Continuous Deployment)

史蒂夫或者安妮所做的每个改动,都是通过测试环节,然后自动投入生产的实践过程。关于这个概念这个PDF有一个很棒的阐释:(http://www.paulhammond.org/201 ... k.pdf)。为了达成持续部署,你首先需要持续交付,所以这不是决定哪个优先级更高的二选一。无论如何,持续交付对于业务的决策带来更大的敏捷性,这才是真正实现业务导向的捷径。






开发运维(DevOps)

 “DevOps”这个词是“development”和“operations”的组合。DevOps已经上升为一种文化,它促使开发人员(史蒂夫和安妮你们快回来)和其他运维人员协同工作。具体地说,在软件交付和部署的过程中沟通合作,为了能够更快速更可靠地发布质量更好的应用。

拥有DevOps文化的团队通常有一个共同的特征:熟练的多技能团队(史蒂夫,安妮和乔伊都在同一团队里),高水平的测试和自动发布(按持续交付的方式)以及团队成员之间共同的目标。






一种方式是我们的开发朋友史蒂夫和安妮将同运维人员乔伊一起工作将应用交付给生产,而不是只将他们的代码“移交”给乔伊来发布。同样地,史蒂夫、安妮和乔伊都将作为共同负责所有产品支持和维护的服务团体的一部分,而不是仅由运维团队负责支持。

你还将看到自动化的实践对于持续交付和DevOps越来越重要。这是为了从持续交付和DevOps中实现可重复的、固定的和成功的应用发布流程,来避免人工处理非常容易出错、而且效率低下的问题。






DevOps文化通常和持续交付关联起来,因为他们的目标都是为了提升开发团队和运维团队之间的协作效率,都使用自动化进程来更快速、更频繁、更可靠地构建、测试和发布应用。这正是我们想要的。

接下来呢?

产品经理们已经逐步看到持续集成、持续交付和DevOps的诸多好处,那么拥抱DevOps吧,祝大家周末愉快,下周见:)


原文链接:https://wanqu.co/amp/p/2862 查看全部
即使产品经理每周都在与开发团队讨论新功能,团队协作紧密无间,在不断的PUSH下,新功能比以往看起来上线和更新速度快多了。但换个角度,从用户层面,其实仍然是一个缓慢的过程。那对比Flickr 和 Google这样的公司能够现在一天实现100次的更新迭代频率,这到底是怎么做到的呢?

毋庸置疑,这就是通过CI/CD在实际生产环境下带来的好处和便利,作为产品经理, 对于CI/CD概念已经并不陌生,但即使想要通过它们来给现有产品更新带来改变,仍然充满担忧顾虑和担心。 那么下面的内容,将帮助产品经理打消疑虑。

持续集成(Continuous Integration ,CI)

在传统软件开发过程中,集成通常发生在每个人都完成了各自的工作之后。在项目尾声阶段,通常集成还要痛苦的花费数周或者数月的时间来完成。持续集成是一个将集成提前至开发周期的早期阶段的实践方式,让构建、测试和集成代码更经常反复地发生。

持续集成意味着一个在家用笔记本编写代码的开发人员(嘿,史蒂夫)和另一个在办公室编程的开发人员(嘿,安妮)可以为同样的产品分别地编写软件,将其改动整合在一个叫做源存储库的地方。他们可以从各自编写的部分构建出组合的软件,并且按照他们期望的方式来测试软件。

开发人员通常使用一种叫做IC Server 的工具来做构建和集成。持续集成要求史蒂夫和安妮能够自测代码。分别测试各自代码来保证它能够正常工作,这些测试通常被称为单元测试(Unit tests)。

代码集成以后,当所有的单元测试通过,史蒂夫和安妮就得到了一个绿色构建(green build)。这表明他们已经成功地集成在一起,代码正按照测试预期地在工作。然而,尽管集成代码能够成功地一起工作了,它仍未为生产做好准备,因为它没有在类似生产的环境中测试和工作。在下面持续交付部分你可以了解到持续集成后面发生了什么。

1.jpg


考虑到实践持续集成,史蒂夫和安妮必须频繁地登记主代码仓库、集成和测试他们的代码。通常一小时很多次,并且每天最少一次。

持续集成的好处是,集成不再是个头疼事。软件在一直被编写和集成。在持续集成之前,集成发生在创建过程的结尾阶段,一次性完成,并且不知道要耗时多久。而现在持续集成,每天都融入到了工作方式当中。

持续交付(Continuous Delivery,CD)

让我们说回到我们的两位开发人员,史蒂夫和安妮。持续交付意味着每次史蒂夫或安妮修改、整合和构建代码时,也同时在类似于生产环境中自动测试了这段代码。我们通常将这个在不同环境发布和测试的过程叫做部署流水线。通常部署流水线有一个开发环境,一个测试环境,一个准生产环境,但是这些阶段会根据不同的团队、产品和组织而变化。例如,Mingle团队有一个阶段叫做“纸杯蛋糕”的准生产环境,而Etsy的准生产环境叫做“公主”。

2.jpg


在不同的环境下,安妮和史蒂夫写的代码被分别进行测试。当代码部署到生产环境它就开始了工作,这给予了他们更多的信心。并且只有当代码通过前一个环境的测试才会进入到下一个部署流水线的环境当中去。通过这种方式,安妮和史蒂夫将会从每个环境中测试并得到新的反馈,如果有失败,他们也可以在代码被应用到生产环境之前更加容易地发现问题并且修正它。

持续学习

这个过程对于业务决策者来说非常重要。它意味着如果安妮的代码通过了所有环境的测试,并将准备投入生产当中。你需要决定你的用户是否立即能够用上它。我们是否希望这个绿色构建现在投入生产?是的!一旦你的开发者完成了构建,那么一个全新的、充分测试的、可以工作的应用已经为你的用户准备好了。

持续部署(Continuous Deployment)

史蒂夫或者安妮所做的每个改动,都是通过测试环节,然后自动投入生产的实践过程。关于这个概念这个PDF有一个很棒的阐释:(http://www.paulhammond.org/201 ... k.pdf)。为了达成持续部署,你首先需要持续交付,所以这不是决定哪个优先级更高的二选一。无论如何,持续交付对于业务的决策带来更大的敏捷性,这才是真正实现业务导向的捷径。

3.jpg


开发运维(DevOps)

 “DevOps”这个词是“development”和“operations”的组合。DevOps已经上升为一种文化,它促使开发人员(史蒂夫和安妮你们快回来)和其他运维人员协同工作。具体地说,在软件交付和部署的过程中沟通合作,为了能够更快速更可靠地发布质量更好的应用。

拥有DevOps文化的团队通常有一个共同的特征:熟练的多技能团队(史蒂夫,安妮和乔伊都在同一团队里),高水平的测试和自动发布(按持续交付的方式)以及团队成员之间共同的目标。

4.jpg


一种方式是我们的开发朋友史蒂夫和安妮将同运维人员乔伊一起工作将应用交付给生产,而不是只将他们的代码“移交”给乔伊来发布。同样地,史蒂夫、安妮和乔伊都将作为共同负责所有产品支持和维护的服务团体的一部分,而不是仅由运维团队负责支持。

你还将看到自动化的实践对于持续交付和DevOps越来越重要。这是为了从持续交付和DevOps中实现可重复的、固定的和成功的应用发布流程,来避免人工处理非常容易出错、而且效率低下的问题。

5.jpg


DevOps文化通常和持续交付关联起来,因为他们的目标都是为了提升开发团队和运维团队之间的协作效率,都使用自动化进程来更快速、更频繁、更可靠地构建、测试和发布应用。这正是我们想要的。

接下来呢?

产品经理们已经逐步看到持续集成、持续交付和DevOps的诸多好处,那么拥抱DevOps吧,祝大家周末愉快,下周见:)


原文链接:https://wanqu.co/amp/p/2862

并存共生or相爱相杀?容器、虚拟机与Docker概念全解析

宁静胡同 发表了文章 • 2 个评论 • 328 次浏览 • 2016-03-24 19:02 • 来自相关话题

当小数看到这篇文章时内心是激动的,因为或许介绍Docker容器的文章有无数,但是如此清晰易懂、对小白如此友好的却不多见。本文立足于新手,从容器和虚拟机两个大的概念入手,由浅入深,由宏转微,为我们解析了Docker的方方面面。来吧朋友们,理解它,热爱它,然后更好地使用它。

作为程序员或者技术人员,大家肯定听说过Docker的鼎鼎大名——这款工具能够帮助我们高效打包、发布及运行承载着应用程序的“容器”系统。其发展如火如荼——从开发者到运维人员,每个人都在关注着这位技术新贵。即使是像谷歌、VMware与Amazon这样的技术巨擘也在构建相关服务为其提供支持。

无论大家是否有意立即使用Docker,我们都应当对其基础概念加以了解,并明确区分容器与虚拟机之间的差异所在。目前网络上已经存在大量对二者关联与区别的阐述性文章,不过在今天的综述中,我们将立足于新手对其加以剖析。

下面首先聊聊虚拟机与容器究竟是什么。

容器与虚拟机究竟是什么?

容器与虚拟机拥有着类似的使命:对应用程序及其关联性进行隔离,从而构建起一套能够随处运行的自容纳单元。

此外,容器与虚拟机还摆脱了对物理硬件的需求,允许我们更为高效地使用计算资源,从而提升能源效率与成本效益。

容器与虚拟机之间的核心差异在于其架构方法。下面一起进行深入了解。

虚拟机

虚拟机在本质上就是在模拟一台真实的计算机设备,同时遵循同样的程序执行方式。虚拟机能够利用“虚拟机管理程序”运行在物理设备之上。反过来,虚拟机管理程序则可运行在主机设备或者“裸机”之上。

下面用更直白的表达来说明:

虚拟机管理程序可表现为软件、固件或者硬件,并作为虚拟机的运行基础。虚拟机管理程序本身运行在物理计算机之上,我们也将这种底层硬件称为“主机设备”。主机设备为虚拟机提供资源,包括内存与CPU。这些资源由不同虚拟机共享,并根据需要进行随意分配。因此如果一套虚拟机运行有需求大量资源的高强度应用程序,那么我们可以在同一主机设备上为其分配远高于其它虚拟机的资源配额。

运行在主机设备上的虚拟机(当然,需要配合虚拟机管理程序)通常被称为一套“客户机”。这套客户机容纳有应用程序及其运行所必需的各类组件(例如系统二进制文件及库)。它同时还包含有完整的虚拟硬件堆栈,其中包括虚拟网络适配器、存储以及CPU——这意味着它也拥有自己的完整访客操作系统。着眼于内部,这套客户机自成体系并拥有专用资源。而从外部来看,这套虚拟机使用的则是由主机设备提供的共享资源。

如上所述,客户机可以运行主机虚拟机管理程序或者裸机虚拟机管理程序。二者之间存在着多种重要区别。

首先,主机虚拟机管理程序运行在主机设备的操作系统之上。举例来说,一台运行有OS X的计算机可以在操作系统之上安装虚拟机(例如VirtualBox或者VMware Workstation 8)。该虚拟机并不会直接访问硬件,因此其需要经由主机操作系统(也就是Mac OS X)实现资源获取。

主机虚拟机管理程序的优势在于,其基本摆脱了对底层硬件的要求。该主机操作系统负责提供硬件驱动程序,而非由虚拟机管理程序自身提供,因此我们认为其具备更理想的“硬件兼容性”。在另一方面,这种介于硬件与虚拟机管理程序之间的额外层会带来更多资源消耗,进而降低虚拟机性能表现。

裸机虚拟机管理程序则将虚拟机直接安装并运行在主机设备硬件之上以改善性能表现。由于其直接接入底层硬件,因此我们不再需要主机操作系统作为辅助。在这种情况下,我们可以直接在硬件上安装虚拟机管理程序并将其作为操作系统。与主机虚拟机管理程序不同,裸机虚拟机管理程序拥有自己的设备驱动程序及接口,从而直接支持各类I/O、处理或者操作系统特定任务相关组件。这种方式能够带来更理想的性能水平、可扩展性以及稳定性。但代价是其硬件兼容性比较有限,因为虚拟机管理程序只能包含一部分设备驱动程序。

说到这里,大家可能提出疑问:为什么我们非得在虚拟机与主机设备之间添加“虚拟机管理程序”呢?

这个嘛,因为虚拟机本身拥有一套虚拟操作系统,而虚拟机管理程序则负责为虚拟机提供平台以管理并运行这套访客操作系统。如此一来,主机计算机就能够为运行于其上的各虚拟机分配共享资源了。







虚拟机原理示意图

如大家所见,虚拟机会将虚拟硬件、内核(即操作系统)以及用户空间打包在新虚拟机当中。

容器
与提供硬件虚拟化机制的虚拟机不同,容器通过对“用户空间”的抽象化处理提供操作系统层级的虚拟化机制。通过对容器进行分解,大家将可以非常清晰地理解其中含义。

出于各种考量与需求,容器在外观上与虚拟机非常相似。举例来说,二者皆拥有专有处理空间、能够作为root执行命令、提供专有网络接口与IP地址、允许定制化路由及iptable规则,且可启动文件系统等等。

容器与虚拟机间的最大区别在于,各容器系统*共享*主机系统的内核。
 






容器原理示意图

以上示意图显示了容器如何对用户空间进行打包,而不像虚拟机那样同样对内核或者虚拟硬件进行打包。每套容器都拥有自己的隔离化用户空间,从而使得多套容器能够运行在同一主机系统之上。我们可以看到全部操作系统层级的架构都可实现跨容器共享。惟一需要独立构建的就是二进制文件与库。正因为如此,容器才拥有极为出色的轻量化特性。

Docker的功能定位

Docker为基于Linux容器的开源项目,其利用Linux内核中的各项功能——例如命名空间与控制组——以在操作系统之上创建容器。

容器概念并不是什么新鲜事物; 谷歌公司多年来一直在使用自己开发的容器技术。其它Linux容器技术方案还包括Solaris Zones、BSD jails以及LXC,且其都已经拥有多年的发展历史。

那么为什么Docker的出现会快速吸引到技术业界的注意?
易用性: Docker能够为潜在受众带来出色的易用性——开发者、系统管理员以及架构师等等——从而帮助其充分利用容器技术优势以快速构建并测试可移植应用程序。每个人都可以在自己的笔记本上打包应用程序,并将其直接运行在任何公有云、私有云甚至是裸机之上。其座右铭是:一次构建,随处运行。速度: Docker容器具备轻量化与高速特性。由于容器本身属于运行在内核之上的沙箱环境,因为其对资源的需求量极低。大家可以在数秒钟内完成容器的创建与运行,而虚拟机则由于需要引导完整的虚拟操作系统而耗费更多时间。Docker Hub: Docker用户还能够享受由Docker Hub带来的丰富生态系统支持,我们可以将其理解成“Docker镜像的应用商店”。Docker Hub提供成千上万由社区开发的公共镜像,且可立即加以使用。我们可以轻松根据需要搜索到合适的镜像,将其提取并稍加修改即加以使用。 模块性与可扩展性: Docker允许我们轻松将应用程序的功能拆分成多个独立容器。举例来说,我们可以将自己的Postgres数据库运行在一套容器当中,并将Redis服务器运行在另一容器内,而Node.js也拥有自己的容器系统。在Docker的帮助上,大家能够轻松将这些容器对接起来以创建完整的应用程序,这就让未来的规模伸缩或者组件更新得以通过相互独立的方式完成。

最后但同样重要的是,Docker鲸鱼实在是太惹人喜爱了~
 






Docker基本概念
现在我们对Docker有了宏观印象,下面具体对其组件进行解读:
 






Docker Engine

Docker Engine属于Docker的运行层。这是一套轻量化运行时及工具组合,负责管理容器、镜像、构建 等等。它以原生方式运行在Linux系统之上,并由以下元素构成:

Docker Daemon,运行在主机计算机之上。
Docker Client,负责与Docker Daemon通信以执行命令。
REST API,用于同Docker Daemon远程交互。

Docker Client

Docker Client正是我们作为最终用户的通信对象。我们可以将其视为Docker的UI。






我们进行的一切操作都将直接接入Docker Client,再由其将指令传递至Docker Daemon。

Docker Daemon

Docker Daemon直接将执行命令发送至Docker Client——例如构建、运行以及分发等等。Docker Daemon运行在主机设备之上,但作为用户,我们永远不会直接与该Daemon进行通信。Docker Client也可以运行在主机设备上,但并非必需。它亦能够运行在另一台设备上,并与运行在目标主机上的Docker Daemon进行远程通信。

Dockerfile

Dockerfile是我们编写指令以构建Docker镜像的载体。这些指令包括:
RUN apt-get y install some-package:安装某软件包
EXPOSE 8000: 开放端口
ENV ANT_HOME /usr/local/apache-ant:传递环境变量

类似的指令还有很多。一旦设置了Dockerfile,大家就可以利用docker build命令来构建镜像了。下面来看Dockerfile示例:







示例Dockerfile

Docker镜像

镜像属于只读模板,大家可以借此配合Dockerfile中的编写指令集进行容器构建。镜像定义了打包的应用程序以及其相关依赖。这些依赖就好像是其启动时需要运行的进程。

Docker镜像利用Dockerfile实现构建。Dockerfile中的每条指令都会在镜像中添加一个新的“层”,这些层则表现为镜像文件系统中的一个分区——我们可以对其进行添加或者替换。层概念正是Docker轻量化的基础。Docker利用一套Union File System建立起这套强大的结构:

Union File System

Docker利用Union File System以构建镜像。大家可以将Union File System视为一套可堆叠文件系统,这意味着各文件系统中的文件与目录(在Docker中被称为分支)可以透明方式覆盖并构成单一文件系统。

覆盖分支内的各目录内容拥有同样的路径,并将被视为单一合并目录,这就避免了需要为每个层分别创建副本的麻烦。相反,这些目录可调用特定指针以指向同样的资源; 当特定层需要进行修改时,其会分别创建修改前与修改后的本地副本。通过这种方式,文件系统*表现*出可写入特性,但其实际上并未接受任何写入操作。(换言之,这是一套‘写入即复制’系统。)

分层系统拥有两大核心优势:

无重复数据: 分层机制使得我们在使用镜像创建并运行新容器时无需复制完整的文件集,从而保证Docker容器实例拥有良好的运行速度与低廉的资源成本。
层隔离: 变更操作速度很快——当我们对镜像进行变更时,Docker只需要对进行了变更的层进行广播。

Volumes

Volumes属于容器中的“数据”部分,会在容器创建时进行初始化。Volumes机制允许我们持久保留并共享容器数据。数据卷 独立于默认Union File System之外,且作为普通目录及文件存在于主机文件系统当中。因此即使是在对容器进行销毁、更新或者重构时,数据卷仍然不受影响。当我们需要对某一数据卷进行更新时,直接加以变更即可。(作为另一项优势,数据卷还能够在不同容器之间进行共享与复用。)

Docker容器
如上所述,Docker容器将一款应用程序的软件打包在单一环境当中,同时包含全部运行必需的要素。其中包括操作系统、应用程序代码、运行时、系统工具、系统库等等。Docker容器由Docker镜像构建而成。由于镜像存在只读属性,因此Docker会在镜像在只读文件系统之上添加一套读取-写入文件系统以实现容器创建。
 






另外,在创建容器时,Docker还会创建一套网络接口以帮助容器同本地主机通信、对接可用IP地址并执行用户在定义镜像时所执行的进程以运行应用程序。
在成功创建了一套容器之后,我们随后可以将其运行在任何环境当中,而不必再做任何变更。

“容器”探秘

打开容器,我们会发现其中包含大量活动组件。容器的实现机制一直令我感到惊讶而好奇,特别是考虑到容器不存在任何抽象的基础设施边界。在阅读了大量材料之后,我将结合自己的理解为大家进行讲解:)

“容器”这一术语其实只是个抽象概念,用于表述多种不同的相关特性,而其与原词“container”的另一含义“集装箱”有着千丝万缕的联系。下面就来一起了解:

1) 命名空间

命名空间为容器提供对应的底层Linux系统视图,即限制容器的查看与访问范畴。当我们运行一套容器时,Docker会创建多个命名空间供特定容器使用。
Docker会在内核中使用多种不同类型的命名空间,例如:
NET: 为容器提供独特的系统网络堆栈视图(例如自有网络设备、IP地址、IP路由表、/proc/net目录、端口编号等等)。PID: PID代表进程ID。如果大家曾经在命令行中运行过ps aux以检查当前系统正在运行的进程,就会发现其中一栏名为“PID”。PID命名空间为容器提供其能够查看与交互的进程范围,其中包括独立的init(PID 1),其属于“所有进程的元祖”。MNT: 为容器提供独特的系统“mounts”视图。这样不同mount命名空间内的进程就将拥有彼此不同的文件系统结构。UTS: UTS代表UNIX分时系统。它允许某一进程识别系统身份(例如主机名称或者域名等)。UTS允许容器拥有不同于其它容器以及主机系统的主机名称与NIS域名。IPC: IPC代表进程间通信。IPC命名空间负责对运行在每套容器内的进程进行IPC资源隔离。USER: 此命名空间用于对每套容器内的用户进行隔离。其允许各容器拥有不同的uid(即用户ID)与gid(组ID)视图区间,并将其与主机系统进行比对。这样一来,某一进程的uid与gid在用户命名空间之内与之外即有所不同,这也使得该进程能够在不影响容器内root权限的情况下,撤销同一用户在容器外的权限。

Docker将这些命名空间结合起来以隔离并创建容器。下面要讲的则是控制组。

2) 控制组

控制组(也被称为cgroups)属于Linux内核中的一项功能,用于对一组进程的资源使用量(包括CPU、内存、磁盘I/O以及网络等)进行隔离、排序与计数。这意味着cgroup能够确保Docker容器只使用其必需的资源——并在必要情况下设置其所能使用的资源上限。另外,cgroups还能够确保单一容器不至于占用太多资源并导致整体系统陷入瘫痪。

最后要说明的是Union文件系统:

3) 隔离化Union file system:

我们在之前的Docker镜像章节中已经解释过了:)

这就是关于Docker容器的全部内容了(当然,实现细节才是最麻烦的环节——例如如何管理不同组件间的交互)。

Docker的未来:Docker与虚拟机将并生共存

尽管Docker已经开始逐步成为主流,但我认为它不太可能对虚拟机造成真正的威胁。容器将继续发展壮大,但虚拟机也仍然拥有适合自己的生存空间。

举例来说,如果我们需要在多台服务器上运行多款应用程序,那么最理想的办法就是使用虚拟机。在另一方面,如果我们需要运行同一应用程序的多套*副本*,那么Docker则拥有更多具体优势。

另外,尽管容器允许我们将应用程序拆分成多个功能组件,但这种分散化趋势意味着我们需要管理更多功能部件,即带来更为复杂的控制与协调任务。

安全同时也是Docker容器需要解决的一大难题——由于各容器共享同一套内核,因此不同容器之间的屏障非常薄弱。与只需要调用主机虚拟机管理程序的虚拟机方案不同,Docker容器需要向主机内核发出系统调用,而这会带来更庞大的攻击面。出于安全性的考量,很多开发人员可能更倾向于选择虚拟机——其由抽象化硬件进行隔离,从而显著提升了彼此交互的难度。

当然,安全性与管理等难题必将随着容器在生产环境下的进一步普及而得到解决。就目前来讲,关于容器与虚拟机孰优孰劣的议题已经成为开发人员与运维人员间的日常争论素材。

最后

到这里,希望大家已经拥有了关于Docker的必要知识,也祝愿各位早日将Docker引入自己的日常工作。

当然,如果大家在文章中发现了什么谬误,也欢迎在评论栏中做出说明。感谢大家,小数与你下次再见!

原文链接:
https://medium.freecodecamp.com/a-beginner-friendly-introduction-to-containers-vms-and-docker-79a9e3e119b#.sl2xp8tiv 查看全部

当小数看到这篇文章时内心是激动的,因为或许介绍Docker容器的文章有无数,但是如此清晰易懂、对小白如此友好的却不多见。本文立足于新手,从容器和虚拟机两个大的概念入手,由浅入深,由宏转微,为我们解析了Docker的方方面面。来吧朋友们,理解它,热爱它,然后更好地使用它。



作为程序员或者技术人员,大家肯定听说过Docker的鼎鼎大名——这款工具能够帮助我们高效打包、发布及运行承载着应用程序的“容器”系统。其发展如火如荼——从开发者到运维人员,每个人都在关注着这位技术新贵。即使是像谷歌、VMware与Amazon这样的技术巨擘也在构建相关服务为其提供支持。

无论大家是否有意立即使用Docker,我们都应当对其基础概念加以了解,并明确区分容器与虚拟机之间的差异所在。目前网络上已经存在大量对二者关联与区别的阐述性文章,不过在今天的综述中,我们将立足于新手对其加以剖析。

下面首先聊聊虚拟机与容器究竟是什么。

容器与虚拟机究竟是什么?

容器与虚拟机拥有着类似的使命:对应用程序及其关联性进行隔离,从而构建起一套能够随处运行的自容纳单元。

此外,容器与虚拟机还摆脱了对物理硬件的需求,允许我们更为高效地使用计算资源,从而提升能源效率与成本效益。

容器与虚拟机之间的核心差异在于其架构方法。下面一起进行深入了解。

虚拟机

虚拟机在本质上就是在模拟一台真实的计算机设备,同时遵循同样的程序执行方式。虚拟机能够利用“虚拟机管理程序”运行在物理设备之上。反过来,虚拟机管理程序则可运行在主机设备或者“裸机”之上。

下面用更直白的表达来说明:

虚拟机管理程序可表现为软件、固件或者硬件,并作为虚拟机的运行基础。虚拟机管理程序本身运行在物理计算机之上,我们也将这种底层硬件称为“主机设备”。主机设备为虚拟机提供资源,包括内存与CPU。这些资源由不同虚拟机共享,并根据需要进行随意分配。因此如果一套虚拟机运行有需求大量资源的高强度应用程序,那么我们可以在同一主机设备上为其分配远高于其它虚拟机的资源配额。

运行在主机设备上的虚拟机(当然,需要配合虚拟机管理程序)通常被称为一套“客户机”。这套客户机容纳有应用程序及其运行所必需的各类组件(例如系统二进制文件及库)。它同时还包含有完整的虚拟硬件堆栈,其中包括虚拟网络适配器、存储以及CPU——这意味着它也拥有自己的完整访客操作系统。着眼于内部,这套客户机自成体系并拥有专用资源。而从外部来看,这套虚拟机使用的则是由主机设备提供的共享资源。

如上所述,客户机可以运行主机虚拟机管理程序或者裸机虚拟机管理程序。二者之间存在着多种重要区别。

首先,主机虚拟机管理程序运行在主机设备的操作系统之上。举例来说,一台运行有OS X的计算机可以在操作系统之上安装虚拟机(例如VirtualBox或者VMware Workstation 8)。该虚拟机并不会直接访问硬件,因此其需要经由主机操作系统(也就是Mac OS X)实现资源获取。

主机虚拟机管理程序的优势在于,其基本摆脱了对底层硬件的要求。该主机操作系统负责提供硬件驱动程序,而非由虚拟机管理程序自身提供,因此我们认为其具备更理想的“硬件兼容性”。在另一方面,这种介于硬件与虚拟机管理程序之间的额外层会带来更多资源消耗,进而降低虚拟机性能表现。

裸机虚拟机管理程序则将虚拟机直接安装并运行在主机设备硬件之上以改善性能表现。由于其直接接入底层硬件,因此我们不再需要主机操作系统作为辅助。在这种情况下,我们可以直接在硬件上安装虚拟机管理程序并将其作为操作系统。与主机虚拟机管理程序不同,裸机虚拟机管理程序拥有自己的设备驱动程序及接口,从而直接支持各类I/O、处理或者操作系统特定任务相关组件。这种方式能够带来更理想的性能水平、可扩展性以及稳定性。但代价是其硬件兼容性比较有限,因为虚拟机管理程序只能包含一部分设备驱动程序。

说到这里,大家可能提出疑问:为什么我们非得在虚拟机与主机设备之间添加“虚拟机管理程序”呢?

这个嘛,因为虚拟机本身拥有一套虚拟操作系统,而虚拟机管理程序则负责为虚拟机提供平台以管理并运行这套访客操作系统。如此一来,主机计算机就能够为运行于其上的各虚拟机分配共享资源了。


1.png


虚拟机原理示意图

如大家所见,虚拟机会将虚拟硬件、内核(即操作系统)以及用户空间打包在新虚拟机当中。

容器
与提供硬件虚拟化机制的虚拟机不同,容器通过对“用户空间”的抽象化处理提供操作系统层级的虚拟化机制。通过对容器进行分解,大家将可以非常清晰地理解其中含义。

出于各种考量与需求,容器在外观上与虚拟机非常相似。举例来说,二者皆拥有专有处理空间、能够作为root执行命令、提供专有网络接口与IP地址、允许定制化路由及iptable规则,且可启动文件系统等等。

容器与虚拟机间的最大区别在于,各容器系统*共享*主机系统的内核。
 

2.png


容器原理示意图

以上示意图显示了容器如何对用户空间进行打包,而不像虚拟机那样同样对内核或者虚拟硬件进行打包。每套容器都拥有自己的隔离化用户空间,从而使得多套容器能够运行在同一主机系统之上。我们可以看到全部操作系统层级的架构都可实现跨容器共享。惟一需要独立构建的就是二进制文件与库。正因为如此,容器才拥有极为出色的轻量化特性。

Docker的功能定位

Docker为基于Linux容器的开源项目,其利用Linux内核中的各项功能——例如命名空间与控制组——以在操作系统之上创建容器。

容器概念并不是什么新鲜事物; 谷歌公司多年来一直在使用自己开发的容器技术。其它Linux容器技术方案还包括Solaris Zones、BSD jails以及LXC,且其都已经拥有多年的发展历史。

那么为什么Docker的出现会快速吸引到技术业界的注意?
  • 易用性: Docker能够为潜在受众带来出色的易用性——开发者、系统管理员以及架构师等等——从而帮助其充分利用容器技术优势以快速构建并测试可移植应用程序。每个人都可以在自己的笔记本上打包应用程序,并将其直接运行在任何公有云、私有云甚至是裸机之上。其座右铭是:一次构建,随处运行。
  • 速度: Docker容器具备轻量化与高速特性。由于容器本身属于运行在内核之上的沙箱环境,因为其对资源的需求量极低。大家可以在数秒钟内完成容器的创建与运行,而虚拟机则由于需要引导完整的虚拟操作系统而耗费更多时间。
  • Docker Hub: Docker用户还能够享受由Docker Hub带来的丰富生态系统支持,我们可以将其理解成“Docker镜像的应用商店”。Docker Hub提供成千上万由社区开发的公共镜像,且可立即加以使用。我们可以轻松根据需要搜索到合适的镜像,将其提取并稍加修改即加以使用。
  •  模块性与可扩展性: Docker允许我们轻松将应用程序的功能拆分成多个独立容器。举例来说,我们可以将自己的Postgres数据库运行在一套容器当中,并将Redis服务器运行在另一容器内,而Node.js也拥有自己的容器系统。在Docker的帮助上,大家能够轻松将这些容器对接起来以创建完整的应用程序,这就让未来的规模伸缩或者组件更新得以通过相互独立的方式完成。


最后但同样重要的是,Docker鲸鱼实在是太惹人喜爱了~
 

3.png


Docker基本概念
现在我们对Docker有了宏观印象,下面具体对其组件进行解读:
 

4.png


Docker Engine

Docker Engine属于Docker的运行层。这是一套轻量化运行时及工具组合,负责管理容器、镜像、构建 等等。它以原生方式运行在Linux系统之上,并由以下元素构成:

Docker Daemon,运行在主机计算机之上。
Docker Client,负责与Docker Daemon通信以执行命令。
REST API,用于同Docker Daemon远程交互。

Docker Client

Docker Client正是我们作为最终用户的通信对象。我们可以将其视为Docker的UI。

4.4_.png


我们进行的一切操作都将直接接入Docker Client,再由其将指令传递至Docker Daemon。

Docker Daemon

Docker Daemon直接将执行命令发送至Docker Client——例如构建、运行以及分发等等。Docker Daemon运行在主机设备之上,但作为用户,我们永远不会直接与该Daemon进行通信。Docker Client也可以运行在主机设备上,但并非必需。它亦能够运行在另一台设备上,并与运行在目标主机上的Docker Daemon进行远程通信。

Dockerfile

Dockerfile是我们编写指令以构建Docker镜像的载体。这些指令包括:
RUN apt-get y install some-package:安装某软件包
EXPOSE 8000: 开放端口
ENV ANT_HOME /usr/local/apache-ant:传递环境变量

类似的指令还有很多。一旦设置了Dockerfile,大家就可以利用docker build命令来构建镜像了。下面来看Dockerfile示例:


sample.jpg


示例Dockerfile

Docker镜像

镜像属于只读模板,大家可以借此配合Dockerfile中的编写指令集进行容器构建。镜像定义了打包的应用程序以及其相关依赖。这些依赖就好像是其启动时需要运行的进程。

Docker镜像利用Dockerfile实现构建。Dockerfile中的每条指令都会在镜像中添加一个新的“层”,这些层则表现为镜像文件系统中的一个分区——我们可以对其进行添加或者替换。层概念正是Docker轻量化的基础。Docker利用一套Union File System建立起这套强大的结构:

Union File System

Docker利用Union File System以构建镜像。大家可以将Union File System视为一套可堆叠文件系统,这意味着各文件系统中的文件与目录(在Docker中被称为分支)可以透明方式覆盖并构成单一文件系统。

覆盖分支内的各目录内容拥有同样的路径,并将被视为单一合并目录,这就避免了需要为每个层分别创建副本的麻烦。相反,这些目录可调用特定指针以指向同样的资源; 当特定层需要进行修改时,其会分别创建修改前与修改后的本地副本。通过这种方式,文件系统*表现*出可写入特性,但其实际上并未接受任何写入操作。(换言之,这是一套‘写入即复制’系统。)

分层系统拥有两大核心优势:

无重复数据: 分层机制使得我们在使用镜像创建并运行新容器时无需复制完整的文件集,从而保证Docker容器实例拥有良好的运行速度与低廉的资源成本。
层隔离: 变更操作速度很快——当我们对镜像进行变更时,Docker只需要对进行了变更的层进行广播。

Volumes

Volumes属于容器中的“数据”部分,会在容器创建时进行初始化。Volumes机制允许我们持久保留并共享容器数据。数据卷 独立于默认Union File System之外,且作为普通目录及文件存在于主机文件系统当中。因此即使是在对容器进行销毁、更新或者重构时,数据卷仍然不受影响。当我们需要对某一数据卷进行更新时,直接加以变更即可。(作为另一项优势,数据卷还能够在不同容器之间进行共享与复用。)

Docker容器
如上所述,Docker容器将一款应用程序的软件打包在单一环境当中,同时包含全部运行必需的要素。其中包括操作系统、应用程序代码、运行时、系统工具、系统库等等。Docker容器由Docker镜像构建而成。由于镜像存在只读属性,因此Docker会在镜像在只读文件系统之上添加一套读取-写入文件系统以实现容器创建。
 

5.png


另外,在创建容器时,Docker还会创建一套网络接口以帮助容器同本地主机通信、对接可用IP地址并执行用户在定义镜像时所执行的进程以运行应用程序。
在成功创建了一套容器之后,我们随后可以将其运行在任何环境当中,而不必再做任何变更。

“容器”探秘

打开容器,我们会发现其中包含大量活动组件。容器的实现机制一直令我感到惊讶而好奇,特别是考虑到容器不存在任何抽象的基础设施边界。在阅读了大量材料之后,我将结合自己的理解为大家进行讲解:)

“容器”这一术语其实只是个抽象概念,用于表述多种不同的相关特性,而其与原词“container”的另一含义“集装箱”有着千丝万缕的联系。下面就来一起了解:

1) 命名空间

命名空间为容器提供对应的底层Linux系统视图,即限制容器的查看与访问范畴。当我们运行一套容器时,Docker会创建多个命名空间供特定容器使用。
Docker会在内核中使用多种不同类型的命名空间,例如:
  • NET: 为容器提供独特的系统网络堆栈视图(例如自有网络设备、IP地址、IP路由表、/proc/net目录、端口编号等等)。
  • PID: PID代表进程ID。如果大家曾经在命令行中运行过ps aux以检查当前系统正在运行的进程,就会发现其中一栏名为“PID”。PID命名空间为容器提供其能够查看与交互的进程范围,其中包括独立的init(PID 1),其属于“所有进程的元祖”。
  • MNT: 为容器提供独特的系统“mounts”视图。这样不同mount命名空间内的进程就将拥有彼此不同的文件系统结构。
  • UTS: UTS代表UNIX分时系统。它允许某一进程识别系统身份(例如主机名称或者域名等)。UTS允许容器拥有不同于其它容器以及主机系统的主机名称与NIS域名。
  • IPC: IPC代表进程间通信。IPC命名空间负责对运行在每套容器内的进程进行IPC资源隔离。
  • USER: 此命名空间用于对每套容器内的用户进行隔离。其允许各容器拥有不同的uid(即用户ID)与gid(组ID)视图区间,并将其与主机系统进行比对。这样一来,某一进程的uid与gid在用户命名空间之内与之外即有所不同,这也使得该进程能够在不影响容器内root权限的情况下,撤销同一用户在容器外的权限。


Docker将这些命名空间结合起来以隔离并创建容器。下面要讲的则是控制组。

2) 控制组

控制组(也被称为cgroups)属于Linux内核中的一项功能,用于对一组进程的资源使用量(包括CPU、内存、磁盘I/O以及网络等)进行隔离、排序与计数。这意味着cgroup能够确保Docker容器只使用其必需的资源——并在必要情况下设置其所能使用的资源上限。另外,cgroups还能够确保单一容器不至于占用太多资源并导致整体系统陷入瘫痪。

最后要说明的是Union文件系统:

3) 隔离化Union file system:

我们在之前的Docker镜像章节中已经解释过了:)

这就是关于Docker容器的全部内容了(当然,实现细节才是最麻烦的环节——例如如何管理不同组件间的交互)。

Docker的未来:Docker与虚拟机将并生共存

尽管Docker已经开始逐步成为主流,但我认为它不太可能对虚拟机造成真正的威胁。容器将继续发展壮大,但虚拟机也仍然拥有适合自己的生存空间。

举例来说,如果我们需要在多台服务器上运行多款应用程序,那么最理想的办法就是使用虚拟机。在另一方面,如果我们需要运行同一应用程序的多套*副本*,那么Docker则拥有更多具体优势。

另外,尽管容器允许我们将应用程序拆分成多个功能组件,但这种分散化趋势意味着我们需要管理更多功能部件,即带来更为复杂的控制与协调任务。

安全同时也是Docker容器需要解决的一大难题——由于各容器共享同一套内核,因此不同容器之间的屏障非常薄弱。与只需要调用主机虚拟机管理程序的虚拟机方案不同,Docker容器需要向主机内核发出系统调用,而这会带来更庞大的攻击面。出于安全性的考量,很多开发人员可能更倾向于选择虚拟机——其由抽象化硬件进行隔离,从而显著提升了彼此交互的难度。

当然,安全性与管理等难题必将随着容器在生产环境下的进一步普及而得到解决。就目前来讲,关于容器与虚拟机孰优孰劣的议题已经成为开发人员与运维人员间的日常争论素材。

最后

到这里,希望大家已经拥有了关于Docker的必要知识,也祝愿各位早日将Docker引入自己的日常工作。

当然,如果大家在文章中发现了什么谬误,也欢迎在评论栏中做出说明。感谢大家,小数与你下次再见!

原文链接:
https://medium.freecodecamp.com/a-beginner-friendly-introduction-to-containers-vms-and-docker-79a9e3e119b#.sl2xp8tiv

回顾Java 发展,看 Docker 与Mesos

宁静胡同 发表了文章 • 2 个评论 • 602 次浏览 • 2016-03-22 17:24 • 来自相关话题

演讲嘉宾

数人云COO 谢乐冰

在德国工作十年,回国后加入惠普电信运营商部门,拥有多年项目经验和创业公司工作经验。在数人云负责产品售前和运营,专注行业的技术应用领域,为金融、电信、电商等行业提供服务。



回顾Java的发展轨迹看容器技术

因为我自己写了十几年的Java,经常把容器和十年前的Java做比较。一个公司说自己是做“Java”的,实际上涵义是背后一整套企业IT基础架构。软件一般都是各个集成商(东软、文思)大量码农兄弟们开发,主要还是用Windows。打成了WAR、EAR包之后交付给甲方,就可以在Linux环境下跑起来。同样Weblogic WAS这些中间件在底层计算集群之上,实现了企业服务的大规模运行。

中间件之下是IOE昂贵的高性能硬件,虽然也是集群化,主要依靠Scale up来提升性能。虽然中间件理论上实现了应用和硬件资源解耦,但实际上依然对硬件有非常苛刻的要求,特别是跑数据库的部分。

整个架构为了向上实现SOA的架构,虽然现实中90%以上顶多做到了“面向对象”,但并不妨碍Java(J2EE)作为企业服务交付的“通用”形式,成为了开发单位和运行单位共同接受的标准。所以Java背后代表的不仅仅是一个语言,还是一个完整的IT基础架构和产业链 —— 昂贵的高性能硬件、闭源的中间件软件、Java作为交付接口、SOA架构和开发与运维分离的模式。

背后还有两个隐性的英雄,一个是北大青鸟这样的培训机构,大量产出Java程序员。另外就是Oracle数据库,当然这些年轻程序员写的代码效率不太高的时候,全靠数据库来救场了。当然这一切还是传统的企业业务决定的,例如ERP、CRM等等,并发较低、强事物性和强一致性、逻辑和关联关系复杂。








如今时代发展到了蓝色的部分,云计算时代的IT架构底层不再是几台小机或者一堆刀片,更多的是企业私有云甚至是公有云,IaaS实现了资源层管理的自动化和标准化。

容器就像当年的Java一样,成为了开发和运维共同认可的接口。容器成为了应用上“云”的标准交付方式,不管是Java、Python还是C,只要用Docker打包,就可以丢到这个那个“云”上跑起来。

当然在底层各种计算资源(公有云、私有云甚至物理机)之间,也需要一个中间件来作为容器的大规模运行环境。下面是成千上万的主机,上面是乌央央的容器,中间的云计算中间件实现了两者的解耦。上面支撑的软件架构是“微服务”架构,就像当年的SOA。整体上也是实践了Devops一套运维开发方式。就像传统中间件包括了运行环境、消息队列、ESB(服务发现)和数据抽象等等,云计算中间件也都有类似的服务,例如Mesos、K8s这些容器运行环境,就对应着跑EJB的Weblogic Application Server。

总之,“容器”背后不是单个技术,而是完整的以开源软件为主的云计算IT基础架构和相应的开发和运维流程。当年虚拟机出现让大家尝到一点点云的滋味,但是毕竟局限于资源层,对开发、业务和软件架构没有影响。如今容器影响这么大,大家终于成为了应用上云的突破口,将对大家未来的职业生涯产生巨大的影响。就像今天很难招聘到懂EJB的大学毕业生,过两年很快容器和背后的互联网开源技术栈就会成为主流。

有关Mesos与K8s的老生常谈

言归正传,下面我来一步一步地介绍Mesos的实战。说起Mesos,大家往往第一个问题是Mesos和K8s有啥区别,哪个更好。我觉得这两个就像iOS和安卓,已经成为了新一代轻量调度框架的主流。两者都是源于Google的Borg,但Google自己没有使用任何一个。K8s胜在开发者多,用Go语言开发,社区活跃。Mesos是Apache项目,已经诞生了7年,目前有过超过万台规模的部署。总体上我们认为Mesos比较适合目前阶段的大规模生产环境部署,K8s目前还处于快速更新的阶段,两者都有很好的未来。当然Mesos也能兼容大数据等框架,未来目标是逐步把各种集群化的应用(Kafka集群例如)都搬到Mesos上来,实现一键安装和自动扩展。

下面是一点点Mesos的科普,其实市面上类似的文章已经不少,这里我特别推荐平安科技余何老师的《PaaS实现与运维管理:基于Mesos +Docker+ELK的实战指南》,内容非常详细。

用两句俗话说Mesos和K8s的原理,就是像使用一台电脑一样使用整个集群,类似集群的操作系统。单机的操作系统是管理单机的计算、存储和IO,集群操作系统是管理管理一堆机器的资源。目前聚焦在计算和内存之上,存储部分需要单独的分布式存储(例如Ceph和GlusterFS),网络需要SDN的支持。不过传统上IOE也是各管一摊了。







原理看起来也不复杂,Mesos 在每台Slave主机上安装一个Agent,不断地把剩余资源上报到Master。报告内容类似 { (node1, <2 CPUs, 4 GB>),(node2, <3 CPUs, 2 GB>) },这样Master就知道各个机器的剩余资源情况了,非常简单。

Master上面有很多框架Framework,例如Docker和Spark。你就可以把他们理解为Linux里面安装的JRE和Golang、C的运行类库。你想在Mesos上跑啥“语言”,就要部署个框架,例如跑Docker的框架就是Marathon。Mesos会把整个集群的资源按照一定的算法分配给各个框架,这个就是所谓资源调度的过程。因为Slave上报资源情况是不断更新的,所以就是所谓动态资源调度。







每个框架收到分配的资源之后,会自行决定将任务和资源匹配,然后通过Master将任务下发到Slave上执行。Slave上面有每种任务的执行器(Executor),就是运行环境。例如Docker任务的执行器是Mesos预装,其他类型任务执行器可能会实时下载。所以通过安装不同的框架+执行器,就可以支持各种“分布式”的任务系统。请注意这里说的一定是集群化的系统,如果是单点部署一个MySQL之类的就意义有限了。

以管理Docker任务的Marathon框架为例,它收到了Master提供的资源之后,一个是负责进行任务调度,而且还能够通过Health Check监控任务是否还活着,发现失败就重新下发任务。

这些都是常规性的解释,下面我们看看Mesos集群,看看如何一步步搭建。初始一般需要准备3台主机承载Master节点,任意多的Slave,这里建议也是3台。还有几台机器存放log等等。下面的一些图片来自前两天数人云公众号(dmesos)翻译的文章《初次微服务体验:从Docker容器农场说起》。








第一步 部署Zookeeper,负责整个集群的分布式一致性,例如Master领导选举








第二步,部署Mesos本身。我们的分布部署了3个Master,管理3个Slave节点。大家注意到,配置Mesos的时候最重要的参数就是Zookeeper,不但Master要通过ZK来进行领导选举,而且Slave也可以通过ZK来知道谁是活跃的Master.








到这一步,理论上已经可以用Mesos来管理集群下发任务了,大家看见下图里面资源(Slave)、任务(正在执行的已经介绍的)。 
 







甚至还能看到该任务的Stdout输出,就和SSH进去操作一样。
 






不过仅仅有Mesos,还要自己来编写框架调用接口发布任务,非常不方便。所以需要一个框架来跑容器任务,那就是马拉松(Marathon)。顾名思义用来跑各种长时间运行的服务,类似Linux里面的Inti.d,例如各种网站服务。马拉松是用Scala编写的,本身提供自己的Web管理界面,通过这个界面我们可以“遥控”Mesos来下发并保证Docker任务长久稳定执行。








马拉松的界面也非常直接,大家看看发布Docker任务的界面,基本就是填入Docker Run后面的那些参数,然后告诉马拉松要发布多少份。马拉松会匹配每个Task和Mesos提供的资源,然后通过Mesos将任务下发下去。








结果
 







服务发现

服务发现是个比较晦涩的翻译(Service Discovery),大概不妨粗略地理解成负载均衡算了。例如马拉松下发了100个网站的容器,每个容器有自己IP(一般是宿主机)和端口。显然前面需要挡一个负载均衡来分配流量。对外暴露的就是负载均衡的某个服务URL,后面自动将流量转发到某个容器的IP+端口上。








我们这里用HAProxy来做负载均衡,有个服务叫Bamboo会不断从ZK读出Mesos状态并且更新HAProxy的配置文件。这样新发下来的Docker会自动添加上HAProxy,而死掉的会被移除。

还有一直办法是用内网的DNS,这个DNS会维护现有的容器列表(IP+端口),并且返回任意一个的IP+端口,页实现了负载均衡和服务发现功能。不过目前Mesos DNS还不太成熟,我们一般用HAProxy。








几百个Docker撒出去,绝对不可能再登到主机上去找看日志。日志必须集中收集,并且提供检索功能,才能有效的Debug。解法也不新奇,无非是ELK。请注意Docker日志可以直接从API读出,另外需要增加一些应用、主机和容器有关的Meta Data。
 







此外分布式系统不能没有监控,黑盒子等于无法运行,所以监控要分为如下三个层面。

* 主机监控:这个并非Mesos的关注点,因为主机是资源层,本身也有自己的监控体系
* 容器层面的监控,主要是用cAdvisor,包括CPU、内存和IO
* 最最重要的是应用层监控,因为PaaS本身对外提供服务,所以监控的关注点应该是全局最终结果和逻辑正确性,而不是太纠结于个别主机和容器的

这个是分布式系统和传统系统最大的区别,关注点不再是个别容器和主机,而是业务本身。这种系统设计本来就是希望软件脱离对特定和单点硬件的依赖,通过集群化实现大规模系统的高性能和高可用。所以监控不再是着眼于“源头”,而是看重效果。很多时候平台的自愈机制甚至“埋没”了底层的一些故障,那么就让他被埋没了,只要最后效果能够得到保证。

分布式系统在应用层监控要求远远大于普通的IT系统,例如下面是一个HTTP返回状态吗的直方图,这样能很快发现是否出现大规模异常,并且通过日志系统来定位问题。








分布式系统和传统IT区别,就像市场经济和计划经济一样,不是要处处完全可控有计划,在最终结果保持可控情况下,突出灵活性、自由度和弹性,支持业务多变和快速发展。








这样一个基本的分布式系统就搭建完毕,当然如果是生产级别还需要有大规模集群运行调优、集群化HAProxy,监控和报警对接、多租户管理、F5的对接、和Openstack等等的IaaS对接等,这样就需要数人云这样的商业化开源方案来支持了。

此外经常有用户问到,啥样的应用可以上云呢,下面的表格回答了这个问题。








可以看到,这个问题的回答并不是黑白分明。最理想的当然是完全的微服务架构,可以发挥全部的作用。当然90%应用目前还是有状态应用,所以可以快速扩张,但是无法收缩,需要实现Graceful Stop功能,慢慢地收缩。所谓的无状态化改造,无非就是很标准互联网架构,不要用J2EE内置的Session就好。

 









本来今天还要展示一个我们的客户案例,如何将一个分布式系统迁移到Mesos之上,因为时间关系,下次再分享吧。

精彩问答


QQ群 

Q1:当初刚接触Linux的时候,最开始是在Virtualbox等虚拟机这种模拟环境里面摸索 Linux,代价低,比较容易动手和入门。对有一定基础的运维人员(但刚接触容器集群),你建议用什么配置的环境测试做 方便入门(比如测试  Mesos+ZooKeeper+Marathon+Docker)
A1:虚拟机就可以,VARGANT 

Q2:Docker的数据持久存储采用何种存储,用Ceph之类?
A2:对,各种分布式存储,例如Glusterfs 

Q3:我想问一下K8s+Docker 现在用作生产的话够成熟吗? K8s能达到高可用了吗?
A3:小集群的话可以倒腾倒腾,K8s的源码有浙大张磊老师的书 

Q4:还有就是Mesos能否和Openstack结合起来,生产环境有没有Docker和Openstack结合的案例
A4:必须可以,我们就和Openstack厂商一起合做生产系统部署了。可以这么说,完整的DCOS是包括IaaS+PaaS,如果企业要对底层资源严格管理,就需要IaaS 

Q5:我想问下Docker的性能,尤其是网络部分,比物理机和普通虚拟机差很多么,用集群性能会不会好些呢
A5:如何是Host模式,Docker网络性能和物理机一样,具体可以看  这里有一篇IBM的论文,讨论了差别:
http://domino.research.ibm.com ... 1E7B/$File/rc25482.pdf 

微信群|云实名

Q1:一直想问Doceker会不会一定成为下一代虚拟化。 
A1:反正Docker已经基本成为了开发和运维和厂商都比较接受的上云交付形式。 

Q2:容器算不算虚拟化的一种,一台服务器,上边跑很多虚拟机怎么更好的提升性能。
A2:最好不要把容器当成虚拟机,虚拟机的意思是和特定IP或者宿主机绑定,而容器特点是在云上飘来飘去。例如经常有需求是给容器分配IP,其实就是当虚拟机了 

Q3:有开源版供学习吗?     
A3:Mesos这些都是开源的,可以参考平安余何老师的著作,数人云管理平台本身是不开源的。 

微信群|运维前线

Q1:ELK本身也是Docker来部署么?  
A1:目前有状态的服务很多都有Mesos框架,但是在生产环境中产品化还不多。我们目前不建议客户数据库等应用放上来。背后逻辑也是这些服务,一般还不太需要动态扩展和更新,就算实在互联网公司里面。下一步我们也会推出企业应用商店,会把一些经过测试已经产品化的集群化组件放出来,这个还需要一些时间。 

Q2:首先说一下我还没有完全拜读完,这个话题很热,我也很感兴趣。我想问的问题,不是具体的技术问题。我是想问一下:传统的数据中心和传统的企业业务,如何在这场技术大潮中转移到新的技术架构。例如我们现在的数据中心怎样转移到您今天分享的这种架构上来?
A2:四个字“业务驱动”,不上云就宕机,或者看着满地黄金捡不起来,就自然有动力了。
一般说来是7个字,新业务上新平台。互联网的成功在于不是顶层设计,而是消费者的业务驱动。
当然,对于技术水平较高的大型企业,未来交付形式普遍容器化之下。他们引入容器的核心目的是推进自身架构云化改造。 

Q3:你们回答的是什么应用适合上云还是容器云?    
A3:首先“容器”是应用上云的Gateway,所以可以说泛指上云的应用,云端应用最好都符合Cloud Native架构。当然IaaS也是云,传统有状态应用理论上无需改造也能上虚拟机。不过传统应用强烈和底层硬件特定能力绑定,而虚拟机网络IO不一定满足需要,所以上云的过程同样需要改造。例如数据库分片来减少单节点压力等等。 

Q4:安全性呢,公司有的业务不敢轻易放上去,这方面的问题如何解决
A4:适合内部私有云,公有云需要底层IaaS协助网络和虚拟机层面隔离  查看全部


演讲嘉宾

数人云COO 谢乐冰

在德国工作十年,回国后加入惠普电信运营商部门,拥有多年项目经验和创业公司工作经验。在数人云负责产品售前和运营,专注行业的技术应用领域,为金融、电信、电商等行业提供服务。




回顾Java的发展轨迹看容器技术

因为我自己写了十几年的Java,经常把容器和十年前的Java做比较。一个公司说自己是做“Java”的,实际上涵义是背后一整套企业IT基础架构。软件一般都是各个集成商(东软、文思)大量码农兄弟们开发,主要还是用Windows。打成了WAR、EAR包之后交付给甲方,就可以在Linux环境下跑起来。同样Weblogic WAS这些中间件在底层计算集群之上,实现了企业服务的大规模运行。

中间件之下是IOE昂贵的高性能硬件,虽然也是集群化,主要依靠Scale up来提升性能。虽然中间件理论上实现了应用和硬件资源解耦,但实际上依然对硬件有非常苛刻的要求,特别是跑数据库的部分。

整个架构为了向上实现SOA的架构,虽然现实中90%以上顶多做到了“面向对象”,但并不妨碍Java(J2EE)作为企业服务交付的“通用”形式,成为了开发单位和运行单位共同接受的标准。所以Java背后代表的不仅仅是一个语言,还是一个完整的IT基础架构和产业链 —— 昂贵的高性能硬件、闭源的中间件软件、Java作为交付接口、SOA架构和开发与运维分离的模式。

背后还有两个隐性的英雄,一个是北大青鸟这样的培训机构,大量产出Java程序员。另外就是Oracle数据库,当然这些年轻程序员写的代码效率不太高的时候,全靠数据库来救场了。当然这一切还是传统的企业业务决定的,例如ERP、CRM等等,并发较低、强事物性和强一致性、逻辑和关联关系复杂。


图片1.png



如今时代发展到了蓝色的部分,云计算时代的IT架构底层不再是几台小机或者一堆刀片,更多的是企业私有云甚至是公有云,IaaS实现了资源层管理的自动化和标准化。

容器就像当年的Java一样,成为了开发和运维共同认可的接口。容器成为了应用上“云”的标准交付方式,不管是Java、Python还是C,只要用Docker打包,就可以丢到这个那个“云”上跑起来。

当然在底层各种计算资源(公有云、私有云甚至物理机)之间,也需要一个中间件来作为容器的大规模运行环境。下面是成千上万的主机,上面是乌央央的容器,中间的云计算中间件实现了两者的解耦。上面支撑的软件架构是“微服务”架构,就像当年的SOA。整体上也是实践了Devops一套运维开发方式。就像传统中间件包括了运行环境、消息队列、ESB(服务发现)和数据抽象等等,云计算中间件也都有类似的服务,例如Mesos、K8s这些容器运行环境,就对应着跑EJB的Weblogic Application Server。

总之,“容器”背后不是单个技术,而是完整的以开源软件为主的云计算IT基础架构和相应的开发和运维流程。当年虚拟机出现让大家尝到一点点云的滋味,但是毕竟局限于资源层,对开发、业务和软件架构没有影响。如今容器影响这么大,大家终于成为了应用上云的突破口,将对大家未来的职业生涯产生巨大的影响。就像今天很难招聘到懂EJB的大学毕业生,过两年很快容器和背后的互联网开源技术栈就会成为主流。

有关Mesos与K8s的老生常谈

言归正传,下面我来一步一步地介绍Mesos的实战。说起Mesos,大家往往第一个问题是Mesos和K8s有啥区别,哪个更好。我觉得这两个就像iOS和安卓,已经成为了新一代轻量调度框架的主流。两者都是源于Google的Borg,但Google自己没有使用任何一个。K8s胜在开发者多,用Go语言开发,社区活跃。Mesos是Apache项目,已经诞生了7年,目前有过超过万台规模的部署。总体上我们认为Mesos比较适合目前阶段的大规模生产环境部署,K8s目前还处于快速更新的阶段,两者都有很好的未来。当然Mesos也能兼容大数据等框架,未来目标是逐步把各种集群化的应用(Kafka集群例如)都搬到Mesos上来,实现一键安装和自动扩展。

下面是一点点Mesos的科普,其实市面上类似的文章已经不少,这里我特别推荐平安科技余何老师的《PaaS实现与运维管理:基于Mesos +Docker+ELK的实战指南》,内容非常详细。

用两句俗话说Mesos和K8s的原理,就是像使用一台电脑一样使用整个集群,类似集群的操作系统。单机的操作系统是管理单机的计算、存储和IO,集群操作系统是管理管理一堆机器的资源。目前聚焦在计算和内存之上,存储部分需要单独的分布式存储(例如Ceph和GlusterFS),网络需要SDN的支持。不过传统上IOE也是各管一摊了。


图片2.png


原理看起来也不复杂,Mesos 在每台Slave主机上安装一个Agent,不断地把剩余资源上报到Master。报告内容类似 { (node1, <2 CPUs, 4 GB>),(node2, <3 CPUs, 2 GB>) },这样Master就知道各个机器的剩余资源情况了,非常简单。

Master上面有很多框架Framework,例如Docker和Spark。你就可以把他们理解为Linux里面安装的JRE和Golang、C的运行类库。你想在Mesos上跑啥“语言”,就要部署个框架,例如跑Docker的框架就是Marathon。Mesos会把整个集群的资源按照一定的算法分配给各个框架,这个就是所谓资源调度的过程。因为Slave上报资源情况是不断更新的,所以就是所谓动态资源调度。


图片3.png


每个框架收到分配的资源之后,会自行决定将任务和资源匹配,然后通过Master将任务下发到Slave上执行。Slave上面有每种任务的执行器(Executor),就是运行环境。例如Docker任务的执行器是Mesos预装,其他类型任务执行器可能会实时下载。所以通过安装不同的框架+执行器,就可以支持各种“分布式”的任务系统。请注意这里说的一定是集群化的系统,如果是单点部署一个MySQL之类的就意义有限了。

以管理Docker任务的Marathon框架为例,它收到了Master提供的资源之后,一个是负责进行任务调度,而且还能够通过Health Check监控任务是否还活着,发现失败就重新下发任务。

这些都是常规性的解释,下面我们看看Mesos集群,看看如何一步步搭建。初始一般需要准备3台主机承载Master节点,任意多的Slave,这里建议也是3台。还有几台机器存放log等等。下面的一些图片来自前两天数人云公众号(dmesos)翻译的文章《初次微服务体验:从Docker容器农场说起》。



图片4.png


第一步 部署Zookeeper,负责整个集群的分布式一致性,例如Master领导选举



图片5.png


第二步,部署Mesos本身。我们的分布部署了3个Master,管理3个Slave节点。大家注意到,配置Mesos的时候最重要的参数就是Zookeeper,不但Master要通过ZK来进行领导选举,而且Slave也可以通过ZK来知道谁是活跃的Master.


图片6.png



到这一步,理论上已经可以用Mesos来管理集群下发任务了,大家看见下图里面资源(Slave)、任务(正在执行的已经介绍的)。 
 


图片7.png


甚至还能看到该任务的Stdout输出,就和SSH进去操作一样。
 

图片8.png


不过仅仅有Mesos,还要自己来编写框架调用接口发布任务,非常不方便。所以需要一个框架来跑容器任务,那就是马拉松(Marathon)。顾名思义用来跑各种长时间运行的服务,类似Linux里面的Inti.d,例如各种网站服务。马拉松是用Scala编写的,本身提供自己的Web管理界面,通过这个界面我们可以“遥控”Mesos来下发并保证Docker任务长久稳定执行。


图片9.jpg



马拉松的界面也非常直接,大家看看发布Docker任务的界面,基本就是填入Docker Run后面的那些参数,然后告诉马拉松要发布多少份。马拉松会匹配每个Task和Mesos提供的资源,然后通过Mesos将任务下发下去。


图片10.png



结果
 

图片11.png



服务发现

服务发现是个比较晦涩的翻译(Service Discovery),大概不妨粗略地理解成负载均衡算了。例如马拉松下发了100个网站的容器,每个容器有自己IP(一般是宿主机)和端口。显然前面需要挡一个负载均衡来分配流量。对外暴露的就是负载均衡的某个服务URL,后面自动将流量转发到某个容器的IP+端口上。


图片12.png



我们这里用HAProxy来做负载均衡,有个服务叫Bamboo会不断从ZK读出Mesos状态并且更新HAProxy的配置文件。这样新发下来的Docker会自动添加上HAProxy,而死掉的会被移除。

还有一直办法是用内网的DNS,这个DNS会维护现有的容器列表(IP+端口),并且返回任意一个的IP+端口,页实现了负载均衡和服务发现功能。不过目前Mesos DNS还不太成熟,我们一般用HAProxy。


图片13.png



几百个Docker撒出去,绝对不可能再登到主机上去找看日志。日志必须集中收集,并且提供检索功能,才能有效的Debug。解法也不新奇,无非是ELK。请注意Docker日志可以直接从API读出,另外需要增加一些应用、主机和容器有关的Meta Data。
 

图片14.png



此外分布式系统不能没有监控,黑盒子等于无法运行,所以监控要分为如下三个层面。

* 主机监控:这个并非Mesos的关注点,因为主机是资源层,本身也有自己的监控体系
* 容器层面的监控,主要是用cAdvisor,包括CPU、内存和IO
* 最最重要的是应用层监控,因为PaaS本身对外提供服务,所以监控的关注点应该是全局最终结果和逻辑正确性,而不是太纠结于个别主机和容器的

这个是分布式系统和传统系统最大的区别,关注点不再是个别容器和主机,而是业务本身。这种系统设计本来就是希望软件脱离对特定和单点硬件的依赖,通过集群化实现大规模系统的高性能和高可用。所以监控不再是着眼于“源头”,而是看重效果。很多时候平台的自愈机制甚至“埋没”了底层的一些故障,那么就让他被埋没了,只要最后效果能够得到保证。

分布式系统在应用层监控要求远远大于普通的IT系统,例如下面是一个HTTP返回状态吗的直方图,这样能很快发现是否出现大规模异常,并且通过日志系统来定位问题。


图片15.png



分布式系统和传统IT区别,就像市场经济和计划经济一样,不是要处处完全可控有计划,在最终结果保持可控情况下,突出灵活性、自由度和弹性,支持业务多变和快速发展。


图片16.jpg



这样一个基本的分布式系统就搭建完毕,当然如果是生产级别还需要有大规模集群运行调优、集群化HAProxy,监控和报警对接、多租户管理、F5的对接、和Openstack等等的IaaS对接等,这样就需要数人云这样的商业化开源方案来支持了。

此外经常有用户问到,啥样的应用可以上云呢,下面的表格回答了这个问题。


图片17.png



可以看到,这个问题的回答并不是黑白分明。最理想的当然是完全的微服务架构,可以发挥全部的作用。当然90%应用目前还是有状态应用,所以可以快速扩张,但是无法收缩,需要实现Graceful Stop功能,慢慢地收缩。所谓的无状态化改造,无非就是很标准互联网架构,不要用J2EE内置的Session就好。

 



图片18.png



本来今天还要展示一个我们的客户案例,如何将一个分布式系统迁移到Mesos之上,因为时间关系,下次再分享吧。

精彩问答


QQ群 

Q1:当初刚接触Linux的时候,最开始是在Virtualbox等虚拟机这种模拟环境里面摸索 Linux,代价低,比较容易动手和入门。对有一定基础的运维人员(但刚接触容器集群),你建议用什么配置的环境测试做 方便入门(比如测试  Mesos+ZooKeeper+Marathon+Docker)
A1:虚拟机就可以,VARGANT 

Q2:Docker的数据持久存储采用何种存储,用Ceph之类?
A2:对,各种分布式存储,例如Glusterfs 

Q3:我想问一下K8s+Docker 现在用作生产的话够成熟吗? K8s能达到高可用了吗?
A3:小集群的话可以倒腾倒腾,K8s的源码有浙大张磊老师的书 

Q4:还有就是Mesos能否和Openstack结合起来,生产环境有没有Docker和Openstack结合的案例
A4:必须可以,我们就和Openstack厂商一起合做生产系统部署了。可以这么说,完整的DCOS是包括IaaS+PaaS,如果企业要对底层资源严格管理,就需要IaaS 

Q5:我想问下Docker的性能,尤其是网络部分,比物理机和普通虚拟机差很多么,用集群性能会不会好些呢
A5:如何是Host模式,Docker网络性能和物理机一样,具体可以看  这里有一篇IBM的论文,讨论了差别:
http://domino.research.ibm.com ... 1E7B/$File/rc25482.pdf 

微信群|云实名

Q1:一直想问Doceker会不会一定成为下一代虚拟化。 
A1:反正Docker已经基本成为了开发和运维和厂商都比较接受的上云交付形式。 

Q2:容器算不算虚拟化的一种,一台服务器,上边跑很多虚拟机怎么更好的提升性能。
A2:最好不要把容器当成虚拟机,虚拟机的意思是和特定IP或者宿主机绑定,而容器特点是在云上飘来飘去。例如经常有需求是给容器分配IP,其实就是当虚拟机了 

Q3:有开源版供学习吗?     
A3:Mesos这些都是开源的,可以参考平安余何老师的著作,数人云管理平台本身是不开源的。 

微信群|运维前线

Q1:ELK本身也是Docker来部署么?  
A1:目前有状态的服务很多都有Mesos框架,但是在生产环境中产品化还不多。我们目前不建议客户数据库等应用放上来。背后逻辑也是这些服务,一般还不太需要动态扩展和更新,就算实在互联网公司里面。下一步我们也会推出企业应用商店,会把一些经过测试已经产品化的集群化组件放出来,这个还需要一些时间。 

Q2:首先说一下我还没有完全拜读完,这个话题很热,我也很感兴趣。我想问的问题,不是具体的技术问题。我是想问一下:传统的数据中心和传统的企业业务,如何在这场技术大潮中转移到新的技术架构。例如我们现在的数据中心怎样转移到您今天分享的这种架构上来?
A2:四个字“业务驱动”,不上云就宕机,或者看着满地黄金捡不起来,就自然有动力了。
一般说来是7个字,新业务上新平台。互联网的成功在于不是顶层设计,而是消费者的业务驱动。
当然,对于技术水平较高的大型企业,未来交付形式普遍容器化之下。他们引入容器的核心目的是推进自身架构云化改造。 

Q3:你们回答的是什么应用适合上云还是容器云?    
A3:首先“容器”是应用上云的Gateway,所以可以说泛指上云的应用,云端应用最好都符合Cloud Native架构。当然IaaS也是云,传统有状态应用理论上无需改造也能上虚拟机。不过传统应用强烈和底层硬件特定能力绑定,而虚拟机网络IO不一定满足需要,所以上云的过程同样需要改造。例如数据库分片来减少单节点压力等等。 

Q4:安全性呢,公司有的业务不敢轻易放上去,这方面的问题如何解决
A4:适合内部私有云,公有云需要底层IaaS协助网络和虚拟机层面隔离 




新视界 | 也许这才是大规模分发容器镜像的正确姿势

宁静胡同 发表了文章 • 0 个评论 • 302 次浏览 • 2016-03-18 19:04 • 来自相关话题

随着Docker技术的日渐火热,一些容器相关的问题也浮出水面。本文就容器数量激增后造成的分发效率低下问题进行了探讨,并提出了一种新的解决方法。发现问题,解决问题,正是IT技术不断进步的真谛,小数深以为然。

容器技术令应用程序的配置与部署工作效率极大提高,但在不同IT运维领域的具体提升效果却又不尽相同。举例来说,其在利用数据中心存储与网络容量进行容器镜像的大规模分发时往往表现得比较不尽如人意。

这确实有点反直觉:容器技术一直以高效的服务运行能力与相较于虚拟机的可观资源节约水平为人们所称道,为什么也会存在效率低下问题?答案出在Docker镜像的存储与下载方式上。从传统角度讲,存储在库中的每套镜像都必须拥有与其各层相关的全部文件,这意味着对任意主机设备上的Docker镜像进行更新,我们就需要从该库中下载完整的镜像。

在面对小型Web应用中的少量容器时,这种机制似乎构不成什么大问题。然而我们可以设想一旦容器系统数量增长至数百、数千乃至数百万之巨时,那么库的体积就会随着容器系统的增加而不断攀升,而每一次更新所需要下载的数据量也会越来越大。与此同时,获取Docker镜像的下载流量也将提升至数GB,这显然是我们所无法接受的。

像Twitter这样的企业无疑运行有大量容器系统,自然也经历过上述困扰。这种状况会随着更多企业采用容器技术而变得愈发普遍,并导致大型容器库的规模不断向外扩展。

我们认为解决容器臃肿难题的可行方案之一正是名为CernVM文件系统(简称CernVM-FS)的技术成果。其由CERN(欧洲核子研究中心)开发而成,同时囊括了来自世界各地的高能物理学领域、特别是费米实验室的辛勤贡献。

CernVM-FS的作用在于帮助科学家分发每年开发出的高达2TB的软件数据——其中一部分软件甚至每周都需要面向数十万台计算机进行多次分发与上传。CernVM-FS采用一整套独特的索引、重复数据删除、缓存与地理分布机制,旨在最大程度降低与每次下载相关的组件数量,同时尽可能加快必要的下载数据量。

Mesosphere与CERN目前正在探索如何将CernVM-FS同Apache Mesos加以结合,从而了解其在容器下载工作中的实际效果以及我们在大型容器环境下的处理效率。

CernVM-FS工作原理深度解析

CernVM-FS的基本构想诞生于2008年,当时CERN的研究人员与现在的人们一样因为底层硬件虚拟化的需求而开始审视容器技术,即寻求新的应用程序部署机制。相较于创建镜像或者软件包,他们想到使用一套全局分布式文件系统帮助科学家们将自己的软件一次性安装在一台Web服务器上,而后立足世界任意位置对其进行访问。

作为一套分布式文件系统,其首要原则就是在任意时间段之内,全部可用文件都只有一小部分接受实际访问。举例来说,要运行一台Web服务器,大家只需要使用操作系统(例如glibc与OpenSSL)中的一部分库。负责承载操作系统的分布式文件系统只需要使用必要的文件,而且事实上CVMFS只需要下载并在本地缓存这部分必要数据。当时研究人员们选择了HTTP作为下载协议,从而接入其它可用Web缓存基础设施(例如Akamai、CloudFront、Squid以及NGINX代理服务器等等)。

而第二项原则在于元数据(即与文件存在相关的信息,而非文件内容)被优先对待。一般来讲,文件系统所承载的软件会受到“libssl.so是否存在于lib32当中?抑或是存在于/lib64目录当中?还是存在于/usr/lib32当中?”这类请求所困扰。在处理这些请求时,通用型分布式文件系统往往表现得很差。CernVM-FS则将全部元数据保存在SQlite文件当中,并将其作为常规文件进行下载与缓存。在这种情况下,数百万计的元数据请求就能够以本地方式进行解析,使得CernVM-FS在速度表现上几乎与本地POSIX文件系统保持一致。

第三项原则在于,软件只能够在发布点处进行修改——其他一切客户都只能在高可用性水平下实现只读操作。多数此前存在的文件系统在设计中都无法处理CAP定理提到的权衡难题,因为这类系统会假定客户的目标始终是读取最新的可用数据版本。在这种情况下,软件必须在应用或者容器运行的同时保持即时性,这意味着运行过程中该文件系统必须交付单一快照。

有鉴于此,CERN决定使用内容可寻址存储与梅克尔树状结构。与git类似,各文件会在内部根据其(惟一的)加密内容散列进行命名。存在于不同目录内的同一文件的多套副本(例如不同Ubuntu镜像当中的“ls”实体)会被合并为单一文件。SQlite文件目录取决于其中文件的内容散列值。如此一来,其root散列值(一个160位整数)将最终确定整套文件系统快照。要关闭信任链,系统会提供一个经过加密的root散列值,每个客户端则对接收到的数据的每一位进行验证,从而确保其来自预期来源且未被篡改。

如今,CernVM-FS负责为分布在全球各地的约十万台计算机交付来自大型强子对撞机实验软件的数百万个文件与目录。

Mesos中的容器化器

Mesos通过所谓“容器化器(containerizer)”利用多种实现手段提供任务容器化能力。容器化器负责对运行当中的各个任务加以隔离,同时限定各个任务可以使用的资源量(例如CPU、内存、磁盘以及网络)。Mesos容器化器的作用可以通过所谓“隔离器(isolator)”轻松得到扩展,后者可被视为一种执行特定任务的插件(举例来说,在容器当中启动外部分卷)。

最后但同样重要的是,容器化器还能够为任务提供一套运行时环境。它允许用户将全部关联性同任务本体一道预打包至文件系统镜像当中。这套镜像随后可进行任意分发,并被用于启动该项任务。

Mesos目前已经拥有多种类型的容器化器。其默认选项为Mesos容器化器——这款工具采用Linux命名空间与cgropus以实现任务隔离同资源使用量控制,同时配合一整套隔离器实现外部功能交付。另外还有一套Docker容器化器,其利用Docker工具以提取镜像并启动Docker容器。

Mesos容器化器目前已通过扩展实现了多种镜像格式的支持能力,其中包括Docker与AppC,旨在建立一套“统一容器化器”。这套方案令新镜像格式的支持变得非常轻松:利用统一容器化器,我们只需要为新的镜像格式构建一款所谓“配置器(provisioner)”,并复用全部现有隔离代码即可。举例来说,Mesos用户可以继续使用Docker镜像,但全部提取、隔离与其它任务都通过Mesos而非Docker工具实现。

集成CernVM-FS与Mesos以实现容器镜像分发

内容可寻址存储的介入、出色的安全水平以及久经考验的扩展能力使得CernVM-FS成为一款极具吸引力的容器镜像分发处理工具。为了测试其实际效果,我们创建了一套新的CernVM-FS库,并将其添加到一套Ubuntu安装软件包当中。在此之后,我们立足于CVMFS构建了一款Mesos容器镜像配置器。相较于直接下载完整镜像,它能够利用CernVM-FS客户端以本地方式远程启动镜像root目录。该配置器可将CernVM-FS库名称作为输入数据(其在内部被映射至该CernVM-FS服务器的URL)以及充当容器镜像root所必需的库内路径。

如此一来,我们就能够立足于同一CernVM-FS库实现多种容器镜像的发布。从本质上讲,CernVM-FS库的作用等同于一套安全且可扩展的容器镜像注册表。

从容器化器的角度来看,一切其实丝毫未受影响。它仍然负责处理包含有镜像目录树的本地目录,并利用一切必要元素实现容器启动。不过这种作法的最大优势在于CernVM-FS拥有经过细化调整的重复数据删除功能(在配合Docker的情况下,基于文件或者块而非层),这意味着我们现在能够在无需下载完整镜像的前提下启动容器。一旦容器启动完成,CernVM-FS会下载必要的文件以进行任务处理。

在我们的测试当中,我们启动了一套Ubuntu容器,而后在shell当中运行了一条命令。在传统场景当中,我们需要下载完整的Ubuntu镜像,其体积约为300 MB。然而,当我们使用CernVM-FS配置器时,我们只需要下载该任务所必需的文件——具体为不足6MB。

由于CernVM-FS采用内容可寻址存储,因此我们不需要重复下载同样的文件。所以,如果我们进一步启动其它容器(例如一套CentOS镜像)并运行不同的命令,那么我们只需要下载新命令所需要的文件,并复用此前已经在Ubuntu镜像中下载过的全部通用关联性(例如Bash或者libc.so)。在这种模式下,容器层的概念已经不复存在,重复数据删除将立足于更为细化的层面进行。

我们还计划添加对该配置器的支持以利用对应的检验机制启动任意CernVM-FS目录。这将帮助开发人员更为轻松地在处理容器镜像时实现快速迭代,并使得运维人员便捷地在不同容器镜像版本间来回切换。

配合容器普及的浪潮

CERN与Mesosphere的技术团队对于将CernVM-FS与Apache Mesos集成充满期待,这也意味着IT行业将更为广泛地采纳应用程序容器技术。如果各企业与机构希望从根本层面改善应用程序构建、代码部署以及数据中心运行的实现方式,则必须要立足于高于当前实际规模的水平上进行容器的启动、关闭、更新以及管理。CernVM-FS与Mesos之间的紧密集成将能够成为一种可行途径,帮助各类用户解决容器采纳道路上的存储容量及网络带宽瓶颈。

作为一项新兴的技术,关于Docker的坑很多,需要我们共同来填满。大家如果有相关的疑问和困惑,也欢迎留言和小数进行讨论。

原文链接:https://mesosphere.com/blog/2016/03/08/cernvmfs-mesos-containers/

  查看全部

随着Docker技术的日渐火热,一些容器相关的问题也浮出水面。本文就容器数量激增后造成的分发效率低下问题进行了探讨,并提出了一种新的解决方法。发现问题,解决问题,正是IT技术不断进步的真谛,小数深以为然。



容器技术令应用程序的配置与部署工作效率极大提高,但在不同IT运维领域的具体提升效果却又不尽相同。举例来说,其在利用数据中心存储与网络容量进行容器镜像的大规模分发时往往表现得比较不尽如人意。

这确实有点反直觉:容器技术一直以高效的服务运行能力与相较于虚拟机的可观资源节约水平为人们所称道,为什么也会存在效率低下问题?答案出在Docker镜像的存储与下载方式上。从传统角度讲,存储在库中的每套镜像都必须拥有与其各层相关的全部文件,这意味着对任意主机设备上的Docker镜像进行更新,我们就需要从该库中下载完整的镜像。

在面对小型Web应用中的少量容器时,这种机制似乎构不成什么大问题。然而我们可以设想一旦容器系统数量增长至数百、数千乃至数百万之巨时,那么库的体积就会随着容器系统的增加而不断攀升,而每一次更新所需要下载的数据量也会越来越大。与此同时,获取Docker镜像的下载流量也将提升至数GB,这显然是我们所无法接受的。

像Twitter这样的企业无疑运行有大量容器系统,自然也经历过上述困扰。这种状况会随着更多企业采用容器技术而变得愈发普遍,并导致大型容器库的规模不断向外扩展。

我们认为解决容器臃肿难题的可行方案之一正是名为CernVM文件系统(简称CernVM-FS)的技术成果。其由CERN(欧洲核子研究中心)开发而成,同时囊括了来自世界各地的高能物理学领域、特别是费米实验室的辛勤贡献。

CernVM-FS的作用在于帮助科学家分发每年开发出的高达2TB的软件数据——其中一部分软件甚至每周都需要面向数十万台计算机进行多次分发与上传。CernVM-FS采用一整套独特的索引、重复数据删除、缓存与地理分布机制,旨在最大程度降低与每次下载相关的组件数量,同时尽可能加快必要的下载数据量。

Mesosphere与CERN目前正在探索如何将CernVM-FS同Apache Mesos加以结合,从而了解其在容器下载工作中的实际效果以及我们在大型容器环境下的处理效率。

CernVM-FS工作原理深度解析

CernVM-FS的基本构想诞生于2008年,当时CERN的研究人员与现在的人们一样因为底层硬件虚拟化的需求而开始审视容器技术,即寻求新的应用程序部署机制。相较于创建镜像或者软件包,他们想到使用一套全局分布式文件系统帮助科学家们将自己的软件一次性安装在一台Web服务器上,而后立足世界任意位置对其进行访问。

作为一套分布式文件系统,其首要原则就是在任意时间段之内,全部可用文件都只有一小部分接受实际访问。举例来说,要运行一台Web服务器,大家只需要使用操作系统(例如glibc与OpenSSL)中的一部分库。负责承载操作系统的分布式文件系统只需要使用必要的文件,而且事实上CVMFS只需要下载并在本地缓存这部分必要数据。当时研究人员们选择了HTTP作为下载协议,从而接入其它可用Web缓存基础设施(例如Akamai、CloudFront、Squid以及NGINX代理服务器等等)。

而第二项原则在于元数据(即与文件存在相关的信息,而非文件内容)被优先对待。一般来讲,文件系统所承载的软件会受到“libssl.so是否存在于lib32当中?抑或是存在于/lib64目录当中?还是存在于/usr/lib32当中?”这类请求所困扰。在处理这些请求时,通用型分布式文件系统往往表现得很差。CernVM-FS则将全部元数据保存在SQlite文件当中,并将其作为常规文件进行下载与缓存。在这种情况下,数百万计的元数据请求就能够以本地方式进行解析,使得CernVM-FS在速度表现上几乎与本地POSIX文件系统保持一致。

第三项原则在于,软件只能够在发布点处进行修改——其他一切客户都只能在高可用性水平下实现只读操作。多数此前存在的文件系统在设计中都无法处理CAP定理提到的权衡难题,因为这类系统会假定客户的目标始终是读取最新的可用数据版本。在这种情况下,软件必须在应用或者容器运行的同时保持即时性,这意味着运行过程中该文件系统必须交付单一快照。

有鉴于此,CERN决定使用内容可寻址存储与梅克尔树状结构。与git类似,各文件会在内部根据其(惟一的)加密内容散列进行命名。存在于不同目录内的同一文件的多套副本(例如不同Ubuntu镜像当中的“ls”实体)会被合并为单一文件。SQlite文件目录取决于其中文件的内容散列值。如此一来,其root散列值(一个160位整数)将最终确定整套文件系统快照。要关闭信任链,系统会提供一个经过加密的root散列值,每个客户端则对接收到的数据的每一位进行验证,从而确保其来自预期来源且未被篡改。

如今,CernVM-FS负责为分布在全球各地的约十万台计算机交付来自大型强子对撞机实验软件的数百万个文件与目录。

Mesos中的容器化器

Mesos通过所谓“容器化器(containerizer)”利用多种实现手段提供任务容器化能力。容器化器负责对运行当中的各个任务加以隔离,同时限定各个任务可以使用的资源量(例如CPU、内存、磁盘以及网络)。Mesos容器化器的作用可以通过所谓“隔离器(isolator)”轻松得到扩展,后者可被视为一种执行特定任务的插件(举例来说,在容器当中启动外部分卷)。

最后但同样重要的是,容器化器还能够为任务提供一套运行时环境。它允许用户将全部关联性同任务本体一道预打包至文件系统镜像当中。这套镜像随后可进行任意分发,并被用于启动该项任务。

Mesos目前已经拥有多种类型的容器化器。其默认选项为Mesos容器化器——这款工具采用Linux命名空间与cgropus以实现任务隔离同资源使用量控制,同时配合一整套隔离器实现外部功能交付。另外还有一套Docker容器化器,其利用Docker工具以提取镜像并启动Docker容器。

Mesos容器化器目前已通过扩展实现了多种镜像格式的支持能力,其中包括Docker与AppC,旨在建立一套“统一容器化器”。这套方案令新镜像格式的支持变得非常轻松:利用统一容器化器,我们只需要为新的镜像格式构建一款所谓“配置器(provisioner)”,并复用全部现有隔离代码即可。举例来说,Mesos用户可以继续使用Docker镜像,但全部提取、隔离与其它任务都通过Mesos而非Docker工具实现。

集成CernVM-FS与Mesos以实现容器镜像分发

内容可寻址存储的介入、出色的安全水平以及久经考验的扩展能力使得CernVM-FS成为一款极具吸引力的容器镜像分发处理工具。为了测试其实际效果,我们创建了一套新的CernVM-FS库,并将其添加到一套Ubuntu安装软件包当中。在此之后,我们立足于CVMFS构建了一款Mesos容器镜像配置器。相较于直接下载完整镜像,它能够利用CernVM-FS客户端以本地方式远程启动镜像root目录。该配置器可将CernVM-FS库名称作为输入数据(其在内部被映射至该CernVM-FS服务器的URL)以及充当容器镜像root所必需的库内路径。

如此一来,我们就能够立足于同一CernVM-FS库实现多种容器镜像的发布。从本质上讲,CernVM-FS库的作用等同于一套安全且可扩展的容器镜像注册表。

从容器化器的角度来看,一切其实丝毫未受影响。它仍然负责处理包含有镜像目录树的本地目录,并利用一切必要元素实现容器启动。不过这种作法的最大优势在于CernVM-FS拥有经过细化调整的重复数据删除功能(在配合Docker的情况下,基于文件或者块而非层),这意味着我们现在能够在无需下载完整镜像的前提下启动容器。一旦容器启动完成,CernVM-FS会下载必要的文件以进行任务处理。

在我们的测试当中,我们启动了一套Ubuntu容器,而后在shell当中运行了一条命令。在传统场景当中,我们需要下载完整的Ubuntu镜像,其体积约为300 MB。然而,当我们使用CernVM-FS配置器时,我们只需要下载该任务所必需的文件——具体为不足6MB。

由于CernVM-FS采用内容可寻址存储,因此我们不需要重复下载同样的文件。所以,如果我们进一步启动其它容器(例如一套CentOS镜像)并运行不同的命令,那么我们只需要下载新命令所需要的文件,并复用此前已经在Ubuntu镜像中下载过的全部通用关联性(例如Bash或者libc.so)。在这种模式下,容器层的概念已经不复存在,重复数据删除将立足于更为细化的层面进行。

我们还计划添加对该配置器的支持以利用对应的检验机制启动任意CernVM-FS目录。这将帮助开发人员更为轻松地在处理容器镜像时实现快速迭代,并使得运维人员便捷地在不同容器镜像版本间来回切换。

配合容器普及的浪潮

CERN与Mesosphere的技术团队对于将CernVM-FS与Apache Mesos集成充满期待,这也意味着IT行业将更为广泛地采纳应用程序容器技术。如果各企业与机构希望从根本层面改善应用程序构建、代码部署以及数据中心运行的实现方式,则必须要立足于高于当前实际规模的水平上进行容器的启动、关闭、更新以及管理。CernVM-FS与Mesos之间的紧密集成将能够成为一种可行途径,帮助各类用户解决容器采纳道路上的存储容量及网络带宽瓶颈。

作为一项新兴的技术,关于Docker的坑很多,需要我们共同来填满。大家如果有相关的疑问和困惑,也欢迎留言和小数进行讨论。

原文链接:https://mesosphere.com/blog/2016/03/08/cernvmfs-mesos-containers/

 

云计算与 Cloud Native|数人云CEO王璞@KVM分享实录

宁静胡同 发表了文章 • 0 个评论 • 372 次浏览 • 2016-03-09 16:11 • 来自相关话题

 
今天小数又给大家带来一篇干货满满的分享——来自KVM社区线上群分享的实录,分享嘉宾是数人云CEO王璞,题目是《云计算与 Cloud Native 》。这是数人云在KVM社区群分享的第一弹,之后还有数人云CTO肖德时、COO谢乐冰的Docker与Mesos的应用实战经验分享,敬请期待!

嘉宾介绍

王璞,数人云创始人兼CEO

美国 George Mason 大学计算机博士。擅长分布式计算、大规模机器学习、海量数据处理。曾担任 Google 广告部门数据平台构架师,负责管理每秒访问量全球最高的架构平台。


云计算技术源于互联网公司,现在云计算已经是下一代企业级IT的发展趋势。云计算最大的特点是弹性和灵活,帮助企业应对复杂的业务需求。但是基于云计算的IT构架和上一代的IT构架有很大不同,只有云原生应用(Cloud Native Application)才能充分发挥云计算弹性和灵活的特性。
 
目前,微服务是云原生应用比较主流的一种构架,微服务的理念是用服务来实现功能模块组件化,把大的业务逻辑拆为多个很微小的服务,每个微服务实现一个简单的功能,微服务之间松散耦合。遵从微服务构架的应用具有弹性和灵活的特性,但是在构架上,微服务比传统应用构架复杂很多。
PaaS平台的出现帮助开发人员打造云原生应用,让开发人员专注于业务开发层面,并为构架层面保驾护航。然而上一代的PaaS平台过于复杂和笨重,没有得到广泛的应用。基于Docker和Mesos打造的DCOS是下一代轻量级PaaS平台的典型代表,DCOS极大地降低了PaaS平台的复杂度,更加方便企业开发人员实现各种业务应用,帮助企业轻松打造基于云计算的软件基础设施。

Google如何做云计算

Google一直是云计算技术的领导者。我有幸在Google工作,接触到了Google强大的内部云计算平台。Google所有的数据中心加起来有大约数百万台服务器,这么多服务器被Google的分布式管理平台Borg统一管理,形成巨大的资源池,支撑了Google庞大的业务体系。Google把所有的服务器分成了近百个集群,每个集群称为一个Cell。每个Cell由几万台处于同一物理位置的服务器组成,每个Cell由几个Borg主节点负责管理其余几万台服务器,被管理的每台服务器对应一个Borg从节点。


Google的开发人员会向Borg提交任务执行申请,Borg负责把任务运行在一个或多个Cell。Borg运行的任务有优先级,高优先级的任务会抢占低优先级任务的资源。为了防止过度抢占,Borg在管理每个Cell资源的时候,任务优先级越高,可供分配的总资源越少,反之,任务优先级越低,可供分配的总资源越多,保证低优先级的任务也会得到很好的执行,而不会总被高优先级任务抢占。

Google内部虽然没有强调PaaS、容器、不可变基础设施(Immutable Infrastructure)以及微服务的概念,但是Google内部处处体现着这些理念。

首先,Google内部的云计算平台除了Borg,还有各种软件基础设施,比如Google File System、MapReduce、BigTable、Chubby、Stubby、PubSub等等,组成了一个功能无比强大的PaaS。这些软件基础设施满足了基于Google内部云计算平台开发时碰到的各种需求,使得Google的开发人员在开发时非常方便,可以专注于业务本身,而不必过多考虑可扩展性、容错性等等复杂的问题,极大地提高了开发效率。这正是PaaS的功能,提高开发效率,降低开发复杂度,保证应用的性能、可靠性等等。

其次,Google内部的业务应用,都是把业务程序和各种依赖库打包在一起,形成巨大的二进制文件,这样应用程序在生产环境的服务器上运行的时候,不需要额外的依赖。更进一步,Google内部不同应用程序在同一服务器上运行时,是用Cgroup技术进行资源隔离,防止某个程序占用过多资源。这些其实都是容器的理念,让应用程序具备了可移植性,并对应用进行资源隔离。

再者,Google内部生产环境服务器,基本上是被Borg自动管理,每台服务器上只安装Linux、Borg程序以及必备的监控程序等,开发或运维人员几乎不会登陆上去做什么操作。这样,Google每台生产环境服务器的状态都是不可变的,极大地简化了对服务器的运维管理工作,这正是不可变基础设施的理念。

另外,Google内部也是按照微服务的方式来组织构架团队。Google各个大的部门内部,按照不同的业务功能划分出不同的小团队,每个小团队负责开发维护一个具体的功能模块组件,也就是一个“微”服务。不同微服务之间通过远程过程调用(RPC)相互协同依赖,实现了很大规模的业务。比如我之前所在的团队,是负责Google广告平台用户数据收集的业务,所维护的微服务有数千个应用实例在运行。

云原生应用与传统架构

云计算最大的特点是弹性和灵活,企业采用云计算技术可以轻松应对复杂的业务需求。一般来说,云计算分为三层,IaaS、PaaS和SaaS:IaaS提供资源弹性,PaaS提供应用弹性,SaaS提供服务弹性。目前IaaS和SaaS相对成熟,PaaS相对早期。PaaS最大的作用是帮助企业打造云原生应用(Cloud Native Application),使得企业的业务应用充分享受云计算带来的灵活和弹性。

传统IT构架最大的问题在于不能满足复杂的业务需求。企业信息化经过多年发展,很多企业的业务已经实现了IT化。每家企业都面临着激烈的商业竞争,业务的需求往往纷繁复杂,势必要求IT系统能灵活应对业务的需求,但实际情况并非如此,往往是企业业务部门的需求很长时间IT部门才能实现。云计算的出现,很大程度缓解了企业内部IT跟不上业务发展需求的矛盾。


云原生应用的优点体现在具有良好的可扩展性、伸缩性和容错性:当业务需求发生变化时,云原生应用可以做到快速迭代;当业务规模发生变化时,云原生应用可以做到弹性伸缩;当IT系统出现软硬件故障时,云原生应用有良好的容错机制,可以做到让业务应用不宕机。云原生应用的这些特性,能极大地帮助企业提升业务能力,在激烈的竞争中占据优势。互联网公司的快速发展,已经印证了云计算技术和云原生应用相比传统IT构架的巨大优势。

 
但是云原生应用的种种良好特性并不是很轻易就能实现的,企业开发人员在开发业务应用的时候,还要考虑未来应用的可扩展性和容错性,这极大地增加了开发的复杂度。于是PaaS的出现,正是要帮助开发人员降低云原生应用的开发复杂度,让开发人员还是专注于业务应用的开发,为开发人员屏蔽底层细节。

PaaS往往会制定出一些开发范式,只要企业的开发人员遵从这些范式,那么开发出的业务应用就能获得云原生应用的特性。但是以CloudFoundry为代表的上一代PaaS,由于规范过于复杂,没有在企业级得到很好的应用。下一代轻量级PaaS(Micro PaaS),特别强调轻量的特性,没有对开发人员制定过多的开发范式,更多是在软件设计层面给出指导,极大地降低了使用门槛。比如,轻量级PaaS倡导应用遵从微服务构架设计,就能具有良好的可扩展性;再如,轻量级PaaS倡导应用尽量遵从无状态设计,就能获得良好的容错性。微服务构架和无状态设计,更多是软件设计理念,而不是诸如EJB、RESTful这样具体的编程规范,降低了开发人员的学习成本,对开发人员更加友好。

 
微服务和SOA异同点

微服务是眼下非常流行的应用设计框架。如前所述,微服务不是具体的编程规范,而是软件设计理念。微服务是伴随互联网公司业务规模快速扩张进而演化得来的设计模式,Google、Amazon、Netflix这些互联网巨头都是微服务的先行者和倡导者。遵从微服务设计,使得互联网巨头的业务应用具有良好的可扩展性:一方面保持业务应用快速迭代,同时应用迭代速度没有随着业务规模扩展急剧减缓;另一方面保证业务应用具有弹性伸缩能力,能处理海量业务带来的巨大负载。

微服务有几个主要的设计理念:

1、通过服务实现组件化。传统的IT构架是把所有的业务逻辑用一个大而全的应用来实现,各个功能组件模块是在一个应用内部。这样做的后果是模块之间很容易紧密耦合,随着应用越来越大,失去了可扩展性,一旦要修改业务逻辑,就会牵一发而动全身,导致应用迭代非常缓慢。微服务使用服务的形式来实现各个功能组件模块,各个模块间的依赖通过服务的方式来组织,即一个模块通过远程过程调用来依赖另一个模块,每个模块是一个微服务。这样做使得模块之间很容易松散耦合,每个微服务规定好服务的形式,诸如请求的格式以及响应的格式,然后多个微服务组合起来共同实现整个业务逻辑。如图一所示。






图一:整体型应用程序与微服务架构应用程序

 
2、微服务的松散耦合构架,使得企业可以按照业务功能来组织团队,每个小团队负责一个微服务,以降低团队间的沟通成本。很多企业的研发团队通常按开发职责划分,诸如前端开发团队、中间件开发团队、数据库团队等等。这样按职责划分加大了团队间沟通成本,因为每个具体的业务需求都有可能涉及前后端,因此多个职能团队要配合才能实现具体的业务需求,这样无疑沟通成本很高。按照微服务的方式,团队是按业务功能来组织划分,而不是按照开发职责划分,这样可以让具体的业务需求落在某个团队内部,避免涉及多个团队,从而极大地降低了团队间的沟通成本。这也符合康威法则:任何组织在设计一套系统(广义层面的系统)时,其设计成果都会直接体现该组织所使用的沟通结构。如图二所示。






图二:康威定律的实际体现

3、企业按照业务功能来组织团队,每个团队负责一个微服务,可以做到“谁构建,谁运行”,这将极大降低运维复杂度。如果按照传统的IT方式,开发团队开发出来的应用交给运维团队去上线维护,不仅周期长,而且运维复杂度高,因为运维团队毕竟不了解业务实现细节,应用出了问题还需要涉及开发和运维两个团队来配合。如果按照微服务的方式,每个团队开发一个微服务,并负责该微服务的上线运行,不涉及运维团队,这样做不仅周期短,而且降低运维复杂度,某个微服务出现问题仅涉及所负责的开发团队。“谁构建,谁运行”还可以让每个团队都经历整个产品的生命周期。采用微服务构架后,运维团队将更多负责整体业务相关的工作,比如整体业务的资源规划、稳定性、性能等等。

4、有了微服务,可以方便地做到离散化数据管理。每个微服务可以自行管理各自的数据,包括不同业务的数据、不同微服务的配置等等,更加切实匹配业务需求。如图三所示。
 





图三:微服务架构的离散数据管理

5、微服务构架使得持续集成和持续交付变得更加便捷。对比传统IT构架,有了微服务,集成和交付的单元从大而全的整体应用变成了各个微服务。这样,每个微服务都可以灵活地集成和交付,降低了集成和交付的复杂度,提高了业务应用迭代的速度,进而提升了企业的业务能力。如图四所示。






图四:微服务构架使得持续集成和持续交付变得更加便捷

微服务经常被拿来与十年前就提出的面向服务架构(SOA)进行比较,因为微服务和SOA有相似的主张。SOA实际所指的是利用企业服务总线实现的集成化整体应用程序,企业服务总线通常包含复杂度极高的消息跌幅、编排、转换以及业务规则应用等机制。准确讲,SOA是中间件时代的一种开发范式,微服务是云计算时代轻量级PaaS的开发范式。

 
支撑微服务的问题和挑战

前面提到微服务最大好处是使得应用具有可扩展性,方便灵活应对业务的复杂需求。凡事必有两面性,微服务提升了应用的可扩展性,但是微服务也有其复杂性的一面。

首先,微服务以服务的形式实现组件化模块化,不同功能模块组件之间通过服务的形式,即远程过程调用的方式,来相互通讯。这样一来,模块或组件间的耦合度降低了,但是通讯效率也降低了。毕竟远程过程调用比共享内存的方式要慢很多。此外,为了提高应用的容错性,一般微服务之间的远程过程调用都尽量设计为异步通讯的方式。异步通讯显然比同步通讯在开发复杂度方面增加不少。

其次,对于按微服务构架设计的应用进行修改迭代的时候,如果要修改的部分仅限于某个或某些微服务组件内部,那就比较容易,不涉及微服务组件间的依赖,比如更改一个微服务内部的业务逻辑、把一个微服务组件分拆为多个微服务。但是一旦要修改的部分要牵扯到已有微服务组件之间的依赖,那改动起来还是有一定工作量的,比如远程过程调用的接口修改,或者更进一步,重新定义两个或多个微服务之间的业务边界。如果微服务构架设计的不好,应用迭代的时候频繁更改微服务间的依赖关系,也就失去了良好的可扩展性。

再者,由于按照微服务构架设计的应用天然是分布式应用,势必在故障排除方面增加了复杂度。分布式应用的维护对远程监控的依赖很强,因为分布式应用会运行在很多台服务器上,而且会在不同服务器上动态调度迁移,一旦发生故障,不可能要求运维人员逐一检查每台服务器,必须有统一的监控平台,实时监控应用的运行情况,并统一收集日志用于故障排查。此外,微服务之间如果是异步通讯机制,也增加了错误检查的复杂度。

 
下一代轻量级PaaS:基于Docker+Mesos的DCOS

基于Docker和Mesos打造的Data Center Operating System(DCOS),是下一代轻量级PaaS的代表。以Docker为代表的容器技术,为DCOS和企业业务应用之间,定义了清晰的边界:DCOS提供统一的、标准的容器运行环境,满足容器运行时的各种需求,诸如调度、编排、容错恢复、弹性伸缩、服务发现、负载均衡、监控报警等等;容器内部封装企业的业务应用,为应用提供良好的可移植性。


DCOS的轻量特性主要体现在如下方面:

首先,企业的开发人员不需要了解容器之外的太多细节,使得开发人员可以专注于开发业务,降低了开发人员的开发复杂度。

其次,DCOS为云原生应用提供良好的弹性,包括可扩展性、伸缩性和容错性。开发人员遵从微服务构架和无状态设计开发云原生应用,一方面可以通过DCOS快速集成和交付上线,加快迭代周期,另一方面DCOS为云原生应用提供很好的弹性伸缩能力,可以按需使用计算资源,再一方面DCOS使云原生应用具有很好的容错能力。

再者,DCOS极大地降低了运维复杂度。DCOS实现了不可变基础设施,DCOS在每台服务器上只安装Linux、Docker、Mesos等DCOS的组件,不包括任何业务应用相关的依赖,再加上DCOS的容错机制,使得生产系统的运维复杂度大大降低。

总之,云计算是下一代企业级IT的发展趋势,云计算相关技术正在逐渐演化成熟,特别是PaaS领域的技术,正在快速发展。以DCOS为代表的下一代轻量级PaaS正逐渐为企业客户所接受。因为DCOS具有轻量的优点,只要企业开发人员遵从微服务和无状态设计开发出云原生业务应用,DCOS就能保证云原生应用具有良好的可扩展性、伸缩性和容错性。这极大地提升了企业IT的灵活性,缓解了IT跟不上业务发展需求的矛盾,帮助企业快速应对业务需求,提升企业业务能力。

 
精彩问答

QQ群 | KVM虚拟化1群


Q1. 云计算弹性与灵活,更多在应用业务的弹性与灵活、快速上线,然而需要庞大的基础设施支撑、同时需要虚拟化、容器技术支撑,若没有这些技术云计算很难做到弹性、灵活,请问在银行业务,银行更多是的使用 小机 Powervm 云计算该如何去做呢?

 

A1. 目前 DCOS 还不支持小型机。云计算的趋势是x86化。

 

Q2. 云计算解决了应用业务快速上线,弹性与灵活,基础环境的灵活弹性。个人认为云计算需要庞大的基础设施(Datacenter)环境及高效的设施,基础环境设施很重要。

 

A2. 的确是很重要。而且数据中心基础设施复杂度很高,不应该每个公司都搞一遍。数据中心必须要有很大规模,才能降低边际成本。

 

QQ群 | KVM虚拟化2群

 

Q1. 请问,银行如何转型新型IT模式呢,云计算将如何在银行领域进行落地呢?个人觉得 IT 市场还是在银行领域,1. 银行有钱 2. IT服务银行用的最多,最广泛。

 

A1. 云计算将帮助金融类客户减轻IT系统的复杂度,让客户的业务应用更轻量、有弹性,灵活应对复杂多变的业务需求。下一代企业级IT肯定是要往轻量化方向发展,注重应用的弹性。

金融机构对IT服务有需求,而且有付费意愿

 

Q2. 企业如何去构架一个真正的云计算数据中心呢?构架成什么样才能达到云计算特性呢?

 

A2. 云计算最根本的特性是弹性。云计算的弹性包括三层:

IaaS 提供资源弹性,PaaS 提供应用弹性,SaaS 提供服务弹性。

包含这三层弹性才是完整的云计算弹性。

 

Q3. 真正的要将云计算进行落地,从技术角度该如何做呢?要遵循什么样的机制去构建云计算数据中心,或者说怎样能达到云计算、灵活、弹性。需要用那些技术做构建呢?

 

A3. 其实主要是 IaaS 相关技术和 PaaS 相关技术。

IaaS 领域主要的技术就是虚拟化技术,包括虚拟主机、SDN、软件定义存储等。

PaaS 领域的技术相对不够成熟,目前 PaaS 领域最流行的技术就是 Docker,还有对 Docker 管理调度的技术,比如 Mesos、K8s、Swarm 等,以及 Docke r网络和存储管理的技术,比如Calico 和 Flocker。

 

微信群 | 云实名技术

 

Q1. DCOS 是不是在 Docker 之上还做了管理?

 

A1. 是的,DCOS目前用Mesos管理Docker

 

Q2. 微服务应该是对一个传统的应用进行拆分吧?

 

A2. 肯定要拆分。微服务的拆分不仅是业务应用实现层面拆分,对开发团队的组织也要拆分成小团队。微服务的拆分不是按照开发职责拆(不是按前端开发、后段开发来拆),而是按照业务职责拆

 

Q3. 能具体描述下 Mesos 的功能吗?Mesos 和 Marathon 是否都可以管理 Docker,其差别在哪里?

 

A3. Mesos 主要是用于资源管理,Mesos 不直接管理 Docker。Marathon 是基于 Mesos 做任务调度,Marathon 支持管理调度 Docker 任务。

 

Q4. 我们现在用 Kubernetes,但是实践中,碰到了太多问题,想换 Swarm,有什么好的建议吗,如果用 Mesos 呢?

 

A4. K8s 和 Swarm 都比较新,还没有经过很大规模生产系统验证。Mesos 相对成熟一些,Twitter 用 Mesos 管理上万台物理服务器。这些开源技术在易用性方面都有缺陷,毕竟只是技术不是产品。

 

微信群 | 《运维前线》

 

Q1. Docker 如何解决网络流量隔离的问题?

 

A1. Docker 目前在网络方面还很弱,目前没有非常成熟的方案,Calico 是我们目前在尝试的方案

 

Q2. 把所有的服务拆成微服务之后是不是会给整个系统带来复杂性?这个微应该微到什么程度?

 

A2. 的确微服务会提高系统复杂度,所以微服务非常需要PaaS来简化系统复杂度。

微服务该多微小,这个没有一般性标准,要按照业务来定。一般来讲,一个微服务最好实现一个单一功能。

 

Q3. 谁构建,谁运行,那微服务团队内部懂各种技术的人员都需要存在了,懂开发语言的,懂平台软件的,懂运维的,人员的成本是否也上去了呢?

 

A3. PaaS平台的作用就是降低开发人员的开发难度,减轻运维工作复杂度。有了PaaS平台之后,懂平台软件的人可以减少,运维的工作变轻,开发人员可以专注业务开发而无需考虑很多底层细节。

 

Q4. 没有开发能力的运维能上不?

 

A4. 可以,运维本来就不要很强的开发能力。PaaS平台就是要降低运维复杂度。Immutable Infrastructure会极大减轻运维的工作复杂度。

 

Q5. 单单靠一个paas平台实现太多,势必会造成另外的一个极端。

 

A5. 是的。所以PaaS平台本身也要轻量化。上一代PaaS没有流行起来就是因为不够轻量,不够灵活。云计算时代,企业客户都偏向轻量化的平台和应用。

 

Q6. 数人云在docker领域主要做了哪些改进,提供哪些特色功能或者服务?

 

A6. 数人云对Docker本身没有什么改动,就是标准的Docker开源版本。数人云的主要工作在对于Docker的管理调度方面,包括服务发现、负载均衡、灰度发布、弹性伸缩等等。 查看全部
 

今天小数又给大家带来一篇干货满满的分享——来自KVM社区线上群分享的实录,分享嘉宾是数人云CEO王璞,题目是《云计算与 Cloud Native 》。这是数人云在KVM社区群分享的第一弹,之后还有数人云CTO肖德时、COO谢乐冰的Docker与Mesos的应用实战经验分享,敬请期待!



嘉宾介绍

王璞,数人云创始人兼CEO

美国 George Mason 大学计算机博士。擅长分布式计算、大规模机器学习、海量数据处理。曾担任 Google 广告部门数据平台构架师,负责管理每秒访问量全球最高的架构平台。


云计算技术源于互联网公司,现在云计算已经是下一代企业级IT的发展趋势。云计算最大的特点是弹性和灵活,帮助企业应对复杂的业务需求。但是基于云计算的IT构架和上一代的IT构架有很大不同,只有云原生应用(Cloud Native Application)才能充分发挥云计算弹性和灵活的特性。
 
目前,微服务是云原生应用比较主流的一种构架,微服务的理念是用服务来实现功能模块组件化,把大的业务逻辑拆为多个很微小的服务,每个微服务实现一个简单的功能,微服务之间松散耦合。遵从微服务构架的应用具有弹性和灵活的特性,但是在构架上,微服务比传统应用构架复杂很多。
PaaS平台的出现帮助开发人员打造云原生应用,让开发人员专注于业务开发层面,并为构架层面保驾护航。然而上一代的PaaS平台过于复杂和笨重,没有得到广泛的应用。基于Docker和Mesos打造的DCOS是下一代轻量级PaaS平台的典型代表,DCOS极大地降低了PaaS平台的复杂度,更加方便企业开发人员实现各种业务应用,帮助企业轻松打造基于云计算的软件基础设施。

Google如何做云计算

Google一直是云计算技术的领导者。我有幸在Google工作,接触到了Google强大的内部云计算平台。Google所有的数据中心加起来有大约数百万台服务器,这么多服务器被Google的分布式管理平台Borg统一管理,形成巨大的资源池,支撑了Google庞大的业务体系。Google把所有的服务器分成了近百个集群,每个集群称为一个Cell。每个Cell由几万台处于同一物理位置的服务器组成,每个Cell由几个Borg主节点负责管理其余几万台服务器,被管理的每台服务器对应一个Borg从节点。


Google的开发人员会向Borg提交任务执行申请,Borg负责把任务运行在一个或多个Cell。Borg运行的任务有优先级,高优先级的任务会抢占低优先级任务的资源。为了防止过度抢占,Borg在管理每个Cell资源的时候,任务优先级越高,可供分配的总资源越少,反之,任务优先级越低,可供分配的总资源越多,保证低优先级的任务也会得到很好的执行,而不会总被高优先级任务抢占。

Google内部虽然没有强调PaaS、容器、不可变基础设施(Immutable Infrastructure)以及微服务的概念,但是Google内部处处体现着这些理念。

首先,Google内部的云计算平台除了Borg,还有各种软件基础设施,比如Google File System、MapReduce、BigTable、Chubby、Stubby、PubSub等等,组成了一个功能无比强大的PaaS。这些软件基础设施满足了基于Google内部云计算平台开发时碰到的各种需求,使得Google的开发人员在开发时非常方便,可以专注于业务本身,而不必过多考虑可扩展性、容错性等等复杂的问题,极大地提高了开发效率。这正是PaaS的功能,提高开发效率,降低开发复杂度,保证应用的性能、可靠性等等。

其次,Google内部的业务应用,都是把业务程序和各种依赖库打包在一起,形成巨大的二进制文件,这样应用程序在生产环境的服务器上运行的时候,不需要额外的依赖。更进一步,Google内部不同应用程序在同一服务器上运行时,是用Cgroup技术进行资源隔离,防止某个程序占用过多资源。这些其实都是容器的理念,让应用程序具备了可移植性,并对应用进行资源隔离。

再者,Google内部生产环境服务器,基本上是被Borg自动管理,每台服务器上只安装Linux、Borg程序以及必备的监控程序等,开发或运维人员几乎不会登陆上去做什么操作。这样,Google每台生产环境服务器的状态都是不可变的,极大地简化了对服务器的运维管理工作,这正是不可变基础设施的理念。

另外,Google内部也是按照微服务的方式来组织构架团队。Google各个大的部门内部,按照不同的业务功能划分出不同的小团队,每个小团队负责开发维护一个具体的功能模块组件,也就是一个“微”服务。不同微服务之间通过远程过程调用(RPC)相互协同依赖,实现了很大规模的业务。比如我之前所在的团队,是负责Google广告平台用户数据收集的业务,所维护的微服务有数千个应用实例在运行。

云原生应用与传统架构

云计算最大的特点是弹性和灵活,企业采用云计算技术可以轻松应对复杂的业务需求。一般来说,云计算分为三层,IaaS、PaaS和SaaS:IaaS提供资源弹性,PaaS提供应用弹性,SaaS提供服务弹性。目前IaaS和SaaS相对成熟,PaaS相对早期。PaaS最大的作用是帮助企业打造云原生应用(Cloud Native Application),使得企业的业务应用充分享受云计算带来的灵活和弹性。

传统IT构架最大的问题在于不能满足复杂的业务需求。企业信息化经过多年发展,很多企业的业务已经实现了IT化。每家企业都面临着激烈的商业竞争,业务的需求往往纷繁复杂,势必要求IT系统能灵活应对业务的需求,但实际情况并非如此,往往是企业业务部门的需求很长时间IT部门才能实现。云计算的出现,很大程度缓解了企业内部IT跟不上业务发展需求的矛盾。


云原生应用的优点体现在具有良好的可扩展性、伸缩性和容错性:当业务需求发生变化时,云原生应用可以做到快速迭代;当业务规模发生变化时,云原生应用可以做到弹性伸缩;当IT系统出现软硬件故障时,云原生应用有良好的容错机制,可以做到让业务应用不宕机。云原生应用的这些特性,能极大地帮助企业提升业务能力,在激烈的竞争中占据优势。互联网公司的快速发展,已经印证了云计算技术和云原生应用相比传统IT构架的巨大优势。

 
但是云原生应用的种种良好特性并不是很轻易就能实现的,企业开发人员在开发业务应用的时候,还要考虑未来应用的可扩展性和容错性,这极大地增加了开发的复杂度。于是PaaS的出现,正是要帮助开发人员降低云原生应用的开发复杂度,让开发人员还是专注于业务应用的开发,为开发人员屏蔽底层细节。

PaaS往往会制定出一些开发范式,只要企业的开发人员遵从这些范式,那么开发出的业务应用就能获得云原生应用的特性。但是以CloudFoundry为代表的上一代PaaS,由于规范过于复杂,没有在企业级得到很好的应用。下一代轻量级PaaS(Micro PaaS),特别强调轻量的特性,没有对开发人员制定过多的开发范式,更多是在软件设计层面给出指导,极大地降低了使用门槛。比如,轻量级PaaS倡导应用遵从微服务构架设计,就能具有良好的可扩展性;再如,轻量级PaaS倡导应用尽量遵从无状态设计,就能获得良好的容错性。微服务构架和无状态设计,更多是软件设计理念,而不是诸如EJB、RESTful这样具体的编程规范,降低了开发人员的学习成本,对开发人员更加友好。

 
微服务和SOA异同点

微服务是眼下非常流行的应用设计框架。如前所述,微服务不是具体的编程规范,而是软件设计理念。微服务是伴随互联网公司业务规模快速扩张进而演化得来的设计模式,Google、Amazon、Netflix这些互联网巨头都是微服务的先行者和倡导者。遵从微服务设计,使得互联网巨头的业务应用具有良好的可扩展性:一方面保持业务应用快速迭代,同时应用迭代速度没有随着业务规模扩展急剧减缓;另一方面保证业务应用具有弹性伸缩能力,能处理海量业务带来的巨大负载。

微服务有几个主要的设计理念:

1、通过服务实现组件化。传统的IT构架是把所有的业务逻辑用一个大而全的应用来实现,各个功能组件模块是在一个应用内部。这样做的后果是模块之间很容易紧密耦合,随着应用越来越大,失去了可扩展性,一旦要修改业务逻辑,就会牵一发而动全身,导致应用迭代非常缓慢。微服务使用服务的形式来实现各个功能组件模块,各个模块间的依赖通过服务的方式来组织,即一个模块通过远程过程调用来依赖另一个模块,每个模块是一个微服务。这样做使得模块之间很容易松散耦合,每个微服务规定好服务的形式,诸如请求的格式以及响应的格式,然后多个微服务组合起来共同实现整个业务逻辑。如图一所示。

1.jpg


图一:整体型应用程序与微服务架构应用程序

 
2、微服务的松散耦合构架,使得企业可以按照业务功能来组织团队,每个小团队负责一个微服务,以降低团队间的沟通成本。很多企业的研发团队通常按开发职责划分,诸如前端开发团队、中间件开发团队、数据库团队等等。这样按职责划分加大了团队间沟通成本,因为每个具体的业务需求都有可能涉及前后端,因此多个职能团队要配合才能实现具体的业务需求,这样无疑沟通成本很高。按照微服务的方式,团队是按业务功能来组织划分,而不是按照开发职责划分,这样可以让具体的业务需求落在某个团队内部,避免涉及多个团队,从而极大地降低了团队间的沟通成本。这也符合康威法则:任何组织在设计一套系统(广义层面的系统)时,其设计成果都会直接体现该组织所使用的沟通结构。如图二所示。

2.jpg


图二:康威定律的实际体现

3、企业按照业务功能来组织团队,每个团队负责一个微服务,可以做到“谁构建,谁运行”,这将极大降低运维复杂度。如果按照传统的IT方式,开发团队开发出来的应用交给运维团队去上线维护,不仅周期长,而且运维复杂度高,因为运维团队毕竟不了解业务实现细节,应用出了问题还需要涉及开发和运维两个团队来配合。如果按照微服务的方式,每个团队开发一个微服务,并负责该微服务的上线运行,不涉及运维团队,这样做不仅周期短,而且降低运维复杂度,某个微服务出现问题仅涉及所负责的开发团队。“谁构建,谁运行”还可以让每个团队都经历整个产品的生命周期。采用微服务构架后,运维团队将更多负责整体业务相关的工作,比如整体业务的资源规划、稳定性、性能等等。

4、有了微服务,可以方便地做到离散化数据管理。每个微服务可以自行管理各自的数据,包括不同业务的数据、不同微服务的配置等等,更加切实匹配业务需求。如图三所示。
 
3.JPG


图三:微服务架构的离散数据管理

5、微服务构架使得持续集成和持续交付变得更加便捷。对比传统IT构架,有了微服务,集成和交付的单元从大而全的整体应用变成了各个微服务。这样,每个微服务都可以灵活地集成和交付,降低了集成和交付的复杂度,提高了业务应用迭代的速度,进而提升了企业的业务能力。如图四所示。

4.JPG


图四:微服务构架使得持续集成和持续交付变得更加便捷

微服务经常被拿来与十年前就提出的面向服务架构(SOA)进行比较,因为微服务和SOA有相似的主张。SOA实际所指的是利用企业服务总线实现的集成化整体应用程序,企业服务总线通常包含复杂度极高的消息跌幅、编排、转换以及业务规则应用等机制。准确讲,SOA是中间件时代的一种开发范式,微服务是云计算时代轻量级PaaS的开发范式。

 
支撑微服务的问题和挑战

前面提到微服务最大好处是使得应用具有可扩展性,方便灵活应对业务的复杂需求。凡事必有两面性,微服务提升了应用的可扩展性,但是微服务也有其复杂性的一面。

首先,微服务以服务的形式实现组件化模块化,不同功能模块组件之间通过服务的形式,即远程过程调用的方式,来相互通讯。这样一来,模块或组件间的耦合度降低了,但是通讯效率也降低了。毕竟远程过程调用比共享内存的方式要慢很多。此外,为了提高应用的容错性,一般微服务之间的远程过程调用都尽量设计为异步通讯的方式。异步通讯显然比同步通讯在开发复杂度方面增加不少。

其次,对于按微服务构架设计的应用进行修改迭代的时候,如果要修改的部分仅限于某个或某些微服务组件内部,那就比较容易,不涉及微服务组件间的依赖,比如更改一个微服务内部的业务逻辑、把一个微服务组件分拆为多个微服务。但是一旦要修改的部分要牵扯到已有微服务组件之间的依赖,那改动起来还是有一定工作量的,比如远程过程调用的接口修改,或者更进一步,重新定义两个或多个微服务之间的业务边界。如果微服务构架设计的不好,应用迭代的时候频繁更改微服务间的依赖关系,也就失去了良好的可扩展性。

再者,由于按照微服务构架设计的应用天然是分布式应用,势必在故障排除方面增加了复杂度。分布式应用的维护对远程监控的依赖很强,因为分布式应用会运行在很多台服务器上,而且会在不同服务器上动态调度迁移,一旦发生故障,不可能要求运维人员逐一检查每台服务器,必须有统一的监控平台,实时监控应用的运行情况,并统一收集日志用于故障排查。此外,微服务之间如果是异步通讯机制,也增加了错误检查的复杂度。

 
下一代轻量级PaaS:基于Docker+Mesos的DCOS


基于Docker和Mesos打造的Data Center Operating System(DCOS),是下一代轻量级PaaS的代表。以Docker为代表的容器技术,为DCOS和企业业务应用之间,定义了清晰的边界:DCOS提供统一的、标准的容器运行环境,满足容器运行时的各种需求,诸如调度、编排、容错恢复、弹性伸缩、服务发现、负载均衡、监控报警等等;容器内部封装企业的业务应用,为应用提供良好的可移植性。


DCOS的轻量特性主要体现在如下方面:

首先,企业的开发人员不需要了解容器之外的太多细节,使得开发人员可以专注于开发业务,降低了开发人员的开发复杂度。

其次,DCOS为云原生应用提供良好的弹性,包括可扩展性、伸缩性和容错性。开发人员遵从微服务构架和无状态设计开发云原生应用,一方面可以通过DCOS快速集成和交付上线,加快迭代周期,另一方面DCOS为云原生应用提供很好的弹性伸缩能力,可以按需使用计算资源,再一方面DCOS使云原生应用具有很好的容错能力。

再者,DCOS极大地降低了运维复杂度。DCOS实现了不可变基础设施,DCOS在每台服务器上只安装Linux、Docker、Mesos等DCOS的组件,不包括任何业务应用相关的依赖,再加上DCOS的容错机制,使得生产系统的运维复杂度大大降低。

总之,云计算是下一代企业级IT的发展趋势,云计算相关技术正在逐渐演化成熟,特别是PaaS领域的技术,正在快速发展。以DCOS为代表的下一代轻量级PaaS正逐渐为企业客户所接受。因为DCOS具有轻量的优点,只要企业开发人员遵从微服务和无状态设计开发出云原生业务应用,DCOS就能保证云原生应用具有良好的可扩展性、伸缩性和容错性。这极大地提升了企业IT的灵活性,缓解了IT跟不上业务发展需求的矛盾,帮助企业快速应对业务需求,提升企业业务能力。

 
精彩问答

QQ群 | KVM虚拟化1群


Q1. 云计算弹性与灵活,更多在应用业务的弹性与灵活、快速上线,然而需要庞大的基础设施支撑、同时需要虚拟化、容器技术支撑,若没有这些技术云计算很难做到弹性、灵活,请问在银行业务,银行更多是的使用 小机 Powervm 云计算该如何去做呢?

 

A1. 目前 DCOS 还不支持小型机。云计算的趋势是x86化。

 

Q2. 云计算解决了应用业务快速上线,弹性与灵活,基础环境的灵活弹性。个人认为云计算需要庞大的基础设施(Datacenter)环境及高效的设施,基础环境设施很重要。

 

A2. 的确是很重要。而且数据中心基础设施复杂度很高,不应该每个公司都搞一遍。数据中心必须要有很大规模,才能降低边际成本。

 

QQ群 | KVM虚拟化2群

 

Q1. 请问,银行如何转型新型IT模式呢,云计算将如何在银行领域进行落地呢?个人觉得 IT 市场还是在银行领域,1. 银行有钱 2. IT服务银行用的最多,最广泛。

 

A1. 云计算将帮助金融类客户减轻IT系统的复杂度,让客户的业务应用更轻量、有弹性,灵活应对复杂多变的业务需求。下一代企业级IT肯定是要往轻量化方向发展,注重应用的弹性。

金融机构对IT服务有需求,而且有付费意愿

 

Q2. 企业如何去构架一个真正的云计算数据中心呢?构架成什么样才能达到云计算特性呢?

 

A2. 云计算最根本的特性是弹性。云计算的弹性包括三层:

IaaS 提供资源弹性,PaaS 提供应用弹性,SaaS 提供服务弹性。

包含这三层弹性才是完整的云计算弹性。

 

Q3. 真正的要将云计算进行落地,从技术角度该如何做呢?要遵循什么样的机制去构建云计算数据中心,或者说怎样能达到云计算、灵活、弹性。需要用那些技术做构建呢?

 

A3. 其实主要是 IaaS 相关技术和 PaaS 相关技术。

IaaS 领域主要的技术就是虚拟化技术,包括虚拟主机、SDN、软件定义存储等。

PaaS 领域的技术相对不够成熟,目前 PaaS 领域最流行的技术就是 Docker,还有对 Docker 管理调度的技术,比如 Mesos、K8s、Swarm 等,以及 Docke r网络和存储管理的技术,比如Calico 和 Flocker。

 

微信群 | 云实名技术

 

Q1. DCOS 是不是在 Docker 之上还做了管理?

 

A1. 是的,DCOS目前用Mesos管理Docker

 

Q2. 微服务应该是对一个传统的应用进行拆分吧?

 

A2. 肯定要拆分。微服务的拆分不仅是业务应用实现层面拆分,对开发团队的组织也要拆分成小团队。微服务的拆分不是按照开发职责拆(不是按前端开发、后段开发来拆),而是按照业务职责拆

 

Q3. 能具体描述下 Mesos 的功能吗?Mesos 和 Marathon 是否都可以管理 Docker,其差别在哪里?

 

A3. Mesos 主要是用于资源管理,Mesos 不直接管理 Docker。Marathon 是基于 Mesos 做任务调度,Marathon 支持管理调度 Docker 任务。

 

Q4. 我们现在用 Kubernetes,但是实践中,碰到了太多问题,想换 Swarm,有什么好的建议吗,如果用 Mesos 呢?

 

A4. K8s 和 Swarm 都比较新,还没有经过很大规模生产系统验证。Mesos 相对成熟一些,Twitter 用 Mesos 管理上万台物理服务器。这些开源技术在易用性方面都有缺陷,毕竟只是技术不是产品。

 

微信群 | 《运维前线》

 

Q1. Docker 如何解决网络流量隔离的问题?

 

A1. Docker 目前在网络方面还很弱,目前没有非常成熟的方案,Calico 是我们目前在尝试的方案

 

Q2. 把所有的服务拆成微服务之后是不是会给整个系统带来复杂性?这个微应该微到什么程度?

 

A2. 的确微服务会提高系统复杂度,所以微服务非常需要PaaS来简化系统复杂度。

微服务该多微小,这个没有一般性标准,要按照业务来定。一般来讲,一个微服务最好实现一个单一功能。

 

Q3. 谁构建,谁运行,那微服务团队内部懂各种技术的人员都需要存在了,懂开发语言的,懂平台软件的,懂运维的,人员的成本是否也上去了呢?

 

A3. PaaS平台的作用就是降低开发人员的开发难度,减轻运维工作复杂度。有了PaaS平台之后,懂平台软件的人可以减少,运维的工作变轻,开发人员可以专注业务开发而无需考虑很多底层细节。

 

Q4. 没有开发能力的运维能上不?

 

A4. 可以,运维本来就不要很强的开发能力。PaaS平台就是要降低运维复杂度。Immutable Infrastructure会极大减轻运维的工作复杂度。

 

Q5. 单单靠一个paas平台实现太多,势必会造成另外的一个极端。

 

A5. 是的。所以PaaS平台本身也要轻量化。上一代PaaS没有流行起来就是因为不够轻量,不够灵活。云计算时代,企业客户都偏向轻量化的平台和应用。

 

Q6. 数人云在docker领域主要做了哪些改进,提供哪些特色功能或者服务?

 

A6. 数人云对Docker本身没有什么改动,就是标准的Docker开源版本。数人云的主要工作在对于Docker的管理调度方面,包括服务发现、负载均衡、灰度发布、弹性伸缩等等。