forked from cloudfoundry/docs-bosh
-
Notifications
You must be signed in to change notification settings - Fork 0
/
terminology.html.md.erb
91 lines (48 loc) · 4.87 KB
/
terminology.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
---
title: Terminology
---
## <a id="agent"></a> Agent
A process that runs continuously on each VM that BOSH deploys (one Agent process per VM). The Agent executes tasks in response to messages it receives from the Director.
## <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="canary"></a> Canary
Canary instances are instances updated before other instances. Any update error in a canary instance causes the deployment to stop. Since only canaries are affected before an update stops, problem packages or jobs are prevented from taking over all job instances.
## <a id="cli"></a> CLI
The BOSH Command Line Interface (CLI) is what you use to run BOSH commands. You must [install](./bosh-cli.html) the CLI to use BOSH. Run `bosh help --all` to view the help.
## <a id="cpi"></a> CPI
A Cloud Provider Interface is a software layer between the Director and an IaaS (cloud).
## <a id="deploy"></a> Deploy
BOSH deploys software to the cloud using a deployment manifest, one or more stemcells, and one or more releases.
## <a id="deployment"></a> Deployment
An encapsulation of software and configuration that BOSH can deploy to the cloud. You can think of a deployment as the state of a collection of VMs: what software is on them, what resources they use, and how these are orchestrated. Even though BOSH creates the deployment using ephemeral resources, the deployment is stable in that BOSH re-creates VMs that fail and otherwise works to keep your software running. BOSH also manages persistent disks so that state (for example, database data files) can survive when BOSH re-creates a VM. A particular combination of manifest, stemcell, and release is portable across different kinds of cloud infrastructure (that is, across different CPIs) with minimal changes to the manifest.
## <a id="director"></a> Director
The main BOSH component that coordinates the Agents and responds to user requests and system events. The Director is the orchestrator of deployments.
## <a id="director-blobstore"></a> Director Blobstore
A repository where BOSH stores release artifacts, logs, stemcells, and other content, at various times during the lifecycle of a BOSH release.
## <a id="director-task"></a> Director Task
The basic unit of work performed by the Director. You can get the status and logs for any task. You can monitor the task throughout its lifecycle, which progresses through states like started, running, done, and error.
## <a id="disk-pools"></a> Disk Pools
Disk pools are logical collections of disks, in a deployment, each created with the same configuration.
## <a id="environment"></a> Environment
A single environment consists of a Director and deployments that it orchestrates. A good example of two separate environments are staging and production environments.</li></ul>
## <a id="errand"></a> Errand
An errand is a short-lived job that an operator can run multiple times after the deploy finishes. Examples:
- smoke tests
- comprehensive test suites
- CF service broker binding and unbinding
## <a id="iaas"></a> IaaS
Short for Infrastructure as a Service. BOSH enables the Cloud Foundry PaaS and other software deployed with BOSH to support multiple IaaS providers.
## <a id="job"></a> Job
A job is a composition of configuration and installed software on a VM. Each job specified names the VM types and job templates used to create the VMs. A job template is part of a release and populates VMs with packages, configuration files, and control scripts that tell the Agent what runs on the VM.
## <a id="jumpbox"></a> Jump box
A VM that acts as a single access point for the Director and deployed VMs. For resilience, there should be more than one jump box. Allowing access through jump boxes and disabling direct access to the other VMs is a common security measure.
## <a id="manifest"></a> Deployment manifest (or just manifest)
A YAML file that identifies one or more release, one or more stemcells and specifies how to configure them for a given deployment.
## <a id="microbosh"></a> MicroBOSH
A complete BOSH environment that runs on a single VM. One use of the MicroBOSH is to orchestrate the deployment of a BOSH on multiple VMs.
## <a id="release"></a> Release
A collection of configuration files, job definitions, source code, package definitions and accompanying information needed to make a software component deployable by BOSH. A self-contained release should have no dependencies that need to be fetched from the internet.
## <a id="resource-pools"></a> Resource Pools
Resource pools are collections of VMs created from the same stemcell, with the same configuration, in a deployment.
## <a id="stemcell"></a> Stemcell
A generic VM image that BOSH clones and configures to during deployment. A stemcell is a template from which BOSH creates whatever VMs are needed for a wide variety of components and products.