Cloud Foundry is an open platform as a service (PaaS) that provides a choice of clouds, developer frameworks, and application services. Cloud Foundry makes it faster and easier to build, test, deploy, and scale applications.
This repository contains the Cloud Foundry source code.
Our documentation (currently a work in progress) is available here: http://docs.cloudfoundry.org/.
The develop branch is where we do active development. Although we endeavor to keep the develop branch stable, we do not guarantee that any given commit will deploy cleanly.
If you want a stable branch, we recommend that you use the release-candidate branch.
This repository is structured for use with BOSH; an open source tool for release engineering, deployment and lifecycle management of large scale distributed services. There are two directories of note:
Source:
- jobs: start and stop commands for each of the jobs (processes) running on Cloud Foundry nodes.
- packages: packaging instructions used by BOSH to build each of the dependencies.
- src: the source code for the components in Cloud Foundry. Note that each of the components is a submodule with a pointer to a specific SHA.
Releases:
- releases: yml files containing the references to blobs for each package in a given release; these are solved within .final_builds
- .final_builds: references into the public blostore for final jobs & packages (each referenced by one or more releases)
- config: URLs and access credentials to the bosh blobstore for storing final releases
- git: Local git hooks
See the documentation for deploying Cloud Foundry for more information about using BOSH.
In order to deploy Cloud Foundry with BOSH, you will need to create a manifest.
To do so, ensure that you have installed Spiff before running ./generate_deployment_manifest <infrastructure-type>; where <infrastructure-type> is one of aws, vsphere, or warden.
This script merges together several manifest stubs from the templates directory using Spiff. Consult the spiff repository for more information on installing and using spiff.
A complete sample manifest for vSphere is also available in the Cloud Foundry documentation.
The current development efforts center on V2, also known as NG. For information on what the core team is working on, please see our roadmap.
The components in a V2 deployment are:
| Component | Description | Build Status |
|---|---|---|
| Cloud Controller (cc) | The primary API entry point for Cloud Foundry. |  |
| gorouter | The central router that manages traffic to applications deployed on Cloud Foundry. |  |
| DEA (dea_next) | The droplet execution agent (DEA) performs two key activities in Cloud Foundry: staging and hosting applications. |  |
| Health Manager | The health manager monitors the state of the applications and ensures that started applications are indeed running, their versions and number of instances correct. |  |
./updatepulls cf-release and updates all submodules (recursively) to the correct commit. This is useful in the following situations:- After you've first cloned the repo
- Before you make changes to the directory. (Running the script avoids having to rebase your changes on top of submodule updates.)
./commit_with_shortlogcommits changes you've made usingupdate_sub.
Questions about the Cloud Foundry Open Source Project can be directed to our Google Groups.
- BOSH Developers: https://groups.google.com/a/cloudfoundry.org/group/bosh-dev/topics
- BOSH Users:https://groups.google.com/a/cloudfoundry.org/group/bosh-users/topics
- VCAP (Cloud Foundry) Developers: https://groups.google.com/a/cloudfoundry.org/group/vcap-dev/topics
Bugs can be filed using GitHub Issues in the respective repository of each Cloud Foundry component.
Please read the contributors' guide