一种针对容器运维的业务处理方法、装置以及设备与流程

1.本说明书涉及计算机运维技术领域，尤其涉及一种针对容器运维的业务处理方法、装置以及设备。


背景技术：

2.容器，是一种隔离应用运行环境的技术，常见的如linux下的docker容器。
3.在容器提供的隔离环境中运行某些业务，有助于提高安全性，以及有助于为这些业务更好地进行资源管理，将这样的容器称为业务容器。在实际应用中，经常需要对业务容器进行运维操作，具体通常是进入业务容器内，执行运维命令，比如，linux下用于正则查找的grep指令、用于管理包的rpm指令等。
4.在目前的运维方式下，针对业务容器的运维动作，可能会干扰该业务容器内正常业务的运行。比如，若运维人员执行了大量消耗内存的运维命令，则可能触发业务容器的出现内存不足，导致业务容器内的业务进程被杀掉(kill)，进而可能导致业务应用崩溃，造成严重后果。
5.基于此，需要针对业务容器更可靠的运维方案。


技术实现要素：

6.本说明书一个或多个实施例提供一种针对容器运维的业务处理方法、装置、设备以及存储介质，用以解决如下技术问题：需要针对业务容器更可靠的运维方案。
7.为解决上述技术问题，本说明书一个或多个实施例是这样实现的：
8.本说明书一个或多个实施例提供的一种针对容器运维的业务处理方法，包括：
9.确定目标业务容器对应的物理机；
10.在所述物理机上，为所述目标业务容器启动与目标业务容器共享至少部分命名空间的伴生容器，并为所述伴生容器配置资源限制信息；
11.在所述资源限制信息指示的限制下，获取所述伴生容器的资源；
12.通过所述伴生容器与所述目标业务容器之间的交互，展示包含所述目标业务容器内的视图的运维管控界面，并利用所述资源执行针对所述目标业务容器的运维命令。
13.本说明书一个或多个实施例提供的一种针对容器运维的业务处理装置，包括：
14.容器物理机确定模块，确定目标业务容器对应的物理机；
15.伴生容器启动配置模块，在所述物理机上，为所述目标业务容器启动与目标业务容器共享至少部分命名空间的伴生容器，并为所述伴生容器配置资源限制信息；
16.伴生容器资源获取模块，在所述资源限制信息指示的限制下，获取所述伴生容器的资源；
17.运维管控交互执行模块，通过所述伴生容器与所述目标业务容器之间的交互，展示包含所述目标业务容器内的视图的运维管控界面，并利用所述资源执行针对所述目标业务容器的运维命令。
18.本说明书一个或多个实施例提供的一种针对容器运维的业务处理设备，包括：
19.至少一个处理器；以及，
20.与所述至少一个处理器通信连接的存储器；其中，
21.所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：
22.确定目标业务容器对应的物理机；
23.在所述物理机上，为所述目标业务容器启动与目标业务容器共享至少部分命名空间的伴生容器，并为所述伴生容器配置资源限制信息；
24.在所述资源限制信息指示的限制下，获取所述伴生容器的资源；
25.通过所述伴生容器与所述目标业务容器之间的交互，展示包含所述目标业务容器内的视图的运维管控界面，并利用所述资源执行针对所述目标业务容器的运维命令。
26.本说明书一个或多个实施例提供的一种非易失性计算机存储介质，存储有计算机可执行指令，所述计算机可执行指令设置为：
27.确定目标业务容器对应的物理机；
28.在所述物理机上，为所述目标业务容器启动与目标业务容器共享至少部分命名空间的伴生容器，并为所述伴生容器配置资源限制信息；
29.在所述资源限制信息指示的限制下，获取所述伴生容器的资源；
30.通过所述伴生容器与所述目标业务容器之间的交互，展示包含所述目标业务容器内的视图的运维管控界面，并利用所述资源执行针对所述目标业务容器的运维命令。
31.本说明书一个或多个实施例采用的上述至少一个技术方案能够达到以下有益效果：一方面，动态地为业务容器提供了可用的伴生容器，利用伴生容器的资源来执行针对业务容器的运维命令，而不用占用业务容器的资源，并且为伴生容器施以相应资源限制，使得若运维命令占用过多资源，则在该限制下只会影响运维命令本身，而不会威胁到业务容器中的业务进程；另一方面，虽然利用的是伴生容器的资源，但是通过伴生容器与业务容器之间的交互，可以切换到业务容器内的视图，在运维管控界面中进行展示，以及在业务容器内执行运维命令，防止了伴生容器内的视图给用户带来困惑和不一致的感受，提高了用户在实施运维行为时的界面交互体验。
附图说明
32.为了更清楚地说明本说明书实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
33.图1为本说明书一个或多个实施例提供的一种针对容器运维的业务处理方法的流程示意图；
34.图2为本说明书一个或多个实施例提供的一种应用场景下，获取和使用容器资源的一种具体实施方案的流程示意图；
35.图3为本说明书一个或多个实施例提供的一种应用场景下，图1中方法的一种具体实施方案的流程架构示意图；
36.图4为本说明书一个或多个实施例提供的一种针对容器运维的业务处理装置的结构示意图；
37.图5为本说明书一个或多个实施例提供的一种针对容器运维的业务处理设备的结构示意图。
具体实施方式
38.本说明书实施例提供一种针对容器运维的业务处理方法、装置、设备以及存储介质。
39.为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。基于本说明书实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本技术保护的范围。
40.背景技术中提到了linux下的运维命令的例子，在实际应用中，很多容器运维行为都是在linux下进行的，因此，为了更好地理解本方案，下面的一部分实施例也会以linux下容器运维场景为例进行详细说明。
41.在本说明书一个或多个实施例中，使用了kubernetes，kubernetes是开源的容器集群编排调度软件。pod是kubernetes下的调度的最小单元，一组容器共享部分命名空间(namespace)构成一个pod。一开始考虑使用kubectl exec应用程序编程接口作为运维命令通道，在物理机节点上(在集群中，一个节点可能对应一个或者多个物理机)，通过调用docker exec，进入到业务容器内，然后，运维人员可以执行一些运维命令，比如，yum install、maven install、grep等，但是，这样也有可能会引发背景技术中提到的问题。
42.基于此，提出了新方案以解决上述问题，在该方案下，能够限制运维命令所使用的资源，同时使得运维命令不占用或者尽量减少占用业务容器自身的资源，从而，这样当运维人员执行占用很多资源(比如，内存)的运维命令时，最多可能导致运维命令自身异常(比如，被kill)，而不会触发业务进程也随之异常，从而能够保护业务正常进行，提高业务可靠性。
43.下面基于这样的思路，进一步地详细说明。
44.图1为本说明书一个或多个实施例提供的一种针对容器运维的业务处理方法的流程示意图。该方法可以应用于不同的业务领域中，比如，电商业务领域、金融业务领域、电子支付业务领域、即时通讯业务领域、机器人业务领域、视频服务业务领域、游戏业务领域、公务业务领域等。该流程可以由相应领域的计算设备(比如，电商业务对应的运维服务器等)执行，流程中的某些输入参数或者中间结果允许人工干预调节，以帮助提高准确性。
45.图1中的流程可以包括以下步骤：
46.s102：确定目标业务容器对应的物理机。
47.在本说明书一个或多个实施例中，运维人员想要针对某个业务容器进行一轮运维行为，则该业务容器即作为目标业务容器。在一轮运维行为中，运维人员能够下达一条或者多条运维命令，每条运维命令可能对应多个具体的运维操作步骤。
48.容器是一个逻辑上的概念，其需要实体设备来承载，即所述的物理机。
49.目标业务容器对应的物理机可以包括目标业务容器所在的物理机，步骤s102的主要目的是为了后续基于该物理机更便利地与该目标业务容器进行交互，以辅助运维行为更高效可靠地完成。当然，能够实现该目的其他物理机也可以作为目标业务容器对应的物理机，比如，与目标业务容器所在的物理机属于同一个集群，且两者之间具有可用的运维命令通道的其他物理机等。
50.s104：在所述物理机上，为所述目标业务容器启动与目标业务容器共享至少部分命名空间的伴生容器，并为所述伴生容器配置资源限制信息。
51.运维命令的执行需要相应的资源，内存是其中一种基本资源，除此之外，还可能需要处理器、网络带宽、时隙、令牌等其他资源。
52.在本说明书一个或多个实施例中，执行运维命令所需的资源由容器来提供，但不是由目标业务容器自身来提供，而是由目标业务容器的伴生容器来提供。伴生容器与其对应的业务容器运行在同一个最小调度单元中，共享部分或者全部命名空间，用于辅助该业务容器执行一些操作。
53.对于本方案而言，运维命令可以通过相应的进程执行，在这种情况下，资源限制配置具体可以用于限制进程所需使用的资源，另外，后续也可能通过进程来进行目标业务容器与伴生容器之间交互。进程的灵活使用能够帮助本方案更好地实现，基于此，可以使目标业务容器启动与伴生容器至少共享进程相关的命名空间，比如进程标识(pid)命名空间，以防止两者之间隔离进程，除此之外，根据需求还可以为两者共享其他类型的命名空间，比如，网络的命名空间、用户的命名空间等。
54.伴生容器与其对应的业务容器分别具有独立的可用于执行运维命令的资源。在伴生容器的资源支持下，运维命令无需占用目标业务容器的资源，从而防止威胁到目标业务容器内的正常业务运行时的资源需求。
55.伴生容器可以伴随对应的业务容器而启动，两者的生命周期保持一致，以更好地协调工作。但是，在本说明书一个或多个实施例中，伴生容器动态地由待执行的运维命令触发启动，在结束本次运维命令或者本轮运维行为之后，使得伴生容器失效，下一次需要使用时再次获取有效可用的伴生容器，如此，通过这样的“用完即弃”的灵活动态的处理方式，能够及时释放伴生容器的资源，减少对整个系统的压力；不仅如此，还有助于减少间接地通过伴生容器来攻击业务容器的风险。
56.需要说明的是，上一段强调的是在阶段性运维结束后，及时地自动干预以降低伴生容器给整个系统带来的影响。在实际实施时，根据需求选择合适的具体干预时机和干预手段。比如，可以根据运维管控界面确定本轮运维行为是否结束，若在运维管控界面中，检测到用户关闭相应的容器内视图或者用户点击用于明确确认结束运维行为的控件，则可以确定已结束，进而及时地自动干预，比如自动将伴生容器转为非运行状态，或者自动删除伴生容器，等等。
57.在本说明书一个或多个实施例中，通过为伴生容器配置资源限制信息，限制对伴生容器的资源的使用。
58.具体到本方案的场景，至少可以限制运维命令过多地使用甚至爆掉伴生容器的资源。若伴生容器的资源基本都提供给运维命令使用，则可以相对简单地设定资源限制信息的具体内容，比如，定义为1核500m内存，那么运维命令能够获得的资源将不能超过1核500m
内存。当然，根据实际需要，还可以更细粒度地设定资源限制，比如，允许指定类型的运维操作步骤最多占用多少内存，用于根据运维命令与目标业务容器交互的进程最多占用多少内存，用于为运维指令服务的最大允许线程数，等等。
59.s106：在所述资源限制信息指示的限制下，获取所述伴生容器的资源。
60.在本说明书一个或多个实施例中，运维人员下达运维命令后，根据运维命令获取伴生容器的资源，以用于执行运维命令。资源限制信息指示的限制，在运维命令的执行过程中也是有效的，在执行过程中，运维命令所占据的资源可能是动态变化的，若变化至要突破限制，则可以通过伴生容器就将运维命令进行限制甚至终止，从而不至于影响到业务容器的运行。
61.具体比如，无论是在执行运维命令前，预取伴生容器的资源，还是在执行过程中动态获取伴生容器的资源，可以由伴生容器根据资源限制信息，对运维命令的情况进行监测，判断待执行或者执行中的运维命令所需的资源，是否将导致或者已导致资源限制信息指示的限制被突破，若是，则可以及时采取相应的防御措施以保护目标业务容器中的业务运行，比如，通过伴生容器中止以等待有多余资源的调配使用，再重启运维命令，或者直接终止运维命令，优先保障业务。
62.s108：通过所述伴生容器与所述目标业务容器之间的交互，展示包含所述目标业务容器内的视图的运维管控界面，并利用所述资源执行针对所述目标业务容器的运维命令。
63.在本说明书一个或多个实施例中，根据所述伴生容器和所述资源，展示所述目标业务容器的运维管控界面，执行针对所述目标业务容器的运维命令。比如，在伴生容器内，利用上述的资源，启动运维命令并与目标业务容器交互，再继续利用该资源在目标业务容器内执行该运维命令，并且自动可以将视图从伴生容器内切换至目标业务容器内。
64.运维人员通过运维管控界面下达运维命令，考虑在伴生容器内直接执行针对目标业务容器的运维命令，如此，不仅不用占用目标业务容器的资源，连目标业务容器的环境都不用占用，可靠性更高。不过，这种方案也存在问题，在于在伴生容器内直接执行运维命令，则运维人员在运维管控界面，能够看到的是伴生容器的根目录文件和执行环境。而运维对象却是目标业务容器，在这种情况下，会给用户造成困惑和不一致的体验。
65.针对上一段的问题，对方案进一步改进。可以不在伴生容器内执行运维命令，伴生容器最多负责启动运维命令，实际执行运维命令则在目标业务容器内进行，为了提高用户的一致性体验，可以通过伴生容器与目标业务容器交互，将视图切换至目标业务容器内，则在运维管控界面，方便运维人员看到自己正在直接操作的数据和环境，交互体验更好。
66.更具体地，上述视图中展示的具体内容(称之为目标内容)根据需求确定。可以优先展示较为关键的内容，比如，根文件系统，除此之外，若有需要，还可以展示相关的至少部分命名空间等其他内容。
67.通过图1的方法，一方面，动态地为业务容器提供了可用的伴生容器，利用伴生容器的资源来执行针对业务容器的运维命令，而不用占用业务容器的资源，并且为伴生容器施以相应资源限制，使得若运维命令占用过多资源，则在该限制下只会影响运维命令本身，而不会威胁到业务容器中的业务进程；另一方面，虽然利用的是伴生容器的资源，但是通过伴生容器与业务容器之间的交互，可以切换到业务容器内的视图，在运维管控界面中进行
展示，以及在业务容器内执行运维命令，防止了伴生容器内的视图给用户带来困惑和不一致的感受，提高了用户在实施运维行为时的界面交互体验。
68.基于图1的方法，本说明书还提供了该方法的一些具体实施方案和扩展方案，下面继续进行说明。
69.在本说明书一个或多个实施例中，前面已经提到，本方案倾向于使用伴生容器的资源来执行运维命令，但是考虑到在一些应用场景下，若只将伴生容器用于为运维命令服务，则也不是适合为伴生容器分配或者预留过多的资源，因为在实际应用中，一轮运维行为中的具体操作未必是紧凑及时的，其中甚至可能有较长的空闲等待时间，在这种情况下，一些资源可能长时间被伴生容器占用，而又没有有效使用。
70.基于此，考虑以伴生容器为主，目标业务容器为辅，来为运维命令保证资源，如此，有助于减少伴生容器占据的资源，以及更充分地利用空闲资源，需要说明的是，虽然是以目标业务容器为辅，但是，本方案的整体思路仍然是尽量不打扰不威胁到目标业务容器。
71.更直观地，基于上一段的思路，本说明书一个或多个实施例提供了的一种应用场景下，获取和使用容器资源的一种具体实施方案的流程示意图，如图2所示。
72.图2的流程可以包括以下步骤：
73.s202：将待执行的所述运维命令分解为第一运维子命令集合和第二运维子命令集合。
74.在本说明书一个或多个实施例中，运维子命令之间具有执行先后顺序，第一运维子命令集合的执行顺序先于第二运维子命令集合的执行顺序。
75.s204：获取所述伴生容器的用于执行所述第一运维子命令集合的资源，以及向所述目标业务容器申请用于执行所述第二运维子命令集合的资源。
76.在本说明书一个或多个实施例中，可以将第一运维子命令集合划得相对小一些(占用资源相对少)，先来试探伴生容器的资源提供能力。执行第一运维子命令集合所需的资源，是少于完整执行运维命令所需的资源的，通过分解运维命令，使得对资源的阶段性需求更加明确具体，而不是上来就针对整个运维命令，请求足量甚至过量的资源，从而减轻了资源分配压力。
77.s206：若所述申请成功，则在所述第一运维子命令集合执行完毕后，利用所述伴生容器的资源继续执行所述第二运维子命令集合，并监测基于所述资源限制信息终止所述运维命令的终止风险。
78.在本说明书一个或多个实施例中，即使是在申请成功后，目标业务容器也可以暂时不将对方申请成功的资源予以分配，而是等待对方实际要使用时再分配，也即，尽量将这部分资源先保持在自己手里，可以暂时用于业务运行，从而能够尽量减少对业务的打扰。
79.运行第二运维子命令集合的过程中，由于资源需求发生变化，因此，有可能导致资源限制被突破，终止风险则反映了该资源限制被突破的风险。
80.s208：若所述终止风险大于设定阈值，则获取从所述目标业务容器申请的资源，用于执行所述第二运维子命令集合中的未执行部分。
81.在本说明书一个或多个实施例中，若终止风险大于设定阈值，则意味着单凭伴生容器的资源可能已不足以支持第二运维子命令集合的继续执行。那么可以选择终止第二运维子命令集合，当然，这样会给运维人员带来负面体验，而在有目标业务容器辅助的情况
下，可以利用从目标业务容器申请成功的资源，继续执行第二运维子命令集合，当然，更可靠的，此时目标业务容器可以检测自身当前是否适合提供这部分资源，若结果为否，那么哪怕之前申请成功了，目标业务容器也可以拒绝提供资源，优先保障业务。
82.按照类似的思路，可以运维命令分解为更多的子集合，以此缓冲资源矛盾，给予伴生容器与目标业务容器之间更多的资源协调空间。
83.通过图2中的方案，在启用了伴生容器的前提下，释放了目标业务容器的资源，然而有没有完全释放，而是将目标业务容器的资源作为紧急情况下的辅助备选，通过细粒度地阶段性地划分资源需求，尽量降低这个辅助备选给目标业务容器带来的额外影响，从而兼顾了正常业务和运维人员的体验，而且又更充分地利用了容器资源。
84.在本说明书一个或多个实施例中，在上面的情况下，目标业务容器与伴生容器不仅共享命名空间，而且在资源也有部分协同的场景存在。对于运维人员而言，可能需要掌握两种容器之间的即时关系和配合情况，那么，如果只有目标业务容器内的视图，则运维人员只能掌握结果性的相关情况，但是对于原因性和过程性的数据确却了解不够，这是不利于发现和定位运维过程中产生的相关问题的。为了解决这个问题，可以在界面上对于两者之间的关系情况进行及时呈现。
85.具体比如，获取伴生容器内的目标内容的视图，根据获取的视图，建立目标业务容器内的目标内容与伴生容器内的目标内容之间的映射关系，并生成相应的映射关系视图，在当前默认的运维管控界面中展示并动态更新映射关系视图。以资源为例，当目标业务容器介入进行资源辅助时，及时将为部分执行第二运维子命令集合使用的伴生容器的资源与从目标业务容器成功申请的资源进行映射，以动态反映两种容器响应于运维行为而负担的实时资源压力。
86.在本说明书一个或多个实施例中，运维管控人员往往是通过别的设备，来对目标业务容器对应的物理机进行操作，为了更好地与运维管控人员对接，可以在该物理上构建专门的代理，用于接收、转达、处理或者响应反馈运维管控人员下达的运维命令，以及用于统一管理伴生容器。基于这样的思路，本说明书一个或多个实施例提供了的一种应用场景下，图1中方法的一种具体实施方案的流程架构示意图，如图3所示。
87.在图3中，上述的对应的物理机具体为目标业务容器所在的物理机。运维管控界面比如为一个web用户交互界面，该界面在该物理机以外的某个运维设备上展示，以供运维人员进行操作，在该物理机上设置有运维代理，运维管控界面能够与运维代理之间建立运维命令通道。基于本方案，在一轮运维行为中，该框架具体可以按照以下方式工作。
88.运维人员进行操作，使得运维设备展示当前默认的运维管控界面，在该默认的界面上，运维人员可以指定自己想要操作的目标业务容器，此时的界面上尚且不能够展示目标业务容器内的一些具体视图，比如，根文件系统和命名空间等内容的视图。运维人员通过该界面下达针对目标业务容器的运维命令，具体比如表现为指示目标业务容器执行诸如/bin、/bash等目录下的程序。
89.该物理机上的运维代理通过运维命令通道，接收到运维命令。之后，运维代理可以通过docker run命令，为目标业务容器拉起动态的伴生容器，可以使伴生容器与目标业务容器共享所有的命名空间。为伴生容器单独设置有资源限制信息，这里的单独的意思是：伴生容器自己拥有资源，这部分资源并不属于目标业务容器，对这部分资源的使用进行限制，
该限制并不直接作用于目标业务容器。
90.在伴生容器启动后，运维人员能够通过运维管控界面查看伴生容器内的视图，处于更好的体验考虑，伴生容器可以启动运维命令，为待执行的该运维命令获取伴生容器的资源，并自动启动设定的容器间访问程序，通过容器间访问程序，从伴生容器访问目标业务容器，以获取目标业务容器内的目标内容(比如，根文件系统、命名空间等)的视图，从而使得对运维管控界面，由伴生容器内的视图切换至目标业务容器内的视图。若预判该运维命令所需资源将突破限制，则可以直接终止运维命令。
91.在目标业务容器内的视图下，利用伴生容器的资源，在目标业务容器内实际执行运维命令，在执行过程中，若出现资源突破限制的风险，同样可以直接终止运维命令。
92.通过图3中的方案，基于动态的伴生容器，为运维命令明确添加了资源限制，以限制其反客为主，不合理地抢占过多资源，不仅如此，还将容器间访问程序，用于及时地切换容器间目标内容的视图，以实现运维人员对操作目标业务容器的视觉反馈期望。最终达到的效果包括：从用户体验上而言，运维人员看到的是所见即所得的目标业务容器的视图，便于下一步运维行为，同时，所有的运维行为耗费的资源可控，不会因为资源突破限制而伤害到正常的业务进程，提高了系统整体的可靠性。
93.基于同样的思路，本说明书一个或多个实施例还提供了上述方法对应的装置和设备，如图4、图5所示。
94.图4为本说明书一个或多个实施例提供的一种针对容器运维的业务处理装置的结构示意图，所述装置包括：
95.容器物理机确定模块402，确定目标业务容器对应的物理机；
96.伴生容器启动配置模块404，确定与所述目标业务容器的命名空间相关的资源限制信息，在所述物理机上，为所述目标业务容器启动与目标业务容器共享所述命名空间的伴生容器，并为所述伴生容器配置所述资源限制信息；
97.伴生容器资源获取模块406，在所述资源限制信息指示的限制下，获取所述伴生容器的资源；
98.运维管控交互执行模块408，通过所述伴生容器与所述目标业务容器之间的交互，展示包含所述目标业务容器内的视图的运维管控界面，并利用所述资源执行针对所述目标业务容器的运维命令。
99.可选地，所述伴生容器资源获取模块406，判断待执行的所述运维命令所需的资源是否导致所述限制被突破；
100.若是，则通过所述伴生容器终止所述运维命令。
101.可选地，所述伴生容器启动配置模块404，确定所述物理机上设置的运维代理；
102.与所述运维代理之间建立运维命令通道；
103.通过所述运维命令通道接收待执行的所述运维命令，以使所述运维代理启动与目标业务容器共享所述命名空间的伴生容器。
104.可选地，所述资源限制配置用于限制进程所需使用的资源，所述运维命令通过所述进程执行；
105.所述伴生容器启动配置模块404，为所述目标业务容器启动与目标业务容器共享进程标识的命名空间的伴生容器。
106.可选地，所述伴生容器资源获取模块406，将待执行的所述运维命令分解为第一运维子命令集合和第二运维子命令集合；
107.获取所述伴生容器的用于执行所述第一运维子命令集合的资源，以及向所述目标业务容器申请用于执行所述第二运维子命令集合的资源；
108.所述运维管控交互执行模块408，若所述申请成功，则在所述第一运维子命令集合执行完毕后，利用所述伴生容器的资源继续执行所述第二运维子命令集合，并监测基于所述资源限制信息终止所述运维命令的终止风险；
109.若所述终止风险大于设定阈值，则获取从所述目标业务容器申请的资源，用于执行所述第二运维子命令集合中的未执行部分。
110.可选地，所述目标业务容器的启动早于所述伴生容器的启动；
111.所述伴生容器启动配置模块404，在所述运维管控交互执行模块408展示包含所述目标业务容器内的视图的运维管控界面，并利用所述资源执行针对所述目标业务容器的运维命令之后，还执行：
112.根据所述运维管控界面确定本轮运维行为是否结束；
113.若是，则自动将所述伴生容器转为非运行状态，或者自动删除所述伴生容器。
114.可选地，所述运维管控交互执行模块408，在展示包含所述目标业务容器内的视图的运维管控界面之前，还执行：
115.展示当前默认的运维管控界面，以便通过所述当前默认的运维管控界面下达待执行的所述运维命令；
116.所述运维管控交互执行模块408，在所述伴生容器内，启动设定的容器间访问程序；
117.通过所述容器间访问程序，访问所述目标业务容器，以获取所述目标业务容器内的目标内容的视图；
118.在所述当前默认的运维管控界面中展示所述目标业务容器内的目标内容的视图，得到所述目标业务容器的运维管控界面。
119.可选地，所述运维管控交互执行模块408，通过所述容器间访问程序对所述目标业务容器的访问，进入所述目标业务容器内；
120.在所述目标业务容器内，利用所述伴生容器的所述资源，执行针对所述目标业务容器的运维命令。
121.可选地，所述运维管控交互执行模块408，获取所述伴生容器内的目标内容的视图；
122.根据获取的所述视图，建立所述目标业务容器内的目标内容与所述伴生容器内的目标内容之间的映射关系，并生成相应的映射关系视图；
123.在所述当前默认的运维管控界面中展示所述映射关系视图。
124.可选地，所述目标内容包括命名空间和根文件系统。
125.图5为本说明书一个或多个实施例提供的一种针对容器运维的业务处理设备的结构示意图，所述设备包括：
126.至少一个处理器；以及，
127.与所述至少一个处理器通信连接的存储器；其中，
128.所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：
129.确定目标业务容器对应的物理机；
130.确定与所述目标业务容器的命名空间相关的资源限制信息，在所述物理机上，为所述目标业务容器启动与目标业务容器共享所述命名空间的伴生容器，并为所述伴生容器配置所述资源限制信息；
131.在所述资源限制信息指示的限制下，获取所述伴生容器的资源；
132.通过所述伴生容器与所述目标业务容器之间的交互，展示包含所述目标业务容器内的视图的运维管控界面，并利用所述资源执行针对所述目标业务容器的运维命令。
133.处理器与存储器之间可以通过总线通信，设备还可以包括与其他设备通信的输入/输出接口。
134.基于同样的思路，本说明书一个或多个实施例还提供了对应于上述方法的一种非易失性计算机存储介质，存储有计算机可执行指令，所述计算机可执行指令设置为：
135.确定目标业务容器对应的物理机；
136.确定与所述目标业务容器的命名空间相关的资源限制信息，在所述物理机上，为所述目标业务容器启动与目标业务容器共享所述命名空间的伴生容器，并为所述伴生容器配置所述资源限制信息；
137.在所述资源限制信息指示的限制下，获取所述伴生容器的资源；
138.通过所述伴生容器与所述目标业务容器之间的交互，展示包含所述目标业务容器内的视图的运维管控界面，并利用所述资源执行针对所述目标业务容器的运维命令。
139.在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(programmable logic device,pld)(例如现场可编程门阵列(field programmable gate array，fpga))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片pld上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(hardware description language，hdl)，而hdl也并非仅有一种，而是有许多种，如abel(advanced boolean expression language)、ahdl(altera hardware description language)、confluence、cupl(cornell university programming language)、hdcal、jhdl(java hardware description language)、lava、lola、myhdl、palasm、rhdl(ruby hardware description language)等，目前最普遍使用的是vhdl(very-high-speed integrated circuit hardware description language)与verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。
140.控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(application specific integrated circuit，asic)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：arc625d、atmel at91sam、microchip pic18f26k20以及silicone labs c8051f320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
141.上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
142.为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本说明书时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
143.本领域内的技术人员应明白，本说明书实施例可提供为方法、系统、或计算机程序产品。因此，本说明书实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本说明书实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
144.本说明书是参照根据本说明书实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
145.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
146.这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
147.在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网
络接口和内存。
148.内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flash ram)。内存是计算机可读介质的示例。
149.计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
150.还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
151.本说明书可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
152.本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、设备、非易失性计算机存储介质实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
153.上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
154.以上所述仅为本说明书的一个或多个实施例而已，并不用于限制本说明书。对于本领域技术人员来说，本说明书的一个或多个实施例可以有各种更改和变化。凡在本说明书的一个或多个实施例的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本说明书的权利要求范围之内。