高校云计算环境下的 DevOps 实践

DevOps 介绍

随着信息化的发展，高校各类业务系统数目繁多，而软件交付的方式也在发生变化。传统的软件系统交付方式是由校方信息化管理部门提供硬件服务器，只负责服务器硬件资源的正常运转和网络访问的畅通云计算 业务系统，而不参与到软件开发生命周期。这种方式在高校信息化发展初期确实非常高效，也弥补了校方人员技术水平不高的缺陷。但是随着信息化的发展，云计算技术的成熟，大数据对教育的变革，尤其是高校信息化需求的变化，各个应用不再是独立的个体，而是整个学校信息化的组件，多个应用之间相辅相成，业务流程交叉，数据流混杂。软件系统个体发展开始向平台化、集成化、统一化发展。这种变化，对于软件开发参与者发生了变化，对校方信息化人员的总体战略和运维也提出了更高的要求。这些变化，要求校方信息化人员与第三方软件供应商协同工作，参与系统部署的环境准备和后续运维。

DevOps（Development 和 Operations 的组合词）是一种重视 “软件开发人员（Dev）” 和 “IT 运维技术人员（Ops）” 之间沟通合作的文化、运动或惯例。透过自动化 “软件交付” 和 “架构变更” 的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。它的出现是由于软件行业日益清晰认识到：为了按时交付软件产品和服务，开发和运营必须紧密合作

如图 1 所示，我们可以把 DevOps 看作开发（软件工程）、技术运营和质量保障（QA）三者的交集传统的软件组织将开发、IT 运营和质量保障设为各自分离的部门，在这种环境下如何采用新的开发方法（例如敏捷软件开发），是一个重要的课题。按照从前的工作方式，开发和部署，不需要 IT 支持或者 QA 深入的跨部门的支持；而现在却需要极其紧密的多部门协作。而 DevOps 考虑的还不止是软件部署，它是一套针对这几个部门间沟通与协作问题的流程和方法。

DevOps 的引入能对产品交付、测试、功能开发和维护起到意义深远的影响。在缺乏 DevOps 能力的组织中，开发与运营之间存在着信息 “鸿沟”──例如运营人员要求更好的可靠性和安全性，开发人员则希望基础设施响应更快，而业务用户的需求则是更快地将更多的特性发布给最终用户使用。这种信息鸿沟就是最常出问题的地方。

云计算技术的发展与局限性

按照 IDC 的研究，2005 年之前是虚拟化技术发展的第一阶段，称之为虚拟化 1.0，从 2005 年到 2010 年时虚拟化发展的第二阶段，称之为虚拟化 2.0，目前已经进入虚拟化 2.5 阶段，虚拟化 3.0 阶段在不久也将会到来。根据 Gartner 的预测，目前中国 70% 的 X86 企业服务器将实现虚拟化。而高校核心机房的虚拟化发展更是如此，几乎每个高校都在利用虚拟化部署应用系统，每个高校部署了私有云。

CPU 的虚拟化技术将计算能力作为资源，VxLAN 技术将网络作为资源，而各种分布式文件系统则将存储作为资源。以上几种资源都可以通过私有云来进行自助申请、使用以及归还。

目前 IaaS 在高校云计算中得到了实现和部署，信息化部门可以使用商业虚拟化软件管理各类虚拟化资源，并允许用户自助申请。但 IaaS 的可分配的资源粒度限定于虚拟机，还未能细化到服务。PaaS 技术则更加侧重于某个开发平台所用组件为服务，譬如数据库作为服务，或者一整套开发环境作为服务，这种模式强调的是服务的可重用性，高校信息化的多样性决定了这种模式在高校中的局限性。SaaS 是更高端的服务模式，所以云计算的发展给高校带来的最主要的服务模式的变更在于 IaaS，这只是原先主机交付与虚拟机交付的差别，还未升级到对软件交付模式进行改进的高层次变更。

高校云计算环境下的 DevOps 实践

为了改进高校软件交付的模式，我们在近两年的软件系统建设中，优先采用 DevOps 模式，校内项目负责人员、运维人员和第三方软件开发商人员进行了对接，组建新形式的项目组，共同参与项目建设。双方职责因分工不同而侧重点不同。在项目建设中引入了敏捷开发方法，并且要求产品多次交付，具体措施有：

* 使用敏捷或其他软件开发过程与方法；

* 校方要求产品分阶段多次交付，提高产品交付的速率；

* 完善虚拟化和云计算基础设施，保障产品开发运行环境；

* 数据中心拥有自动化技术和配置管理工具。

有了这几项措施，DevOps 增进了开发团队与运营团队之间的协作性、高效性的关系。由于团队间协作关系的改善，整个组织的效率因此得到提升，伴随频繁变化而来的生产环境的风险也能得到降低，并且降低了软件产品开发失败的风险。图 2 为 DevOps 的生命周期路线。

为了正确使用 DevOps 模式，在软件架构中，引入了微服务，并根据基于业务进行拆分、采用自动化文化、去中心化、服务独立部署、服务完全自治、隔离失败、渐进式拆分、避免大规模改造原有代码等原则对业务进行拆分。

结合我们具体的实践，现总结一下在实践 DevOps 模式时需要执行的步骤。

1. 操作系统的限定

目前常用的服务器操作系统有 Windows Server 和 Linux，而软件普遍采用 B/S 架构，因此对于操作系统的需求，主要是为了能够运行 Web 服务器，考虑到目前常用 Web 服务器有微软的 IIS，Apache httpd，Nginx，我们只需要准备 Windows Server 2012 和 CentOS 等 Linux 系统即可。由于我们限定了操作系统，开发组也会提早获知生产运行环境，改变以往软件完成后，校方必须满足软件开发方的需求，造成了多种操作系统的存在。

2. 数据库的限定

现有编程语言，都有成熟的数据持久化工具，而数据持久化工具对于数据库是透明的，它依赖于数据驱动程序，允许用户比较容易的在多种数据库软件中迁移和部署，因此数据库可由校方自主选择决定。比较常见的数据库有 Oracle、Microsoft SQL Server 和 MySQL。其中 Oracle 基本是采取独立于软件部署服务器的方式提供，Microsoft SQL Server 和 MySQL 因为是轻量级的数据库服务系统，可以视软件系统的复杂性决定是否与软件部署在相同的服务器中。

操作系统和数据库的决定，为我们准备虚拟机模板提供了依据。在 DevOps 实践中，我们根据上面几个选项，分别构建了 Windows Server+Microsoft SQL Server 和 CentOS+MySQL 的模板，并让开发方实现知情未来的生产环境，开发方在需求调研阶段依然获知未来的运行环境，有针对性的开发，提高了后续产品的稳定性。

3.Web 服务器的选择

对于 Java 类开发语言，对 Web 服务器的依赖性不强，反而是需要成熟的容器，如 Tomcat、Glassfish、WebLogic Server 等容器。这一方面的选择根据操作系统以及 Java 平台架构限定。若是轻量级的应用，可以选用 Tomcat 容器，也可以根据开发方的熟悉程度由开发方选择，但基本可以限定在 Linux 操作系统。

对于.Net 平台下的 Web 应用，其 Web 服务器必然选择 IIS，其对应的操作系统亦为 Windows Server。由于 Web 服务器都是以软件包的形式存在，其均可以通过命令行方式安装，因此该项没有做进虚拟机模板，而是根据实际情况实时安装。

4. 建立统一的日志规范规范

整个系统而非微服务的日志体系，采用标准的日志格式非常便于后续的日志聚合检索，便于整体的视角分析、监控、查看系统；一旦系统出现问题，运维可以提供详实的日志给开发方，便于问题的查找和解决。鉴于不同的服务器操作系统有不同的日志系统，因为对于虚拟机准备中没有特殊要求。但也可以单独准备 rsyslog 服务器，用于接收从 Linux 服务器发过来的日志。

5. 选择成熟框架

在 DevOps 中，重复使用某个模块是该模式的基础。必须避免自己重复发明轮子，尽量选择市面上成熟的开源技术框架进行支撑，比如 SpringBoot、Spring Cloud、Netflix、WildFly Swarm、Docker、Kubernetes、Bootstrap、CAS 等框架；只有如此，才能减少 DevOps 组的技术负责度，降低运维人员的技术要求。由于使用组件的重复性，运维和开发人员均可以充分熟悉所用组件框架，从而快速发现问题、解决问题。

有了以上的要求，我们还需要建设代码共享库，问题列表库、文档知识库等 DevOps 所必须的支撑，而这些支撑是通过云计算的方式来提供。尤其是新的应用系统建设时，DevOps 中的运维人员，即校方运维人员，可以以同样的架构应用于新的应用系统建设。

由此我们可以总结出如图 3 所示的云计算下的 DevOps 开发模式拓扑图。

在该拓扑结构下，原有私有云运维团队中，需要提升部分工作人员向业务层发展，并控制代码库、知识库和问题库的部署和基本运维管理。在新建项目时，私有云运维团队需要根据项目需要，分配生产环境、测试环境和开发环境给项目组，从而允许项目多次部署、多次交付。

在云计算环境下的 DevOps 要求云计算运维人员不仅是云基础架构管理员，还需要参与到项目组中，了解项目基本信息，因此对于云计算相关人员的定位提出了更明晰的要求。引入 DevOps 机制，可以保障软件项目的有序推荐，保障软件项目的质量。

（编辑：财气旺网 - 财气网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!