Solución:
Cuando parece que no puede eliminar un directorio, aquí hay dos posibilidades:
-
Confusión del usuario entre imágenes y contenedores. Cada
docker run
crea un nuevo contenedor y cualquier cambio en los contenedores, como eliminar un directorio o ejecutar algo que modifique el sistema de archivos, se aísla de la imagen original y de todos los demás contenedores. -
Aufs error / característica de capas. Mirar
docker info
para ver si está utilizando Storage Driver aufs o imagemapper. Para reinstalar docker para usar imagemapper: haga una copia de seguridad de las imágenes únicas e irremplazables en archivos tar, elimine docker.io, instale lxc-docker desde el ppa como se describe en los documentos oficiales de instalación y cambie/etc/default/docker
contenerDOCKER_OPTS="--storage-driver=devicemapper"
También es probable que sea un antipatrón confirmar directorios y luego eliminarlos porque es posible que esos datos todavía estén allí en algún lugar. Incluso si desaparece del sistema de archivos, aún podría estar desperdiciando espacio internamente.
Las imágenes de Docker se crean en capas, cada confirmación es una capa.
Para ver esto, intente docker history <image>
para ver lo que hay en tu imagen.
El primer caso merece un ejemplo breve y sencillo, pero parece que posiblemente esté experimentando el segundo caso.
Imágenes frente a contenedores y eliminación de directorios
Creemos una imagen privada llamada mystuff
de ubuntu:14.04
y, más adelante, intente rm -rf / opt:
$ docker run -it ubuntu:14.04 /bin/bash
[email protected]:/# ls
bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var
[email protected]:/# exit
$ docker commit 435e6 mystuff
Miremos adentro-t
solo se usa aquí para impresiones bonitas en una línea):
docker run -t mystuff ls
bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var
Ahora intentemos eliminar /opt
(por lo general, son cosas opcionales, seguras de eliminar):
docker run -t mystuff rm -rf /opt
¡Y luego mire adentro en busca de él, y todavía está allí! (parece el problema informado):
docker run -t mystuff ls
bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var
¿Qué sucedió?
- cada vez
docker run mystuff
se usa, hace un contenedor nuevo de la imagenmystuff
- Los cambios en la imagen no se confirman a menos que use docker commit
Si miras en el contenedor, los cambios están ahí:
docker ps -a
... lots of stuff...
e9e8be13d928 mystuff:latest "rm -rf /opt" 2 minutes ago Exited (0) 2 minutes ago nostalgic_archimedes
Obtenga un tarball y busque opt, grep para dir comenzando con opt, ¡no está ahí !:
docker export e9e8 | tar tv | grep ^opt
Nota: e9e8
es particular para mi ejecución de este ejemplo. Para hacer referencia a un contenedor, puede utilizar parte de la cadena hexadecimal de docker ps
en la primera col.
Ahora confirmo el contenedor que tiene el cambio rm -rf en una nueva imagen noopt
:
docker commit e9e8 noopt
Y mire dentro de un contenedor creado a partir de noopt:
docker run -t noopt ls
bin boot dev etc home lib lib64 media mnt proc root run sbin srv sys tmp usr var
Y, efectivamente, ¡opt se ha ido!
Pero debido a que las imágenes de la ventana acoplable están en capas, la distribución de noopt incluirá / optará por una imagen histórica anterior, por lo que no puede evitar que otras personas la recuperen:
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
Para volver a la capa anterior a la eliminación de / opt, solo tenemos que seleccionar d198d … y ejecutarlo
docker run -t d198d23dab38 ls
bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var
Resumen:
- Docker tiene contenedores e imágenes.
- Las imágenes están destinadas a ser más permanentes.
- Las imágenes se crean en capas llamadas comete, similar en concepto a los repositorios de git
- Los contenedores se crean a partir de imágenes y los cambios en los contenedores no se guardan en imágenes (a menos que se comprometan explícitamente)
Docker también tiene un gran sistema de compilación que debería haberse utilizado aquí. Quienquiera que haya escrito ese guión debería aprender docker build
y escribe un Dockerfile adecuado