forked from cloudfoundry/docs-cloudfoundry-concepts
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathhow-applications-are-staged.html.md.erb
64 lines (35 loc) · 4.29 KB
/
how-applications-are-staged.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
---
title: How Applications Are Staged
owner:
- Runtime OG
- Diego
- CAPI
---
<strong><%= modified_date %></strong>
Cloud Foundry uses [Diego](../concepts/diego/diego-architecture.html) to manage application containers.
This topic describes how the Diego architecture stages [buildpack applications](#stage-buildpack) and [Docker images](#stage-docker).
##<a id='stage-buildpack'></a>How Diego Stages Buildpack Applications
<%= image_tag("app_push_flow_diagram_diego.png") %>
1. At the command line, the developer enters the directory containing her application source code and uses the Cloud Foundry Command Line Interface (cf CLI) to issue a push command.
2. The cf CLI tells the [Cloud Controller](../concepts/architecture/cloud-controller.html) to create a record for the application.
3. The Cloud Controller stores the application metadata. Application metadata can include the app name, number of instances the user specified, and the buildpack, and other information about the application.
4. Before uploading all the application source files, the cf CLI issues a resource match request to the Cloud Controller to determine if any of the application files already exist in the resource cache. When the application files are uploaded, the cf CLI omits files that exist in the resource cache by supplying the result of the resource match request. The uploaded application files are combined with the files from the resource cache to create the application package.
5. The Cloud Controller stores the application package in the [blobstore](../concepts/architecture/index.html#blob).
6. The cf CLI issues an app start command.
7. The Cloud Controller issues a staging request to Diego, which then schedules a [Diego cell](../concepts/diego/diego-architecture.html#cell-components) ("Cell") to run the staging [task](../concepts/diego/diego-auction.html#processes) ("Task"). The Task downloads buildpacks and the app’s buildpack cache, if present. It then uses the buildpack that is detected automatically or specified with the `-b` flag to compile and stage the application.
8. The Cell streams the output of the staging process so the developer can troubleshoot application staging problems.
9. The Task packages the resulting compiled and staged application into a tarball called a "droplet" and the Cell stores the droplet in the blobstore. The Task also uploads the buildpack cache to the blobstore for use the next time the application is staged.
10. The [Diego Bulletin Board System](../concepts/diego/diego-architecture.html#database-vms) reports to the Cloud Controller that staging is complete. Staging must complete within 15 minutes or the staging is considered failed. Apps are given a minimum of 1GB memory to stage, even if the requested running memory is smaller.
11. Diego schedules the application as a [Long Running Process](../concepts/diego/diego-auction.html#processes) on one or more Diego cells.
12. The Diego cells report the status of the application to the Cloud Controller.
See the [Diego Architecture](./diego/diego-architecture.html) topic for more information.
##<a id='stage-docker'></a>How Diego Stages Docker Images
<%= image_tag("docker_push_flow_diagram_diego.png") %>
1. At the command line, the developer enters the name of a Docker image in an accessible Docker Registry and uses the cf CLI to issue a push command.
2. The cf CLI tells the Cloud Controller to create a record for the Docker image.
2. The Cloud Controller issues a staging request to Diego, which then schedules a Cell to run the Task.
2. The Cell streams the output of the staging process so the developer can troubleshoot staging problems.
3. The Task fetches the metadata associated with the Docker image and returns a portion of it to the Cloud Controller, which stores it in the Cloud Controller database (CCDB).
4. The Cloud Controller uses the Docker image metadata to construct a Long Running Process that runs the start command specified in the Dockerfile. The Cloud Controller also takes into account any user-specified overrides specified in the Dockerfile, such as custom environment variables.
5. The Cloud Controller submits the Long Running Process to Diego. Diego schedules the Long Running Process on one or more Diego Cells.
6. The Cloud Controller instructs Diego and the Gorouter to route traffic to the Docker image.