Docker Images are the application binaries and dependencies for your app and the metadata on how to run them. They are ordered collections of root file system changes and execution parameters for use within a container run time.
The images are not complete operating systems. There are no kernels or kernel modules (like drivers). They only contain the binaries that your application needs to function, because the host operating system provides everything else.
https://docs.docker.com/engine/reference/commandline/image_ls/
To list all of the images available on your system to run containers off of:
docker image ls
https://docs.docker.com/engine/reference/commandline/image_pull/
To pull an image off of the docker hub repository:
docker image pull {image}
If it is not an official docker image, you will need to specify the owner of the repository before the image name as such: owner/image.
Most images tend to have different versions and platforms of the image available to you. They are differentiated by their tag. To specify a specific tag for an image, add a colon followed by the tag in the pull request:
docker image pull {user}/{image}:{tag}
Show the History of an Image
https://docs.docker.com/engine/reference/commandline/image_history/
To show the history of a specific image’s layers:
docker image history {image}
The image itself starts on the first layer (known as the scratch layer) and each change to the image creates a new layer on top of the first one in your image history.
Note: Do not be alarmed by the
<missing>value in the Image column. It simply means that the specified layer is not in itself, an image.
Essentially, the idea behind image cache is if you have a image of an operating system on your system, and you have two application images that use that one operating system. It would make more sense to have the OS on one layer, while your two apps are on another layer. That way you only need to store the system files for one OS at a time.
As you make changes to the images, they create new layers on top of the old ones. If you decide that you want to use the same image as the base image for more layers, then it is only ever storing one copy of each layer. Each layer contains only the changes (the differences) that were made to the base layer and will only be stored on the host once.
https://docs.docker.com/engine/reference/commandline/image_inspect/
To show detailed data (metadata) of one or more images:
docker image inspect {image}
Besides the basic identifier information for that image, the metadata also shows how the image is intended to be ran. This includes information such as
https://docs.docker.com/engine/reference/commandline/image_tag/
To assign or reassign a tag to an image:
docker image tag {source_image} {target_image}
If you are tagging an existing image, this will create a new image with same image id. Essentially, the {target_image} will become a new copy of the {source_image}. If you do not specify a tag after the {target_image}, the latest tag will be assigned by default. For official images, “latest” should always mean the latest stable release of that image.
https://docs.docker.com/engine/reference/commandline/image_push/
To push an image to the docker hub repository, make sure you are logged in and then use the push command:
docker login
docker image push {user}/{image}:{tag}
This will push only the changed layers of an image to your docker hub repository.
https://docs.docker.com/engine/reference/commandline/image_build/
To build an image from a Dockerfile:
docker image build {path}
This looks for a Dockerfile in the specified path and attempts to build it into an image.
If the file is not named Dockerfile, you can specify the correct file to build using the --file flag:
docker image build -f {path}/{file_name}
You can also give the new image a custom name and tag using the --tag flag:
docker image build -t {image}:{tag} {path}
Once you build an image from a Dockerfile, the layers of the image are saved to your image cache. If you make a change to the Dockerfile and build it, all of the unchanged values up to the “point of change” will pull form your image cache to build. All other values will have to be re-executed. This is why the order of the Dockerfile matters.
Note: To efficiently build a Dockerfile, keep the things that potentially change the least at the top of the file while keeping the things that change the most at the bottom.