CN111610980A - 部署系统及方法 - Google Patents

Abstract

本发明提供了部署系统及方法，部署在内网中的Gitlab服务器，部署在公有云中的Jenkins服务器、打包服务器和Ansible服务器；Gitlab服务器，用于当接收到用于部署服务的部署方式时向Jenkins服务器推送第一回调请求，以使Jenkins服务器从Gitlab服务器中拉取部署方式；当接收到业务代码时向Jenkins服务器推送第二回调请求；以使Jenkins服务器调用部署方式执行：从Gitlab服务器中拉取业务代码，获取与服务相关联的关联参数，并将业务代码和关联参数推送给打包服务器，以使打包服务器对业务代码进行打包处理得到打包后的服务，将服务和关联参数推送给Ansible服务器；Ansible服务器，用于按照关联参数将服务部署到目标位置处。本方案减少CICD过程中的人工干预。

Description

部署系统及方法

技术领域

本发明涉及计算机技术领域，特别涉及部署系统及方法。

背景技术

目前，很多企业有本地的内网服务器环境、云上的业务服务器环境，服务的开发部署环境复杂，对服务的部署和交付的要求及场景越来越高，服务的持续交付和持续部署几乎要成为运维要求的必备技能，也对其稳定性，可靠性，灵活性有了很高的要求。

申请号CN201410680952.2，公开的一种外网穿透内网访问web应用的方法中，公开了通过在未开放外网IP的内部局域网服务器的shell中执行ngrok命令，在该服务器上生成一个指定端口的二级域名；外网通过该二级域名，直接访问该局域网服务器上部署的网站。

申请号CN201811443662.0，公开的一种基于Jenkins和Gitlab的持续集成平台构建方法中，公开了通过定制Jenkins的界面，根据CPU利用率、内容空闲度以及磁盘容量自动推荐Agent；根据环境配置制作容器镜像，定制后的插件读取第一配置文件后，根据需求自动读取第二配置文件以及第三配置文件；所述Gitlab用于存储代码，进行版本控制，所述Jenkins执行生成App的指令，并将所述执行生成App的指令推送到远程仓库。

通过上述描述可见，现在的持续集成持续交付CICD过程中，有的代码使用SVN进行管理，有的开发本地打好包之后发给运维后再手动进行部署，有的在服务器上手动执行脚本进行打包和部署，上述几种方式均存在CICD过程中人工干预过多的情况。

发明内容

本发明实施例提供了部署系统及方法，减少CICD过程中的人工干预。

第一方面，本发明提供了部署系统，Gitlab服务器、Jenkins服务器、打包服务器和Ansible服务器；

所述Gitlab服务器部署在内网中，所述Jenkins服务器、所述打包服务器和所述Ansible服务器部署在公有云中；

所述Gitlab服务器，用于当接收到用于部署服务的部署方式时，向所述Jenkins服务器推送第一回调请求，当接收到业务代码时，向所述Jenkins服务器推送第二回调请求；

所述Jenkins服务器，用于当接收到所述第一回调请求时，从所述Gitlab服务器中拉取所述部署方式，当接收到所述第二回调请求时，调用所述部署方式执行：从所述Gitlab服务器中拉取所述业务代码，获取与所述服务相关联的关联参数，并将所述业务代码和所述关联参数推送给所述打包服务器；

所述打包服务器，用于对接收到的所述业务代码进行打包处理，得到打包后的服务，将所述服务和所述关联参数推送给Ansible服务器；

所述Ansible服务器，用于按照所述关联参数将所述服务部署到目标位置处。

优选地，

所述部署系统进一步包括：用于与所述Gitlab服务器的数据输出端口和所述Jenkins服务器的数据输入端口相连接的Ngrok服务器；

所述Ngrok服务器部署在所述公有云中；

所述Gitlab服务器，用于通过所述Ngrok服务器向所述Jenkins服务器推送所述第一回调请求和所述第二回调请求；

所述Jenkins服务器，用于通过所述Ngrok服务器从所述Gitlab服务器中拉取所述部署方式和所述业务代码。

优选地，

当所述打包服务器包括：Maven服务器时，

所述Maven服务器，用于在所述服务对应Facade项目时，按照所述关联参数将所述服务推送至预设的Maven私库，在所述服务对应Service项目时，将所述服务和所述关联参数推送给Ansible服务器。

优选地，

所述Ansible服务器，进一步用于将所述关联参数写入到预设的部署脚本中，调用写入所述关联参数后的所述部署脚本将所述服务部署到目标位置处。

优选地，

所述Jenkins服务器，用于从所述Jenkins服务器的环境变量中获取与所述服务相关联的第一参数，从所述服务的配置文件中获取第二参数，并将所述第一参数和所述第二参数作为关联参数。

优选地，

所述部署方式包括：Jenkins插件、Shell脚本或pipeline脚本。

第二方面，本发明提供了部署方法，包括：

将Gitlab服务器部署在内网中，并将Jenkins服务器、打包服务器和Ansible服务器部署在公有云中；

通过所述Gitlab服务器，当接收到用于部署服务的部署方式时，向所述Jenkins服务器推送第一回调请求；

通过所述Jenkins服务器，当接收到所述第一回调请求时，从所述Gitlab服务器中拉取所述部署方式；

通过所述Gitlab服务器，当接收到业务代码时，向所述Jenkins服务器推送第二回调请求；

通过所述Jenkins服务器，当接收到所述第二回调请求时，调用所述部署方式执行：从所述Gitlab服务器中拉取所述业务代码，获取与所述服务相关联的关联参数，并将所述业务代码和所述关联参数推送给所述打包服务器；

通过所述打包服务器，对接收到的所述业务代码进行打包处理，得到打包后的服务，将所述服务和所述关联参数推送给Ansible服务器；

通过所述Ansible服务器，按照所述关联参数将所述服务部署到目标位置处。

优选地，

进一步包括：

将Ngrok服务器部署在所述公有云中，其中，所述Ngrok服务器分别与Gitlab服务器的数据输出端口和所述Jenkins服务器的数据输入端口相连接；

所述向所述Jenkins服务器推送第一回调请求，包括：

通过所述Ngrok服务器向所述Jenkins服务器推送第一回调请求；

所述从所述Gitlab服务器中拉取所述部署方式，包括：

通过所述Ngrok服务器从所述Gitlab服务器中拉取所述部署方式；

所述向所述Jenkins服务器推送第二回调请求，包括：

通过所述Ngrok服务器向所述Jenkins服务器推送第二回调请求；

所述从所述Gitlab服务器中拉取所述业务代码，获取与所述服务相关联的关联参数，包括：

通过所述Ngrok服务器从所述Gitlab服务器中拉取所述业务代码。

优选地，

当所述打包服务器包括：Maven服务器时，

所述通过所述打包服务器，对接收到的所述业务代码进行打包处理，得到打包后的服务，将所述服务和所述关联参数推送给Ansible服务器，包括：

通过所述Maven服务器，在所述服务对应Facade项目时，按照所述关联参数将所述服务推送至预设的Maven私库，在所述服务对应Service项目时，将所述服务和所述关联参数推送给Ansible服务器。

优选地，

所述按照所述关联参数将所述服务部署到目标位置处，包括：

将所述关联参数写入到预设的部署脚本中；

调用写入所述关联参数后的所述部署脚本将所述服务部署到目标位置处。

优选地，

所述获取与所述服务相关联的关联参数，包括：

从所述Jenkins服务器的环境变量中获取与所述服务相关联的第一参数；

从所述服务的配置文件中获取第二参数，并将所述第一参数和所述第二参数作为关联参数；

优选地，

所述部署方式包括：Jenkins插件、Shell脚本或pipeline脚本。

本发明实施例提供了部署系统及方法，为了便于业务人员提交代码，提高代码安全，Gitlab服务器部署在内网环境中，便于业务人员向Gitlab服务器提交代码。若Gitlab服务器接收到部署服务时所用的部署方式或者业务代码是，则触发Jenkins服务器的回调机制，使得Jenkins服务器从Gitlab服务器中拉取部署方式和业务代码到Jenkins服务器内。当Jenkins服务器拉取到部署方式，则执行该部署方式，以使在Gitlab服务器接收到业务代码后，调用部署方式拉取业务代码，并获取与业务代码相关联的关联参数，然后推送给打包服务器，以使打包服务器对业务代码进行打包得到服务，再由Ansible服务器将打包后的服务按照关联参数部署到目标位置处，完成CICD流程，减少人工干预，实现CICD更智能、更灵活的部署目的。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明一实施例提供的部署系统的结构示意图；

图2是本发明另一实施例提供的部署系统的结构示意图；

图3是本发明又一实施例提供的部署系统的结构示意图；

图4是本发明一实施例提供的部署方法的流程图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例，基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

如图1所示，本发明实施例提供了部署系统，包括：Gitlab服务器101、Jenkins服务器102、打包服务器103和Ansible服务器104；

所述Gitlab服务器101部署在内网中，所述Jenkins服务器102、所述打包服务器103和所述Ansible服务器104部署在公有云中；

所述Gitlab服务器101，用于当接收到用于部署服务的部署方式时，向所述Jenkins服务器102推送第一回调请求，当接收到业务代码时，向所述Jenkins服务器102推送第二回调请求；

所述Jenkins服务器102，用于当接收到所述第一回调请求时，从所述Gitlab服务器101中拉取所述部署方式，当接收到所述第二回调请求时，调用所述部署方式执行：从所述Gitlab服务器101中拉取所述业务代码，获取与所述服务相关联的关联参数，并将所述业务代码和所述关联参数推送给所述打包服务器；

所述打包服务器103，用于对接收到的所述业务代码进行打包处理，得到打包后的服务，将所述服务和所述关联参数推送给Ansible服务器104；

所述Ansible服务器104，用于按照所述关联参数将所述服务部署到目标位置处。

在本发明实施例中，为了便于业务人员提交代码，提高代码安全，Gitlab服务器部署在内网环境中，便于业务人员向Gitlab服务器提交代码。若Gitlab服务器接收到部署服务时所用的部署方式或者业务代码是，则触发Jenkins服务器的回调机制，使得Jenkins服务器从Gitlab服务器中拉取部署方式和业务代码到Jenkins服务器内。当Jenkins服务器拉取到部署方式，则执行该部署方式，以使在Gitlab服务器接收到业务代码后，调用部署方式拉取业务代码，并获取与业务代码相关联的关联参数，然后推送给打包服务器，以使打包服务器对业务代码进行打包得到服务，再由Ansible服务器将打包后的服务按照关联参数部署到目标位置处，完成CICD流程，减少人工干预，实现CICD更智能、更灵活的部署目的。

具体地，所述部署方式包括：Jenkins插件、Shell脚本或pipeline脚本。

如图2所示，为了使得在公有云中的Jenkins服务器能够访问内网中的Gitlab服务器，在本发明一实施例中，所述部署系统进一步包括：用于与所述Gitlab服务器的数据输出端口和所述Jenkins服务器的数据输入端口相连接的Ngrok服务器201；

所述Ngrok服务器201部署在所述公有云中；

所述Gitlab服务器101，用于通过所述Ngrok服务器201向所述Jenkins服务器102推送所述第一回调请求和所述第二回调请求；

所述Jenkins服务器102，用于通过所述Ngrok服务器201从所述Gitlab服务器101中拉取所述部署方式和所述业务代码。

在本发明实施例中，由于业务人员提交的代码通常较小，如30兆、50兆、80兆等，因此，可通过Ngrok服务器打通公有云和内网的通信问题，即将Ngrok服务器分别与Gitlab服务器的数据输出端口和Jenkins服务器的数据输入端口连接，以使Gitlab服务器与Jenkins服务器通过Ngrok服务器进行数据交互。

为了保证内网中的代码的安全性，Gitlab服务器的数据输出端口需要在能够与Jenkins服务器进行数据交互的白名单中。

为了将服务部署在指定的位置，在本发明一实施例中，当所述打包服务器包括：Maven服务器时，

所述Maven服务器，用于在所述服务对应Facade项目时，按照所述关联参数将所述服务推送至预设的Maven私库，在所述服务对应Service项目时，将所述服务和所述关联参数推送给Ansible服务器。

在本发明实施例中，可以通过Maven服务器对Jenkins服务器拉取到的业务代码进行打包得到服务。由于不同的服务对应的项目不同，不同的项目依赖的库不同，因此，当服务为Facade项目时Maven服务器则将服务推送至Maven私库，以通过Maven私库对服务进行部署。若服务为Service项目，则通过Ansible服务器对服务进行部署。

为了完成服务的部署，在本发明一实施例中，所述Ansible服务器，进一步用于将所述关联参数写入到预设的部署脚本中，调用写入所述关联参数后的所述部署脚本将所述服务部署到目标位置处。

在本发明实施例中，在部署某项目的业务代码时，Jenkins服务器调用部署方式在获取到用于部署业务代码时所用的关联参数后，再将关联参数写入到Ansible服务器预设的部署脚本内，Ansible服务器即可通过调用该部署脚本对服务进行部署，实现对不同项目的服务的部署工作，减少部署服务时的人工干预。

为了保证能够将服务部署到目标位置，在本发明一实施例中，所述Jenkins服务器，用于从所述Jenkins服务器的环境变量中获取与所述服务相关联的第一参数，从所述服务的配置文件中获取第二参数，并将所述第一参数和所述第二参数作为关联参数。

在本发明实施例中，Jenkins服务器在调用部署方式拉取到业务代码过程后，部署方式会按照预设的配置信息，获取业务代码传递过程中的关联参数，例如，业务代码对应的项目名、应用名、业务代码在Gitlab服务器上的文件夹名、打包后的服务的包名、拉取的业务代码对应的分支名、读取的配置文件名(也就是所要部署的环境名)等，然后按照配置信息对上述关联参数进行排序。

例如，获取到的关联参数依次为：superapp(项目名)+superapp-service-device(应用名，Gitlab服务器上的文件夹名，业务代码打包后的jar包名)+develop(拉取的代码分支名)+dev(读取的配置文件名，也就是部署环境名)。

可以理解的是，本发明实施例示意的结构并不构成对部署系统的具体限定。在本发明的另一些实施例中，部署系统可以包括比图示更多或者更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件、软件或者软件和硬件的组合来实现。

上述装置内的各单元之间的信息交互、执行过程等内容，由于与本发明方法实施例基于同一构思，具体内容可参见本发明方法实施例中的叙述，此处不再赘述。

如图3所示，为了更加清楚地说明本发明的技术方案及优点，下面以部署方式为pipeline脚本的为例，对本发明实施例提供的部署系统进行详细说明，具体可以包括：

部署在内网中的Gitlab服务器301，部署在公有云中的Ngrok服务器302、Jenkins服务器303、Maven服务器304和Ansible服务器305；

Ngrok服务器302分别与Gitlab服务器301的数据输出端口和Jenkins服务器303的数据输入端口相连接。

具体地，为了保证业务人员提交的各种类型的代码的安全，将用于管理代码的Gitlab服务器部署在内网中。为了便于Jenkins服务器将Gitlab服务器中的代码拉取到公有云中，Jenkins服务器部署在公有云中，为了便于对Jenkins服务器拉取的业务代码进行打包、部署，Maven服务器和Ansible服务器也部署在公有云中。为了便于位于内网中的Gitlab服务器和位于公有云中的Jenkins服务器能够进行数据交互，可在公有云中部署Ngrok服务器，以打通公有云和内网的通信问题。

Gitlab服务器301，用于当接收到用于部署服务的pipeline脚本时，通过Ngrok服务器302向Jenkins服务器303推送第一回调请求。

Jenkins服务器303，用于当接收到第一回调请求时，通过Ngrok服务器302从Gitlab服务器301中拉取pipeline脚本。

具体地，对于部署需求复杂多变，经常会变换分支，多处启动几套环境同时测试等情况时，为了部署的可靠性和灵活性，业务人员可针对要部署的项目配置对应的pipeline脚本，并将pipeline脚本上传至Gitlab服务器，这样Gitlab服务器即可触发Jenkins服务器的回调机制，以使Jenkins服务器通过Gitlab服务器拉取pipeline脚本，并执行pipeline脚本。

Gitlab服务器301，用于当接收到业务代码时，通过Ngrok服务器302向Jenkins服务器303推送第二回调请求。

Jenkins服务器303，用于当接收到第二回调请求时，调用pipeline脚本通过Ngrok服务器302从Gitlab服务器301中拉取业务代码。从Jenkins服务器的环境变量中获取与服务相关联的第一参数，从服务的配置文件中获取第二参数，并将第一参数和第二参数作为关联参数，并将业务代码和关联参数推送给Maven服务器304。

具体地，当业务人员向Gitlab服务器上传待部署的业务代码后，Gitlab服务器可再次触发Jenkins服务器的回调机制，Jenkins服务器通过调用pipeline脚本，确定Gitlab服务器中的业务代码所在的位置、对应的项目名、对应的应用名、业务代码打包后的包名、所要部署的环境名等关联信息，然后通过Ngrok服务器将业务代码拉取自身的服务器内，并推送给Maven服务器。

Maven服务器304，用于对接收到的业务代码进行打包处理，得到打包后的服务。在服务对应Facade项目时，按照关联参数将服务推送至预设的Maven私库306；在服务对应Service项目时，将服务和关联参数推送给Ansible服务器305。

具体地，当Jenkins服务器拉取到业务代码后，Maven服务器可对业务代码进行打包处理，形成待部署的服务。对于不同项目的服务所要部署的环境有可能不同，例如，有的服务需要将其放置指定的环境里运行即可。因此，若打包后的服务为Facade项目的服务，则将服务推送至Maven私库，以通过Maven私库进行部署，若服务Service项目的服务，则推送给Ansible服务器，以通过Ansible服务器进行远程部署。

Ansible服务器305，用于将关联参数写入到预设的部署脚本中，调用写入关联参数后的部署脚本将服务部署到目标位置处。

具体地，若需要Ansible服务器部署服务，需要先将服务对应的关联参数写入到Ansible服务器的部署脚本内，以便确定服务所要部署的服务器、部署的服务器的数量等信息，然后调用写入关联参数后的部署脚本即可对服务进行部署。

通过上述描述可见，本方案可以减少Jenkins任务的配置，减少人工干预，快速部署一套环境出来，只需根据脚本对任务名的匹配，复制一个Jenkins项目并改一下任务名，然后配置上部署的一些参数，比如应用拉取配置的环境、服务器ip、服务启动格式、服务配置的内存参数等等。并且Pipeline脚本执行时会把Ansible服务器上需要的参数全部带过来给部署脚本再次使用，比如服务启动个数、运行环境、部署路径、启动参数等等，自定义性非常强，可以满足绝大部署场景的部署使用。本方案可以实现CICD自动化部署过程中人工介入过多、不智能、不可靠、不灵活等部署问题。

图3中还示出了Maven私库306，以及3个目标位置对应的目标服务器307。

如图4所示，本发明实施例还提供了部署方法，包括：

步骤401：将Gitlab服务器部署在内网中，并将Jenkins服务器、打包服务器和Ansible服务器部署在公有云中；

步骤402：通过所述Gitlab服务器，当接收到用于部署服务的部署方式时，向所述Jenkins服务器推送第一回调请求；

步骤403：通过所述Jenkins服务器，当接收到所述第一回调请求时，从所述Gitlab服务器中拉取所述部署方式；

步骤404：通过所述Gitlab服务器，当接收到业务代码时，向所述Jenkins服务器推送第二回调请求；

步骤405：通过所述Jenkins服务器，当接收到所述第二回调请求时，调用所述部署方式执行：从所述Gitlab服务器中拉取所述业务代码，获取与所述服务相关联的关联参数，并将所述业务代码和所述关联参数推送给所述打包服务器；

步骤406：通过所述打包服务器，对接收到的所述业务代码进行打包处理，得到打包后的服务，将所述服务和所述关联参数推送给Ansible服务器；

步骤407：通过所述Ansible服务器，按照所述关联参数将所述服务部署到目标位置处。

在本发明实施例中，为了便于业务人员提交代码，提高代码安全，Gitlab服务器部署在内网环境中，便于业务人员向Gitlab服务器提交代码。若Gitlab服务器接收到部署服务时所用的部署方式或者业务代码是，则触发Jenkins服务器的回调机制，使得Jenkins服务器从Gitlab服务器中拉取部署方式和业务代码到Jenkins服务器内。当Jenkins服务器拉取到部署方式，则执行该部署方式，以使在Gitlab服务器接收到业务代码后，调用部署方式拉取业务代码，并获取与业务代码相关联的关联参数，然后推送给打包服务器，以使打包服务器对业务代码进行打包得到服务，再由Ansible服务器将打包后的服务按照关联参数部署到目标位置处，完成CICD流程，减少人工干预，实现CICD更智能、更灵活的部署目的。

在本发明一实施例中，进一步包括：

将Ngrok服务器部署在所述公有云中，其中，所述Ngrok服务器分别与Gitlab服务器的数据输出端口和所述Jenkins服务器的数据输入端口相连接；

所述向所述Jenkins服务器推送第一回调请求，包括：

通过所述Ngrok服务器向所述Jenkins服务器推送第一回调请求；

所述从所述Gitlab服务器中拉取所述部署方式，包括：

通过所述Ngrok服务器从所述Gitlab服务器中拉取所述部署方式；

所述向所述Jenkins服务器推送第二回调请求，包括：

通过所述Ngrok服务器向所述Jenkins服务器推送第二回调请求；

所述从所述Gitlab服务器中拉取所述业务代码，获取与所述服务相关联的关联参数，包括：

通过所述Ngrok服务器从所述Gitlab服务器中拉取所述业务代码。

在本发明一实施例中，当所述打包服务器包括：Maven服务器时，

所述通过所述打包服务器，对接收到的所述业务代码进行打包处理，得到打包后的服务，将所述服务和所述关联参数推送给Ansible服务器，包括：

通过所述Maven服务器，在所述服务对应Facade项目时，按照所述关联参数将所述服务推送至预设的Maven私库，在所述服务对应Service项目时，将所述服务和所述关联参数推送给Ansible服务器。

在本发明一实施例中，所述按照所述关联参数将所述服务部署到目标位置处，包括：

将所述关联参数写入到预设的部署脚本中；

调用写入所述关联参数后的所述部署脚本将所述服务部署到目标位置处。

在本发明一实施例中，所述获取与所述服务相关联的关联参数，包括：

从所述Jenkins服务器的环境变量中获取与所述服务相关联的第一参数；

从所述服务的配置文件中获取第二参数，并将所述第一参数和所述第二参数作为关联参数。

在本发明一实施例中，所述部署方式包括：Jenkins插件、Shell脚本或pipeline脚本。

需要说明的是，上述各流程和各系统结构图中不是所有的步骤和模块都是必须的，可以根据实际的需要忽略某些步骤或模块。各步骤的执行顺序不是固定的，可以根据需要进行调整。上述各实施例中描述的系统结构可以是物理结构，也可以是逻辑结构，即，有些模块可能由同一物理实体实现，或者，有些模块可能分由多个物理实体实现，或者，可以由多个独立设备中的某些部件共同实现。

以上各实施例中，硬件单元可以通过机械方式或电气方式实现。例如，一个硬件单元可以包括永久性专用的电路或逻辑(如专门的处理器，FPGA或ASIC)来完成相应操作。硬件单元还可以包括可编程逻辑或电路(如通用处理器或其它可编程处理器)，可以由软件进行临时的设置以完成相应操作。具体的实现方式(机械方式、或专用的永久性电路、或者临时设置的电路)可以基于成本和时间上的考虑来确定。

上文通过附图和优选实施例对本发明进行了详细展示和说明，然而本发明不限于这些已揭示的实施例，基与上述多个实施例本领域技术人员可以知晓，可以组合上述不同实施例中的代码审核手段得到本发明更多的实施例，这些实施例也在本发明的保护范围之内。

Claims (10)

1.部署系统，其特征在于，Gitlab服务器、Jenkins服务器、打包服务器和Ansible服务器；

所述Gitlab服务器部署在内网中，所述Jenkins服务器、所述打包服务器和所述Ansible服务器部署在公有云中；

所述Gitlab服务器，用于当接收到用于部署服务的部署方式时，向所述Jenkins服务器推送第一回调请求，当接收到业务代码时，向所述Jenkins服务器推送第二回调请求；

所述Jenkins服务器，用于当接收到所述第一回调请求时，从所述Gitlab服务器中拉取所述部署方式，当接收到所述第二回调请求时，调用所述部署方式执行：从所述Gitlab服务器中拉取所述业务代码，获取与所述服务相关联的关联参数，并将所述业务代码和所述关联参数推送给所述打包服务器；

所述打包服务器，用于对接收到的所述业务代码进行打包处理，得到打包后的服务，将所述服务和所述关联参数推送给Ansible服务器；

所述Ansible服务器，用于按照所述关联参数将所述服务部署到目标位置处。

2.根据权利要求1所述的部署系统，其特征在于，所述部署系统进一步包括：用于与所述Gitlab服务器的数据输出端口和所述Jenkins服务器的数据输入端口相连接的Ngrok服务器；

所述Ngrok服务器部署在所述公有云中；

所述Gitlab服务器，用于通过所述Ngrok服务器向所述Jenkins服务器推送所述第一回调请求和所述第二回调请求；

所述Jenkins服务器，用于通过所述Ngrok服务器从所述Gitlab服务器中拉取所述部署方式和所述业务代码。

3.根据权利要求1所述的部署系统，其特征在于，

当所述打包服务器包括：Maven服务器时，

所述Maven服务器，用于在所述服务对应Facade项目时，按照所述关联参数将所述服务推送至预设的Maven私库，在所述服务对应Service项目时，将所述服务和所述关联参数推送给Ansible服务器。

4.根据权利要求1所述的部署系统，其特征在于，

所述Ansible服务器，进一步用于将所述关联参数写入到预设的部署脚本中，调用写入所述关联参数后的所述部署脚本将所述服务部署到目标位置处。

5.根据权利要求1至4中任一所述的部署系统，其特征在于，

所述Jenkins服务器，用于从所述Jenkins服务器的环境变量中获取与所述服务相关联的第一参数，从所述服务的配置文件中获取第二参数，并将所述第一参数和所述第二参数作为关联参数；

和/或，

所述部署方式包括：Jenkins插件、Shell脚本或pipeline脚本。

6.部署方法，其特征在于，包括：

将Gitlab服务器部署在内网中，并将Jenkins服务器、打包服务器和Ansible服务器部署在公有云中；

通过所述Gitlab服务器，当接收到用于部署服务的部署方式时，向所述Jenkins服务器推送第一回调请求；

通过所述Jenkins服务器，当接收到所述第一回调请求时，从所述Gitlab服务器中拉取所述部署方式；

通过所述Gitlab服务器，当接收到业务代码时，向所述Jenkins服务器推送第二回调请求；

通过所述Jenkins服务器，当接收到所述第二回调请求时，调用所述部署方式执行：从所述Gitlab服务器中拉取所述业务代码，获取与所述服务相关联的关联参数，并将所述业务代码和所述关联参数推送给所述打包服务器；

通过所述打包服务器，对接收到的所述业务代码进行打包处理，得到打包后的服务，将所述服务和所述关联参数推送给Ansible服务器；

通过所述Ansible服务器，按照所述关联参数将所述服务部署到目标位置处。

7.根据权利要求6所述的部署方法，其特征在于，进一步包括：

将Ngrok服务器部署在所述公有云中，其中，所述Ngrok服务器分别与Gitlab服务器的数据输出端口和所述Jenkins服务器的数据输入端口相连接；

所述向所述Jenkins服务器推送第一回调请求，包括：

通过所述Ngrok服务器向所述Jenkins服务器推送第一回调请求；

所述从所述Gitlab服务器中拉取所述部署方式，包括：

通过所述Ngrok服务器从所述Gitlab服务器中拉取所述部署方式；

所述向所述Jenkins服务器推送第二回调请求，包括：

通过所述Ngrok服务器向所述Jenkins服务器推送第二回调请求；

所述从所述Gitlab服务器中拉取所述业务代码，获取与所述服务相关联的关联参数，包括：

通过所述Ngrok服务器从所述Gitlab服务器中拉取所述业务代码。

8.根据权利要求6所述的部署方法，其特征在于，

当所述打包服务器包括：Maven服务器时，

所述通过所述打包服务器，对接收到的所述业务代码进行打包处理，得到打包后的服务，将所述服务和所述关联参数推送给Ansible服务器，包括：

通过所述Maven服务器，在所述服务对应Facade项目时，按照所述关联参数将所述服务推送至预设的Maven私库，在所述服务对应Service项目时，将所述服务和所述关联参数推送给Ansible服务器。

9.根据权利要求6所述的部署方法，其特征在于，

所述按照所述关联参数将所述服务部署到目标位置处，包括：

将所述关联参数写入到预设的部署脚本中；

调用写入所述关联参数后的所述部署脚本将所述服务部署到目标位置处。

10.根据权利要求6至9中任一所述的部署方法，其特征在于，

所述获取与所述服务相关联的关联参数，包括：

从所述Jenkins服务器的环境变量中获取与所述服务相关联的第一参数；

从所述服务的配置文件中获取第二参数，并将所述第一参数和所述第二参数作为关联参数；

和/或，

所述部署方式包括：Jenkins插件、Shell脚本或pipeline脚本。

Images