如何删除docker中的目录？(How to remove a directory in docker?)

似乎docker容器中的rm -rf仅适用于文件。

docker run ubuntu /bin/bash -c 'sudo rm -rf ./mydir; ls'

它列出了目录中的mydir而没有打印任何错误。

我使用ubuntu 14.04作为主机和图像。

编辑：

我认为在我将另一个文件添加到目录后出现了错误，但我错了。 最后，更改存储驱动程序有助于解决问题。

It seems that rm -rf in docker container works only with files.

docker run ubuntu /bin/bash -c 'sudo rm -rf ./mydir; ls'

it lists mydir among directories without printing any errors.

I use ubuntu 14.04 for host and image.

EDIT:

I thought that the bug appeared after I had added another file to the directory, but I was mistaken. Finally, changing storage driver helped to solve the issue.

最满意答案

当你似乎无法删除目录时，这里有两种可能：

用户在图像和容器之间的混淆。 每个docker run都会创建一个新容器，容器中的任何更改（如删除目录或运行修改文件系统的内容）都会与原始映像和所有其他容器隔离。 Aufs分层错误/功能 。 查看docker info以查看您是否正在使用存储驱动程序aufs或imagemapper。 要重新安装docker以使用imagemapper：将任何不可替代的唯一映像备份到tar文件，删除docker.io，按照官方安装文档中的说明从ppa安装lxc-docker，并将/etc/default/docker DOCKER_OPTS="--storage-driver=devicemapper"更改为包含DOCKER_OPTS="--storage-driver=devicemapper"

它也可能是一个反模式来提交目录然后删除它们，因为那些数据可能仍然存在于某处。 即使它从文件系统中消失，它仍然可能在内部浪费空间。

Docker镜像是按层构建的，每个提交都是一个层。 要查看此内容，请尝试使用docker history <image>查看图像中的内容。

第一种情况是值得一个简短的例子，但看起来你可能正在经历第二种情况。

图像与容器和删除目录

让我们从ubuntu:14.04创建一个名为mystuff的私有映像ubuntu:14.04 ，稍后，尝试使用rm -rf / opt：

$ docker run -it ubuntu:14.04 /bin/bash root@435e68479c5b:/# ls bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var root@435e68479c5b:/# exit $ docker commit 435e6 mystuff

让我们看看里面（ -t仅用于在一行上进行漂亮打印）：

docker run -t mystuff ls bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var

现在让我们尝试删除/opt （通常这是可选的东西，可以安全删除）：

docker run -t mystuff rm -rf /opt

然后在里面寻找它，它仍然存在！ （似乎报告的问题）：

docker run -t mystuff ls bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var

发生了什么？

每次使用docker run mystuff ，它都会从图像mystuff创建一个新容器 除非您使用docker commit，否则不会提交对映像的更改

如果您查看容器，则会发生以下更改：

docker ps -a ... lots of stuff... e9e8be13d928 mystuff:latest "rm -rf /opt" 2 minutes ago Exited (0) 2 minutes ago nostalgic_archimedes

得到一个tarball并寻找选择，grep it for dir以opt开头，它不存在！：

docker export e9e8 | tar tv | grep ^opt

注意： e9e8特别适用于我的这个例子。 要引用容器，可以在第一个col中使用docker ps中的部分十六进制字符串。

现在我将具有rm -rf更改的容器提交到新映像noopt ：

docker commit e9e8 noopt

并查看从noopt创建的容器：

docker run -t noopt ls bin boot dev etc home lib lib64 media mnt proc root run sbin srv sys tmp usr var

果然，选择已经消失了！

但是因为docker图像是分层的，所以分发noopt会包含/ opt in一个早期的历史图像，所以你不能阻止其他人收回它：

docker history noopt IMAGE CREATED CREATED BY SIZE bc4e69f9e871 59 minutes ago rm -rf /opt 0 B d198d23dab38 About an hour ago /bin/bash 3 B 04c5d3b7b065 9 days ago /bin/sh -c #(nop) CMD [/bin/bash] 0 B d735006ad9c1 9 days ago /bin/sh -c sed -i 's/^#\s*\(deb.*universe\)$/ 1.895 kB 70c8faa62a44 9 days ago /bin/sh -c echo '#!/bin/sh' > /usr/sbin/polic 194.5 kB c7b7c6419568 9 days ago /bin/sh -c #(nop) ADD file:d4aab24fc178303dc0 192.5 MB 511136ea3c5a 18 months ago 0 B

要在删除/ opt之前返回到图层，我们只需要选择d198d ...并运行它

docker run -t d198d23dab38 ls bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var

概要：

Docker有容器和图像。 图像旨在更持久。 图像是在称为提交的层中创建的，在概念上类似于git存储库 容器是从映像创建的，容器中的更改不会保留在映像中（除非显式提交）

Docker还有一个很棒的构建系统，应该在这里使用。 编写该脚本的人应该学习docker docker build并编写适当的Dockerfile

When you can't seem to remove a directory, here are two possibilities:

User confusion between images and containers. Each docker run creates a new container, and any changes in containers, like removing a directory, or running something that modifies the file system, are isolated from the original image, and all other containers. Aufs layering bug/feature. Look at docker info to see if you are using Storage Driver aufs or imagemapper. To reinstall docker to use imagemapper: backup any irreplaceable, unique images to tar files, remove docker.io, install lxc-docker from the ppa as described in the official install docs and change /etc/default/docker to contain DOCKER_OPTS="--storage-driver=devicemapper"

It is also probably an anti-pattern to commit directories and then remove them because that data may still be in there somewhere. Even if it disappears from the file system, it could still be wasting space internally.

Docker images are built in layers, each commit is a layer. To see this, try docker history <image> to see what is in your image.

The first case is deserving of a short, simple example, but it looks like you are possibly experiencing the second case.

Images vs. Containers and removing directories

Let's create a private image called mystuff from ubuntu:14.04 and, later below, try to rm -rf /opt:

$ docker run -it ubuntu:14.04 /bin/bash root@435e68479c5b:/# ls bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var root@435e68479c5b:/# exit $ docker commit 435e6 mystuff

Let's look inside (-t is only used here for pretty printing on one line):

docker run -t mystuff ls bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var

Now let's try to remove /opt (usually that is optional stuff, safe to remove):

docker run -t mystuff rm -rf /opt

And then look inside for it, and it is still there!!! (seems like the reported problem):

docker run -t mystuff ls bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var

What happened?

each time docker run mystuff is used, it makes a new container from the image mystuff Changes to the image are not committed unless you use docker commit

If you look in the container, the changes are there:

docker ps -a ... lots of stuff... e9e8be13d928 mystuff:latest "rm -rf /opt" 2 minutes ago Exited (0) 2 minutes ago nostalgic_archimedes

Get a tarball out and look for opt, grep it for dir beginning with opt, it isn't there!:

docker export e9e8 | tar tv | grep ^opt

Note: e9e8 is particular to my run of this example. To refer to a container, you can use part of the hex string from docker ps in the first col.

Now I commit the container that has the rm -rf change into a new image noopt:

docker commit e9e8 noopt

And look inside a container created from noopt:

docker run -t noopt ls bin boot dev etc home lib lib64 media mnt proc root run sbin srv sys tmp usr var

And sure enough, opt is gone!

But because docker images are in layers, distributing noopt will include /opt in an earlier historical image, so you can't keep other people from getting it back:

docker history noopt IMAGE CREATED CREATED BY SIZE bc4e69f9e871 59 minutes ago rm -rf /opt 0 B d198d23dab38 About an hour ago /bin/bash 3 B 04c5d3b7b065 9 days ago /bin/sh -c #(nop) CMD [/bin/bash] 0 B d735006ad9c1 9 days ago /bin/sh -c sed -i 's/^#\s*\(deb.*universe\)$/ 1.895 kB 70c8faa62a44 9 days ago /bin/sh -c echo '#!/bin/sh' > /usr/sbin/polic 194.5 kB c7b7c6419568 9 days ago /bin/sh -c #(nop) ADD file:d4aab24fc178303dc0 192.5 MB 511136ea3c5a 18 months ago 0 B

To get back to the layer before /opt was removed, we just need to pick out d198d... and run it

docker run -t d198d23dab38 ls bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var

Summary:

Docker has containers and images. Images are intended to be more permanent. Images are created in layers called commits, similar in concept to git repositories Containers are created from images, and changes in containers are not kept in images (unless explicitly committed)

Docker also has a great build system that should have been used here. Whoever wrote that script should instead learn about docker build and write a proper Dockerfile