行业资讯

  • 首页
  • 新闻中心
  • 行业资讯

持续集成服务器部署策略-宇众网络科技服务器租用-高防服务器租用


2019年07月09日

   在软件交付领域上有一个非常有用的启发式原则:提前并频繁地做让你感到痛苦的事。集成通常是一个非常痛苦的过程,所以每次有人提交代码后应立刻进行集成。

 马丁福勒说:持续集成是一种软件开发实践,即团队开发成员经常集成他们的工作,通过每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽早地发现集成错误。

而持续集成服务器(也称为构建服务器,又称CI服务器)是一种软件工具,它包含所有持续集成操作,并为我们构建项目提供可靠和稳定的环境。

工欲善其事,必先利其器。持续集成的重要性毋庸置疑,但是理解如何创建安全、高效、可伸缩的持续集成服务器将使得持续集成更加顺畅。

CI服务器 - 安装方式

CI服务器的安装方式有四种:

  • 单机
    单机的CI服务器即安装在一台单个主机上,通常用于小型项目。

  • 托管
    托管的CI服务器由托管平台提供,一般是根据订阅计价。这一般被那些不想维护CI服务器的企业所采纳。

  • 私有云
    一些大型企业或者想要完全掌控及安全使用他们自己的基础设施的组织,通常会选择私有云的部署方式。

  • 半托管半私有云
    这种方式是对托管部署和私有云部署的折中方案。这种部署方式通常将流水线管理,日志管理,用户管理部分进行托管,而将流水线运行时环境放在私有云中。这种方式即保证了基础设施安全,同时也降低了维护CI服务器的成本。

我所在的团队最初使用私有云的方式搭建CI服务器,但出于可维护性、成本和安全性等方面的折中考虑转向了半托管半私有云的安装方式。本文将主要讨论在私有云和半托管半私有云安装方式下CI服务器的部署策略。

CI服务器 - 主从架构

主从架构也叫主仆架构或者Master-Slave架构,主从式架构意图提供一个可伸缩的架构,其核心是基于分而治之的思想,将一个原始任务分解为若干个子任务,并由专门的工作者来执行这些任务,原始任务的结通过整合各个子任务的处理结果形成。

主从架构看似与CI服务器毫无关系,实则联系紧密。因为很多CI服务器使用了主从架构或者服务器/代理架构。通过主从架构的Master可以进行用户管理、流水线管理、日志管理。Master作为任务调度者,给多个主从架构的Slave分配任务,Slave会将流水线任务运行的信息和结果发给Master。主从架构提供了一个可伸缩的架构,所以可以动态的添加或者删除Slave以支持团队动态变化的持续集成任务。

CI服务器 - 部署策略

通常,一个开发团队会有三个应用部署环境:开发环境(Dev),类生产环境(Staging)和生产环境(Production)。当一次修改通过持续集成后,就会被部署到开发环境,然后部署到类生产环境,然后部署到生产环境。

为此,需要CI服务器具有操作相应部署环境的权限。如图2,开发环境中部署了CI服务器,其中每个CI服务器都具有开发、类生产和生产环境的权限。

图2

这种方式粗暴简单,看似药到病除实质上却会引发很严重的安全问题。通常项目中对开发、类生产和生产环境权限的管控类似于金字塔,越往上权限管控越严格。但如果开发环境的CI服务器也具有类生产和生产环境的权限,那么这座本来坚固的金字塔将有可能瞬间崩塌。

为了解决开发环境CI服务器具有多环境操作权限的问题,如图3所示,可以在不同的环境独立部署一套CI服务器,这样部署某个环境时,就可以使用相应环境的CI服务器即可。

但随之而来的问题是,不同的环境独立部署一套CI服务器,会使得每个环境的CI服务器之间没有任何关系。它们的流水线管理,日志管理,用户管理都是独立的。这意味着原本一个流水线完成的事情会分散的对个多个持续集成系统中,用户需要在多个系统中来回切换。这不仅降低了使用体验,并且增加了复杂性和维护成本。

那么有没有什么办法,既保证只部署一套CI服务器,同时又能保证CI服务器不能跨环境操作?如图4所示,虽然所有的CI服务器依然部署在开发环境中,但每个CI服务器代理已经被打上了开发环境、类生产和生产环境的标签,并且只具有操作相应环境的权限。

这种部署策略看似解决了安全问题,但实际上有点掩耳盗铃,因为只要开发环境上的用户具有足够的权限,他就有可能可以修改CI服务器代理的权限,从而达到操纵其他环境的目的。

既然如此,那么可不可以将CI服务器代理部署到相应的环境中?如图5所示,不同环境将维护相应的CI服务器代理,通过这种部署方式,既保证只部署一套CI服务器,同时又能保证CI服务器代理不能跨环境操作。

 

 


客服