BT

你的观点很重要! 快来参与InfoQ调研吧!

持续交付:当前普遍存在的三个问题与解决方案

| 作者 阮志敏 关注 0 他的粉丝 发布于 2015年3月25日. 估计阅读时间: 11 分钟 | ArchSummit社交架构图谱:Facebook、Snapchat、Tumblr等背后的核心技术

A note to our readers: As per your request we have developed a set of features that allow you to reduce the noise, while not losing sight of anything that is important. Get email and web notifications by choosing the topics you are interested in.

早在2009年,Flickr就分享了他们如何通过工具的支撑和文化的改变,使之能够支撑业务部门“每天部署10次”的要求。这些工具包括:

1) Automated infra

2) Shared version control

3) One step build and deploy

4) Feature flags

5) Shared metrics

6) IRC and IM Robots

5年时间过去了,随着云计算和开源软件的发展,我们拥有了比Flickr更好的基础条件:IaaS给我们提供了可编程的接口,我们不再受到物理资源的约束;GitHub带给我们新型版本控制和代码协作方式; Chef/Puppet等配置和自动化部署工具更加成熟;基于ELK的实时监控和日志系统也很成熟。但是,即便如此,有多少企业达到了Flickr的持续部署和交付水平呢?

这里,我们把持续交付分解成三条主线:

  1. 从Code到Artifacts仓库;
  2. 从Artifacts到Running Service;
  3. 从开发、测试环境到准生产、生产环境。

对于这三条主线,笔者发现大部分IT组织都存在三个类似的问题。

1. 从Code到Artifact仓库:没有统一的Artifacts仓库

在很多企业IT组织中,由于历史及其他各种各样的原因,不同的项目,会采用不同的开发语言、框架,版本控制服务和持续集成工具。这是不可避免的。真正的问题是出在Artifact的管理上。有些人根本就没有Artifact的概念,认为代码就是Artifact,部署应用时都是直接从svn等版本控制器上面直接获取代码进行部署。有些IT组织即便有Artifact仓库,也没有统一的规范,非常混乱。

如何改进呢?

建立统一的Artifacts仓库。这是后续自动化部署和多版本开发的基础。

Artifacts仓库的实现方式有三种,FTP、对象存储(比如阿里云OSS,AWS S3等)和专业的Artifacts存储仓库。对象存储、 FTP都重在存储,只能实现最基础的分目录和权限管理。如果你的环境都在公有云上面,那么用公有云的对象存储服务来管理Artifacts是很合适的,原因有以下几个:

  • 不用担心可用性和可靠性;
  • 上传和下载速度快;
  • 不同的项目可以用不同的Buckets来进行权限管理。如果是AWS S3,还可以使用IAM来进行更细粒度的权限控制。

专业的Artifacts存储仓库方面,目前有三个使用比较广的选择:ArtifactoryNexusArchiva,其中Artifactory和Nexus也有商业版本。这三个工具虽然都源自Maven,但是他们不仅仅支持Java/Maven,任何项目和语言都可以使用Maven机制来打包Artifact,区分Artifact版本,并最终存储到Repository中去。下图是Nexus的一个截图,可以清楚地看出Artifacts仓库所要解决的几个问题:不同项目、不同组件Artifacts的分类存储;Artifacts格式的统一;用户和权限控制;开发版本和发布版本区分、如何与CI服务器集成等。

2. 从Artifacts到Running service:不同环境的部署方法不一样

这条主线解决的是,如何将Build Artifacts部署到开发环境、测试环境、准生产环境和生产环境。

对于这条主线,当前普遍存在的问题是:不同环境的资源创建、服务器配置和代码部署方法是不一样的。很多时候大家只关注生产环境的部署管理,对于开发及测试的部署管理又不重视。比如,开发和测试环境是手工部署的,而生产环境是用工具进行自动部署的,因为部署方式不一致,所以在生产环境会经常出现不可预知的错误。另外,随着版本分支的增加,开发、测试和准生产环境会混乱不堪。

如何改进呢?

貌似PaaS的存在就是为了解决这个问题,开发人员只要专注于应用的开发,部署和Ops工作都是有PaaS本身完成。然而,现实是目前的PaaS仍然没有进入主流,这是因为PaaS给予太多的限制、很好解决的80%问题,但是剩下20%很难解决。

在云计算(IaaS)支撑下,在云管理和部署工具的支持下(比如Rightscale, Cloudify,AWS Cloudformation, AWS CodeDeploy, FIT2CLOUD),用户可以实现从Artifacts到Running service整个过程的自动化,包括环境创建自动化、虚机安装配置自动化和代码部署自动化。

1) 环境创建:创建VMs、网络、存储、负载均衡,协调不同角色VMs的创建过程和配置。

2) 软件安装和配置:操作系统配置,比如创建用户、组,设置ulimit参数等;基础软件安装和配置,比如Mysql/Nginx。这些软件的特点是变动不频繁。

3) 应用部署(Code Deploy):部署应用代码,比如war包、db脚本、php/rails代码等。这部分的变动是频繁的。开发人员不仅仅是提供代码,而且要提供部署代码所需的脚本,比如AWS CodeDeploy规定Artifact中必须包括的部署这份代码所需要的脚本。CodeDeploy虽然没有编排功能及完备的插件和脚本库(比如HP OO),但是实现了应用代码和部署脚本的统一融合,可以避免多版本同时开发、部署所导致的混乱。采用CodeDeploy,每个应用组件可以单独、持续的继续升级部署,不需要整体部署。

3. 从开发、测试环境到准生产、生产环境:开发、QA和运营仍然采用传统的协作方式

这条主线涉及IT组织内部的合作和协调。传统的协作方式及流程的设计是依据当时“非频繁”交付设计的,不适应于当前对频繁交付的要求。IT组织仍然固守传统的运作和分工机制,做一件事需要开很多会,是一种类似瀑布流的组织方式,需要花很多时间。当下很多IT组织采用了敏捷开发、每天都可以产生很多构建(Build),但是生产环境的部署节奏仍然很慢,这是普遍存在的问题。

如何改进呢?

实现DTAP的融合需要三个方面的支持:观念的转变,组织结构和文化的更新及技术和工具的支撑。

首先是观念上面的改变,并建立与新观念相匹配的共享服务Metric和SLA信息。在竞争激烈的新时代,原来那种Dev和Ops隔离的方式已经满足不了云时代的快速迭代交互的需求。

传统观念

新观念

开发人员的工作是:增加新功能

运维人员的工作是:保持服务稳定、快速

开发人、运营、测试、项目管理人员的共同工作是:enable the business

其次是工具和流程上面的改进。基于上面第一条、第二条主线达成的基础,构建自动化的文化,并建立清晰、一致的DTAP流程。这样Dev、Ops、QA因为是在一个流程和同样工具下工作的,相互所有的细节都透明了,也就自然融合了。同时,DTAP环境都是用相同的方式进行自动化部署的,在进行生产环境部署前,这个部署方法已经在开发、测试、准生产环境上面被反复验证过。总而言之,用统一的流程和工具管理不同的环境,又能支持不同环境的不同策略,这是实现DTAP环境融合在技术和工具上的关键所在。

最后,不同角色人员之间相互融合。比如,开发人员应该更加深入地参与测试及生产环境的运营,比如参与测试环境的部署、生产环境各个层面监控指标的设计和开发。“You build it, you run it”,这是Amazon一年可以完成5000万次部署,平均每个工程师每天部署超过50次的核心秘籍。

结束语

持续部署、持续交付能力的改进,是一个从自身情况出发的,持续的、不断改进的过程。在文章结束之前,我还想分享下我的两个体会。

  1. 不能把希望完全寄托在新兴的技术,比如Docker,来提升持续交付能力。很多人盼着Docker来解决现在存在的问题。但这些问题都不需要Docker就可解决,Netflix/ Flickr等就是例子,关键得有持续改进的意愿和行动。松耦合的SOA/微服务架构; “you build it, you run it”的DevOps文化; 与架构和文化相适应的自动化工具和Infra。这三点都不是一朝一夕或者一个新技术可以解决的。
  2. IaaS会是新常态,将成为互联网和企业的基础设施。云IT和传统IT有很大的不同。 使用IaaS只是第一步,企业应该利用上云这个契机,在应用架构、部署管理工具、开发运维协作方式也进行转变,解决这三个普遍存在的问题,打通从代码到服务的通道,提升持续交付能力。

作者简介

阮志敏是AWS认证解决方案架构师(专业级别),FIT2CLOUD联合创始人。FIT2CLOUD致力于帮助企业更好地使用云来加速业务创新,实现从传统IT到Cloud IT的转型。FIT2CLOUD不仅提供一站式的应用交付及运维管理工具,同时还提供方法论来帮助企业打通从代码到服务的通道,实现云应用的持续交付和自动化运维。


感谢丁晓昀对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。

立即免费注册AWS账号,获得12个月免费套餐:点击注册

有云计算问题?立刻联系AWS云计算专家:立即联系

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT