github.com/huiliang/nomad@v0.2.1-0.20151124023127-7a8b664699ff/website/source/docs/drivers/docker.html.md (about) 1 --- 2 layout: "docs" 3 page_title: "Drivers: Docker" 4 sidebar_current: "docs-drivers-docker" 5 description: |- 6 The Docker task driver is used to run Docker based tasks. 7 --- 8 9 # Docker Driver 10 11 Name: `docker` 12 13 The `docker` driver provides a first-class Docker workflow on Nomad. The Docker 14 driver handles downloading containers, mapping ports, and starting, watching, 15 and cleaning up after containers. 16 17 ## Task Configuration 18 19 The `docker` driver is configured via a `config` block: 20 21 ``` 22 task "webservice" { 23 driver = "docker" 24 config = { 25 image = "redis" 26 labels = { 27 group = "webservice-cache" 28 } 29 } 30 } 31 ``` 32 33 The following options are available for use in the job specification. 34 35 * `image` - The Docker image to run. The image may include a tag or custom URL. 36 By default it will be fetched from Docker Hub. 37 38 * `command` - (Optional) The command to run when starting the container. 39 40 * `args` - (Optional) A list of arguments to the optional `command`. If no 41 `command` is present, `args` are ignored. 42 43 * `labels` - (Optional) A key/value map of labels to set to the containers on 44 start. 45 46 * `privileged` - (Optional) `true` or `false` (default). Privileged mode gives 47 the container access to devices on the host. Note that this also requires the 48 nomad agent and docker daemon to be configured to allow privileged 49 containers. 50 51 * `network_mode` - (Optional) The network mode to be used for the container. In 52 order to support userspace networking plugins in Docker 1.9 this accepts any 53 value. The default is `bridge`. Other networking modes may not work without 54 additional configuration on the host (which is outside the scope of Nomad). 55 Valid values pre-docker 1.9 are `default`, `bridge`, `host`, `none`, or 56 `container:name`. See below for more details. 57 58 * `hostname` - (Optional) The hostname to assign to the container. When 59 launching more than one of a task (using `count`) with this option set, every 60 container the task starts will have the same hostname. 61 62 * `dns_servers` - (Optional) A list of DNS servers for the container to use 63 (e.g. ["8.8.8.8", "8.8.4.4"]). *Docker API v1.10 and above only* 64 65 * `search_domains` - (Optional) A list of DNS search domains for the container 66 to use. 67 68 * `port_map` - (Optional) A key/value map of port labels (see below). 69 70 * `auth` - (Optional) Provide authentication for a private registry (see below). 71 72 ### Container Name 73 74 Nomad creates a container after pulling an image. Containers are named 75 `{taskName}-{allocId}`. This is necessary in order to place more than one 76 container from the same task on a host (e.g. with count > 1). This also means 77 that each container's name is unique across the cluster. 78 79 This is not configurable. 80 81 ### Authentication 82 83 If you want to pull from a private repo (for example on dockerhub or quay.io), 84 you will need to specify credentials in your job via the `auth` option. 85 86 The `auth` object supports the following keys: 87 88 * `username` - (Optional) The account username. 89 90 * `password` - (Optional) The account password. 91 92 * `email` - (Optional) The account email. 93 94 * `server_address` - (Optional) The server domain/ip without the protocol. 95 Docker Hub is used by default. 96 97 Example: 98 99 ``` 100 task "secretservice" { 101 driver = "docker" 102 config { 103 image = "secret/service" 104 auth { 105 username = "dockerhub_user" 106 password = "dockerhub_password" 107 } 108 } 109 } 110 ``` 111 112 **Please note that these credentials are stored in Nomad in plain text.** 113 Secrets management will be added in a later release. 114 115 ## Networking 116 117 Docker supports a variety of networking configurations, including using host 118 interfaces, SDNs, etc. Nomad uses `bridged` networking by default, like Docker. 119 120 You can specify other networking options, including custom networking plugins 121 in Docker 1.9. **You may need to perform additional configuration on the host 122 in order to make these work.** This additional configuration is outside the 123 scope of Nomad. 124 125 ### Allocating Ports 126 127 You can allocate ports to your task using the port syntax described on the 128 [networking page](/docs/jobspec/networking.html). Here is a recap: 129 130 ``` 131 task "webservice" { 132 driver = "docker" 133 134 port "http" {} 135 port "https" {} 136 } 137 ``` 138 139 ### Forwarding and Exposing Ports 140 141 A Docker container typically specifies which port a service will listen on by 142 specifying the `EXPOSE` directive in the `Dockerfile`. 143 144 Because dynamic ports will not match the ports exposed in your Dockerfile, 145 Nomad will automatically expose all of the ports it allocates to your 146 container. 147 148 These ports will be identified via environment variables. For example: 149 150 ``` 151 port "http" {} 152 ``` 153 154 If Nomad allocates port `23332` to your task for `http`, `23332` will be 155 automatically exposed and forwarded to your container, and the driver will set 156 an environment variable `NOMAD_PORT_http` with the value `23332` that you can 157 read inside your container. 158 159 This provides an easy way to use the `host` networking option for better 160 performance. 161 162 ### Using the Port Map 163 164 If you prefer to use the traditional port-mapping method, you can specify the 165 `port_map` option in your job specification. It looks like this: 166 167 ``` 168 task "redis" { 169 driver = "docker" 170 171 port "redis" {} 172 173 config { 174 image = "redis" 175 port_map { 176 redis = 6379 177 } 178 } 179 } 180 ``` 181 182 If Nomad allocates port `23332` to your task, the Docker driver will 183 automatically setup the port mapping from `23332` on the host to `6379` in your 184 container, so it will just work! 185 186 Note that by default this only works with `bridged` networking mode. It may 187 also work with custom networking plugins which implement the same API for 188 expose and port forwarding. 189 190 ### Networking Protocols 191 192 The Docker driver configures ports on both the `tcp` and `udp` protocols. 193 194 This is not configurable. 195 196 ### Other Networking Modes 197 198 Some networking modes like `container` or `none` will require coordination 199 outside of Nomad. First-class support for these options may be improved later 200 through Nomad plugins or dynamic job configuration. 201 202 ## Host Requirements 203 204 Nomad requires Docker to be installed and running on the host alongside the 205 Nomad agent. Nomad was developed against Docker `1.8.2` and `1.9`. 206 207 By default Nomad communicates with the Docker daemon using the daemon's unix 208 socket. Nomad will need to be able to read/write to this socket. If you do not 209 run Nomad as root, make sure you add the Nomad user to the Docker group so 210 Nomad can communicate with the Docker daemon. 211 212 For example, on ubuntu you can use the `usermod` command to add the `vagrant` 213 user to the `docker` group so you can run Nomad without root: 214 215 sudo usermod -G docker -a vagrant 216 217 For the best performance and security features you should use recent versions 218 of the Linux Kernel and Docker daemon. 219 220 ## Agent Configuration 221 222 The `docker` driver has the following host-level configuration options: 223 224 * `docker.endpoint` - Defaults to `unix:///var/run/docker.sock`. You will need 225 to customize this if you use a non-standard socket (http or another 226 location). 227 228 * `docker.tls.cert` - Path to the server's certificate file (`.pem`). Specify 229 this along with `docker.tls.key` and `docker.tls.ca` to use a TLS client to 230 connect to the docker daemon. `docker.endpoint` must also be specified or 231 this setting will be ignored. 232 233 * `docker.tls.key` - Path to the client's private key (`.pem`). Specify this 234 along with `docker.tls.cert` and `docker.tls.ca` to use a TLS client to 235 connect to the docker daemon. `docker.endpoint` must also be specified or 236 this setting will be ignored. 237 238 * `docker.tls.ca` - Path to the server's CA file (`.pem`). Specify this along 239 with `docker.tls.cert` and `docker.tls.key` to use a TLS client to connect to 240 the docker daemon. `docker.endpoint` must also be specified or this setting 241 will be ignored. 242 243 * `docker.cleanup.container` Defaults to `true`. Changing this to `false` will 244 prevent Nomad from removing containers from stopped tasks. 245 246 * `docker.cleanup.image` Defaults to `true`. Changing this to `false` will 247 prevent Nomad from removing images from stopped tasks. 248 249 * `docker.privileged.enabled` Defaults to `false`. Changing this to `true` will 250 allow containers to use `privileged` mode, which gives the containers full 251 access to the host's devices. Note that you must set a similar setting on the 252 Docker daemon for this to work. 253 254 cert := d.config.Read("docker.tls.cert") 255 key := d.config.Read("docker.tls.key") 256 ca := d.config.Read("docker.tls.ca") 257 258 Note: When testing or using the `-dev` flag you can use `DOCKER_HOST`, 259 `DOCKER_TLS_VERIFY`, and `DOCKER_CERT_PATH` to customize Nomad's behavior. If 260 `docker.endpoint` is set Nomad will **only** read client configuration from the 261 config filie. 262 263 ## Agent Attributes 264 265 The `docker` driver will set the following client attributes: 266 267 * `driver.docker` - This will be set to "1", indicating the driver is 268 available. 269 * `driver.docker.version` - This will be set to version of the docker server 270 271 ## Resource Isolation 272 273 ### CPU 274 275 Nomad limits containers' CPU based on CPU shares. CPU shares allow containers 276 to burst past their CPU limits. CPU limits will only be imposed when there is 277 contention for resources. When the host is under load your process may be 278 throttled to stabilize QOS depending on how many shares it has. You can see how 279 many CPU shares are available to your process by reading `NOMAD_CPU_LIMIT`. 280 1000 shares are approximately equal to 1Ghz. 281 282 Please keep the implications of CPU shares in mind when you load test workloads 283 on Nomad. 284 285 ### Memory 286 287 Nomad limits containers' memory usage based on total virtual memory. This means 288 that containers scheduled by Nomad cannot use swap. This is to ensure that a 289 swappy process does not degrade performance for other workloads on the same 290 host. 291 292 Since memory is not an elastic resource, you will need to make sure your 293 container does not exceed the amount of memory allocated to it, or it will be 294 terminated or crash when it tries to malloc. A process can inspect its memory 295 limit by reading `NOMAD_MEMORY_LIMIT`, but will need to track its own memory 296 usage. Memory limit is expressed in megabytes so 1024 = 1Gb. 297 298 ### IO 299 300 Nomad's Docker integration does not currently provide QOS around network or 301 filesystem IO. These will be added in a later release. 302 303 ### Security 304 305 Docker provides resource isolation by way of 306 [cgroups and namespaces](https://docs.docker.com/introduction/understanding-docker/#the-underlying-technology). 307 Containers essentially have a virtual file system all to themselves. If you 308 need a higher degree of isolation between processes for security or other 309 reasons, it is recommended to use full virtualization like 310 [QEMU](/docs/drivers/qemu.html).