基于Docker的动态工具：通常被忽视的最佳实践
|
两种方法都有优点和缺点。如果构建服务器中的所有节点完全相同，则需要使用特殊机制来处理同一工具的多个版本。此外，每个构建节点都可能很快变得过载。另一方面，这使得开发人员的工作更容易，因为他们可以为他们的构建选择节点。 为不同的工具使用不同的节点解决了构建工具的版本冲突，因为每个节点可以在同一工具上具有不同的版本。但是，在这种情况下，操作员需要密切跟踪哪个工具安装在哪个节点上，并确保在新版本出现时升级所有节点。 开发人员还需要了解后一种方法，因为他们必须确保将构建作业发送到正确的节点。例如，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构建工具视为一种改变开发人员和操作员操作的新方法，并希望看到它在公司和组织中获得进一步的认可。 译者介绍： 刘志红，17年IT从业经验。曾在NTT DATA，Oracle，中钞造币集团，中国电信云计算分公司从事云计算等关联IT研发工作。独立拥有软件著作权1件。目前就职于电子工业出版社。 【编辑推荐】
点赞 0 （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
