CN115599399A - 一种应用程序部署方法、装置及存储介质 - Google Patents

一种应用程序部署方法、装置及存储介质 Download PDF

Info

Publication number
CN115599399A
CN115599399A CN202211513077.XA CN202211513077A CN115599399A CN 115599399 A CN115599399 A CN 115599399A CN 202211513077 A CN202211513077 A CN 202211513077A CN 115599399 A CN115599399 A CN 115599399A
Authority
CN
China
Prior art keywords
executable file
service container
configuration
application server
file
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202211513077.XA
Other languages
English (en)
Inventor
傅芳
卢琰
吴佩珊
李丹
杨思诗
黎丽娜
罗亮
李海威
龙武
江新超
杜宝林
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Guangdong Science & Technology Infrastructure Center
Original Assignee
Guangdong Science & Technology Infrastructure Center
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Guangdong Science & Technology Infrastructure Center filed Critical Guangdong Science & Technology Infrastructure Center
Priority to CN202211513077.XA priority Critical patent/CN115599399A/zh
Publication of CN115599399A publication Critical patent/CN115599399A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3664Environments for testing or debugging software
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/65Updates
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/70Software maintenance or management
    • G06F8/71Version control; Configuration management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Stored Programmes (AREA)

Abstract

本发明公开了一种应用程序部署方法、装置及存储介质,包括:内网在监测到用户提交的源代码有更新时,对更新后的源代码进行打包处理,生成可执行文件,并上传至外网或隔离区;外网或隔离区的应用服务器创建对应配置环境的服务容器,并在所述服务容器中运行可执行文件,启动所述服务容器;其中,在运行可执行文件时,通过预设的查找路径查找得到对应配置环境的配置文件,所述配置环境包括测试环境和正式环境。采用本发明实施例能够在一台服务器上部署两套配置环境或多套配置环境,无需分配多台服务器,只在一台服务器上运维即可,减少运维的工作量。

Description

一种应用程序部署方法、装置及存储介质
技术领域
本发明涉及计算机技术领域,尤其涉及一种应用程序部署方法、装置及存储介质。
背景技术
互联网软件通常采用迭代模式开发,版本更新频繁,为了提高打包部署的效率,现通常采用自动化持续集成和持续部署的方式,替代传统的人工打包部署的方式,常用的集成工具如Jenkins。
软件在开发过程中,会部署两套配置环境:测试环境和正式环境。软件在测试环境测试通过后,才部署到正式环境,用户才能使用。当软件上线后,有新版本需要更新时,为了不能影响客户使用旧版本,同时需要测试新版本,在测试通过后,再启用新版本,这时需要同时启用两套配置环境,然而,现有技术通常仅在一台服务器上部署一套配置环境,导致需要启用多台服务器,增加运维的工作量。
发明内容
本发明实施例的目的是提供一种应用程序部署方法、装置及存储介质,通过在一台应用服务器中同时创建测试环境的测试服务容器和正式环境的正式服务容器,能够在一台服务器上部署两套配置环境或多套配置环境,无需分配多台服务器,只在一台服务器上运维即可,减少运维的工作量。
为实现上述目的,本发明实施例提供了一种应用程序部署方法,包括:
内网在监测到用户提交的源代码有更新时,对更新后的源代码进行打包处理,生成可执行文件,并上传至外网或隔离区;
外网或隔离区的应用服务器创建对应配置环境的服务容器,并在所述服务容器中运行可执行文件,启动所述服务容器;其中,在运行可执行文件时,通过预设的查找路径查找得到对应配置环境的配置文件,所述配置环境包括测试环境和正式环境。
作为上述方案的改进,在启动所述服务容器之后,所述应用程序部署方法还包括:
在等待预设的时长阈值后,验证对应配置环境的服务是否启动成功。
作为上述方案的改进,对于测试环境,所述创建对应配置环境的服务容器,并在所述服务容器中运行可执行文件,启动所述服务容器包括:
在监测到可执行文件有更新时,拉取更新后的可执行文件和更新后的配置文件存放于所述应用服务器中,或拉取预设版本的可执行文件和预设版本的配置文件存放于所述应用服务器中;
当判断到所述应用服务器存在测试服务容器时,删除所述测试服务容器;
将存放于所述应用服务器中的可执行文件和配置文件挂载到新的测试服务容器;
创建新的测试服务容器,在所述新的测试服务容器中运行可执行文件,并启动新的测试服务容器;其中,在运行可执行文件时,通过预设的查找路径在所述应用服务器中查找得到对应测试环境的配置文件。
作为上述方案的改进,对于正式环境,所述创建对应的服务容器,并在所述服务容器中运行可执行文件,启动所述服务容器包括:
响应于用户的部署指令,拉取更新后的可执行文件和更新后的配置文件存放于所述应用服务器中,或拉取预设版本的可执行文件和预设版本的配置文件存放于所述应用服务器中;
当判断到所述应用服务器存在正式服务容器时,删除所述正式服务容器;
将存放于所述应用服务器中的可执行文件和配置文件挂载到新的正式服务容器;
创建新的正式服务容器,在所述新的正式服务容器中运行可执行文件,并启动新的正式服务容器;其中,在运行可执行文件时,通过预设的查找路径在所述应用服务器中查找得到对应正式环境的配置文件。
作为上述方案的改进,在所述对更新后的源代码进行打包处理之前,所述应用程序部署方法还包括:
将更新后的源代码划分为主干源代码和分支源代码;
则所述对更新后的源代码进行打包处理,生成可执行文件,并上传至外网或隔离区,包括:
对所述分支源代码进行打包处理,生成测试可执行文件,并所述主干源代码进行打包处理,得到正式可执行文件,将所述正式可执行文件和所述测试可执行文件上传至外网或隔离区;
则,对于测试环境,在所述服务容器中运行的可执行文件为测试可执行文件,对于正式环境,在所述服务容器中运行的可执行文件为正式可执行文件。
为实现上述目的,本发明实施例提供了一种应用程序部署装置,包括:设于内网的源代码库及打包构建模块,和设于外网或DMZ区的可执行文件库、配置文件库及应用服务器;
所述源代码库,用于存储用户提交的源代码;
所述打包构建模块,用于在监测到所述源代码库中的源代码有更新时,从所述源代码库中拉取更新后的源代码,对更新后的源代码进行打包处理,生成可执行文件,并上传至所述可执行文件库;
所述可执行文件库,用于存储所述打包构建模块上传的可执行文件;
所述应用服务器,用于创建对应配置环境的服务容器,并在所述服务容器中运行可执行文件,启动所述服务容器;其中,在运行可执行文件时,通过预设的查找路径查找得到对应配置环境的配置文件,所述配置环境包括测试环境和正式环境;
所述配置文件库,用于存储用户提交的配置文件。
作为上述方案的改进,所述应用服务器还用于:
在等待预设的时长阈值后,验证对应配置环境的服务是否启动成功。
作为上述方案的改进,所述应用服务器还用于:
在监测到可执行文件有更新时,拉取更新后的可执行文件和更新后的配置文件存放于所述应用服务器中,或拉取预设版本的可执行文件和预设版本的配置文件存放于所述应用服务器中;
当判断到所述应用服务器存在测试服务容器时,删除所述测试服务容器;
将存放于所述应用服务器中的可执行文件和配置文件挂载到新的测试服务容器;
创建新的测试服务容器,在所述新的测试服务容器中运行可执行文件,并启动新的测试服务容器;其中,在运行可执行文件时,通过预设的查找路径在所述应用服务器中查找得到对应测试环境的配置文件。
作为上述方案的改进,所述应用服务器还用于:
响应于用户的部署指令,拉取更新后的可执行文件和更新后的配置文件存放于所述应用服务器中,或拉取预设版本的可执行文件和预设版本的配置文件存放于所述应用服务器中;
当判断到所述应用服务器存在正式服务容器时,删除所述正式服务容器;
将存放于所述应用服务器中的可执行文件和配置文件挂载到新的正式服务容器;
创建新的正式服务容器,在所述新的正式服务容器中运行可执行文件,并启动新的正式服务容器;其中,在运行可执行文件时,通过预设的查找路径在所述应用服务器中查找得到对应正式环境的配置文件。
为实现上述目的,本发明实施例提供了一种计算机可读存储介质,所述计算机可读存储介质包括存储的计算机程序;其中,所述计算机程序在运行时控制所述计算机可读存储介质所在的设备执行如上述的应用程序部署方法。
与现有技术相比,本发明实施例提供的一种应用程序部署方法、装置及介质,通过在内网对源代码进行打包处理,生成可执行文件,并上传至外网或隔离区;在外网或隔离区的应用服务器创建对应配置环境的服务容器,并在所述服务容器中运行可执行文件,启动所述服务容器;其中,在运行可执行文件时,通过预设的查找路径查找得到对应配置环境的配置文件,所述配置环境包括测试环境和正式环境,能够在一台服务器上部署并启用两套配置环境或多套配置环境,且互不影响,无需分配多台服务器,只在一台服务器上运维即可,减少运维的工作量。
附图说明
图1是本发明实施例提供的一种应用程序部署方法的流程图;
图2是本发明实施例提供的应用服务器的结构框图;
图3是本发明实施例提供的源代码管理图;
图4是本发明实施例提供的又一源代码管理图;
图5是本发明实施例提供的一种应用程序部署装置的结构框图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
对本发明实施例所用到的名词进行说明,以便更好理解本发明实施例:
内网:内部封闭性局域网,此网络区域与互联网不互通;
隔离区(DMZ),是内外网防火墙之间的区域,可以通过一定的网络访问策略与互联网互通;
外网:即互联网。
正式环境:正式提供对外服务;
测试环境:用于测试的,不对外提供服务。
参见图1,图1是本发明实施例提供的一种应用程序部署方法的流程图,所述应用程序部署方法包括:
S1、内网在监测到用户提交的源代码有更新时,对更新后的源代码进行打包处理,生成可执行文件,并上传至外网或隔离区;
可以理解的是,用户提交的源代码可存储于源代码库,在所述源代码库中进行代码版本管理,可以使用源代码托管工具,如SVN,GitLab。可见,本发明实施例源代码存储在企业内网,在不交付源代码的情况下,自动化持续部署交付软件产品,可保护源码免受网络攻击。
可以理解的是,通过使用持续集成工具,如Jenkins,对更新后的源代码进行打包处理。具体地,在Jenkins中进行如下配置:(a)设置源代码的svn路径;(b)设置轮询svn的时间(可自由定义,如每秒,每分,每小时…);如果是拉取预设版本的可执行文件,则不需要设置轮询时间。本步骤是为了监测源代码是否有更新,(c)设置shell脚本,执行打包需要的一系列操作。
当轮询发现源代码版本有更新时,即会自动从该svn路径拉取最新的源代码进行打包(在Jenkins打包即为build),生成可执行文件,并将可执行文件拷贝至设于外网或隔离区的可执行文件库。
可以理解的是,将生成的可执行文件上传至设于外网或隔离区的可执行文件库中,在所述可执行文件库中进行可执行文件版本管理,可以使用源代码托管工具,如SVN,GitLab。
S2、外网或隔离区的应用服务器创建对应配置环境的服务容器,并在所述服务容器中运行可执行文件,启动所述服务容器;其中,在运行可执行文件时,通过预设的查找路径查找得到对应配置环境的配置文件,所述配置环境包括测试环境和正式环境。
可以理解的是,可执行文件运行需要连接相应的数据库及程序所需的账号密码等通用配置信息,这些通用配置信息都是在配置文件里进行配置的。测试环境和正式环境下的配置文件存储的配置信息不同,配置信息主要是需要连接的数据库信息,包括数据库的IP、端口、用户名、密码、数据库名称。配置文件不参与构建,在可执行文件运行时,通过路径找到配置文件即可,所以,开发人员直接将在内网将配置文件提交至位于DMZ或外网的配置文件库。可见,本发明实施例将源代码和配置文件分开管理,基于同一套源代码,通过不同的配置文件,实现不同的服务。在源代码工程的管理上,更简洁,减少代码同步的工作量。
可以理解的是,应用服务器是用于部署可执行文件的服务器,可以采用容器化技术工具如docker,创建对应配置环境的服务容器。具体地,在Jenkins中进行如下配置:(a)设置可执行文件和配置文件的svn路径;(a)针对测试环境,设置轮询svn的时间(可自由定义,如每秒,每分,每小时…);针对正式环境,因为涉及到用户直接使用,所以正式环境通常比较谨慎,不会直接自动部署发布,通常通过人工发布,故正式环境不设置轮询时间。(c)设置shell脚本,执行部署发布需要的一系列操作;
当轮询发现可执行文件有更新或者手动触发发布操作时,则从可执行文件库拉取最新的或者指定版本的可执行文件,运行可执行文件,启动服务。
在本发明实施例中,开发人员在内网开发,源代码也存储在内网服务器,在内网打包,生成可执行文件并将可执行文件存放在DMZ区或外网的服务器。位于DMZ区或外网的应用服务器通过一定的访问策略,分别从可执行文件库和配置文件库拉取可执行文件和配置文件,运行可执行文件,启动服务容器即可认为启动服务。可见,本发明实施例能够解决现有技术中一台服务器只能运行一个软件版本,即在一台服务器上只能部署一个配置环境,不能同时部署启用两套环境的问题,本发明实施例能够在一台服务器上部署并启用两套配置环境或多套配置环境,且互不影响。
服务启动后,通过nginx(高性能的HTTP和反向代理web服务器)实现反向代理。开发人员通过测试服务访问路径,可访问测试服务,对软件产品进行测试。正式用户通过正式服务访问路径,正常使用软件产品。两者互不影响。测试通过后,打包最新的代码,部署到正式环境,用户即可体验最新的软件版本。
上述所有配置完成后,可实现全流程自动化,由开发人员提交源代码后即可触发一系列的自动化操作。
可以理解的是,可执行文件要运行起来,需要部署相应的环境,连接相应的数据库。本发明实施例中,将可执行文件放入alpine基础环境中运行,采用redis作为内存数据库,用于保存用户session、参数等需要经常访问的数据,采用nginx作为反向代理,jenkins作为持续部署工具。
本发明实施例使用容器化技术,采用docker部署正式环境和测试环境。在应用服务器中安装docker,执行相应的镜像文件创建Jenkins、nginx和redis容器,通过运行命令创建测试服务容器和正式服务容器,例如docker run 测试服务容器/正式服务容器,创建的各容器如图2所示。启动正式服务容器/测试服务容器,即启动了正式服务/测试服务,以下对测试环境和正式环境下的可执行文件运行进行说明:
在一可选实施例中,对于测试环境,所述创建对应配置环境的服务容器,并在所述服务容器中运行可执行文件,启动所述服务容器包括:
在监测到可执行文件有更新时,拉取更新后的可执行文件和更新后的配置文件存放于所述应用服务器中,或拉取预设版本的可执行文件和预设版本的配置文件存放于所述应用服务器中;
可以理解的是,此时,拉取的配置文件包括测试环境的配置文件和正式环境的配置文件,因此,存放于应用服务器中的配置文件同样包括测试环境的配置文件和正式环境的配置文件;后续在运行可执行文件时,通过预设的查找路径在所述应用服务器中查找得到测试环境的配置文件。
当判断到所述应用服务器存在测试服务容器时,删除所述测试服务容器;
可以理解的是,因为测试服务是通过在测试服务容器里运行可执行文件来实现,当可执行文件有更新时,若要实现测试服务的更新,就需要运行新的可执行文件。所以此处删除旧的测试服务容器,并重新创建新的测试容器,以实现服务的更新。当然此处也有其他的实现方式。例如,将测试服务容器里的可执行文件替换为新的可执行文件,具体行为是找到旧可执行文件的存放路径,再将新可执行文件拷贝过去。但这种方式存在以下几个问题:1、因为通常服务是处于运行状态,可执行文件被占用,所以此时拷贝操作会失败。2、可执行文件有时并不只有一个,比如前端页面服务,可执行文件是多个。如果采用这种方式就需要依次找到文件存放路径,依次替换,容易出现遗漏,容易出问题。
因此本发明实施例删除旧的测试服务容器,具体实现行为是先停测试服务,再删除测试服务容器,此时,测试服务是正常退出的,接着创建新的测试服务容器,启动测试服务。所以,采用此种方式,是相对稳妥且方便的。
将存放于所述应用服务器中的可执行文件和配置文件挂载到新的测试服务容器;
创建新的测试服务容器,在所述新的测试服务容器中运行可执行文件,并启动新的测试服务容器;其中,在运行可执行文件时,通过预设的查找路径在所述应用服务器中查找得到对应测试环境的配置文件。
可以理解的是,应用服务器的Jenkins新建一个测试任务,该测试任务做如下配置(触发build操作,会执行以下操作):
1、从可执行文件库拉取可执行文件,从配置文件库拉取配置文件,存放于宿主机中。
可以理解的是,docker是安装在应用服务器中,应用服务器相对docker来讲也叫宿主机,宿主机可以是电脑,是数据中心的物理服务器,也可以是公有云的某个实例;
2、执行sh脚本,脚本中执行如下命令:
a)判断是否存在测试服务容器,若存在,则删除测试服务容器,否则进入步骤b);
b)将宿主机中的可执行文件和配置文件挂载到测试服务容器;具体地,通过-v命令,可在测试服务容器未创建的情况下挂载数据;
c)基于alpine基础镜像,创建测试服务容器,在测试服务容器中运行可执行文件,并启动测试服务容器。
至此,可以认为测试服务已经完成启动。
在一可选实施例中,对于正式环境,所述创建对应的服务容器,并在所述服务容器中运行可执行文件,启动所述服务容器包括:
响应于用户的部署指令,拉取更新后的可执行文件和更新后的配置文件存放于所述应用服务器中,或拉取预设版本的可执行文件和预设版本的配置文件存放于所述应用服务器中;
可以理解的是,此时,拉取的配置文件包括测试环境的配置文件和正式环境的配置文件,因此,存放于应用服务器中的配置文件同样包括测试环境的配置文件和正式环境的配置文件;后续在运行可执行文件时,通过预设的查找路径在所述应用服务器中查找得到测试环境的配置文件。
当判断到所述应用服务器存在正式服务容器时,删除所述正式服务容器;
可以理解的是,因为正式服务是通过在正式服务容器里运行可执行文件来实现,当可执行文件有更新时,若要实现正式服务的更新,就需要运行新的可执行文件。所以此处删除旧的正式服务容器,并重新创建新的正式服务容器,以实现服务的更新。当然此处也有其他的实现方式。例如,将正式服务容器里的可执行文件替换为新的可执行文件,具体行为是找到旧可执行文件的存放路径,再将新可执行文件拷贝过去。但这种方式存在以下几个问题:1、因为通常服务是处于运行状态,可执行文件被占用,所以此时拷贝操作会失败。2、可执行文件有时并不只有一个,比如前端页面服务,可执行文件是多个。如果采用这种方式就需要依次找到文件存放路径,依次替换,容易出现遗漏,容易出问题。
因此本发明实施例删除旧的正式服务容器,具体实现行为是先停正式服务,再删除正式服务容器,此时,正式服务是正常退出的,接着创建新的正式服务容器,启动正式服务。所以,采用此种方式,是相对稳妥且方便的。
将存放于所述应用服务器中的可执行文件和配置文件挂载到新的正式服务容器;
创建新的正式服务容器,在所述新的正式服务容器中运行可执行文件,并启动新的正式服务容器;其中,在运行可执行文件时,通过预设的查找路径在所述应用服务器中查找得到对应正式环境的配置文件。
可以理解的是,应用服务器的Jenkins新建一个正式任务,该正式任务做如下配置(触发build操作,会执行以下操作):
1、从可执行文件库拉取可执行文件,从配置文件库拉取配置文件,存放于宿主机中。
2、执行sh脚本,脚本中执行如下命令:
a)判断是否存在正式服务容器,若存在,则删除正式服务容器,否则进入步骤b);
b)将宿主机中的可执行文件和配置文件挂载到正式服务容器;具体地,通过-v命令,可在正式服务容器未创建的情况下挂载数据;
c)基于alpine基础镜像,创建正式服务容器,在正式服务容器中运行可执行文件,并启动正式服务容器。
至此,可以认为正式服务已经完成启动。
在一可选实施例中,在启动所述服务容器之后,所述应用程序部署方法还包括:
在等待预设的时长阈值后,验证对应配置环境的服务是否启动成功。
具体地,等待10s,验证测试服务或正式服务是否启动成功;可以通过curl命令访问后端一个接口,如果不返回错误,即认为服务正常启动。
可以理解的是,在现有的实现方式中,只是验证是否构建部署成功,不能保证服务正常启动。现在应用通常是前后端分离架构,分为前端服务和后端服务。前端服务提供界面,后端服务提供接口,用户在操作界面的过程中,系统通过调用后端接口实现功能的交互。服务打包成功,不代表服务可以正常启动起来,例如,可能无法连接数据库,但打包可以成功。所以,即使构建部署成功,也不代表服务可以正常启动,不代表软件可以正常使用。
在本发明实施例中,针对后端接口服务,在服务容器构建成功后,再次验证服务是否正常启动,可提前发现问题,防止在软件正式部署到正式环境中,用户已经使用最新软件才发现问题,例如连接数据库出错,影响用户体验。
在一可选实施例中,在所述对更新后的源代码进行打包处理之前,所述应用程序部署方法还包括:
将更新后的源代码划分为主干源代码和分支源代码;
则所述对更新后的源代码进行打包处理,生成可执行文件,并上传至外网或隔离区,包括:
对所述分支源代码进行打包处理,生成测试可执行文件,并所述主干源代码进行打包处理,得到正式可执行文件,将所述正式可执行文件和所述测试可执行文件上传至外网或隔离区。
则,对于测试环境,在所述服务容器中运行的可执行文件为测试可执行文件,对于正式环境,在所述服务容器中运行的可执行文件为正式可执行文件。
可以理解的是,针对测试环境和正式环境,使用的可执行文件,可由同一套源代码打包而来,参见图3,也可由不同的源代码打包而来,参见图4,这取决于源代码的管理。源代码可由主干源代码和若干分支源代码进行管理。分支源代码进行测试,测试通过再将分支源代码合并到主干源代码,主干源代码用于正式环境最终提供对外服务。可以理解的是,可以对合并前的主干源代码,也可以对合并后的主干源代码进行打包处理。
本发明实施例所提供的一种应用程序部署方法,通过在内网对源代码进行打包处理,生成可执行文件,并上传至外网或隔离区;在外网或隔离区的应用服务器创建对应配置环境的服务容器,并在所述服务容器中运行可执行文件,启动所述服务容器;其中,在运行可执行文件时,通过预设的查找路径查找得到对应配置环境的配置文件,所述配置环境包括测试环境和正式环境,能够在一台服务器上部署并启用两套配置环境或多套配置环境,且互不影响,无需分配多台服务器,只在一台服务器上运维即可,减少运维的工作量。
参见图5,图5是本发明实施例提供的一种应用程序部署装置10的结构框图,所述应用程序部署装置10包括:设于内网的源代码库11及打包构建模块12,和设于外网或DMZ区的可执行文件库13、配置文件库14及应用服务器15;
所述源代码库11,用于存储用户提交的源代码;
所述打包构建模块12,用于在监测到所述源代码库中的源代码有更新时,从所述源代码库中拉取更新后的源代码,对更新后的源代码进行打包处理,生成可执行文件,并上传至所述可执行文件库;
所述可执行文件库13,用于存储所述打包构建模块上传的可执行文件;
所述应用服务器15,用于创建对应配置环境的服务容器,并在所述服务容器中运行可执行文件,启动所述服务容器;其中,在运行可执行文件时,通过预设的查找路径查找得到对应配置环境的配置文件;
所述配置文件库14,用于存储用户提交的配置文件。
优选地,所述应用服务器15还用于:
在等待预设的时长阈值后,验证对应配置环境的服务是否启动成功。
优选地,所述应用服务器15还用于:
在监测到可执行文件有更新时,拉取更新后的可执行文件和更新后的配置文件存放于所述应用服务器中,或拉取预设版本的可执行文件和预设版本的配置文件存放于所述应用服务器中;
当判断到所述应用服务器存在测试服务容器时,删除所述测试服务容器;
将存放于所述应用服务器中的可执行文件和配置文件挂载到新的测试服务容器;
创建新的测试服务容器,在所述新的测试服务容器中运行可执行文件,并启动新的测试服务容器;其中,在运行可执行文件时,通过预设的查找路径在所述应用服务器中查找得到对应测试环境的配置文件。
优选地,所述应用服务器15还用于:
响应于用户的部署指令,拉取更新后的可执行文件和更新后的配置文件存放于所述应用服务器中,或拉取预设版本的可执行文件和预设版本的配置文件存放于所述应用服务器中;
当判断到所述应用服务器存在正式服务容器时,删除所述正式服务容器;
将存放于所述应用服务器中的可执行文件和配置文件挂载到新的正式服务容器;
创建新的正式服务容器,在所述新的正式服务容器中运行可执行文件,并启动新的正式服务容器;其中,在运行可执行文件时,通过预设的查找路径在所述应用服务器中查找得到对应正式环境的配置文件。
值得说明的是,本发明实施例所述的应用程序部署装置10中各个模块的工作过程可参考上述实施例所述的应用程序部署方法的工作过程,在此不再赘述。
本发明实施例所提供的一种应用程序部署装置10,通过在内网对源代码进行打包处理,生成可执行文件,并上传至外网或隔离区;在外网或隔离区的应用服务器创建对应配置环境的服务容器,并在所述服务容器中运行可执行文件,启动所述服务容器;其中,在运行可执行文件时,通过预设的查找路径查找得到对应配置环境的配置文件,所述配置环境包括测试环境和正式环境,能够在一台服务器上部署并启用两套配置环境或多套配置环境,且互不影响,无需分配多台服务器,只在一台服务器上运维即可,减少运维的工作量。
本发明实施例还一种计算机可读存储介质,所述计算机可读存储介质包括存储的计算机程序;其中,所述计算机程序在运行时控制所述计算机可读存储介质所在的设备执行如上述实施例的应用程序部署方法。
以上所述是本发明的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也视为本发明的保护范围。

Claims (10)

1.一种应用程序部署方法,其特征在于,包括:
内网在监测到用户提交的源代码有更新时,对更新后的源代码进行打包处理,生成可执行文件,并上传至外网或隔离区;
外网或隔离区的应用服务器创建对应配置环境的服务容器,并在所述服务容器中运行可执行文件,启动所述服务容器;其中,在运行可执行文件时,通过预设的查找路径查找得到对应配置环境的配置文件,所述配置环境包括测试环境和正式环境。
2.如权利要求1所述的应用程序部署方法,其特征在于,在启动所述服务容器之后,所述应用程序部署方法还包括:
在等待预设的时长阈值后,验证对应配置环境的服务是否启动成功。
3.如权利要求1所述的应用程序部署方法,其特征在于,对于测试环境,所述创建对应配置环境的服务容器,并在所述服务容器中运行可执行文件,启动所述服务容器包括:
在监测到可执行文件有更新时,拉取更新后的可执行文件和更新后的配置文件存放于所述应用服务器中,或拉取预设版本的可执行文件和预设版本的配置文件存放于所述应用服务器中;
当判断到所述应用服务器存在测试服务容器时,删除所述测试服务容器;
将存放于所述应用服务器中的可执行文件和配置文件挂载到新的测试服务容器;
创建新的测试服务容器,在所述新的测试服务容器中运行可执行文件,并启动新的测试服务容器;其中,在运行可执行文件时,通过预设的查找路径在所述应用服务器中查找得到对应测试环境的配置文件。
4.如权利要求1所述的应用程序部署方法,其特征在于,对于正式环境,所述创建对应的服务容器,并在所述服务容器中运行可执行文件,启动所述服务容器包括:
响应于用户的部署指令,拉取更新后的可执行文件和更新后的配置文件存放于所述应用服务器中,或拉取预设版本的可执行文件和预设版本的配置文件存放于所述应用服务器中;
当判断到所述应用服务器存在正式服务容器时,删除所述正式服务容器;
将存放于所述应用服务器中的可执行文件和配置文件挂载到新的正式服务容器;
创建新的正式服务容器,在所述新的正式服务容器中运行可执行文件,并启动新的正式服务容器;其中,在运行可执行文件时,通过预设的查找路径在所述应用服务器中查找得到对应正式环境的配置文件。
5.如权利要求1所述的应用程序部署方法,其特征在于,在所述对更新后的源代码进行打包处理之前,所述应用程序部署方法还包括:
将更新后的源代码划分为主干源代码和分支源代码;
则所述对更新后的源代码进行打包处理,生成可执行文件,并上传至外网或隔离区,包括:
对所述分支源代码进行打包处理,生成测试可执行文件,并所述主干源代码进行打包处理,得到正式可执行文件,将所述正式可执行文件和所述测试可执行文件上传至外网或隔离区;
则,对于测试环境,在所述服务容器中运行的可执行文件为测试可执行文件,对于正式环境,在所述服务容器中运行的可执行文件为正式可执行文件。
6.一种应用程序部署装置,其特征在于,包括:设于内网的源代码库及打包构建模块,和设于外网或DMZ区的可执行文件库、配置文件库及应用服务器;
所述源代码库,用于存储用户提交的源代码;
所述打包构建模块,用于在监测到所述源代码库中的源代码有更新时,从所述源代码库中拉取更新后的源代码,对更新后的源代码进行打包处理,生成可执行文件,并上传至所述可执行文件库;
所述可执行文件库,用于存储所述打包构建模块上传的可执行文件;
所述应用服务器,用于创建对应配置环境的服务容器,并在所述服务容器中运行可执行文件,启动所述服务容器;其中,在运行可执行文件时,通过预设的查找路径查找得到对应配置环境的配置文件,所述配置环境包括测试环境和正式环境;
所述配置文件库,用于存储用户提交的配置文件。
7.如权利要求6所述的应用程序部署装置,其特征在于,所述应用服务器还用于:
在等待预设的时长阈值后,验证对应配置环境的服务是否启动成功。
8.如权利要求6所述的应用程序部署装置,其特征在于,所述应用服务器还用于:
在监测到可执行文件有更新时,拉取更新后的可执行文件和更新后的配置文件存放于所述应用服务器中,或拉取预设版本的可执行文件和预设版本的配置文件存放于所述应用服务器中;
当判断到所述应用服务器存在测试服务容器时,删除所述测试服务容器;
将存放于所述应用服务器中的可执行文件和配置文件挂载到新的测试服务容器;
创建新的测试服务容器,在所述新的测试服务容器中运行可执行文件,并启动新的测试服务容器;其中,在运行可执行文件时,通过预设的查找路径在所述应用服务器中查找得到对应测试环境的配置文件。
9.如权利要求6所述的应用程序部署装置,其特征在于,所述应用服务器还用于:
响应于用户的部署指令,拉取更新后的可执行文件和更新后的配置文件存放于所述应用服务器中,或拉取预设版本的可执行文件和预设版本的配置文件存放于所述应用服务器中;
当判断到所述应用服务器存在正式服务容器时,删除所述正式服务容器;
将存放于所述应用服务器中的可执行文件和配置文件挂载到新的正式服务容器;
创建新的正式服务容器,在所述新的正式服务容器中运行可执行文件,并启动新的正式服务容器;其中,在运行可执行文件时,通过预设的查找路径在所述应用服务器中查找得到对应正式环境的配置文件。
10.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质包括存储的计算机程序;其中,所述计算机程序在运行时控制所述计算机可读存储介质所在的设备执行如权利要求1~5任一项所述的应用程序部署方法。
CN202211513077.XA 2022-11-30 2022-11-30 一种应用程序部署方法、装置及存储介质 Pending CN115599399A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202211513077.XA CN115599399A (zh) 2022-11-30 2022-11-30 一种应用程序部署方法、装置及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211513077.XA CN115599399A (zh) 2022-11-30 2022-11-30 一种应用程序部署方法、装置及存储介质

Publications (1)

Publication Number Publication Date
CN115599399A true CN115599399A (zh) 2023-01-13

Family

ID=84852388

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211513077.XA Pending CN115599399A (zh) 2022-11-30 2022-11-30 一种应用程序部署方法、装置及存储介质

Country Status (1)

Country Link
CN (1) CN115599399A (zh)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107908421A (zh) * 2017-09-29 2018-04-13 北京创鑫旅程网络技术有限公司 软件代码版本管理与发布的方法及装置
CN109086069A (zh) * 2018-10-24 2018-12-25 特瓦特能源科技有限公司 一种后台服务无缝升级方法及其装置
CN109358858A (zh) * 2018-09-19 2019-02-19 网易(杭州)网络有限公司 自动化部署方法、装置、介质及电子设备
CN109871241A (zh) * 2019-01-02 2019-06-11 石化盈科信息技术有限责任公司 一种跨环境应用服务器的配置方法
CN113703730A (zh) * 2021-08-30 2021-11-26 平安普惠企业管理有限公司 持续集成方法、装置、计算机设备及存储介质
CN114995835A (zh) * 2022-05-27 2022-09-02 珠海格力电器股份有限公司 一种应用自动化部署方法、系统、设备和可读存储介质

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107908421A (zh) * 2017-09-29 2018-04-13 北京创鑫旅程网络技术有限公司 软件代码版本管理与发布的方法及装置
CN109358858A (zh) * 2018-09-19 2019-02-19 网易(杭州)网络有限公司 自动化部署方法、装置、介质及电子设备
CN109086069A (zh) * 2018-10-24 2018-12-25 特瓦特能源科技有限公司 一种后台服务无缝升级方法及其装置
CN109871241A (zh) * 2019-01-02 2019-06-11 石化盈科信息技术有限责任公司 一种跨环境应用服务器的配置方法
CN113703730A (zh) * 2021-08-30 2021-11-26 平安普惠企业管理有限公司 持续集成方法、装置、计算机设备及存储介质
CN114995835A (zh) * 2022-05-27 2022-09-02 珠海格力电器股份有限公司 一种应用自动化部署方法、系统、设备和可读存储介质

Similar Documents

Publication Publication Date Title
CN110572436B (zh) 多地跨集群的服务器部署方法及系统
CN110768833B (zh) 基于kubernetes的应用编排部署方法及装置
CN106933635B (zh) Docker镜像生成方法及Docker容器
CN110752947A (zh) 一种k8s集群部署方法及装置,一种部署平台
CN111651352B (zh) 一种仓库代码的合并方法及装置
CN112860282B (zh) 集群插件的升级方法、装置和服务器
WO2020000811A1 (zh) 应用组件部署方法、装置及计算机存储介质
CN112130871A (zh) 远程部署中间件的方法、装置、计算机设备及存储介质
US10606730B2 (en) Networked digital data processor log file viewer
CN112860645A (zh) 一种离线压缩文件的处理方法、装置、计算机设备及介质
CN112702195A (zh) 网关配置方法、电子设备及计算机可读存储介质
CN112363731A (zh) 一种应用自动化部署方法、装置和计算机可读存储介质
CN115086287A (zh) 一种软件产品自动部署方法及系统
US11449324B2 (en) Automatic updating of an application executing on an application server
CN111831567B (zh) 应用的测试环境配置方法、装置、系统和介质
CN112732265B (zh) 一种数据处理方法和相关装置
US7437705B1 (en) System and method for building an application on a computing device which includes an environment-controlling process
CN111930466A (zh) 一种基于Kubernetes的数据同步环境部署方法和装置
CN112130889A (zh) 资源的管理方法和装置、存储介质、电子装置
CN112333229A (zh) kubernetes节点扩展方法、装置、设备及存储介质
Manases et al. Automation of Network Traffic Monitoring using Docker images of Snort3, Grafana and a custom API
CN115599399A (zh) 一种应用程序部署方法、装置及存储介质
CN114879977A (zh) 应用部署方法、装置及存储介质
CN112685102B (zh) 一种网关插件热加载方法、装置、设备及介质
CN115080338A (zh) 一种自动监测边缘设备容器内应用进程的系统及方法

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication

Application publication date: 20230113

RJ01 Rejection of invention patent application after publication