github.com/vincentwoo/docker@v0.7.3-0.20160116130405-82401a4b13c0/docs/userguide/dockerimages.md (about) 1 <!--[metadata]> 2 +++ 3 title = "Build your own images" 4 description = "How to work with Docker images." 5 keywords = ["documentation, docs, the docker guide, docker guide, docker, docker platform, docker.io, Docker images, Docker image, image management, Docker repos, Docker repositories, docker, docker tag, docker tags, Docker Hub, collaboration"] 6 [menu.main] 7 parent = "smn_containers" 8 weight = -4 9 +++ 10 <![end-metadata]--> 11 12 # Build your own images 13 14 Docker images are the basis of containers. Each time you've used `docker run` 15 you told it which image you wanted. In the previous sections of the guide you 16 used Docker images that already exist, for example the `ubuntu` image and the 17 `training/webapp` image. 18 19 You also discovered that Docker stores downloaded images on the Docker host. If 20 an image isn't already present on the host then it'll be downloaded from a 21 registry: by default the [Docker Hub Registry](https://registry.hub.docker.com). 22 23 In this section you're going to explore Docker images a bit more 24 including: 25 26 * Managing and working with images locally on your Docker host. 27 * Creating basic images. 28 * Uploading images to [Docker Hub Registry](https://registry.hub.docker.com). 29 30 ## Listing images on the host 31 32 Let's start with listing the images you have locally on our host. You can 33 do this using the `docker images` command like so: 34 35 $ docker images 36 REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE 37 ubuntu 14.04 1d073211c498 3 days ago 187.9 MB 38 busybox latest 2c5ac3f849df 5 days ago 1.113 MB 39 training/webapp latest 54bb4e8718e8 5 months ago 348.7 MB 40 41 You can see the images you've previously used in the user guide. 42 Each has been downloaded from [Docker Hub](https://hub.docker.com) when you 43 launched a container using that image. When you list images, you get three crucial pieces of information in the listing. 44 45 * What repository they came from, for example `ubuntu`. 46 * The tags for each image, for example `14.04`. 47 * The image ID of each image. 48 49 > **Tip:** 50 > You can use [a third-party dockviz tool](https://github.com/justone/dockviz) 51 > or the [Image layers site](https://imagelayers.io/) to display 52 > visualizations of image data. 53 54 A repository potentially holds multiple variants of an image. In the case of 55 our `ubuntu` image you can see multiple variants covering Ubuntu 10.04, 12.04, 56 12.10, 13.04, 13.10 and 14.04. Each variant is identified by a tag and you can 57 refer to a tagged image like so: 58 59 ubuntu:14.04 60 61 So when you run a container you refer to a tagged image like so: 62 63 $ docker run -t -i ubuntu:14.04 /bin/bash 64 65 If instead you wanted to run an Ubuntu 12.04 image you'd use: 66 67 $ docker run -t -i ubuntu:12.04 /bin/bash 68 69 If you don't specify a variant, for example you just use `ubuntu`, then Docker 70 will default to using the `ubuntu:latest` image. 71 72 > **Tip:** 73 > You should always specify an image tag, for example `ubuntu:14.04`. 74 > That way, you always know exactly what variant of an image you are using. 75 > This is useful for troubleshooting and debugging. 76 77 ## Getting a new image 78 79 So how do you get new images? Well Docker will automatically download any image 80 you use that isn't already present on the Docker host. But this can potentially 81 add some time to the launch of a container. If you want to pre-load an image you 82 can download it using the `docker pull` command. Suppose you'd like to 83 download the `centos` image. 84 85 $ docker pull centos 86 Pulling repository centos 87 b7de3133ff98: Pulling dependent layers 88 5cc9e91966f7: Pulling fs layer 89 511136ea3c5a: Download complete 90 ef52fb1fe610: Download complete 91 . . . 92 93 Status: Downloaded newer image for centos 94 95 You can see that each layer of the image has been pulled down and now you 96 can run a container from this image and you won't have to wait to 97 download the image. 98 99 $ docker run -t -i centos /bin/bash 100 bash-4.1# 101 102 ## Finding images 103 104 One of the features of Docker is that a lot of people have created Docker 105 images for a variety of purposes. Many of these have been uploaded to 106 [Docker Hub](https://hub.docker.com). You can search these images on the 107 [Docker Hub](https://hub.docker.com) website. 108 109  110 111 You can also search for images on the command line using the `docker search` 112 command. Suppose your team wants an image with Ruby and Sinatra installed on 113 which to do our web application development. You can search for a suitable image 114 by using the `docker search` command to find all the images that contain the 115 term `sinatra`. 116 117 $ docker search sinatra 118 NAME DESCRIPTION STARS OFFICIAL AUTOMATED 119 training/sinatra Sinatra training image 0 [OK] 120 marceldegraaf/sinatra Sinatra test app 0 121 mattwarren/docker-sinatra-demo 0 [OK] 122 luisbebop/docker-sinatra-hello-world 0 [OK] 123 bmorearty/handson-sinatra handson-ruby + Sinatra for Hands on with D... 0 124 subwiz/sinatra 0 125 bmorearty/sinatra 0 126 . . . 127 128 You can see the command returns a lot of images that use the term `sinatra`. 129 You've received a list of image names, descriptions, Stars (which measure the 130 social popularity of images - if a user likes an image then they can "star" it), 131 and the Official and Automated build statuses. [Official 132 Repositories](https://docs.docker.com/docker-hub/official_repos) are a carefully 133 curated set of Docker repositories supported by Docker, Inc. Automated 134 repositories are [Automated Builds](dockerrepos.md#automated-builds) that allow 135 you to validate the source and content of an image. 136 137 You've reviewed the images available to use and you decided to use the 138 `training/sinatra` image. So far you've seen two types of images repositories, 139 images like `ubuntu`, which are called base or root images. These base images 140 are provided by Docker Inc and are built, validated and supported. These can be 141 identified by their single word names. 142 143 You've also seen user images, for example the `training/sinatra` image you've 144 chosen. A user image belongs to a member of the Docker community and is built 145 and maintained by them. You can identify user images as they are always 146 prefixed with the user name, here `training`, of the user that created them. 147 148 ## Pulling our image 149 150 You've identified a suitable image, `training/sinatra`, and now you can download it using the `docker pull` command. 151 152 $ docker pull training/sinatra 153 154 The team can now use this image by running their own containers. 155 156 $ docker run -t -i training/sinatra /bin/bash 157 root@a8cb6ce02d85:/# 158 159 ## Creating our own images 160 161 The team has found the `training/sinatra` image pretty useful but it's not quite 162 what they need and you need to make some changes to it. There are two ways you 163 can update and create images. 164 165 1. You can update a container created from an image and commit the results to an image. 166 2. You can use a `Dockerfile` to specify instructions to create an image. 167 168 169 ### Updating and committing an image 170 171 To update an image you first need to create a container from the image 172 you'd like to update. 173 174 $ docker run -t -i training/sinatra /bin/bash 175 root@0b2616b0e5a8:/# 176 177 > **Note:** 178 > Take note of the container ID that has been created, `0b2616b0e5a8`, as you'll 179 > need it in a moment. 180 181 Inside our running container let's add the `json` gem. 182 183 root@0b2616b0e5a8:/# gem install json 184 185 Once this has completed let's exit our container using the `exit` 186 command. 187 188 Now you have a container with the change you want to make. You can then 189 commit a copy of this container to an image using the `docker commit` 190 command. 191 192 $ docker commit -m "Added json gem" -a "Kate Smith" \ 193 0b2616b0e5a8 ouruser/sinatra:v2 194 4f177bd27a9ff0f6dc2a830403925b5360bfe0b93d476f7fc3231110e7f71b1c 195 196 Here you've used the `docker commit` command. You've specified two flags: `-m` 197 and `-a`. The `-m` flag allows us to specify a commit message, much like you 198 would with a commit on a version control system. The `-a` flag allows us to 199 specify an author for our update. 200 201 You've also specified the container you want to create this new image from, 202 `0b2616b0e5a8` (the ID you recorded earlier) and you've specified a target for 203 the image: 204 205 ouruser/sinatra:v2 206 207 Break this target down. It consists of a new user, `ouruser`, that you're 208 writing this image to. You've also specified the name of the image, here you're 209 keeping the original image name `sinatra`. Finally you're specifying a tag for 210 the image: `v2`. 211 212 You can then look at our new `ouruser/sinatra` image using the `docker images` 213 command. 214 215 $ docker images 216 REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE 217 training/sinatra latest 5bc342fa0b91 10 hours ago 446.7 MB 218 ouruser/sinatra v2 3c59e02ddd1a 10 hours ago 446.7 MB 219 ouruser/sinatra latest 5db5f8471261 10 hours ago 446.7 MB 220 221 To use our new image to create a container you can then: 222 223 $ docker run -t -i ouruser/sinatra:v2 /bin/bash 224 root@78e82f680994:/# 225 226 ### Building an image from a `Dockerfile` 227 228 Using the `docker commit` command is a pretty simple way of extending an image 229 but it's a bit cumbersome and it's not easy to share a development process for 230 images amongst a team. Instead you can use a new command, `docker build`, to 231 build new images from scratch. 232 233 To do this you create a `Dockerfile` that contains a set of instructions that 234 tell Docker how to build our image. 235 236 First, create a directory and a `Dockerfile`. 237 238 $ mkdir sinatra 239 $ cd sinatra 240 $ touch Dockerfile 241 242 If you are using Docker Machine on Windows, you may access your host 243 directory by `cd` to `/c/Users/your_user_name`. 244 245 Each instruction creates a new layer of the image. Try a simple example now for 246 building your own Sinatra image for your fictitious development team. 247 248 # This is a comment 249 FROM ubuntu:14.04 250 MAINTAINER Kate Smith <ksmith@example.com> 251 RUN apt-get update && apt-get install -y ruby ruby-dev 252 RUN gem install sinatra 253 254 Examine what your `Dockerfile` does. Each instruction prefixes a statement and 255 is capitalized. 256 257 INSTRUCTION statement 258 259 > **Note:** You use `#` to indicate a comment 260 261 The first instruction `FROM` tells Docker what the source of our image is, in 262 this case you're basing our new image on an Ubuntu 14.04 image. The instruction uses the `MAINTAINER` instruction to specify who maintains the new image. 263 264 Lastly, you've specified two `RUN` instructions. A `RUN` instruction executes 265 a command inside the image, for example installing a package. Here you're 266 updating our APT cache, installing Ruby and RubyGems and then installing the 267 Sinatra gem. 268 269 270 271 Now let's take our `Dockerfile` and use the `docker build` command to build an image. 272 273 $ docker build -t ouruser/sinatra:v2 . 274 Sending build context to Docker daemon 2.048 kB 275 Sending build context to Docker daemon 276 Step 1 : FROM ubuntu:14.04 277 ---> e54ca5efa2e9 278 Step 2 : MAINTAINER Kate Smith <ksmith@example.com> 279 ---> Using cache 280 ---> 851baf55332b 281 Step 3 : RUN apt-get update && apt-get install -y ruby ruby-dev 282 ---> Running in 3a2558904e9b 283 Selecting previously unselected package libasan0:amd64. 284 (Reading database ... 11518 files and directories currently installed.) 285 Preparing to unpack .../libasan0_4.8.2-19ubuntu1_amd64.deb ... 286 Unpacking libasan0:amd64 (4.8.2-19ubuntu1) ... 287 Selecting previously unselected package libatomic1:amd64. 288 Preparing to unpack .../libatomic1_4.8.2-19ubuntu1_amd64.deb ... 289 Unpacking libatomic1:amd64 (4.8.2-19ubuntu1) ... 290 Selecting previously unselected package libgmp10:amd64. 291 Preparing to unpack .../libgmp10_2%3a5.1.3+dfsg-1ubuntu1_amd64.deb ... 292 Unpacking libgmp10:amd64 (2:5.1.3+dfsg-1ubuntu1) ... 293 Selecting previously unselected package libisl10:amd64. 294 Preparing to unpack .../libisl10_0.12.2-1_amd64.deb ... 295 Unpacking libisl10:amd64 (0.12.2-1) ... 296 Selecting previously unselected package libcloog-isl4:amd64. 297 Preparing to unpack .../libcloog-isl4_0.18.2-1_amd64.deb ... 298 Unpacking libcloog-isl4:amd64 (0.18.2-1) ... 299 Selecting previously unselected package libgomp1:amd64. 300 Preparing to unpack .../libgomp1_4.8.2-19ubuntu1_amd64.deb ... 301 Unpacking libgomp1:amd64 (4.8.2-19ubuntu1) ... 302 Selecting previously unselected package libitm1:amd64. 303 Preparing to unpack .../libitm1_4.8.2-19ubuntu1_amd64.deb ... 304 Unpacking libitm1:amd64 (4.8.2-19ubuntu1) ... 305 Selecting previously unselected package libmpfr4:amd64. 306 Preparing to unpack .../libmpfr4_3.1.2-1_amd64.deb ... 307 Unpacking libmpfr4:amd64 (3.1.2-1) ... 308 Selecting previously unselected package libquadmath0:amd64. 309 Preparing to unpack .../libquadmath0_4.8.2-19ubuntu1_amd64.deb ... 310 Unpacking libquadmath0:amd64 (4.8.2-19ubuntu1) ... 311 Selecting previously unselected package libtsan0:amd64. 312 Preparing to unpack .../libtsan0_4.8.2-19ubuntu1_amd64.deb ... 313 Unpacking libtsan0:amd64 (4.8.2-19ubuntu1) ... 314 Selecting previously unselected package libyaml-0-2:amd64. 315 Preparing to unpack .../libyaml-0-2_0.1.4-3ubuntu3_amd64.deb ... 316 Unpacking libyaml-0-2:amd64 (0.1.4-3ubuntu3) ... 317 Selecting previously unselected package libmpc3:amd64. 318 Preparing to unpack .../libmpc3_1.0.1-1ubuntu1_amd64.deb ... 319 Unpacking libmpc3:amd64 (1.0.1-1ubuntu1) ... 320 Selecting previously unselected package openssl. 321 Preparing to unpack .../openssl_1.0.1f-1ubuntu2.4_amd64.deb ... 322 Unpacking openssl (1.0.1f-1ubuntu2.4) ... 323 Selecting previously unselected package ca-certificates. 324 Preparing to unpack .../ca-certificates_20130906ubuntu2_all.deb ... 325 Unpacking ca-certificates (20130906ubuntu2) ... 326 Selecting previously unselected package manpages. 327 Preparing to unpack .../manpages_3.54-1ubuntu1_all.deb ... 328 Unpacking manpages (3.54-1ubuntu1) ... 329 Selecting previously unselected package binutils. 330 Preparing to unpack .../binutils_2.24-5ubuntu3_amd64.deb ... 331 Unpacking binutils (2.24-5ubuntu3) ... 332 Selecting previously unselected package cpp-4.8. 333 Preparing to unpack .../cpp-4.8_4.8.2-19ubuntu1_amd64.deb ... 334 Unpacking cpp-4.8 (4.8.2-19ubuntu1) ... 335 Selecting previously unselected package cpp. 336 Preparing to unpack .../cpp_4%3a4.8.2-1ubuntu6_amd64.deb ... 337 Unpacking cpp (4:4.8.2-1ubuntu6) ... 338 Selecting previously unselected package libgcc-4.8-dev:amd64. 339 Preparing to unpack .../libgcc-4.8-dev_4.8.2-19ubuntu1_amd64.deb ... 340 Unpacking libgcc-4.8-dev:amd64 (4.8.2-19ubuntu1) ... 341 Selecting previously unselected package gcc-4.8. 342 Preparing to unpack .../gcc-4.8_4.8.2-19ubuntu1_amd64.deb ... 343 Unpacking gcc-4.8 (4.8.2-19ubuntu1) ... 344 Selecting previously unselected package gcc. 345 Preparing to unpack .../gcc_4%3a4.8.2-1ubuntu6_amd64.deb ... 346 Unpacking gcc (4:4.8.2-1ubuntu6) ... 347 Selecting previously unselected package libc-dev-bin. 348 Preparing to unpack .../libc-dev-bin_2.19-0ubuntu6_amd64.deb ... 349 Unpacking libc-dev-bin (2.19-0ubuntu6) ... 350 Selecting previously unselected package linux-libc-dev:amd64. 351 Preparing to unpack .../linux-libc-dev_3.13.0-30.55_amd64.deb ... 352 Unpacking linux-libc-dev:amd64 (3.13.0-30.55) ... 353 Selecting previously unselected package libc6-dev:amd64. 354 Preparing to unpack .../libc6-dev_2.19-0ubuntu6_amd64.deb ... 355 Unpacking libc6-dev:amd64 (2.19-0ubuntu6) ... 356 Selecting previously unselected package ruby. 357 Preparing to unpack .../ruby_1%3a1.9.3.4_all.deb ... 358 Unpacking ruby (1:1.9.3.4) ... 359 Selecting previously unselected package ruby1.9.1. 360 Preparing to unpack .../ruby1.9.1_1.9.3.484-2ubuntu1_amd64.deb ... 361 Unpacking ruby1.9.1 (1.9.3.484-2ubuntu1) ... 362 Selecting previously unselected package libruby1.9.1. 363 Preparing to unpack .../libruby1.9.1_1.9.3.484-2ubuntu1_amd64.deb ... 364 Unpacking libruby1.9.1 (1.9.3.484-2ubuntu1) ... 365 Selecting previously unselected package manpages-dev. 366 Preparing to unpack .../manpages-dev_3.54-1ubuntu1_all.deb ... 367 Unpacking manpages-dev (3.54-1ubuntu1) ... 368 Selecting previously unselected package ruby1.9.1-dev. 369 Preparing to unpack .../ruby1.9.1-dev_1.9.3.484-2ubuntu1_amd64.deb ... 370 Unpacking ruby1.9.1-dev (1.9.3.484-2ubuntu1) ... 371 Selecting previously unselected package ruby-dev. 372 Preparing to unpack .../ruby-dev_1%3a1.9.3.4_all.deb ... 373 Unpacking ruby-dev (1:1.9.3.4) ... 374 Setting up libasan0:amd64 (4.8.2-19ubuntu1) ... 375 Setting up libatomic1:amd64 (4.8.2-19ubuntu1) ... 376 Setting up libgmp10:amd64 (2:5.1.3+dfsg-1ubuntu1) ... 377 Setting up libisl10:amd64 (0.12.2-1) ... 378 Setting up libcloog-isl4:amd64 (0.18.2-1) ... 379 Setting up libgomp1:amd64 (4.8.2-19ubuntu1) ... 380 Setting up libitm1:amd64 (4.8.2-19ubuntu1) ... 381 Setting up libmpfr4:amd64 (3.1.2-1) ... 382 Setting up libquadmath0:amd64 (4.8.2-19ubuntu1) ... 383 Setting up libtsan0:amd64 (4.8.2-19ubuntu1) ... 384 Setting up libyaml-0-2:amd64 (0.1.4-3ubuntu3) ... 385 Setting up libmpc3:amd64 (1.0.1-1ubuntu1) ... 386 Setting up openssl (1.0.1f-1ubuntu2.4) ... 387 Setting up ca-certificates (20130906ubuntu2) ... 388 debconf: unable to initialize frontend: Dialog 389 debconf: (TERM is not set, so the dialog frontend is not usable.) 390 debconf: falling back to frontend: Readline 391 debconf: unable to initialize frontend: Readline 392 debconf: (This frontend requires a controlling tty.) 393 debconf: falling back to frontend: Teletype 394 Setting up manpages (3.54-1ubuntu1) ... 395 Setting up binutils (2.24-5ubuntu3) ... 396 Setting up cpp-4.8 (4.8.2-19ubuntu1) ... 397 Setting up cpp (4:4.8.2-1ubuntu6) ... 398 Setting up libgcc-4.8-dev:amd64 (4.8.2-19ubuntu1) ... 399 Setting up gcc-4.8 (4.8.2-19ubuntu1) ... 400 Setting up gcc (4:4.8.2-1ubuntu6) ... 401 Setting up libc-dev-bin (2.19-0ubuntu6) ... 402 Setting up linux-libc-dev:amd64 (3.13.0-30.55) ... 403 Setting up libc6-dev:amd64 (2.19-0ubuntu6) ... 404 Setting up manpages-dev (3.54-1ubuntu1) ... 405 Setting up libruby1.9.1 (1.9.3.484-2ubuntu1) ... 406 Setting up ruby1.9.1-dev (1.9.3.484-2ubuntu1) ... 407 Setting up ruby-dev (1:1.9.3.4) ... 408 Setting up ruby (1:1.9.3.4) ... 409 Setting up ruby1.9.1 (1.9.3.484-2ubuntu1) ... 410 Processing triggers for libc-bin (2.19-0ubuntu6) ... 411 Processing triggers for ca-certificates (20130906ubuntu2) ... 412 Updating certificates in /etc/ssl/certs... 164 added, 0 removed; done. 413 Running hooks in /etc/ca-certificates/update.d....done. 414 ---> c55c31703134 415 Removing intermediate container 3a2558904e9b 416 Step 4 : RUN gem install sinatra 417 ---> Running in 6b81cb6313e5 418 unable to convert "\xC3" to UTF-8 in conversion from ASCII-8BIT to UTF-8 to US-ASCII for README.rdoc, skipping 419 unable to convert "\xC3" to UTF-8 in conversion from ASCII-8BIT to UTF-8 to US-ASCII for README.rdoc, skipping 420 Successfully installed rack-1.5.2 421 Successfully installed tilt-1.4.1 422 Successfully installed rack-protection-1.5.3 423 Successfully installed sinatra-1.4.5 424 4 gems installed 425 Installing ri documentation for rack-1.5.2... 426 Installing ri documentation for tilt-1.4.1... 427 Installing ri documentation for rack-protection-1.5.3... 428 Installing ri documentation for sinatra-1.4.5... 429 Installing RDoc documentation for rack-1.5.2... 430 Installing RDoc documentation for tilt-1.4.1... 431 Installing RDoc documentation for rack-protection-1.5.3... 432 Installing RDoc documentation for sinatra-1.4.5... 433 ---> 97feabe5d2ed 434 Removing intermediate container 6b81cb6313e5 435 Successfully built 97feabe5d2ed 436 437 You've specified our `docker build` command and used the `-t` flag to identify 438 our new image as belonging to the user `ouruser`, the repository name `sinatra` 439 and given it the tag `v2`. 440 441 You've also specified the location of our `Dockerfile` using the `.` to 442 indicate a `Dockerfile` in the current directory. 443 444 > **Note:** 445 > You can also specify a path to a `Dockerfile`. 446 447 Now you can see the build process at work. The first thing Docker does is 448 upload the build context: basically the contents of the directory you're 449 building in. This is done because the Docker daemon does the actual 450 build of the image and it needs the local context to do it. 451 452 Next you can see each instruction in the `Dockerfile` being executed 453 step-by-step. You can see that each step creates a new container, runs 454 the instruction inside that container and then commits that change - 455 just like the `docker commit` work flow you saw earlier. When all the 456 instructions have executed you're left with the `97feabe5d2ed` image 457 (also helpfully tagged as `ouruser/sinatra:v2`) and all intermediate 458 containers will get removed to clean things up. 459 460 > **Note:** 461 > An image can't have more than 127 layers regardless of the storage driver. 462 > This limitation is set globally to encourage optimization of the overall 463 > size of images. 464 465 You can then create a container from our new image. 466 467 $ docker run -t -i ouruser/sinatra:v2 /bin/bash 468 root@8196968dac35:/# 469 470 > **Note:** 471 > This is just a brief introduction to creating images. We've 472 > skipped a whole bunch of other instructions that you can use. We'll see more of 473 > those instructions in later sections of the Guide or you can refer to the 474 > [`Dockerfile`](../reference/builder.md) reference for a 475 > detailed description and examples of every instruction. 476 > To help you write a clear, readable, maintainable `Dockerfile`, we've also 477 > written a [`Dockerfile` Best Practices guide](../articles/dockerfile_best-practices.md). 478 479 480 ## Setting tags on an image 481 482 You can also add a tag to an existing image after you commit or build it. We 483 can do this using the `docker tag` command. Now, add a new tag to your 484 `ouruser/sinatra` image. 485 486 $ docker tag 5db5f8471261 ouruser/sinatra:devel 487 488 The `docker tag` command takes the ID of the image, here `5db5f8471261`, and our 489 user name, the repository name and the new tag. 490 491 Now, see your new tag using the `docker images` command. 492 493 $ docker images ouruser/sinatra 494 REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE 495 ouruser/sinatra latest 5db5f8471261 11 hours ago 446.7 MB 496 ouruser/sinatra devel 5db5f8471261 11 hours ago 446.7 MB 497 ouruser/sinatra v2 5db5f8471261 11 hours ago 446.7 MB 498 499 ## Image Digests 500 501 Images that use the v2 or later format have a content-addressable identifier 502 called a `digest`. As long as the input used to generate the image is 503 unchanged, the digest value is predictable. To list image digest values, use 504 the `--digests` flag: 505 506 $ docker images --digests | head 507 REPOSITORY TAG DIGEST IMAGE ID CREATED VIRTUAL SIZE 508 ouruser/sinatra latest sha256:cbbf2f9a99b47fc460d422812b6a5adff7dfee951d8fa2e4a98caa0382cfbdbf 5db5f8471261 11 hours ago 446.7 MB 509 510 When pushing or pulling to a 2.0 registry, the `push` or `pull` command 511 output includes the image digest. You can `pull` using a digest value. 512 513 $ docker pull ouruser/sinatra@sha256:cbbf2f9a99b47fc460d422812b6a5adff7dfee951d8fa2e4a98caa0382cfbdbf 514 515 You can also reference by digest in `create`, `run`, and `rmi` commands, as well as the 516 `FROM` image reference in a Dockerfile. 517 518 ## Push an image to Docker Hub 519 520 Once you've built or created a new image you can push it to [Docker 521 Hub](https://hub.docker.com) using the `docker push` command. This 522 allows you to share it with others, either publicly, or push it into [a 523 private repository](https://registry.hub.docker.com/plans/). 524 525 $ docker push ouruser/sinatra 526 The push refers to a repository [ouruser/sinatra] (len: 1) 527 Sending image list 528 Pushing repository ouruser/sinatra (3 tags) 529 . . . 530 531 ## Remove an image from the host 532 533 You can also remove images on your Docker host in a way [similar to 534 containers](usingdocker.md) using the `docker rmi` command. 535 536 Delete the `training/sinatra` image as you don't need it anymore. 537 538 $ docker rmi training/sinatra 539 Untagged: training/sinatra:latest 540 Deleted: 5bc342fa0b91cabf65246837015197eecfa24b2213ed6a51a8974ae250fedd8d 541 Deleted: ed0fffdcdae5eb2c3a55549857a8be7fc8bc4241fb19ad714364cbfd7a56b22f 542 Deleted: 5c58979d73ae448df5af1d8142436d81116187a7633082650549c52c3a2418f0 543 544 > **Note:** To remove an image from the host, please make sure 545 > that there are no containers actively based on it. 546 547 # Next steps 548 549 Until now you've seen how to build individual applications inside Docker 550 containers. Now learn how to build whole application stacks with Docker 551 by networking together multiple Docker containers. 552 553 Go to [Network containers](networkingcontainers.md).