开发测试云DevOps解决方案建议书.docx

开发测试云DevOps解决方案建议书.docx

《开发测试云DevOps解决方案建议书.docx》由会员分享，可在线阅读，更多相关《开发测试云DevOps解决方案建议书.docx（160页珍藏版）》请在冰豆网上搜索。

开发测试云（DevOps）解决方案建议书

目录

159

1 开发测试行业现状及需求分析............................................................................. 3

1.1开发测试现状 3

1.2传统开发测试架构和流程 5

1.3开发测试新需求 7

2 开发测试云（DevOps）解决方案概述.................................................................... 9

2.1方案概览 9

2.1.1平台架构 11

2.1.2功能特性 13

2.2产品组件 16

2.2.1持续交付vRealizeCodeStream 16

2.2.2服务调配vRealizeAutomation 18

2.2.3软件定义的存储VSAN 26

2.2.4软件定义的网络NSX 31

3 开发测试云（DevOps）解决方案技术详解........................................................... 38

3.1持续交付vRealizeCodeStream 38

3.2服务调配vRealizeAutomation 42

3.2.1业务组成元素 42

3.2.2构成组件 47

3.2.3主要功能 49

3.3软件定义的存储VSAN 83

3.3.1体系结构 83

3.3.2基于存储策略的管理 85

3.4软件定义的网络NSX 91

3.4.1基本组件 91

3.4.2工作原理 93

3.4.3主要功能 95

4 VMwareDevOps 方法论.............................................................................. 108

4.1总体指导原则 108

4.2服务调配方法论 109

4.2.1关于服务 109

4.2.2服务的调配管理 112

4.2.3服务设计和开发管理 115

5 DevOps部署建议........................................................................................... 120

5.1服务调配部署建议 120

5.1.1基础架构服务调配规划 120

5.1.2应用服务调配规划 134

5.2软件定义存储部署建议 135

5.2.1部署要求 135

5.2.2规划设计细则 137

5.2.3部署最佳实践 143

5.3软件定义网络部署建议 143

5.3.1逻辑交换 143

5.3.2逻辑路由 146

5.3.3逻辑负载均衡 148

6 方案优势总结.................................................................................................. 151

7 DevOps实施步骤与成功案例......................................................................... 156

7.1实施步骤 156

7.2成功案例 156

8 缩略语解释...................................................................................................... 158

1

开发测试行业现状及需求分析

1.1开发测试现状

现在，人们越来越多的意识到传统意义上的开发行为和运维行为存在脱节现象，从而导致冲突和低效，正如李·汤普森（LeeThompson）和安德鲁·谢福尔（AndrewShafer）所言，

在开发和运维之间存在一面“混乱之墙”。

相互冲突的动机、流程和工具导致了这面“墙”的存在。

图：

开发与运维之间的“混乱之墙”

以开发为中心的人通常认为，变化会带来回报，企业依靠他们来应对不断变化的需求，因此他们被鼓励尽可能进行变革。

而运维人员则往往视变化为敌人，企业依靠他们维持正常业务运维和实施让企业赚钱的服务。

由于变化会影响稳定性和可靠性，运维业务有理由对它说不。

我们多次听到过如下统计数字：

在所有宕机事件中有80%情况是源于自杀式的改变。

更糟糕的是，开发和运维团队通常处于公司组织架构的不同部分，通常具有不同的管理者和竞争关系，而且通常工作在不同的地点。

图：

开发与运维通常工作在不同的地点

此外，让混乱之墙更坚固的还包括开发和运维工具之间的错位。

开发者要求和日常使用的常见工具与系统管理员所使用的工具存在很大不同，开发人员没有兴趣使用运维人员的工具，反之亦然。

而且两部分工具之间也不存在重要的集成，即使在某些工具类型上有一些重叠之处，使用方式也完全不同。

图：

开发与运维常用工具的不集成

当应用程序变动需要从开发团队推向运维团队时，混乱之墙的存在将变得更加明显，如下图所示。

图：

应用程序变动从开发到运维

开发人员把一个软件版本“扔”给墙对面的运维人员，后者拿到该版本产品后开始准备将其部署。

运维人员手动修改由开发者提供的部署脚本或创建自己的脚本，他们还需要修改配置文件来适应与开发环境大不相同的真实生产环境。

最完美的情况是，他们重复在此前环境中已完成的工作，而糟糕的情况却是，他们将引入或发现新的漏洞。

运维人员然后开始进行他们自认为正确的部署过程，但是由于开发和运维之间的脚本、配置、过程和环境存在差别，这一部署过程实际上也是首次被执行。

这一期间如果产生一个问题，开发人员会被要求来帮助进行排障。

运维人员会说开发团队给的产品存在问题，而开发人员则会回应称该产品在他们的环境下运行良好，因此一定是运维人员在部署的过程中做错了什么。

由于配置、文件存储位置和过程的不同，开发人员诊断问题也并非一件易事。

可见，由于没有一个可靠的方式来把环境回滚到此前已知的正常状态，本来应该一帆风顺的部署过程最后变成一场救火行动，经过反复测试之后才让生产环境恢复到正常状态。

上述这些状况在目前的开发测试行业极其普遍。

可见，部署阶段已经非常明显的需要开发和运维之间的协作来解决问题，但需要这种协作的绝不仅仅是这一阶段。

正如约翰·阿尔斯帕瓦（JohnAllspaw）所指出的那样，开发和运维之间的协作需求在部署之前就已存在，同时也会在部署之后的长时间之内继续存在。

1.2传统开发测试架构和流程

传统开发测试架构和流程是导致上述状况的主要原因。

传统的开发测试中，由于组织结构、文化以及技术局限性的多种原因，开发、测试和运维各自相互独立，每个阶段都需要一套复杂繁琐的流程，如下图所示。

图：

传统开发、测试与生产

在组织中，开发测试和运维管理往往属于不同的部门。

开发测试部门的驱动力通常是“频繁交付新特性”，而运维部门则更关注IT服务的可靠性和IT成本投入的效率。

两者目标的不匹配，就在开发测试与运维部门之间造成了鸿沟，从而减慢了IT交付业务价值的速度，如下图所示。

图：

各部门之间的鸿沟

上述开发测试架构和流程会在开发测试与系统运维中制造诸多的不协调与矛盾。

u开发人员经常不考虑自己写的代码会对运营造成什么影响，他们在交付代码之前，并不邀请运营人员参与架构决策或代码评审。

u开发人员对配置或环境进行修改之后，经常没有及时与运营人员沟通，导致新的代码不能运行。

u开发人员在自己的机器上手工修改配置，而没有记录所有需要的步骤。

想找到必要的配置参数，通常需要尝试很多不同的参数，在得到一个可工作的状态后，往往很难识别出通过哪些最小步骤就能到达该状态。

u开发人员倾向于使用有利于快速开发的工具：

对代码修改更快的反馈，更低的内存消耗，等等。

这样的工具集与运营人员面对的目标运行时环境非常不同：

后者对稳定性和性能的要求远胜于灵活性。

u由于开发人员平时使用桌面电脑，他们倾向于使用为桌面用户优化的操作系统。

生产环境的运行时系统通常都运行服务器操作系统上。

u在开发过程中，系统在开发者的本地机器上运行。

在运营过程中，系统经常分布在多台服务器上，例如web服务器、应用服务器、数据库服务器等等。

u开发是由功能性需求（通常与业务需求直接相关）驱动的。

而运营是由非功能性需求（例如可获得性、可靠性、性能等）驱动的。

u运营人员希望尽量避免修改功能，从而降低满足非功能性需求的风险

u如果拒绝了小的修改，但给定时间段内需要修改的总量不变，那么每次变更的规模就会变大

u变更规模越大，风险也越大，因为其中涉及的区域越多

u由于运营人员尝试避免变更，新功能流入生产环境的速度因此被延缓，从而延缓了开发人员将特性交付给用户使用的速度。

u运营人员可能对应用程序内部缺乏了解，从而难以正确地选择运行时环境和发布流程。

u开发人员可能对运行时环境缺乏了解，从而难以正确地对代码进行调整。

由于上述这些不协调与矛盾，现有开发测试架构存在如下问题。

u研发效率低,应用上线速度慢

u开发测试环境搭建从资源申请、购买到使用手工配置需时较长，影响进度

u开发测试所需的IT资源管理不灵活，申请分配环节多，且使用率不高

u开发测试资源申请周期长，影响工作效率

u大型软件企业各部门独立开发环境易形成孤岛，管理成本较高

u开发测试所需的硬件和软件环境对初创软件企业来说成本过高，使用开源软件的配置和掌握需时较多影响效率

1.3开发测试新需求

基于上述当前开发测试架构存在的诸多问题，开发测试行业的新需求如下所示。

Ø业务层面

u如何快速业务创新

u如何快速占领市场

u如何获得竞争优势

Ø产品研发层面

u如何快速交付应用

u如何让研发人员更专注于产品

u如何提高产品质量

Ø架构和运维层面

u如何更好支撑应用

u如何提高运维效率

u如何降低IT成本

u如何维护统一的IT运维流程

上述三方面的新需求是为了让企业在市场、成本与风险层面达到最大程度的协调与统一，如下图所示。

图：

开发测试新需求

2 开发测试云（DevOps）解决方案概述

本章将对开发测试云（DevOps）解决方案进行概述。

2.1方案概览

从应用架构与基础架构的角度看，开发测试云（DevOps）解决方案属于第三代开发测试平台，不同于以ERP等传统应用为代表的第二代平台，第三代平台以社交、移动和云为特点。

VMware开发测试云平台基于软件定义的基础架构，并采用自动化的方式进行交付。

同时，应用的开发和部署也通过自动化的方式来完成，如下图所示。

图：

VMwareDevOps属于第三代平台开发测试云（DevOps）平台通过如下方式实现。

u从应用开发与基础架构两个层面面向DevOps进行转型

u打通研发与生产运维体系,逐步推进构建DevOps团队

u采用统一的工具vRealizeCode