Differences

This shows you the differences between two versions of the page.

--- docker:docker_images_vs._container [2016/10/15 10:29] – peter
+++ docker:docker_images_vs._container [2020/07/15 09:30] (current) – external edit 127.0.0.1
@@ Line 2: / Line 2: @@
 Docker has images and containers.  The two are closely related, but distinct.
+----
 ===== Docker Images =====
-An image is an inert, immutable, file that's essentially a snapshot of a container.  Images are created with the **[[http://docs.docker.com/reference/commandline/cli/#build|build]]** command, and they'll produce a container when started with **[[https://docs.docker.com/reference/run/|run]]**.  Images are stored in a Docker registry such as **[[https://registry.hub.docker.com/|registry.hub.docker.com]]**.  Because they can become quite large, images are designed to be composed of layers of other images, allowing a miminal amount of data to be sent when transferring images over the network.
+Images are basically a template used to create containers.
-Local images can be listed by running docker images:
+  * An image is an inert, immutable, file that's essentially a snapshot of a container.
+  * Images are created with the **[[http://docs.docker.com/reference/commandline/cli/#build|build]]** command, and they'll produce a container when started with **[[https://docs.docker.com/reference/run/|run]]**.
+  * Images are stored in a Docker registry such as **[[https://registry.hub.docker.com/|registry.hub.docker.com]]**.
+  * Because they can become quite large, images are designed to be composed of layers of other images, allowing a minimal amount of data to be sent when transferring images over the network.
-<code>
+Local images can be listed by running:
+<code bash>
+docker images
+</code>
+returns:
+<code bash>
 REPOSITORY                TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
 ubuntu                    13.10               5e019ab7bf6d        2 months ago        180 MB
@@ Line 22: / Line 35: @@
   * **IMAGE ID** is the first 12 characters of the true identifier for an image. You can create many tags of a given image, but their IDs will all be the same (as above).
   * **VIRTUAL SIZE** is virtual because its adding up the sizes of all the distinct underlying layers.  This means that the sum of all the values in that column is probably much larger than the disk space used by all of those images.
-  * The value in the REPOSITORY column comes from the -t flag of the docker build command, or from docker tag-ing an existing image.  You're free to tag images using a nomenclature that makes sense to you, but know that docker will use the tag as the registry location in a docker push or docker pull.
+  * The value in the **REPOSITORY** column comes from the -t flag of the docker build command, or from docker tag-ing an existing image.  You're free to tag images using a nomenclature that makes sense to you, but know that docker will use the tag as the registry location in a docker push or docker pull.
-  * The full form of a tag is [REGISTRYHOST/][USERNAME/]NAME[:TAG].  For ubuntu above, REGISTRYHOST is inferred to be registry.hub.docker.com.  So if you plan on storing your image called my-application in a registry at docker.example.com, you should tag that image docker.example.com/my-application.
+  * The full form of a tag is [REGISTRYHOST/][USERNAME/]NAME[:TAG].  For ubuntu above, **REGISTRYHOST** is inferred to be registry.hub.docker.com.  So if you plan on storing your image called my-application in a registry at docker.example.com, you should tag that image docker.example.com/my-application.
-  * The TAG column is just the [:TAG] part of the full tag. This is unfortunate terminology.
+  * The **TAG** column is just the [:TAG] part of the full tag. This is unfortunate terminology.
   * The latest tag is not magical, it's simply the default tag when you don't specify a tag.
-  * You can have untagged images only identifiable by their IMAGE IDs.  These will get the <none> TAG and REPOSITORY.  It's easy to forget about them.
+  * You can have untagged images only identifiable by their **IMAGE ID**s.  These will get the <none> **TAG** and **REPOSITORY**.  It's easy to forget about them.
 More info on images is available from the [[https://docs.docker.com/terms/image/|Docker docs]].
+----
 ===== Docker Containers =====
-To use a programming metaphor, if an image is a class, then a container is an instance of a class—a runtime object.  Containers are hopefully why you're using Docker; they're lightweight and portable encapsulations of an environment in which to run applications.
+To use a programming metaphor, if an image is a class, then a container is an instance of a class — a runtime object.
-View local running containers with **docker ps**:
+Containers are hopefully why you're using Docker; they're lightweight and portable encapsulations of an environment in which to run applications.
-<code>
+View local running containers by running:
+<code bash>
+docker ps
+</code>
+returns:
+<code bash>
 CONTAINER ID        IMAGE                               COMMAND                CREATED             STATUS              PORTS                    NAMES
 f2ff1af05450        samalba/docker-registry:latest      /bin/sh -c 'exec doc   4 months ago        Up 12 weeks         0.0.0.0:5000->5000/tcp   docker-registry
@@ Line 44: / Line 66: @@
 Here I'm running a dockerized version of the docker registry, so that I have a private place to store my images.  Again, some things to note:
-  - Like IMAGE ID, CONTAINER ID is the true identifier for the container.  It has the same form, but it identifies a different kind of object.
+  - Like **IMAGE ID**, **CONTAINER ID** is the true identifier for the container.  It has the same form, but it identifies a different kind of object.
   - docker ps only outputs running containers.  You can view stopped containers with **docker ps -a**.
-  - NAMES can be used to identify a started container via the **--name** flag.
+  - **NAMES** can be used to identify a started container via the **<nowiki>--name</nowiki>** flag.
+----
 ===== How to avoid image and container build-up =====
-One of my early frustrations with Docker was the seemingly constant build-up of untagged images and stopped containers. On a handful of occasions this build-up resulted in maxed out hard drives slowing down my laptop or halting my automated build pipeline.  Talk about "containers everywhere"!
+There's a constant build-up of untagged images and stopped containers which could lead to a maxed out hard drive.
 We can remove all untagged images by combining **docker rmi** with the recent **dangling=true** query:
@@ Line 65: / Line 88: @@
 </code>
-These are known pain points with Docker, and may be addressed in future releases.  However, with a clear understanding of images and containers, these situations can be avoided with a couple of practices:
+These are known pain points with Docker, and may be addressed in future releases.
-  - Always remove a useless, stopped container with docker rm [CONTAINER_ID].
+However, with a clear understanding of images and containers, these situations can be avoided with a couple of practices:
-  - Always remove the image behind a useless, stopped container with docker rmi [IMAGE_ID].
+  - Always remove a useless, stopped container with **docker rm [CONTAINER_ID]**.
+  - Always remove the image behind a useless, stopped container with **docker rmi [IMAGE_ID]**.