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 机制,可以保障软件项目的有序推荐,保障软件项目的质量。

本文转载自: 中国教育和科研计算机网 CERNET