是否有任何理由将 Puppet 与 Docker 一起使用?

Hau*_*eth 16 puppet docker

前段时间我尝试过 DevOps 的 Ops 部分,它很有趣,但我没有时间和理由在任何项目中尝试它。但是上周我开始了新工作,老板问我是否可以配置服务器来为公司项目制作诸如暂存环境之类的东西。除此之外,我开始考虑将项目迁移到更多的 DevOps 而不仅仅是开发。

我已经推出了 Docker,这对我来说非常棒而且非常简单。但是前段时间我在尝试 Puppet,所以我想到了一个问题:“有什么理由将 Puppet 与 Docker 一起使用?”。Docker 似乎做了 Puppet 会做的所有事情,但方式更简单。

PS 前段时间在 Hacker News 上有Consul,它是很好的配置和服务发现,所以即使配置也可以解决(我也在考虑实现这个)。

spu*_*der 18

Puppet 和 docker 可以做很多相同的事情,但是他们以不同的方式处理它们。

Puppet 管理文件 + 包 + 服务。(称为三连胜)。Docker 将二进制文件和配置文件封装在容器内。

在撰写本文时,docker 仍然不稳定,不应在生产中使用。在 1.0 版发布之前,许多 API 可能会更改。

即使 docker 变得稳定,将每个进程和配置文件转换为 docker 容器也将是一项艰巨的任务。

另一方面,Puppet 是一个稳定的产品,并带有完整的工具生态系统(heira、mcollective、facter、razor)。这些工具可以快速实施,而不必担心事情会破裂。

我强烈建议以下资源。

如何使用 puppet 管理应用程序堆栈的视频
https://www.youtube.com/watch?v=KSo_mcJxFIA

关于 docker 和 puppet 如何协同工作的播客
http://devopscafe.org/show/2014/1/23/devops-cafe-episode-46.html

关于如何与 docker 集成的 puppet 博客文章
http://puppetlabs.com/blog/building-puppet-based-applications-inside-docker

另一篇关于 puppet 和 docker 共存的博客文章
http://puppetlabs.com/blog/can-containers-and-configuration-management-co-exist

用于与 docker 交互的 puppet 模块
http://docs.docker.io/use/puppet/

对 devops 术语的小幅修正。Devops 更像是一种开发人员和运营商合作的软件开发方法,而不是任何特定工具。

更新

目前我的公司同时使用 puppet 和 docker。这是在 puppet conf 2014 上给出的关于为什么要使用 puppet 与 docker 的精彩演示。由 James Turnbull 提供,他是 puppetlabs 的前雇主,也是 docker 一书的作者。

https://puppetlabs.com/presentations/using-docker-puppet-james-turnbull-kickstarter

也是 sysadmincasts.com 提供的关于 docker 的一个很好的简短视频教程

https://sysadmincasts.com/episodes/31-introduction-to-docker

Docker 优点:

  • 可以快速启动实例
  • 比木偶更容易学习
  • 轻松做到 0 停机时间

Docker 缺点:

  • 容器在使用 devicemapper 后端时有 10GB 的限制
  • 小的配置更改需要很长时间才能重建容器
  • 使用像 hub.docker.com、quay.io 这样的 docker 注册表需要花钱(自托管的 docker 注册表非常有问题,并且没有 gui)
  • 没有合适的初始化系统。一些应用程序不好玩。
  • 没有对网络的细粒度控制
  • 需要子外壳的应用程序(看着你的 RVM + ruby​​)很难正常工作
  • 无法管理 windows 主机,没有 SLES 或其他不太流行的操作系统
  • 目前 docker 编排还很年轻。
  • 当前无法在构建时设置您的 /etc/resolv.conf
  • 我们必须挂载 /etc/localtime 和 /dev/urandom 以映射到主机 localtime 和 urandom 目录的各种错误。
  • 性能没有那么快(尽管都声称 docker 应该是裸机速度的 99%,但有时比其他机器慢 30%)。
  • 小型容器仍然有数百兆字节的开销。我们的容器都是数 GB。

木偶优点:

  • 易于扩展
  • 适用于现有服务器(windows、linux、sles)
  • 快速做出小的改变
  • 其他人偶用户和模块的强大社区
  • 用于在所有平台上安装软件包的标准化 API

傀儡缺点:

  • 大型基础设施变得非常复杂
  • 条件模块依赖创建意大利面条代码
  • 更重的重量

目前我们使用 puppet 来配置我们的 docker 容器。docker 容器用于 jenkins 构建,并在每次构建后销毁。它运行良好,并为我们提供了一致的环境。这意味着我们只需编写一次代码,然后重新构建 ubuntu、sles 和 centos 机器。重建容器大约需要 15 到 30 分钟,并且仍然是一个手动过程。Docker 非常适合启动快速测试虚拟机,

简而言之,puppet 非常擅长管理您现有的基础设施。如果您有一个 100% linux 的绿地,并且其技术堆栈可以包含在小型临时实例中,那么 Docker 会很好。虽然某些功能重叠,但它们并不相互排斥。

  • 我发现这个答案是主观的和推测性的。我不相信它真的回答了为什么人们可能会继续将 Puppet 与 Docker 一起/结合使用,当 Docker 在高层次上出现时,它是一个更简单的工具,用于同一目的。 (5认同)