基于应用的可视化容器配置管理方法、装置及系统与流程

本公开涉及软件工程领域，更具体地，涉及一种基于应用的可视化容器配置管理方法、装置、系统及计算机可读介质。
背景技术：
：与传统部署方式相比，以docker、kubernetes(也称为k8s)为代表的容器化部署带来许多优势：实现统一的程序运行环境、毫秒级的启动速度、保障应用的高可用、运维高度自动化等。借助容器技术，可以大幅提升交付效率、运维效率、资源利用率。例如，kubernetes可以自动分配容器资源，因此可以提高资源利用率。然而，kubernetes适合有经验的容器管理员使用，现有的paas系统只是对kubernetesapi的简单封装，降低kubernetes的使用门槛，但是用户依然需要对kubernetes的概念进行理解，并且需要使用命令行或配置文件进行容器化部署，使用起来较为不便。技术实现要素：有鉴于此，本公开内容提供了一种基于应用的可视化容器配置管理方法、装置、系统及计算机可读介质，通过可视化方式降低了容器配置的难度。按照本公开内容的第一方面，本公开提供了一种基于应用的可视化容器配置管理方法，包括：获得应用基本信息；根据应用基本信息获得应用对应的镜像地址以及应用对应的部署资源；以及根据应用对应的镜像地址以及应用对应的部署资源实现容器配置。按照本公开内容的第二方面，本公开提供了一种基于应用的可视化容器配置管理装置，包括：应用基本信息获取模块，被配置为用于获得应用基本信息；配置信息获取模块，被配置为用于根据应用基本信息获得应用对应的镜像地址以及应用对应的部署资源；以及配置模块，被配置为用于根据应用对应的镜像地址以及应用对应的部署资源实现容器配置。按照本公开内容的第三方面，本公开提供了一种基于应用的可视化容器配置管理系统，包括paas系统，paas系统包括：应用管理模块，用于管理和/或配置应用基本信息；部署资源管理模块，用于根据应用基本信息管理和/或配置部署资源；以及镜像仓库管理模块，用于根据应用基本信息管理和/或配置镜像地址。按照本公开内容的第四方面，本公开提供了一种计算机可读介质，其上存储有可执行指令，所述可执行指令被处理器执行时使处理器执行如上述第一方面所述的方法。本公开内容提供了一种基于应用的可视化容器配置管理方法、装置、系统及计算机可读介质，通过可视化界面获得应用基本信息，再根据应用基本信息获得应用对应的镜像地址和应用对应的部署资源，根据应用对应的镜像地址以及应用对应的部署资源实现容器配置，使得用户无需了解容器配置的内部逻辑就可以实现容器配置，降低容器配置的难度。附图说明为了更清楚地说明本公开实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本公开的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。图1为本公开具体实施例中的一种基于应用的可视化容器配置管理系统的结构图；图2为本公开具体实施例中的一种基于应用的可视化容器配置管理方法的流程图；图3为本公开具体实施例中的实现新集群和镜像仓库接入时的可视化界面示例图；图4为本公开具体实施例中的添加环境的可视化界面示例图；图5为本公开具体实施例中的线下环境配置流水线的可视化界面示例图；图6为本公开具体实施例中的线上环境配置流水线的可视化界面示例图；图7a和图7b为本公开具体实施例中的配置容器部署的可视化界面示例图；图8为本公开具体实施例中的配置服务的可视化界面示例图；图9为本公开具体实施例中的配置自动扩缩容的可视化界面示例图。具体实施方式下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本公开一部分实施例，而不是全部的实施例。基于本公开中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本公开保护的范围。与传统部署方式相比，以docker、kubernetes(也称为k8s)为代表的容器化部署带来许多优势：实现统一的程序运行环境、毫秒级的启动速度、保障应用的高可用、运维高度自动化等。借助容器技术，可大幅提升交付效率、运维效率、资源利用率。例如，kubernetes可以自动分配容器资源，因此可以提高资源利用率。然而，kubernetes适合有经验的容器管理员使用，现有的paas系统只是对kubernetesapi的简单封装，降低kubernetes的使用门槛，但是用户依然需要对kubernetes的概念进行理解，并且需要使用命令行或配置文件进行容器化部署。其中，docker为一种容器运行时的引擎，是一种用于根据容器镜像生成容器的工具。docker也是一种linux容器工具集，是为“构建(build)、交付(ship)和运行(run)”分布式应用而设计的。docker相当于把应用以及应用所依赖的环境完完整整地打成了一个包，这个包拿到哪里都能原生运行。因此可以在开发、测试、运维中保证环境的一致性。docker的本质：docker＝lxc(namespace+cgroups)+dockerimages，其中，lxc表示linux容器(linuxcontainer)，namespace表示资源隔离，cgroups表示资源控制，dockerimages表示docker镜像，即在linux内核的资源隔离和资源控制技术的基础上通过镜像管理机制来实现轻量化设计。docker镜像是一个只读的模板，可以把镜像理解成一个模子(模具)，由模子(镜像)制作的成品(容器)都是一样的(除非在生成时加额外参数)，修改成品(容器)本身并不会对模子(镜像)产生影响(除非将成品提交成一个模子)，容器重建时，即由模子(镜像)重新制作成一个成品(容器)，与其他由该模子制作成的成品并无区别。kubernetes为一种容器调度编排系统，即一种配置容器资源的系统。kubernetes是容器集群管理系统。它构建docker技术之上，为容器化的应用提供资源调度、部署运行、服务发现、扩容缩容等整一套功能，本质上可看作是基于容器技术的micro-paas平台，即第三代paas的代表性项目。image表示容器镜像，容器镜像是容器的文件和数据系统，镜像运行起来后成为一个容器(container)。大部分容器paas系统存在如下不足：1、容器paas系统普遍存在系统复杂、使用门槛高的问题，并不适合普通开发者使用。首先，kubernetes属于复杂系统，用户需理解较多的概念才能使用，门槛较高，kubernetes本身提供的命令行和应用程序接口(applicationprogramminginterface，简称为api)，功能全面但较为复杂，只适合深入理解kubernetes的容器管理员使用。其次，基于kubernetes开发的容器paas系统，是对kubernetesapi的简单包装，仍然要求使用者深入理解kubernetes的原理，实际上也仅适合容器管理员使用，并不适合容器管理员以外的开发者使用。2、资源管理较为混乱，无法给普通用户提供一个简单的视图。以部署一个无状态应用为例，用户需处理deployment资源、service资源、hpa资源、pod资源、镜像资源，以及各个资源之间的关系，但是这些资源的处理是通过配置文件手动进行。这些资源错综复杂，配置稍有错误，就会导致部署失败。其中，pod表示容器组，pod是kubernetes调度的最小单位。一个pod中可以包含一个或多个容器，同一个pod中的容器总是调度到同一台机器上，且共享一个集群ip。一个pod包含一个容器是最常见的情况。用户一般不会直接创建pod，而是通过创建deployment/statefulset/daemonset/job/cronjob，再由k8s控制pod的创建。pod是若干个相关容器的组合，是一个逻辑概念，pod包含的容器运行在同一个宿主机上，这些容器使用相同的网络命名空间、ip地址和端口，相互之间能通过本地主机(localhost)来发现和通信，共享一块存储卷空间。在kubernetes中创建、调度和管理的最小单位是pod。一个pod一般只放一个业务容器和一个用于统一网络管理的网络容器。deployment表示无状态应用。无状态应用的特点是应用本身不存储状态信息，应用的各个实例的身份完全等同。statefulset表示有状态应用。有状态应用的特点是应用的各个容器实例有唯一稳定的身份标识，包括网络标识或存储。有状态应用通常用于部署集群类应用，例如需要稳定网络标识的eureka集群。有状态应用中每一个应用是不同的，每个应用的存储内容也是不同的，而无状态应用是可以替换使用的，无自身标识。daemonset为守护类应用。守护类应用的特点是应用在集群内一批机器上各运行一个实例。通常用于agent类程序的部署，例如监控程序的agent。一台机器上只能运行一个守护类应用，用于实现数据监控和数据采集。job为任务类应用。任务类应用的特点是任务类应用是一次性、短时任务，任务执行完毕后，容器退出，即任务类应用在执行完毕后，容器自动销毁。cronjob为定时任务类应用。定时任务类应用是定时执行的任务。当系统时间满足指定的cron时间表达式时，系统唤起定时任务；定时类任务执行完毕后，容器退出。其中，cron时间表达式为用户自定义的任务启动时间。service表示k8s服务。service可以理解为kubernetes为容器提供的一种反向代理和负载均衡机制。同一应用(app)的多个实例(pod)可利用service对外统一提供服务。对service的请求将被分发给其代表的pod来处理。service是真实应用服务的抽象，定义了pod的逻辑集合和访问这个pod逻辑集合的策略，service将代理pod对外表现为一个单一访问接口，外部不需要了解后端pod如何运行，这给扩展或维护带来很大的好处，提供了一套简化的服务代理和发现机制。其中，反向代理指的是服务器的代理，个人代理为正向代理。hpa(horizontalpodautoscaling)表示pod横向自动扩缩容，也即容器的横向自动扩缩容配置。用户创建hpa配置后，k8s将根据应用的性能指标(cpu、内存或其他自定义指标)，自动增加或减少应用的pod实例数。自动扩缩容通过平均资源消耗确定自动扩缩容的阈值，通过定时采集的容器资源消耗判断当前容器资源消耗是否达到所述阈值，从而进行容器的扩缩容。因此，如何方便明了的管理各种资源以及各种资源之间的关联，并给普通用户提供一个简单可靠的视图，已经成为一个亟需解决的问题。所以基于上述不足，在本公开的具体实施例中，提出一种以可视化界面为核心的容器配置管理方案，用户可以通过可视化界面进行容器配置参数的填充，从而使得用户可以忽略kubernetes的内部运行，在不理解kubernetes概念的情况下也可以实现资源管理，从而降低kubernetes的使用门槛。在本公开内容的一个实施例中，如图1所示，本公开内容提供了一种基于应用的可视化容器配置管理系统，包括paas系统1，其中，paas系统1可以包括：应用管理模块11，用于管理和/或配置应用基本信息；部署资源管理模块12，用于根据应用基本信息管理和/或配置部署资源；以及镜像仓库管理模块13，用于根据应用基本信息管理和/或配置镜像地址。在本公开内容的具体实施例中，基于应用的可视化容器配置管理系统还可以包括配置数据库2、容器集群3、镜像仓库4。其中，应用基本信息可以包括应用所部署的k8s集群、应用所部署的k8snamespace、应用类型、应用的gitlab仓库地址、编译脚本在gitlab仓库的相对路径、dockerfile在gitlab仓库的相对路径、是否使用已有镜像、使用的已有镜像的uri。namespaces提供一种资源隔离方案。每个namespace下的资源对于其他namespace下的资源都是不可见的。dockerfile用于构建docker镜像。部署资源管理模块12可以包括deployment模块、statefulset模块、daemonset模块、cronjob模块、service模块、pod模块。其中，deployment模块可以用于提供对无状态应用的配置、管理，将用户对无状态应用的配置改动同步到配置数据库2中，并根据用户的配置对kubernetesdeployment资源进行操作。statefulset模块可以用于提供对有状态应用的配置、管理，将用户对有状态应用的配置改动同步到配置数据库2中，并根据用户的配置对kubernetesstatefulset资源进行操作。daemonset模块可以用于提供对守护类应用的配置、管理，将用户对守护类应用的配置改动同步到配置数据库2中，并根据用户的配置对kubernetesdaemonset资源进行操作。cronjob模块可以用于提供对定时任务类应用的配置、管理，将用户对定时任务类应用的配置改动同步到配置数据库2中，并根据用户的配置对kubernetescronjob资源进行操作。job模块可以用于提供对任务类应用的配置、管理，将用户对任务类应用的配置改动同步到配置数据库2中，并根据用户的配置对kubernetesjob资源进行操作。service模块可以用于提供对k8sservice的配置、管理，将用户对service的配置改动同步到配置数据库2中，并根据用户的配置对kubernetesservice资源进行操作。pod模块可以用于提供对k8spod的管理，负责提供对kubernetespod资源的操作接口。在本公开的具体实施例中，不需要对pod进行配置，只需要对pod进行查询、删除api等管理操作。hpa模块可以用于提供对k8shpa的配置、管理，将用户对hpa的配置改动同步到配置数据库2中，并根据用户的配置对kuberneteshpa资源进行操作。镜像仓库管理模块13还可以用于镜像仓库4相关信息的配置管理，并对接多款镜像仓库4(例如，dockerregistry、harbor、阿里云容器镜像服务)，提供对镜像信息的操作接口。在本公开的具体实施例中，配置数据库2可以用于存储配置信息，所存储的配置信息可以包括应用基本配置、deployment配置、statefulset配置、daemonset配置、cronjob配置、job配置、service配置、pod配置、镜像仓库配置、hpa配置。容器集群3可以是kubernetes容器集群。镜像仓库4用于存储容器镜像数据。在实践中，有dockerregistry、harbor、阿里云容器镜像服务等多种容器镜像仓库服务。在逻辑上，一个镜像仓库4下可划分多个项目(project)，每个镜像仓库项目下又可以划分多个存储库(repository)，一个存储库可存储多个镜像标签(tag)。例如，容器镜像uri"172.30.10.195:15000/paas/nginx:v1.7.9"，其中"172.30.10.195:15000"是镜像仓库服务的uri，而"paas"是项目，"nginx"是具体的存储库，"v1.7.9"是镜像的标签。其中，一台机器上可以运行的容器的最大数量是根据机器的存储空间决定的。在本公开的一个具体实施例中，如图2所示，本公开还提供了一种基于应用的可视化容器配置管理方法，可以包括：s1、获得应用基本信息；s2、根据应用基本信息获得应用对应的镜像地址以及应用对应的部署资源；以及s3、根据应用对应的镜像地址以及应用对应的部署资源实现容器配置。在获得应用基本信息之前，还可以包括：根据需要部署的软件决定是否创建新的应用，如果之前完成过该软件应用的创建和配置，则可以直接获得应用基本信息，如果之前没有完成过该软件应用的创建和配置，则可以创建和配置该软件对应的新的应用，再获得应用基本信息。应用基本信息可以通过应用接收的输入的基本信息获得。应用可以包括可视化界面，可以通过该可视化界面输入应用基本信息。在本公开的具体实施例中，应用基本信息可以包括应用名、应用所在项目名。则根据应用基本信息获得应用对应的镜像地址可以包括：根据应用名获得镜像仓库存储库名；根据应用所在项目名获得镜像仓库项目名；根据应用名获得应用所在集群信息，根据应用所在集群信息获得镜像仓库服务地址；以及根据镜像仓库服务地址、镜像仓库项目名、镜像仓库存储库名获得应用对应的镜像地址。即应用可以通过应用的应用名、应用所在项目名与镜像建立关联关系。应用与镜像进行关联，是为了解决如下问题：对于特定的应用，如何确定应用对应的镜像仓库存储库(repository)地址，以便在部署配置(deployment/statefulset/daemonset/job/cronjob)中配置正确的镜像地址。由于镜像仓库4和容器集群3一一对应，且镜像地址由三部分组成：镜像仓库服务地址、镜像仓库项目名、镜像仓库存储库名，因此，对于应用与镜像进行关联的问题，可以采用如下方式解决：首先，先确定应用名，镜像仓库存储库再根据应用名自动确定镜像仓库存储库名，即应用名与镜像仓库存储库名保持一致，镜像仓库存储库名即应用名；其次，确定应用所在项目名，镜像仓库项目名再根据应用所在项目名确定，应用所在项目名与对应镜像仓库项目名保持一致，镜像仓库项目名即应用所在项目名；再次，由于应用所在集群与镜像仓库信息一一关联，从而可根据应用名关联查询到应用所在集群信息，进而根据应用所在集群信息查询到镜像仓库服务地址。例如，某个应用名为aiops-controller，应用所在项目名为aiops，应用所在集群信息为cluster-sg，根据应用所在集群信息cluster-sg获得的镜像仓库服务地址是172.30.185:15000/，那么根据上述规则可知，镜像仓库存储库名是aiops-controller，镜像仓库项目名是aiops；另外与应用关联的镜像仓库服务地址为172.30.185:15000/，综合这些信息，可以获得应用对应的镜像地址是172.30.185:15000/aiops/aiops-controller。通过上述方式，可以建立起应用与镜像地址的一一关联。在本公开的具体实施例中，应用基本信息还可以包括应用类型、应用命名空间名。则根据应用基本信息获得应用对应的部署资源可以包括：根据应用类型获得部署资源类别；根据应用命名空间名获得部署资源对应的命名空间；根据应用名获得部署资源名；以及根据部署资源类别、部署资源对应的命名空间、部署资源名获得应用对应的部署资源。即应用可以通过应用名、应用类型、应用命名空间名与部署资源建立关联关系。其中，部署资源可以指kubernetes集群中的资源，部署资源可以包括deployment资源、statefulset资源、daemonset资源、cronjob资源、job资源中的一个或多个。在本公开的具体实施例中，可以通过如下方式建立应用与部署资源之间的关联关系：首先，根据应用类型确定部署资源类别，部署资源类别可以为deployment资源、statefulset资源、daemonset资源、cronjob资源、job资源中的一个；其次，确定应用命名空间名，再根据应用命名空间名确定部署资源对应的命名空间，即应用命名空间名与部署资源所在的kubernetes命名空间保持一致；再次，确定应用名，再根据应用名确定部署资源名，即应用名与kubernetes部署资源的名字保持一致。例如，某个应用名为aiops-controller，应用命名空间名是aiops-ali-bj，应用类型是0(0可以表示deployment)，那么kubernetes集群中对应的部署资源就是命名空间aiops-ali-bj中名为aiops-controller的deployment资源。通过上述方式，可以将应用与部署资源一一关联。在本公开的具体实施例中，应用类型可以包括无状态应用、有状态应用、守护类应用、任务类应用、定时任务类应用中的一种或多种。无状态应用是最常见的类型。无状态应用不需要稳定的外部存储，不需要稳定的网络标识符，常见的前端应用、后端应用通常都是无状态应用。在本公开的具体实施例中，基于应用的可视化容器配置管理方法还可以包括根据应用基本信息确定对容器扩缩容的配置。可以根据需要部署的软件确定该软件是否需要hpa功能。若该软件有横向自动扩缩容的需求，则可以开启hpa功能，若该软件没有横向自动扩缩容的需求，则无需开启hpa功能。例如，可以根据需要部署的软件的流量波动大小确定该软件是否有横向自动扩缩容的需求。对容器扩缩容的配置的参数可以包括最多实例数、最少实例数、扩缩容指标等，其中，扩缩容指标指的是资源消耗的阈值，当超过或低于某一指标时，可以进行相应的扩容或缩容。在本公开的具体实施例中，应用与hpa之间的关联关系可以通过应用的应用名、应用命名空间名实现，具体可以采用如下方式：首先，确定应用命名空间名，根据应用命名空间名确定hpa资源所在命名空间名，即应用命名空间名与kuberneteshpa资源所在的命名空间名保持一致；其次，确定应用名，根据应用名确定hpa名，即应用名与其对应的hpa名保持一致。通过上述方式，可以将应用与kuberneteshpa一一关联。在本公开的具体实施例中，基于应用的可视化容器配置管理方法还可以包括根据应用基本信息确定对服务的配置。可以根据需要部署的软件确定该软件是否需要service功能。若该软件需要向其他软件开放tcp/udp端口，则可以开启service功能，若该软件不需要向其他软件开放tcp/udp端口，则可以不开启service功能。其中，可以通过确定该软件是否需要与其他软件进行通信，来确定该软件是否需要向其他软件开放tcp/udp端口。对服务的配置的参数可以包括service端口、容器目标端口、外部ip等。其中，service端口指的是外部软件和需要部署的容器之间通信的端口，也是kubernetes反向代理的端口，容器目标端口指的是内部部署资源与需要部署的容器之间通信的端口，外部ip指的是外部需要与部署容器所在集群通信的ip地址。在本公开的具体实施例中，应用与service之间的关联关系可以通过应用名、应用命名空间名实现，具体可以采用如下方式：首先，确定应用命名空间名，根据应用命名空间名确定kubernetesservice资源所在命名空间名，即应用命名空间名与kubernetesservice资源所在命名空间名保持一致；其次，确定应用名，根据应用名确定service名，即应用名与其对应的service名保持一致。通过上述方式，可以将应用与kubernetesservice一一关联。在本公开的具体实施例中，基于应用的可视化容器配置管理方法还可以包括根据应用基本信息实现对容器组的配置。在本公开的具体实施例中，应用与容器组pod之间的关联关系可以通过应用名、应用命名空间名实现，具体可以采用如下方式：首先，确定应用命名空间名，根据应用命名空间名确定kubernetespod资源所在命名空间名，即应用命名空间名与kubernetesservice资源所在命名空间名保持一致；其次，确定应用名，自动化地为应用所对应的pod统一打上一个标签(label)，标签的内容可以为“app：应用名”。例如，对于应用名为aiops-controller的应用，可以自动化地为该应用所对应的pod添加标签“app:aiops-controller”。其中，一个应用可能对应多个pod，这多个pod的名称不同，但是标签相同。通过上述方式，可以将应用与kubernetespod进行关联。应用基本信息还可以包括应用的gitlab仓库地址、编译脚本在gitlab仓库的相对路径、dockerfile在gitlab仓库的相对路径、是否使用已有镜像，如果使用已有镜像，则应用基本信息还包括已有镜像的uri。对于不同的应用，需要完成的配置存在相同之处，也存在不同之处，系统可以根据应用的应用类型提供不同的配置界面供用户配置，例如，所有类型的应用均需要配置cpu和/或内存配置，而有状态应用还需要配置volumeclaimtemplates，volumeclaimtemplates包括存储资源，存储资源包括所需存储空间、存储介质等参数。其中，一个应用可以只属于一种应用类型。可以通过上述基于应用的可视化容器配置管理方法，完成部署资源的创建或变更。在本公开的具体实施例中，基于应用的可视化容器配置管理方法还可以包括对集群的配置和/或对镜像仓库4的配置。例如，如图3所示，在应用的可视化界面上实现新集群和镜像仓库4接入时，可以配置如下参数：在本公开的具体实施例中，可以以无状态应用的容器配置管理的容器化接入为例，则一种基于应用的可视化容器配置管理方法包括：a1、配置环境；a2、创建和配置应用；a3、配置容器部署，即deployment；a4、配置服务，即service；a5、配置自动扩缩容，即hpa。其中，配置环境可以包括添加环境、配置流水线。环境对应于kubernetes中的一个namespace，添加环境包括在应用管理软件界面通过输入环境名称、集群名称、是否容器化创建新环境，添加环境可视化界面如图4所示。配置流水线包括对线下环境流水线的配置和对线上环境流水线的配置。线下环境流水线为：代码编译、镜像构建、部署到集群，如图5所示，需要添加如下4个工作任务：节点名称触发工作任务indextest_gears_docker_indextartest_gears_docker_tarimagetest_gears_docker_imagedeploytest_gears_docker_deploy线上环境流水线为：镜像推送、部署到集群，如图6所示，需要添加如下3个工作任务：节点名称触发工作任务indexon_gears_docker_indeximageon_gears_docker_imagedeployon_gears_docker_deploy创建和配置应用可以包括两种情况，一种是使用常规镜像的情况，一种是使用第三方镜像的情况。在使用常规镜像的情况下，可能需要进行代码编译和镜像构建，此时创建和配置应用可以包括：输入gitlab地址；输入编译脚本路径，编译脚本路径是相对于gitlab项目顶层目录，如果应用不需要进行编译，则可以不输入编译脚本路径；输入dockerfile路径，dockerfile路径是相对于gitlab项目顶层目录。在使用第三方镜像的情况下，不需要经过代码编译和镜像构建，此时创建和配置应用可以包括：选择使用第三方镜像；输入镜像地址，例如，mysql:5.6。配置容器部署是容器的运行时配置。如图7a和图7b所示，配置容器部署所需要配置的参数可以包括如下列表中的一个或多个：配置服务是容器的访问方式配置。配置服务后，可以起到如下作用：·同一环境下其他应用可通过service名访问应用的接口，其中，service名与应用名相同。由于kubernetes集群提供dns功能，可将service名解释为serviceip，因此可以通过service名访问service。例如，app名字为guava-mall-api，service端口为28085，则同一空间下其他应用可通过http://guava-mall-api:28085访问该应用的接口。·配置ip后，容器可暴露给集群外部访问。例如，ip配置为172.30.10.188，则集群外可通过http://172.30.10.188:28085访问该应用的容器。kubernetes提供负载均衡，能根据策略将请求分发给该应用的容器。这里配置输入的ip必须是容器所运行的集群内节点ip，否则将无法转发请求。如图8所示，配置服务所需要配置的参数可以包括如下列表中的一个或多个：service配置修改后，可以点击“保存”，然后点击“应用”，即可启动service。配置自动扩缩容可以根据容器的cpu和/或内存的利用率或阈值对容器进行横向扩缩容配置。配置hpa前需要明确如下几点：·一个hpa可配置一个或两个性能指标。例如，可以配置cpu和内存两个性能指标，hpa将分别根据两个性能指标计算预期的实例数，取其中较大的作为hpa预期实例数。·不建议一个hpa配置多个性能指标，因为并不是hpa指标越多越复杂效果就越好；而是应该根据应用的类型，选择最适合的性能指标。例如，对于计算密集型的后端应用，cpu利用率事实上就是反映容器负载的最佳指标，因此就应该选择cpu作为hpa的唯一指标。如图9所示，配置自动扩缩容所需要配置的参数可以包括如下列表中的一个或多个：hpa配置修改后，点击“保存”，然后点击“应用”，即可启动hpa。本公开通过引入应用概念，一个应用对应一个应用服务，以应用作为镜像仓库4、交付流水线，kubernetes各类资源的纽带。1个应用唯一对应镜像仓库4中的1个存储库，1个应用有且只有1份部署配置，即根据应用类型，在deployment配置、statefulset配置、daemonset配置、cronjob配置、job配置中选择其一，且包含1份或0份service配置、包含1份或0份hpa配置。同时，1个应用对应kubernetes中唯一一个部署资源，即根据应用类型，在deployment资源、statefulset资源、daemonset资源、cronjob资源、job资源中选择其一，且对应1份或0份service资源，对应1份或0份hpa资源。在可视化界面输入以上配置参数以及应用基本信息后，可以在配置数据库2中产生数据表，其中，数据表可以包括如下列表中的一个或多个参数：通过可视化界面，用户可以输入上表中所示的一个或多个参数，并且在配置数据库2中产生如上表格。k8s可以利用上述表格，针对对应的集群、命名空间、应用名创建所需的部署资源，从而有效地降低了容器系统的使用门槛。在本公开的具体实施例中，本公开通过引入可视化应用，有助于形成简单的视图，降低了容器paas系统的使用难度。本公开通过帮助用户建立和理解一个简单的视图，解决了容器paas系统概念复杂，使用门槛高的问题。在引入应用设计前，用户需关注kubernetes的各类资源(deployment、statufulset、daemonset、job、cronjob、pod)，以及资源之间复杂的关联。在引入应用设计后，用户的关注中心转移到了应用以及应用的配置，而将背后复杂的kubernetes资源管理，以及资源之间复杂的关联，都交由本公开自动实现。因此，本公开能够帮助用户建立和理解以应用为核心的视图，从而有效地降低了容器系统的使用门槛。在本公开内容的另一实施例中，本公开内容还提供了一种基于应用的可视化容器配置管理装置，包括：应用基本信息获取模块，被配置为用于获得应用基本信息；配置信息获取模块，被配置为用于根据应用基本信息获得应用对应的镜像地址以及应用对应的部署资源；以及配置模块，被配置为用于根据应用对应的镜像地址以及应用对应的部署资源实现容器配置。在本公开的具体实施例中，本公开提供的基于应用的可视化容器配置管理装置与上述实施例中提供的一种基于应用的可视化容器配置管理方法相对应。在本公开内容的又一实施例，本公开内容还提供了一种计算机可读介质，其上存储有可执行指令，该可执行指令被处理器执行时使处理器执行如上述的基于应用的可视化容器配置管理方法。结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(ram)、内存、只读存储器(rom)、电可编程rom、电可擦除可编程rom、寄存器、硬盘、可移动磁盘、cd-rom、或
技术领域：
内所公知的任意其它形式的存储介质中。在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本公开所述的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，dvd)、或者半导体介质(例如固态硬盘solidstatedisk)等。需要说明的是，本公开内容中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于方法类实施例而言，由于其与产品类实施例相似，所以描述的比较简单，相关之处参见产品实施例的部分说明即可。还需要说明的是，在本公开内容中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本公开内容。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本公开内容中所定义的一般原理可以在不脱离本公开内容的精神或范围的情况下，在其它实施例中实现。因此，本公开内容将不会被限制于本公开内容所示的这些实施例，而是要符合与本公开内容所公开的原理和新颖特点相一致的最宽的范围。当前第1页12