用于容器工作负载的开放源代码私有云VM配置

Question

开发了新一代工具，试图将不同的IaaS提供者(Azure/AWS/GCE/DigitalOcean)集成到一个“基础结构代码库”中。它被称为“云本地人”，并被认为是“一个工具来统治他们的一切”。这里有来自HashiCorp的Terraform，来自Docker的InfraKit，来自规范的Juju，独立的Foreman，Pulumi和其他。

很容易迷路。这些工具中哪一个最适合IaaS？假设您有一堆金属服务器，您想在那里提供一些VM。假设您不需要VirtualBox/VMWare/ESX/Xen，您需要KVM。除此之外，还有一个明显的选择是利布维特。要管理多个虚拟机监控程序，我们需要使用连接URI远程连接到libvirt守护进程。对于KVM，我们可以使用qemu+ssh。让我们假设我们使用PXE引导来设置它们。现在，我们有了大量的qemu+ssh://链接和ssh访问。

现在，我们需要一个核心组件来管理资源和一些工具，以便根据某种声明性规范提供虚拟主机。

在这些VM之上，我希望运行容器，因此需要自动设置容器编排集群。此外，还需要某种附加存储的方式。至少直接连接块设备或fs安装。

有什么建议吗？

注意:找到了一个类似的问题，但是Xen。

澄清：“最适合”需要衡量标准。以下是我想要优化的指标：

• 零闭源LOC
• 工具的数量，如果不是“全部一体”的话
• 设置3主+5工作人员的UI操作K8s/群集群
  • 命令数量(用于CLI工具)
  • 点击次数(用于基于Web的/GUI工具)
  • 配置文件的长度/大小

• 安装工具的UI操作
• 维护配置的UI操作(最好是无，自愈基础设施)

Answer 1

“最适合”是问题所在。你怎么测量这个？衡量标准是什么?为什么要选择它们？我认为你正在寻找某种“工具组合”，早期测试由其他人的生产，如果喜欢的话。您想要做的是在这个私有环境中尝试一些开源/免费的私有云，并运行IaC。你可以永远测试工具。你如何比较这些工具？我相信只要没有任何不一致的问题，它们都能正常工作。我认为，当涉及到IaC时，您的搜索中有一个缺失/主要部分。因为缺少角度的选择也不多。我认为最好是为我们大家创建一个图表，因为你们正在进行这一进程，以造福于这里的人们。你有工作环境吗？如果是这样的话，你能详细说明你用来创建这个环境的所有工具吗？

一些供应商运行开源项目。那他们呢？

寻求通过培育和维护一个开源、供应商中立的项目的生态系统来推动这一模式的采用。

我开始怀疑这是否是云本地的，那么不是云本地的是什么呢？

我想这就是你要找的。提供者和供给者之间的区别是模糊的。工作流自动化工具应该像云调度器使用GUI所做的那样。Terraform对提供者和提供程序进行了区分，但Cloudify在我看来删除了它们。对于架构师来说，使用GUI设计整个工作流对于达到所需的状态可能是有用的。编写您预先做过的干燥测试或用图表显示所需的状态。有一些东西你已经知道它的去向，因为你已经测试过了，看到它在图形工作流中流动是有意义的吗？那就去争取吧。对我来说，这是绘画的历史，我没有看到的好处。

有许多方法可以分解自动化的类型，无论是命令式还是声明式，还是编排与所需的配置状态。

大多数规划器完全基于CLI，或者提供非常有限的GUI操作。这里的一个明显的优点是Cloudify使您能够通过架构关系图一键单击。见：Terraform诉云。

提供者

提供者负责理解API交互和公开资源。提供者通常是IaaS (例如AWS、GCP、Microsoft、OpenStack)、PaaS (例如Heroku)或SaaS服务(例如、DNSimple、CloudFlare)。见：提供者。

供应人员

作为资源创建或销毁的一部分，提供程序用于在本地或远程计算机上执行脚本。供应程序可用于引导资源、销毁前的清理、运行配置管理等。参见：供给者。