Docker Images vs. Containers
IMAGE :- An image is an inert, immutable, file that’s essentially a snapshot of a container. Images are created with the build command, and they’ll produce a container when started with run. Images are stored in a Docker registry such as 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.
-tflag of the
docker buildcommand, 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
ubuntuabove, REGISTRYHOST is inferred to be
registry.hub.docker.com. So if you plan on storing your image called
my-applicationin a registry at
docker.example.com, you should tag that image
latesttag is not magical, it’s simply the default tag when you don’t specify a tag.
<none>TAG and REPOSITORY. It’s easy to forget about them.
CONTAINER :- 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.
- 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 psonly outputs running containers. You can view stopped containers with
docker ps -a.
- NAMES can be used to identify a started container via the