forked from cloudfoundry/docs-bosh
-
Notifications
You must be signed in to change notification settings - Fork 0
/
bosh-components.html.md.erb
108 lines (65 loc) · 5.09 KB
/
bosh-components.html.md.erb
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
---
title: BOSH Components
---
Before bootstrapping a new [environment](terminology.html#environment) we recommend to learn the names of major components that will be installed, used and configured:
<%= image_tag("images/bosh-architecture.png") %>
---
## <a id="bosh-init"></a> bosh-init
bosh-init is tool used for creating and updating the Director (its VM and persistent disk) in an environment.
---
## <a id="cli"></a> Command Line Interface (CLI)
The Command Line Interface (CLI) is the primary operator interface to BOSH. An operator uses the CLI to interact with the Director and perform actions on the cloud.
CLI is typically installed on a machine that can directly communicate with the Director's API, e.g. an operator's laptop, or a jumpbox in the datacenter.
---
## <a id="director"></a> Director
The Director is the core orchestrating component in BOSH. The Director controls VM creation and deployment, as well as other software and service lifecycle events.
The Director creates actionable tasks:
* By translating commands sent by an operator through the CLI
* From scheduled processes like backups or snapshots
* If needed to reconcile the expected state with the actual state of a VM
Once created, the Director adds these tasks to the Task Queue. Worker processes take tasks from the Task Queue and act on them.
### <a id="queue"></a> Task Queue
An asynchronous queue used by the Director and Workers to manage tasks. The Task Queue resides in a Redis key-value store.
### <a id="workers"></a> Workers
Director workers take tasks from the Task Queue and act on them.
### <a id="cpi"></a> Cloud Provider Interface (CPI)
A Cloud Provider Interface (CPI) is an API that the Director uses to interact with an IaaS to create and manage stemcells, VMs, and disks. A CPI abstracts infrastructure differences from the rest of BOSH.
---
## <a id="health-monitor"></a> Health Monitor
The Health Monitor uses status and lifecycle events received from Agents to monitor the health of VMs. If the Health Monitor detects a problem with a VM, it can send an alert through notification plugins, or trigger the Resurrector.
### <a id="resurrector"></a> Resurrector
If enabled, the Resurrector plugin automatically recreates VMs identified by the Health Monitor as missing or unresponsive. It uses same Director API that CLI uses.
---
## <a id="dns"></a> DNS Server
BOSH uses PowerDNS to provide DNS resolution between the VMs in a deployment.
---
## <a id="persistent"></a> Components used to store Director's persistent data
### <a id="database"></a> Database
The Director uses a Postgres database to store information about the desired state of a deployment. This includes information about stemcells, releases, and deployments.
### <a id="blobstore"></a> Blobstore
The Blobstore stores the source forms of releases and the compiled images of releases. An operator uploads a release using the CLI, and the Director inserts the release into the Blobstore. When you deploy a release, BOSH orchestrates the compilation of packages and stores the result in the Blobstore.
---
## <a id="agent"></a> Agent
BOSH includes an Agent on every VM that it deploys. The Agent listens for instructions from the Director and carries out those instructions. The Agent receives job specifications from the Director and uses them to assign a role, or Job, to the VM.
For example, to assign the job of running MySQL to a VM, the Director sends instructions to the Agent on the VM. These instructions include which packages to install and how to configure those packages. The Agent uses these instructions to install and configure MySQL on the VM.
---
## <a id="comm"></a> Components used for cross-component communication
### <a id="nats"></a> Message Bus (NATS)
The Director and the Agents communicate through a lightweight publish-subscribe messaging system called NATS. These messages have two purposes: to perform provisioning instructions on the VMs, and to inform the Health Monitor about changes in the health of monitored processes.
### <a id="registry"></a> Registry
When the Director creates or updates a VM, it stores configuration information for the VM in the Registry so that it can be used during bootstrapping stage of the VM.
---
## <a id="example"></a> Example component interaction
This example shows how components interact when creating a new VM.
### <a id="create-vm"></a> Creating a new VM
<%= image_tag("images/deploy-sequence.png") %>
1. Through the CLI, the operator takes an action (e.g. deploy for the first time, scaling up deployment) which requires creating a new VM.
1. The CLI passes the instruction to the Director.
1. The Director uses the CPI to tell the IaaS to launch a VM.
1. The IaaS provides the Director with information (IP addresses and IDs) the Agent on the VM needs to configure the VM.
1. The Director updates the Registry with the configuration information for the VM.
1. The Agent running on the VM requests the configuration information for the VM from the Registry.
1. The Registry responds with the IP addresses and IDs.
1. The Agent uses the IP addresses and IDs to configure the VM.
---
Next: [Bootstrapping an environment](init.html)