CN115794312A - 基于关注点分离的容器自动化构建部署方法 - Google Patents

Abstract

本发明公开了一种基于关注点分离的容器自动化构建部署方法，减少开发人员工作量、缩短系统交付时间、降低运维成本。其技术方案为：基于关注点分离的思想，一方面将系统组件构建阶段所需的dockerfile文件从代码仓库中抽离，采用无侵入方式，将dockerfile文件的生成转移至编译构建阶段。另一方面，利用流水线编排方式，将构建、部署各项配置抽取成通用模板，通过参数传递对所需数据进行预设。通过持续集成配置，实现容器组件自动化构建、部署。通过这两个方面的设计，可以让开发和运维的任务特征更加明显，低耦合性、高敏捷性地自动化构建、部署方式，能够提高交付效率，实现产品的快速迭代，更低成本地进行业务试错。

Description

基于关注点分离的容器自动化构建部署方法

技术领域

本发明涉及容器构建技术，具体涉及一种基于关注点分离的容器自动化构建部署方法。

背景技术

随着数字化转型在各行业中不断推进，以容器为代表的云原生技术更广泛地被应用。以实践中一个系统通过容器方式构建、k8s云平台部署为例，微服务架构下，一个系统往往被拆分成多个组件(模块)。在容器化构建阶段，每个组件对应的代码仓中会存一份dockerfile文件，根据该文件会构建生成各自的镜像制品。

在容器化部署阶段，需要在组件镜像制品生成并上传至镜像仓后，通过手工方式在k8s云平台配置各项数据，进行部署运行。该流程中存在以下问题：第一，构建阶段，每个组件代码仓中的dockerfile存在大量重复内容，而且对于该组件的开发人员，此文件的内容及后续变更与当前组件业务无关，存在业务冗余；第二，部署阶段，每个组件要手工编排各种配置项，要求开发人员需要掌握一定的运维知识，而且人工操作会增大运维风险；第三，构建、部署没有串联在一起，流程中组件间存在很多共性的操作，导致整个流程繁琐且费时。

发明内容

以下给出一个或多个方面的简要概述以提供对这些方面的基本理解。此概述不是所有构想到的方面的详尽综览，并且既非旨在指认出所有方面的关键性或决定性要素亦非试图界定任何或所有方面的范围。其唯一的目的是要以简化形式给出一个或多个方面的一些概念以为稍后给出的更加详细的描述之序。

本发明的目的在于解决上述问题，提供了一种基于关注点分离的容器自动化构建部署方法，减少开发人员工作量、缩短系统交付时间、降低运维成本。

本发明的技术方案为：本发明揭示了一种基于关注点分离的容器自动化构建部署方法，方法包括前期的静态配置过程以及静态配置完成之后的动态执行过程；

静态配置过程包括以下步骤：

步骤1：在容器化管理数据配置的可视化界面中分别设置dockerfile模板和基础镜像数据；

步骤2：进行组件信息配置：配置组件与dockerfile、基础镜像的关系；

步骤3：预览生成的dockerfile，并在本地验证是否符合预期；

步骤4：进行流水线任务配置，包括代码源配置以及关联gitlab代码仓库，当触发流水线任务时从gitlab代码仓库下载源代码；

步骤5：对容器化构建、部署步骤进行任务编排；

步骤6：配置持续集成项目，静态配置流程结束；

动态执行过程包括以下步骤：

步骤一：在gitlab repo仓的代码发生变动时，判断触发分支/类型是否满足流线持续集成配置，若满足则进入下一步，否则动态执行过程结束；

步骤二：读取构建任务配置环境数据拉取源代码；

步骤三：执行构建任务配置脚本内容生成目标文件；

步骤四：读取构建任务镜像组件信息配置生成dockerfile文件；

步骤五：根据dockerfile文件编译构建生成镜像并推送至镜像仓库；

步骤六：读取部署任务中信息配置调用k8s云平台API部署服务；

步骤七：服务健康探测，探测完成后动态执行过程结束。

根据本发明的基于关注点分离的容器自动化构建部署方法的一实施例，在步骤1中，dockerfile模板的配置包括配置dockerfile模板适用的OS/Arch以及配置dockerfile模板内容；基础镜像数据的配置包括配置OS/Arch以及配置OS/Arch对应的镜像。

根据本发明的基于关注点分离的容器自动化构建部署方法的一实施例，在步骤2中，先选择组件适用的dockerfile模板，再配置组件适用的dockerfile模板中的具体参数，然后选择组件适用的基础镜像。

根据本发明的基于关注点分离的容器自动化构建部署方法的一实施例，在步骤3中，若dockerfile模板内容不符合预期，则跳转到步骤1中的设置dockerfile模板的处理，若基础镜像不符合预期，则跳转到步骤1中的设置基础镜像数据的处理，若dockerfile模板内容和基础镜像均符合预期则进入下一步。

根据本发明的基于关注点分离的容器自动化构建部署方法的一实施例，步骤5进一步包括：

首先是容器化构建阶段，先执行构建脚本生成目标文件，然后读取步骤2中配置的各项数据，通过关联的dockerfile模板填充基本镜像、参数在内的数据，自动生成dockerfile文件，最后根据该dockerfile文件生成docker镜像并推送至镜像仓库；

然后是容器化部署阶段，预先配置k8s云平台部署服务所需要的各项资源及需要部署的分区、应用在内的信息，当流水线被调度执行，构建镜像制品生成后，调用k8s云平台API根据设定创建资源，拉取镜像制品，进行服务部署。

根据本发明的基于关注点分离的容器自动化构建部署方法的一实施例，静态配置过程是基于关注点分离的整体配置，包括容器化管理配置的处理，容器化管理配置的具体配置项包括：基础镜像配置、dockerfile模板配置、组件与基础镜像及dockerfile配置。

根据本发明的基于关注点分离的容器自动化构建部署方法的一实施例，静态配置过程包括流水线任务配置的处理，通过将构建阶段、部署阶段各自共性内容抽取为步骤模板，通过流水线编排方式，实现容器组件构建、部署自动化，其中流水线任务配置的具体配置项包括：代码源repo仓库配置、容器化构建-目标文件生成脚本配置、容器化构建-组件镜像信息配置、容器化部署-基本信息配置、容器化部署-k8s资源配置、容器化部署-服务监控探测配置、流水线持续集成配置。

本发明对比现有技术有如下的有益效果：本发明从关注点分离思路出发，将容器化组件构建、部署过程中的共性数据、操作进行抽取，以使开发、运维的任务耦合性变得更松散。

详细而言，本发明基于关注点分离的思想，一方面将系统组件构建阶段所需的dockerfile文件从代码仓库中抽离，采用无侵入方式，将dockerfile文件的生成转移至编译构建阶段。另一方面，利用流水线编排方式，将构建、部署各项配置抽取成通用模板，通过参数传递对所需数据进行预设。通过持续集成配置，实现容器组件自动化构建、部署。通过这两个方面的设计，可以让开发和运维的任务特征更加明显，低耦合性、高敏捷性地自动化构建、部署方式，能够提高交付效率，实现产品的快速迭代，更低成本地进行业务试错。

对于开发人员，通过传统方式对开发完成的容器组件进行构建、部署流程中，有两个点比较复杂，一个是容器化构建过程中dockerfile文件编写(通常存于组件对应的gitlab仓库，缺少灵活性，与业务无关)，即容器化管理，另一个是不同组件在容器化构建、部署过程中存在大量类似操作(费时费力)，即流水线任务管理。将这两点抽取构成了静态配置过程、动态执行过程。在任务执行过程中，通过参数传值方式屏蔽差异部分，保留共性部分。

附图说明

在结合以下附图阅读本公开的实施例的详细描述之后，能够更好地理解本发明的上述特征和优点。在附图中，各组件不一定是按比例绘制，并且具有类似的相关特性或特征的组件可能具有相同或相近的附图标记。

图1示出了本发明的基于关注点分离的容器自动化构建部署方法的实施例中的关注点分离整体配置的流程图。

图2示出了图1所示的流程中所包括的容器化管理配置的流程图。

图3示出了图1所示的流程中所包括的流水线任务配置的流程图。

图4示出了本发明的基于关注点分离的容器自动化构建部署方法的实施例中的容器自动构建部署的流程图。

具体实施方式

以下结合附图和具体实施例对本发明作详细描述。注意，以下结合附图和具体实施例描述的诸方面仅是示例性的，而不应被理解为对本发明的保护范围进行任何限制。

本发明的基于关注点分离的容器自动化构建部署方法，构建部署包括前期的静态配置(图1所示的整体处理流程)，以及静态配置完成之后的动态执行过程(如图4所示的容器自动构建部署的流程)，在执行过程中，根据静态配置读取各项数据，完成构建、部署流程中的各动作。而静态配置的图1所示的整体处理流程，包括如图2所示的容器化管理配置的处理流程、以及图3所示的流水线任务配置的处理流程。

图1示出了关注点分离整体配置的流程，即前期的静态配置的整体处理流程。请参见图1，以下是流程中各步骤的详细说明。

步骤1：在容器化管理数据配置的可视化界面中分别设置dockerfile模板(dockerfile是一个用于构建镜像的文本文件，文本内容包含了构建镜像所需的一系列命令和参数)和基础镜像数据。

dockerfile模板的配置，包括配置dockerfile模板适用的OS/Arch(操作系统和体系架构)以及配置dockerfile模板内容。

基础镜像数据的配置，包括配置OS/Arch以及配置OS/Arch对应的镜像。

步骤2：进行组件信息配置，即配置组件与dockerfile、基础镜像的关系。

在本步骤中，先选择组件适用的dockerfile模板，再配置组件适用的dockerfile模板中的具体参数，然后选择组件适用的基础镜像。

步骤3：预览生成的dockerfile，并在本地验证是否符合预期。

若dockerfile模板内容不符合预期，则跳转到步骤1中的设置dockerfile模板的处理，若基础镜像不符合预期，则跳转到步骤1中的设置基础镜像数据的处理。若dockerfile模板内容和基础镜像均符合预期则进入下一步。

步骤4：进行流水线任务配置，包括代码源配置以及关联gitlab代码仓库，当触发流水线任务时从gitlab代码仓库下载源代码。

步骤5：对容器化构建、部署步骤进行任务编排。

首先是容器化构建阶段，先执行构建脚本生成目标文件，然后读取步骤2中配置的各项数据，通过关联的dockerfile模板填充基本镜像、参数等数据，自动生成dockerfile文件，最后根据该dockerfile文件生成docker镜像并推送至镜像仓库。

然后是容器化部署阶段，预先配置k8s云平台部署服务所需要的各项资源及需要部署的分区、应用等信息。当流水线被调度执行，构建镜像制品生成后，调用k8s云平台API根据设定创建资源，拉取镜像制品，进行服务部署。

步骤6：配置持续集成项目，流程结束。

持续集成数据配置完成后，自动帮助用户在gitlab代码库下创建webhook钩子链接。如图4所示，当配置的分支有事件触发且触发类型与监控事件类型一致时，自动触发流水线任务，按照既定逻辑自动执行容器构建、部署任务。

上述的关注点分离整体配置的流程，包括了图2所示的容器化管理配置的处理流程、以及图3所示的流水线任务配置的处理流程。

首先，请参考图2的容器化管理数据配置。

传统容器化构建过程中，dockerfile文件存在于组件代码仓库中，与代码仓库中业务代码无关，作为构建脚本置于代码库，略显冗余。当组件迭代升级，dockerfile文件内容需要变动时，灵活性较差，需编辑后重新提交代码。而且多个组件中的dockerfile文件内容可能存在大量冗余。

为了解决这些问题，如图2所示，本发明将dockerfile文件从组件代码仓库中分离，通过可视化数据配置的方式，定义组件与基础镜像及dockerfile之间的关系。

容器化管理数据配置的具体配置项如下：

(一)基础镜像配置

在基础镜像配置中，配置必选属性包括了OS/Arch属性以及镜像属性，其中OS/Arch是指基础镜像的操作系统及架构，如rhel7.4/amd64、kylinV10/arm64v8，即容器运行的操作系统环境；镜像是指具体使用的容器镜像，如redhat-openjdk-18、kylin10-sp1-arrch64，即容器运行的基本环境。

(二)dockerfile模板配置

在dockerfile模板配置中，配置必选属性包括了适用的OS/Arch属性以及模板内容属性，其中适用的OS/Arch是指不同的OS/Arch可能使用同一个dockerfile模板，所以这里需要配置适用的OS/Arch；模板内容是指由于组件的dockerfile文件内容存在共性内容，将这些内容抽取成模板，变动的数据，如PORT等通过${PORT}方式进行参数注入。

(三)组件与基础镜像及dockerfile配置

组件与基础镜像及dockerfile配置中包括dockerfile数据、基础镜像。其中的dockerfile数据包括dockerfile模板和dockerfile参数，dockerfile模板是指组件采用的dockerfile模板，进行容器化构建的时候，将使用填充模板参数后生成的文件，生成镜像制品；dockerfile参数包括以下：PORT(必选)：容器暴露端口；TARGET_ADDR(必选)：目标文件目录地址；VOLUMES(可选)：自定义挂卷，开发人员可以指定自定义挂卷；MY_STEPS(可选)：自定义步骤，如果模板中缺少步骤，可定义步骤进行补充。

其中的基础镜像包括以下：基础镜像基本数据(必选项)：从上述涉及的基础镜像中进行选择；是否使用基本镜像默认版本(可选)：默认使用。如果不使用默认版本，可以选择其他镜像版本。

其次，请参考图3所示的流水线任务配置的处理流程。

容器化管理数据配置，通过定义基础镜像、dockerfile模板、组件与两者关系，将dockerfile文件从代码库中分离，解决了容器化构建过程中的文件冗余问题，提高了开发人员构建效率。但是对于部署阶段运维风险、流程繁琐费时等问题，并没有得到解决。

图3所示的流水线任务配置，通过将构建阶段、部署阶段各自共性内容抽取为步骤模板，通过流水线编排方式，实现容器组件构建、部署自动化。

流水线任务配置的具体配置项包括：代码源repo仓库配置、容器化构建-目标文件生成脚本配置、容器化构建-组件镜像信息配置、容器化部署-基本信息配置、容器化部署-k8s资源配置、容器化部署-服务监控探测配置、流水线持续集成配置。

代码源repo仓库配置进一步包括gitlab repo代码仓库和配置代码源。

容器化构建-目标文件生成脚本配置中，包括构建环境和构建脚本，其中构建环境是指选择生成目标文件的环境，如java项目需要mvn环境进行编译；构建脚本是指编辑构建脚本，目标文件可能需要编译构建、执行特定脚本后生成。

容器化构建-组件镜像信息配置包括组件选择以及OS/Arch，其中组件选择是指从上述容器化管理数据配置中，选择通过容器化管理配置流程图完成配置的组件；OS/Arch是指一个组件可能存在多个OS/Arch对应的镜像，选择要构建的OS/Arch。

容器化部署-基本信息配置包括k8s分区、应用名称和构建任务，其中k8s分区是指需要部署的分区，通过k8s云平台API接口获取分区列表；应用名称是指需要部署的应用，通过k8s云平台API接口获取应用名称列表；构建任务是指选择上述容器化构建中配置的任务名称。

容器化部署-k8s资源配置包括配置服务启动数量、申请cpu数量、申请内存大小、最大内存限制。

容器化部署-服务监控探测配置包括配置监控探测url、重试次数、间隔时间。

流水线持续集成配置包括配置监控触发分支和监控触发类型，其中监控触发分支是指通过gitlab webhook钩子函数，设置监控触发分支，只有配置的分支有事件触发时才执行流水线；监控触发类型是指设置监控触发类型，如PUSH事件/MR事件。

静态配置完成之后的动态执行过程请参见图4所示，以下是对图4中各步骤的详细描述。

步骤一：因开发人员提交代码至Gitlab代码仓库，触发Gitlab代码仓库PUSH/MergeRequest事件，该事件会调用图3的流水线任务配置流程中的持续集成步骤中设置的钩子方法，此方法是触发本装置的入口。然后进入钩子方法，首先判断图3的流水线任务配置流程中，持续集成步骤配置的分支是否匹配，然后判断事件触发类型与监控事件类型是否一致时，如果两者中任一条件不满足，则动态执行任务结束。如果两者均满足条件，跳转步骤二。

步骤二：如图3的流水线任务配置流程所示，流水线任务主要由容器化构建、容器化部署步骤构成，各步骤中预先配置代码源、环境、脚本等数据信息。流水线任务触发后，如满足步骤一中条件，会依次执行后续各步骤。

先从图3的流水线任务配置流程的配置代码源中读取gitlab repo信息，拉取目标源代码。

步骤三：从图3的流水线任务配置流程所示的容器化构建目标脚本配置中读取构建环境、构建脚本信息，在指定构建环境中执行构建脚本，生成目标文件。如Java项目在指定构建机器上执行mvn clean package命令生成target目标文件。

步骤四：从图3的流水线任务配置流程所示容器化构建镜像组件信息配置中读取组件、OS/Arch信息，如图1的关注点分离整体配置流程所示，在配置流水线任务前，需要先配置组件容器化配置信息，因此通过组件、OS/Arch数据，获取容器化管理配置中对应组件的dockerfile模板、dockerfile配置基本参数等，通过填充OS/Arch、组件在容器化管理配置中的各项dockerfile参数、target目标文件等数据至该模板，生成具体的dockerfile文件。

Dockerfile模板样例：

FROM${BASE_OS/ARCH_IMAGE}

ADD${TARGET_FILR_ADDR}/deployments/${COMPONENT_NAME}

……

ENV JVM_OPTIONS＝${JVM_OPTIONS}

……

步骤五：根据步骤四生成的dockerfile文件，通过内置的docker命令生成容器化镜像，并推送至镜像仓库。

步骤六：从图3的流水线任务配置流程所示的容器化部署基本信息、k8s资源配置中读取应用名称、服务启动数量等各项k8s容器云管理平台部署服务所需基本数据，调用k8s容器云管理平台API接口，k8s容器云管理平台根据各项基本数据调度资源，然后拉取步骤七中生成的容器化构建镜像，进行服务部署。

步骤七：服务部署完成后，通过向图3所示的流水线任务配置流程服务中设置的健康探测url按照间隔时间、重试次数发送请求，以检测服务是否正常。探测完成后动态执行过程结束。

尽管为使解释简单化将上述方法图示并描述为一系列动作，但是应理解并领会，这些方法不受动作的次序所限，因为根据一个或多个实施例，一些动作可按不同次序发生和/或与来自本文中图示和描述或本文中未图示和描述但本领域技术人员可以理解的其他动作并发地发生。

本领域技术人员将进一步领会，结合本文中所公开的实施例来描述的各种解说性逻辑板块、模块、电路、和算法步骤可实现为电子硬件、计算机软件、或这两者的组合。为清楚地解说硬件与软件的这一可互换性，各种解说性组件、框、模块、电路、和步骤在上面是以其功能性的形式作一般化描述的。此类功能性是被实现为硬件还是软件取决于具体应用和施加于整体系统的设计约束。技术人员对于每种特定应用可用不同的方式来实现所描述的功能性，但这样的实现决策不应被解读成导致脱离了本发明的范围。

结合本文所公开的实施例描述的各种解说性逻辑板块、模块、和电路可用通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或其它可编程逻辑器件、分立的门或晶体管逻辑、分立的硬件组件、或其设计成执行本文所描述功能的任何组合来实现或执行。通用处理器可以是微处理器，但在替换方案中，该处理器可以是任何常规的处理器、控制器、微控制器、或状态机。处理器还可以被实现为计算设备的组合，例如DSP与微处理器的组合、多个微处理器、与DSP核心协作的一个或多个微处理器、或任何其他此类配置。

结合本文中公开的实施例描述的方法或算法的步骤可直接在硬件中、在由处理器执行的软件模块中、或在这两者的组合中体现。软件模块可驻留在RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动盘、CD-ROM、或本领域中所知的任何其他形式的存储介质中。示例性存储介质耦合到处理器以使得该处理器能从/向该存储介质读取和写入信息。在替换方案中，存储介质可以被整合到处理器。处理器和存储介质可驻留在ASIC中。ASIC可驻留在用户终端中。在替换方案中，处理器和存储介质可作为分立组件驻留在用户终端中。

在一个或多个示例性实施例中，所描述的功能可在硬件、软件、固件或其任何组合中实现。如果在软件中实现为计算机程序产品，则各功能可以作为一条或更多条指令或代码存储在计算机可读介质上或藉其进行传送。计算机可读介质包括计算机存储介质和通信介质两者，其包括促成计算机程序从一地向另一地转移的任何介质。存储介质可以是能被计算机访问的任何可用介质。作为示例而非限定，这样的计算机可读介质可包括RAM、ROM、EEPROM、CD-ROM或其它光盘存储、磁盘存储或其它磁存储设备、或能被用来携带或存储指令或数据结构形式的合意程序代码且能被计算机访问的任何其它介质。任何连接也被正当地称为计算机可读介质。例如，如果软件是使用同轴电缆、光纤电缆、双绞线、数字订户线(DSL)、或诸如红外、无线电、以及微波之类的无线技术从web网站、服务器、或其它远程源传送而来，则该同轴电缆、光纤电缆、双绞线、DSL、或诸如红外、无线电、以及微波之类的无线技术就被包括在介质的定义之中。如本文中所使用的盘(disk)和碟(disc)包括压缩碟(CD)、激光碟、光碟、数字多用碟(DVD)、软盘和蓝光碟，其中盘(disk)往往以磁的方式再现数据，而碟(disc)用激光以光学方式再现数据。上述的组合也应被包括在计算机可读介质的范围内。

提供对本公开的先前描述是为使得本领域任何技术人员皆能够制作或使用本公开。对本公开的各种修改对本领域技术人员来说都将是显而易见的，且本文中所定义的普适原理可被应用到其他变体而不会脱离本公开的精神或范围。由此，本公开并非旨在被限定于本文中所描述的示例和设计，而是应被授予与本文中所公开的原理和新颖性特征相一致的最广范围。

Claims (7)

1.一种基于关注点分离的容器自动化构建部署方法，其特征在于，方法包括前期的静态配置过程以及静态配置完成之后的动态执行过程；

静态配置过程包括以下步骤：

步骤1：在容器化管理数据配置的可视化界面中分别设置dockerfile模板和基础镜像数据；

步骤2：进行组件信息配置：配置组件与dockerfile、基础镜像的关系；

步骤3：预览生成的dockerfile，并在本地验证是否符合预期；

步骤4：进行流水线任务配置，包括代码源配置以及关联gitlab代码仓库，当触发流水线任务时从gitlab代码仓库下载源代码；

步骤5：对容器化构建、部署步骤进行任务编排；

步骤6：配置持续集成项目，静态配置流程结束；

动态执行过程包括以下步骤：

步骤一：在gitlab repo仓的代码发生变动时，判断触发分支/类型是否满足流线持续集成配置，若满足则进入下一步，否则动态执行过程结束；

步骤二：读取构建任务配置环境数据拉取源代码；

步骤三：执行构建任务配置脚本内容生成目标文件；

步骤四：读取构建任务镜像组件信息配置生成dockerfile文件；

步骤五：根据dockerfile文件编译构建生成镜像并推送至镜像仓库；

步骤六：读取部署任务中信息配置调用k8s云平台API部署服务；

步骤七：服务健康探测，探测完成后动态执行过程结束。

2.根据权利要求1所述的基于关注点分离的容器自动化构建部署方法，其特征在于，在步骤1中，dockerfile模板的配置包括配置dockerfile模板适用的OS/Arch以及配置dockerfile模板内容；基础镜像数据的配置包括配置OS/Arch以及配置OS/Arch对应的镜像。

3.根据权利要求1所述的基于关注点分离的容器自动化构建部署方法，其特征在于，在步骤2中，先选择组件适用的dockerfile模板，再配置组件适用的dockerfile模板中的具体参数，然后选择组件适用的基础镜像。

4.根据权利要求1所述的基于关注点分离的容器自动化构建部署方法，其特征在于，在步骤3中，若dockerfile模板内容不符合预期，则跳转到步骤1中的设置dockerfile模板的处理，若基础镜像不符合预期，则跳转到步骤1中的设置基础镜像数据的处理，若dockerfile模板内容和基础镜像均符合预期则进入下一步。

5.根据权利要求1所述的基于关注点分离的容器自动化构建部署方法，其特征在于，步骤5进一步包括：

首先是容器化构建阶段，先执行构建脚本生成目标文件，然后读取步骤2中配置的各项数据，通过关联的dockerfile模板填充基本镜像、参数在内的数据，自动生成dockerfile文件，最后根据该dockerfile文件生成docker镜像并推送至镜像仓库；

然后是容器化部署阶段，预先配置k8s云平台部署服务所需要的各项资源及需要部署的分区、应用在内的信息，当流水线被调度执行，构建镜像制品生成后，调用k8s云平台API根据设定创建资源，拉取镜像制品，进行服务部署。

6.根据权利要求1所述的基于关注点分离的容器自动化构建部署方法，其特征在于，静态配置过程是基于关注点分离的整体配置，包括容器化管理配置的处理，容器化管理配置的具体配置项包括：基础镜像配置、dockerfile模板配置、组件与基础镜像及dockerfile配置。

7.根据权利要求1所述的基于关注点分离的容器自动化构建部署方法，其特征在于，静态配置过程包括流水线任务配置的处理，通过将构建阶段、部署阶段各自共性内容抽取为步骤模板，通过流水线编排方式，实现容器组件构建、部署自动化，其中流水线任务配置的具体配置项包括：代码源repo仓库配置、容器化构建-目标文件生成脚本配置、容器化构建-组件镜像信息配置、容器化部署-基本信息配置、容器化部署-k8s资源配置、容器化部署-服务监控探测配置、流水线持续集成配置。

Images