开发测试云DevOps解决方案建议书Word文档格式.docx
《开发测试云DevOps解决方案建议书Word文档格式.docx》由会员分享，可在线阅读，更多相关《开发测试云DevOps解决方案建议书Word文档格式.docx（160页珍藏版）》请在冰点文库上搜索。
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采用统一的工具vRealizeCodeStream自动化管理整个软件研发周期
u采用vRealizeAutomation进行研发,预生产,生产环境的资源自动化部署
u采用NSX进行网络微分段,同时提供多个相同环境（含网络）并行开发测试进程,加快软件发布
u采用vRealizeAutomation跨开发、测试、生产进行应用平台的自动化部署
u通过部署VSAN作为研发平台的后端存储
u包含的产品:
vRealizeCodeStreamvRealizeAutomationVSAN
NSX
DevOps平台在构建过程中的要点如下所示。
u协作：
开发运维共同定义环境并共享
u定义：
端到端的交付生产线，整合的自动化流程（集成，发布，部署，测试）
u执行：
在与生产环境一致的测试环境自动化部署和测试
u报告：
按照实例报告代码变更，软件发布和测试结果
u持续集成：
持续集成代码，持续发布应用
u持续部署：
弹性云服务平台管理，保证开发、测试、准生产、生产的环境完全一致，持续部署新发布的应用及其底层环境，包含监控部分
u持续测试：
持续自动化测试
u持续监控：
持续对测试，准生产和生产环境提供自动化的监控和性能评估，并反馈给开发
该平台彻底将开发、测试、试运行和生产打通，如下图所示。
2.1.1平台架构
图：
VMware平台彻底打通各个阶段
开发测试云（DevOps）平台架构如下图所示。
开发测试云平台架构
该平台通过VSAN作为后端存储，利用NSX网络微分段促进软件并行开发。
上层使用vRealizeAutomation来完成自动化部署。
同时，DevOps平台通过vRealizeCodeStream提供应用持续交付以实现频繁、可靠的软件发布，同时还能降低运维风险。
VMwareDevOps通过构建统一云平台，将所有的阶段进行整合，实现系统管理、开发人员、测试人员在同一的门户下进行操作，真正的实现资源的统一整合，如下图所示。
资源统一整合
DevOps平台使用VSAN作为开发测试云的后端存储，如下图所示。
VSAN
该方式具有如下价值
u应用感知的性能控制
u部署简单,管理方便
与vSphere紧密集成基于策略驱动
u经济高效的存储
运行于标准X86服务器
容易纵向,横向扩展,无需初次采购大存储
同时，该平台还利用NSX网络微分段促进软件并行开发，如下图所示。
NSX微分段
该方法将一套物理网络虚拟成多套相同配置逻辑网络，实现自动化部署和并行测试。
2.1.2功能特性
VMware开发测试云平台（DevOps）具有如下功能特性。
功能特性
提供个性化的自助式体验
u通过统一的IT服务目录交付基础架构、应用和自定义服务
u凭借基于策略的个性化行政管理满足适当服务级别的特定业务需求
u自动执行和加速IT服务交付
自动化管理开发、测试与生产部署整个软件生命周期
一次应用建模，随地部署
u使用具有拖放界面的可视画布将预构建的组件组合为各种应用，从而简化设计流程
u凭借跨混合云的标准化且一致的配置，快速部署基础架构和应用服务
u通过利用一系列即时可用的内容和对现有配置管理工具（例如Chef、Puppet和
SaltStack）的投资，加速工作负载部署
并行开发与测试,加速开发进度
u利用NSX的Micro-segmentation功能自动化交付多套相同网络配置的研发环境
u并行项目测试与开发
通过可延展的自动化平台实现最短的价值实现时间
u内置全面的专门构建的功能和广泛的多供应商、多云支持
u调整和扩展专门构建的全面vRealizeAutomation 功能
u自动执行自定义IT服务的交付
u利用VMware云计算管理市场中由VMware和合作伙伴提供的解决方案
实现持续交付
u对发布管道进行建模，并执行发布
u通过筛选规则在发布的各个阶段实施行政监管
u可简化和自动执行软件交付流程
跨版本提供可见性
u跨发布阶段提供一致的视图
u跟踪项目以确保各个阶段均使用正确的版本
u通过发布仪表盘提供端到端的执行可见性
与持续集成工具集成
u使用JFrogArtifactory 来利用对现有工具和技能的投资
u使用Artifactory插件将项目纳入发布管道
u可与Jenkins、Yum、Artifactory、Git实现即时可用的集成
u用于调配和部署软件的框架
u可通过vRealizeAutomation，同时借助Puppet、Chef、Saltstack、Ansible、
CFEngine等配置管理工具，甚至是自定义脚本来部署应用环境
上述功能特性使得DevOps平台可以在业务、产品研发与IT运维三个层面很好的满足开发测试行业的新需求，为企业带来如下收益，进一步提高企业市场竞争力、降低成本与风险。
u业务创新更快
u占领市场更快
u竞争优势更强
u交付应用更快
u上线速度更快
u产品质量更高
IT运维层面
u支撑应用更好
u运维效率更高
uIT成本更低
uIT运维流程更统一
2.2产品组件
开发测试云平台收益
本节介绍开发测试云（DevOps）解决方案的如下四款主要产品。
uvRealizeCodeStream
uvRealizeAutomation
uVSAN
uNSX
2.2.1持续交付vRealizeCodeStream
VMwarevRealizeCodeStream可提供持续交付以实现频繁、可靠的软件发布，同时还能降低运维风险。
CodeStreamCodeStream具有如下功能特性。
u对发布管道进行建模，并执行发布。
u通过筛选规则在发布的各个阶段实施行政监管。
u可简化和自动执行软件交付流程。
u跨发布阶段提供一致的视图。
u跟踪项目以确保各个阶段均使用正确的版本。
u通过发布仪表盘提供端到端的执行可见性。
u使用JFrogArtifactory 来利用对现有工具和技能的投资。
u使用Artifactory插件将项目纳入发布管道。
u可与Jenkins、Yum、Artifactory、Git实现即时可用的集成。
用于调配和部署软件的框架
CFEngine等配置管理工具，甚至是自定义脚本来部署应用环境。
2.2.2服务调配vRealizeAutomation
VMwareDevOps解决方案的服务调配功能由vRealizeAutomation实现，它通过自动交付个性化的IT服务来提高业务敏捷性。
2.2.2.1概览
垂直竖井式管理把特定应用和基础架构捆绑在一起，而VMware可以把基础硬件和应用，以及终端用户服务抽象到一种水平的松耦合的层级中，进而打破这种垂直竖井结构的壁垒。
传统竖井IT管理向云计算管理转变
VMwarevRealizeAutomation（vRA）位于VMware云计算数据中心的最高级管理层面，它不仅可以管理基础计算资源，也可以管理桌面与应用资源。
vRA提供了一个可以跨不同云提
供商的，管理和调配虚拟机、云虚拟机和物理机，并管理它们的生命周期资源的自助式门户。
vRealizeAutomation
客户的异构环境可以通过vRA来进行集中化和标准化的调配和管理。
对于管理虚拟机，可以对VMwarevCloudDirector环境、vSphere环境虚拟机进行管理，并且可以管理MicrosoftHyper-V、CitrixXenserver、RedhatKVM等虚拟化环境。
对于物理机，vRA可以管理主流x86服务器厂商的服务器，包括HP（通过iLO），DELL
（通过iDRAC），CISCO（通过UCSM），IBM（需要作一定的定制开发）。
此外，vRA还可以管理外部公有云如VMwarevCloudDirector和AmazonAWS虚拟环境的云资源。
vRA自身不具备虚拟化资源的能力，而是与虚拟化平台协作，提供调配和管理虚拟化平台所创建的虚拟机和产生的虚拟计算资源的能力。
要完成上述调配和管理的功能v，RA需要使用包含在平台结构内的代理。
类似地，vRA并不直接管理云虚拟机，而是直接与云服务交互，来调配和管理云平台创建的虚拟机。
对于管理物理机器，vRA直接与每个系统的管理接口通信来执行诸如操作系统安装、重启、重调配等操作。
vRA的三个主要优点如下图所示。
vRA的三个主要优势
VMware通过采用针对基础架构服务（包括计算和桌面两方面），以及应用服务的调配解决方案很好地解决了客户所面临的挑战，通过自动交付个性化的IT服务提高了业务敏捷性。
vRA的主要价值
借助vRealizeAutomation（vRA），客户可以对通过自助式门户和目录向终端用户提供的预定义基础架构和桌面服务进行自动化调配，从而快速实现价值。
这些功能可促使企业加大创新力度，并且能够提高企业的敏捷性以及降低IT成本，同时还能确保符合行业和公司的法规和策略。
此外，vRA还能够简化和自动化将任何自定义或打包应用调配到任何已批准的云的过程，从而缩短应用的上市时间。
可重复使用的标准化应用组件能够降低成本，并且有助于确保合规性，此外还能调配到多个云，因而可提高业务敏捷性。
随着客户继续将增进业务价值的流程自动化，vRA的功能可使客户大大缩短服务交付时间并提高控制力和治理程度。
在基础架构层面，vRealizeAutomation可让用户通过服务店面轻松访问IT服务，而这
些服务，无论是计算、桌面还是应用，都是通过服务蓝本调配的。
该解决方案还提供策略引擎，从而确保用户能够访问经授权的服务，同时确保将服务调配到正确的环境并将审批和调配流程自动化。
在应用层面，vRA可让用户通过可重复使用的组件构建应用蓝本，并且将这些蓝本与所有可用云的部署配置文件关联起来。
应用调配
应用架构设计师可从这个独特的用户界面（基本上是一个空白画布）中拖放已批准且可重复使用的操作系统、中间件和应用组件，以创建多层应用蓝本。
此后会自动将此逻辑蓝本与您选择的特定云计算环境相关联，无论它是内部的
升级会员 