forked from cloudfoundry/docs-cf-admin
-
Notifications
You must be signed in to change notification settings - Fork 2
/
docker.html.md.erb
146 lines (105 loc) · 6.69 KB
/
docker.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
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
---
title: Using Docker in Cloud Foundry
owner: Diego
---
<strong><%= modified_date %></strong>
This topic provides information about how Docker works in Cloud Foundry and describes how to push an application with a Docker image.
For information about Diego, see the [Diego Architecture](../concepts/diego/diego-architecture.html) topic.
In addition to the default Linux environment provided by Cloud Foundry,
operators can specify a Docker image that provides the file system used by the
container.
When pushing an app, you can specify the location of the docker image you want
to use.
A Docker image consists of a collection of layers.
Each layer consists of one or both of the following:
* Raw bits to download and mount. These bits form the file system.
* Metadata that describes commands, users, and environment for the layer.
This metadata includes the `ENTRYPOINT` and `CMD` directives, and is specified in the Dockerfile.
##<a id='create-container'></a>How Garden-runC Creates Containers##
Diego currently uses Garden-runC to construct Linux containers. Earlier
versions of Diego used Garden-Linux. For more information, see the
[Garden](../concepts/architecture/garden.html) topic.
<%= vars.garden_runc %>
Both Docker and Garden-runC use libraries from the [Open Container Initiative (OCI)](https://www.opencontainers.org/) to build Linux containers.
After creation, these containers use name space isolation, or *namespaces*, and
control groups, or *cgroups*, to isolate processes in containers and limit
resource usage.
These are common kernel resource isolation features used by all Linux
containers.
Before Garden-runC creates a Linux container, it creates a file system that is
mounted as the root file system of the container.
Garden-runC supports mounting Docker images as the root file systems for the
containers it creates.
When creating a container, both Docker and Garden-runC perform the following
actions:
* Fetch and cache the individual layers associated with a Docker image
* Combine and mount the layers as the root file system
These actions produce a container whose contents exactly match the contents of
the associated Docker image.
##<a id='run-monitor'></a>How Diego Runs and Monitors Processes ##
After Garden-runC creates a container, Diego runs and monitors the processes
inside of it.
To determine which processes to run, the [Cloud Controller](../concepts/architecture/cloud-controller.html)
fetches and stores the metadata associated with the Docker image.
The Cloud Controller uses this metadata to perform the following actions:
* Runs the start command as the user specified in the Docker image
* Instructs Diego and the [Gorouter](../concepts/architecture/router.html) to route traffic to the lowest-numbered port exposed in the Docker image
<p class='note'><strong>Note</strong>: When launching an application on Diego, the Cloud Controller honors any user-specified overrides such as a custom start command or custom environment variables.</p>
##<a id='multi-tenant'></a>Docker Security Concerns in a Multi-Tenant Environment##
The attack surface area for a Docker-based container running on Diego remains
somewhat higher than that of a buildpack application because Docker allows
users to fully specify the contents of their root file systems.
A buildpack application runs on a trusted root filesystem.
Garden-runC provides features that allow the platform to run Docker images more
securely in a multi-tenant context.
In particular, Cloud Foundry uses the `user-namespacing` feature found on
modern Linux kernels to ensure that users cannot gain escalated privileges on
the host even if they escalate privileges within a container.
The Cloud Controller always runs Docker containers on Diego with user
namespaces enabled.
This security restriction prevents certain features, such as the ability to mount FuseFS devices, from working in Docker containers.
Docker applications can use fuse mounts through [volume services](#volume), but they cannot directly mount fuse devices from within the container.
To mitigate security concerns, Cloud Foundry recommends that you run only
trusted Docker containers on the platform.
By default, the Cloud Controller does not allow Docker-based applications to
run on the platform.
To allow Docker-based applications to run, a Cloud Controller administrator can
enable the `diego_docker` feature flag with the following command:
<pre class='terminal'>
$ cf enable-feature-flag diego_docker
</pre>
To disallow Docker-based applications, a Cloud Controller administrator can run
the following command:
<pre class='terminal'>
$ cf disable-feature-flag diego_docker
</pre>
<p class='note'><strong>Note</strong>: Disabling the <code>diego_docker</code> feature flag stops all Docker-based apps in your deployment within a few convergence cycles, on the order of a minute.</p>
##<a id='push-docker'></a>Push a Docker Image with the cf CLI
Follow these instructions to deploy updated or new Docker images using the
[Cloud Foundry Command Line Interface (cf CLI)](../cf-cli/install-go-cli.html).
When pushing an app, you specify either a Docker image on Docker Hub or the URI
to a trusted Docker registry.
Diego does not support using private registries.
Also, when using Diego, you must use a registry that supports the [Docker Registry API V2](https://docs.docker.com/registry/spec/api/).
###<a id='public'></a>Push a Docker Image Using Docker Hub
Run `cf push test-app -o cloudfoundry/MY-DOCKER-IMAGE` to deploy a Docker
image.
Replace `MY-DOCKER-IMAGE` with the name of an image from an accessible Docker
Registry.
For example, the following command pushes the `test-app` on Docker Hub to Cloud
Foundry:
<pre class='terminal'>$ cf push test-app -o cloudfoundry/test-app</pre>
###<a id='private'></a>Push a Docker Image Using Docker Trusted Registries
To deploy a Docker image using Docker trusted registries, run:
<pre class='terminal'>$ cf push my-app -o MY-PRIVATE-REGISTRY.DOMAIN:5000/image/name:v2
</pre>
Replace `MY-PRIVATE-REGISTRY.DOMAIN` with your domain name, which resolves to
the private registry.
This example uses the following values:
* `5000`: The port on which your private registry serves traffic.
* `image/name`: The name of the Docker image repository.
* `v2`: A tag in the specified Docker image repository that refers to a specific image.
###<a id='volume'></a> Docker Volume Support
Diego now supports Docker volumes.
For more information about enabling volume support, see the [Using an External File System (Volume Services)](../devguide/services/using-vol-services.html) topic.
For information about the limitations of NFS volumes, see the [NFS Bosh Volume Release](https://github.com/cloudfoundry-incubator/nfs-volume-release#special-notes-for-docker-image-based-apps).