Menu
I use docker inspect to get the image information. I find there are Config and ContainerConfig in the output, and most value are the same, except the CMD.
In practice, the Config take effect. For I must add cmd in the run command. $ docker run -it debian bash
I wonder what is the difference of the two items?
$ docker inspect debian [ { "Id": "7abab0fd74f97b6b398a1aca68735c5be153d49922952f67e8696a2225e1d8e1", ...... "ContainerConfig": { "Hostname": "e5c68db50333", "Domainname": "", "User": "", "AttachStdin": false, "AttachStdout": false, "AttachStderr": false, "Tty": false, "OpenStdin": false, "StdinOnce": false, "Env": null, "Cmd": [ "/bin/sh", "-c", "#(nop) CMD [\"/bin/bash\"]" ], "Image": "d8bd0657b25f17eef81a3d52b53da5bda4de0cf5cca3dcafec277634ae4b38fb", "Volumes": null, "WorkingDir": "", "Entrypoint": null, "OnBuild": null, "Labels": {} }, "Config": { "Hostname": "e5c68db50333", "Domainname": "", "User": "", "AttachStdin": false, "AttachStdout": false, "AttachStderr": false, "Tty": false, "OpenStdin": false, "StdinOnce": false, "Env": null, "Cmd": [ "/bin/bash" ], "Image": "d8bd0657b25f17eef81a3d52b53da5bda4de0cf5cca3dcafec277634ae4b38fb", "Volumes": null, "WorkingDir": "", "Entrypoint": null, "OnBuild": null, "Labels": {} }, ...... } ] 
975
Docker swarm service configs allow you to store non-sensitive information, such as configuration files, outside a service's image or running containers. This allows you to keep your images as generic as possible, without the need to bind-mount configuration files into the containers or use environment variables.
Docker inspect provides detailed information on constructs controlled by Docker. By default, docker inspect will render results in a JSON array.
docker inspect is a command that returns detailed, low-level information on Docker objects. Those objects can be docker images, containers, networks, volumes, plugins, etc.
The config. json file stores a JSON encoding of several properties: The HttpHeaders property specifies a set of headers to include in all messages sent from the Docker client to the daemon. Docker does not try to interpret or understand these header; it simply puts them into the messages.
As mentioned in issue 18880, regarding ContainerConfig:
What you're seeing there is related to the history of how the image was created.
Try runningdocker history ...on your image and you'll see the complete history.
Docker will place theDockerfilecommands into theCMDsection as a way of keeping track of how that layer/container was created.
Its really only used for cache-lookup purposes (internal docker processing) and not meant to be used by the user.
It is also visible in image/image.go as:
// ContainerConfig is the configuration of the container that is committed into the image ContainerConfig container.Config `json:"container_config,omitempty"` For instance, issue 17780 illustrates an empty ContainerConfig:
The ContainerConfig of an image is the container the image was generated from.
In the case of your image, it wasn't generated from a container, but from runningdocker import.
183
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
