加入收藏 | 设为首页 | 会员中心 | 我要投稿 核心网 (https://www.hxwgxz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 移动互联 > 正文

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

发布时间:2018-12-20 11:59:45 所属栏目:移动互联 来源:刘志红 翻译
导读:容器正在迅速成为大小企业的通用部署工具。Docker自然而然地被开发人员用于各种版本的轻松部署。 使用容器进行部署确实在过去(裸机和虚拟机(VM)世界)是一个受欢迎的过渡方式,因为小的占用空间(无论是在大小和启动时间上)促使组织比以前更方便地实施部署。
副标题[/!--empirenews.page--]

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

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

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

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

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

1.使用Docker动态构建节点

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(编辑:核心网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读