基于Docker的动态工具：通常被忽视的最佳实践

容器正在迅速成为大小企业的通用部署工具。Docker自然而然地被开发人员用于各种版本的轻松部署。

使用容器进行部署确实在过去(裸机和虚拟机(VM)世界)是一个受欢迎的过渡方式，因为小的占用空间(无论是在大小和启动时间上)促使组织比以前更方便地实施部署。缩短版本的部署时间是任何组织都想要达成的目标，因为这可以确保新功能在实施后立即被客户使用。

不幸的是，从VM到Docker映像的这种快速转换，掩盖了很少提到的容器的另一大优势，这就是在动态工具形式的持续集成(CI)过程中，使用容器时，对开发人员的操作有利之处。这是容器改变游戏规则的特征，可以说它比部署工件更重要。

关于如何在CI / CD(持续集成/持续部署)过程中使用容器，“采用Docker”几乎与生产部署同义，但这可能不是事实。在本文中，我们将解释为什么利用基于Docker的工具，是完整Docker采用过程中一个重要且独立的部分。

1.使用Docker动态构建节点

在传统的CI环境中，执行编译的所有计算机都拥有开发人员可能需要的工具的超集。 每个节点都提供了公司采用的预安装版本、测试和配置工具。

拥有同一工具的多个版本是一项巨大的挑战，对于不同团队使用多种技术的大型组织而言，维护编译节点所需的工作很快就会失控。

容器的出现(以Docker的形式)向我们展示了另一种更直观和简化的方法 --- 动态工具。使用动态Docker工具，编译节点从安装Docker开始。

基于动态Docker的工具对于使用习惯于传统静态构建工具的开发人员来说，就像是再生。

在构建期间，只使用Docker容器启动手头构建作业需要特定工具。 编译完成后，编译节点将恢复其原始状态(即完全清空工具)。

这种方法既简单，也强大，对开发人员和操作员都有优势，将在下一节中详细介绍。

2.静态编译工具的黑暗时代 - 开发者的观点

现在我们已经了解了如何仅为CI过程采用Docker，而不是完整的CD，我们需要解释基于Docker的工具的优势。最简单的方法是解释传统静态编译方法的缺点。

在静态工具平台中，编译节点长时间运行，只能加载部分的编译工具。这给开发人员带来了许多问题(和挫败感)：

必须首先通过操作请求升级新工具，从而导致升级周期非常缓慢。

开发人员必须根据构建节点上的可用内容配置自己的工作站。

使用新的框架和工具创建一个全新的项目需要付出很多努力，因为必须升级所有编译节点以适应它。

开发人员必须跟踪编译节点功能，并确保其编译作业实际发送到满足所有要求的节点。

在编译节点中使用同一工具的多个版本始终是一个巨大的挑战。在极端情况下，开发人员被迫更改其项目库，只是因为编译节点已升级/降级该版本。

采用基于云的体系结构使这个问题显得更为凸出，因为现在单个组织可以同时部署到多个平台，这些平台受外部控制。

开发人员对最终结果不满意，因为他们认为编译平台对他们有影响。在编译工具可用性方面，开发人员和操作员之间始终存在紧张关系。

3.动态Docker工具为开发人员带来的好处

使用动态Docker工具，开发人员和操作员之间的通信变得非常容易。编译节点只有一个硬性要求，那就是Docker本身。

一旦Docker安装在构建节点中，任何开发人员都可以使用该特定项目所需的特定工具启动Docker镜像。操作员不再是采用新框架和新库的障碍。

这种方法的动态特性来自于Docker容器是短暂的。只有需要时，它们才存在。与在构建节点中预安装工具的传统做法相比，差异巨大。

开发人员能够愉悦的使用(并且效率更高)，因为：

• 他们可以选择使用任何版本的框架。

• 创建使用全新架构的新项目非常容易。

• 所有构建节点都是相同的，因此，他们可以将任务发送到任何节点，如果操作者事先知道工具版本不匹配，将永远不会执行此操作。

• 使用同一工具的多个版本非常简单(即使在同一个项目中)。

• 他们永远不会被迫升级库版本。遗留项目仍然可以使用与greenfield项目完全不同的工具版本。

• 构建节点是“自我清理”(self-cleaning)的，因此，他们永远不必担心版本工具的冲突问题。

• 与操作员的沟通变得非常简单。要讨论的唯一主题是构建节点中Docker守护程序的版本。

基于动态Docker的工具对于习惯于传统静态构建工具方法约束的开发人员来说就像是再生。

现在让我们看看操作员如何从CI中的动态工具中获益。

4.静态构建工具的黑暗时代 – 操作员的观点

传统上，操作员(即系统管理员)需要花费大量精力来管理静态构建节点。他们的责任是保留一大堆工具，以确保开发人员可以使用这些工具。

这种方法的复杂性很快会引发矛盾，特别是在使用不同工具和技术的组织中。

为了解决多种构建工具和版本的复杂性，操作员通常遵循以下两种方法之一：

• 所有构建节点都完全相同，每个节点都包含开发人员使用的项目所需的构建工具。

• 不同的构建节点具有不同的构建工具集合。节点被分配了显示其功能的特殊“标签”。

两种方法都有优点和缺点。如果构建服务器中的所有节点完全相同，则需要使用特殊机制来处理同一工具的多个版本。此外，每个构建节点都可能很快变得过载。另一方面，这使得开发人员的工作更容易，因为他们可以为他们的构建选择节点。

为不同的工具使用不同的节点解决了构建工具的版本冲突，因为每个节点可以在同一工具上具有不同的版本。但是，在这种情况下，操作员需要密切跟踪哪个工具安装在哪个节点上，并确保在新版本出现时升级所有节点。

开发人员还需要了解后一种方法，因为他们必须确保将构建作业发送到正确的节点。例如，Python开发人员需要指定作业需要具有“python”标签的节点，而JavaScript开发人员需要具有“javascript / npm”标签的节点，依此类推。

总之，静态构建节点对于操作员来说需要耗费巨大的时间成本。实际上，有些公司在构建节点维护上需要全职投入。

5.动态Docker工具对操作员的好处

使用动态Docker工具，操作变得非常容易。

所有节点都易于设置和维护，特别是如果现有的Kubernetes集群用于构建，这很快就会成为一种常见做法。如前所述，每个构建节点只需要安装Docker，而不需要其他任何东西。其他节点也完全相同(根据定义)。

操作员通过这种直截了当的方法，维护已批准的工具列表，但不需要事先安装它们;

• 不关心开发人员使用的工具的确切版本;

• 对工具升级不再负责(因为开发人员可以自己完成);

• 不再面对同一工具的多个版本的问题;

• 可以在同质级机器上工作

• 不必管理节点的标签，并跟踪哪个节点具有哪个工具。

与开发人员的沟通非常简单，因为唯一要讨论的是节点的Docker版本。

图中未显示的另一个优点来自Docker容器的速度和占用空间。使用传统的静态构建方法，即使没有开发人员需要作业的构建内容，操作员也必须始终准备好构建节点，并将其用于作业。

使用基于Docker的工具，开发人员可以在几秒钟内按需启动工具。当没有开发人员使用节点时，可以轻松地将节点重新分配给使用完全不同技术的另一个开发团队。

总之，基于Docker的工具可以释放操作员的手，并减轻他们的日常负担。

6.两种完全正交的Docker方法

本文的重点是介绍使用Docker进行动态构建工具，这是今天在实际生产应用中的最佳实践，而无需实际使用Docker本身进行生产部署。

Docker部署工件或构建工具方法是完全独立的，您可以根据组织情况，轻松有效地混合和匹配这些工具。

基本上，公司内有4个可能的容器采用阶段：

• 基于VM的工具，在VM上部署(旧方法)。

• 基于VM的工具，在容器上部署(大多数人都熟悉这种方法)。

• 基于Docker的工具，可在VM上部署(从容器中获益的好方法)。

• 基于Docker的工具，在容器上部署(完全Docker采用)。

大多数与Docker相关的新闻都侧重于基于Docker的部署，而不是基于Docker的构建工具，这使得许多组织无视后者的好处。

从上图中可以清楚地看出，基于Docker的工具可以单独使用(而部署仍然可以针对VM /裸机)。许多组织试图通过盲目地尝试在生产部署中使用Docker，而不了解这不是唯一可能的方法来赶上容器潮流。

事实上，基于Docker的工具可以为CI / CD流程带来更多好处，因为它解决了开发人员面临的许多常见生产力问题，正如我们在前面部分中看到的那样。

按需创建构建环境而不是等待冗长的供应批准的能力是开发人员和操作人员需要经常面对的痛点之一。

在Codefresh，我们已经为CI / CD管道实现了这种方法。每个步骤都是自己的容器。想运行Node?有一个Docker镜像。想要运行Maven?有一个Docker镜像。想要进行 Canary rollout吗?有一个图像。你需要吗?你需要Terraform吗?基本上，作为Docker镜像提供的所有内容都可以用作构建步骤。

您仍然可以使用Codefresh部署到传统目标(即VM和裸机)，但构建平台的核心是利用工具来使用容器和Docker镜像。

开发人员可以创建管道，其中每个构建步骤都在包含所需工具的Docker镜像的上下文中运行。版本冲突、工具升级和在不同版本上构建节点等问题都已成为过去。

我们将动态Docker构建工具视为一种改变开发人员和操作员操作的新方法，并希望看到它在公司和组织中获得进一步的认可。