CN114995962B - 一种通过初始化容器来加载应急补丁的方法 - Google Patents
一种通过初始化容器来加载应急补丁的方法 Download PDFInfo
- Publication number
- CN114995962B CN114995962B CN202210943870.7A CN202210943870A CN114995962B CN 114995962 B CN114995962 B CN 114995962B CN 202210943870 A CN202210943870 A CN 202210943870A CN 114995962 B CN114995962 B CN 114995962B
- Authority
- CN
- China
- Prior art keywords
- container
- file
- initialization
- jar
- class 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.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45562—Creating, deleting, cloning virtual machine instances
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45575—Starting, stopping, suspending or resuming virtual machine instances
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Stored Programmes (AREA)
Abstract
本发明公开了一种通过初始化容器来加载应急补丁的方法，该方法包括以下步骤：S1、根据用户请求，使用注解标识应用需要替换的Class文件；S2、利用Kubernetes在资源对象创建时触发回调服务；S3、所述回调服务根据注解信息，修改资源对象的描述定义信息，增加初始化容器；S4、Kubernetes完成修订后的资源对象的创建，并调度容器实例到具体节点上运行；S5、运行时先启动初始化容器，所述初始化容器将所述Class文件更新到Jar包中；S6、所述原容器正常启动，加载修改后的Jar包并运行。本发明实现Class文件自动化更新，无须修改容器的启动逻辑、制作容器镜像，实现快速的版本更新。
Description
技术领域
本发明涉及DevOps领域，具体来说，涉及一种通过初始化容器来加载应急补丁的方法。
背景技术
在软件交付过程中，很多场景都需要通过替换Java应用中的Class文件来实现版本更新，比如：生产***发现一个紧急的缺陷，需要尽快修复。如果更新整个版本或者重新构建所有Jar包文件，可能会引入很多未经充分验证的变更，因此为了控制变更范围，最安全的方案就是只更新这一处代码逻辑所属的Class文件。另外，在研发和交付分处异地的场景下，如果每次都全部重新打包、测试、发布容器镜像，不但整个流程非常长，而且因为发布包非常大，沟通和传输时间长，无法满足快速修复缺陷的时效要求。
目前越来越多的应用采用容器化的方式进行交付，并普遍使用容器编排引擎来管理应用，目前最为主流的容器平台是Kubernetes，利用Kubernetes来实现自动化的部署和运维。与传统的虚拟机部署方式相比，容器平台实现了自动化的资源调度，提高了运维效率，但是也让一些传统运维手段无法再使用，比如传统方式下，如果我们需要替换某个Java应用的Class文件，可以直接登录到虚拟机中直接停止进程，修改Jar文件，然后再启动。但是容器交付模式下，容器是动态调度的，容器内文件的修改是易失的，如果直接修改文件，当重启进程生效修改时会造成容器重建，修改内容会被重置，无法实现替换Class文件的目标。为了解决这个问题，现有的容器化Java应用实现Class文件替换的方法有：
1) 重新制作镜像。主要原理是从原镜像中下载Jar文件，将Class合入后再制作成新的镜像文件，并升级新的镜像文件。这种方案有如下问题，首先需要在现场部署容器镜像制作平台，并管理镜像仓库授权等，需要额外占用资源，流程长，耗时长，同时由于重新制作了镜像，也存在变更范围蔓延的风险。同时如果有多个版本的容器镜像，每个版本都需要全部制作一遍，否则版本升级或者回滚时会冲掉原来的修改内容，并且需要通知容器镜像所有的相关方，所有版本更新必须先合入这个Class后再做升级。可以看出这个方法比较复杂，并且协作较多，变更容易被遗漏。
2) 修改容器，在进程启动前进行文件下载和替换。这种方法无须重新制作镜像，而是在容器中放入一个专门的程序（通常是一个脚本），并修改容器启动命令，容器启动后先执行这个脚本，在脚本中从外部存储拉取Class文件，然后合入到Jar文件中，然后再启动原来的Java进程。这种方式在进程启动之前进行替换，无须重新制作镜像，但是这个方法对容器启动逻辑有侵入性修改，需要提前埋入脚本，解决存活探针失效问题，不具备通用性。
3) 在进程运行过程中通过热更新方式进行Class替换。在Java程序运行时，利用JVM本身提供的热更新能力，在不停进程的情况下直接进行替换。但是这种方法只能支持方法级修改等非常窄的场景，无法满足项目的需要。
这些方法都存在一些缺陷，也没有充分利用Kubernetes本身能力，因此并非Kubernetes平台上应用加载Class的最优方案，需要提出了一种充分利用Kubernetes的扩展能力来实现的更优的Java应用替换Class文件方案。
针对相关技术中的问题，目前尚未提出有效的解决方案。
发明内容
针对相关技术中的问题，本发明提出一种通过初始化容器来加载应急补丁的方法，以克服现有相关技术所存在的上述技术问题。
为此，本发明采用的具体技术方案如下：
一种通过初始化容器来加载应急补丁的方法，该方法包括以下步骤：
S1、根据用户请求，使用注解标识应用需要替换的Class文件；
S2、利用Kubernetes在资源对象创建时触发回调服务；
S3、所述回调服务根据注解信息，修改资源对象的描述定义信息，增加初始化容器，并返回修订内容至Kubernetes；
S4、Kubernetes完成修订后的资源对象的创建，并调度容器实例到具体节点上运行；
S5、运行时先启动初始化容器，所述初始化容器将所述Class文件更新到Jar包中，并覆盖原容器中的原始Jar包；
S6、所述原容器正常启动，加载修改后的Jar包并运行。
进一步的，所述根据用户请求，使用注解标识应用需要替换的Class文件，包括以下步骤：
S11、根据应用的创建或更新请求，在最小修改范围内修改Java代码实现相应功能，并将修改后的Java文件编译成对应的Class文件；
S12、利用Kubernetes的Configmap对象来存放所述Class文件以及对应的Jar包路径和类路径信息；
S13、修订Kubernetes平台上部署的应用Workload对象的描述，在其内部Pod对象的元数据字段增加一个注解，并将值设定为Configmap资源对象名。
进一步的，所述利用Kubernetes在资源对象创建时触发回调服务，包括以下步骤：
S21、通过新增Kubernetes的MutatingWebhookConfiguration在Kubernetes平台中新增一个动态准入控制策略；
S22、所述动态准入控制策略在Kubernetes创建Pod资源时自动触发一个准入控制器插件的回调服务。
进一步的，所述Kubernetes采用滚动更新的方式逐步更换Pod实例。
进一步的，所述回调服务根据注解信息，修改资源对象的描述定义信息，增加初始化容器，并返回修订内容至Kubernetes，包括以下步骤：
S31、当接收到Kubernetes的回调请求后，从参数中获取应用的Pod资源对象的描述定义信息；
S32、判断所述描述定义信息中元数据字段是否存在需要更新Class文件的注解，如果不存在，则直接返回结束；
S33、如果存在需要更新Class文件的注解，根据注解的值找到对应的Configmap信息；
S34、根据所述Configmap信息，向Pod对象中增加一个初始化容器，同时初始化容器的入口程序替换为更新Class文件的脚本，并挂载至Configmap；
S35、根据所述Configmap信息，向Pod对象增加一个共享卷，并将共享卷同时挂载到初始化容器和原容器中；
S36、将Pod资源描述的修订内容返回给Kubernetes完成资源对象的编辑。
进一步的，所述Configmap信息包括存放的Class文件以及路径和类路径信息。
进一步的，所述初始化容器通过使用与原容器相同的容器镜像创建得到。
进一步的，所述运行时先启动初始化容器，所述初始化容器将所述Class文件更新到Jar包中，并覆盖原容器中的原始Jar包，包括以下步骤：
S51、利用初始化容器读取原容器的文件，并在原文件基础上进行增量修改；
S52、所述初始化容器通过卷挂载的方式将Class文件信息挂载到初始化容器中；
S53、利用所述初始化容器将Jar文件放置到共享卷中；
S54、将所述共享卷同时挂载到所述初始化容器和原容器，并且路径与原Jar路径一致，实现对原容器文件的修改。
进一步的，所述利用所述初始化容器将Jar文件放置到共享卷中，包括以下步骤：
S531、依据所述Configmap信息将初始化容器的入口程序修改为一段Shell脚本，
S532、读取所述Jar包，并利用所述Shell脚本使用jar-uf命令用新的Class文件覆盖Jar文件对应的Class文件；
S533、将合并后的Jar文件存放到共享卷中。
进一步的，所述共享卷通过使用Kubernetes的EmptyDir存储卷实现创建。
本发明的有益效果为：通过利用自动注入初始化容器和共享卷等机制实现了Class文件的自动替换；即首先利用Kubernetes平台的扩展机制为需要更新Class文件的Java应用容器自动注入一个初始化容器，并在初始化容器中读取原Jar包并更新对应的Class文件，然后将修改后的Jar包通过共享卷挂载到原容器中，覆盖原容器中的Jar文件，从而实现Class文件的自动化更新，且无须修改容器的启动逻辑，无须制作容器镜像，能够透明、无侵入的将Class文件更新到Kubernetes平台的Java应用中，实现快速的版本更新，并且具备以下优点：
1. 精准控制变更范围，只修改少数几个Class文件来完成变更，其余保持不变，能够实现安全快速修复线上故障等场景；
2. 无须重新制作容器镜像，避免了制作镜像造成的流程和耗时长，容易引入未知变更等问题，同时这个过程是在容器应用启动时自动执行，能够避免遗漏等问题；
3. 具备良好兼容性，Jar包的修改是在独立的初始化容器中进行的，对原始容器无侵入，不影响其启动流程，相互隔离，避免因为修改Jar包而引起容器启动异常等问题；
4. 方法灵活高效，替换Jar包中的Class文件可以摆脱JVM热加载更新的限制，同时可以直接在启动时按需选择要加载哪些Class，后续过程全部自动化完成，使用者无须了解实现细节，对运维人员友好；
5. 通用性好，仅仅依赖Kubernetes自身的扩展机制，对应用描述文件、Java版本、容器基础镜像、容器启动命令等没有限定条件，只要是运行在Kubernetes上的应用都可以利用本发明来替换Class文件来解决环境上的紧急问题。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是根据本发明实施例的一种通过初始化容器来加载应急补丁的方法的流程图；
图2是根据本发明实施例的一种通过初始化容器来加载应急补丁的方法中增量修改Jar文件的示意图；
图3是根据本发明实施例的一种通过初始化容器来加载应急补丁的方法中基于Kubernetes实现方案的整体流程原理图；
图4是根据本发明实施例的一种通过初始化容器来加载应急补丁的方法中Kubernetes回调服务的逻辑示意图；
图5是根据本发明实施例的一种通过初始化容器来加载应急补丁的方法中更新覆盖容器内Jar包文件的原理示意图。
具体实施方式
根据本发明的实施例，提供了一种通过初始化容器来加载应急补丁的方法。
现结合附图和具体实施方式对本发明进一步说明，如图1-5所示，根据本发明实施例的通过初始化容器来加载应急补丁的方法，该方法包括以下步骤：
S1、根据用户请求，使用注解标识应用需要替换的Class文件，包括以下步骤：
S11、根据应用的创建或更新请求（当要求在最小化变更要求下创建或更新应用），在最小修改范围内修改Java代码实现相应功能，并将修改后的Java文件编译成对应的Class文件（研发人员仅需要将这些Class文件从研发中心发送到项目现场）；
S12、（运维人员）利用Kubernetes的Configmap对象来存放所述Class文件以及对应的Jar包路径和类路径信息；
S13、修订Kubernetes平台上部署的应用Workload对象的描述，在其内部Pod对象的元数据(metadata)字段增加一个注解(annotation)，并将值设定为Configmap资源对象名（表示此Java应用需要加载对应的Class文件）。
S2、利用Kubernetes在资源对象创建时触发回调服务，包括以下步骤：
S21、通过新增Kubernetes的MutatingWebhookConfiguration在Kubernetes平台中新增一个动态准入控制策略；
S22、所述动态准入控制策略在Kubernetes创建Pod资源时自动触发一个准入控制器插件（MutatingAdmissionWebhook）的回调服务。
其中，所述Kubernetes采用滚动更新的方式逐步更换Pod实例。
完成Pod的重新创建的同时完成Class文件的更新，指定应用的Kubernetesworkload对象的updateStrategy为Rollingupdate方式，则Kubernetes会使用滚动更新的方式来逐步更换Pod实例。滚动更新过程中会重新创建Pod，使用滚动更新方法可以实现业务不中断的情况下完成Class文件的更新。
S3、所述回调服务根据注解信息，修改资源对象的描述定义信息，增加初始化容器，并返回修订内容至Kubernetes；
如图4所示，步骤S3包括以下步骤：
S31、当接收到Kubernetes的回调请求后，从参数中获取应用的Pod资源对象的描述定义信息；
S32、判断所述描述定义信息中元数据字段是否存在需要更新Class文件的注解，如果不存在，则直接返回结束；
S33、如果存在需要更新Class文件的注解，根据注解的值找到对应的Configmap信息；
其中，所述Configmap信息包括存放的Class文件以及路径和类路径信息。
S34、根据所述Configmap信息，向Pod对象中增加一个初始化容器，同时初始化容器的入口程序替换为更新Class文件的脚本，并挂载至Configmap；
其中，所述初始化容器通过使用与原容器相同的容器镜像创建得到。
S35、根据所述Configmap信息，向Pod对象增加一个共享卷，并将共享卷同时挂载到初始化容器和原容器中；
S36、将Pod资源描述的修订内容返回给Kubernetes完成资源对象的编辑。
S4、Kubernetes完成修订后的资源对象的创建，并调度容器实例到具体节点上运行；
S5、运行时先启动初始化容器，所述初始化容器将所述Class文件更新到Jar包中，并覆盖原容器中的原始Jar包；
如图5所示，步骤S5包括以下步骤：
S51、利用初始化容器读取原容器的文件，并在原文件基础上进行增量修改；
S52、所述初始化容器通过卷挂载的方式将Class文件信息挂载到初始化容器中；
S53、利用所述初始化容器将Jar文件放置到共享卷中；
所述利用所述初始化容器将Jar文件放置到共享卷中，包括以下步骤：
S531、依据所述Configmap信息将初始化容器的入口程序修改为一段Shell脚本，
S532、读取所述Jar包，并利用所述Shell脚本使用jar-uf命令用新的Class文件覆盖Jar文件对应的Class文件；
S533、将合并后的Jar文件存放到共享卷中。
S54、将所述共享卷同时挂载到所述初始化容器和原容器，并且路径与原Jar路径一致，实现对原容器文件的修改。
其中，所述共享卷通过使用Kubernetes的EmptyDir存储卷实现创建。
S6、所述原容器正常启动，加载修改后的Jar包并运行。
此外，图2为增量修改Jar文件的示意图。如图2所示，假设现场出现某个异常，经过排查分析后，需要修改Java的类A，从1.0版本修改为1.1版本，此时方法是，开发直接修改类A相关的代码，并导出类A对应的Class文件，然后基于现场的Jar包合并成新的Jar包文件，这样严格控制了变更的范围，避免了直接升级整个Jar包而引入不相关的类B、类C的修改。
本发明基于Kubernetes平台，Kubernetes拥有非常丰富的扩展能力，并利用以下机制：
1）自动注入机制是指用户可以向Kubernetes注册一个回调函数，当用户创建对象时（比如部署或者升级应用），Kubernetes会自动回调这个函数，在这个函数中可以对原始对象进行一些编辑，比如增加存储卷，增加边车容器或者初始化容器等，这个过程能够自动化完成，用户无感知。可以利用这个机制对用户透明的增加一些功能。
2）初始化容器机制是指Kubernetes平台上用户可以为应用容器指定一个或者多个初始化容器，在应用容器启动之前会先运行初始化容器。用户可以利用初始化容器机制来做一些准备性的工作，初始化容器与原容器是两个独立的容器。
3）存储卷是Kubernetes平台提供的一种能力，能够将各种外部存储挂载到容器中供应用使用，对于某些类型的存储卷可以同时挂载到多个容器中，从而实现不同容器之间数据的共享。
并且本发明中运用到的相关格式与文件类型包括：
①Jar：Java软件包的格式，内部包含了编译后的类文件(class文件)和元数据等应用运行需要的数据
②Class文件：Java类文件经过编译之后生成的字节码文件
③Configmap：Kubernetes平台的一种资源对象的名称，可以将配置等文件保存到这种资源对象中，然后挂载给应用使用。
④Pod：Kubernetes平台上一种对象的名称，是最小的部署逻辑单位，由一个或者多个容器组成。
⑤EmptyDir：Kubernetes平台上存储卷(Volume)的一种模式的名称，主要用于存放临时文件。
⑥subPath：Kubernetes平台上挂载存储卷(Volume)的一个参数的名称，用于指定存储卷的路径信息。
以下通过一个具体的实施例来对本发明做进一步说明。
本实施例基于当前主流的容器编排引擎Kubernetes，以一个Java无状态容器化应用web-demo为例，描述其具体的技术实现，web-demo程序包含一个jar文件:web.jar，存放路径为/app/lib/web.jar，需要加载的应急补丁文件为WebController.class，class文件原始存放路径为jar包内的\BOOT-INF\classes\com\example\controller。
具体的实施步骤如下：
步骤一、使用Kubectl create configmap命令将应急补丁class文件和路径等信息存放到Kubernetes的Configmap对象中，命名为hotfix-demo。
步骤二、在web-demo应用描述文件中增加一个注解，名称为injector.hotfix.zcm/request，值为hotfix-demo，表示这个应用需要加载hotfix-demo补丁。
步骤三、在Kubernetes中增加一个MutatingWebhookConfiguration对象，为Kubernetes的Pod创建事件新增一个MutatingAdmissionWebhook回调。
步骤四、使用Golang开发一个回调服务，判断如果Pod资源存在injector.hotfix.zcm/request注解，则***初始化容器和共享卷信息。
步骤五、在回调函数中通过指定command参数修改初始化容器的入口程序，本实施例中这个值修改为如下的内容:
bash -c "cp /app/lib/web.jar /hotfix-patched/
mkdir -p /hotfix-patched/BOOT-INF/classes/com/example/controller/
cp/hotfix-demo/WebController.class /hotfix-patched/BOOT-INF/classes/com/example/controller/
cd /hotfix-patched/
jar-uf web.jar ./BOOT-INF/classes/com/example/controller/WebController.class"
步骤六、在回调函数中为初始化容器和原容器添加存储卷信息，本实施例增加的相关内容如下:
spec:
containers:
volumeMounts:
- mountPath: /app/lib/web.jar
name: hotfix
subPath: web.jar
initContainers:
volumeMounts:
- mountPath: /hotfix-patched/
name: hotfix
- mountPath: /hotfix-demo/
name: hotfix-demo
volumes:
- emptyDir: {}
name: hotfix
- configMap:
name: hotfix-demo
name: hotfix-demo
步骤七、用户使用Kubectl rolling-update命令来对应用进行滚动更新(Deployment默认updateStrategy为Rollingupdate，滚动更新过程中分批次创建和销毁容器，但不会造成业务中断，可以无业务中断的完成Class文件的更新和应用。
综上所述，借助于本发明的上述技术方案，通过利用自动注入初始化容器和共享卷等机制实现了Class文件的自动替换；即首先利用Kubernetes平台的扩展机制为需要更新Class文件的Java应用容器自动注入一个初始化容器，并在初始化容器中读取原Jar包并更新对应的Class文件，然后将修改后的Jar包通过共享卷挂载到原容器中，覆盖原容器中的Jar文件，从而实现Class文件的自动化更新，且无须修改容器的启动逻辑，无须制作容器镜像，能够透明、无侵入的将Class文件更新到Kubernetes平台的Java应用中，实现快速的版本更新；并且具备以下优点：
1. 精准控制变更范围，只修改少数几个Class文件来完成变更，其余保持不变，能够实现安全快速修复线上故障等场景；
2. 无须重新制作容器镜像，避免了制作镜像造成的流程和耗时长，容易引入未知变更等问题，同时这个过程是在容器应用启动时自动执行，能够避免遗漏等问题；
3. 具备良好兼容性，Jar包的修改是在独立的初始化容器中进行的，对原始容器无侵入，不影响其启动流程，相互隔离，避免因为修改Jar包而引起容器启动异常等问题；
4. 方法灵活高效，替换Jar包中的Class文件可以摆脱JVM热加载更新的限制，同时可以直接在启动时按需选择要加载哪些Class，后续过程全部自动化完成，使用者无须了解实现细节，对运维人员友好；
5. 通用性好，仅仅依赖Kubernetes自身的扩展机制，对应用描述文件、Java版本、容器基础镜像、容器启动命令等没有限定条件，只要是运行在Kubernetes上的应用都可以利用本发明来替换Class文件来解决环境上的紧急问题。
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
Claims (8)
1.一种通过初始化容器来加载应急补丁的方法，其特征在于，该方法包括以下步骤：
S1、根据用户请求，使用注解标识应用需要替换的Class文件；
S2、利用Kubernetes在资源对象创建时触发回调服务；
S3、所述回调服务根据注解信息，修改资源对象的描述定义信息，增加初始化容器，并返回修订内容至Kubernetes；
S4、Kubernetes完成修订后的资源对象的创建，并调度容器实例到具体节点上运行；
S5、运行时先启动初始化容器，所述初始化容器将所述Class文件更新到Jar包中，并覆盖原容器中的原始Jar包；
S6、所述原容器正常启动，加载修改后的Jar包并运行；
其中，所述回调服务根据注解信息，修改资源对象的描述定义信息，增加初始化容器，并返回修订内容至Kubernetes，包括以下步骤：
S31、当接收到Kubernetes的回调请求后，从参数中获取应用的Pod资源对象的描述定义信息；
S32、判断所述描述定义信息中元数据字段是否存在需要更新Class文件的注解，如果不存在，则直接返回结束；
S33、如果存在需要更新Class文件的注解，根据注解的值找到对应的Configmap信息；
S34、根据所述Configmap信息，向Pod对象中增加一个初始化容器，同时初始化容器的入口程序替换为更新Class文件的脚本，并挂载至Configmap；
S35、根据所述Configmap信息，向Pod对象增加一个共享卷，并将共享卷同时挂载到初始化容器和原容器中；
S36、将Pod资源描述的修订内容返回给Kubernetes完成资源对象的编辑；
所述运行时先启动初始化容器，所述初始化容器将所述Class文件更新到Jar包中，并覆盖原容器中的原始Jar包，包括以下步骤：
S51、利用初始化容器读取原容器的文件，并在原文件基础上进行增量修改；
S52、所述初始化容器通过卷挂载的方式将Class文件信息挂载到初始化容器中；
S53、利用所述初始化容器将Jar文件放置到共享卷中；
S54、将所述共享卷同时挂载到所述初始化容器和原容器，并且路径与原Jar路径一致，实现对原容器文件的修改。
2.根据权利要求1所述的一种通过初始化容器来加载应急补丁的方法，其特征在于，所述根据用户请求，使用注解标识应用需要替换的Class文件，包括以下步骤：
S11、根据应用的创建或更新请求，在最小修改范围内修改Java代码实现相应功能，并将修改后的Java文件编译成对应的Class文件；
S12、利用Kubernetes的Configmap对象来存放所述Class文件以及对应的Jar包路径和类路径信息；
S13、修订Kubernetes平台上部署的应用Workload对象的描述，在其内部Pod对象的元数据字段增加一个注解，并将值设定为Configmap资源对象名。
3.根据权利要求2所述的一种通过初始化容器来加载应急补丁的方法，其特征在于，所述利用Kubernetes在资源对象创建时触发回调服务，包括以下步骤：
S21、通过新增Kubernetes的MutatingWebhookConfiguration在Kubernetes平台中新增一个动态准入控制策略；
S22、所述动态准入控制策略在Kubernetes创建Pod资源时自动触发一个准入控制器插件的回调服务。
4.根据权利要求3所述的一种通过初始化容器来加载应急补丁的方法，其特征在于，所述Kubernetes采用滚动更新的方式逐步更换Pod实例。
5.根据权利要求4所述的一种通过初始化容器来加载应急补丁的方法，其特征在于，所述Configmap信息包括存放的Class文件以及路径和类路径信息。
6.根据权利要求5所述的一种通过初始化容器来加载应急补丁的方法，其特征在于，所述初始化容器通过使用与原容器相同的容器镜像创建得到。
7.根据权利要求6所述的一种通过初始化容器来加载应急补丁的方法，其特征在于，所述利用所述初始化容器将Jar文件放置到共享卷中，包括以下步骤：
S531、依据所述Configmap信息将初始化容器的入口程序修改为一段Shell脚本，
S532、读取所述Jar包，并利用所述Shell脚本使用jar-uf命令用新的Class文件覆盖Jar文件对应的Class文件；
S533、将合并后的Jar文件存放到共享卷中。
8.根据权利要求7所述的一种通过初始化容器来加载应急补丁的方法，其特征在于，所述共享卷通过使用Kubernetes的EmptyDir存储卷实现创建。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210943870.7A CN114995962B (zh) | 2022-08-08 | 2022-08-08 | 一种通过初始化容器来加载应急补丁的方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210943870.7A CN114995962B (zh) | 2022-08-08 | 2022-08-08 | 一种通过初始化容器来加载应急补丁的方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114995962A CN114995962A (zh) | 2022-09-02 |
| CN114995962B true CN114995962B (zh) | 2022-12-02 |
Family
ID=83023075
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210943870.7A Active CN114995962B (zh) | 2022-08-08 | 2022-08-08 | 一种通过初始化容器来加载应急补丁的方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114995962B (zh) |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109947452A (zh) * | 2019-03-26 | 2019-06-28 | 南京联创信息科技有限公司 | 一种Kubernetes容器平台应用更新方法 |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105404524B (zh) * | 2014-09-15 | 2019-01-15 | 阿里巴巴集团控股有限公司 | Java应用中的类加载隔离方法及装置 |
| US10296323B2 (en) * | 2016-02-02 | 2019-05-21 | ZeroTurnaround AS | System and method for fast initial and incremental deployment of apps |
| CN110780822B (zh) * | 2019-10-28 | 2023-09-19 | 浪潮云信息技术股份公司 | 一种管理容器云本地存储***及实现方法 |
| CN114489927A (zh) * | 2021-12-13 | 2022-05-13 | 航天信息股份有限公司 | 一种解耦依赖文件的容器部署方法及*** |
| CN114706767A (zh) * | 2022-03-24 | 2022-07-05 | 网易（杭州）网络有限公司 | 一种代码覆盖率采集方法、装置及设备 |
-
2022
- 2022-08-08 CN CN202210943870.7A patent/CN114995962B/zh active Active
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109947452A (zh) * | 2019-03-26 | 2019-06-28 | 南京联创信息科技有限公司 | 一种Kubernetes容器平台应用更新方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114995962A (zh) | 2022-09-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7539985B2 (en) | Systems and methods for dynamic component versioning | |
| JP4878715B2 (ja) | オペレーティングシステムに適合しないアプリケーションにパッチを当てる方法、コンピュータシステム及びコンピュータ可読記録媒体 | |
| US7484223B2 (en) | System and method for building a run-time image from components of a software program | |
| CN102053831B (zh) | 一种Linux操作***的定制方法及*** | |
| CN111198744A (zh) | 自动化应用程序容器化和镜像备份发布的方法 | |
| US20040088397A1 (en) | System and method for management of software applications | |
| CN105320554A (zh) | 程序更新的方法、用于程序更新的客户端及*** | |
| CN113238819B (zh) | 一种适用于U-Boot的驱动文件动态加载方法及*** | |
| CN112181858B (zh) | Java软件项目依赖冲突语义一致性的自动化检测方法 | |
| CN107220074A (zh) | 对支撑层软件功能的访问、升级方法及装置 | |
| CA2267549A1 (en) | Loading and unloading of application components | |
| CN116049207A (zh) | 应用程序sql脚本处理方法、装置、处理器及电子设备 | |
| CN114995962B (zh) | 一种通过初始化容器来加载应急补丁的方法 | |
| CN111522623B (zh) | 组件化软件多进程运行*** | |
| CN112565416A (zh) | 基于云原生的大规模边缘安卓设备纳管***及其纳管方法 | |
| CN114398155A (zh) | 一种应用程序自动化部署流水线配置方法及*** | |
| CN113448549B (zh) | 一种前端开发的全流程自动化处理***及方法 | |
| CN111831314B (zh) | 一种针对不可写分区打补丁的方法与装置 | |
| CN115599434A (zh) | MySQL数据库RPM打包方法 | |
| CN115220873A (zh) | 一种在Android***中运行Open Harmony应用的方法 | |
| CN114968277A (zh) | 母片烧录程序文件生成方法、装置、计算机设备和介质 | |
| CN106648797A (zh) | 安装测试软件的方法、***、测试服务器及共享服务器 | |
| CN113590179A (zh) | 插件检测方法、装置、电子设备及存储介质 | |
| CN113849181A (zh) | 交叉编译工具链构建方法、装置、电子设备及存储介质 | |
| CN116594661B (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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |