I downloaded a Docker image and made some changes inside a container based on it. Then I commited those changes to create a new image that I would actually like to use.
docker images says that these images have about the same size. So, it seemed to me that Docker copied everything it needs to the new image.
Yet I can't remove the old image which I no longer need. It seems like I'm getting the worst of both worlds: neither is space conserved by a parenting relationship, nor can I delete the unwanted files.
What gives? Am I interpreting docker images output wrong (maybe it's not reporting the actual on-disk size)?
you may remove the first image with a force,
docker image rm -f $IMAGE_ID
As for the same size, it depends mainly on your changes, you can check if they match exactly on a byte level with:
docker image inspect IMAGE_NAME:$TAG --format='{{.Size}}'
Related
We are doing an artifactory cleanup, removing Docker images from our docker repo.
I understand from the article over https://jfrog.com/knowledge-base/how-can-i-delete-docker-images-older-than-a-certain-time-period
that if a layer is shared between two different images, and if only one is a candidate for deletion, then that layer will not be deleted from the binary storage.
Our policy is on deleting some specific tag versions (that are not used in production) and now we have some queries based on the above article
Is there a possibility that we will end up with partially deleted images (corrupted images). Say some of the layers of the image we are trying to delete is referenced by some other image, would layers be partially deleted, leaving us with a corrupted image which could be be pulled, but then result in failure??
You are correct, if the layer is referenced by another tag, then it will not be deleted.
The worst that can happen is that you will leave a tag behind that points to a non-existent image.
I was looking at my disk with DaisyDisk and I have a 30GB something called Docker.qcow2. More specifically, DaisyDisk puts it under ~/Library/Containers/com.docker.docker/Data/vms/0/Docker.qcow2. Is it some kind of cache? Can I delete it? I have a lot of images from old projects that I won't ever use and I'm trying to clear up my disk.
The .qcow2 file is exposed to the VM as a block device with a maximum size of 64GiB by default. As new files are created in the filesystem by containers, new sectors are written to the block device. These new sectors are appended to the .qcow2 file causing it to grow in size, until it eventually becomes fully allocated. It stops growing when it hits this maximum size.
You can stop Docker and delete this file, however deleting it will also remove all your containers and images. And Docker will recreate this file on start.
If you stumbled upon this, you're probably not stoked about a 64gb file. If you open up Docker > Preferences, you can tone it down quite a bit to a more reasonable size. Doing this will delete the old cow file, and that will delete your containers, so be careful.
I've had the same issue. Instead of deleting the file or adjusting the size using the settings simply use the following commands:
docker images
This will show all of the images on your system and the size of each image (you'd be surprised how quickly this can get out of hand).
docker image rm IMAGEID
This will remove the image with the ID that you can get from the images command above.
I use this method and it frees up a lot of disk space.
I'm experiencing the same problem as found here:
mkdir .ssh in a Dockerfile, folder is not there?
I'm wondering if there is a way for my dockerfile to remove a volume declared by its parent?
My reasoning for this is that; the volume was declared to mount to an external database, the image I'm creating is for testing purposes and contains the data present for the volume internally. Ideally I don't want to have to populate this in my entry point as it's an expensive operation.
See also How to remove configure volumes in docker images
Actually I did have a very similar use case in using an image from production that would be modified for testing. The only chance is to modify the metadata of the parent image. As I need to that regulary, I have created a little script for that, have a look at docker-copyedit if that can help you.
Is there any way to know what is in a public image other than downloading it and checking it out manually?
e.g. I can see on dockerhub various java images and a various ansible images, I would have to download quite a lot to determine which one to use and if any had both
The dockerfile lists some info but often there is inheritance and so you can't see all the info.
Is there anything that lists all the contained packages or an online service that lets you try them out without downloading the whole image?
MicroBadger lists the docker history of a Docker image and shows matching base images (with their layers as well). E.g. https://microbadger.com/images/ansible/ansible
Since v2.4.0 a garbage collector command is included within the registry binary. I read about how it works in the official documentation.
To use the garbage-collection:
bin/registry garbage-collect [--dry-run] /path/to/config.yml
I see the config in /etc/docker/registry/config.yml
When I just perform a dry-run I see a lot of blobs marked and at the end the blobs which would have been deleted without dry-run.
But I don't see how I can easily link this blobs to images?
Which images will be deleted and am I able to tell which image should be deleted or do I need to use another command and after that I have to run the gc?)
Can someone maybe provide an example in which case an image/blob will be deleted? Thanks
From your referenced documentation:
In the context of the Docker registry, garbage collection is the process of removing blobs from the filesystem which are no longer referenced by a manifest. Blobs can include both layers and manifests.
Manifests are groups of blobs (layers) used to represent an image tag. The only blobs deleted no longer reference any image. So to answer your question, if GC is working correctly, no one should be able to give an example of this deleting an image, but every useful GC should delete blobs, including your own.