CN114840226A - 基于sa进行微服务升级版本的管理***及方法 - Google Patents
基于sa进行微服务升级版本的管理***及方法 Download PDFInfo
- Publication number
- CN114840226A CN114840226A CN202210454410.8A CN202210454410A CN114840226A CN 114840226 A CN114840226 A CN 114840226A CN 202210454410 A CN202210454410 A CN 202210454410A CN 114840226 A CN114840226 A CN 114840226A
- Authority
- CN
- China
- Prior art keywords
- file
- version
- service
- package
- upgrade
- 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
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/61—Installation
- G06F8/63—Image based installation; Cloning; Build to order
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Stored Programmes (AREA)
Abstract
本发明涉及物联网技术领域,具体涉及一种基于sa进行微服务升级版本的管理***及方法,包括以下步骤:进入打包程序,构建后端docker镜像文件、前端docker镜像文件、helm Chart包文件及离线安装包文件,进而形成SA包;上传SA包,并在OS上进行解压,获取manifest文件内容及安装环境的***信息;载入镜像,并在指令集操作***的注册中心服务中,注册应用的相关信息;清理旧版本创建的job,执行安装命令,执行SQL后,更新pod,并在健康检查接口有正常响应后,安装成功。本发明有效解决在多个服务升级的情况下,某服务升级了错误的版本后,导致应用整体升级失败。保证服务升级的简易性,减少服务升级带来的变更成本。
Description
技术领域
本发明涉及物联网技术领域,具体涉及一种基于sa进行微服务升级版本的管理***及方法。
背景技术
在现有的物联网操作***中为用户P1部署了一套***环境;客户需要升级常用的功能1和功能n。
而现在技术人员通常是直接操作微服务,对相关微服务的镜像进行升级。由于客户的技术能力残次不齐,且不知道功能是由哪些微服务提供的,通过更新微服务的方式来直接升级功能1和功能n的方案操作难度大且易出错,因此本文提供了一种基于sa进行微服务升级版本的管理***及方法。
发明内容
针对现有技术的不足,本发明公开了一种基于sa进行微服务升级版本的管理***及方法,用于解决由于客户的技术能力残次不齐,且不知道功能是由哪些微服务提供的,通过更新微服务的方式来直接升级功能1和功能n的方案操作难度大且易出错的问题。
本发明通过以下技术方案予以实现:
第一方面,本发明提供了一种基于sa进行微服务升级版本的管理方法,包括以下步骤:
S1初始化进入打包程序,构建后端docker镜像文件、前端docker镜像文件、helmChart包文件及离线安装包文件,进而形成SA包;
S2上传S1中构建的SA包,并在OS上进行解压,获取manifest文件内容及安装环境的***信息;
S3载入镜像,并在指令集操作***的注册中心服务中,注册应用的相关信息;
S4清理旧版本创建的job,执行安装命令,执行SQL后,更新pod,并在健康检查接口有正常响应后,安装成功。
更进一步的,所述方法中,构建Helm Chart包时,替换文件中的各项参数,修改Chart.yaml文件和values.yaml文件。
更进一步的,所述方法中,构建离线安装整合包时,包括以下步骤:
准备整合包工作目录;
准备Docker镜像文件;
准备HelmChart包文件;
准备应用图标文件;
准备manifest文件;
修改manifest.json文件;
构建整合包。
更进一步的,所述方法中,上传SA包,支持分片上传,具体如下:
在浏览器端解析获取文件的MD5值,将文件解析后的MD5值发送给后端,去判断该文件以前是否上传过,
请求服务端判断文件是否上传,如上传完成就直接返回文件地址;
如果曾经上传过返回上次上传的分片索引,后面会从这个索引开始继续上传,每次上传单个分片,等所有分片上传完成后向后端发起一个分片合并请求,所有分片合并成功后会返回文件存储地址给前端。
更进一步的,所述方法中,获取manifest文件内容及安装环境的***信息,包括如下步骤:
***内是否存在和升级包应用code相同的应用code,若存在,则进入下一个判断,若不存在,则中断升级流程;
将安装包的兼容版本字段和***内已安装应用的版本号进行比较,当已安装应用版本号包含在兼容版本号之内,则进入下一个判断,若不包含,则中断升级流程;
获取***内所有服务的版本号,将升级包的依赖服务和***内已有的服务进行比较,当服务版本号一致,则进入下一个判断,若不一致,则中断升级流程。
更进一步的,所述方法中,在指令集操作***的注册中心服务中,注册应用的相关信息包括appcode和版本号。
更进一步的,所述方法中,通过健康检查接口,监听服务是否正常启动,若健康检查接口有正常响应,则安装成功。
更进一步的,所述方法中,通过健康检查接口,监听服务时间小于10分钟。
第二方面,本发明提供了一种基于sa进行微服务升级版本的管理***,包括处理器、存储器以及存储在所述存储器中且被配置为由所述处理器执行的计算机程序,所述存储器与所述处理器耦接,且所述处理器执行所述计算机程序时,实现第一方面所述的基于sa进行微服务升级版本的管理方法步骤。
本发明的有益效果为:
本发明将多个微服务作为一个独立单元“SA”,进行统一的开发和管理,再配合SA版本控制机制,明确SA版本依赖的外部服务,有效解决升级微服务后,因为缺少组件或依赖的服务,导致应用无法正常运行的情况,增加了服务的可靠性。
本发明有效解决在多个服务升级的情况下,某服务升级了错误的版本后,导致应用整体升级失败。保证服务升级的简易性,减少服务升级带来的变更成本。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是基于sa进行微服务升级版本的管理方法原理步骤图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
实施例1
本实施例提供一种基于sa进行微服务升级版本的管理方法,包括以下步骤:
S1初始化进入打包程序,构建后端docker镜像文件、前端docker镜像文件、helmChart包文件及离线安装包文件,进而形成SA包;
S2上传S1中构建的SA包,并在OS上进行解压,获取manifest文件内容及安装环境的***信息;
S3载入镜像,并在指令集操作***的注册中心服务中,注册应用的相关信息;
S4清理旧版本创建的job,执行安装命令,执行SQL后,更新pod,并在健康检查接口有正常响应后,安装成功。
本实施例若干微服务进行升级时,将多个微服务打包成一个应用,在待升级环境中,根据客户需求,自由选择安装包,替换微服务的镜像。
本实施例将若干相关服务进行打包,SA包含服务镜像、SQL、描述文件,***会根据描述文件判断是否适配其他SA。若适配,可以对应服务的镜像和数据库进行更新;若不适配,将无法执行更新。SA通常是以业务能力维度进行集合的。
本实施例应用包内包含微服务、SQL和配置信息。在管理多套环境时,大大提升服务升级的高效性、易用性,及保持客户环境的个性化。
实施例2
在具体实施层面,本实施例提供一种打包方法,包括以下步骤:
本实施例构建前准备,将后端编译的jar文件,放入devops文件夹根目录下。将前端编译后的静态文件,放入devops下的ui目录下。
进入devops文件夹,执行命令mkdir -p release&&rm-rf release,创建并清空release目录。
本实施例构建后端镜像,*以下所有命令,均在devops根目录下执行
后端打包命令
${REPO_NAME}替换为您自己的仓库地址,或者使用默认地址harbor.isyscore.com/application。
${SERVICE_NAME}替换为您的应用名称。
${SERVICE_VERSION}替换为您的应用版本。
${JAR_FILE}替换为您jar包名称。
打包完成后,需要将构建成功的镜像文件保存至release目录下,执行命令:
同样,按照第一步的内容将参数全部替换。
本实施例构建前端镜像,*以下所有命令,均在devops根目录下执行;
由于前端资源文件夹,名称必须为html。所以,需要将您构建成功的静态文件夹重新命名为html。
比如,您的文件夹名字为dist,那么可以执行命令mv ui/dist ui/html将文件夹重命名。
然后,将新的html文件夹,通过命令tar-zcvf ui/html.tar ui/html/打成tar包。
本实施例前端打包命令:
docker build\
-t${REPO_NAME}/${SERVICE_NAME}:${SERVICE_VERSION}\
--build-arg PORT=${SERVICE_PORT}\
--build-arg JAR_FILE="${JAR_FILE}"\
.
1
2
3
4
5
docker save\
-o release/${SERVICE_NAME}-${SERVICE_VERSION}.tar\
${REPO_NAME}/${SERVICE_NAME}:${SERVICE_VERSION}
1
2
3
docker build -t harbor.isyscore.com/application/demo3:v1.0.0--build-arg PORT=9080.
docker save -o release/demo3-v1.0.0.tar harbor.isyscore.com/application/demo3:v1.0.0
1
2${REPO_NAME}替换为您自己的仓库地址,或者使用默认地址harbor.isyscore.com/application。
${SERVICE_NAME}替换为您的应用名称。
${SERVICE_VERSION}替换为您的应用版本。
打包完成后,需要将构建成功的镜像文件保存至release目录下,执行命令:
同样,按照第一步的内容将参数全部替换。
本实施例构建Helm Chart包:
替换文件中的各项参数:
Helm Chart的所有模板文件位于chart_temp文件夹中。您可以将模板文件夹复制一份,以供您多次利用。
Windows和Mac OS X或Linux桌面版用户可以使用文本编辑器,Linux无桌面用户,可以使用sed或者vim
命令,
编辑chart_temp文件夹下Chart.yaml和values.yaml文件。
修改Chart.yaml文件:
将${chart_name}替换为您应用名称。
将${version}和${app_version}都替换为您的应用版本号。
将${app_icon}替换为您应用的icon,如果没有可以替换为空字符。
修改values.yaml文件:
docker build\
-t${REPO_NAME}/${SERVICE_NAME}-ui:${SERVICE_VERSION}\
--build-arg UI_FILE=./ui/html.tar\
-f./ui/Dockerfile\
.
1
2
3
4
5
docker save\
-o release/${SERVICE_NAME}-${SERVICE_VERSION}-ui.tar\
${REPO_NAME}/${SERVICE_NAME}-ui:${SERVICE_VERSION}
1
2
3
docker build -t harbor.isyscore.com/application/demo3-ui:v1.0.0-f./ui/Dockerfile.
docker save -o release/demo3-v1.0.0-ui.tar harbor.isyscore.com/application/demo3-ui:v1.0.0
1
2将${repo_name}替换为您的仓库地址,或者使用默认地址harbor.isyscore.com/application。
将${host}替换为空字符。
将${project_name}、${image_name}替换为您应用的名称。
将${project_dbname}替换为您应用的数据名称。
将${project_dbusername}替换为您应用的数据用户名。
将${project_dbpassword}替换为您应用的数据库密码。
将${port}、${service_port}替换为您应用的服务端口号。
将${uiimage_name}替换为您应用的名称加上-ui后缀。
将${image_tag}、${uiimage_tag}替换为您应用的版本号。
如果,您的应用需要注入启动参数,如-Dspring.profiles.active=test,
将${env_javaopts}替换为您需要注入的参数,如果没有,则替换为空字符串。
本实施打包文件
将替换后的文件保存,然后执行命令:
${SERVICE_NAME}替换为您的应用名称。
${SERVICE_VERSION}替换为您的应用版本。
使用下面的命令,可以将打出的Chart包,移动到release文件夹下:
helm package--app-version${SERVICE_VERSION}--version${SERVICE_VERSION}chart_temp
1同样,按照第一步的内容将参数全部替换。
实施例3
在具体实施层面,本实施例提供一种构建离线安装整合包方法,包括以下步骤:
准备整合包工作目录
执行命令,创建工作目录:
${SERVICE_NAME}替换为您的应用名称。
${SERVICE_VERSION}替换为您的应用版本。
准备Docker镜像文件
执行命令,创建整合Docker镜像:
${REPO_NAME}替换为您自己的仓库地址,或者使用默认地址harbor.isyscore.com/application。
${SERVICE_NAME}替换为您的应用名称。
${SERVICE_VERSION}替换为您的应用版本。
然后,执行命令mv allInOne.tar release/${WORK_DIR},将构建成功的文件,移动至工作目录中。
${WORK_DIR}替换为您的工作目录,如demo3-v1.0.0-installer。
准备HelmChart包文件
在步骤构建Helm Chart包中,已经将Helm Chart包构建成功,此步骤,需要将该文件复制一份至工作目录中。
您可以执行如下命令,完成操作:
mv${SERVICE_NAME}-${SERVICE_VERSION}.tgz release/
1
helm package --app-version v1.0.0 --version v1.0.0 chart_temp
mv demo3-v1.0.0.tgz release/
1
2
mkdir -p release/${SERVICE_NAME}-${SERVICE_VERSION}-installer
1
mkdir -p release/demo3-v1.0.0-installer
1
docker save\
-o allInOne.tar\
"${REPO_NAME}/${SERVICE_NAME}:${SERVICE_VERSION}"\
"${REPO_NAME}/${SERVICE_NAME}-ui:${SERVICE_VERSION}"
1
2
3
4
docker save\
-o allInOne.tar\
"harbor.isyscore.com/application/demo3:v1.0.0"\
"harbor.isyscore.com/application/demo3-ui:v1.0.0}"
1
2
3
4
mv allInOne.tar release/demo3-v1.0.0-installer
1${SERVICE_NAME}替换为您的应用名称。
${SERVICE_VERSION}替换为您的应用版本。
${WORK_DIR}替换为您的工作目录,如demo3-v1.0.0-installer。
准备应用图标文件
如果您在构建时,已经使用-i参数或者已经输入应用的图标连接URL,此步骤可以忽略。
如果您未传入上述参数,您可以将您的应用图标文件,放入工作目录下,并重新命名为${SERVICE_CODE}。在构建时,将图标文件打包入整合包。
本实施例进行优选如,您的图标文件为icon.png,您的SERVICE_CODE为demo3-a380,您的工作目录为demo3-v1.0.0-installer。那么,您需要将文件icon.png复制到文件夹demo3-v1.0.0-installer下,然后,将文件icon.png重命名为demo3-a380.png。
准备manifest文件
您可以将位于manifest文件夹中的模板文件manifest.json,复制到您的工作目录中。
Windows和Mac OS X或Linux桌面版用户可以使用文本编辑器,Linux无桌面用户,可以使用sed或者vim
命令,编辑manifest.json文件。
修改manifest.json文件
将${app_code}替换为您应用Code,如demo3-a380。
将${app_name}替换为您应用名称,如demo3。
将${app_version}替换为您应用版本,如v1.0.0。
将${chart_name}替换为您Helm Chart包名称,如demo3-v1.0.0.tgz。
将${repo_name}替换为您仓库名称,或者使用默认地址harbor.isyscore.com/application。
将${port}替换为您应用端口号,如8080。
将${icon}替换为您应用图标名称或URL,如demo3-a380.png。
构建整合包
可以使用如下命令,构建整合包:
cp release/"${SERVICE_NAME}-${SERVICE_VERSION}".tgz release/${WORK_DIR}
1
cp release/demo3-v1.0.0.tgz release/demo3-v1.0.0-installer
1${WORK_DIR}就是您的工作目录,如demo3-v1.0.0-installer。
然后,将构建出的整合包,移动至release文件夹下。
至此,整个devops操作完成。查看release文件夹,可以获得最终的前端镜像文件、后端镜像文件、Helm Chart文件以及离线安装包文件。
实施例4
在具体实施层面,本实施例提供一种安装步骤,具体如下:
本实施例将SA包在OS上进行安装。上传SA包,支持分片上传,包括以下步骤:
在浏览器端解析获取文件的MD5值(作为文件的唯一key值),把文件解析后的MD5值发送给后端,去判断该文件以前是否上传过;
请求服务端判断文件是否上传,如上传完成就直接返回文件地址;
如果曾经上传过返回上次上传的分片索引,后面会从这个索引开始继续上传,每次上传单个分片,等所有分片上传完成后向后端发起一个分片合并请求,所有分片合并成功后会返回文件存储地址给前端。
本实施例解压SA包,获取manifest文件内容及安装环境的***信息,包括如下步骤:
***内是否存在和升级包应用code相同的应用code,若存在,则进入下一个判断,若不存在,则中断升级流程。
将安装包的兼容版本字段和***内已安装应用的版本号进行比较,当已安装应用版本号包含在兼容版本号之内,则进入下一个判断,若不包含,则中断升级流程
获取***内所有服务的版本号,将升级包的依赖服务和***内已有的服务进行比较,当服务版本号一致,则进入下一个判断,若不一致,则中断升级流程。
判断全部通过后,执行第4步。
本实施例载入镜像,在指令集操作***的注册中心服务中,注册应用的相关信息,如appcode、版本号等。
本实施例清理旧版本创建的job;执行安装命令,执行SQL后,更新pod。
本实施例通过健康检查接口,监听服务是否正常启动,限时10分钟,若健康检查接口有正常响应,则安装成功。
实施例5
本实施例提供一种基于sa进行微服务升级版本的管理***,包括处理器、存储器以及存储在所述存储器中且被配置为由所述处理器执行的计算机程序,所述存储器与所述处理器耦接,且所述处理器执行所述计算机程序时,实现基于sa进行微服务升级版本的管理方法步骤。
综上,本发明将多个微服务作为一个独立单元“SA”,进行统一的开发和管理,再配合SA版本控制机制,明确SA版本依赖的外部服务,有效解决升级微服务后,因为缺少组件或依赖的服务,导致应用无法正常运行的情况,增加了服务的可靠性。
本发明有效解决在多个服务升级的情况下,某服务升级了错误的版本后,导致应用整体升级失败。保证服务升级的简易性,减少服务升级带来的变更成本。
以上实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。
Claims (9)
1.一种基于sa进行微服务升级版本的管理方法,其特征在于,包括以下步骤:
S1初始化进入打包程序,构建后端docker镜像文件、前端docker镜像文件、helm Chart包文件及离线安装包文件,进而形成SA包;
S2上传S1中构建的SA包,并在OS上进行解压,获取manifest文件内容及安装环境的***信息;
S3载入镜像,并在指令集操作***的注册中心服务中,注册应用的相关信息;
S4清理旧版本创建的job,执行安装命令,执行SQL后,更新pod,并在健康检查接口有正常响应后,安装成功。
2.根据权利要求1所述的一种基于sa进行微服务升级版本的管理方法,其特征在于,所述方法中,构建Helm Chart包时,替换文件中的各项参数,修改Chart.yaml文件和values.yaml文件。
3.根据权利要求1所述的一种基于sa进行微服务升级版本的管理方法,其特征在于,所述方法中,构建离线安装整合包时,包括以下步骤:
准备整合包工作目录;
准备Docker镜像文件;
准备HelmChart包文件;
准备应用图标文件;
准备manifest文件;
修改manifest.json文件;
构建整合包。
4.根据权利要求1所述的一种基于sa进行微服务升级版本的管理方法,其特征在于,所述方法中,上传SA包,支持分片上传,具体如下:
在浏览器端解析获取文件的MD5值,将文件解析后的MD5值发送给后端,去判断该文件以前是否上传过,
请求服务端判断文件是否上传,如上传完成就直接返回文件地址;
如果曾经上传过返回上次上传的分片索引,后面会从这个索引开始继续上传,每次上传单个分片,等所有分片上传完成后向后端发起一个分片合并请求,所有分片合并成功后会返回文件存储地址给前端。
5.根据权利要求1所述的一种基于sa进行微服务升级版本的管理方法,其特征在于,所述方法中,获取manifest文件内容及安装环境的***信息,包括如下步骤:
***内是否存在和升级包应用code相同的应用code,若存在,则进入下一个判断,若不存在,则中断升级流程;
将安装包的兼容版本字段和***内已安装应用的版本号进行比较,当已安装应用版本号包含在兼容版本号之内,则进入下一个判断,若不包含,则中断升级流程;
获取***内所有服务的版本号,将升级包的依赖服务和***内已有的服务进行比较,当服务版本号一致,则进入下一个判断,若不一致,则中断升级流程。
6.根据权利要求1所述的一种基于sa进行微服务升级版本的管理方法,其特征在于,所述方法中,在指令集操作***的注册中心服务中,注册应用的相关信息包括appcode和版本号。
7.根据权利要求1所述的一种基于sa进行微服务升级版本的管理方法,其特征在于,所述方法中,通过健康检查接口,监听服务是否正常启动,若健康检查接口有正常响应,则安装成功。
8.根据权利要求7所述的一种基于sa进行微服务升级版本的管理方法,其特征在于,所述方法中,通过健康检查接口,监听服务时间小于10分钟。
9.一种基于sa进行微服务升级版本的管理***,包括处理器、存储器以及存储在所述存储器中且被配置为由所述处理器执行的计算机程序,所述存储器与所述处理器耦接,且所述处理器执行所述计算机程序时,实现如权利要求1至8任一项所述的基于sa进行微服务升级版本的管理方法步骤。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210454410.8A CN114840226A (zh) | 2022-04-27 | 2022-04-27 | 基于sa进行微服务升级版本的管理***及方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210454410.8A CN114840226A (zh) | 2022-04-27 | 2022-04-27 | 基于sa进行微服务升级版本的管理***及方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN114840226A true CN114840226A (zh) | 2022-08-02 |
Family
ID=82567022
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202210454410.8A Pending CN114840226A (zh) | 2022-04-27 | 2022-04-27 | 基于sa进行微服务升级版本的管理***及方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN114840226A (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN116301951A (zh) * | 2023-05-17 | 2023-06-23 | 北京长亭科技有限公司 | 一种基于kubernetes的微服务应用安装升级方法及装置 |
CN117234545A (zh) * | 2023-11-16 | 2023-12-15 | 深圳万物安全科技有限公司 | 应用程序安装方法、装置、终端设备以及存储介质 |
-
2022
- 2022-04-27 CN CN202210454410.8A patent/CN114840226A/zh active Pending
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN116301951A (zh) * | 2023-05-17 | 2023-06-23 | 北京长亭科技有限公司 | 一种基于kubernetes的微服务应用安装升级方法及装置 |
CN116301951B (zh) * | 2023-05-17 | 2023-09-12 | 北京长亭科技有限公司 | 一种基于kubernetes的微服务应用安装升级方法及装置 |
CN117234545A (zh) * | 2023-11-16 | 2023-12-15 | 深圳万物安全科技有限公司 | 应用程序安装方法、装置、终端设备以及存储介质 |
CN117234545B (zh) * | 2023-11-16 | 2024-03-08 | 深圳万物安全科技有限公司 | 应用程序安装方法、装置、终端设备以及存储介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7356816B2 (en) | Method and apparatus for multiplatform migration | |
US8365164B1 (en) | Portable software applications | |
US7937697B2 (en) | Method, system and computer program for distributing software patches | |
US9043778B2 (en) | Method and system for upgrading software | |
CN114840226A (zh) | 基于sa进行微服务升级版本的管理***及方法 | |
US8745610B2 (en) | Maintenance system, maintenance method and program for maintenance | |
US8819670B2 (en) | Automated software installation with interview | |
US8209288B2 (en) | System and method for inspecting a virtual appliance runtime environment | |
US20020124245A1 (en) | Method and apparatus for advanced software deployment | |
US20030195951A1 (en) | Method and system to dynamically detect, download and install drivers from an online service | |
US20040117414A1 (en) | Method and system for automatically updating operating systems | |
US20070294676A1 (en) | Open virtual appliance | |
US20030046682A1 (en) | System and method for the automatic installation and configuration of an operating system | |
US20020010910A1 (en) | Preferable modes of software package deployment | |
US20140082602A1 (en) | Deployment and updating of applications and drivers on a client device using an extensible markup language (xml) configuration file | |
US20140082160A1 (en) | Deployment of a driver or an application on a client device having a write-filter | |
US8776056B2 (en) | Maintenance system, maintenance method and program for maintenance | |
CN112463198B (zh) | 基于Electron的更新方法及*** | |
CN113342387A (zh) | 一种软件自动升级方法、更新客户端及更新服务器 | |
JP2001356912A (ja) | ソフトウェアのインストール/アップデート/アンインストールシステム | |
JP2016064591A (ja) | 情報処理装置、その制御方法、プログラム。 | |
CN113760306A (zh) | 安装软件的方法、装置、电子设备及存储介质 | |
US9760364B2 (en) | Checks for software extensions | |
CN111782236A (zh) | ***软件升级方法、装置、存储介质及一体机设备 | |
US8473943B2 (en) | Using ecoprint for cloning of applications |
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 |