{"id":15284,"date":"2016-11-21T12:15:04","date_gmt":"2016-11-21T10:15:04","guid":{"rendered":"https:\/\/www.webcodegeeks.com\/?p=15284"},"modified":"2016-11-18T17:20:31","modified_gmt":"2016-11-18T15:20:31","slug":"container-image-immutability-power-metadata","status":"publish","type":"post","link":"https:\/\/www.webcodegeeks.com\/devops\/container-image-immutability-power-metadata\/","title":{"rendered":"Container Image Immutability and the Power of Metadata"},"content":{"rendered":"

One of the principles of Docker containers is that an image is immutable \u2014 once built, it\u2019s unchangeable, and if you want to make changes, you\u2019ll get a new image as a result. In this post, we\u2019ll take a deep dive into the immutability of containers, and then we\u2019ll look at some of the consequences and potential problems, as well as see how applying some metadata to your container images can really help.<\/p>\n

Not got time for the details? TL;DR: use LABEL<\/code> to add meaningful metadata to your container images, and you\u2019ll thank yourself in months to come!<\/p><\/blockquote>\n

Container Images and Immutability<\/h2>\n

You can modify a container, and you can create a new container image by \u201ccommitting\u201d the state of that container. But when you do that, you create a new image. The previous image is untouched. Let\u2019s see how we do that with Docker.<\/p>\n

I\u2019m going to use an image called lizrice\/imagetest<\/code>, which is a very simple image based on Alpine that I\u2019ve been using for metadata experiments. Feel free to use your own image if you prefer. For this example, I inspect my image as follows:<\/p>\n

$ docker inspect lizrice\/imagetest<\/pre>\n
The first line in the output is the identifier: a unique hash for this particular image that looks something like this:<\/p>\n
\"Id\": \"sha256:e9ea81af1e8d197fb083cc05e8d722233c0c4aab83deabc54adccd8a225a8b29\"<\/pre>\n
This is the full-length hash. You\u2019ll see that it matches the prefix that\u2019s displayed if you run Docker images to list the images you have locally.<\/p>\n
Now let\u2019s create a container based on that image. In my example, I happen to not have a CMD directive in the Dockerfile. So I need to specify a command to run (even though it won\u2019t get run at this point).<\/p>\n
$ docker create lizrice\/imagetest touch \/nothing_to_see_here<\/pre>\n
The docker create<\/code> command makes the container but doesn\u2019t start it yet, so it won\u2019t actually run the touch<\/code> command yet. Eventually when we do run the container, the touch<\/code> command will make a change to the file system of the container by creating a file called nothing_to_see_here<\/code>. We\u2019ll come to that very soon, but first let\u2019s take a look at the container and its status.<\/p>\n
Because the container isn\u2019t running yet, we\u2019ll need the -a<\/code> flag to see it included in docker ps<\/code>:<\/p>\n
$ docker ps -a\r\n    CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS                     PORTS               NAMES\r\n    306f4ba7c68a        lizrice\/imagetest   \"touch \/nothing_to_se\"   5 minutes ago       Exited (0) 3 minutes ago                       grave_almeida<\/pre>\n
As you can see, the container is in Created status; it\u2019s ready to run, but it\u2019s not actually running yet. We can inspect it at this stage.<\/p>\n
$ docker inspect 306f4ba7c68a<\/pre>\n
This generates quite a bit of output, including the image that this container is based on. As expected, you should see this is exactly the same identifier SHA that we saw as the ID of the container image:<\/p>\n
\"Image\": \"sha256:e9ea81af1e8d197fb083cc05e8d722233c0c4aab83deabc54adccd8a225a8b29\"<\/pre>\n
Now let\u2019s start the container. This is the point at which that touch<\/code> command will get run.<\/p>\n
$ docker start grave_almeida<\/pre>\n
The container starts up, runs the touch<\/code> command, and then exits. We can see the change that this made on the file system by running docker diff<\/code>.<\/p>\n
$ docker diff grave_almeida\r\nA \/nothing_to_see_here<\/pre>\n
If we inspect the container, we can see that it\u2019s still based on the same image ID (the one beginning with e9ea81<\/em>). If we want to save this as a container image, we can do this with docker commit<\/code>.<\/p>\n
$ docker commit grave_almeida\r\nsha256:8b76eee48c6c1e9373d321c99c8bbd80bb3f606c848d639280cce3395073807f<\/pre>\n
The SHA that has been output is the identifier for a new container image, which we can see included in the list of container images. We haven\u2019t modified our original image in any way.<\/p>\n
$ docker images\r\n    REPOSITORY                             TAG                    IMAGE ID            CREATED             SIZE\r\n    <none>                                 <none>                 8b76eee48c6c        7 seconds ago       4.805 MB\r\n    lizrice\/imagetest                      latest                 e9ea81af1e8d        About an hour ago   4.805 MB<\/pre>\n
The new image doesn\u2019t have any repository or tag information associated with it. We can use the docker tag<\/code> command to add this, but let\u2019s say, for the sake of argument, that we got distracted and forgot to do that.<\/p>\n
Working Out What the Image Is<\/h2>\n
If you\u2019ve been working with Docker for more than about ten minutes, you\u2019ll know how quickly you can build up containers and container images. You might even be surprised by how many you have sitting on your machine if you run docker ps -a<\/code> (to list all the containers) and docker images<\/code>. And you might well find a fair few with those rather stark <none><\/code> entries for repo and tag.<\/p>\n
If you haven\u2019t tagged those images with a repo name, how on earth can you find out what code is inside them? As we\u2019ve seen, you can inspect an image to get its ID, but unless you have a list of what the image IDs are, how useful is that?<\/p>\n
Labels to the rescue<\/h3>\n
One solution, and a good practice in general, is to use Labels<\/a>. Labels are simply key-value pairs that can be applied to images at build time or added when you start a container. You can use them to add meaningful metadata that can be invaluable in managing your containers and metadata.<\/p>\n
I\u2019m one of the authors of a community initiative called Label Schema<\/a>, which offers some conventions for the keys to use in your labels. As I write, there are over 500 public images whose maintainers have already adopted these conventions<\/a>.<\/p>\n
The most basic of labels that can help us with our image identification problem is to give the image a name with the following line in the Dockerfile:<\/p>\n
LABEL org.label-schema.name=\u2019imagetest\u2019<\/pre>\n
This means that my image will be built including this key-value pair, which I can see as part of the inspection process.<\/p>\n
$ docker inspect lizrice\/imagetest \r\n               \"Labels\": {\r\n                    \"org.label-schema.name\": \"imagetest\"\r\n                }<\/pre>\n
How does this help?<\/h3>\n
Labels are inherited from ancestor images. So when you do a Docker commit as we did earlier, any labels from the original image will also exist in the new one. Inspect that new image, or a container based on that image, you\u2019ll see the same labels have been inherited.<\/p>\n
Labels are also inherited from the base image specified in the FROM directive in a Dockerfile. You can see this in action by using MicroBadger<\/a> to look at the metadata from my example image lizrice\/childimage<\/code>.<\/p>\n
\"screen-shot-2016-11-11-at-15-45-17\"<\/a><\/p>\n
You can see this (experimental!) image has three labels:<\/p>\n