跳到正文 →

亚马逊DevOps的实践指南

嘉宾介绍

代闻  :亚马逊AWS解决方案架构师,负责基于AWS的云计算方案架构的咨询和设计,同时致力于:WS云服务在国内的应用和推广,在大规模后台架构、物联网应用、媒体行业转型、企业混合IT和自动化运维等方面有着广泛的设计和实践经验。在加入AWS之前,在思科中国担任系统工程师,负责方案咨询和架构设计,在企业私有云和基础网络方面有丰富经验。曾任IBM中国软件开发中心软件工程师,从事企业软件和移动平台的开发工作。

在很多企业中,应用程序发布是一项涉及多个团队、压力很大、风险很高的活动。然而在具备DevOps能力的组织中,应用程序发布的风险却很低。目前开发人员对于DevOps的认识深浅不一,本期请到了亚马逊架构师代闻来为我们实例解析DevOps。

01/DevOps简介和适用场景
DevOps是一个软件开发的方法,目的是为了提高内部运维能力,也就是说,DevOps是运维的一个方式,只不过通过软件实现了更高的自动化。DevOps一词,Dev是形容词,Ops是主体,DevOps的兴起,并不是技术人员自娱自乐,而是业务需求推动的结果。传统的瀑布式开发,周期长,风险大;现在的初创公司推崇的是敏捷开发、快速迭代但是敏捷开发仅解决了软件开发的问题,如果集成、部署、平台搭建没有做相应的调整,Ops将会是整个流程的短板。当然,这里面涉及到另一个话题,就是微服务。当软件开发的各个团队负责各自服务,彼此通过约定接口调用实现松耦合,软件集成和部署就可以细化到各个服务,然后通过工具和平台实现持续的集成、部署、平台构建,平台的敏捷程度就会大大提升。其中,通过代码、脚本来加速集成、部署和平台构建的过程,可以成为DevOps。DevOps需要关注的方面很多,主要有两个重点:第一,文化和组织

关于DevOps文化和组织,听起来比较虚,但却是DevOps应用的核心。

传统公司里,开发和运维之间有既成组织架构的界限,向DevOps转型需要付出很多努力

初创公司负担少,更容易接受DevOps。

DevOps要求开发和运维之间互相协作,以业务为共同目标,实现快速迭代,平台的feature从设计、开发到交付的整个流程,都有担任ops角色的同事(也可能兼开发)参与,确保程序在设计初始就已经考虑到基础架构的优化,以及后续的内部OP事宜。

同时,担任DevOps角色的同事的技能要比以往更多一些,除了基本的服务器、网络、存储知识,还需要有代码或脚本能力。

综合下来,可以看到三种模式:

1)开发兼运维:这是在初创公司最常见的模式,5人以下的团队很多是这样的;

2)每个产品团队有OP同事,但没有运维Team。这是开始发展的公司,需要有专人做OP,但是op还是在研发的team;

3)独立的OP Team,适用于已经有一定规模的公司。比如,在AWS的用户里,我常看到80人以上的技术团队,一半都会有考虑将基础架构管理独立出来。

但无论哪种模式,都要求Ops同事除了基本系统管理以外,能够有脚本或代码的能力,能够有基于云做平台架构的能力。

云计算将最底层的数据中心运维做完了,基于云做DevOps和架构设计也就成了自然而然的事情。比如,在猎豹移动,海外运维团队10人以下,管理着上万的VM,以及各类平台服务,DevOps是必须的。

另外,如果组织发展壮大后,在DevOps过程里有一些需要仲裁的事情(如上线时间和方式),或者有些标准需要制定(如版本、平台环境等),建议有一个技术委员会(如果组织小,也许就一两个人)来作仲裁。在Netflix,这个委员会叫CORE Team,大家可以Google以下Re:invent 2015大会上Netflix的分享。

第二,工具和平台

亚马逊DevOps的实践指南
既然DevOps是以软件开发的方式来解决运维自动化,先看看软件开发的工具和平台。首先最底层的Platform就是服务器和操作系统,操作系统有API是一切的基础,然后操作系统的API包装成系统编程的SDK,再然后才有高级语言和解释型语言运行的框架,最上面一层是代码,同时,代码也可以越过封装,通过Native调用的方式来调用更底层的接口。

02/AWS DevOps介绍
亚马逊DevOps的实践指南
公有云对DevOps的支持,其实是一个原理。以AWS为例,Platform就是底层的基础设施,AWS通过技术平台实现了基础设施虚拟化,并提供API,这是最核心的部分,没有API,一切无从谈起。这个API就是Restful API,这也是Amazon Web Services的由来,因为Restful API就是web services,AWS做了很多的工作,把restful API包装成java、python、php、ruby等sdk,到这里已经可以通过编程的方式控制基础设施了,但是为了更加易用,AWS提供了各类的service来作为自动化框架,如基于Chef的opsworks,快速部署的Elasticbeanstalk,将基础设施代码化的cloudformation等。通过这一层的搭建,用户只需要在配置文件或模板或脚本里指定资源,就可以完成部署和控制,因为Framework具备执行和验证的逻辑。
这是使用python sdk (名字叫boto)启用二次启用EC2的代码逻辑和行文需要自己控制,已经很好用了,比如你要启用20台,每台的参数可能会有不同,就可以通过写python脚本的方式,快速搭建,但是行文是自己控制的。亚马逊DevOps的实践指南
这是一个cloudformation模板,里面也是启用一个instance,但是,这里面只有资源描述,具体的操作逻辑是cloudformation这个服务来进行的。

通过框架服务,在自动化的基础上,可以进一步实现标准化。

亚马逊DevOps的实践指南
这个图是AWS的DevOps服务在开发运维整个生命周期的支持情况。

三个黄色的框,分别是CodeCommit、CodePipeline和CodeDeploy。

CodeCommit是一个托管的Git仓库,用于托管代码,好处是AWS托管服务,高可用,完全支持git。

CodePipeline是一个集成编译和测试的工作流服务,可以联合源代码仓库、编译服务器(如genkins)、部署服务(如codedeploy)工作,将部署流程可视化,并能管理复杂的条件分支。

CodeDeploy是一个代码部署服务,通过在EC2虚拟机上部署Agent,可以实现分批和滚动部署,并可以通过配置文件实现部署前后的检测和验证脚本执行。

以上三个工具都可以和第三方工具集成,在部署(deploy)、平台构建(Provision)和监控(Monitor)方面,AWS服务很多。

Cloudformation其实是通过json描述的模板来实现基础架构的搭建,你可以把cloudformation模板也存入Git仓库,每一次基础设施修改都是通过修改cloudformation模板,然后应用来改动(cloudformation可以自己判断差别和资源依赖,实现最小化变更范围)。然后再存入git的时候,在注释中写明更改原由。cloudformation可以做到基础架构代码化,非常重要。

监控方面,Cloudwatch可以监控AWS各类服务的数据,比如EC2的CPU、网络、存储IO,ELB的连接数、排队数、溢出数,数据库服务的IO、延迟等等。

AWS Opswork和ElasticBeanstalk都是完整覆盖三个阶段的服务,不同之处是,Opswork偏运维,控制粒度细,基于Chef来实现平台和应用部署,基于AWS API来实现底层搭建。

熟悉Chef的同学会很容易喜欢上Opsworks。

ElasticBeanstalk更加适合研发背景多一些,或者不喜欢做很多运维工作的同学,ElasticBeanstalk可以自动化搭建底层基础设施和平台环境(如tomcat、python、ruby等),同时,ElasticBeanstalk的命令行可以和git 命令协同工作,git commit之后,一条eb deploy命令可以完成部署。但是ElasticBeanstalk的平台环境版本不可以随意修改,对底层资源的修改也需要修改通过elasticbeanstalk来作。

ECS全程EC2 Container Services,是AWS的docker 集群管理服务,这里就不详细展开了。

值得一提的时,ElasticBeanstalk和ECS也可以联动,如果ElasticBeanstalk提供的环境不能满足要求,你可以把你的自定义环境打包到docker Image,ElasticBeanstalk支持docker部署。

03/猎豹DevOps案例分享
最后,分享一下猎豹DevOps的一些情况。各项服务的频繁开启与维护: 自动化运维开发
代码快速迭代: 基于ansible的发布配置管理
各业务成本控制: 基于tags的成本核算
服务性能监控: zabbix监控上面四项是猎豹移动在海外运维中遇到的问题的解决办法。猎豹移动增长非常迅猛,现在使用了几乎所有的AWS商用Region以服务全球用户。亚马逊DevOps的实践指南这是内部运维平台的架构图,基于Boto(aws api的python sdk)来构建,猎豹自己开发了一个资源申请流程系统,内部用户可以在网页上申请资源,后台通过boto来控制aws资源此外,更复杂的一些运维和部署,通过ansible来做。

对于初创公司,可以通过sdk控制,也可以通过aws命令行来实现自动化。Ansible也是一个非常不错的工具,不需要agent,支持aws api.

亚马逊DevOps的实践指南
这是ansible快速部署ebs存储卷的一个例子。

总结下要点:

首先,DevOps是个方式,要建立正确的文化,开发与运维互相协作,运维技能需要从单点系统扩展到架构设计和脚本自动化。

第二,选用正确的平台和工具,诸如SDK、运维框架等平台和工具,尽量选用已有和比较成熟的,然后直接使用或进行二次开发。但即使二次开发,也是结合业务流,而不是重新做已有平台的事情。

第三,完整考虑各个环境,包括开发、编译、测试、集成、部署、平台构建、监控等,从软件设计之初就考虑到最终的基础架构支持和优化部署,通过微服务演化加速继承和部署,DevOps在其中至关重要。

第四,从哪里上手?第一步,AWS命令行和SDK(比如基于python的boto或boto3);第二步,使用AWS基础设施服务,如cloudformation;第三步,结合使用场景使用高级服务,如ElasticBeanstak、Opsworks等提高运维规范和敏捷度,CodeCommit、CodePipeline、CodeDeploy优化CI/CD流程。

04/Q&A

Q1:在 DevOps 环节中是否需要专门的安全人员?如何解决安全问题?

安全是贯彻始终的,在初创公司,最好是大家形成安全意识,使用工具、平台和服务,也都积极了解安全方面的功能和保障。在AWS上做DevOps,要留意数据存储和传输时候加密,数据的访问权限设置,部署避免使用静态秘钥绑定等等。

Q2:Devops只适用于敏捷开发团队,还是也使用其它开发周期?

如果不做敏捷开发,那么DevOps更多的是自动化部署、降低人为错误、提高运维标准化方面。比如,虽然研发依然是瀑布式开发,但是运维Team内部可以做自动化,基础架构代码化,但是有业务驱动的话,动力一般更强,对不对。

Q3:国内团队如何选择选择云厂商?

AWS的API和SDK是最全面的,在一个比较全面的平台上可以专注自己的平台构建。首先,AWS的基础服务功能很全面,比如VPC,现在还没有看到一个级别的;第二,AWS的PaaS服务可以简化运维,如数据分析类(EMR、Redshift、Kinesis)、数据库类(RDS、DynamoDB);第三,在同一平台上向先驱学习,比如Netflix、SuperCell、小米、猎豹、MobiVista、Camera360等等。

大家Google一下Netflix的OSS,有很多开源的好工具,便于大家在AWS上自动化运维、做大数据分析、提高架构可靠性。

Q4:如何利用 Docker 实现 DevOps 自动化、做好应用持续集成、持续交付有什么好的案例。

Docker革命性地改变了开发和部署,改变了持续集成和交付的流程,研发和运维之间的交付从代码编程了DockerImage(或者Code+DockerFile),运维只需要关注底层资源自动化。但是,DockerImage封装的平台环境要有内部的标准,虽然隔离后可以多环境,但多环境还是要有标准,方便管理。

另外,底层平台的自动化依然需要编程或脚本来实现自动化提供,这点没有变。

现在业界有一个误区,就是把Docker的集装箱特性和高动态特性没有分场景去谈,如果是你自己用,更多是关注Docker的集装箱特性,如果你是用Docker做一个PaaS,那才需要关注和实现在集群里提供高动态。

归类 技术分享