What's benefit of docker's image layer?
I’m new to Docker. Based on reading some Docker documentation, I plan to convert my project to Docker image as the following design:
My project has the follow natures:
- The base OS almost never need to update unless big OS issue, thus say update base OS every 2 years.
- The base libraries might be updated only 6 months.
- Libraries are updated every month.
- Project code are updated once a day.
Thus I plan to create 4 images:
- image1 – base os
- image2 – from image1 and add base libraries
- image3 – from image2 and add libraries
- image4 – from image3 and add project code
My understanding is, image4 has 4 layers. Once I build a new image4, Docker only needs to pull layer4, because layer 1,2,3 are same as the old image4. Since my project code is just some text scripts, thus layer4 should be very small, thus pull a new image4 should be very fast.
Is my understanding correct?
One Solution collect form web for “What's benefit of docker's image layer?”
Since my project code is just some text scripts, thus layer4 should be very small
Layer4 will be small, but pulling image4 will be fast only if one has already pulled image 1 to 3 before.
And the resulting image4 won’t be small, but the result of the concatenation of the 3 base images.
Plus, the term “layer” should not mask the fact that each line in a docker file will create an intermediate image, making the actual image a collection of all those intermediate small layers (resulting from the execution of each Dockerfile command).
You might have 4 “general” layers, but the actual image is likely to be composed of more than 4 layers.
You can check that with imagelayers.io
I use an alias to cleanup old dangling images:
alias drmiad='docker rmi $(docker images --filter "dangling=true" -q --no-trunc)'
My build script usually include:
. ../.bash_aliases docker build -t sshd . || exit 1 drmiad 2> /dev/null