英语原文共 9 页，剩余内容已隐藏，支付完成后下载完整资料

在R环境下关于Docker可重现研究的介绍

卡尔 鲍特格

股票评估研究中心

摘要

由于计算工作在科学研究的许多方面变得越来越不可或缺，对于计算机系统开发人员以及这个领域的科学家来说，计算再现性已成为日益重要的问题。虽然计算机再现性看上去比物理重复实验更加直接，计算机环境的复杂性和快速变化的本质使得能够复制和扩展这些工作成为一个严峻挑战。在这篇论文里，我探索了常见的原因是，一个研究项目不能被下任代码研发者成功的执行或者扩展。我回顾了当前处理这些的方法，包括虚拟器和作业流系统，以及他们的局限。然后我结合系统研究的几个领域研究了当下流行的Docker技术，例如重建一个虚拟系统，跨越平台的可移植能力，模块化再用元素，版本控制，以及DevOps的哲学，来讲述这些挑战。我会重点在R数据分析环境下阐述Docker使用的几个例子。

分类和主题描述：

[信息系统应用]：多方面

一般术语：

系统，可重现研究

介绍

可重用研究受到了科技社区以及广大公众与日俱增的关注。所有科学过程的步骤，从数据收集、处理到分析、可视化以及结论都越加依靠于计算和算法。计算再现性已经受到了特别的关注。虽然原则上该算法的依赖使得这种研究更容易再生计算机代码，并且比物理实践方法更加便携和精准地改变和执行，但是这也导致了一个更加大并且复杂的黑盒子，这个是在文献中描绘的实际上做的事情。如果可能的话，像复制结果，扩展方法，在其他情况下测试结论或者甚至不通过原研发者来安装软件等重要的科学方法会变得非常费时。

系统研究和再现性

系统研究关注计算再现性问题以及便利这些东西的技术已经很长时间了。Docker是一个新兴的技术同时是非常流行的开源工具，它在用户友好的基础上组合了许多技术实现，包括：（1）基于操作系统层面的虚拟化执行Linux容器（LXC），（2）跨平台的便携的容器部署，（3）组件重用，（4）共享，（5）归档，（6）容器镜像的版本控制。与此同时，Docker市场的成功主要集中在部署Web应用的商业需求以及在完全虚拟化的轻量级的潜力上，这些特征在科学再现领域方面的研究具有潜在的重要意义。在这篇论文里，我试图在遍布各种不同领域的科学情况下，找寻Docker扮演的意义。但是这里的研发者大部分对让计算变得更加具有可重生产性，可扩展，对其他的研究人员更具有移植性的技术不那么关心。在这样做时，我突出了Docker平台那些应该对计算机系统研究以及领域科学家们有兴趣的元素。

一个文化问题

一个一开始就值得观察的事情是，计算再现性最主要的障碍是很多领域的科学家并没有将这门技术方法进行探讨。尽管有大量的相反证据表明，许多的研发者以及杂志继续假设概要描述或伪代码可以提供一份足够说明，关于数据收集，加工，模拟，可视化和分析采用的计算方法。直到这样的代码是在第一时间可用，一个人甚至不能遇到这样的问题，它的方法是可以拿来讨论解决的。其结果是，很少领域的研究人员可以充分意识到关于涉及有效再利用出版代码的挑战。

毫无疑问，缺乏需求或奖励对劝阻分享起着至关重要的作用。然而，由于缺少熟悉，直观，以及广泛运用的工具来定位计算再现性的挑战，因此，很容易低估这个最重要的障碍。调查和案例研究发现缺乏时间超过先天反对共享，不鼓励提供代码的研究人员。

四大技术难题

通过限制我们已经可以利用的代码的研究，我将回避再现性的文化挑战情况。所以我能集中精神在技术开发上。实际上，这些为了改善工具和技术，而不是仅仅行为的挑战能持续不断为改善再现性做出贡献。集中已经在常规科学出版的有用代码的研究发现普遍的问题，构建持续不断的障碍来减少原生结果或者构建代码。这也是我尝试在下面总结出来的。

1依赖Hell

来自亚利桑那大学最新的一份研究表明，低于50％的软件甚至可成功地建立或安装，并且类似的结果也可以从其他的研发者不断努力的研究证明中看到。用错误的代码构建和安装软件被证实是一种重新创建计算环境的能力。

在数值计算的差异，如出现在浮点运算或者甚至含糊标准化编程语言(“order-of-evaluation” 问题) ，可以在不同的结果甚至在同一个计算平台负责。这些问题使得难以限制在更高环境下的代码的真实独立性，如给定的脚本语言，独立于底层操作系统，甚至硬件本身。

2不精确的文档

有关如何安装和发表研究相关的运行代码的文档是另一种常见的复制障碍。通过拉普的研究发现，损害研究员的安装和建立必要的软件的能力，如文档中甚至小孔被认为是主要障碍，尤其是对于新人而言。其中，新人也许会在语言上会成为专家，但是在涉及到包管理以及语言工具上，则显得陌生。这些问题同样被讨论过。不精确的文档远远超出了软件环境本身的问题：不完整的参数文件涉及到，借助流行的软件STRUCTURE统计到小于30%的分析可以再次在学习中生产。

3代码rot

软件依赖关系不是静态的元素，但可以定期更新接收修正的错误，增加新功能或者分离旧功能（甚至分离自己本身）。任何这些变化可潜在改变由代码生成的结果。由于这些变化可能的确有效解决错误或底层问题代码，它通常会足以证明可以通过使用原始版本时的结果，这个问题有时候以“代码rot”被我们熟知。研究人员想知道结果是否稳健的变化。在[16]的情况下研究提供了这些问题的例子。

1. 在现有解决方案的采用和重用的障碍

例如工作流程软件，虚拟器，持续集成（CI）服务，和软件开发和最佳实践这样的技术方法将解决许多经常挫败重复性的问题。然而，研发者面临着非常显著的障碍来学习这些工具和方法，这些不是典型课程的一部分，缺乏激励机制与所需的工作量相称。

虽然存在各种方案来解决这些挑战，还是在低级别没有运行来提供一个通用的方法。关于这种情况Clark给出一个非常棒的描述：

在科学计算环境是通过Makefile文件与Unix-Y黑客常用的管理，或者用类似Matlab的单片软件。最近，集中式包管理提供适合一起策划的工具。但是，随着越来越多的基本功能在各种不同的系统和语言中得到构建。协调多个工具的难度不断提高。无论我们生产的研究成果或Web服务，它正变得越来越重要来建立新的语言，库，数据库等等。

有两种主要的方法来协调多个工具的这个问题：工作流和虚拟机。

目前的做法

两个主导范式都出现了迄今为止解决的这些问题：工作流和虚拟机。工作流软件提供了非常优雅的技术解决方案，以多样通讯软件工具之间的挑战，图形驱动的界面捕获出处，从版本依赖于数据访问处理的问题。工作流程解决方案往往是由域的科学家和计算机科学家之间的资金雄厚的合作建成，并且通过社区非常成功。尽管如此，大多数的工作流系统还在和低层次的整体向抗争。

Dudley和Butte给出了一些原因，全面的工作流系统还没有比较成功的：

（i）努力不是由目前的学术研究和资金环境奖励

（ii）商业软件供应商倾向于通过专有格式和接口来保护自己的市场;

（iii）调查自然倾向于要“拥有”和控制他们的研究工具;

（iv）即使是最广义的软件，也不能满足一个领域里的每一个研发者。

（v）最后需要获得并快速发布结果尽可能排除了往往较慢基于标准的发展道路。

总之，工作流软件需要一个新的方法来计算研究。相反，虚拟机提供一个直接的方法。由于计算机操作系统（OS）已经提供了软件层负责协调计算机上运行的所有不同的元素，虚拟机捕获操作系统和在上面运行的所有程序。为了实现这，Dudley，Butte和Howe建议将在云中使用运行的虚拟机映像，就像亚马逊EC2系统一样，这是一个基于某种虚拟实现的系统。

使用vm支持再现性的批评者强调黑盒的方法太多了,因此不适合再现性。虽然方法回避了需要安装或甚至文档的依赖关系。这也使得其他研究人员理解,更难评估,或改变这些依赖项。此外,其他研究不能轻松地构建虚拟机在一个一致的和可扩展的方式。如果每个研究提供了它自己的虚拟机,任何管道结合多项研究的工具会很快变得不切实际或不可能实现。

一个“DevOps”的方法

突出的这个问题并不是唯一的学术软件，但影响软件开发。而学术研究文献经常关注工作流软件专注于特定领域的发展,或者使用虚拟机。软件开发社区最近强调哲学(而不是一个特定的工具),被称为开发和系统操作,或者更频繁的只是“DevOps。

特点是脚本的方法,通常从操作系统(OS)运行，而不是记录所需的依赖项的描述软件运行。克拉克描述了在学术研究背景DevOps的方法以及其相关性可重用的研究和使用它的例子。他们识别了困难，而这些我们已经在很多有效的文件里讨论过了。

在复杂的软件环境下的文档卡在两个对立的要求。对新手用户,简化文档必须解释与不同的操作系统等因素相关的细节。另外,为了节省时间编写和更新文档,开发人员喜欢抽象等细节。

作者对比这DevOps方法,依赖文档脚本:

DevOps的方法“记录”应用程序可能包含提供简要的描述各种安装路径,以及自动设置的脚本或“食谱。

这个地址的需求简单优雅使用(一个执行一个脚本,而不是手动管理环境设置)和全面性的实现。克拉克小心翼翼地指出,作为一个哲学这并不是是一个技术转移:

主要转变所需的不是一个新的工具,因为大多数开发人员已经拥有他们所需要的基本工具。相反,所需的转变是一种哲学。

然而,越来越多的工具套件设计明确。为此迅速取代了使用通用工具(如makefile,bash脚本)成为DevOps哲学的代名词。克拉克评论这些DevOps的工具,不同的角色,他们的应用程序在做可重用的研究。

我论文的其余部分将侧重于论述这些工具套件中近期流行且快速发展的内容，也就是Docker，还有它在可重现（reproducible）研究方面起到的作用。Docker在可重现性方面提供了一些有前途的特征，并且已经超越了其他通用工具所突出的地方。然而，我研究这项技术的目的却不在于推广一种特定的解决方法，而是在具体的实例中将有关技术解决方法的讨论重心固定在可重现性挑战上。

DOCKER

Docker是建立在操作系统研究上许多早为熟悉的技术上的开源项目，比如：LXC容器，操作系统虚拟化技术，散列或类似于git的版本控制和差异化系统等等。

通过我上文提及的有关可重现性研究的四个挑战内容，我从Docker里引入了最相关的概念。

1. Docker镜像：解决“依赖地狱”

基于Docker的解决方案的工作方式和虚拟机镜像处理依赖问题时的工作原理很相似，它通过提供其他的研究人员二进制镜像，在这样的镜像里所有的软件都已经被安装、配置和测试过。（一个虚拟机镜像也能够包含研究所需的所有数据文件，并有可能简化数据的发布。）

区分Docker镜像和其他虚拟机镜像的关键在于，Docker镜像能够与主机共享Linux内核。对于最终用户来说，最主要的后续影响是任何Docker镜像必须依赖于Linux系统，然后安装兼容Linux平台的软件，比方说R，Python，Matlab，以及其他大多数科学编程软件。

共享Linux内核后，Docker会变得更加轻便，并且当运行时会比其他完整的虚拟机性能更高。一台典型的桌面计算机并不能同时运行多个虚拟机，但是却能毫无压力地运行100个Docker容器。（容器仅仅是镜像运行的实例）。这样的特征使得Docker对于企业而言变得更加具有吸引力，所以这也能解释Docker流行起来的原因。对于我们所追求的目标而言，这完全是一种额外的福利，但是对于可重现研究而言，它的主要价值在其他方面。

1. Dockerfile：解决不准确的文档问题。

尽管Docker的镜像能够以交互式方式创建，但几乎没有留下可见的记录，如包含什么软件被安装了，是怎么被安装了等信息。Dockerfile提供了一种简单的脚本（和Makefile的原理类似），脚本里能够定义如何创建Docker镜像，并与我之前提及的DevOps方式保持一致。

Docker有一种比其他配置工具（如：Chef，Puppet，Ansible）或持续集成平台（如：Travis CI，Shippable CI）更简单的语法，用户仅仅需要一些基本命令与shell脚本和一个Linux发行版的软件环境（如：Debian-based apt-get），他们就能够开始编写Dockerfile。

这样的方式拥有许多优点：

bull;当机器镜像非常大的时候（许多千兆字节），一个Dockerfile仅仅是一个简单的普通文本文档并且可以被轻松保存和分享。

bull;小体积的文本文档是极其适合与一个版本管理系统搭配使用的，比方说subversion或是git，它能够追踪到所有针对Dockerfile做出的改动。

bull;Dockerfile提供了人类可读的关于必要软件依赖和环境变量等等其他需要用来执行代码需求的组件的概要信息。在这样的脚本里极少存在漏洞或是不精确的现象，这些毛病会频繁导致手动解决依赖的文本化过程的困难。这样的方法也避免了在一个项目的结尾中遇到的无聊地记载依赖所带来的负担，因为在编写Dockerfile的时候该类内容就已经记载好了。

bull;不像Makefile或是其他脚本，Dockerfile包含所有软件降低到操作系统级别的依赖，并且是被Docker build工具所生成的，使得它在不同机器上的生成镜像很难出错。但这样的现象并不是说Dockerfile的生成镜像是每一个比特都是相同的。特别地，如果没在包管理器里面配置了软件的特定版本，后面构建的镜像可能会安装某个软件较新的版本。我将在下一部分里再提到这个问题。

bull;为了安装软件运行环境，在指令之后添加必要的检查和测试脚本是有必要的，这些脚本能够核实软件是不是

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[30227]，资料为PDF文档或Word文档，PDF文档可免费转换为Word