Menu
When I fetch a Docker image from a repository I see that it pulls a bunch of layers with some ids, but when I try to run them using docker run it tells me that it can't find it.
Can I run a certain layer of a Docker image that I can see through docker history < image_id >, like a paleontologist digging to find something interesting?
What I tried:
docker pull ruby Using default tag: latest latest: Pulling from library/ruby 693502eb7dfb: Already exists 081cd4bfd521: Already exists 5d2dc01312f3: Already exists 54a5f7da9a4f: Pulling fs layer 168cf3f33330: Pulling fs layer 021d84fef638: Pulling fs layer 168c3c107cd1: Waiting f001b782a027: Waiting Then:
docker run --rm -it 5d2dc01312f3 bash Unable to find image '5d2dc01312f3:latest' locally The question popped to me when I was pulling an image that I have build and published. I could see it clearly that one layer had almost 1.2 GB of size. It was the layer where I copied some files from the machine I used to build the image and on the next layer I cleaned and deleted some of those files as I was cleaning the image, but the total size of the image was about 1.5 GB which means that the big fat layer is of 1.2 GB is there. I just want to see if I can peek into that fat layer.
742
Docker images have intermediate layers that increase reusability, decrease disk usage, and speed up docker build by allowing each step to be cached. These intermediate layers are not shown by default. The SIZE is the cumulative space taken up by the image and all its parent images.
Hence, the major difference between a container and an image is the top writable layer. All writes to the container that add new or modify existing data are stored in this writable layer. When the container is deleted, the writable layer is also deleted. The underlying image remains unchanged.
Each layer stores the changes compared to the image it's based on. An image can consist of a single layer (that's often the case when the squash command was used). Each instruction in a Dockerfile results in a layer.
The second image contains all the layers from the first image, plus new layers created by the COPY and RUN instructions, and a read-write container layer. Docker already has all the layers from the first image, so it does not need to pull them again. The two images share any layers they have in common.
You can run an intermediate image of a Docker layer, which is probably what you want.
During your build you might need to inspect an image at certain point (step) in the build process e.g. in your Docker build output you'll see:
Step 17/30 : RUN rm -rf /some/directory ---> Running in 5ab963f2b48d Where 5ab963f2b48d is an image ID, and when you list your images, you'd see that ID in the list e.g.
$ docker image ls --all REPOSITORY TAG IMAGE ID CREATED SIZE <none> <none> 5ab963f2b48d 7 minutes ago 1.18GB To run that image (with a terminal) for example, you can simply:
docker run -i -t 5ab963f2b48d /bin/bash Also see: Run a Docker Image as a Container
189
No, you can not run a layer. You can only run an image. So it depends on whether there is an intermediate image associated with this layer or not!
Here is a typical scenario:
docker history <image-id> The digests you see when you pull the image are digests of the layers they are not intermediate images.
The value <missing> in the image column of docker history output means that there is no images associated to these layers. Hence there is nothing to run really.
The Docker daemon will not allow access to these layers unless the image was built on same docker host (or the Docker cache was distributed).
You can read more about layers at explaining-docker-image-ids.
21
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
