Open katsar0v opened 6 years ago
The overlay2 storage driver can at maximum have 125 layers, so I suspect that that's what you're running into (error message is defined here; https://github.com/moby/moby/blob/8e610b2b55bfd1bfa9436ab110d311f5e8a74dcb/layer/layer.go#L53)
First of all, I would recommend trying to optimize your images / Dockerfile, as mounting this many layers can affect performance (it will take longer to start the container, as all layers have to be mounted, and modifying files inside the container may be less performant)
We should document this though, and (if possible) make the error message more clear.
/ cc @dmcgowan @ahh-docker
Yes, would be good if the error is documented and explained why. I could have one script as well installing and set everything in 10 steps, instead of 125 layers, but layers have cache and etc.. are more useful. I find this 125 layer limitation stupid, maybe because I don't understand it and it is not documented
@thaJeztah can you please file me at documentation issue for this in docker.github.io? Thanks.
I would recommend trying to optimize your images / Dockerfile, as mounting this many layers can affect performance
@thaJeztah I was not aware of that drawback. it is the same if we split the content in several Dockerfiles that inherits using the FROM directive? Or is it the total amont of layers?
It's the total amount of layers; note that not every step in a Dockerfile creates a new layer, only (RUN
) steps that modify the filesystem will introduce a new layer, and (depending on your use-case) you can reduce the number of layers in the final image with multi-stage builds by (e.g.) copying artefacts from intermediate stages to the final stage.
If I'm not mistaken, the current limit of 125 layers is due to the kernel's ARG_MAX
, which limits the number of arguments / length of arguments that can be passed when mounting the layers (this limit can be raised in kernels, but is not something that could be relied on as it would make those images non-interoperable on systems that don't have the custom configuration)
Thanks. I have to read about multi-stage builds.
My question was more about the performance impact at runtime. Do you have references about that? If so, I would probably rewrite in order to put everything in a bash script and execute it in one single RUN command.
if it is the case, about the performance impact, I really think now it became a bad design. Instead of creating a layer on each RUN command, I think they shall be treated like a bash command, and let the user decide when to "snapshot" a layer. ie with a SNAPSHOT or LAYER command ;-)
1
Expected behavior
Build image
Actual behavior
Error
max depth exceeded
Steps to reproduce the behavior
I am building an image, which inherits from another image, which inherits from a third image. I get this error, which is not documented at all? Is there any documentation / info about this?
Output of
docker version
:Output of
docker info
: