"htmlcode">

"htmlcode">

{"id":"37dd4150474449629e8a7b576eed26cb8583d2fe5a3edf10fd84323dfd538678","parent":"5cf74bcb1bde2e2249824a682f45235954543a5d57081db22c96402342db49e9","created":"2017-04-06T16:28:35.51523979Z","container_config":{"Hostname":"","Domainname":"","User":"","Memory":0,"MemorySwap":0,"CpuShares":0,"Cpuset":"","AttachStdin":false,"AttachStdout":false,"AttachStderr":false,"PortSpecs":null,"ExposedPorts":null,"Tty":false,"OpenStdin":false,"StdinOnce":false,"Env":null,"Cmd":["/bin/sh -c set -e; \u0009NGINX_GPGKEY=573BFD6B3D8FBC641079A6ABABF5BD827BD9BF62; \u0009found=''; \u0009for server in \u0009\u0009ha.pool.sks-keyservers.net \u0009\u0009hkp://keyserver.ubuntu.com:80 \u0009\u0009hkp://p80.pool.sks-keyservers.net:80 \u0009\u0009pgp.mit.edu \u0009; do \u0009\u0009echo \"Fetching GPG key $NGINX_GPGKEY from $server\"; \u0009\u0009apt-key adv --keyserver \"$server\" --keyserver-options timeout=10 --recv-keys \"$NGINX_GPGKEY\" \u0026\u0026 found=yes \u0026\u0026 break; \u0009done; \u0009test -z \"$found\" \u0026\u0026 echo \u003e\u00262 \"error: failed to fetch GPG key $NGINX_GPGKEY\" \u0026\u0026 exit 1; \u0009exit 0"],"Image":"","Volumes":null,"WorkingDir":"","Entrypoint":null,"NetworkDisabled":false,"MacAddress":"","OnBuild":null,"Labels":null},"author":"NGINX Docker Maintainers \"docker-maint@nginx.com\"","Size":4901}


最后做一个总结：:镜像是一种中间镜像，我们可以使用`docker images -a`来看到，他们不会造成硬盘空间占用的问题（因为这是镜像的父层，必须存在的），但是会给我们的判断带来迷惑。
无效的 none 镜像
另一种类型的 < none>:< none> 镜像是dangling images ，这种类型会造成磁盘空间占用问题。
像Java和Golang这种编程语言都有一个内存区，这个内存区不会关联任何的代码。这些语言的垃圾回收系统优先回收这块区域的空间，将他返回给堆内存，所以这块内存区对于之后的内存分配是有用的
docker的悬挂(dangling)文件系统与上面的原理类似，他是没有被使用到的并且不会关联任何镜像，因此我们需要一种机制去清理这些悬空镜像。
我们在上文已经提到了有效的< none>镜像，他们是一种中间层，那无效的< none>镜像又是怎么出现的？这些 dangling镜像主要是我们触发 docker build 和 docker pull命令产生的。
用一个例子来讲解：
假设我们要构建一个新的镜像，Dockerfile 文件如下


FORM Ubuntu:latest
RUN echo 'hello world'


当我们构建 docker build -t hello-world ./ 的时候，会生成一个新的镜像。
可是过了一个月之后，Ubuntu发布了新的镜像，这个时候我们再次构建一个 hello world镜像，会依赖于最新的 Ubuntu
问题来了，我们引用旧的Ubuntu的hello-world镜像，这个时候就会成为没有标签的 dangling镜像！使用下面的命令可以清理


docker rmi $(docker images -f "dangling=true" -q)


docker没有自动垃圾回收处理机制，未来可能会有这方面的改进，但是目前我们只能这样手动清理（写个脚本就好）。
删除本地硬盘的镜像


当我们registry服务器存在很多tag标签的镜像，但是硬盘空间不够用的时候，我们会希望删除存量的镜像给服务器腾出空间，registry自带了API接口删除镜像，但是即使我们调用了，他也只是逻辑层面的删除，软删除（soft delete），只是把二进制和镜像的关系解除罢了，实际上镜像一直存在我们的硬盘中，我们需要一种方式彻底物理删除存量空间。网上有第三方的解决方案：delete-docker-registry-image,接下来列出操作步骤，操作之前先把 registry服务停掉。
安装:


curl https://raw.githubusercontent.com/burnettk/delete-docker-registry-image/master/delete_docker_registry_image.py | sudo tee /usr/local/bin/delete_docker_registry_image >/dev/null
sudo chmod a+x /usr/local/bin/delete_docker_registry_image


设置环境变量：数据存放地址:
我服务器上registry的配置如下：


 volumes:
 - /root/docker-data/registry/data:/var/lib/registry




root@iZ94ft8hgzqZ:~/docker-data/registry/data/docker/registry/v2/repositories# ls -al
total 108
drwxr-xr-x 27 root root 4096 Aug 21 18:29 .
drwxr-xr-x 4 root root 4096 Oct 30 2015 ..
drwxr-xr-x 5 root root 4096 Mar 27 2016 example
drwxr-xr-x 5 root root 4096 Mar 20 19:25 gitlab_ansible
drwxr-xr-x 5 root root 4096 Mar 22 2016 hlpays-job
drwxr-xr-x 5 root root 4096 Jan 26 2016 hlpays-oa
drwxr-xr-x 5 root root 4096 Mar 24 2016 hlpays-portal
drwxr-xr-x 5 root root 4096 Mar 27 18:32 ifex-crm




export REGISTRY_DATA_DIR=/root/docker-data/registry/data/docker/registry/v2


逻辑删除:
delete_docker_registry_image –image tickets –dry-run ; 只是逻辑删除，没什么用，演示一下而已。。。


root@iZ94ft8hgzqZ:~/docker-data/registry/data/docker/registry/v2/repositories# delete_docker_registry_image --image tickets --dry-run


INFO [2017-09-13 18:21:04,505] DRY_RUN: would have deleted /root/docker-data/registry/data/docker/registry/v2/blobs/sha256/27/27dedd9200ff607e76eb9d0e10beb103f53551e4ed39829d767cfbc208b79581
INFO [2017-09-13 18:21:04,506] DRY_RUN: would have deleted /root/docker-data/registry/data/docker/registry/v2/blobs/sha256/1b/1b2aade332a7133b1a03cae7695a3dcf9413dd017ff41f35a1bb1506becbacf3


物理数据删除:
删除物理内存，能看到硬盘空间已经空出来了。


delete_docker_registry_image --image tickets

df -h 


删除指定标签:


delete_docker_registry_image --image testrepo/awesomeimage:supertag


其他用法请参照官网
总结
以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，如果有疑问大家可以留言交流，谢谢大家对的支持。