3

由于我想旋转多个虚拟机，LXD 似乎是一个有效的选择

但作为 docker，LXD 似乎少了一些嗡嗡声，

最初的想法，我已经使用LXC创建了一个启动测试容器，并安装了mongodb数据库，至少mongodb中的数据在重新启动容器后是持久的。（我在这里可能是错的）并且与 lxc-containers 交互就像您登录到物理服务器一样简单。

有没有人能说说 LXD 的优点、缺点和痛点，就像这篇文章提到使用 docker 的个人经验 一样？

希望回答的问题

  • 我可以在 12GB 的 RAM 和四核处理器上运行多少个 LXD 容器？
  • LXD 是否成熟到可以在生产环境中运行？
  • 我可以使用我的应用程序、数据库创建 LXD 图像并在生产服务器上运行吗？
  • LXD 容器的当前限制？
  • 它是由 Canonical 开发和维护的，（不确定这个项目会像 unity 8 一样被放弃），还是会继续？
4

1 回答 1

9

虽然这个答案没有 Docker 文章那么广泛，但我将讨论您的首选问题：

我可以在 12GB 的 RAM 和四核处理器上运行多少个 LXD 容器？

  • 真的没有设定的最大值基于您的硬件要求的容器，这也不是可以直接回答的问题。容器占用的空间非常小，因此就 RAM 和处理能力而言，在容器实际执行某些操作之前，它们不会真正使用资源。不要将 LXD 视为保留资源的管理程序，而是在请求冒泡到主机操作系统以进行硬件访问之前等待容器执行某些操作。话虽如此，您可以为每个容器设置资源上限，因此它们不会超过一定的限制，但您的问题的答案完全取决于容器将要做什么。您可以在该设置上运行数百个容器，但前提是它们不做任何事情。一旦他们开始消耗资源，你

LXD 是否成熟到可以在生产环境中运行？

  • 是的，我们已经为我们的生产服务器运行 LXD 一年多了，并且对正常运行时间非常满意。LXD 已经成熟满足我们的需求，但重要的是您首先评估您的业务需求。

我可以使用我的应用程序、数据库创建 LXD 图像并在生产服务器上运行吗？

  • 是的，它为此内置了命令。您可以使用他们的基础镜像，构建您的应用程序，制作它的镜像，然后在其他硬件上复制它，然后根据需要简单地指向您的负载均衡器。但要小心你的数据库。如果您正在复制您的应用程序，我建议您为您的数据库使用一个单独的 LXD 容器，您也可以根据需要对其进行分片和映像。我已经对一些容器进行了一些测试，我们有 50gb 的容器用于我们的数据库和复制映像，推送到异地进行备份，然后拉到新服务器通常需要不到 2 分钟的时间。因此，如果您有小型容器，您将拥有极快的响应时间。我们试图在这些图像写入期间导致数据库损坏，以及在成像过程中通过查询轰炸数据库，它非常优雅地处理它，没有任何损坏，但不要依赖它。也总是运行自己的备份。

LXD 容器的当前限制？

  • 关于限制，我发现糟糕的是基本网络设置。但是，现在正在开发中解决这个问题，而且要好得多。我们的测试版服务器现在通过 DHCP 进行连接，而不是通过桥接方式进行连接，这使它更快更容易推出。我发现那里缺少工具，所以如果你对命令行不太了解，你可能一开始可能会遇到困难。

它是由 Canonical 开发和维护的，（不确定这个项目会像 unity 8 一样被放弃），还是会继续？

  • 据我所知，开发非常活跃，这个项目的负责人 Stéphane Graber 将留在这里。他在社区中很活跃，我也看到他在 Stackexchange 上回答问题。如果它被删除，我会感到非常惊讶，因为 LXD 也是 LXC 的主要扩展。
于 2017-05-11T10:48:41.710 回答