致:正在选择CI平台的你(10大要素需把控)

杨y 发表了文章 • 0 个评论 • 39 次浏览 • 2017-07-21 18:58 • 来自相关话题

对于程序员来说,最纠结的恐怕是如何在众多工具和应用中选取合适的那个,小数之前给大家分享了8种CI/CD工具,用以提高交付效率和质量,今天再和谈谈选择CI平台要考虑的10大要素,前人栽树后人乘凉~

持续集成(CI)是一种软件开发实践,即团队开发成员经常集成他们的工作,通过每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽早地发现集成错误。

CI是采用DevOps的关键性一步,所以选择正确的平台无比重要。

以下是选择平台需要评估的10大要素:

NO.1 快速构建

CI平台的主要目标是为开发者提供代码检测的快速反馈,如:有一个存储库,每天进行2次更新,每年大约有500次更新,如果此存储库的构建速度快5分钟,将节省(5 * 500)/(60 * 8) = 5.2 个工作日,因此若有多个存储库就会发现,即使在构建时加快几分钟,也能大大提高生产率。

NO.2 集成

应该与构建所需的语言和第三方工具相结合,支持源代码管理系统以及编程语言、测试工具、打包工具和推送应用程序包的存储库及部署端点。CI平台应轻松地将这些集成起来并开始工作,一般情况下,建议使用具有规模大的平台,以便后续不受限制地采用不同工具。

NO.3 免费方案

免费方案或试用期是选择CI平台的关键因素,若没有免费方案,无法确切了解原理,也很难与有竞争力的产品进行比较做出决策。智能CI平台应说服潜在客户试用免费方案或无限制免费试用,用户一旦了解了高级功能的价值,即会做出明智选择。

NO.4 快速简便设置

CI服务需要快速方便地安装使用,若发现自己问了太多关于如何使用平台来实现简单场景的问题,这意味着服务太复杂,操作不便。如果优秀的使用文档和案例最好,且可以通过在线聊天系统即时询问。

NO.5 容器的支撑

Docker逐渐成为主流,应该选择具有支持Docker的平台,即便尚未使用容器,也应未雨绸缪。提前进行部署,如此CI平台才不会成为迁移到Docker的瓶颈。

NO.6 多点运行、版本、环境

支持多点运行,这样可以确保应用在不同场景中正常使用,同时也帮助测试语言的环境,并在采用新语言版本之前发现潜在问题。

NO.7 代码覆盖率、测试结果可视化

能在不使用任何其他工具的情况下,显示代码覆盖率和测试结果的信息,充分实现可视化。

NO.8 Build-as-Code

可以通过命令行的通用语法(如YAML文件)进行简单的配置,该文件可以与命令行一起使用并进行版本控制。UI配置相对比较笨重,使用命令行可以改善。

NO.9 灵活的基础设施选择

支持基础设施处理和满足安全要求。如果是资源密集型构建,要可以购买更大的节点。如果是严谨的金融技术型公司,建议应用开发放在内网,则CI平台要有企业版。

NO.10 客户支持团队

最后,询问CI平台是否有客户支持团队,并允许开发人员不需要太繁琐的手续或操作即可对其进行询问,因为传统的客服对产品或客户场景无法很好理解,只是提供了表面的支持。如果CI平台组建了客户支持团队,表明愿意采取主动的方式来帮助客户解决问题。

原文作者: Pavan Belagatti 原文链接:https://dzone.com/articles/10- ... tform 查看全部

QQ图片20170721185708.png


对于程序员来说,最纠结的恐怕是如何在众多工具和应用中选取合适的那个,小数之前给大家分享了8种CI/CD工具,用以提高交付效率和质量,今天再和谈谈选择CI平台要考虑的10大要素,前人栽树后人乘凉~

持续集成(CI)是一种软件开发实践,即团队开发成员经常集成他们的工作,通过每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽早地发现集成错误。

CI是采用DevOps的关键性一步,所以选择正确的平台无比重要。

以下是选择平台需要评估的10大要素:

NO.1 快速构建

CI平台的主要目标是为开发者提供代码检测的快速反馈,如:有一个存储库,每天进行2次更新,每年大约有500次更新,如果此存储库的构建速度快5分钟,将节省(5 * 500)/(60 * 8) = 5.2 个工作日,因此若有多个存储库就会发现,即使在构建时加快几分钟,也能大大提高生产率。

NO.2 集成

应该与构建所需的语言和第三方工具相结合,支持源代码管理系统以及编程语言、测试工具、打包工具和推送应用程序包的存储库及部署端点。CI平台应轻松地将这些集成起来并开始工作,一般情况下,建议使用具有规模大的平台,以便后续不受限制地采用不同工具。

NO.3 免费方案

免费方案或试用期是选择CI平台的关键因素,若没有免费方案,无法确切了解原理,也很难与有竞争力的产品进行比较做出决策。智能CI平台应说服潜在客户试用免费方案或无限制免费试用,用户一旦了解了高级功能的价值,即会做出明智选择。

NO.4 快速简便设置

CI服务需要快速方便地安装使用,若发现自己问了太多关于如何使用平台来实现简单场景的问题,这意味着服务太复杂,操作不便。如果优秀的使用文档和案例最好,且可以通过在线聊天系统即时询问。

NO.5 容器的支撑

Docker逐渐成为主流,应该选择具有支持Docker的平台,即便尚未使用容器,也应未雨绸缪。提前进行部署,如此CI平台才不会成为迁移到Docker的瓶颈。

NO.6 多点运行、版本、环境

支持多点运行,这样可以确保应用在不同场景中正常使用,同时也帮助测试语言的环境,并在采用新语言版本之前发现潜在问题。

NO.7 代码覆盖率、测试结果可视化

能在不使用任何其他工具的情况下,显示代码覆盖率和测试结果的信息,充分实现可视化。

NO.8 Build-as-Code

可以通过命令行的通用语法(如YAML文件)进行简单的配置,该文件可以与命令行一起使用并进行版本控制。UI配置相对比较笨重,使用命令行可以改善。

NO.9 灵活的基础设施选择

支持基础设施处理和满足安全要求。如果是资源密集型构建,要可以购买更大的节点。如果是严谨的金融技术型公司,建议应用开发放在内网,则CI平台要有企业版。

NO.10 客户支持团队

最后,询问CI平台是否有客户支持团队,并允许开发人员不需要太繁琐的手续或操作即可对其进行询问,因为传统的客服对产品或客户场景无法很好理解,只是提供了表面的支持。如果CI平台组建了客户支持团队,表明愿意采取主动的方式来帮助客户解决问题。

原文作者: Pavan Belagatti 原文链接:https://dzone.com/articles/10- ... tform

DevOps、敏捷开发、云计算,三剑客的小时代

杨y 发表了文章 • 0 个评论 • 40 次浏览 • 2017-07-21 18:52 • 来自相关话题

前言

在开发和创新领域中,DevOps、敏捷开发以及云计算终于突破了布道阶段逐步成为主流,本篇文章讲述将三种模式结合在一起所带来的巨大收益。

随着数字化的快速发展,整个世界都在全方位转型,过去的十年中,个人和职业生活都受到了技术的深刻影响,这一切可能要归功于DevOps。

DevOps出现前

2013年,敏捷开发受到很多开发者的青睐,这让开发和其他合作团队在部署上线方面出现瓶颈,从而产生了一些矛盾。

开发急于交付应用,运维难以同样的速度维护业务流程,两个团队都被和整体业务无关的自身需求束缚住。

DevOps出现后

在此背景下,DevOps应运而生,强调通过敏捷方法使软件交付和部署自动化,让两个团队一起工作。这种模式下的应用生命周期如:构建、测试、交付等都出现了重大转变。

应用可以算得上是创新的代名词,用户可以随时收到更新的应用,DevOps转变运营和管理工具链,让越来越多的公司获得成功。

技术上的优势:

持续交付
降低复杂度
快速解决问题

文化上的好处:

工作增加趣味
提高员工敬业度
职业发展机会增加

商业利益:

快速交付应用
稳定的操作环境
改善沟通和协作
更多时间用于创新

DevOps与敏捷开发

许多公司相信,敏捷开发可以极大改善用户体验,DevOps可以从这些新来源增加收入。敏捷开发是应用反映体系,如:应用必须反映业务需求,在快速的基础上进行测试。简而言之,应用必须更好的反应业务所面临的的挑战和现实状况。

DevOps像另一种系统——技术、方法和规则。它是一种端对端应用开发周期更全面的方法,不仅扩展了敏捷开发实践,同时只需简单的通过持续交付、测试、反馈和协作等概念简化软件变更过程。

不同的策略为应用开发带来了价值,若将DevOps和敏捷开发结合在一起,会将价值最大化:

员工满意度:两种策略相结合,可以提高员工满意度,为其创造更有发挥空间的环境,不会轻易离职。

用户满意度:越来越多的企业利用DevOps和敏捷开发在竞争中保持领先地位,因为轻松关键会让开发团队提高参与度,从而做到高品质的产出,提升用户的忠诚度,吸引新用户。

DevOps与云计算

基础设施、应用的部署、更新是开发生命周期的重要瓶颈,云计算永久地改变了IT基础设施,使用AWS和Azure等即可启用云端基础设施。云计算已经成为了实用场景,广泛应用于开发中。DevOps非常适用于云计算的开发方式。

DevOps和云计算被称为天作之合的原因:

首先,云计算的集中化特性为DevOps提供了标准且自动化的平台,用于测试、部署和生产。因分布式的特性,企业系统不能很好地与集中式软件部署匹配,但在云平台的帮助下,很多问题迎刃而解。

其次,DevOps自动化正逐步以云计算为中心,许多服务商已经开始在平台上支持DevOps。集成使本地自动化技术成本降低,通过云端控制要比各个部分控制更容易。

最后,可以帮助用户监控应用、开发、用户数据等的资源使用度,传统系统无法提供此类服务,基于云计算的DevOps减少了资源利用需求和开发成本,并能根据需求进行调整。

结语

DevOps、云计算、敏捷开发正在各个领域的企业中证明价值:支持灵活定价和快速提供服务;降低了管理开发及运行时基础设施的总成本;无需自行开发的企业,只要有基础设施即可采用云计算和DevOps实践。

DevOps、云计算、敏捷开发是重塑整个IT行业的三剑客,若云计算是一种乐器,DevOps就是演奏家。它们一起帮助行业转移重心,无需再担心宕机、交付时间和快速部署之类的问题。

原文作者:Dhrumit Shukla 原文链接:https://dzone.com/articles/dev ... three 查看全部
前言

在开发和创新领域中,DevOps、敏捷开发以及云计算终于突破了布道阶段逐步成为主流,本篇文章讲述将三种模式结合在一起所带来的巨大收益。

随着数字化的快速发展,整个世界都在全方位转型,过去的十年中,个人和职业生活都受到了技术的深刻影响,这一切可能要归功于DevOps。

DevOps出现前

2013年,敏捷开发受到很多开发者的青睐,这让开发和其他合作团队在部署上线方面出现瓶颈,从而产生了一些矛盾。

开发急于交付应用,运维难以同样的速度维护业务流程,两个团队都被和整体业务无关的自身需求束缚住。

DevOps出现后

在此背景下,DevOps应运而生,强调通过敏捷方法使软件交付和部署自动化,让两个团队一起工作。这种模式下的应用生命周期如:构建、测试、交付等都出现了重大转变。

应用可以算得上是创新的代名词,用户可以随时收到更新的应用,DevOps转变运营和管理工具链,让越来越多的公司获得成功。

技术上的优势:

持续交付
降低复杂度
快速解决问题

文化上的好处:

工作增加趣味
提高员工敬业度
职业发展机会增加

商业利益:

快速交付应用
稳定的操作环境
改善沟通和协作
更多时间用于创新

DevOps与敏捷开发

许多公司相信,敏捷开发可以极大改善用户体验,DevOps可以从这些新来源增加收入。敏捷开发是应用反映体系,如:应用必须反映业务需求,在快速的基础上进行测试。简而言之,应用必须更好的反应业务所面临的的挑战和现实状况。

DevOps像另一种系统——技术、方法和规则。它是一种端对端应用开发周期更全面的方法,不仅扩展了敏捷开发实践,同时只需简单的通过持续交付、测试、反馈和协作等概念简化软件变更过程。

不同的策略为应用开发带来了价值,若将DevOps和敏捷开发结合在一起,会将价值最大化:

员工满意度:两种策略相结合,可以提高员工满意度,为其创造更有发挥空间的环境,不会轻易离职。

用户满意度:越来越多的企业利用DevOps和敏捷开发在竞争中保持领先地位,因为轻松关键会让开发团队提高参与度,从而做到高品质的产出,提升用户的忠诚度,吸引新用户。

DevOps与云计算

基础设施、应用的部署、更新是开发生命周期的重要瓶颈,云计算永久地改变了IT基础设施,使用AWS和Azure等即可启用云端基础设施。云计算已经成为了实用场景,广泛应用于开发中。DevOps非常适用于云计算的开发方式。

DevOps和云计算被称为天作之合的原因:

首先,云计算的集中化特性为DevOps提供了标准且自动化的平台,用于测试、部署和生产。因分布式的特性,企业系统不能很好地与集中式软件部署匹配,但在云平台的帮助下,很多问题迎刃而解。

其次,DevOps自动化正逐步以云计算为中心,许多服务商已经开始在平台上支持DevOps。集成使本地自动化技术成本降低,通过云端控制要比各个部分控制更容易。

最后,可以帮助用户监控应用、开发、用户数据等的资源使用度,传统系统无法提供此类服务,基于云计算的DevOps减少了资源利用需求和开发成本,并能根据需求进行调整。

结语

DevOps、云计算、敏捷开发正在各个领域的企业中证明价值:支持灵活定价和快速提供服务;降低了管理开发及运行时基础设施的总成本;无需自行开发的企业,只要有基础设施即可采用云计算和DevOps实践。

DevOps、云计算、敏捷开发是重塑整个IT行业的三剑客,若云计算是一种乐器,DevOps就是演奏家。它们一起帮助行业转移重心,无需再担心宕机、交付时间和快速部署之类的问题。

原文作者:Dhrumit Shukla 原文链接:https://dzone.com/articles/dev ... three

Serverless架构用这5大优势,挽救了后来7亿用户的Instagram

杨y 发表了文章 • 0 个评论 • 74 次浏览 • 2017-07-06 14:20 • 来自相关话题

数人云之前分享的文章:《关于Serverless架构及平台选择,你知道多少?》详细地讲述了发展历史和公有云的Serverless服务平台,今天小数再讲讲它的5大优势,在如缩短交付周期等功能上与DevOps&SRE不谋而合。

图片社交巨头Instagram面对流量爆增,通过Serverless完成自救。果然创业艰辛,而这也恰恰证明了Serveless架构逐渐成为主流技术是有道理的。

Instagram&Serverless

Serverless架构在IT行业蓄势待发,并非没有道理。尽管这是一个相对较新的技术,但已引起了广泛的关注,许多新技术专家指出,Serverless架构具有缩短交付时间,改善操作和安全实践等功能,以及创造出一种革命性的付费模式——按资源消耗付费。

2010年Instagram发布时,差点因其准备不足而无法成为下一个白手起家的社交媒体公司。

在短短的6个小时之内,暴增的流量超过了其在洛杉矶服务器所能承受的负载。

联合创始人Mike Krieger和Kevin Systrom被迫将本地服务器紧急迁移到Amazon的E2C云服务上,他们称之为心脏手术。也正是这个举措挽救了Instagram。

经过六年的快速发展,Serverless架构取得了巨大的成果,不止简单的将现有服务器迁移到云端帮助扩展和操作,还采用弹性计算这种新的方法来简化开发过程。为Uber、口袋妖怪GO、部落冲突、Airbnb和其他具有大量基数的应用及实时数据提供了必要的保障。

在苹果或者谷歌的游戏应用商店里,有超过400万个应想供用户选择,开发人员为了寻求竞争优势,逐步转向Serverless架构。游戏应用的开发成本很容易就到达6位数,但90%的付费应用每天收入不到1250美元。通过降低成本和内部复杂性,Serverless架构帮助开发者应对激烈竞争的市场,以及提供良好的用户体验。

例如,利用全球网络数据流,无需繁琐构建架构和维护服务器,为什么不这样做呢?

Serverless架构的秘密 对于开发者来说,Serverless架构可以将其服务器端应用程序分解成多个执行不同任务的函数,整个应用分为几个独立、松散耦合的组件,这些组件可以在任何规模上运行。

Serverless需要这些功能运行在并行的容器上,分别监控和缩放。这种新的体系结构提供了几个关键点,并解决了其他软件挑战性和伸缩性问题。

举个例子:实时过滤聊天评论。许多聊天应用的业务需求大都是每条信息必须经过过滤、解析或在交付给收件人之前进行管理。

通常的方法是每条消息首先会发送到服务器,解析并重新发布到聊天室,对于少量的同步用户可能有用,但若有100万用户的话,简单的聊天过滤问题就会变成分布式计算的噩梦。

同样的问题对于Serverless架构来说简直是无痛的,开发人员写一个过滤聊天信息的函数。Serverless将函数封装到容器中,可以在任意数量的服务器上监控、备份和分发。开发人员将所有聊天信息路由到程序,只需运行更多容器即可确保逻辑能在任何规模上运行。

Serverless架构的优势

无论是正在开发一个聊天应用,还是想成为下一个口袋妖怪GO,Serverless架构都是最好的选择。

〓 缩短交付时间

Serverless架构允许开发人员在极短时间内(数天、数小时)交付新的应用程序,而不是像以前一样需要几个星期或数月。在新的应用程序中,依赖于第三方API提供服务的例子很多,如认证(OAuth)、社交(Twitter)、地图(Mapbox)、人工智能(IBM的Watson)等等。

〓 增强可伸缩性

所有人都希望自己开发的应用成为下一个Facebook,但若梦想成真,它能够负载吗?当成功降临却没有准备好就更加令人遗憾。Serverless架构的体系不用有上述担忧,如某个在线培训APP,6个月内获取了4万用户,但一个服务器都没有用。

〓 降低成本

Serverless架构模式可以降低计算能力和人力资源方面的成本,如果不需要服务器,就不用花费时间重新造轮子、风险监测、图像处理、以及基础设施管理,操作成本更会直线下降。

〓 改善用户体验

用户不太关心基础设施,更注重的是功能和用户体验。Serverless架构允许团队将资源集中在用户体验上。例如:气象公司利用Serverless架构给种植者提供了丰富的界面去操作农场设备,并会提示相关操作改进。

〓 减少延迟及优化地理位置信息

应用规模能力取决于三个方面:用户数量、所在位置及网络延迟。现在应用要面向全球受众,因而产生延迟降低体验。在Serverless架构下,供应商在每个用户附近都有节点,大幅度降低了延迟,因此对每个用户都适用。如:Gett在全球范围内提供按需服务,因此它选择了Serverless架构来降低延迟,即时消息连接司机和乘客,以及流媒体的地理位置更新。

结语

从照片分享应用到农业数据仪表盘再到连接引擎,Serverless架构可以满足开发者的广泛需求。

随着数据负载的持续增长,期待Serverless架构通过降低成本、延迟、交付时间和复杂性,成为应用开发领域的主要技术。

关于Serverless架构,你还知道哪些其他的优势吗? 查看全部

微信图片_20170705144139.jpg


数人云之前分享的文章:《关于Serverless架构及平台选择,你知道多少?》详细地讲述了发展历史和公有云的Serverless服务平台,今天小数再讲讲它的5大优势,在如缩短交付周期等功能上与DevOps&SRE不谋而合。

图片社交巨头Instagram面对流量爆增,通过Serverless完成自救。果然创业艰辛,而这也恰恰证明了Serveless架构逐渐成为主流技术是有道理的。

Instagram&Serverless

Serverless架构在IT行业蓄势待发,并非没有道理。尽管这是一个相对较新的技术,但已引起了广泛的关注,许多新技术专家指出,Serverless架构具有缩短交付时间,改善操作和安全实践等功能,以及创造出一种革命性的付费模式——按资源消耗付费。

2010年Instagram发布时,差点因其准备不足而无法成为下一个白手起家的社交媒体公司。

在短短的6个小时之内,暴增的流量超过了其在洛杉矶服务器所能承受的负载。

联合创始人Mike Krieger和Kevin Systrom被迫将本地服务器紧急迁移到Amazon的E2C云服务上,他们称之为心脏手术。也正是这个举措挽救了Instagram。

经过六年的快速发展,Serverless架构取得了巨大的成果,不止简单的将现有服务器迁移到云端帮助扩展和操作,还采用弹性计算这种新的方法来简化开发过程。为Uber、口袋妖怪GO、部落冲突、Airbnb和其他具有大量基数的应用及实时数据提供了必要的保障。

在苹果或者谷歌的游戏应用商店里,有超过400万个应想供用户选择,开发人员为了寻求竞争优势,逐步转向Serverless架构。游戏应用的开发成本很容易就到达6位数,但90%的付费应用每天收入不到1250美元。通过降低成本和内部复杂性,Serverless架构帮助开发者应对激烈竞争的市场,以及提供良好的用户体验。

例如,利用全球网络数据流,无需繁琐构建架构和维护服务器,为什么不这样做呢?

Serverless架构的秘密 对于开发者来说,Serverless架构可以将其服务器端应用程序分解成多个执行不同任务的函数,整个应用分为几个独立、松散耦合的组件,这些组件可以在任何规模上运行。

Serverless需要这些功能运行在并行的容器上,分别监控和缩放。这种新的体系结构提供了几个关键点,并解决了其他软件挑战性和伸缩性问题。

举个例子:实时过滤聊天评论。许多聊天应用的业务需求大都是每条信息必须经过过滤、解析或在交付给收件人之前进行管理。

通常的方法是每条消息首先会发送到服务器,解析并重新发布到聊天室,对于少量的同步用户可能有用,但若有100万用户的话,简单的聊天过滤问题就会变成分布式计算的噩梦。

同样的问题对于Serverless架构来说简直是无痛的,开发人员写一个过滤聊天信息的函数。Serverless将函数封装到容器中,可以在任意数量的服务器上监控、备份和分发。开发人员将所有聊天信息路由到程序,只需运行更多容器即可确保逻辑能在任何规模上运行。

Serverless架构的优势

无论是正在开发一个聊天应用,还是想成为下一个口袋妖怪GO,Serverless架构都是最好的选择。

〓 缩短交付时间

Serverless架构允许开发人员在极短时间内(数天、数小时)交付新的应用程序,而不是像以前一样需要几个星期或数月。在新的应用程序中,依赖于第三方API提供服务的例子很多,如认证(OAuth)、社交(Twitter)、地图(Mapbox)、人工智能(IBM的Watson)等等。

〓 增强可伸缩性

所有人都希望自己开发的应用成为下一个Facebook,但若梦想成真,它能够负载吗?当成功降临却没有准备好就更加令人遗憾。Serverless架构的体系不用有上述担忧,如某个在线培训APP,6个月内获取了4万用户,但一个服务器都没有用。

〓 降低成本

Serverless架构模式可以降低计算能力和人力资源方面的成本,如果不需要服务器,就不用花费时间重新造轮子、风险监测、图像处理、以及基础设施管理,操作成本更会直线下降。

〓 改善用户体验

用户不太关心基础设施,更注重的是功能和用户体验。Serverless架构允许团队将资源集中在用户体验上。例如:气象公司利用Serverless架构给种植者提供了丰富的界面去操作农场设备,并会提示相关操作改进。

〓 减少延迟及优化地理位置信息

应用规模能力取决于三个方面:用户数量、所在位置及网络延迟。现在应用要面向全球受众,因而产生延迟降低体验。在Serverless架构下,供应商在每个用户附近都有节点,大幅度降低了延迟,因此对每个用户都适用。如:Gett在全球范围内提供按需服务,因此它选择了Serverless架构来降低延迟,即时消息连接司机和乘客,以及流媒体的地理位置更新。

结语

从照片分享应用到农业数据仪表盘再到连接引擎,Serverless架构可以满足开发者的广泛需求。

随着数据负载的持续增长,期待Serverless架构通过降低成本、延迟、交付时间和复杂性,成为应用开发领域的主要技术。

关于Serverless架构,你还知道哪些其他的优势吗?

crane现在不能部署

xds2000 回复了问题 • 2 人关注 • 1 个回复 • 428 次浏览 • 2017-05-11 01:22 • 来自相关话题

五个小技巧,快速创建Docker镜像

宁静胡同 发表了文章 • 0 个评论 • 477 次浏览 • 2017-01-06 14:51 • 来自相关话题

毫无疑问,容器是DevOps世界一个突破性的技术。镜像创建对于部署和发布环节都非常重要。那么如何效率地创建和使用镜像来提升部署速度呢?以下是作者的经验和分享,大家不妨一试——


1. 尽可能多地缓存网络下载

通常部署需要从Internet下载成百上千MB的数据。因此部署常受到网速慢或者断网的困扰。

而缓存得越多,部署得就会越快。最终的目标是实现Docker镜像离线一键部署。


2. 把Docker镜像看做Plain OS Golden Image

Docker很强力,但是我们也有很多VM或者裸机部署。为了避免供应商锁定,通常需要选择是否用Docker支持部署,最好两种场景都实施部署持续集成。

举例来说,如果使用kitchen来做持续集成。默认情况下,使用自定义Docker镜像来测试。当IMAGE_NAME指定为ubuntu:14.04时,可以很肯定ubuntu:14.04系统对于部署非常适用。


3. 审核Docker镜像里所有包和服务的安装

从镜像起一个Docker容器,然后列出并检查所有安装的包/服务。

为什么要这么做?首先我们希望Docker镜像尽可能地小,镜像交付就会很快速。其次,包/服务越多,问题也会越多,例如包冲突,TCP端口占有问题。一些服务的安装后脚本甚至会改变关键性的全局配置文件或者留下不可预期的flagfile。所以最好让Docker镜像保持傻傻的单纯。


4. Docker构建的最后清理关闭所有服务

如果不这么做,服务会在Docker镜像的最后阶段被杀掉。在/var/lock/*下的服务的lockfile如果没有被正确使用,当测试新建镜像的部署时,服务可能会启动失败,导致测试无效。


5. 添加验证步骤,确保镜像正常

当有改变发生时,我们时不时需要重构Docker镜像。为了确保一切正常,我们可以在Docker构建过程中添加自动验证逻辑。


这是一个简单的例子,实践了上述提到的技巧。
########## How To Use Docker Image ###############
## docker run -t -d --privileged -p 8022:22 \
## denny/mydockertest:v1 /usr/sbin/sshd -D
##
##################################################

FROM denny/sshd:v1
MAINTAINER Deny <denny@dennyzhang.com>
ARG devops_branch=master
ARG working_dir=/root/chef
##################################################
# Install basic packages
RUN apt-get -yqq update && \
apt-get -yqq install curl && \
apt-get -yqq install openssh-server && \
apt-get install -y sudo lsb-release && \
# Install chef
curl -L https://www.opscode.com/chef/install.sh | bash && \
# clean up files to make this docker layer smaller
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean
##################################################
# checkout code
RUN bash /root/git_update.sh ${working_dir} \
git@github.com:DennyZhang/chef_community_cookbooks.git \
${devops_branch} && \
echo "cookbook_path [\"${working_dir}/${devops_branch}/mdmdevops/community_cookbooks\", \
\"${working_dir}/${devops_branch}/mdmdevops/cookbooks\"]" \
> /root/client.rb

# Chef all-in-one deployment. This step takes minutes
RUN echo "{\"run_list\": [\"recipe[all-in-one::predownload]\"]}" \
> /root/client.json && \
chef-solo --config /root/client.rb -j /root/client.json && \
# Clean up to make docker image smaller
rm -rf /tmp/* /var/tmp/* && \
rm -rf /var/chef/cache/jdk-*.tar.gz && \
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean
##################################################

# Shutdown services
RUN service couchbase-server stop || true && \
service elasticsearch stop || true && \
service nagios3 stop || true && \
service apache2 stop || true && \
service haproxy stop || true && \
service nagios-nrpe-server stop || true && \
rm -rf /run/apache2/apache2.pid && \
rm -rf /var/log/apache2/* && \
rm -rf /usr/local/var/run/vagrant_ubuntu_trusty_64.pid && \
rm -rf /root/docker.rb /root/docker.json

# Verify docker image
RUN test -f /var/chef/cache/couchbase-server-enterprise_4.1.0-ubuntu14.04_amd64.deb && \
test -f /var/chef/cache/elasticsearch-2.3.3.deb && \
test -f /etc/apt/sources.list.d/ruby2.1-repo.list && \
test -f /etc/apt/sources.list.d/haproxy-repo.list && \
dpkg -s haproxy | grep "1.6.5"

# Clean up to make docker image smaller
RUN rm -rf /tmp/* /var/tmp/* /var/chef/cache/jdk-*.tar.gz && \
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean

EXPOSE 22
CMD ["/usr/sbin/sshd", "-D"]
##################################################



作者:Denny Zhang
文章来源:https://dennyzhang.github.io/d ... .html 查看全部

毫无疑问,容器是DevOps世界一个突破性的技术。镜像创建对于部署和发布环节都非常重要。那么如何效率地创建和使用镜像来提升部署速度呢?以下是作者的经验和分享,大家不妨一试——




1. 尽可能多地缓存网络下载

通常部署需要从Internet下载成百上千MB的数据。因此部署常受到网速慢或者断网的困扰。

而缓存得越多,部署得就会越快。最终的目标是实现Docker镜像离线一键部署。


2. 把Docker镜像看做Plain OS Golden Image

Docker很强力,但是我们也有很多VM或者裸机部署。为了避免供应商锁定,通常需要选择是否用Docker支持部署,最好两种场景都实施部署持续集成。

举例来说,如果使用kitchen来做持续集成。默认情况下,使用自定义Docker镜像来测试。当IMAGE_NAME指定为ubuntu:14.04时,可以很肯定ubuntu:14.04系统对于部署非常适用。


3. 审核Docker镜像里所有包和服务的安装

从镜像起一个Docker容器,然后列出并检查所有安装的包/服务。

为什么要这么做?首先我们希望Docker镜像尽可能地小,镜像交付就会很快速。其次,包/服务越多,问题也会越多,例如包冲突,TCP端口占有问题。一些服务的安装后脚本甚至会改变关键性的全局配置文件或者留下不可预期的flagfile。所以最好让Docker镜像保持傻傻的单纯。


4. Docker构建的最后清理关闭所有服务

如果不这么做,服务会在Docker镜像的最后阶段被杀掉。在/var/lock/*下的服务的lockfile如果没有被正确使用,当测试新建镜像的部署时,服务可能会启动失败,导致测试无效。


5. 添加验证步骤,确保镜像正常

当有改变发生时,我们时不时需要重构Docker镜像。为了确保一切正常,我们可以在Docker构建过程中添加自动验证逻辑。


这是一个简单的例子,实践了上述提到的技巧。
########## How To Use Docker Image ###############
## docker run -t -d --privileged -p 8022:22 \
## denny/mydockertest:v1 /usr/sbin/sshd -D
##
##################################################

FROM denny/sshd:v1
MAINTAINER Deny <denny@dennyzhang.com>
ARG devops_branch=master
ARG working_dir=/root/chef
##################################################
# Install basic packages
RUN apt-get -yqq update && \
apt-get -yqq install curl && \
apt-get -yqq install openssh-server && \
apt-get install -y sudo lsb-release && \
# Install chef
curl -L https://www.opscode.com/chef/install.sh | bash && \
# clean up files to make this docker layer smaller
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean
##################################################
# checkout code
RUN bash /root/git_update.sh ${working_dir} \
git@github.com:DennyZhang/chef_community_cookbooks.git \
${devops_branch} && \
echo "cookbook_path [\"${working_dir}/${devops_branch}/mdmdevops/community_cookbooks\", \
\"${working_dir}/${devops_branch}/mdmdevops/cookbooks\"]" \
> /root/client.rb

# Chef all-in-one deployment. This step takes minutes
RUN echo "{\"run_list\": [\"recipe[all-in-one::predownload]\"]}" \
> /root/client.json && \
chef-solo --config /root/client.rb -j /root/client.json && \
# Clean up to make docker image smaller
rm -rf /tmp/* /var/tmp/* && \
rm -rf /var/chef/cache/jdk-*.tar.gz && \
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean
##################################################

# Shutdown services
RUN service couchbase-server stop || true && \
service elasticsearch stop || true && \
service nagios3 stop || true && \
service apache2 stop || true && \
service haproxy stop || true && \
service nagios-nrpe-server stop || true && \
rm -rf /run/apache2/apache2.pid && \
rm -rf /var/log/apache2/* && \
rm -rf /usr/local/var/run/vagrant_ubuntu_trusty_64.pid && \
rm -rf /root/docker.rb /root/docker.json

# Verify docker image
RUN test -f /var/chef/cache/couchbase-server-enterprise_4.1.0-ubuntu14.04_amd64.deb && \
test -f /var/chef/cache/elasticsearch-2.3.3.deb && \
test -f /etc/apt/sources.list.d/ruby2.1-repo.list && \
test -f /etc/apt/sources.list.d/haproxy-repo.list && \
dpkg -s haproxy | grep "1.6.5"

# Clean up to make docker image smaller
RUN rm -rf /tmp/* /var/tmp/* /var/chef/cache/jdk-*.tar.gz && \
rm -rf /var/chef/cache/*.plugin && \
rm -rf /usr/share/doc && \
apt-get clean && apt-get autoclean

EXPOSE 22
CMD ["/usr/sbin/sshd", "-D"]
##################################################



作者:Denny Zhang
文章来源:https://dennyzhang.github.io/d ... .html

DevOps 新年计划清单:对失败的准备 say no

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

随着2016年接近尾声,又到了为明年做准备的时候啦。今天的文章里邀请了国外三位嘉宾Andrew Phillips, Tim Buntel,和 TJ Randall,看看业界的思想者们对于DevOps世界新一年有哪些展望,为大家提供一些参考。

1.新浪潮——“下一代平台”将要来临

在2017年,将会有一种聚焦于容器编排框架的“下一代平台”项目,以及将工具重组的PaaS平台,例如OpenShift 或者 Cloud Foundry。对于跨机资源管理和调度框架的需求会持续增长,生态链上的供应商会甩掉身上的重负、快速地跟随上这个趋势。同时在容器标准化上会有一个更清晰的认识,容器自动化也会成为一种必需。

2.应用新定义将成为约定俗成的标准

未来将不再定义应用为“虚拟化设备概念”,就此开启从“为每个应用版本制作亚马逊机器镜像”到软件交付的新阶段。

3.迎刃而上的企业需求

随着下一代平台的实现以及容器自动化,在企业需求上面将会有更多关注点,比如接口控制,审计跟踪和网络技术,在编排层实现“虚拟防火墙”。我们也会看到一波波的案例,充分感受到“它们比看起来的要困难得多”。

4.数据科学/大数据遍地开花

数据科学/大数据项目数量会有一个提升,围绕着测试、持续集成和持续交付将会有各自不同的挑战。更多的商业关注会提高大家对于集群管理工具的接受度,因为多数大数据框架都是运行在它们之上的。

5.软件开发强调分析与监测

自动化进程会产生大量的数据,而自动操作的软件发布越来越多。管理发布的关键信息量十分庞大,散布在一堆工具里。团队需要简化数据来做商业报告,为了更深入地进行使用操作、工作情况的调查,要明确和强调其中不寻常的数据。

6.Serverless Architecture,不再纸上谈兵

PaaS我们已经听了很多年,在这一层之下,Serverless Architecture可以让代码运行而不需要提供或者管理服务器。不再需要提供服务器,也不需要应用一直运行,Serverless Architecture还提供了完全自动化的的水平扩展能力。它们并不是很新的东西(比如AWS Lambda 2014年就出来了),明年有望实现更广泛的使用,而不再只是会议上的一个话题了。

7.企业的应用迁移之路

在古董、过渡和现代应用栈之间的巨大鸿沟,让企业在人员招聘、员工分配和预算上都承受了巨大的压力。新平台面向用户的解决方案有越来越多的成功案例——比如云计算和容器方面——会让公司在新架构应用迁移上投入更多。

8.敏捷驱动和瀑布式交付模式的完美结合

Pipeline和发布编排会成为应用交付进程中非开发人员最时髦的流行词,这些方法会在交付过程中提供企业需要的一致性,以及IT团队需要更快交付解决方案的灵活性。

Benjamin Franklin 曾经说过, “By failingto prepare, you are preparing to fail” 。 
2017 将会成为行业内有巨大变革的一年—— 
你,准备好了吗?

作者:Divesh Rupani 文章来源:https://blog.xebialabs.com/201 ... 2017/ 查看全部
随着2016年接近尾声,又到了为明年做准备的时候啦。今天的文章里邀请了国外三位嘉宾Andrew Phillips, Tim Buntel,和 TJ Randall,看看业界的思想者们对于DevOps世界新一年有哪些展望,为大家提供一些参考。

1.新浪潮——“下一代平台”将要来临

在2017年,将会有一种聚焦于容器编排框架的“下一代平台”项目,以及将工具重组的PaaS平台,例如OpenShift 或者 Cloud Foundry。对于跨机资源管理和调度框架的需求会持续增长,生态链上的供应商会甩掉身上的重负、快速地跟随上这个趋势。同时在容器标准化上会有一个更清晰的认识,容器自动化也会成为一种必需。

2.应用新定义将成为约定俗成的标准

未来将不再定义应用为“虚拟化设备概念”,就此开启从“为每个应用版本制作亚马逊机器镜像”到软件交付的新阶段。

3.迎刃而上的企业需求

随着下一代平台的实现以及容器自动化,在企业需求上面将会有更多关注点,比如接口控制,审计跟踪和网络技术,在编排层实现“虚拟防火墙”。我们也会看到一波波的案例,充分感受到“它们比看起来的要困难得多”。

4.数据科学/大数据遍地开花

数据科学/大数据项目数量会有一个提升,围绕着测试、持续集成和持续交付将会有各自不同的挑战。更多的商业关注会提高大家对于集群管理工具的接受度,因为多数大数据框架都是运行在它们之上的。

5.软件开发强调分析与监测

自动化进程会产生大量的数据,而自动操作的软件发布越来越多。管理发布的关键信息量十分庞大,散布在一堆工具里。团队需要简化数据来做商业报告,为了更深入地进行使用操作、工作情况的调查,要明确和强调其中不寻常的数据。

6.Serverless Architecture,不再纸上谈兵

PaaS我们已经听了很多年,在这一层之下,Serverless Architecture可以让代码运行而不需要提供或者管理服务器。不再需要提供服务器,也不需要应用一直运行,Serverless Architecture还提供了完全自动化的的水平扩展能力。它们并不是很新的东西(比如AWS Lambda 2014年就出来了),明年有望实现更广泛的使用,而不再只是会议上的一个话题了。

7.企业的应用迁移之路

在古董、过渡和现代应用栈之间的巨大鸿沟,让企业在人员招聘、员工分配和预算上都承受了巨大的压力。新平台面向用户的解决方案有越来越多的成功案例——比如云计算和容器方面——会让公司在新架构应用迁移上投入更多。

8.敏捷驱动和瀑布式交付模式的完美结合

Pipeline和发布编排会成为应用交付进程中非开发人员最时髦的流行词,这些方法会在交付过程中提供企业需要的一致性,以及IT团队需要更快交付解决方案的灵活性。

Benjamin Franklin 曾经说过, “By failingto prepare, you are preparing to fail” 。 
2017 将会成为行业内有巨大变革的一年—— 
你,准备好了吗?

作者:Divesh Rupani 文章来源:https://blog.xebialabs.com/201 ... 2017/

Docker 1.13最实用命令行:终于可以愉快地打扫房间了

宁静胡同 发表了文章 • 0 个评论 • 985 次浏览 • 2016-12-16 10:35 • 来自相关话题

Docker1.13出来已经有一段时间了,新版本添加了许多有用的命令,本文作者从处女座的洁癖(此处有雾)出发,告诉大家一些整理环境的小技巧。打扫房间再也不需费时又费力了,简单的命令,就可以轻松地把物品分门别类(容器、镜像、网络、存储卷……)地整理好^_^

在1.13版本中,Docker向CLI添加了一些有用的命令,让环境更加整洁。你可能已经体验了很长时间乱糟糟的开发环境——无用的容器,挂起的Docker镜像,弃置的volume,被遗忘的网络……所有这些过时的事物占据了宝贵的资源,最终导致环境无法使用。在之前的文章中曾经提到用各种各样的命令保持环境的整洁,例如:docker rm -f $(docker ps -aq)

强制地删除所有正在运行的、暂停的以及终止的容器。同样地,也有命令可以删除挂起的镜像、网络和volume。

尽管上述命令解决了问题,但是它们要么专有,要么冗长或者难用。而新加入的命令直截了当又简单好用,现在就开始一一介绍吧。



管理命令

为了整理CLI,Docker 1.13引进了新的管理命令,如下:
systemcontainerimagepluginsecret

Docker的老版本中已经有了 network, node, service, swarm 和 volume 。这些新命令组子命令过去作为root命令直接实现。举个例子:docker exec -it [container-name] [some-command]
exec 命令现在是 container 下面的一个子命令,这个命令相当于:docker container exec -it [container-name] [some-command]

个人猜测为了兼容性的考虑,旧语句眼下还会使用一段时间。


Docker系统

现在有一个新管理命令 system 。它有4个子命令分别是 df, events, info 和 prune 。命令 docker system df 提供Docker整体磁盘使用率的概况,包括镜像、容器和(本地)volume。所以我们现在随时都可以查看Docker使用了多少资源。

如果之前的命令展示出 docker 已经占用了太多空间,我们会开始清理。有一个包办一切的命令:docker system prune

这个命令会删除当前没有被使用的一切项目,它按照一种正确的序列进行清理,所以会达到最大化的输出结果。首先删除没有被使用的容器,然后是volume和网络,最后是挂起的镜像。通过使用 y 回复来确认操作。如果想在脚本中使用这个命令,可以使用参数 --force 或者 -f 告诉Docker不要发来确认请求。


Docker容器

我们已经知道许多 docker container 的子命令。它们过去(现在也是)是 docker 的直接子命令。可以通过下面的命令得到完整的子命令列表:docker container --help

在列表中会看到一个 prune 命令。如果使用它,那么只会删除无用的容器。因此这条命令比 docker system prune 命令更局限。使用 --force 或者 -f 同意可以让CLI不再进行确认请求。


Docker网络

这里也有一个 prune 命令:docker network prune
删除所有孤立的网络。


Docker Volume

volume也有新的 prune 命令了:docker volume prune
删除所有(本地)没有被容器使用的volume。


Docker镜像

新的镜像命令也是 prune 子命令。--force 用法如上面一样, --all 可以删除所有不用的镜像,不只挂起的镜像。docker image prune --force --all

这个命令可以删除所有不使用的镜像并且不再请求确认。


总结

Docker 1.13不仅通过引入admin command添加了一些需要的命令,也让我们找到了一些非常有用的清理环境的命令。笔者最爱的命令莫过于 docker system prune,让环境一直保持干净整齐。


本文作者:Gabriel Schenker
原文链接:https://lostechies.com/gabriel ... ited/ 查看全部

Docker1.13出来已经有一段时间了,新版本添加了许多有用的命令,本文作者从处女座的洁癖(此处有雾)出发,告诉大家一些整理环境的小技巧。打扫房间再也不需费时又费力了,简单的命令,就可以轻松地把物品分门别类(容器、镜像、网络、存储卷……)地整理好^_^



在1.13版本中,Docker向CLI添加了一些有用的命令,让环境更加整洁。你可能已经体验了很长时间乱糟糟的开发环境——无用的容器,挂起的Docker镜像,弃置的volume,被遗忘的网络……所有这些过时的事物占据了宝贵的资源,最终导致环境无法使用。在之前的文章中曾经提到用各种各样的命令保持环境的整洁,例如:
docker rm -f $(docker ps -aq)


强制地删除所有正在运行的、暂停的以及终止的容器。同样地,也有命令可以删除挂起的镜像、网络和volume。

尽管上述命令解决了问题,但是它们要么专有,要么冗长或者难用。而新加入的命令直截了当又简单好用,现在就开始一一介绍吧。



管理命令

为了整理CLI,Docker 1.13引进了新的管理命令,如下:
  • system
  • container
  • image
  • plugin
  • secret


Docker的老版本中已经有了 network, node, service, swarm 和 volume 。这些新命令组子命令过去作为root命令直接实现。举个例子:
docker exec -it [container-name] [some-command]

exec 命令现在是 container 下面的一个子命令,这个命令相当于:
docker container exec -it [container-name] [some-command]


个人猜测为了兼容性的考虑,旧语句眼下还会使用一段时间。


Docker系统

现在有一个新管理命令 system 。它有4个子命令分别是 df, events, info 和 prune 。命令 docker system df 提供Docker整体磁盘使用率的概况,包括镜像、容器和(本地)volume。所以我们现在随时都可以查看Docker使用了多少资源。

如果之前的命令展示出 docker 已经占用了太多空间,我们会开始清理。有一个包办一切的命令:
docker system prune


这个命令会删除当前没有被使用的一切项目,它按照一种正确的序列进行清理,所以会达到最大化的输出结果。首先删除没有被使用的容器,然后是volume和网络,最后是挂起的镜像。通过使用 y 回复来确认操作。如果想在脚本中使用这个命令,可以使用参数 --force 或者 -f 告诉Docker不要发来确认请求。


Docker容器

我们已经知道许多 docker container 的子命令。它们过去(现在也是)是 docker 的直接子命令。可以通过下面的命令得到完整的子命令列表:
docker container --help


在列表中会看到一个 prune 命令。如果使用它,那么只会删除无用的容器。因此这条命令比 docker system prune 命令更局限。使用 --force 或者 -f 同意可以让CLI不再进行确认请求。


Docker网络

这里也有一个 prune 命令:
docker network prune

删除所有孤立的网络。


Docker Volume

volume也有新的 prune 命令了:
docker volume prune

删除所有(本地)没有被容器使用的volume。


Docker镜像

新的镜像命令也是 prune 子命令。--force 用法如上面一样, --all 可以删除所有不用的镜像,不只挂起的镜像。
docker image prune --force --all


这个命令可以删除所有不使用的镜像并且不再请求确认。


总结

Docker 1.13不仅通过引入admin command添加了一些需要的命令,也让我们找到了一些非常有用的清理环境的命令。笔者最爱的命令莫过于 docker system prune,让环境一直保持干净整齐。


本文作者:Gabriel Schenker
原文链接:https://lostechies.com/gabriel ... ited/

版本更新 | Mesos调度器Swan v0.2来啦

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

数人云Mesos调度器Swan开源已经一个月啦,在社区和大家的共同呵护下成长了许多。正值双十二又一波剁手节来临之际,小数带来了Swan v0.2的新版本,添加了很多新功能,大家快来看看吧——



Feature List
Uri  支持:支持自定义资源,支持多资源下载PortIndex:支持端口命名,健康检测支持portIndex,portName和portValueCli:命令行工具Heathcheck:支持mesos自带的healthcheck,http和tcp两种Raft:高可用,分布式数据复制和leader选举Proxy:自带proxy功能,支持负载均衡DNS:自带DNS功能,支持域名解析一容器一IP:支持IP地址固定分配,一容器一IPConstraints:支持约束条件,UNIQUE和LIKE



Fork me on GitHub!
https://github.com/Dataman-Cloud/swan


关于数人云Mesos调度器Swan

Swan是基于Mesos Restful API编写的应用调度框架,可以帮助用户轻松发布应用,实现应用的滚动更新,并根据用户指定的策略做应用的健康检测和故障转移。 查看全部

数人云Mesos调度器Swan开源已经一个月啦,在社区和大家的共同呵护下成长了许多。正值双十二又一波剁手节来临之际,小数带来了Swan v0.2的新版本,添加了很多新功能,大家快来看看吧——





Feature List
  • Uri  支持:支持自定义资源,支持多资源下载
  • PortIndex:支持端口命名,健康检测支持portIndex,portName和portValue
  • Cli:命令行工具
  • Heathcheck:支持mesos自带的healthcheck,http和tcp两种
  • Raft:高可用,分布式数据复制和leader选举
  • Proxy:自带proxy功能,支持负载均衡
  • DNS:自带DNS功能,支持域名解析
  • 一容器一IP:支持IP地址固定分配,一容器一IP
  • Constraints:支持约束条件,UNIQUE和LIKE




Fork me on GitHub!
https://github.com/Dataman-Cloud/swan


关于数人云Mesos调度器Swan

Swan是基于Mesos Restful API编写的应用调度框架,可以帮助用户轻松发布应用,实现应用的滚动更新,并根据用户指定的策略做应用的健康检测和故障转移。

避无可避:Mesos安全问题的几点思考

宁静胡同 发表了文章 • 0 个评论 • 374 次浏览 • 2016-12-13 16:48 • 来自相关话题

小数今天为大家抱来的内容,是有关Mesos的一个安全问题。这个问题可以说是目前行业内容器管理工具的一个通病,Mesos的团队已经在尝试解决它,那么在正式的解决方案出来前,我们也可以有办法来避免它——看看本文作者是如何思考的。

笔者研究Mesos已经很长时间了,在大多数情况下,享受着围绕Mesos整个生态系统的成长过程。为了应用(或者微服务)交付而在一个大平台上统一管理服务器是一件非常酷的事情。虽然有一些学习曲线,但是Mesos是一个非常好的应用配置工具,同时还可以把它看做统一架构进行规模扩展以及应用管理。

但是每一个技术都存在自己的缺陷和问题,我们必须诚实和开放地对待,才能让它更好地应用于企业生产。Mesos也不例外。

身份验证,开or关?

大多数开源项目都是这样开始的:“如果我们做到了X,Y和Z,那么我们就可以做到这件很酷的事情了!”然后只考虑目标用户的安全需求,这是它们的通病。Mesos团队已经踏上了从无(或者可选)到有的企业级安全之路,但是现阶段,现在仍有一些可以值得考虑的事情,让Mesos安装更加安全。

Mesos之父Ben Hindman是这样说的,“对于没有身份验证的用户来说,我们不希望在升级的时候打破他们的集群。身份验证将在默认有足够时间的情况下让应用框架升级。当一些应用框架可以身份验证同时另外其他应用框架并不支持这种升级路径时,我们开启了一种混合模式来应对。”

现在Mesos的安装默认是没有应用框架的身份验证的,也没有限制可以看到哪些应用框架。如果你使用命令行开关,可以修改这个默认行为,但是涉及到的应用框架仍然是默认打开的。本篇文章的目的即在于督促大家尽可能地在环境中使用命令行开关。

而行业标准和Mesos的做法完全相反——提供一个关闭安全的选项——但是默认它是开启的。虽然这样会使最初的部署更加困难,但这恰恰是Mesos需要的(从Ben的评论中得出的推断,他们或许正打算这么做)。

Mesos的核心安全问题

接下来的这些产生了核心的问题:
默认情况下,Mesos允许没有身份验证。通常情况下,一些形式的身份验证是需要的。越来越多的OAuth访问控制被使用。 参见Stormpath或者DigitalOcean诸如此类的API认证方案。Mesos使用“角色(role)”来决定哪一个应用框架访问资源。默认情况下,应用框架可以注册为任何角色。持久化磁盘(例如数据库或者合同目录)可以由Mesos进行资源分配。访问被角色限定(历史版本中的最近点)控制,让它们可以用于多个应用框架上的多个应用。这也使得任意和可访问应用框架有相同角色的应用框架可以被访问。Mesos可以根据需要通过mesos fetcher给集群中的节点分配agent。所以agent的分配,将是这一弱点的限定因素,实际上相当简单——一个应用框架可以要求它的agent下载到集群中的任意一台服务器上。公共应用框架开发框架。
 所以Mesos的默认安装,任何机器都可以点击应用框架的REST API,我可以注册一个自己架构的应用框架。Mesos系统自动批准注册,所以没有人员参与决策;注册(也叫:调度器订阅)意味着没有授权也会批准,并且会回复注册信息。考虑添加应用框架的频率很低,这应该是一个有人员参与的决策处。注意,更早期的应用框架开发使用libmesos所以可能滥用这种默认,但是那样更加困难,因此不太可能被利用。新应用框架可以申请存在其他应用框架的角色,之后只需等待Mesos传递给我正确的资源,就可以访问这些静态资源。这些资源可能包含任何分配给这个角色的持久化存储磁盘,可以读写(因为目前Mesos只支持读写)。

再次强调,这是一个已知的问题,Mesos团队正在解决它。但是现在,用户需要根据自己的环境来决定是否需要自己实现。

解决之道

解决方法也很简单,有命令行选项开启应用框架身份验证,限制哪一种应用框架使用哪一种角色。但是需要把它们都打开——它们默认都是关闭的——观察Mesos集群的日志,没有显示应用框架注册是默认登录设置来登录的。注意角色管理是额外的开销,但是适用于应用框架还不是一个大的安全负担,除非频繁不断地从系统里添加/移除应用框架(非常不可能的情况)。系统目前如此设计的原因是一些应用框架并不支持身份验证,所以在生产环境之前将这项功能开启进行测试也是很有必要的。

这个问题的风险大吗?坦白地说,这取决于实现过程。如果Mesos问题集群把敏感信息放在持久化存储磁盘上,风险可能很高。如果问题集群没有这样做,仍然存在架构设计上的风险以及认证的缺失,但是可用数据——Mesos之外如何保护它——决定了它会受到何种攻击。修改运行应用的配置参数的能力是更深层的考虑;HTTP单独重定向也可能很麻烦。

总结

简而言之,这个过渡期的存在,让我们更加意识到Mesos安全的重要性,因为一个未能共同遵守规范的实践,让项目的其他地方受到类似安全设计决策的影响,目前它已经在修复身份验证这个问题。

因为是过程中的不同阶段,所以实现几乎总是和调研时发掘出不同的信息或者问题。有时间多做几个应用框架后,会把信息升级,用一个“正常者”和一个“攻击者”进行测试。安全上来说,在有足够充分的文件说明的情况下,优先彻底检验问题是最好的,但我选择在准备好可能很长的证据之前先通知社区。

本文的意义在于帮助大家使用Mesos的时候绕掉那些已知的坑,建议大家使用“命令行”开关,阅读打开身份认证的指导,然后再实现它。并且建议限制角色,至少打开验证应用框架的开关并在环境中测试它是否工作。然后再畅游Mesos的世界,享受它带来的种种便利。

Note:虽然开源技术都有这样那样的问题,但是作为出色的Mesos技术框架,那些在大规模生产集群下使用的知名企业众多,小数顺便再盘点下—— 
国外有:Airbnb,Apple,Cisco,eBay,PayPal,Time Warner Cable,Twitter,Uber, Netflix,Bloomberg,Verizon…… 国内有:小米,新浪微博,爱奇艺,去哪儿网……

本文作者: DON MACVITTIE 原文链接: https://devops.com/mesos-secur ... ions/ 查看全部

小数今天为大家抱来的内容,是有关Mesos的一个安全问题。这个问题可以说是目前行业内容器管理工具的一个通病,Mesos的团队已经在尝试解决它,那么在正式的解决方案出来前,我们也可以有办法来避免它——看看本文作者是如何思考的。



笔者研究Mesos已经很长时间了,在大多数情况下,享受着围绕Mesos整个生态系统的成长过程。为了应用(或者微服务)交付而在一个大平台上统一管理服务器是一件非常酷的事情。虽然有一些学习曲线,但是Mesos是一个非常好的应用配置工具,同时还可以把它看做统一架构进行规模扩展以及应用管理。

但是每一个技术都存在自己的缺陷和问题,我们必须诚实和开放地对待,才能让它更好地应用于企业生产。Mesos也不例外。

身份验证,开or关?

大多数开源项目都是这样开始的:“如果我们做到了X,Y和Z,那么我们就可以做到这件很酷的事情了!”然后只考虑目标用户的安全需求,这是它们的通病。Mesos团队已经踏上了从无(或者可选)到有的企业级安全之路,但是现阶段,现在仍有一些可以值得考虑的事情,让Mesos安装更加安全。

Mesos之父Ben Hindman是这样说的,“对于没有身份验证的用户来说,我们不希望在升级的时候打破他们的集群。身份验证将在默认有足够时间的情况下让应用框架升级。当一些应用框架可以身份验证同时另外其他应用框架并不支持这种升级路径时,我们开启了一种混合模式来应对。”

现在Mesos的安装默认是没有应用框架的身份验证的,也没有限制可以看到哪些应用框架。如果你使用命令行开关,可以修改这个默认行为,但是涉及到的应用框架仍然是默认打开的。本篇文章的目的即在于督促大家尽可能地在环境中使用命令行开关。

而行业标准和Mesos的做法完全相反——提供一个关闭安全的选项——但是默认它是开启的。虽然这样会使最初的部署更加困难,但这恰恰是Mesos需要的(从Ben的评论中得出的推断,他们或许正打算这么做)。

Mesos的核心安全问题

接下来的这些产生了核心的问题:
  1. 默认情况下,Mesos允许没有身份验证。通常情况下,一些形式的身份验证是需要的。越来越多的OAuth访问控制被使用。 参见Stormpath或者DigitalOcean诸如此类的API认证方案。
  2. Mesos使用“角色(role)”来决定哪一个应用框架访问资源。默认情况下,应用框架可以注册为任何角色。
  3. 持久化磁盘(例如数据库或者合同目录)可以由Mesos进行资源分配。访问被角色限定(历史版本中的最近点)控制,让它们可以用于多个应用框架上的多个应用。这也使得任意和可访问应用框架有相同角色的应用框架可以被访问。
  4. Mesos可以根据需要通过mesos fetcher给集群中的节点分配agent。所以agent的分配,将是这一弱点的限定因素,实际上相当简单——一个应用框架可以要求它的agent下载到集群中的任意一台服务器上。
  5. 公共应用框架开发框架。

 所以Mesos的默认安装,任何机器都可以点击应用框架的REST API,我可以注册一个自己架构的应用框架。Mesos系统自动批准注册,所以没有人员参与决策;注册(也叫:调度器订阅)意味着没有授权也会批准,并且会回复注册信息。考虑添加应用框架的频率很低,这应该是一个有人员参与的决策处。注意,更早期的应用框架开发使用libmesos所以可能滥用这种默认,但是那样更加困难,因此不太可能被利用。新应用框架可以申请存在其他应用框架的角色,之后只需等待Mesos传递给我正确的资源,就可以访问这些静态资源。这些资源可能包含任何分配给这个角色的持久化存储磁盘,可以读写(因为目前Mesos只支持读写)。

再次强调,这是一个已知的问题,Mesos团队正在解决它。但是现在,用户需要根据自己的环境来决定是否需要自己实现。

解决之道

解决方法也很简单,有命令行选项开启应用框架身份验证,限制哪一种应用框架使用哪一种角色。但是需要把它们都打开——它们默认都是关闭的——观察Mesos集群的日志,没有显示应用框架注册是默认登录设置来登录的。注意角色管理是额外的开销,但是适用于应用框架还不是一个大的安全负担,除非频繁不断地从系统里添加/移除应用框架(非常不可能的情况)。系统目前如此设计的原因是一些应用框架并不支持身份验证,所以在生产环境之前将这项功能开启进行测试也是很有必要的。

这个问题的风险大吗?坦白地说,这取决于实现过程。如果Mesos问题集群把敏感信息放在持久化存储磁盘上,风险可能很高。如果问题集群没有这样做,仍然存在架构设计上的风险以及认证的缺失,但是可用数据——Mesos之外如何保护它——决定了它会受到何种攻击。修改运行应用的配置参数的能力是更深层的考虑;HTTP单独重定向也可能很麻烦。

总结

简而言之,这个过渡期的存在,让我们更加意识到Mesos安全的重要性,因为一个未能共同遵守规范的实践,让项目的其他地方受到类似安全设计决策的影响,目前它已经在修复身份验证这个问题。

因为是过程中的不同阶段,所以实现几乎总是和调研时发掘出不同的信息或者问题。有时间多做几个应用框架后,会把信息升级,用一个“正常者”和一个“攻击者”进行测试。安全上来说,在有足够充分的文件说明的情况下,优先彻底检验问题是最好的,但我选择在准备好可能很长的证据之前先通知社区。

本文的意义在于帮助大家使用Mesos的时候绕掉那些已知的坑,建议大家使用“命令行”开关,阅读打开身份认证的指导,然后再实现它。并且建议限制角色,至少打开验证应用框架的开关并在环境中测试它是否工作。然后再畅游Mesos的世界,享受它带来的种种便利。

Note:虽然开源技术都有这样那样的问题,但是作为出色的Mesos技术框架,那些在大规模生产集群下使用的知名企业众多,小数顺便再盘点下—— 
国外有:Airbnb,Apple,Cisco,eBay,PayPal,Time Warner Cable,Twitter,Uber, Netflix,Bloomberg,Verizon…… 国内有:小米,新浪微博,爱奇艺,去哪儿网……

本文作者: DON MACVITTIE 原文链接: https://devops.com/mesos-secur ... ions/

DevOps:谁说我只是自动化工具?

宁静胡同 发表了文章 • 0 个评论 • 334 次浏览 • 2016-12-13 16:31 • 来自相关话题

关于DevOps,每个人都有不同的认识。有人坚持它是一种方法论,然而在实践中为了脱离缓慢的手工作业,自动化工具必不可少。从职责传递到自助服务,DevOps为满足业务的快速交付而生,却存在学习上的瓶颈。
然后谢天谢地,容器来了……

参加了大大小小许多DevOps和软件工程的会议。每当”DevOps究竟意味着什么”这个话题被提起时,总是会有一个这样的论点出现:

DevOps不是一系列可以连贯起来的工具,你用了它们就可以说自己做的是DevOps。DevOps是一种方法论,让开发和运维团队能够更紧密工作的一套过程。最终的目标是消除在软件发布的过程中手动作业和耗费时间的部分,实现更多成功的部署和更频繁的发布。

它完全正确。然而,话虽如此,祝不使用自动化工具的DevOps或者持续交付……好运。

为什么自动化工具是先决条件

假设这样一个场景:你处在一个研发工作室,创业公司甚至是大型企业。你有很多开发人员,他们中的少数一些被称为“Ops小组”“DevOps魔法师”或者“云运维”,在企业中他们可能被称为“基础设施运营专家”(如果你们有更有趣的名字也可以在下方留言)。但不管怎样,他们的人使用开发团队所写的代码,并确保它们能够在生产级别的环境上可靠运行。
开发写代码并添加新特性从开发到运维,一个传递发生了现在它是运维的麻烦了……运维挥动服务器魔法,把问题解决了!

听着很耳熟?主要的问题是什么呢?运维和开发的分离这件事在整个发布过程中发生得过早了。它随着传递发生,从此变成了一个问题。在技术团队中有服务器魔法师当然很棒,因为开发人员不用再担心如何处理服务器问题,但是它确实是一个把你从DevOps的喜悦中拉下来的瓶颈。

自助服务:开发人员需要它,运维也是

DevOps的目的是团队紧密工作,缩短反馈回路。

做一些改变,让它们在测试环境中提交、合并、站住脚来确保一切都如预期那样。看起来不错?然后让新功能平滑地上生产,交到用户的手里。出现了问题?回滚一下,迅速地修复它,然后在不停机的情况下发布更新。

然而写代码的开发人员和理解及维护云平台的运维人员减慢了反馈回路,经常慢如爬行动物。

写代码的开发人员最适合做发布(在他们的计划中方便的时候),测试,监控性能,以及解决任何突然出现的问题。可是为什么没有工作流程是默认如此的呢?

很多情况下,服务器魔法师或者运维团队是唯一理解云平台所有事物的人。没有为开发者或者试图了解幕后情况的人提供的自助服务。

听起来运维团队处在一个非常强大的位置,但实际上它是非常痛苦和充满压力的。在给用户提供软件后你多少会明白,发布和维护是你职责所在,如果出错了要在第一线调试它,通常一忙就是一天24小时。

那为什么这是一个如此常见的场景呢?(提示,通常和工具有关)。

你选择的工具可能重要,也可能无关紧要

在一天结束的时候,运维人员、开发人员、安全保障人员、项目经理等等都对新软件发布的过程很满意,它实现了快速交付满足了业务需求。你可以通过很多方式到达这个目标。如果你是通过类似自助的方式,那么恭喜。

讲个故事。

在之前的一份工作里,我们采用了一种配置管理工具,插在Jenkins上,集成了很多开源系统,很高兴地自动化了一个大型、多区、遵从PCI并且流畅跑在AWS上的服务器。我们让非技术人员添加和部署新项目成为可能,可以为每个变化进行完整测试。一切看起来都很好,除了一个大问题:我们构建了类似自助服务的东西,但是它对公司95%的人来说是一个黑盒。开发把他们的代码给我们,他们可以检查日志,查看图表,看各项性能,但是当碰到钉子的时候,就是我们的职责了。
 
所以怎样才能让更多的人能够明白我们搭建的主机系统如何工作?我们用来连接一切的工具和用户配置让学习的复杂度大大提高。

然后……容器来了。

为什么容器可以帮上忙

你知道我一定会提容器的,对不对?在过去几年的DevOps大会上,容器和其应用基本是一个必谈的话题。

容器改变了开发和运维之间的分离境地,改进了他们之间的传递进程。开发人员能够更接近项目来确保他们的更新在传递给本地镜像创建人员之前可以成功部署。标准变得更加成熟和有意义,让更多人专注于应用程序而不是服务器。

容器已经催生了很多颇有竞争力的解决方案,提供一个平台来代替自助服务。因此运维团队和开发团队可以把关注点放在生产更多高效的进程和结果。所以在实践中它是什么样的?

当容器和DevOps碰撞

每一个软件公司如果着手开发一个改变游戏规则的产品,在前进的道路上,不管是从基础架构、还是人员管理和软件发布的角度,都会不可避免遇到可伸缩性的问题。随着团队的成长,和服务器的扩展,公司不仅需要关注产品线路图的执行,还需要变成云计算自动化领域的专家。能够最快速地执行新想法就会有显著的优势。如果你仍然手动登录服务器或者尝试再造一个云平台的车轮,那么就是在伤害你的公司。

而最近的一些容器技术或者容器服务平台可以帮助你从别人的硬件中解放出来,让公司更加专注于产品——
 
开发者能够通过友好的用户界面管理自己的服务器硬件需求开发者可以减少一个数量级的反馈回路时间,这意味着更多的代码更快的发布运维不用再尝试将一堆工具拢在一起做一个内部的PaaS,它很难做,很难管理,很难修补,很难保证安全运维可以更进一步地专注在应用监控、性能表现上,给予开发一些有价值的反馈来快速提升产品业务可以更灵活地延伸到全球范围,根据业务需求进行扩展,更新用户平台不需要时间和成本上的花费更多的资金可以用来雇佣人才专注于产品研发

所以,拥有了容器技术的DevOps,是否有了新的定义?

当然小数要补充一句,容器不是万能的,用在适合的地方最好。


文章作者:Phil Dougherty
原文链接:https://blog.containership.io/ ... isite 查看全部

关于DevOps,每个人都有不同的认识。有人坚持它是一种方法论,然而在实践中为了脱离缓慢的手工作业,自动化工具必不可少。从职责传递到自助服务,DevOps为满足业务的快速交付而生,却存在学习上的瓶颈。
然后谢天谢地,容器来了……



参加了大大小小许多DevOps和软件工程的会议。每当”DevOps究竟意味着什么”这个话题被提起时,总是会有一个这样的论点出现:

DevOps不是一系列可以连贯起来的工具,你用了它们就可以说自己做的是DevOps。DevOps是一种方法论,让开发和运维团队能够更紧密工作的一套过程。最终的目标是消除在软件发布的过程中手动作业和耗费时间的部分,实现更多成功的部署和更频繁的发布。

它完全正确。然而,话虽如此,祝不使用自动化工具的DevOps或者持续交付……好运。

为什么自动化工具是先决条件

假设这样一个场景:你处在一个研发工作室,创业公司甚至是大型企业。你有很多开发人员,他们中的少数一些被称为“Ops小组”“DevOps魔法师”或者“云运维”,在企业中他们可能被称为“基础设施运营专家”(如果你们有更有趣的名字也可以在下方留言)。但不管怎样,他们的人使用开发团队所写的代码,并确保它们能够在生产级别的环境上可靠运行。
  • 开发写代码并添加新特性
  • 从开发到运维,一个传递发生了
  • 现在它是运维的麻烦了……
  • 运维挥动服务器魔法,把问题解决了!


听着很耳熟?主要的问题是什么呢?运维和开发的分离这件事在整个发布过程中发生得过早了。它随着传递发生,从此变成了一个问题。在技术团队中有服务器魔法师当然很棒,因为开发人员不用再担心如何处理服务器问题,但是它确实是一个把你从DevOps的喜悦中拉下来的瓶颈。

自助服务:开发人员需要它,运维也是

DevOps的目的是团队紧密工作,缩短反馈回路。

做一些改变,让它们在测试环境中提交、合并、站住脚来确保一切都如预期那样。看起来不错?然后让新功能平滑地上生产,交到用户的手里。出现了问题?回滚一下,迅速地修复它,然后在不停机的情况下发布更新。

然而写代码的开发人员和理解及维护云平台的运维人员减慢了反馈回路,经常慢如爬行动物。

写代码的开发人员最适合做发布(在他们的计划中方便的时候),测试,监控性能,以及解决任何突然出现的问题。可是为什么没有工作流程是默认如此的呢?

很多情况下,服务器魔法师或者运维团队是唯一理解云平台所有事物的人。没有为开发者或者试图了解幕后情况的人提供的自助服务。

听起来运维团队处在一个非常强大的位置,但实际上它是非常痛苦和充满压力的。在给用户提供软件后你多少会明白,发布和维护是你职责所在,如果出错了要在第一线调试它,通常一忙就是一天24小时。

那为什么这是一个如此常见的场景呢?(提示,通常和工具有关)。

你选择的工具可能重要,也可能无关紧要

在一天结束的时候,运维人员、开发人员、安全保障人员、项目经理等等都对新软件发布的过程很满意,它实现了快速交付满足了业务需求。你可以通过很多方式到达这个目标。如果你是通过类似自助的方式,那么恭喜。

讲个故事。

在之前的一份工作里,我们采用了一种配置管理工具,插在Jenkins上,集成了很多开源系统,很高兴地自动化了一个大型、多区、遵从PCI并且流畅跑在AWS上的服务器。我们让非技术人员添加和部署新项目成为可能,可以为每个变化进行完整测试。一切看起来都很好,除了一个大问题:我们构建了类似自助服务的东西,但是它对公司95%的人来说是一个黑盒。开发把他们的代码给我们,他们可以检查日志,查看图表,看各项性能,但是当碰到钉子的时候,就是我们的职责了。
 
所以怎样才能让更多的人能够明白我们搭建的主机系统如何工作?我们用来连接一切的工具和用户配置让学习的复杂度大大提高。

然后……容器来了。

为什么容器可以帮上忙

你知道我一定会提容器的,对不对?在过去几年的DevOps大会上,容器和其应用基本是一个必谈的话题。

容器改变了开发和运维之间的分离境地,改进了他们之间的传递进程。开发人员能够更接近项目来确保他们的更新在传递给本地镜像创建人员之前可以成功部署。标准变得更加成熟和有意义,让更多人专注于应用程序而不是服务器。

容器已经催生了很多颇有竞争力的解决方案,提供一个平台来代替自助服务。因此运维团队和开发团队可以把关注点放在生产更多高效的进程和结果。所以在实践中它是什么样的?

当容器和DevOps碰撞

每一个软件公司如果着手开发一个改变游戏规则的产品,在前进的道路上,不管是从基础架构、还是人员管理和软件发布的角度,都会不可避免遇到可伸缩性的问题。随着团队的成长,和服务器的扩展,公司不仅需要关注产品线路图的执行,还需要变成云计算自动化领域的专家。能够最快速地执行新想法就会有显著的优势。如果你仍然手动登录服务器或者尝试再造一个云平台的车轮,那么就是在伤害你的公司。

而最近的一些容器技术或者容器服务平台可以帮助你从别人的硬件中解放出来,让公司更加专注于产品——
 
  • 开发者能够通过友好的用户界面管理自己的服务器硬件需求
  • 开发者可以减少一个数量级的反馈回路时间,这意味着更多的代码更快的发布
  • 运维不用再尝试将一堆工具拢在一起做一个内部的PaaS,它很难做,很难管理,很难修补,很难保证安全
  • 运维可以更进一步地专注在应用监控、性能表现上,给予开发一些有价值的反馈来快速提升产品
  • 业务可以更灵活地延伸到全球范围,根据业务需求进行扩展,更新用户平台不需要时间和成本上的花费
  • 更多的资金可以用来雇佣人才专注于产品研发


所以,拥有了容器技术的DevOps,是否有了新的定义?

当然小数要补充一句,容器不是万能的,用在适合的地方最好。


文章作者:Phil Dougherty
原文链接:https://blog.containership.io/ ... isite