Often when I'm talking to developers about Cloud Foundry, I get questions about where the different application dependencies come from. All applications deployed on Cloud Foundry rely on the following stack to provide it an operating system and needed middleware.
In this article I'm going to only focus on the role of the stemcell as it pertains to what a developer pushing an app on Cloud Foundry would see. The stemcell is responsible for a much larger portion of the stack on other components of CF and other bosh deployments.
As a developer, the stemcell is primarily responsible for providing the application a kernel and devices required for the application to run. The drivers for the network interface, semaphores required by compilers, and other kernel specific dependencies are also provided by the stemcell that is deployed to the DEA's (or in Diego lingo Cells). Today CF primarily uses an Ubuntu Trusty 14.04 stemcell, with support for RHEL7/CentOS7 and Windows Server 2012 coming soon.
Every container that is spun up in Cloud Foundry receives an root filesystem from an image that is purpose built for CF use. This image is kept as minimal as possible, only providing the bare essential dependencies for a Cloud Foundry buildpack to be able to run. For this reason, change here is minimized to essential security patches only. Keeping this layer consistent ensures applications and buildpacks continue to function properly as the rest of the stack iterates.
Buildpacks in Cloud Foundry are truly where the magic happens that enables developers to focus on developing business logic and enables ops folks to standardize their deployed stack. The format of a buildpack was adopted from Heroku and is being iterated to meet increasingly more robust application needs. Primarily buildpacks come with the following three scripts and any bundled dependencies required for deploying a user's application.
The detect script of each buildpack is executed in order of priority as defined by the CF operator. The first detect script that positively identifies the application as a match will end the detect process. Once a buildpack has detected an application it is capable of deploying, the compile process begins.
The compile script is responsible for providing the user's application with all the required middleware, app dependencies, and finally compiling a re-usable image of the end result. Often this involves installing a framework and/or web server along with running any staging commands against the application framework to download dependencies (i.e. maven, npm, pip, gem, nuget, etc). The end result of this process is an image of the application deployed and staged against the rootfs + stemcell kernel. This image called a droplet is then stored in the Cloud Foundry blobstore for immediate use.
Finally the release script provides execution metadata back to Cloud Foundry about how to execute the application and what environment variables need to be set for the application at execution.
It is a common practice for a CF operator to constrain the middleware/framework versions provided by a buildpack to establish a standard stack within an enterprise setting. It is also possible for developers to bring their own custom buildpack along with their application to provide a custom stack for their application not found in any of the default buildpacks. It is very easy for change to be made at this level of the stack without updating the entire environment. This is an ideal layer for customization and iteration of application dependencies.
Cloud Foundry leverages this unique layering of the traditional application host stack to enable devs to refocus on developing business value. Operators are given the needed tooling to establish a consistent execution environment while maintaining a very ephemeral (cattle) view of their deployed applications.