中国科技核心期刊      中国指挥与控制学会会刊     军事装备类重点期刊
Weapon & Information System

Research on rapid deployment for command and control software based on container technology

  • MEN Hongshuan ,
  • LI Zhaorui ,
  • GUO Baofeng ,
  • YIN Wenlong
Expand
  • Army Engineering University of PLA, Shijiazhuang 050003, China

Received date: 2024-11-14

  Revised date: 2024-12-12

  Online published: 2025-03-27

Abstract

This paper focuses on the deployment method and implementation of command and control software, and focuses on the rapid deployment of applications. Based on the practical testing of container technology's technical conditions and advantages, this paper analyzes the potential application prospects of container technology in charge software. It proposes a design concept for rapidly deploying charge software using containers, while also analyzing the shortcomings and defects of traditional deployment methods. Furthermore, it designs a logical architecture and summarizes key technologies that need to be addressed for rapid deployment and solving difficult problems. This provides valuable reference for further improving and upgrading the software.

Cite this article

MEN Hongshuan , LI Zhaorui , GUO Baofeng , YIN Wenlong . Research on rapid deployment for command and control software based on container technology[J]. Command Control and Simulation, 2025 , 47(2) : 113 -120 . DOI: 10.3969/j.issn.1673-3819.2025.02.015

在军事竞争中,率先充分挖掘技术创新成果并加以军事化应用的一方,将开启新的竞争机制并抢占制高点。在智能化为背景的信息化战争中,指挥控制行为主要依托指挥控制软件来实现,实现指控软件快速部署是打赢现代信息化战争的重要一环。传统指控系统软件部署量大,部署效率不高。在指控集群部署过程中,需操作人员手动执行每一个步骤,不仅容易出错,而且耗时较长,在添加新设备或进行重大配置更改时,又需要手动重新部署整个集群,导致软件系统快速响应能力不够迅捷。并且软件部署采用逐机下载或介质复制安装方式,面对终端类型复杂的指控集群,这种方式耗时耗力,若软件运行环境配置不当还会导致未知的错误,从而不得不进行重新部署。
强化指控软件面对战场环境变化时的即时重构能力和自主调优能力,有利于提升指控软件动态抗毁能力,持续保障作战任务完成。容器是物理机虚拟化过程中一种标准的软件单元,它将程序运行所需的代码及其所有依赖环境打包成镜像,使得应用程序能够实现更加便捷、高效、准确的部署[1]。容器化部署方式更适用于软件应用安装配置繁杂的部署场景,引入容器技术为指控软件快速部署提供了新思路。

1 容器化技术分析

1.1 容器技术概念

容器(container)技术是一种轻量级的操作系统层面的虚拟化技术, 能够为软件应用及其依赖环境提供一个资源独立的虚拟运行空间[2]。容器借鉴了现实生活中“集装箱”的含义,为应用程序部署运行提供了统一的、标准化的、隔离的运行环境,应用程序及其依赖环境在容器中运行,而各容器对外有统一的API接口标准。容器技术使得应用程序的部署不再需要单独预配置其依赖环境,容器内的应用程序与底层操作系统实现解耦, 并可在不同宿主机上敏捷部署[3]。部署方式如图1所示。
图1 容器技术部署软件对比图

Fig.1 Container technology architecture diagram

在众多容器技术中,Docker[4]是目前使用范围最广的容器引擎。Docker容器平台使用C/S(client-server)架构,主要由客户端、守护进程、镜像、容器、镜像仓库五个部分组成。它们之间的交互如图2所示。
图2 Docker架构图

Fig.2 Docker architecture diagram

Docker容器最初是在Linux系统上开发和广泛使用的,但随着技术的发展,通过使用适当的工具和解决方案,现在也可通过Docker Desktop在Windows操作系统上构建和运行容器镜像,使得容器技术在各类装备的嵌入式系统中应用成为可能。

1.2 容器编排部署工具

为了更好地自动化管理和拓展容器,我们需要使用容器编排工具。目前使用最广泛的容器编排工具是Kubernetes[5],它使得部署和管理容器化的应用更加简单高效。Kubernetes采用声明式接口设计理念,用户通过定义资源对象的期望状态来管理Kubernetes集群中的资源,资源对应的控制器则负责保证资源对象从“当前状态”迁移到“期望”状态。这种思想将资源定义与具体实现解耦,提升了Kubernetes的自愈能力,使其更易于使用和扩展。Pod是Kubernetes中的基本单位,是在容器之上抽象出的一个概念。如果将Pod比作一颗花生,容器可以比作花生内部的种皮,镜像可比作花生最内部的种子。单个Pod内可包含若干个容器,所有容器共享Pod的资源[6]
传统指控软件运行中,如果IP地址发生变化,需重新配置并全部重启后,才可正常使用。但容器彼此之间是隔离的,每个容器都拥有自己独立的文件系统、网络栈和进程空间,更新域只需Kubernetes将对应的容器进行重新配置后重启容器即可。对于战损或故障的指控节点,Kubernetes可通过自动控制将其剔除出指控集群,防止资源浪费和系统整体瘫痪。

2 引入容器技术优势

传统的指控软件部署方式是通过存储介质或网络传输的方式,复制指控应用软件各安装包至目标计算机,然后在相应宿主机中配置软件运行所需的依赖环境,环境配置正确后, 执行应用包来运行程序,整个流程完成后,指控应用才可对外提供指控服务。在部署过程中,部署、安装、调试的工作量大,尤其环境的配置非常繁琐且细致,稍有疏忽就会造成配置错误,后期对于软件集群的调整部署不够友好。
容器化技术日益成熟,阿里巴巴[7]、腾讯[8]、华为[9]等一线互联网公司在实践中广泛应用,进一步验证了容器技术的可靠性。指控软件部署研究可吸纳互联网实践中的先进技术与研究成果。与传统部署方式相比,容器技术具有以下优势:
•部署难度降低。容器技术不再需要单独配置应用程序运行所需的运行环境,降低了部署软件的复杂度,在宿主机中安装相应的容器引擎,通过拉取镜像便可进行各设备终端的一致部署,减少环境依赖的配置环节,确保了指控软件部署的质量和效率。
•资源利用率高。由于部分装备硬件资源有限,导致可装应用软件的数量和大小受限。容器通过共享主机系统的资源(如CPU、内存和网络)来运行,从而实现了资源的最大化利用。这使得利用容器在相同的硬件资源下可以运行更多的应用程序实例,进一步提高了装备硬件资源的利用率。
•快速启动。由于轻量级的特性,容器的启动和停止速度更快,可达到秒级启动,这使得指控应用程序部署过程中更加快速高效,在紧急情况下,可迅速启动新装备以替换战损装备。
•隔离性好。容器的实质是进程,但与直接在宿主机执行的进程不同,容器进程运行于独立的命名空间[10]。由于指控过程的复杂性,各指控应用间调用瞬时并发较高,各应用间通过容器隔离,有利于减少单个应用故障导致的系统瘫痪。
•可弹性伸缩。容器化就是将应用程序及其依赖打包成一个可重复拉取的镜像(image),部署到某个容器中,从而确保应用程序在不同环境中能够一致地运行。这种容器为构建可伸缩的集群管理提供了完美的粒度水平。由于每个容器服务在独立空间中运行,单个容器变化理论上不会影响其他容器,在Kubernetes编排功能的运行下,可实现集群中成员的添加或缩减,新的装备设备可随时加入战斗,战损装备也可及时退出指挥集群,减少指控资源占用,提高了指控软件的可用性和灵活性。

3 指挥控制软件快速部署分析

3.1 实现快速部署的功能性需求

运用容器技术须将原有指控应用软件根据业务功能和领域模型进行微服务拆分,将每个微服务的代码及依赖环境打包成镜像,并通过战术云平台完成镜像的传递和储存。战术云平台采用B/S架构,部署在战场前沿服务车内,操作人员在浏览器的网页上进行相关操作,触发云端请求,经由网关后,由Kubernetes平台统一管理调度。一组服务部署在一个Pod内,Pod中运行着支持这组服务各项功能实现的容器。
指控应用各微服务部署完成后最终运行于各容器内,部署方式为镜像拉取和运行。为便于镜像的存储与管理,应建立专有的私有镜像仓库。客户端与云端系统的交互模块,前端和后端功能实现分离,与客户端的各类交互接口部署于前端,便于客户端人员通过浏览器对指控软件部署进行操作。

3.2 实现快速部署的非功能性需求

•从灵活可扩展角度分析。由于装备设备的差异性,不同应用部署的服务存在差异,微服务拆分时各模块之间耦合度应足够低,实现共有功能的下沉,以便于既能针对不同业务功能灵活部署应用,又能实现不同级别指挥平台和不同装备间的互联互通,使得指控软件具有足够的灵活度以支持复杂的应用场景。
•从便于部队操作使用角度分析。部署过程应实现操作界面窗口化,便于一个不懂运维和开发的一线保障人员根据操作手册也能够快速、便捷地将指控软件部署到相应的设备,而不需要寻求专业软件开发人员的帮助。
•从节省资源角度分析。对于某节点指控软件的部署过程,需要根据各席位不同的应用需求来选择合适的配置镜像。在实际执行过程中,应支持各席位自定义依赖,即通过存储卷将已下载好的应用进行挂载,以便于同一指挥车上的各席位对软件运行的相同依赖环境进行复用,避免同一车组人员重复下载相同的环境依赖数据,造成网络及存储资源的浪费。
•从运行可靠性角度分析。单个指控节点的指控应用包含多个功能,数个微服务的功能组合起来才能支持应用实现全部需求,一旦某个容器运行出现异常,可能导致部署完成后应用某项功能异常或无法使用,甚至整个指控节点无法运行,因此,各容器间之间应具备强大的异常检测和故障自愈能力,提升可靠性。

3.3 实现快速部署的逻辑架构设计

基于传统的指挥信息系统,将各项指控软件业务合理拆分为相应的微服务模块,进而运用容器化技术进行部署。以某级指挥集群为例,将某级指挥平台打造为轻量战术云平台,本级服务器作为战术云端服务器,数据通过各级交换机进行中转,下属各级指挥车及各类装备终端为客户端。快速部署逻辑架构设计如图 3所示。
图3 指挥集群部署逻辑架构图

Fig.3 Command cluster software deployment architecture diagram

软件科研单位完成指控软件的微服务开发后,进行镜像封装,供应至本级指挥平台,镜像经本级指挥平台由保障人员推送至镜像仓库服务器。在服务器内部依据私有镜像仓库规范,搭建镜像仓库服务器,负责管理和存储本级指挥集群的全部镜像,并向各指挥层级装备设备群提供镜像下载服务。为保证镜像存储的高可靠性,镜像仓库服务器宜采用主备集群策略。
服务器集群需预置Kubernetes和容器环境,各级指挥车设备群和各类装备终端群需预置容器引擎及环境。根据战时网络环境,可采取在线部署和离线部署两种方式,在网络不畅时,可采用离线方式进行容器化环境的安装与部署[11]。云端服务器集群由Kubernetes管理,一线指挥保障人员通过简单的命令行操作或可视化窗口进行镜像拉取和运行,使指控应用微服务实例正常运行于各自的容器中并保持良好的交互,完成指控软件各应用的部署和管理,从而使指控节点中的整个应用正常运行,达到相应指挥效果,保障战斗任务圆满完成。
基于容器轻量、敏捷的技术特性,保障人员可在较短时间内完成各终端设备指控软件的部署任务,若某装备设备发生故障,也便于新装备及时进行软件部署后替换,保障指挥控制系统在故障状态中快速恢复。且Kubernetes具有跨数据中心的可移植性,使得指控软件系统可具备云端应用级的容灾方案。

4 关键技术实现

基于容器技术部署指控软件,关键技术主要包括微服务拆分、镜像推送及拉取、镜像部署和容器编排管理4个阶段,如图4所示。
图4 关键技术概略图

Fig.4 Key technologies schematic diagram

指挥车及各装备宿主机为各指控节点提供硬件及基础操作系统支持。配置中心集中管理指控集群中不同节点的微服务应用的配置,配置修改后能实时推送到装备设备端,容器运行使用过程中的各项配置均在配置中心进行管理,确保配置的安全性和可控性。服务注册中心提供了服务注册、服务发现、心跳检测和数据同步、客户端缓存等功能,确保本级指挥中心对下级各指控节点的实时指挥和控制以及各节点间进行信息交互。当容器中的微服务启动后,首先读取容器中包含注册中心地址信息的文件,根据地址连接到注册中心的配置中心,从配置中心读取服务注册地址,然后将容器地址登记到注册中心。注册中心还会提供其他微服务的注册信息,微服务通过注册信息与其他微服务实现交互[12]。在运行过程中,各节点会缓存其他节点的注册地址,如本机指挥中心受敌打击失去效能,各指挥节点仍可根据缓存中的地址进行交互,确保后续战斗任务继续进行。

4.1 微服务拆分阶段

指控软件科研开发人员将传统指控软件根据软件功能领域,按照最优的拆分策略进行微服务拆分。软件集成采用使用广泛的Spring Cloud微服务架构[13],开发人员完成微服务应用的开发后,将代码上传至本地的GitLab版本管理平台进行代码版本管理。Jenkins为自动化开源服务器,它功能强大,提供了自动化集成和部署的框架[14]。代码开发过程中的版本控制及镜像制作,均在保密良好的局域网中进行,确保指控软件的绝对安全性。基于容器技术的软件开发采用标准化的API接口进行交互,有利于推进行业级的标准化,克服目前指控领域各单位进行散点开发和重复建设的弊端,促进科研团队集中力量研发打赢亟需的关键组件。

4.2 镜像推送和拉取阶段

按照专网分离的原则,打包好的镜像包以离线方式推送至指挥平台的镜像仓库服务器,在服务器中形成运行着的多个Pod,预制的Kubernetes环境对所有镜像文件进行统一的管理和调度。指挥保障人员在稳定的战术局域网环境中,通过简单的命令行代码拉取各自作战对应功能的镜像。

4.3 镜像部署阶段

镜像拉取成功后,保障人员在容器中运行镜像,镜像程序会自动配置应用程序运行所需的依赖环境,同车组席位人员可共享其他席位依赖配置项。运行环境配置完成后,执行服务运行命令运行该程序,各微服务启动运行,并通过API接口与其他容器中的微服务进行交互和调度,形成完备的功能模块,应用程序部署成功。

4.4 容器编排管理阶段

各项应用实例最终运行在Kubernetes部署的Pod容器中[15],各指控节点上运行着多个Pod。 API 服务器会拦截处理所有指控节点的请求,并与控制器管理器和调度器交互共同处理请求。通过一系列认证和授权等操作后, Kubernetes会将请求信息存储到分布式键值存储系统中,保障人员通过Kubelet命令与API 服务器交互,从而对节点内Pod或者其他资源的操作,如图5所示。
图5 Kubernetes工作逻辑架构图

Fig.5 Kubernetes working logic architecture diagram

4.5 试验论证

本研究基于本地局域网服务器,以离线方式安装部署了Kubernetes软件和Docker软件,引入微服务架构应用进行试验论证。
试验采用微服务框架,应用容器化技术部署了基于百度飞桨深度学习框架构建的PP-LiteSeg智能语义分割模型,实现对侦察图片的语义化处理,并从本地服务器拉取语义分割后的处理结果。模型软件架构图如图6所示。
图6 模型软件架构图

Fig.6 Diagram of the model software architecture

模型镜像通过容器化方式部署到服务器后,在局域网内的3台计算机通过镜像拉取的方式,拉取模型镜像到本机。镜像中包含模型运行所需完整环境配置,在计算机内部署模型过程中,无须再配置模型运行所需环境依赖,运行镜像文件便可快速完成模型部署。部署完成后,可在Windows终端界面(如图7所示)或Docker Desktop软件界面(如图8所示)查看镜像部署情况和容器运行情况。
图7 Windows终端界面

Fig.7 The interface of Windows Terminal

图8 Docker Desktop软件界面

Fig.8 The software interface of Docker Desktop

通过Kubernetes平台,服务器端可调度3台计算机中的Pod,实现计算资源的负载均衡。计算机端输入图片,语义化处理后,服务器端及其他计算机均可灵活调取。处理效果如图9所示。
图9 软件运行效果图

Fig.9 The operational effect graph of the software

通过试验论证,Kubernetes软件平台和Docker软件离线部署使用效果良好,在局域网状态下,容器化部署更加便捷、快速、高效。Kubernetes对负载资源进行平衡调度, PP-LiteSeg智能语义分割模型运行稳定,达到了试验的预期效果,为下步指控软件容器化部署积累了经验。

5 面临挑战

5.1 微服务拆分较为困难

信息化作战指挥层级分布广,各兵种专业多样,武器平台复杂,传统指控软件系统本身非常庞大和复杂。因此在对指控软件进行微服务拆分重构过程中,应做好完整的模块划分,在确保软件应用功能不中断的前提下,采用“绞杀应用”模式[16],逐步将原有应用程序重构为微服务,重构过程需要数月甚至数年,是一项庞大而系统的工程。

5.2 容器技术使用的局限性

容器化技术本身存在一定的操作系统适配局限性,对操作系统的版本要求比较高,对于一些版本较低的操作系统并不友好,甚至无法使用。虽然容器技术具有轻量级的特点,但部署一定数量的容器仍会占用大量硬件资源,部分基于嵌入式操作系统的装备在有些场景不便于拉取镜像进行部署,无法利用容器的优点,我们只能以现行方式将应用部署到装备的物理机或者虚拟机上,这有待国产化厂家对容器技术的进一步优化改进。

5.3 速率瓶颈

容器化提升了物理机的硬件资源利用率,但数据交互所需网络资源随之增大。各指控应用业务高峰期并行数量大时,物理主机用来支撑容器的服务资源就会紧张,甚至造成队列堵塞[17],指控末端会感受到应用卡顿。战术云服务器端通过内部网络进行访问读写操作,网络带宽与数据吞吐速率是制约指控软件数据处理能力上限的瓶颈。

6 结束语

容器技术在互联网开发部署应用中扮演着越来越重要的角色,本文对指控软件快速部署应用进行探索,以解耦的思路从根源上提升指控系统的灵活性和稳定性,从而提升指控软件的部署效率,有利于从体系架构层面对现行指控软件系统改造调优,在未来战场争得“快敌一秒、先敌一步、胜敌一筹”的指控效果。
[1]
王琼. 微服务与容器化在图文包装集群中的应用[J]. 现代电视技术, 2020(1): 115-121.

WANG Q. Application of microservices and containerization in graphic packaging cluster[J]. Advanced Television Engineering, 2020(1): 115-121.

[2]
严亮亮. 面向轻量云的嵌入式系统容器化资源管理技术研究[D]. 北京: 北京邮电大学, 2020.

YAN L L. Research on containerized resource management technology of embedded system for lightweight cloud[D]. Beijing: Beijing University of Posts and Telecommunications, 2020.

[3]
郑国庆. 容器云平台上应用自动化部署系统的设计与实现[D]. 杭州: 浙江大学, 2021.

ZHENG G Q. Design and implementation of application automated deployment system on container cloud platform[D]. Hangzhou: Zhejiang University, 2021.

[4]
卢西亚诺·巴雷西, 乔瓦尼·夸特罗基, 尼古拉斯·拉西. 关于容器引擎的定性与定量分析[J]. 软件工程, 2024,210:111 965.

BARESI L, QUATTROCCHI G, RASI N. A qualitative and quantitative analysis of container engines[J]. The Journal of Systems and Software, 2024,210:111 965.

[5]
卡门·卡里翁. 基于Kubernetes的容器编排标准——文献统计分析[J]. 网格计算, 2022, 20(4):42.

CARMENC. Kubernetes as a standard container orchestrator-A bibliometric analysis[J]. Journal of Grid Computing, 2022, 20(4):42.

[6]
卡洛斯·德·阿方索, 阿曼达·卡拉特拉瓦, 赫尔曼·莫尔托. 基于容器的虚拟弹性集群[J]. 系统与软件, 2017,127:1-11.

ALFONSO D C, CALATRAVA A, MOLTÓG. Container-based virtual elastic clusters[J]. The Journal of Systems and Software, 2017,127:1-11.

[7]
阿里云[EB/OL]. https://www.aliyun.com/.

Aliyun[EB/OL]. https://www.aliyun.com/.

[8]
腾讯云[EB/OL]. https://cloud.tencent.com/.

Tencent cloud[EB/OL]. https://cloud.tencent.com/.

[9]
华为云[EB/OL]. https://activity.huaweicloud.com/.

Hicloud[EB/OL]. https://activity.huaweicloud.com/.

[10]
田源, 李樊, 汪晓臣, 等. Docker技术在乘客信息系统部署中的应用[J]. 铁路计算机应用, 2019, 28(5): 69-72.

TIAN Y, LI F, WANG X C, et al. Docker technology applied to deployment of passenger information system[J]. Railway Computer Application, 2019, 28(5): 69-72.

[11]
喜度, 殷笑茹, 牛霭琛. 基于关联挖掘的自动站数据质控方法的改进[J]. 气象水文海洋仪器, 2018, 35(4): 73-78.

XI D, YIN X R, NIU A C. Improvement for automatic station data quality control method based on association mining[J]. Meteorological, Hydrological and Marine Instruments, 2018, 35(4): 73-78.

[12]
迈克尔·索尔弗兰克, 弗里德尔·洛赫, 斯蒂夫·登特尼尔, 等. 对Docker在工业自动化中分布式和时间敏感型应用的轻量级虚拟化的评估[J]. IEEE工业信息学报, 2021, 17(5):3566-3 576.

MichaelS, Frieder L, Steef D, et al. Evaluating Docker for lightweight virtualization of distributed and time-sensitive applications in industrial automation[J]. IEEE Transaction on Industrial Informatics, 2021, 17(5):3566-3 576.

[13]
S.莱恩-沃尔什, J.斯蒂勒曼, F.桑托罗, 等. 基于Docker的MDSplus导论[J]. 融合工程与设计, 2021,165:112 121.

S.L,J.S,F.S, et al. Introduction to MDSplus using Docker[J]. Fusion Engineering and Design, 2021,165:112 121.

[14]
董子奇, 刘淇, 高原, 等. 基于容器技术的微服务部署研究[J]. 信息技术与标准化, 2023(1): 93-98.

DONG Z Q, LIU Q, GAO Y, et al. Research of microservice deployment based on container technology[J]. Information Technology & Standardization, 2023(1): 93-98.

[15]
曼尼什·阿比谢克, D.拉杰斯瓦拉·拉奥, K.苏布拉马尼亚姆. 利用Kubernetes和CI/CD流水线部署容器的框架[J]. 国际高级计算机科学及应用期刊, 2022, 13(4):522-526.

Abhishek K M, Rao R D, Subrahmanyam K. Framework to deploy containers using Kubernetes and CI/CD Pipeline[J]. International Journal of Advanced Computer Science and Applications, 2022, 13(4):522-526.

[16]
克里斯·理查森. 微服务架构设计模式[M]. 喻勇,译. 北京: 机械工业出版社, 2023:417-420.

CHRISR. Microservices patterns:with examples in Java[M]. Translated by YU Y. Beijing: China Machine Press, 2023:417-420.

[17]
刘宏娟, 黄炜, 李文吉, 等. 基于Kubernetes的卫星遥感数据容器云平台[J]. 计算机测量与控制, 2022, 30(1): 209-214, 220.

LIU H J, HUANG W, LI W J, et al. A Kubernetes based container cloud-platform of satellite remote sensing data[J]. Computer Measurement & Control, 2022, 30(1): 209-214, 220.

Outlines

/