LXD是否用于生产？

Question

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

但作为码头工人，LXD似乎没那么活跃，

首先，我使用LXC创建了一个测试容器，并安装了mongodb数据库，至少在重新启动容器后mongodb中的数据是持久的。(这里我可能错了)，与lxc容器交互就像登录到物理服务器一样简单。

有人能提到LXD的优点、坏处和痛苦之处吗?就像本文提到了使用docker的个人体验一样？

喜欢回答的问题

• 我能在12 on的RAM和Quad核心处理器上运行多少个LXD容器？
• LXD是否已经成熟到可以在生产中运行？
• 我是否可以使用我的应用程序、数据库创建LXD映像，并且只在生产服务器上运行？
• 当前LXD容器的限制？
• 它是由规范开发和维护的，(不确定这个项目是否会像统一8一样下降)，还是会继续？

Answer 1

虽然这个答案不像Docker文章那样广泛，但我将讨论您喜欢的问题：

我能在12 on的RAM和Quad核心处理器上运行多少个LXD容器？

• 根据您的硬件需求，实际上没有容器的最大值，也没有可以直接回答的东西。容器占用的内存非常小，因此在RAM和处理能力方面，它们在容器实际执行某些操作之前并不真正使用资源。不要认为LXD是保留资源的系统管理程序，而是坐着等待容器在请求冒泡到主机操作系统进行硬件访问之前做一些事情。尽管如此，您可以为每个容器设置资源上限，这样它们就不会超过一定的限制，但是您的问题的答案完全取决于容器将要做什么。您可以在这个设置上运行数百个容器，但前提是它们什么都不做。一旦它们开始消耗资源，您就会更清楚地知道可以运行多少。

LXD是否已经成熟到可以在生产中运行？

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

我是否可以使用我的应用程序、数据库创建LXD映像，并且只在生产服务器上运行？

• 是的，它有内置的命令。您可以使用它们的基本映像，构建您的应用程序，生成它的映像，然后在其他硬件上复制它，然后根据需要简单地指向您的负载均衡器。但要小心你的数据库。如果您正在复制您的应用程序，我建议您为您的数据库设置一个单独的LXD容器，您可以将其分解，并根据需要进行图像处理。我在一些容器上做了一些测试，我们为我们的DB提供了50 on的容器，为了复制映像，将备份推送出场外，然后拉到新服务器通常需要不到2分钟的时间。所以如果你有小容器，你就会有快速的响应时间。在这些映像写入过程中，我们还试图通过在成像过程中用查询轰击DB，从而导致数据库损坏，而且它处理数据库时非常优雅，没有一次损坏，但不要依赖它。也要运行自己的备份。

当前LXD容器的限制？

• 关于限制，我发现最糟糕的是基本的网络设置。然而，这一问题目前正在发展中，而且要好得多。我们的测试版服务器现在通过DHCP连接，而不是桥接，这使得它更快、更容易推出。我发现这里缺少一些工具，所以如果您不太喜欢命令行，那么您可能一开始就很困难。

它是由规范开发和维护的，(不确定这个项目是否会像统一8一样下降)，还是会继续？

• 据我所见，开发非常活跃，这个项目的负责人Stéphane Graber将留在这里。他在社区中很活跃，我也看到他在Stackexchange上回答问题。考虑到LXD也是LXC的一大扩展，如果它被放弃了，我会非常惊讶。