<commit_before>---
title: Runtime Components
---

<%# Reset page title based on product title %>
<% current_page.data.title = vars.product_short + " Components" if vars.product_name != 'CF'  %>


This topic describes <%= vars.app_runtime_full %> runtime components.

## <a id="overview"></a> Overview

<%= vars.product_short %> components include a self-service application execution engine, an automation engine for application deployment and lifecycle management, and a scriptable command line interface (CLI), as well as integration with development tools to ease deployment processes.
<%= vars.product_short %> has an open architecture that includes a buildpack mechanism for adding frameworks, an application services interface, and a cloud provider interface.

See the descriptions below for more information about <%= vars.product_short %> components. Some descriptions include links to more detailed documentation.

![<%= vars.product_short %> Architecture](../images/cf_architecture_block.png)


## <a id='routing'></a> Routing

### <a id='router'></a> Router

The [router](./router.html) routes incoming traffic to the appropriate component, either a Cloud Controller component or a hosted application running on a Diego Cell.

The router periodically queries the Diego Bulletin Board System (BBS) to determine which cells and containers each application currently runs on. Using this information, the router recomputes new routing tables based on the IP addresses of each cell virtual machine (VM) and the host-side port numbers for the cell's containers.


## <a id='authentication'></a> Authentication

### <a id='uaa'></a> OAuth2 Server (UAA) and Login Server

The OAuth2 server (the [UAA](./uaa.html)) and Login Server work together to provide identity management.


## <a id='app-lifecycle'></a> App Lifecycle

### <a id='cc'></a> Cloud Controller and Diego Brain

The [Cloud Controller](./cloud-controller.html) (CC) directs the deployment of applications. To push an app to <%= vars.product_short %>, you target the Cloud Controller. The Cloud Controller then directs the Diego Brain through the CC-Bridge components to coordinate individual [Diego cells](#diego-cell) to stage and run applications.

The Cloud Controller also maintain records of [orgs, spaces, user roles](../roles.html), <%= vars.services_link %>, and more.

### <a id='nsync-bbs'></a> nsync, BBS, and Cell Reps

To keep applications available, cloud deployments must constantly monitor their states and reconcile them with their expected states, starting and stopping processes as required.

![<%= vars.product_short %> Architecture](../images/diego/app-monitor-sync-diego.png)

The nsync, BBS, and Cell Rep components work together along a chain to keep apps running. At one end is the user. At the other end are the instances of applications running on widely-distributed VMs, which may crash or become unavailable.

Here is how the components work together:

* **nsync** receives a message from the Cloud Controller when the user scales an app. It writes the number of instances into a `DesiredLRP` structure in the Diego BBS database. 
* **BBS** uses its convergence process to monitor the `DesiredLRP` and `ActualLRP` values. It launches or kills application instances as appropriate to ensure the `ActualLRP` count matches the `DesiredLRP` count.
* **Cell Rep** monitors the containers and provides the `ActualLRP` value.


## <a id='app-storage-execution'></a> App Storage and Execution

### <a id='blob'></a> Blobstore

The blobstore is a repository for large binary files, which Github cannot easily manage because GitHub is designed for code. The blobstore contains the following:

* Application code packages
* Buildpacks
* Droplets

You can configure the blobstore as either an internal server or an external S3 or S3-compatible endpoint. <%= vars.blobstore_kb %>

### <a id='diego-cell'></a> Diego Cell

Application instances, application tasks, and staging tasks all run as [Garden](garden.html) containers on the Diego Cell VMs. The Diego cell rep component manages the lifecycle of those containers and the processes running in them, reports their status to the Diego BBS, and emits their logs and metrics to [Loggregator](#metrics-logging).


## <a id='services'></a> Services

### <a id='broker'></a> Service Brokers

Applications typically depend on <%= vars.services %> such as databases or third-party SaaS providers. When a developer provisions and binds a service to an application, the service broker for that service is responsible for providing the service instance.


## <a id='messaging'></a> Messaging

### <a id='bbs'></a> Internal HTTPS and BBS

<%= vars.product_short %> component VMs communicate with each other internally through HTTP and HTTPS protocols, sharing temporary messages and data stored in Diego's [Bulletin Board System (BBS)](../diego/diego-architecture.html#bbs).

* BOSH Director colocates a [BOSH DNS](https://bosh.io/docs/dns/) server on every deployed VM. All VMs keep up-to-date DNS records for all the other VMs in the same foundation, enabling service discovery between VMs. BOSH DNS also provides client-side load-balancing by randomly selecting a healthy VM when multiple VMs are available.

* Diego's [Bulletin Board System](../diego/diego-architecture.html#bbs) (BBS) stores more frequently updated and disposable data such as cell and app status, unallocated work, and heartbeat messages, as well as longer-lived distributed locks. The BBS stores data in MySQL, using the [Go MySQL Driver](https://github.com/go-sql-driver/mysql).

The route-emitter component uses the NATS protocol to broadcast the latest routing tables to the routers.


## <a id='metrics-logging'></a> Metrics and Logging

### <a id='metrics'></a> Loggregator

The <%= vars.loggregator_name_or_link %> (log aggregator) system streams application logs to developers.

<% if vars.platform_code == 'CF' %>
<%= partial 'old_collector' %>
<% end %>

<commit_msg>Update or remove variable references [#165353862]<commit_after>---
title: Runtime Components
---

<%# Reset page title based on product title %>
<% current_page.data.title = vars.product_short + " Components" if vars.product_name != 'CF'  %>


This topic describes <%= vars.app_runtime_full %> runtime components.

## <a id="overview"></a> Overview

<%= vars.product_short %> components include a self-service application execution engine, an automation engine for application deployment and lifecycle management, and a scriptable command line interface (CLI), as well as integration with development tools to ease deployment processes.
<%= vars.product_short %> has an open architecture that includes a buildpack mechanism for adding frameworks, an application services interface, and a cloud provider interface.

See the descriptions below for more information about <%= vars.product_short %> components. Some descriptions include links to more detailed documentation.

![<%= vars.product_short %> Architecture](../images/cf_architecture_block.png)


## <a id='routing'></a> Routing

### <a id='router'></a> Router

The [router](./router.html) routes incoming traffic to the appropriate component, either a Cloud Controller component or a hosted application running on a Diego Cell.

The router periodically queries the Diego Bulletin Board System (BBS) to determine which cells and containers each application currently runs on. Using this information, the router recomputes new routing tables based on the IP addresses of each cell virtual machine (VM) and the host-side port numbers for the cell's containers.


## <a id='authentication'></a> Authentication

### <a id='uaa'></a> OAuth2 Server (UAA) and Login Server

The OAuth2 server (the [UAA](./uaa.html)) and Login Server work together to provide identity management.


## <a id='app-lifecycle'></a> App Lifecycle

### <a id='cc'></a> Cloud Controller and Diego Brain

The [Cloud Controller](./cloud-controller.html) (CC) directs the deployment of applications. To push an app to <%= vars.product_short %>, you target the Cloud Controller. The Cloud Controller then directs the Diego Brain through the CC-Bridge components to coordinate individual [Diego cells](#diego-cell) to stage and run applications.

The Cloud Controller also maintain records of [orgs, spaces, user roles](../roles.html), services, and more.

### <a id='nsync-bbs'></a> nsync, BBS, and Cell Reps

To keep applications available, cloud deployments must constantly monitor their states and reconcile them with their expected states, starting and stopping processes as required.

![<%= vars.product_short %> Architecture](../images/diego/app-monitor-sync-diego.png)

The nsync, BBS, and Cell Rep components work together along a chain to keep apps running. At one end is the user. At the other end are the instances of applications running on widely-distributed VMs, which may crash or become unavailable.

Here is how the components work together:

* **nsync** receives a message from the Cloud Controller when the user scales an app. It writes the number of instances into a `DesiredLRP` structure in the Diego BBS database. 
* **BBS** uses its convergence process to monitor the `DesiredLRP` and `ActualLRP` values. It launches or kills application instances as appropriate to ensure the `ActualLRP` count matches the `DesiredLRP` count.
* **Cell Rep** monitors the containers and provides the `ActualLRP` value.


## <a id='app-storage-execution'></a> App Storage and Execution

### <a id='blob'></a> Blobstore

The blobstore is a repository for large binary files, which Github cannot easily manage because GitHub is designed for code. The blobstore contains the following:

* Application code packages
* Buildpacks
* Droplets

You can configure the blobstore as either an internal server or an external S3 or S3-compatible endpoint. <%= vars.blobstore_kb %>

### <a id='diego-cell'></a> Diego Cell

Application instances, application tasks, and staging tasks all run as [Garden](garden.html) containers on the Diego Cell VMs. The Diego cell rep component manages the lifecycle of those containers and the processes running in them, reports their status to the Diego BBS, and emits their logs and metrics to [Loggregator](#metrics-logging).


## <a id='services'></a> Services

### <a id='broker'></a> Service Brokers

Applications typically depend on <%= vars.services %> such as databases or third-party SaaS providers. When a developer provisions and binds a service to an application, the service broker for that service is responsible for providing the service instance.


## <a id='messaging'></a> Messaging

### <a id='bbs'></a> Internal HTTPS and BBS

<%= vars.product_short %> component VMs communicate with each other internally through HTTP and HTTPS protocols, sharing temporary messages and data stored in Diego's [Bulletin Board System (BBS)](../diego/diego-architecture.html#bbs).

* BOSH Director colocates a [BOSH DNS](https://bosh.io/docs/dns/) server on every deployed VM. All VMs keep up-to-date DNS records for all the other VMs in the same foundation, enabling service discovery between VMs. BOSH DNS also provides client-side load-balancing by randomly selecting a healthy VM when multiple VMs are available.

* Diego's [Bulletin Board System](../diego/diego-architecture.html#bbs) (BBS) stores more frequently updated and disposable data such as cell and app status, unallocated work, and heartbeat messages, as well as longer-lived distributed locks. The BBS stores data in MySQL, using the [Go MySQL Driver](https://github.com/go-sql-driver/mysql).

The route-emitter component uses the NATS protocol to broadcast the latest routing tables to the routers.


## <a id='metrics-logging'></a> Metrics and Logging

### <a id='metrics'></a> Loggregator

The Loggregator (log aggregator) system streams application logs to developers.

For more information, see <%= vars.loggregator_arch_link %>.

<% if vars.platform_code == 'CF' %>
<%= partial 'old_collector' %>
<% end %>


{'fraction_non_alphanumeric': 0.09285476349100599, 'fraction_numerical': 0.0014157228514323785, 'mean_word_length': 4.933300395256917, 'pattern_counts': {'":': 0, '<': 104, '<?xml version=': 0, '>': 104, 'https://': 4, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2337240', 'n_tokens_mistral': 3254, 'n_tokens_neox': 3055, 'n_words': 1488}