github.com/a4a881d4/docker@v1.9.0-rc2/docs/userguide/labels-custom-metadata.md (about) 1 <!--[metadata]> 2 +++ 3 title = "Apply custom metadata" 4 description = "Learn how to work with custom metadata in Docker, using labels." 5 keywords = ["Usage, user guide, labels, metadata, docker, documentation, examples, annotating"] 6 [menu.main] 7 parent = "mn_use_docker" 8 +++ 9 <![end-metadata]--> 10 11 # Apply custom metadata 12 13 You can apply metadata to your images, containers, or daemons via 14 labels. Labels serve a wide range of uses, such as adding notes or licensing 15 information to an image, or to identify a host. 16 17 A label is a `<key>` / `<value>` pair. Docker stores the label values as 18 *strings*. You can specify multiple labels but each `<key>` must be 19 unique or the value will be overwritten. If you specify the same `key` several 20 times but with different values, newer labels overwrite previous labels. Docker 21 uses the last `key=value` you supply. 22 23 >**Note:** Support for daemon-labels was added in Docker 1.4.1. Labels on 24 >containers and images are new in Docker 1.6.0 25 26 ## Label keys (namespaces) 27 28 Docker puts no hard restrictions on the `key` used for a label. However, using 29 simple keys can easily lead to conflicts. For example, you have chosen to 30 categorize your images by CPU architecture using "architecture" labels in 31 your Dockerfiles: 32 33 LABEL architecture="amd64" 34 35 LABEL architecture="ARMv7" 36 37 Another user may apply the same label based on a building's "architecture": 38 39 LABEL architecture="Art Nouveau" 40 41 To prevent naming conflicts, Docker recommends using namespaces to label keys 42 using reverse domain notation. Use the following guidelines to name your keys: 43 44 - All (third-party) tools should prefix their keys with the 45 reverse DNS notation of a domain controlled by the author. For 46 example, `com.example.some-label`. 47 48 - The `com.docker.*`, `io.docker.*` and `org.dockerproject.*` namespaces are 49 reserved for Docker's internal use. 50 51 - Keys should only consist of lower-cased alphanumeric characters, 52 dots and dashes (for example, `[a-z0-9-.]`). 53 54 - Keys should start *and* end with an alpha numeric character. 55 56 - Keys may not contain consecutive dots or dashes. 57 58 - Keys *without* namespace (dots) are reserved for CLI use. This allows end- 59 users to add metadata to their containers and images without having to type 60 cumbersome namespaces on the command-line. 61 62 63 These are simply guidelines and Docker does not *enforce* them. However, for 64 the benefit of the community, you *should* use namespaces for your label keys. 65 66 67 ## Store structured data in labels 68 69 Label values can contain any data type as long as it can be represented as a 70 string. For example, consider this JSON document: 71 72 73 { 74 "Description": "A containerized foobar", 75 "Usage": "docker run --rm example/foobar [args]", 76 "License": "GPL", 77 "Version": "0.0.1-beta", 78 "aBoolean": true, 79 "aNumber" : 0.01234, 80 "aNestedArray": ["a", "b", "c"] 81 } 82 83 You can store this struct in a label by serializing it to a string first: 84 85 LABEL com.example.image-specs="{\"Description\":\"A containerized foobar\",\"Usage\":\"docker run --rm example\\/foobar [args]\",\"License\":\"GPL\",\"Version\":\"0.0.1-beta\",\"aBoolean\":true,\"aNumber\":0.01234,\"aNestedArray\":[\"a\",\"b\",\"c\"]}" 86 87 While it is *possible* to store structured data in label values, Docker treats 88 this data as a 'regular' string. This means that Docker doesn't offer ways to 89 query (filter) based on nested properties. If your tool needs to filter on 90 nested properties, the tool itself needs to implement this functionality. 91 92 93 ## Add labels to images 94 95 To add labels to an image, use the `LABEL` instruction in your Dockerfile: 96 97 98 LABEL [<namespace>.]<key>[=<value>] ... 99 100 The `LABEL` instruction adds a label to your image, optionally with a value. 101 Use surrounding quotes or backslashes for labels that contain 102 white space characters in the `<value>`: 103 104 LABEL vendor=ACME\ Incorporated 105 LABEL com.example.version.is-beta 106 LABEL com.example.version="0.0.1-beta" 107 LABEL com.example.release-date="2015-02-12" 108 109 The `LABEL` instruction also supports setting multiple `<key>` / `<value>` pairs 110 in a single instruction: 111 112 LABEL com.example.version="0.0.1-beta" com.example.release-date="2015-02-12" 113 114 Long lines can be split up by using a backslash (`\`) as continuation marker: 115 116 LABEL vendor=ACME\ Incorporated \ 117 com.example.is-beta \ 118 com.example.version="0.0.1-beta" \ 119 com.example.release-date="2015-02-12" 120 121 Docker recommends you add multiple labels in a single `LABEL` instruction. Using 122 individual instructions for each label can result in an inefficient image. This 123 is because each `LABEL` instruction in a Dockerfile produces a new IMAGE layer. 124 125 You can view the labels via the `docker inspect` command: 126 127 $ docker inspect 4fa6e0f0c678 128 129 ... 130 "Labels": { 131 "vendor": "ACME Incorporated", 132 "com.example.is-beta": "", 133 "com.example.version": "0.0.1-beta", 134 "com.example.release-date": "2015-02-12" 135 } 136 ... 137 138 # Inspect labels on container 139 $ docker inspect -f "{{json .Config.Labels }}" 4fa6e0f0c678 140 141 {"Vendor":"ACME Incorporated","com.example.is-beta":"","com.example.version":"0.0.1-beta","com.example.release-date":"2015-02-12"} 142 143 # Inspect labels on images 144 $ docker inspect -f "{{json .ContainerConfig.Labels }}" myimage 145 146 147 ## Query labels 148 149 Besides storing metadata, you can filter images and containers by label. To list all 150 running containers that have the `com.example.is-beta` label: 151 152 # List all running containers that have a `com.example.is-beta` label 153 $ docker ps --filter "label=com.example.is-beta" 154 155 List all running containers with the label `color` that have a value `blue`: 156 157 $ docker ps --filter "label=color=blue" 158 159 List all images with the label `vendor` that have the value `ACME`: 160 161 $ docker images --filter "label=vendor=ACME" 162 163 164 ## Container labels 165 166 docker run \ 167 -d \ 168 --label com.example.group="webservers" \ 169 --label com.example.environment="production" \ 170 busybox \ 171 top 172 173 Please refer to the [Query labels](#query-labels) section above for information 174 on how to query labels set on a container. 175 176 177 ## Daemon labels 178 179 docker daemon \ 180 --dns 8.8.8.8 \ 181 --dns 8.8.4.4 \ 182 -H unix:///var/run/docker.sock \ 183 --label com.example.environment="production" \ 184 --label com.example.storage="ssd" 185 186 These labels appear as part of the `docker info` output for the daemon: 187 188 $ docker -D info 189 Containers: 12 190 Images: 672 191 Server Version: 1.9.0 192 Storage Driver: aufs 193 Root Dir: /var/lib/docker/aufs 194 Backing Filesystem: extfs 195 Dirs: 697 196 Dirperm1 Supported: true 197 Execution Driver: native-0.2 198 Logging Driver: json-file 199 Kernel Version: 3.19.0-22-generic 200 Operating System: Ubuntu 15.04 201 CPUs: 24 202 Total Memory: 62.86 GiB 203 Name: docker 204 ID: I54V:OLXT:HVMM:TPKO:JPHQ:CQCD:JNLC:O3BZ:4ZVJ:43XJ:PFHZ:6N2S 205 Debug mode (server): true 206 File Descriptors: 59 207 Goroutines: 159 208 System Time: 2015-09-23T14:04:20.699842089+08:00 209 EventsListeners: 0 210 Init SHA1: 211 Init Path: /usr/bin/docker 212 Docker Root Dir: /var/lib/docker 213 Http Proxy: http://test:test@localhost:8080 214 Https Proxy: https://test:test@localhost:8080 215 WARNING: No swap limit support 216 Username: svendowideit 217 Registry: [https://index.docker.io/v1/] 218 Labels: 219 com.example.environment=production 220 com.example.storage=ssd