分布式混合云DevOps实践

5/8/2015分布式混合云DevOps实践分布式混合云DevOps实践千米网Bugatti系统的起源，发展与未来彭毅5/8/2015分布式混合云DevOps实践年以前，我们只有30-40个开发人员，公司处于startup状态。初期没有CI，没有版本Release，大部分模块上线由模块负责人使用class或jsp替换线上服务器完成。我们2012年配备第一套测试环境，测试环境的搭建和调测花费了10多个人，陆续约1周半的时间。模块负责人维护着共80台左右的虚拟机这种不规范的工程实践方式带来很大隐患5/8/2015分布式混合云DevOps实践年，逐渐从30多开发人员迅速膨胀到80人左右的研发团队初步建立了CI、版本发布，但依然由人工部署上线。因业务需要，出现了第二，第三套测试环境，但维护代价很高，新测试环境的搭建依然缓慢。由于SOA化和模块解耦重构的工作不断开展，生产环境虚拟机迅速增加到200-300台。由于部署时，很多配置文件的修改都是人工在线上服务器操作，导致环境的再部署非常困难，且依然只能由熟悉的人来完成。5/8/2015分布式混合云DevOps实践年后，研发团队达到到110人左右90%以上的模块具备CI能力新测试环境搭建和测试环境维护依然费时费力SOA改造初步完成，生产环境虚拟机达到500-600台的规模，出现了一些无人认领的主机。依然由专人进行系统部署，且往往部署时丢三落四，导致扩容和故障点迁移时间很长。为了解决这个问题，后来甚至形成了新员工转正需要考核本模块部署的“上机考试文化”。显然，环境部署问题已经严重阻碍业务发展，需要CD能力。5/8/2015分布式混合云DevOps实践自动部署流程的选择不可能像startup团队一样，由开发人员自己写自动部署脚本完成上线。也不希望和一些大公司一样，将开发和部署分两个部门，之间的需求传递通过文档完成。更不可能仅提供一套工具，由各业务部门完成自动部署脚本的开发。5/8/2015分布式混合云DevOps实践我们选择的部署流程形态我们需要一套工具，利于开发人员理解和使用。开发人员的输出可以很自然的衔接上运维人员写的脚本，从而完成自动部署。即如何更快速的以第二种形态进行工作，而不会有太多沟通成本。5/8/2015分布式混合云DevOps实践这套系统承载的诉求资源管理和环境隔离新环境的快速搭建数据库脚本的版本化现有部署形态向CD的演进最终以业务的高可用为目标，DevOps需求整合的平台5/8/2015分布式混合云DevOps实践寻找可行的方案通过jenkinsPipelines方式完成自动部署。业界有较成熟的自动测试+自动部署的实践，但对资源管理偏弱。编写script脚本完成自动部署。不具备大型bash类script脚本编程经验，其实现和维护成本相对较高。资源管理是否用openstack或cloudstack初步试用上的感觉较重，注重资源管理，结合其他软件实现部署，暂不引入。现有deploy框架的使用，如puppet、salt等基于dsl方式puppet的和使用yaml格式基于申明方式的salt做了比较，salt的学习曲线较低。结合考虑了puppet的开发语言ruby和salt的开发语言python，综合公司技术栈（python），最终选择了salt。5/8/2015分布式混合云DevOps实践初期方案使用salt脚本作为后端脚本进行自动部署通过一套简单的界面调用salt的脚本完成部署5/8/2015分布式混合云DevOps实践初期成果使用scala的playframework与简单的html表单完成对salt-master的调用用salt完成了一个项目的自动部署Lessons内部系统也是人在用，没人忍受那么简单的界面5/8/2015分布式混合云DevOps实践第一次重构将用户操作抽象成工作流，stepbystep填写部署参数，参数传递给salt脚本完成部署。以资源管理角度出发抽象和规划功能使用bootstrap+backbone+coffeescript进行前端开发，后端使用playframework+Anorm。5/8/2015分布式混合云DevOps实践第一次重构结果初步完成规划功能的30%，进行初步推广试用Lessons界面有所改观，操作比较繁琐，继续被喷。salt脚本与程序本身存在耦合，脚本的变动影响到操作界面代码编写，不利于脚本快速迭代开发和快速bugfix。开始在开发环境进行部署试用，无法支撑复杂环境。公司生产环境分5个区域（杭州联通机房，杭州万网机房，南京软件大道，南京凤凰机房，杭州阿里云）机房之间做了必要隔离，且之间连接的网络带宽不高，不能仅通过一套salt-master管理所有机房主机。在大并发情况下，salt-master调用会挂起执行线程，导致程序异常5/8/2015分布式混合云DevOps实践思考几个问题从软件使用者角度出发重新思考界面操作问题salt脚本与bugatti软件耦合度高，如何解耦？salt自带syndic分布式方案在文件传输上有问题，如何处理多环境下的配置文件传输？salt的同步调用如何转换为异步调用，如何获取返回值？服务的配置文件渲染（根据环境、ip、不同组网等有不同配置要求）如何实现？是否用salt自带的渲染方式？5/8/2015分布式混合云DevOps实践重新设计以项目而不是资源为维度进行建模，从软件使用角度出发简化操作，灵感来源于iTunes等软件播放器。抽象一个中间层spiritspirit封装salt的一些实现细节，中间层spirit与bugatti之间以标准协议进行通讯spirit起到网关作用，替代saltsyndic实现分布式组网抽象一套模板，用于隔离salt脚本变化与bugatti软件变化屏蔽salt渲染方式，抽象一个部署meta对象，使用javascript引擎对配置文件进行渲染5/8/2015分布式混合云DevOps实践精益创业开发——重构持续进行5/8/2015分布式混合云DevOps实践组网与典型场景5/8/2015分布式混合云DevOps实践分布式组网图5/8/2015分布式混合云DevOps实践典型场景-部署5/8/2015分布式混合云DevOps实践典型场景-salt脚本开发5/8/2015分布式混合云DevOps实践典型场景-日志5/8/2015分布式混合云DevOps实践典型场景-自动测试5/8/2015分布式混合云DevOps实践典型场景-数据库版本管理5/8/2015分布式混合云DevOps实践软件功能介绍5/8/2015分布式混合云DevOps实践网关、区域、环境的关系网关与地域组网相关区域为资源所在地的标识和集合环境为逻辑隔离单元，可以横跨1-n个区域5/8/2015分布式混合云DevOps实践环境环境与实际网络的3层隔离情况无关，只与配置的逻辑掩码有关不同分支salt脚本可以配置到不同环境，方便salt脚本开发验证，版本回退等环境分普通和安全，分别对应不同权限需求5/8/2015分布式混合云DevOps实践权限系统支持ldap绑定登录和非绑定登录。环境分普通和安全（对应到线上生产环境）两个级别分环境和项目两个维度设置权限，分别都有管理员和成员。项目管理员（成员）可以管理所有环境下该项目（成员不能操作安全环境）。环境管理员和成员可以管理该环境下所有项目。环境管理员可以锁定该环境，防止项目成员修改该环境中项目信息。5/8/2015分布式混合云DevOps实践项目维度的操作体验负载为该网元下绑定的环境资源（机器）属性为该项目所属模板需要填写的参数（属性由模板定义）配置为项目按版本的配置文件成员为项目下相关成员界面中按钮动作来源于模板Queue（提供了一个动作队列，salt本身不支持队列）5/8/2015分布式混合云DevOps实践项目模板定义分别抽象了模板依赖、别名、属性、动作和步骤等name:webapiremark:用于dubbo项目的自动部署，即api类项目dependences:-name:$logServertype:nfsdescription:日志服务器default:LogServeraliass:-items:-actions:-name:安装应用css:glyphiconglyphicon-uploadversionMenu:Truesteps:-name:安装