如何使用Docker数据卷进行大规模构建
Docker容器已成为测试，开发和持续集成工作流程中不可或缺的一部分。使用容器的好处之一是它们的尺寸相对较小且生命周期短。团队可以生成清晰，可重现的构建，可以快速部署。此外，没有剩余的环境数据或自定义工具来破坏构建。
有一个问题，也是Docker的一个好处，就是每次运行后所有内容都会被摒弃。
如果您正在管理许多大型资产（例如许多Helix Core客户），您需要一种方法来部署容器而不会减慢速度。复制大量可能非常大的文件（如图形，电影和声音）数千次会严重影响性能。
持久的外部存储（如Docker卷）可以显着减少将大量代码和非代码资产引入容器所需的时间。这可以加速您的容器工作流程并提高团队生产力。
在本博客中，我们将回顾使用Helix Core的不同方法，以允许容器访问未更改的代码和其他大型二进制资产。
没有Docker容器的构建
在Docker之前，像Jenkins这样的构建代理将使用Helix Core工作区同步来自Helix Core的源代码。Helix Core跟踪同步到构建代理程序工作区的文件修订。
使用最新文件版本更新构建代理程序的工作空间时，Helix Core工作空间仅发送已更改的文件。Helix Core使用数据表（db.have）来跟踪同步到工作空间的修订。您可以使用p4 have命令查看此信息。
在没有容器的情况下构建和同步是快速有效的。但是这种方法缺乏容器提供的所有优点，例如清洁和管理的环境。
那么如何才能有效地将文件同步到临时构建环境中呢？
公司转而使用虚拟机（或虚拟机）来寻求解决方案。虚拟机提供了一种方法来拍摄机器状态的快照 – 一种版本控制。但是，这仍然缺乏控制机器环境所需的更正式的管理。其他缺点包括：
虚拟机具有很多复杂性，尤其是与容器相比时。
需要安装和配置VM。
虚拟机消耗更多的IT资源，并且可能比容器更昂贵。
在VM上配置整个环境时，构建可能会中断，只是为了检查最新的代码更改。这会导致您的开发和后续管道出现重大延迟。这就是为什么我们看到团队越来越多地采用容器来开发，测试和部署其持续集成/持续交付（CI / CD）管道。
Puppet，Chef和Vagrant都提供了管理环境的方法，但Docker是一种有效控制整个机器环境的方法。
使用Docker进行持续集成
Docker容器为开发人员和DevOps团队提供了更大的灵活性。它们是VM的轻量级替代品。它们可以在几秒钟内创建，并在达到目的时被杀死。
事实证明，Docker可为团队的持续集成工作流程提供性能改进：
构建Web应用程序
采用微服务架构
处理不使用大量代码构建或部署的项目
使用容器，每次都可以获得干净的同步，并且早期版本中没有剩余的环境设置。不需要安装不同的工具链。
那么你需要Docker的Helix核心工作区吗？
如果容器生命周期短，那么Helix Core有几种选择。每次容器启动时，您应该使用新的Helix Core工作区吗？如果每次运行同步源，您是否还需要Helix Core工作区？
使用Helix Core工作区具有优势。它允许您：
控制视图
映射源文件
修订版
应用过滤器
更重要的问题：在与db.have列表同步时，是否应该跟踪文件修订？让我们来看看你的选择。
配置新的Helix核心工作区
为每个容器设置新工作区都有好处。运行构建时，您知道工作区中没有任何剩余内容，并且可以快速启动。
但是每次创建容器时，都需要删除旧工作区。如果不删除它，则可能会阻塞Helix Core db.have列表。更好的是，由于工作区仅使用一次，因此请使用p4 sync -p命令跳过记录有列表。您可以使用Jenkins插件选项’SyncOnly’并取消选中’Populate Have List’选项以避免同步“have list”。
checkout perforce( credential: ‘myID’, populate: syncOnly(have: false), workspace: manualSpec(cleanup: true, view: ‘//depot/project/… //${P4_CLIENT}/…’) ))
如果你观察的比较仔细，你可能已经在Jenkins p4插件中发现了一个新的“清理”选项。这不会在Pipeline语法代码段生成器中公开。将此选项设置为true将在初始同步后删除Helix Core工作区。
不过要小心。确保没有后续管道步骤需要Helix Core工作区非常重要。或者，有一个’p4cleanup’管道步骤（’cleanup’的别名），如果设置为true，将删除Helix Core工作区和所有本地文件。
cleanup(true)
重用Helix核心工作区
如果您选择重复使用Helix Core工作区，则可以跳过清理和删除步骤。您需要忽略“have list”，因为先前的同步将不再具有相关信息。您可以使用“Force Sync”填充选项来实现此目的。但同样，由于未使用“have list”信息，最好取消选中“Populate Have List”选项。
注意：您无法设置’Force Syne’并取消设置’Populate Have List’，因为这是无效状态。您不能忽略您从未创建的列表。
使用Docker卷构建1 TB项目
许多Helix Core用户不仅处理小型源代码库。它们还具有包含数十万或数百万个文件的大型代码库。其中一些代码库包括大型资产文件，如二进制文件，可能达到超过1 TB的项目代码。因此，仅使用容器丢弃工作空间仅重新同步所有文件不是一种选择。
那么Docker如何扩展以支持大型文件和代码库呢？
答案是这样的：Docker使用的一些持久数据不会一直改变。实现Docker卷允许您在容器外部编译一些资产，然后将它们拉入构建中。
我们没有扩展容器。相反，我们在Jenkins构建机器之外放置了一些代码以及非代码二进制资产（图形等）。这节省了编译和复制大文件的时间。这些大型资产可以在外部存储上随时使用，并且可以随时使用。
如何在Helix Core中创建Docker卷
请按照以下步骤创建持久的外部存储。
1.将构建区域安装在容器外部，以便它可以通过构建持久化。
2.如果该区域是共享的或存在被污染风险，请使用“AutoClean”（Perforce协调/清洁）。
3.或者，如果可以保证Docker卷始终由相同的Jenkins作业，代理和Helix Core工作区使用，请使用“SyncOnly”。
处理并发访问
防止并发访问Docker挂载的共享工作空间至关重要。从同一组外部文件构建多个Docker实例是一个坏主意 – 除非您确定生成的资产或中间文件对另一个容器不可见。
虽然Helix Core工作区重用具有其优势，但同一工作空间的并发访问将导致问题。如果两个或更多执行者试图更新相同的“have list”，则尤其如此。
将功能与Helix Core持续集成
Docker是一个非常强大的工具，可以加速持续集成并为开发人员提供即时反馈。它可以更好地保证您在生产中运行的内容。通过使用外部存储（如Docker卷来保存一些代码和二进制文件），即使对于大型项目，您也可以实现这些优势。