CN114691189B - 分布式项目开发处理方法及系统 - Google Patents

Abstract

本申请是关于一种分布式项目开发处理方法及系统。该分布式项目开发处理方法，包括：使用分布式的网络文件系统NFS作为代码目录，通过NFS服务器存储代码；使用容器集群管理系统k8s构建分布式web服务环境，其中所述k8s中将不同的Pod作为不同的web服务器，通过所述k8s中的Pod挂载所述网络文件系统NFS来挂载所述代码。本申请提供的方案，能够提高项目的开发和测试环境的稳定性，降低运维压力。

Description

分布式项目开发处理方法及系统

技术领域

本申请涉及计算机及互联网技术领域，尤其涉及一种分布式项目开发处理方法及系统。

背景技术

相关技术中，目前一般是单点服务器部署开发测试环境，单个分支进行项目的开发和测试，并且针对每个开发和测试域名配置DNS(Domain Name System，域名系统)解析。当多个互相联系的项目的开发测试环境放到一台服务器上，如果该台服务器崩溃，则影响到公司所有业务的开发和测试流程，影响很大，可能因为服务器崩溃并且修复时间过久，导致业务开发团队长时间无法正常工作。

因此，相关技术的项目开发处理方法，开发和测试环境的稳定性有待改善。

发明内容

为克服相关技术中存在的问题，本申请提供一种分布式项目开发处理方法及系统，能够提高项目的开发和测试环境的稳定性，降低运维压力。

本申请第一方面提供一种分布式项目开发处理方法，包括：

使用分布式的网络文件系统NFS作为代码目录，通过NFS服务器存储代码；

使用容器集群管理系统k8s构建分布式web服务环境，其中所述k8s中将不同的Pod作为不同的web服务器，通过所述k8s中的Pod挂载所述网络文件系统NFS来挂载所述代码。

在一种实施方式中，所述方法还包括：

在所述Pod通过联合文件系统mergerfs来创建各个分支的web目录。

在一种实施方式中，所述方法还包括：

在所述Pod基于DNSmasq配置正则通配的域名规则，按照所述域名规则为不同的分支各分配域名。

在一种实施方式中，所述方法还包括：

设置GitLab作为远程代码仓库，通过Gitlab CI进行持续代码部署。

在一种实施方式中，所述方法还包括：

在用户端将创建的分支及代码推送到所述远程代码仓库后，通过Gitlab CI调用GitLab-Runner运行设定命令，将所述代码传输给所述NFS服务器上对应的代码分支挂载目录。

在一种实施方式中，所述通过Gitlab CI调用GitLab-Runner运行设定命令，将所述代码传输给所述NFS服务器上对应的代码分支挂载目录，包括：

通过Gitlab CI调用所述Pod上的GitLab-Runner运行代码拉取命令，将所述代码拉取到NFS服务器上对应的代码分支挂载目录。

本申请第二方面提供一种分布式项目系统：

包括NFS服务器和容器集群管理系统k8s，其中所述k8s中包括不同的Pod，不同的Pod作为不同的web服务器；

NFS服务器，用于使用分布式的网络文件系统NFS作为代码目录，通过NFS服务器存储代码；

容器集群管理系统k8s，用于构建分布式web服务环境，通过所述k8s中的Pod挂载所述网络文件系统NFS来挂载所述代码。

在一种实施方式中，所述k8s中的Pod通过联合文件系统mergerfs来创建各个分支的web目录。

在一种实施方式中，所述k8s中的Pod基于DNSmasq配置正则通配的域名规则，按照所述域名规则为不同的分支各分配域名。

在一种实施方式中，所述k8s中的Pod在用户端将创建的分支及代码推送到远程代码仓库后，通过Gitlab CI调用所述Pod上的GitLab-Runner运行设定命令，将所述代码传输给所述NFS服务器上对应的代码分支挂载目录。

本申请提供的技术方案可以包括以下有益效果：

本申请实施例示出的方案，使用分布式的NFS(Network File System，网络文件系统)作为代码目录并通过NFS服务器存储代码，使用容器集群管理系统k8s构建分布式web服务环境，并通过k8s中的Pod挂载所述网络文件系统NFS来挂载所述代码，即将NFS挂载到分布式的web服务器上(即k8s中的Pod上)，也就是说本申请实施例使用了NFS网络存储部署代码和分布式web服务器挂载代码的方案。由于NFS是一种网络存储协议，所以多个Pod可以同时分布式地挂载NFS目录，这样就避免了单点服务器存在的问题，使得开发和测试环境的稳定性大大提高，多分支的开发和测试流程也比单分支流程更加稳健和高效，也可以降低运维的压力。

进一步的，本申请实施例方案使用联合文件系统mergerfs，对于某个功能分支但没有实际建立分支的项目，可以节省代码的存储空间。也就是说，使用联合文件系统mergerfs来创建各个分支的web目录，实际上是覆盖了实际分支代码目录和主分支的代码目录，可以达到节省存储空间和部署时间的目的。

进一步的，本申请实施例方案基于DNSmasq配置正则通配的域名规则，按照所述域名规则为不同的分支各分配域名，也就是说是使用了正则表达式来做DNS解析的方案。由于是通配，所以只需要配置一次即可。这样，开发或测试人员就可以通过项目名和分支的方式访问应用，例如分支名是bug-fix，则访问aaa-bug-fix.xxx.com，这样就可以实现多分支同时开发测试的效果，而每个域名代表了一个分支。

进一步的，本申请实施例方案使用了Gitlab作为代码仓库和Gitlab CI作为持续部署的方式，并且开发了一个钩子程序，对于每次项目的Git提交，都可以根据分支按需要自动创建部署的代码目录和推送代码，从而实现部署流程自动化。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

通过结合附图对本申请示例性实施方式进行更详细的描述，本申请的上述以及其它目的、特征和优势将变得更加明显，其中，在本申请示例性实施方式中，相同的参考标号通常代表相同部件。

图1是本申请实施例示出的分布式项目开发处理的流程示意图；

图2是本申请实施例示出的分布式项目开发处理方法的另一流程示意图；

图3是本申请实施例示出的分布式项目开发处理方法中的网络应用架构示意图；

图4是本申请实施例示出的分布式项目系统的结构示意图。

具体实施方式

下面将参照附图更详细地描述本申请的优选实施方式。虽然附图中显示了本申请的优选实施方式，然而应该理解，可以以各种形式实现本申请而不应被这里阐述的实施方式所限制。相反，提供这些实施方式是为了使本申请更加透彻和完整，并且能够将本申请的范围完整地传达给本领域的技术人员。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语“第一”、“第二”、“第三”等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本申请的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。

本申请实施例提供一种分布式项目开发处理方法，能够提高项目的开发和测试环境的稳定性，降低运维压力。

以下结合附图详细描述本申请实施例的技术方案。

图1是本申请实施例示出的分布式项目开发处理的流程示意图。

参见图1，该方法包括：

在步骤S101中，使用分布式的网络文件系统NFS作为代码目录，通过NFS服务器存储代码。

NFS是一种网络存储协议，该步骤使用分布式的网络文件系统NFS作为代码目录，通过NFS服务器存储代码。

在步骤S102中，使用容器集群管理系统k8s构建分布式web服务环境，其中所述k8s中将不同的Pod作为不同的web服务器，通过所述k8s中的Pod挂载所述网络文件系统NFS来挂载所述代码。

k8s全称kubernetes，是容器集群管理系统。Pod是kubernetes的基本操作单元，也是应用运行的载体。由于NFS是一种网络存储协议，所以多个Pod可以同时分布式地挂载NFS目录，可以避免单点服务器存在的问问题。

从该实施例可以看出，本申请实施例示出的方案，使用分布式的网络文件系统NFS作为代码目录并通过NFS服务器存储代码，使用容器集群管理系统k8s构建分布式web服务环境，并通过k8s中的Pod挂载所述网络文件系统NFS来挂载所述代码，即将NFS挂载到分布式的web服务器上(即k8s中的Pod上)，也就是说本申请实施例使用了NFS网络存储部署代码和分布式web服务器挂载代码的方案。由于NFS是一种网络存储协议，所以多个Pod可以同时分布式地挂载NFS目录，这样就避免了单点服务器存在的问题，使得开发和测试环境的稳定性大大提高，多分支的开发和测试流程也比单分支流程更加稳健和高效，也可以降低运维的压力。

图2是本申请实施例示出的分布式项目开发处理方法的另一流程示意图；图3是本申请实施例示出的分布式项目开发处理方法中的网络应用架构示意图。图2相对图1更详细描述了本申请实施例的技术方案。

参见图2，该方法包括：

在步骤S201中，预先设置使用容器集群管理系统k8s构建分布式web服务环境，其中所述k8s中将不同的Pod作为不同的web服务器。

k8s全称kubernetes，是容器集群管理系统，是一个开源的、用于管理云平台中多个主机上的容器化的应用，可以实现容器集群的自动化部署、自动扩缩容、维护等功能。kubernetes中的大部分概念如Master、Node、Pod、Service等都可以被看作一种资源对象，几乎所有资源对象都可以通过Kubernetes提供的kubectl工具执行增、删、改、查等操作并将其保存在etcd(是一个高可用的Key/Value(键/值)存储系统)中持久化存储。

Pod是kubernetes的基本操作单元，也是应用运行的载体。整个kubernetes系统都是围绕着Pod展开的，例如如何部署运行Pod、如何保证Pod的数量、如何访问Pod等。另外，Pod是一个或多个机关容器的集合，提供了一种容器的组合的模型。

在步骤S202中，预先设置分布式的网络文件系统NFS作为代码目录和设置NFS服务器，及预先设置GitLab作为远程代码仓库。

需说明的是，步骤201和步骤202可以没有顺序关系。

在步骤S203中，转发机Nginx根据域名匹配规则，将用户请求反向代理到相应的Pod的代码分支。

Nginx是一款轻量级的Web服务器/反向代理服务器及电子邮件代理服务器，其特点是占有内存少，并发能力强。转发机Nginx接收到用户请求后，根据域名匹配规则，将用户请求反向代理到k8s中相应的Pod的代码分支。

在步骤S204中，通过Gitlab CI调用Pod上的GitLab-Runner运行设定命令，将代码传输给NFS服务器。

本申请实施例使用了Gitlab作为代码仓库和Gitlab CI作为持续部署的方式，并且开发了一个钩子程序，对于每次项目的Git提交，都会根据分支按需要自动创建部署的代码目录和推送代码，将部署的流程自动化。

GitLab是一个用于仓库管理系统的开源项目，使用Git作为代码管理工具，并在此基础上搭建起来的web服务。安装方法是参考GitLab在GitHub上的Wiki页面。GitLab CI是GitLab提供的持续集成服务，只要在仓库根目录创建一个.Gitlab-ci.yml文件，并为该项目指派一个Runner，当有合并请求或者push的时候就会触发build(构建)。持续集成(Continuous integration)，简称CI，是一种软件开发实践。开发人员提交代码后，系统自动进行构建、(单元)测试，通过自动化测试保障所有的提交在合并主线之后不会出现质量问题，对可能出现的一些问题进行预警。

GitLab-Runner是配合GitLab-CI进行使用的。一般地，GitLab里面的每一个工程都会定义一个属于这个工程的软件集成脚本，用来自动化地完成一些软件集成工作。当这个工程的仓库代码发生变动时，例如有人push了代码，GitLab就会将这个变动通知GitLab-CI。这时GitLab-CI会找出与这个工程相关联的Runner，并通知这些Runner把代码更新到本地并执行预定义好的执行脚本。

在步骤S205中，通过所述k8s中的Pod挂载所述网络文件系统NFS来挂载所述代码。

在通过Gitlab CI调用所述Pod上的GitLab-Runner运行代码拉取命令后，将所述代码拉取到NFS服务器上对应的代码分支挂载目录，并通过k8s的Pod挂载NFS来挂载代码。

本申请使用分布式的文件存储系统作为代码目录，并挂载到分布式的web服务器也即k8s中的Pod上。也就是说，使用NFS网络存储来部署代码，使用k8s作为分布式web服务环境，通过k8s的Pod挂载NFS来挂载代码。

需说明的是，本申请实施例中，在所述Pod通过联合文件系统mergerfs来创建各个分支的web目录。本申请实施例使用联合文件系统，对于某个功能分支但没有实际建立分支的项目，节省了代码的存储空间。使用联合文件系统mergerfs来创建各个分支的web目录，实际上是覆盖了实际分支代码目录和主分支的代码目录，达到节省存储空间和部署时间的目的。

还需说明的是，本申请实施例中，在所述Pod基于DNSmasq配置正则通配的域名规则，按照所述域名规则为不同的分支各分配域名。本申请实施例使用支持正则表达式的DNS服务器。本申请实施例基于DNSmasq自行开发支持正则表达式的DNS域名解析功能，通配域名规范中分支的那一部分的域名。DNSmasq是一个小巧且方便地用于配置DNS和DHCP(Dynamic Host Configuration Protocol，动态主机配置协议)的工具，适用于小型网络，它提供了DNS功能和可选择的DHCP功能。它服务那些只在本地适用的域名，这些域名是不会在全球的DNS服务器中出现的。DHCP服务器和DNS服务器结合，并且允许DHCP分配的地址能在DNS中正常解析，而这些DHCP分配的地址和相关命令可以配置到每台主机中，也可以配置到一台核心设备中(比如路由器)，DNSmasq支持静态和动态两种DHCP配置方式。

以下进一步结合一个应用实施例进行说明：

首先，开发人员按照需求或者缺陷创建一个Git分支，进行相应的代码的写入或修改，然后push到远程Gitlab仓库。转发机Nginx根据域名匹配规则，将用户请求反向代理到相应的Pod的代码分支。Gitlab CI感应到push操作后，调用Pod上的Gitlab runner运行代码拉取命令，将代码拉取到NFS服务器上相应的代码分支挂载目录，并且调用各个业务服务Pod上的mergerfs命令，来实现联合文件系统的目录复用。由于NFS是一种网络存储协议，所以多个Pod可以同时分布式地挂载NFS目录，避免了单点问题。如果是全新的项目，则运维人员需要在DNSmasq-plus配置一条正则通配的域名规则，例如项目名是aaa，则配置成aaa-*.xxx.com，其中*匹配任意一个分支名，由于是通配，所以只需要配置一次即可。这样，测试人员就可以通过项目名和分支的方式访问应用，比如分支名是bug-fix，则访问aaa-bug-fix.xxx.com，这样就可以实现多分支同时开发测试的效果，每个域名代表了一个分支。

综上所描述，本申请实施例提出了分布式的开发测试环境的方案，并且对于各个新需求或缺陷修复独立一个分支进行代码部署，做到良好的隔离性，更具体的分析如下：

针对代码方面，由于各个项目之前联系比较紧密，所以可以使用一台存储机器存放部署的代码，代码存放在相应的目录以保证关联性不受到影响，然后使用mergerfs文件联合系统实现分支开发，即实际代码目录是功能分支代码目录覆盖主分支代码目录，从而节省了存储空间，然后通过NFS给分布式的web服务器(即k8s中的Pod)作为挂载。

针对web服务器方面，使用了k8s作为分布式的部署环境，按照业务部门区分成不同的k8s的Pod，即不同的web服务器，以保证单独的web服务器崩溃不会影响到所有业务。然后对于不同的分支，按照开发测试的域名规范各分配一个域名，并且使用自行开发的支持通配符的DNS解析的方式作为配置，达到各个分支之间的隔离性。

针对代码部署方面，使用了Gitlab作为代码仓库和Gitlab CI作为持续部署的方式，并且开发了一个钩子程序，对于每次项目的Git提交，都会根据分支按需要自动创建部署的代码目录和推送代码，将部署的流程自动化。

相关技术中多个互相联系的项目的开发测试环境是放到一台服务器上，如果这一台服务器崩溃掉，则影响到公司所有业务的开发和测试流程，影响很大，经常因为服务器崩溃并且修复时间过久导致业务开发团队长时间无法正常工作。利用本申请实施例提出的方案，开发测试环境的稳定性得到了很大提升，经过试验测试，数百个多功能或修复分支在活跃使用中，隔离性良好。因此，本申请实施例方案，满足多个互相联系的分布式项目的持续的开发测试流程，并且对于各个新需求或缺陷修复进行独立分支的代码部署，能做到良好的隔离性。

与前述应用功能实现方法实施例相对应，本申请还提供了分布式项目系统及相应的实施例。

图4是本申请实施例示出的分布式项目系统的结构示意图。

参见图4，一种分布式项目系统：包括NFS服务器41和容器集群管理系统(k8s)42，其中所述k8s中包括不同的Pod，不同的Pod作为不同的web服务器；

NFS服务器41，用于用于使用分布式的网络文件系统NFS作为代码目录，通过NFS服务器41存储代码；

容器集群管理系统(k8s)42，用于构建分布式web服务环境，通过所述k8s中的Pod挂载所述网络文件系统NFS来挂载所述代码。

在一种实施方式中，所述k8s中的Pod通过联合文件系统mergerfs来创建各个分支的web目录。

在一种实施方式中，所述k8s中的Pod基于DNSmasq配置正则通配的域名规则，按照所述域名规则为不同的分支各分配域名。

在一种实施方式中，所述基于DNSmasqPod在用户端将创建的分支及代码推送到所述远程代码仓库后，通过Gitlab CI调用所述Pod上的GitLab-Runner运行设定命令，将所述代码传输给所述NFS服务器41上对应的代码分支挂载目录。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不再做详细阐述说明。

上文中已经参考附图详细描述了本申请的方案。在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详细描述的部分，可以参见其他实施例的相关描述。本领域技术人员也应该知悉，说明书中所涉及的动作和模块并不一定是本申请所必须的。另外，可以理解，本申请实施例方法中的步骤可以根据实际需要进行顺序调整、合并和删减，本申请实施例装置中的模块可以根据实际需要进行合并、划分和删减。

此外，根据本申请的方法还可以实现为一种计算机程序或计算机程序产品，该计算机程序或计算机程序产品包括用于执行本申请的上述方法中部分或全部步骤的计算机程序代码指令。

或者，本申请还可以实施为一种非暂时性机器可读存储介质(或计算机可读存储介质、或机器可读存储介质)，其上存储有可执行代码(或计算机程序、或计算机指令代码)，当所述可执行代码(或计算机程序、或计算机指令代码)被电子设备(或电子设备、服务器等)的处理器执行时，使所述处理器执行根据本申请的上述方法的各个步骤的部分或全部。

附图中的流程图和框图显示了根据本申请的多个实施例的系统和方法的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标记的功能也可以以不同于附图中所标记的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

以上已经描述了本申请的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术的改进，或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。

Claims (3)

1.一种分布式项目开发处理方法，其特征在于，包括：

使用分布式的网络文件系统NFS作为代码目录，通过NFS服务器存储代码；

使用容器集群管理系统k8s构建分布式web服务环境，其中所述k8s中将不同的Pod作为不同的web服务器，通过所述k8s中的Pod挂载所述网络文件系统NFS来挂载所述代码；

在所述Pod通过联合文件系统mergerfs来创建各个分支的web目录；

在所述Pod基于DNSmasq配置正则通配的域名规则，按照所述域名规则为不同的分支各分配域名；

所述k8s中的Pod在用户端将创建的分支及代码推送到远程代码仓库后，通过GitlabCI调用所述Pod上的GitLab-Runner运行代码拉取命令，将所述代码传输给所述NFS服务器上对应的代码分支挂载目录。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

设置GitLab作为远程代码仓库，通过Gitlab CI进行持续代码部署。

3.一种分布式项目系统，其特征在于：

包括NFS服务器和容器集群管理系统k8s，其中所述k8s中包括不同的Pod，不同的Pod作为不同的web服务器；

NFS服务器，用于使用分布式的网络文件系统NFS作为代码目录，通过NFS服务器存储代码；

容器集群管理系统k8s，用于构建分布式web服务环境，通过所述k8s中的Pod挂载所述网络文件系统NFS来挂载所述代码；其中，

所述k8s中的Pod通过联合文件系统mergerfs来创建各个分支的web目录；

所述k8s中的Pod基于DNSmasq配置正则通配的域名规则，按照所述域名规则为不同的分支各分配域名；

所述k8s中的Pod在用户端将创建的分支及代码推送到远程代码仓库后，通过GitlabCI调用所述Pod上的GitLab-Runner运行代码拉取命令，将所述代码传输给所述NFS服务器上对应的代码分支挂载目录。