《Devops建设方案.docx》由会员分享，可在线阅读，更多相关《Devops建设方案.docx（21页珍藏版）》请在课桌文档上搜索。
1、DevOps建设方案D0实践deployPeratepv*fficiency效能Value价值0PenProgressSecurity开放演进安全目录DevOps建设方案11概述41.1 背景41.2 需求分析41.2.1 质量管理需求：41.2.2 系统运维需求：41.2.3 集成开发需求：51.2.4 产品管理需求：51.3 建设目标51.3.1 自动化51.3.2 可视化61.3.3 流程化62总体设计63详细设计83.1 环境管理设计83.1.1 进程隔离93.1.2 网络隔离103.1.3 文件系统隔离113.1.4 镜像仓库隔离113.1.5 产品实现123.2 配置管理设计123
2、.2.1 源代码配置管理133.2.2 依赖管理133.2.3 应用配置管理133.2.4 环境配置管理143.2.5 产品实现143.3 构建集成设计143.3.1 编译153.3.2 构建153.3.3 部署163.4 测试管理设计173.4.1 自动化测试173.4.2 人工测试174实施步骤185建设实施难点195.1 短期收益与长期收益的平衡195.2 习惯的改变191概述1.1 背景#依据实际情况接受背景#1.2 需求分析1.2.1 质量管理需求：测试人员在需求阶段就接入，产品、开发、测试、运维达到全流程需求透明集成自动化测试平台，在每个环境部署后自动执行测试，包括开发阶段的单元测
3、试、代码质量扫描，安全性测试、压力测试等1.2.2 系统运维需求：支持LDAP用户对接登录；支持用户角色划分，不同角色对应不同操作权限；devops系统本身运行在IinUX系统之上，但devops的作用对象（容器，虚拟机，物理机）应当支持异构操作系统平台（Winde）WS,Iinux）;devops的作用对象（容器，虚拟机，物理机）应当支持多种应用框架的开发部署，如PHP,JAVA,ruby等，具体结合公司现有开发部署环境梳理；自动对接公司现有基于ZabbiX的监控系统，服务上线自动注册，服务下线主动注销；项目需求中应包含对部分系统的微服务化改造，以及对于未来建设项目的微服务化建设建议和具体模
4、板框架推荐；将自动化测试框架、devops平台工具组件运维及相关培训纳入项目需求；devops系统须与公司现有云平台二期的虚拟机及容器对接,基于云平台二期实现；1.2.3 集成开发需求：所有的开发人员需要在本地机器上做本地构建，然后再提交的版本控制库中,从而确保他们的变更不会导致持续集成失败。开发人员每天至少需要从版本控制库中更新一次代码到本地机器。每次构建都可以生成可发布的产品。修复失败的构建是优先级最高的事情。每次代码递交后都会在持续集成服务器上触发一次构建每人都能通过系统，清楚正在发生的状况。统一的代码库、自动构建、自动测试、自动部署1.2.4 产品管理需求：集成需求管理功能，能便捷提交
5、需求，需求评估，审核，监控需求处理流程，对需求变更进行跟踪管理；监控产品开发、测试、发布整体处理流程与进度。1.3 建设目标为信息服务部内的数据组、综合平台组、运行平台组、服务营销平台组、移动开发组等开发小组提供统一的研发构建测试平台。打破开发、测试、运维、产品、运营之间的壁垒，适应快速变化的市场需求，提升软件的交付效率与交付质量。1.3.1 自动化自动化是持续交付的基础能力，目标是加速代码提交到部署上线的过程，主要包括构建、环境管理、应用部署、测试这几方面的自动化。1.3.2 可视化可视化能力是独立于组织文化、持续交付、技术运营之外，贯穿始终的一种能力，可视化的意义在于通过数据度量DeVOP
6、S能力、推动持续改进、便于团队基于全过程的数据分析与协作、帮助定位故障等。1.3.3 流程化在考虑流程类的问题时，一些耗时较长的流程，完全人工类的流程，一般效率低下，且质量难以保证，持续交付的逐步深入会通过自动化替代这些人工流程的存在。同时一些审批类的流程，代表着授权与责任，有其存在的价值和意义，不能轻易被去除或打破。2总体设计XX云DeVoPS解决方案以CCOS容器云操作系统为基础，实现从项目需求提出到产品设计、研发、编码、编译、构建、部署、测试、运维的全生命周期管理。采用微服务化的设计思路，各功能模块相互依赖而又相互独立，不但具备单独发布升级的能力，而且各功能模块留有公共的API接口，结合
7、客户已有的研发工具、流程，实现资源的最大化整合，不额外增加客户对工具的学习、使用成本。总体功能结构如下图所示：项目产品构建部署流水线团队版本管理构建定义滚动更新发布库计划需求管理构建执行动态伸缩I发布流水1.线任务立项管理代码质蚩部署设计集成流水通知产品运营代码库异构环境多中心总结竞品分析分枝/tag组件运维蛉收ECOS容器云平台产品实现以Drone为基础,合理的利用docker容器技术来构建和部署应用，结合容器的云原生特性构建强大的持续交付平台。Drone引入pipeline的概念,整个build过程由多个stage组成,每一个stage都是docker容器。各Stage间可以通过共享宿主机
8、的磁盘目录，实现build阶段的数据共享和缓存基础数据，实现加速下次build的目标。各stage也可以共享宿主机的docker环境,实现共享宿主机的dockerimage,不用每次build都重新拉取baseimage,减少build时间。多个build可以并发运行，单机并发数量由服务器CPU数决定。其中由开发者负责打包image和流程控制，docker-in-docker,一切都在掌握之中。相比jenkins的好处是，所有的image都是开发者提供，不需要运维参与在Cl服务器上部署各种语言编译需要的环境。然后直接通过docker-compose的方式部署应用。实现逻辑如下图所示：项目管理工
9、具3详细设计3.1环境管理设计DeVoPS工程所涉及到的环境包含开发环境、集成环境、测试环境、预生产环境、生产环境。环境与环境之间的隔离借助CCc)S容器云平台的多租户功能实用户间数据的隔离性。CCOS多个租户共享整个物理集群系统计算资源，并限制各个租户的相互隔离和资源使用配额限制。多租户使用KUbernet6sNamespace实现隔离和限制，不同租户拥有独立用户管理、角色和权限控制，隔离的进程、网络、文件、域名和镜像仓库系统。租户共享主机资源，共享网络带宽，共享基础存储和镜像仓库；租户之间进程隔离，网络访问相互隔离，存储访问相互隔离；限制租户对计算资源，存储资源和对象创建数量的限制；以租户
10、为单位对实际使用的计算资源，存储资源消耗和对象创建数量进行计费。不同的租户，共享底层IT资源（计算、存储，网络），但必须保证租户之间的服务运行性能以及数据c和网络安全，所以需要对不同用户之间运行的容器进行严格限制和隔离。限制的内容包括：容器的CPU和内存需求，容器的特权模式，容器的网络HoSt模式，以及容器相关的能力。隔离的内容包括：程序进程，网络访问，文件系统，主机域名，用户操作。3.1.1进程隔离docker使用LinUXkernelnameSPaCe实现隔离。其中Pid、net、ipc、mnt、UtSxuser等namespace将container的进程、网络、消息、文件系统、UTS（
11、UNIXTime-sharingSyStem)和用户空间隔离开。并在创建容器时严格限制容器所拥有的能力(特权)模式和网络模式运行，防止访问内核权限和主机网络，实现对应用的进程隔离和安全控制。pidnamespaceroot pid namespacepid namespace Xpid 3 (pid 1) *pid 4 (pid 2)不同用户的进程就是通过Pidnamespace隔离开的，且不同namespace中可以有相同pido所有的LXC进程在docker中的父进程为docker进程，每个Ixc进程具有不同的namespace。同时由于允许嵌套，因此可以很方便的实现DOCkerinDoc
12、keropid1(pid1)IIIpid2(pid2) Black:therealpid Red:thepidprocessusegtidtoget有了pidnamespace,每个namespace中的pid能够相互隔离，但是网络端口还是共享host的端口。网络隔离是通过netnamespace实现的，每个netnamespace有独立的networkdevices,IPaddresses,IProutingtables,procnet目录。这样每个container的网络就能隔离开来。docker默认采用veth的方式将container中的虚拟网卡同host上的一个dockerbridg
13、edockerO连接在一起。1.1.2 网络隔离通过netnamespace实现容器之间的网络隔离，但同一个租户容器之间需要互访，不同租户之间的网络进行隔离，每个租户只能访问自己的网络资源，不可访问其他租户的网络资源。默认使用Calico实现容器之间的互联互通,但在创建租户时自动创建租户对应的Calicoprofile,通过Calicoprofile利用LinUXiPtables、ACLS特性，实现不同租户的网络隔离和访问安全控制。1.1.3 文件系统隔离文件系统分为本地文件系统和网络文件系统。本地文件系统：创建容器时挂载本地文件系统，则用户需要指定文件系统需求的容量和容器中挂载的路径，但不能
14、指定主机文件路径，必须由调度系统自动创建目录进行挂载，防止文件被多个容器挂载，实现文件系统的隔离网络文件系统：依赖KUbemeteSPVC和命名空间绑定，实现不同租户的网络隔离。1.1.4 镜像仓库隔离集群安装完成后，系统自动在不同数据中心部署镜像仓库的主从，并全数据中心同步，以实现各租户对镜像仓库的需求；各个租户镜像相互隔离，镜像仓库通过三个级别的镜像仓库访问控制实现租户的访问隔离：公共镜像仓库：默认以/image）路径表示，公共镜像仓库任何租户可访问，提供基础镜像的公共访问；集群管理员可管理公共镜像仓库。租户仓库：默认以namespaceimage）路径表示，只有该租户中的用户可以访问，具
15、有该租户仓库管理权限的用户可以psh镜像到命名空间镜像仓库中，实现租户内仓库的共享。个人镜像仓库：默认以serameimage）路径表示，供个人使用（需要具备相应的PUSh权限才会开通），个人用户名需要排除特殊名字的注册。产品实现:每一类环境配置一个管理员，具体的环境权限由管理员设置。JaatJ11nS35认证授仅用户管理用户类型工作空间用户亘支姓名告注asdi23asd角色：admins添加用户I期新帐号Emailpoduct,admnI23qqcom+融操作更新test_a(knintesil工作空间郦adeveJop-adfm277H70l4&qqcom工作空间用户admmadmmeko
16、s.local彩用户每一个工作空间代表一类环境。工作空间所有空间a:Eg司叨新工作空间售在莒理员麴遣理员创窿时间asdi23asdasdi23asd系统超轨管理员共4条_更新时间儡S三领三虐辅雄涂10/跳至页admin告理员娟作defaultK8s默认命名空间admin2018-06-1111452018-06-111145更多Vdevelopdevelop_admn2018-07-0915:152018-07-0915:15哪三电眸更多VproductionprDdudadmin2018-07-0921262018-07-092126更多VtestIeSLadmin2018-07-09212
17、22018-07092122共4条QAS除10条/页更多V貌至页3.2 配置管理设计持续交付的源头是配置管理，源代码、依赖、应用、环境都应该实现配置管理。配置管理工具不仅仅是Git、SVN等版本控制工具，MaVen的NeXUS和自建的CMDB都可视为配置管理工具，只要能够根据版本定位到具体时间点的状态即可。变更问题事件管理配置土酶 可用性发布3.2.1 源代码配置管理源代码包括：业务代码、测试代码、构建脚本、部署脚本、相关文档等，这些源代码都需要配置管理起来，便于追溯历史版本，和团队成员间的协作。3.2.2 依赖管理依赖管理包括：外部库文件管理和内部组件管理。依赖管理采用类似Maven这样的自
18、动化工具实现，而不是将库文件存储到代码库中。团队协作也基于组件进行协作，而不是直接依赖于源码。3.2.3 应用配置管理应用配置管理主要包括三要素：应用程序、应用程序版本、应用程序版本运行的环境，如JDK1.7UbuntuServer-1404-LTS3.2.4 环境配置管理环境配置管理的核心是通过全自动过程创建环境，创建全新的环境总是要比修复已受损的环境更容易。配置项：操作系统版本补丁级别应用依赖的环境软件包应用需要的网络拓扑结构应用依赖的外部服务3.2.5 产品实现3.3 构建集成设计构建集成是指开发人员在开发环境中完成编码和单元测试后，提交代码到代码库中并发起集成的过程，将验证之后的开发代
19、码提交到代码库主干分支，供其他开发人员使用和提交测试。提交集成会执行私有构建，私有构建是可选的，目标是防止明显错误的代码签入代码库,保证代码质量。包括针对该代码库的编译、单元测试、代码扫描和CodeReView。其中编译、单元测试和代码扫描的结果可以作为CodeReview的依据。集成构建的目标是构建出产品部署包，可以是人工触发、定期执行或者提交时即执行。集成构建对产品的所有代码库按顺序进行如下过程：编译：生成编译文件，用于打包。单元测试：生成白盒测试报告，用于衡量产品功能质量。打包：生成产品部署包，用于部署，这里指打包成docker镜像。代码扫描：生成产品代码扫描报告，用于衡量产品代码质量，
20、促进团队优化代码。3.3.1 编译在以drone为核心的PiPeline当中，不同语言的编译环境由开发者自己定义，通过images的方式。名称：mpe执行镜像：reQstrv.eos.locawPrafv,OIana.IaiestCGO ENAf rglstfy os k)ca1,iirafyheo.atestregistry.ekos iocai/liorary/aipgolagjatesrDuiidimage: dockerfile /Dockeffile image. mifror.gostcloud.cfV(levopsdrone-pJuginlocker.atest* oo_cach
21、e falserepo registry ekos Iocalzlitxaryzfirstpublish:image:miffor.ghostcloud.cdevopsdrone-puginleploytest, yaml: /.depoyment.ym3.3.2 构建构建打包是通过dockerfile的方式生成对应的应用镜像，镜像内容由开发者根据实际情况设定。名称：buildimage恂版存：CBDockefflie: /Dockeffiie食像发布：registry.ekos.locaWbfary/pe:commands:-CGO.ENABLE。=OgotWHdimage: registr
22、y.ekos.locallibrarygolangJatesrOuiidimagedockerfile: JDockerfiIeimage ,mwghos(coud Cevops(iroe-pgin-docker aest, no-cache: falserepo registry ekos.ocaHbrafyfirstpublish:image: mi(x.gostcloud.cdevopsdroe-plgin-deployJatesryamr ./.(Ieploymentyml3.3,3部署部署通过配置yml文件的方式，将应用快速部署到CCOS容器云平台。名称：tMJidimage构献存：
23、QDockerfile: ./Dockefflle确像发布：registry ekos lat,libraryfirst名称：deploy/deployment ymlpipelinecompile:commands-CGO_ENABLED=0 go buildimage: regtst,.ekos.locaVlibrafygolag1atest,bulldimagedockerfle: ./Dockerfileimage Hiirrorghostcloud crVdevops.drone-piugin-docker latestno_cacne: falserepo: registry ek
24、os.localbraryfirstdeploy:image: TnirrorghostcIoiKl Vdevopsdroneplgn-,并将以哥代码方式托管在薄码仓Ie中，可以实现在多个环球集群中DeVOPS配三afl.就角出S文件璃耳渣当叠花动.I修/IapemeteskrevsnTekos.grstcol.c,desc-Kubemelesi,cagecausemCreatiOnTlmestamP2O18-O3-24T11O528Zgeneration1tat)efeekosapplicationappeos-seve:flrstserveiogignofe:laiseschedule:p
25、uWcNodestateful,nonetypeservice,3.4 测试管理设计3.4.1 自动化测试自动化测试的目标是对验证产品是否符合需求，使用自动化测试工具对产品进行测试，生成自动化测试报告。名称：test执行镜像：registry eos local/HDrary/fobotframeworK latest执行命令：testimage. ,registry.ekos.locaVlibraryrobotframevork. latestI濠力译步骤I添加构建愤像步赛I添加发布到警群步或I添加自定义步骤3.4.2 人工测试测试人员在自动化测试的基础上根据业务需求和测试经验进行探索性测试
26、,发现隐藏的缺陷。4实施步骤改变原有的交付习惯，过程肯定是漫长的也是痛苦的，为了应对这些挑战,从整个DeVc)PS实施的角度出发，需要通过图所示的三个阶段逐步进行实施。3,简化开发测试发布流程JL业务人员*开发蓼试人员*4运媛人员持楼加控2,优化现有开发模式及现有产品架 构,消除流动障碍,构建!陵YQ磔支付流水线平台，减少人工操作第一步，显然，消除大量的手工操作，构建一个持续交付的流水线平台是最基础也是最迫切的，只有通过流水线平台的自动化和持续流动，才能保证在不同阶段、不同节点上产品发布的一致性和稳定性，同时，也才能消除由于人工操作所引入的人为风险，同时提高效率。第二步，则需要对现有的开发模式
27、及产品架构做进一步的优化，否则，整个流水线是很难顺畅地流动起来的。例如，如果不调整固定版本排期的开发模式，则即使自动化程度再高，紧急需求的上线仍然需要等待整个版本的上线；而对于项目排期的开发模式，在上线前，多个项目代码或者构建包的手工合并也是必不可少的；在传统紧耦合的产品架构下，想要做到自动化的增量迭代发布，也是非常困难的，而每次都将整个产品的所有代码进行发布也是极不现实的，这些其实都是实现整个DeVC)PS持续交付过程全自动化的障碍。因此，在构建好持续交付的流水线平台后，其第二步就是开发模式及产品架构的优化。当然，如果没有第一步的自动化的持续交付平台作为基础，则由开发模式调整所带来的发布次数
28、增多也是无法完全用手工完成的。在通过工具自动化的方式实现产品的持续交付后，由于人工操作的减少，自动化及流水线操作的提高，包括操作过程可追踪性的实现，快速自动回滚操作的实施等，这个时候，在完整的开发测试交付流程中，有些管控步骤可能就是多余的，是可以优化的。因此，实施的第三步就是对整体开发测试发布流程进行优化，去掉冗余的人工评审步骤，从而实现企业级的DeVOPS持续交付流水线。5建设实施难点5.1 短期收益与长期收益的平衡对于开发人员和运维人员来说，每天的工作任务都非常重，其最关心的是眼前的问题能不能解决，当前的效率能不能马上提高。而任何一个新工具，新方法的实施都不可避免地需要投入一定的时间进行学
29、习、适应，会对当前的工作造成影响，甚至短期内反而会降低效率。故而在实施初期会引起部分团队成员的抵触和反对，这个时候，如何将开发人员及发布人员当前迫切关心的短期收益与整个平台实施后的长期收益结合起来就成为实施推进的难点之一。针对这种情况，在具体实施时，我们既需要一定的耐心，也需要有抓有放，对于部分时间暂时允许，也愿意积极配合的团队先行推进，而对于目前比较抵触的团队，则先放一放，等到先行实施的团队显示出收益，中间观望团队积极推进时，慢慢就会形成一定的气候，从而能够比较好的进行推进。5.2 习惯的改变任何一个人，都会有其熟悉的行为习惯和方式，当需要其作出改变，适应新的方式时，谁都会作出抵触，都会不愿
30、意。而任何工具和方法的实施，都不可能避免地会对团队成员原先的习惯、方式产生影响，需要他们作出改变。尽管从原则上，也许团队成员是认同新工具、新方法的理念的，也是愿意改变的，但是在具体作出改变的，则仍然是会产生各种各样的担心、顾虑，从而影响实施的进度。这种情况下，我们更多采用的是先适应，后改造的方式，即在一些不影响平台实施关键的点上，先去适应开发发布团队当前的工作习惯，从平台方面主动做出一些调整，等开发发布团队尝到收益之后，再反过来影响他们，让他们做出改变和调整，这个时候，往往就相对容易一些了。实施“持续交付”，将会影响整个的研发生命周期，会涉及到流程、团队、工具等多个方面。很可能需要突破当前组织的束缚，引起大量的技术和组织变革。因为，实施“持续交付”需要组织从上到下的认可，需要有大勇气将一些可能属于黑箱操作的工作，公开出来给大家监督。所以，这样的事情很难推进。实施“持续交付”，对实施者和参与者的要求都很高，他们不仅需要了解开发，还要了解流程，了解测试，了解运维，甚至还需要有一定的架构知识和管理知识。实施“持续交付”，大多数团队都希望能够快速见效，立竿见影。但是，“持续交付”的改进过程本身就是一个持续迭代的过程,需要多次循环才能体现效果。甚至在实施的初期，因为开发习惯和流程变化，团队在适应的过程中效率会有暂时的下降。
