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