Docker Manifest – An Experimental Feature!
The image manifest provides a configuration and a set of layers for a container image.
This is an experimental feature. To enable this feature in the Docker CLI, one can edit the config.json file found in ~/.docker/config.json like :
Java
1
{
2
"auths": {
3
"https://index.docker.io/v1/": {
4
"auth": "XXXXXXX"
5
}
6
},
7
"HttpHeaders": {
8
"User-Agent": "Docker-Client/19.03.8 (linux)"
9
},
10
"experimental": "enabled",
11
"debug": true
12
}
What Is ‘Docker Manifest’?
The docker manifest command does not work independently to perform any action. In order to work with the docker manifest or manifest list, we use sub-commands along with it. This manifest sub-command can enable us to interact with the image manifests. Furthermore, it also gives information about the OS and the architecture, that a particular image was built for.
A single manifest comprises of information about an image, it’s size, the layers and digest.
A manifest list is a list of image layers (manifests) that are, created by specifying one or more image names. It can then be used in the same way as an image name in docker pull and docker run commands.
Commands to Get Started With:
After enabling this feature, one would be able to access the following command :
These commands are easy to use. It basically avoids the need for pulling and running and then testing the images locally, from a docker registry.
Next, to inspect an image manifest, follow this syntax,
docker manifest inspect image-name
As we can see, the image hello-world supports many different architectures.
As a result, it becomes very easy to identify the list of platforms that an image can run upon, without the need for ” pulling ” that image on that platform and then running it, to test if it supports such architecture or not.
Image Layers
In this section, we will be talking about the image layers, their architecture.Each of the files that make up a docker image is known as a layer.These layers form a series of intermediate images, built one on top of the other in stages, where each layer is dependent on the layer immediately below it.
The hierarchy in which the layers are organized is very important, the layers that change frequently should be placed as high up the hierarchy as possible. This helps in efficient management of a docker image’s life cycle.
This is because, when one makes changes to a layer in your image, docker not only rebuilds that particular layer but all layers built from it. Therefore a change to a layer at the top of the stack involves the least amount of computational work to rebuild the entire image. Thus the layers with the least or can be said with no changes are kept at the bottom of the hierarchy formed.
#devops #docker #ops
