2. 中国科学院大学天文与空间科学学院, 北京 100049;
3. 中国科学院空间天文与技术重点实验室, 北京 100101
2. University of Chinese Academy of Sciences, Beijing 100049, China;
3. Key Laboratory of Space Astronomy and Technology, Chinese Academy of Sciences, Beijing 100101, China
中法合作天文卫星(Space multi-band Variable Object Monitor, SVOM)的研究对象是来自宇宙深处的伽玛射线爆发，伽玛暴是宇宙中极端明亮的瞬变源，产生于大质量恒星塌缩或致密双星并合时恒星级黑洞或磁星喷射出的在视线方向的极端相对论性喷流①。伽玛暴爆发时，在很小的空间释放了巨大的能量，如伽玛暴和引力波暴等瞬变源光学对应体的后随观测与搜索对研究瞬变源的物理属性有重要作用[1]。伽玛暴研究具有拓宽或根本改变对一些重大天体物理问题认识的潜力。中法合作天文卫星通过对科学目标的实现，为研究暂现源涉及的从恒星、星系到宇宙学等天体物理学中的多领域，解决相关天体物理学领域的若干重大问题提供观测和数据基础①。
① A类先导专项实施方案-SVOM科学应用系统二期
天文数据档案库系统是中法合作天文卫星中方科学中心的重要组成部分，实现科学数据产品长期存档与数据产品查询检索，支持各级数据产品、工程数据、标定数据、辅助数据等的管理，数据产品版本可控，保证数据的安全性与完整性。数据档案系统提供统一的用户及数据存取管理平台，实现跨平台对科学数据产品存储、检索、提取、维护、分析、控制功能②。
② 光学载荷数据处理存储解决方案-用户手册
作为国际合作项目，中法合作天文卫星天文数据档案库系统需要在中法双方不同单位和场景进行测试、集成、调试。与一般基于互联网的应用部署不同，天文软件一般在部署运行时需要非常多的第三方库支持，运行时也有诸多参数以满足不同要求。天文领域对容器技术的使用还停留在天文应用软件的封装层面[2]，如何让天文学家快捷方便地使用天文数据档案库系统，让测试人员在中法双方调试环境中，不会因服务器迁移而进行重新部署测试环境的重复劳动，针对国际合作项目中服务器需要迁移的工作需求，即在中法双方调试环境中运行，可以采用将容器镜像导入法方服务器的方式，启动需要的容器服务，降低部署过程中出现问题的风险，节约时间和人力成本。容器技术具有轻量级、易移植且保证环境一致性的特点，为天文数据档案库系统环境部署和测试的首选解决方案。
1 容器技术简介容器是基于Go语言实现的云开源项目，其核心解决的问题是利用LXC实现类似虚拟机的功能，用更加节省的硬件资源给用户提供更多的计算资源。容器的主要目标是在任何地方构建、发布和运行任何应用程序，通过对应用程序的封装(Packaging)、分发(Distribution)、部署(Deployment)、运行(Runtime)等生命周期的管理，真正实现“一次封装，随处运行”[3]。
容器技术具有标准化、轻量级、迁移性和扩展性等显著特点，为了更好地理解容器技术，需要了解两个非常重要的基本概念：
(1) 镜像(Image)：是类似虚拟机的镜像，可以将它理解为一个面向容器引擎的只读模板，包含文件系统[3]。镜像可以从Docker Hub公共镜像源中下载，也可以在本地自行创建。
(2) 容器(Container)：是运行起来的镜像，所有容器运行在镜像上，如果把镜像理解为程序，那么容器可以看作是进程。
2 容器与虚拟机在软件测试中的应用特点及区别在软件测试中，软件环境的搭建直接影响测试结果的准确性和真实性。很多软件测试人员都有使用虚拟机的经验，即在传统物理机的基础上克隆虚拟机，这种镜像具有真实Windows, Linux操作系统的功能，在此基础上安装软件，配置参数，解决软件测试环境搭建和资源紧张的难题。
容器技术快速部署，高效构建应用，与宿主机共享内核资源优势，使测试人员在保证测试环境的标准性、数据隔离性和缺陷环境重现中得到很好的应用。特别是秒级的快速启动容器服务，软件测试效率显著提高。
容器相对于虚拟机，在轻量级、资源利用率方面具有明显的优势。从图 1 ③的对比可以看到，由于容器技术是虚拟化操作系统而不是硬件，是应用程序的抽象，多个容器可以在同一台机器上运行，与其他容器共享操作系统，占用空间少，可以处理更多的应用程序，从而减少对操作系统的需求。虚拟机是物理硬件的抽象，每个虚拟机都包含操作系统、应用程序及必要的二进制文件和库 ③。
|
| 图 1 容器与虚拟机的对比 Fig. 1 Docker Vs VM |
③ https://www.docker.com/resources/what-container
3 容器技术在天文数据档案库系统测试中的应用 3.1 天文数据档案库项目简介天文数据档案库主要实现科学数据产品长期存档、数据产品查询、检索、提取及分析等功能，支持跨平台运行，主要给用户提供管理接口、数据注入接口、数据检索接口以及数据获取接口。软件运行支持Linux平台，在项目测试中，服务器端操作系统使用Ubuntu, 数据库使用MySQL，网络服务器使用Tomcat，客户端运行使用赫歇尔空间天文台的地面系统软件平台(Herschel Interactive Processing Environment)，它是欧洲空间局最复杂的大型空间项目赫歇尔空间天文台的地面系统软件平台[4]。
针对项目的实际运行情况，需要满足数据处理功能要求、系统的长期可扩展性、后期大系统集成测试和上天设备的同步运行等各种复杂因素，如果采用传统的服务器客户端部署系统环境测试，势必造成每一次变动需要重新部署测试环境，耗费大量的时间和人力成本。
天文数据档案库系统作为中法双方合作项目，不同科学家常常使用不同软件开发语言版本，比如在中方运行环境中使用科学数据检索Python2的脚本没有错误，在法方部署环境中运行法国科学家创建的科学数据检索Python3的脚本出现运行抛错，虽然可以采用工具如Python Virtual Environment或者Anaconda帮助解决版本不同的问题，但是安装工具Anaconda中本身碰到的错误，如选择是否添加到系统路径还是使用默认Python的路径不正确，直接导致使用Python运行出错。如果有一种更为快捷的方式帮助测试人员快速进行环境配置，准确定位发现软件的缺陷，使测试工作进行更加顺畅。
采用容器技术，在软件测试中保证复杂的天文软件环境一致，重现测试中发现的软件缺陷并复制测试环境，有效运用有限的测试环境资源和人力资源，极大地提高测试工作效率。
3.2 天文数据档案库环境搭建通过图 2可以看到，容器技术如何在实际项目测试环境搭建中的应用。
|
| 图 2 天文数据档案库测试模块及环境部署图 Fig. 2 Astronomical data archive system testing modules and environment deployment diagram |
(1) 首先建立一个宿主机环境，本项目使用Ubuntu 14.04.5并在该环境下安装Docker软件包和依赖包，
(2) 建立数据库容器，下载MySQL 5.7镜像，使用命令
docker pull mysql/mysql-server: 5.7.24
启动容器并指定端口3306，将数据库容器的端口映射到宿主机上，使用命令
docker run -p 3306: 3306-name mysql -e MYSQL_ROOT_PASSWORD=123456 -d mysql
成功启动数据库容器并进入，将数据库配置文件my.cnf中port修改为容器启动的端口3306，执行SQL语句创建用户管理库及创建权限库。
(3) 建立天文数据档案库应用程序容器，拉取Tomcat-7.0.67容器镜像，使用命令
docker pull tomcat: 7.0.67
启动容器并指定端口8000，使用命令
docker run -p 8000: 8000 tomcat: 7.0.67
运行容器，将数据档案库应用程序war包复制到该容器对应的路径，并进行相关参数以及数据库的配置，输入正确的数据库容器IP和数据库密码，重新启动容器使用命令
docker stop < containerID>
docker start < containerID>
可以通过curl命令在应用程序容器里检查天文数据档案库应用程序容器和数据库容器连接是否成功
curl http://ip : 3306
(4) 建立用户管理子系统容器, 拉取Tomcat-6.0.45容器镜像并指定端口启动容器，使用命令
docker pull tomcat: 6.0.45
成功启动并进入容器，对相应配置文件和数据库进行配置，重启容器，检查数据注入是否成功
(5) 建立天文数据档案库系统镜像，对数据库容器、天文数据档案库应用程序容器、用户管理子系统容器创建新的容器镜像，使用命令
docker commit -a “tester” -m “test” < containerID> test: v01
完成镜像创建后，通过docker images查看新创建镜像是否已经在本地提交。
(6) 导出导入镜像，针对天文数据档案库系统需要在中法双方调试的实际需求，可以通过导出在中方调试成功的镜像，导入法方运行环境中，从而避免部署过程中出现问题，使测试人员更加关注软件功能测试。导出镜像使用命令
docker save -o test.tar test: v01
导入镜像使用命令
docker load-input test.tar
(7) 天文数据档案库系统中载荷数据处理存储解决方案，提供应用程序接口依赖于HIPE[4]提供的ProductStorage Java API接口②，实现天文数据档案库在HIPE中交互访问，在HIPE脚本指令区，通过脚本调用产品归档、检索、获取、分析功能，在HIPE控制台区，可以查看脚本运行的结果，即通过数据注入接口和数据查询接口成功将数据产品存入天文数据档案库并查询已存入的科学数据产品。
(8) 通过图 3可以看到，容器技术在天文数据档案库系统测试中的应用即容器创建、运行、提交镜像的全流程，将数据库、应用程序、用户管理子系统分别部署在3个不同的容器；对用户管理子系统和应用程序的各个模块进行测试，验证科学数据产品存储、检索、提取、维护、分析、控制功能是否正常工作；将测试通过的容器镜像提交到容器仓库。
|
| 图 3 天文数据档案库系统测试流程图 Fig. 3 Astronomical data archive system test flowchart |
测试人员都有这样的经验，同样的环境配置和产品发布版本，在不同的机器或者不同的集成环境中安装有可能失败，造成这样的结果有很多因素，而环境的标准化无疑是这种问题的有效解决方式。通过以上项目实例，容器技术在天文数据档案库系统测试中的主要优势有以下几点：
(1) 测试环境标准化：在传统测试工作中，不同操作系统和数据库版本有不同限制，比如Linux平台中Ubuntu和Centos, 运行安装命令完全不同，Ubuntu安装命令执行apt-get，Centos安装命令执行yum。在天文数据档案库系统测试中，因为MySQL版本不同，SQL语句执行datetime字段出现高版本5.7运行低版本SQL语句抛错，数据不能导入的错误。
天文数据档案库系统测试环境选用Ubuntu14和MySQL5.7，在交付用户的使用环境采用容器将操作系统和数据库打包到新的镜像，容器标准化使开发、测试、运维环境保持一致[5]，避免用户由于使用不同版本操作系统或数据库造成运行程序抛错，在需要调试排错时，开发测试人员可以直接使用打包镜像针对问题研究，而不会因环境问题损耗时间。
(2) 测试安装简洁化：软件测试过程中，安装测试是测试工作的第1步，也是软件功能、集成、压力测试的重要保障。在传统测试过程中，以天文数据档案库系统为例，由于项目设计需要安装不同版本的网络服务器Tomcat，在设置环境参数CATALINA_HOME时，不注意区分多版本共存的问题，极易导致启动一个Tomcat而另一个版本的Tomcat也启动。
选择容器技术，在同一个宿主机环境里，运行两个不同版本Tomcat容器，在每个容器里配置对应的环境参数，通过不同的端口映射到宿主机，分别启动两个容器, 环境隔离有效避免了因环境参数配置的问题，导致启动一个Tomcat而另外一个启动的错误。安装测试时间减少，安装测试步骤更加简化，卸载安装时只需要删除容器，在几秒钟内启动一个新的基础容器进行环境配置，快速解决环境卸载不干净的问题。
(3) 测试功能扩展性：天文数据档案库系统采用迭代开发模式，通过用户使用反馈逐步完善产品功能，传统测试过程中，每次发布新的应用程序版本或产品功能修改更新，测试人员需要重新搭建测试环境，重复劳动造成测试工作效率降低。
运用容器技术，可以把Tomcat6.0/7.0作为基础镜像，每次发布新的应用程序版本，在基础镜像上更新配置快速搭建新环境，通过对各个独立容器进行扩展实现无缝化伸缩，而不需要对整个应用程序进行重新开发。同时在SVOM VOEvent网络系统中，也成功应用容器技术部署VOEvent原型系统，对中方科学中心的复杂项目集成测试工作流程和效率带来极大提高[6]。
(4) 测试数据隔离性：传统软件测试过程中，常常因为测试数据的增加，特别是天文软件环境配置复杂，天文数据档案库系统需要多次采用不同类型和不同数据量的数据进行测试，将各个子系统和数据库都部署在一个环境，极易造成测试中产生脏数据，重复读取数据的问题。
采用将数据库、应用程序、用户管理子系统分别部署在不同的容器，实现各自独立，测试数据分离，测试环境干净，可以随时切换测试场景，方便定位软件缺陷。同时，数据库容器独立，需要卸载数据库，通过容器删除命令就可以简单实现，避免卸载数据库环境不干净的问题。
(5) 问题重现便捷性：软件测试的一个重要目的是尽可能多地发现软件的缺陷。作为测试人员，发现缺陷后重现问题环境是帮助推进修正软件缺陷的重要工作环节，即使将代码和数据同时发布，比如一些未做文档记录的假设项、依赖项、配置项都会使重现问题非常困难[7]。传统测试过程中，由于测试数据交叉，测试案例复杂，发现软件缺陷常常无法将测试环境共享给开发团队。如果用传统虚拟机快照技术复制测试环境(包含操作系统)，极易造成资源占用过大[8]。
对于本项目测试中碰到的SQL语句版本问题导致数据不能导入数据库，因为需要对数据库本身的调试和对天文数据档案库的集成调试，找到建立用户系统不成功的根源，数据库、应用程序、用户管理子系统几个容器都需要保证问题环境完全相同，通过容器镜像可以在几秒内把测试环境成功复制，容器共享宿主机操作系统，层级简化，磁盘空间占用少。在试验中Docker1.4.1的环境新建一个容器需要12 KB磁盘空间，而同样的测试环境用虚拟机做快照占用资源将超过100 MB[9]。
5 总结从表 1可以看到，容器化服务器端环境并应用于软件测试中，相比传统的测试方法，可以极大地节省测试人员部署调试环境的时间，使测试环境标准化、测试数据隔离性、重现问题环境更加便捷。同时各个系统部署在各自独立的容器，进行配置连接，形成统一的整体应用程序，容器技术的这种高扩展性对于可以将应用程序独立于各个容器设计的项目尤为适用。在整个项目测试过程中，同时运行多个容器，对中央处理器、磁盘、内存等资源占用率小，启动和备份相对于传统虚拟机技术速度显著加快。容器技术的应用，为测试环境的稳定性和标准化提供了快捷高效的解决方案，为软件测试工作效率提高和成本降低提供了保障。
| Software test features | Issues in traditional testing methods | Docker technology solutions | Advantages of docker |
| Test environment standardization | Development, test, user environment issues caused by different OS and DB versions |
Make the user environment, development debug environment and test environment exact same by packaging the docker image |
Make the same development, test, and maintenance environment to ensure standardization of configuration files, running paths, and permissions |
| Test installation simplification | Parameter setting errors and running conflicts between different versions in the multiple versions of coexist environment | Create different versions of Tomcat containers, map different ports to the host, and make multiple versions of Tomcat to startup successfully | Simplify installation, test steps and isolate test environment to avoid coexist environment parameter settings errors and application startup conflict issues |
| Test function scalability | Duplicate works in setting up test environment when newly added functions and released versions | Set up new test environment based on base image by creating base docker image | Reduce unnecessary repetitive work to set up a test environment, save test time, labor cost, and improve test efficiency |
| Test data isolation | Dirty data and repeated reading of data when test data increase in the complex astronomy software environment | Deploy the DBs, applications, and user management subsystems in different containers | Easy to switch test scenarios when test data is isolated, test environment is clean, test container is independent |
| Test defects reproduction | Difficult to reproduce defect environment if undocumented assumptions, dependencies, and configuration items |
Quickly copy test environment and locate defects | The container shares the host operating system, which takes less resource costs, easy to reproduce the problem environment |
致谢: 感谢刘飞飞老师对项目测试过程中的技术建议。感谢SVOM项目组工程人员在测试和系统搭建过程中给予的建议和帮助。
| [1] | 符夏川, 吴潮, 黄茂海, 等. 瞬变源快速自动响应观测系统的研究与实现[J]. 天文研究与技术, 2017, 14(4): 452–460 |
| [2] | 姚坤, 戴伟, 杨秋萍, 等. 基于容器技术的天文应用软件自动部署方法[J]. 天文研究与技术, 2019, 16(3): 321–328 |
| [3] | 杨宝华, 戴王剑, 曹亚仑. Docker技术入门与实战[M]. 北京: 机械工业出版社. |
| [4] | OTT S. The Herschel Date Processing System-HIPE and pipelines-up and running since the start of the mission[C]//ASP Conference Series. 2010: 139-142. |
| [5] | MORRIS D, VOUTSINAS S, HAMBLY N C, et al. Use of Docker for deployment and testing of astronomy software[J]. Astronomy and Computing, 2017, 20: 105–119. |
| [6] | ZHANG M, HUANG M H, WU C. Prototype VOEvent network systems based on VTP and XMPP for the SVOM Chinese Science Center[C]//14th International Conference on Space Operations. 2016. |
| [7] | BOETTIGER C. An introduction to Docker for reproducible research[J]. ACM SIGOPS Operating Systems Review, 2015, 49(1): 71–79. |
| [8] | DAV C, AARON C, BRIAN H, et al. BCE: Berkeley's Common scientific compute Environment for research and education[C]//Proceedings of the 13th Python in Science Conference. 2014. |
| [9] | MATTHIAS K, KANE S P. Docker:up and running[M]. New York: O'Reilly Media, 2015: 27-28. |