Cloud Foundry Basic Questions

Question

I am very new to Cloud Foundry/Bosh and have a set of basic questions.

1) Droplet vs Garden container: I understand that droplet contains source code + build pack and these droplets are executed in garden container. IMHO, containers are good to transport to other system. Why there is intermediate notion of droplets? Should container by them-self not create the droplets?

2) Diego cell: What is the role of Diego cell (I assume that its job is to only start/stop garden containers) ? Are Diego cell platform dependent (eg. particular cell can run only windows-garden or other can run linux-garden container) ? Do we need one cell per container?

3) In the description of Diego cell, I read "Each application VM has a Diego Cell that executes application start and stop actions locally, manages the VM’s containers, and reports app status and other data to the BBS and Loggregator." What is application VM mentioned here? Does it mean container?

4) Lets assume, I use Bosh to create my cloud foundry instance. After some time, I need to scale my system to two VMs (due to increase in load). Do I need to create a new Manifest for second VM (As the earlier manifest will also deploy the entire CF on this VM also)?

Answer 1

A container is, roughly speaking, a root file system image together with some things like resource limits and metadata about what volumes to mount, what processes to run, etc.

Garden is an API for creating and running container specifications. Anyone can write a server that implements the Garden API, the core Cloud Foundry teams maintain garden-linux, garden-runC, and garden-windows implementations.

A droplet is a "built" artifact created from source code that is typically mounted or streamed into a Garden container and then run. There are times where you do not want a separate droplet, and want to have your root file system as well as all source code and/or built artifacts baked into a single image. However, often, you do want this separation between the droplet, which represents your code, and the root file system. One major benefit is that CVEs present in lower level dependencies that are common to most containers can be uniformly repaired across all tenants and all running applications on the Cloud Foundry platform without any developers having to re-push their code. E.g. if there is a new patch required for something like openssl, and your Cloud Foundry installation has thousands of developers and hundreds of thousands of running Garden containers, it would be much better if an operator could roll out the openssl patch to all containers with a single command.

The Diego cell is a VM that's part of the Cloud Foundry architecture. Cloud Foundry itself is a distributed system with different components responsible for different things. There is a component responsible for user authorization and authentication, there are components for aggregating logs from applications, there is a component responsible for providing the developer-facing API for creating, scaling, and managing applications, etc. The Diego cell's are responsible for essentially taking requests to run containerized workloads, and running them. User requests to run an application are consumed by the user-facing API, and translated to a request to the Diego backend. Diego itself has several components, including a scheduler, and the scheduler's job is to select which cell to do a given piece of work.

You can think of the cell has having two components: (1) a Garden server for running containers, and (2) a representative that can represent that Garden server to the Diego scheduler, so rather than Garden having any Diego-specific knowledge (Garden can function in a standalone manner), the scheduler instead talks to each Garden's Diego representative on that same cell.

I'm not sure what "application VM" means in the quote you pulled out. Each application running on Cloud Foundry can be run with multiple parallel instances (for fault tolerance, better concurrency, etc.). Each application instance is running as a Garden container in some Diego cell. A production deployment of Cloud Foundry will have many Diego cells. Each cell can run many (up to hundreds) of Garden containers. For better fault tolerance, the Diego scheduler will attempt to place the instances of a given application on different Diego cells, rather than cramming them all into the same cell, since if that single cell goes down, your whole application goes down.

You do not need to create a new manifest to scale up BOSH deployments. Just change the instances value of whatever job/instance group you want to have more VMs of, and re-run bosh deploy.

Answer 2

1) The droplet is a container image that is stored persistently when you upload your application with a cf push. This image will be re-used whenever the system creates a new container with the same image (for example, when you restart your application, or scale to multiple instances). Without the droplet, you would have to re-upload your application and create the container image every time you wanted a new instance.

2) The Diego cell runs in a large VM that hosts many containers. A typical Diego cell might be 32G in size, while a typical container might be 1G. Diego cells currently only run Linux-Garden containers.

3) The application VM is just the VM that is hosting the Diego cell. I found the sentence a bit confusing because I tend to use the term Diego cell to refer both to the cell software and to the "application VM" which is hosting it.

4) Bosh will use multiple VMs to deploy Cloud Foundry. Single-VM deployments do exist (see for example, http://pivotal.io/pcf-dev) but they are not deployed with Bosh.