cloud-foundry - Cloud Foundry基本问题

Question

我是Cloud Foundry/Bosh的新手，并且有一系列基本问题。

1)Droplet与Garden容器:我了解Droplet包含源代码+构建包，并且这些Droplet在Garden容器中执行。恕我直言，容器很好地运输到其他系统。为什么会有液滴的中间概念？容器自身不应该产生液滴吗？

2)Diego单元格: Diego单元格的作用是什么(我假设它的工作是仅启动/停止花园容器)？迭戈单元平台是否相关(例如特定单元只能运行Windows-garden或其他单元可以运行linux-garden容器)？每个容器需要一个细胞吗？

3)在Diego单元的描述中，我读到“每个应用程序VM都有一个Diego单元，该单元在本地执行应用程序的启动和停止操作，管理VM的容器，并将应用程序状态和其他数据报告给BBS和Loggregator。”
这里提到的应用虚拟机是什么？它是指容器吗？

4)假设，我使用Bosh创建我的Cloud Foundry实例。一段时间后，我需要将系统扩展到两个VM(由于负载增加)。我是否需要为第二个VM创建新的 list (因为较早的 list 也将在此VM上部署整个CF)？

Answer 1

大致来说，容器是一个根文件系统镜像，以及诸如资源限制和关于要装入的卷，要运行的进程等的元数据之类的内容。

花园是用于创建和运行容器规范的API。任何人都可以编写实现Garden API的服务器，Cloud Foundry核心团队维护 garden-linux ， garden-runC 和 garden-windows 的实现。

小滴是从源代码创建的“构建”工件，通常将其安装或流式传输到Garden容器中然后运行。有时候，您不需要单独的Droplet，并希望将您的根文件系统以及所有源代码和/或构建的工件烘焙到单个图像中。但是，通常，您确实希望代表代码的小滴与根文件系统之间存在这种分隔。一个主要好处是，大多数容器共有的低级依赖关系中存在的CVE可以在Cloud Foundry平台上的所有租户和所有正在运行的应用程序中进行统一修复，而无需任何开发人员重新推送其代码。例如。如果像openssl这样的东西需要一个新的补丁程序，并且您的Cloud Foundry安装中有成千上万的开发人员和成千上万的运行中的Garden容器，那么如果运算符(operator)可以将openssl补丁程序发布到所有容器中，则更好命令。

Diego单元格是VM，它是Cloud Foundry体系结构的一部分。 Cloud Foundry本身是一个分布式系统，具有负责不同事务的不同组件。有一个组件负责用户授权和身份验证，有一个组件用于汇总来自应用程序的日志，有一个组件负责提供面向开发人员的API以创建，扩展和管理应用程序等。Diego单元实质上负责接受运行容器化工作负载的请求并运行它们。面向用户的API消耗了运行应用程序的用户请求，并将其转换为对Diego后端的请求。 Diego本身具有多个组件，包括调度程序，调度程序的工作是选择要执行给定工作的单元。

您可以认为该单元具有两个组件:(1)用于运行容器的Garden服务器，以及(2)可以将Diego服务器表示为Diego调度程序的代表，而不是Garden具有任何特定于Diego的知识(花园可以以独立的方式运行)，而是调度程序在同一单元上与每个Garden的Diego代表进行对话。

我不确定您拔出的引号中的“应用程序VM”是什么意思。 Cloud Foundry上运行的每个应用程序都可以与多个并行实例一起运行(以实现容错，更好的并发性等)。每个应用程序实例都在某个Diego单元中作为Garden容器运行。 Cloud Foundry的生产部署将有许多Diego单元。每个单元可以运行许多(最多数百个)Garden容器。为了获得更好的容错能力，Diego调度程序将尝试将给定应用程序的实例放置在不同的Diego单元上，而不是将所有实例都塞入同一单元中，因为如果单个单元出现故障，则整个应用程序都将崩溃。

您无需创建新 list 即可扩展BOSH部署。只需更改要拥有更多VM的任何作业/实例组的instances值，然后重新运行bosh deploy即可。