Nothing will be deleted that is required by the container to run and use the filesystem. Only some metadata and references to recognize the image itself.
Think of it as Git (not the same, but it is similar). It helps if you know Git and Docker because they have similar subcommands like commit, push, pull.
- When you pull an image from the registry you have an image tag which basically points to a filesystem layer (not directly). In addition to that, you will have some metadata, but that is not important now. This is similar to how Git uses a tag or branch name to point to a commit hash. Git will not garbage collect the commits (and previous commits) until you have a reference to that
- When you run a container, you will use the fileystem layers of the image but those layers are not writable from the container.
- Every layer has a folder that you could see from the host and also write it if you wanted to make the image unusable.
- Each layer contains different files and these layers together will give you a base filesystem which you can see as one root filesystem of a light weight Linux distribution.
- Your container will have its own writable layer and every time you want to change a file on the filesystem of the image, Docker will copy it to the layer of the container (just an other folder on the host) and change that version. You don’t see that because every layer on top of an other can hide files on the lower layers.
- When you delete a file, Docker (actually not Docker but the overlay2 storage driver) will save a special file which means that file with the same name on a lower layer is deleted.
- What you can see from the container is multiple folders mounted into the same destination folder.
So if you delete the metadata of an image, you will still have the filesystem, so the folders that the container uses and knows about. If you remove the container then you will have no way to tell which layers you need, but the container already knows that.
What I referred to as “image layer metadata” is the information that was saved when you built the image. Since building a container with multiple instructions in the Dockerfile means you run multiple containers and run
docker commit after each step, each instruction will create a file like that. When you run
docker image inspect you basically read the latest file.
The container also has a metadata file:
You can also find the container id as a name of an other folder in which there is a “parent-id” file which points to the parent layer:
If you search for the value in that file, you will find an other folder with that name but not under mounts, because this id is now the layer of the image:
I don’t want to continue this deep explanation, because it would be more complicated I can’t say I understand everything. The point is there are many references and you don’t need all of them for a container to work when you already started it.
If you can rebuild the image or get the previously built image export again, you can load it again on your server and that should fix the name too. If it does not give a name to the ID, you will at least have a complete image and you can add a tag manually using
docker tag <imageid> <imagename>