github.com/walkingsparrow/docker@v1.4.2-0.20151218153551-b708a2249bfa/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