10 月 23 - 25 日,QCon 上海站即将召开,现在购票,享9折优惠 了解详情
写点什么

Baruch Sadogursky 谈 Docker 容器生命周期管理面临的挑战

  • 2016-07-03
  • 本文字数:1745 字

    阅读完需:约 6 分钟

JFrog 开发大使 Baruch Sadogursky 在多个会议上做过演讲,包括去年 5 月举行的 DevOps Days Kiel
内容涉及控制和跟踪 Docker 镜像从开发环境到生产环境的流程所面临的挑战,以及 JFrog 提出的解决方案。

为了更好地了解 Docker 容器生命周期管理所面临的部分挑战,InfoQ 采访了 Sadogursky。

InfoQ:如今,您看到有许多工程团队使用 Docker 镜像作为构件,并通过部署管道推送它们吗?

Baruch Sadogursky: 我们看到,人们如今对 Docker 非常感兴趣。人们试图像使用先前的技术栈那样,借助 Docker 实现推送管道,但那并不总是有效。有些 Docker 的架构决策让做正确的事变得困难,而部分 Docker 的最大优势却让人容易做错。

InfoQ:那些使用 Docker 的人,他们是真正地将镜像部署到生产环境,还是只是使用它们作为复制实际的 VM 生产实例的一种快速而简单的方式?

Sadogursky: 真正在生产环境中使用 Docker 的团队,比“摆弄”Docker、做概念验证或者在开发环境中使用 Docker 的团队要少得多。我们认为,其中的一个原因是,增加一个更不透明的抽象层会增加生产级工件不能有的不确定性。

InfoQ:您能简要地说明下,为什么您主张使用 Docker 镜像作为工件而不是 Dockerfiles(有依赖管理)+ 应用程序二进制文件(比如 WAR 文件)?

Sadogursky:这篇博文对整个理论进行了解释,但简单来说——如果你从 Dockerfiles 多次构建(每个环境的)镜像,那么并没有什么方法可以确保你最终获得的工件相同。那是由 Dockerfile 的性质决定的——它的大多数命令都会引入不同的依赖项,而且经常会使用一个不稳定的版本。

InfoQ:在您看来,Dockerfile 应该包含什么类型的信息,而又不应该包含什么信息?

Sadogursky: 设法锁定所有依赖项的版本,越多越好。对于有些依赖项,这可以做到,例如使用一个版本号运行 apt-get,但对于其他依赖项,这无法做到(例如基于 Ubuntu 的镜像会累积相同版本下的安全补丁),但要试一下。

InfoQ:通过部署管道推送 Docker 镜像面临什么挑战?

Sadogursky: 当前,大多数 Docker 注册中心使用的推送模式是获取镜像、重打标签并添加到新的注册中心(或库),用于管道的下一个步骤,并把它重新放回。相当愚蠢,不是吗?

InfoQ:您如何看待(Docker 及其竞争者的)Docker 注册中心的现状?它们之间主要有什么不同?

Sadogursky: 这是一个相当宽泛的问题。有一大堆指标可以用于比较注册中心。其中一个最有趣的是,管道的其他部分是否需要额外的工具。Docker 是一种容器技术,容器会包含某些东西。如果你可以在和容器镜像一样的工件库里管理这些“东西”,你就可以在创建镜像的构建和创建容器所含内容的构建之间建立可追溯的元数据。

InfoQ:如果你需要确保源代码、应用程序二进制版本和 Docker 镜像版本之间的可追溯性,那么如何才能避免依赖管理地狱?

Sadogursky:“一次构建,推送不可变二进制版本”实际上同样解决了这个问题。你运行一次依赖管理系统,这样,一旦二进制版本创建了出来,到源代码的追溯就是不变的,一直到生产环境都是如此。

InfoQ:从安全的角度讲,在确保推送到生产环境的 Docker 镜像不易受到攻击方面,您有什么建议吗?

Sadogursky: 这没有什么特别之处。你应该使用安全扫描器。务必要确保,使用的工具既能扫描 Docker 容器,又能扫描镜像内容及镜像内的工件内容,等等。它们都可以在运行时暴露出容器的安全漏洞。

InfoQ:基于 Docker 镜像的推送管道可以帮助团队实现不可变基础设施吗?为了支持那种“构建 & 清除(build & forget)”的基础设施建设方法,还需要考虑什么其他的因素吗?

Sadogursky: 基于 Docker 镜像的方法就是指不可变基础设施。尽快创建不可变镜像的思想恰恰就是不可变基础设施的方法论。一旦你有了一个很好的持续集成(CI)管道,每次源代码修改就会触发一系列的 CI 构建和推送,最终进入一组新的 Docker 容器——那就是最好的不可变基础设施。

InfoQ:像 Chef 或 Puppet 这样的配置管理工具如何纳入那种场景?

Sadogursky: 那是个价值 10 亿美元的问题。我不知道有谁现在能够回答这个问题。看可变基础设施软件在不可变基础设施领域如何自我改造是非常意思的。也许 Chef Habitat 是向那个方向迈出的第一步?等着瞧吧。

查看英文原文 Q&A with Baruch Sadogursky on the Challenges of Managing Docker Containers Lifecycle

2016-07-03 19:001522
用户头像

发布了 1008 篇内容, 共 431.2 次阅读, 收获喜欢 346 次。

关注

评论

发布
暂无评论
发现更多内容

使用通义灵码,参与开源项目全程纪实

阿里巴巴云原生

阿里云 云原生 通义灵码

如何通过API实现淘宝/天猫商品的精准搜索

技术冰糖葫芦

API Gateway API 接口 API 测试 pinduoduo API

2024 年 8 月公链行业研报:Layer 1、比特币 Layer 2 和以太坊 Layer 2 趋势分析

Footprint Analytics

店铺信息全掌握:拍立淘API中的卖家与店铺数据

技术冰糖葫芦

API Gateway api 货币化 API 接口 API 测试 pinduoduo API

“AI+Security”系列第3期(三):大模型在网络安全检测及运营场景的探索及应用

云起无垠

用二维码收集信息时,在后台可以查看、统计哪些数据?

草料二维码

低代码 无代码 无代码平台 低代码起源 草料二维码

从0到1搭建权限管理系统系列三 .net8 JWT创建Token并使用

不在线第一只蜗牛

Java .net

云手机运营电商对比真机有什么优势?

Ogcloud

云手机 海外云手机 电商云手机 云手机群控 海外社媒营销

面试官:项目中如何实现分布式锁?

王磊

ByteHouse新一代云数仓关键技术及最佳实践

字节跳动数据平台

数据库 大数据 云原生 Clickhouse 数仓

使用通义灵码,参与开源项目全程纪实

阿里云云效

阿里云 云原生 通义灵码

快手B端商业化技术探索:基于LLM构建智能RAG与Agent平台

快手技术

大模型 LLM rag

Web3 游戏周报(9.15-9.21)

Footprint Analytics

链游

阿里云函数计算 x NVIDIA 加速企业 AI 应用落地

阿里巴巴云原生

阿里云 云原生 函数计算

海外云服务器与传统服务器的对比与选择

Ogcloud

服务器 云主机 云服务器 云主机厂商 海外云服务器

Footprint Analytics: 我们为何打造 Growthly 这款产品

Footprint Analytics

区块链+

携手SelectDB,观测云实现性能与成本的双重飞跃

观测云

监控

Baruch Sadogursky谈Docker容器生命周期管理面临的挑战_DevOps & 平台工程_Manuel Pais_InfoQ精选文章