Soy nuevo en el mundo de Docker y estoy tratando de lograr algo que uno podría pensar que es trivial. Sin embargo, parece que muchos principiantes luchan por conservar sus datos cuando usan Docker.
He creado una imagen personalizada usando un Dockerfile . El contenedor ejecuta un servidor MySQL y... sí, lo adivinó: me gustaría conservar los datos .
Aquí está mi Dockerfile:
FROM debian:8.7 ENV MYSQL_ROOT_PASSWORD=test RUN apt-get update -y && apt-get install -y apt-utils && \ echo "mysql-server mysql-server/root_password password $MYSQL_ROOT_PASSWORD" | debconf-set-selections && \ echo "mysql-server mysql-server/root_password_again password $MYSQL_ROOT_PASSWORD" | debconf-set-selections && \ apt-get install -y mysql-server mysql-client && service mysql start CMD service mysql start && /bin/bash VOLUME /var/lib/mysql EXPOSE 3306Construyo y ejecuto la imagen de esta manera:
docker build -t mysql-persist-test:0.1 . docker run -dt -v database_volume:/var/lib/mysql mysql-persist-test:0.1Hasta ahora, todo funciona como se esperaba, incluida la base de datos.
Sin embargo, digamos que quiero recuperar los datos en mi máquina host (Windows 10, instalé Docker a través de Docker Toolbox ).
" Enlazo " una carpeta local al volumen nombrado con Kitematic (ver más abajo), el contenedor se reinicia automáticamente y... ¡todo está roto! Se eliminaron todos los archivos del directorio /var/lib/mysql . Algunos fueron recreados con el staff del propietario en lugar de mysql .
Entonces tengo estos errores en /var/log/mysql/error.log :
... /usr/sbin/mysqld: Table 'mysql.plugin' doesn't exist 170328 16:03:13 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it. ... 170328 16:03:13 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. ... 170328 16:03:13 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed ... 170328 16:03:14 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.host' doesn't exist¿Qué estoy haciendo mal?
Los datos en contenedores están en una especie de jerarquía. Dice así.
Este es el nivel más bajo, donde los datos están en la imagen inmutable de solo lectura.
Una vez que inicia un contenedor a partir de una imagen, se agrega una capa de lectura y escritura encima de las capas de imagen existentes. Si se cambia, agrega o elimina algo en el contenedor, por defecto se escribe aquí.
Los cambios en esta capa anulan los datos de la capa 1.
En su ejemplo, ha creado un volumen en Docker, con
VOLUME /var/lib/mysql Esto creará un volumen dentro de Docker, que se puede reutilizar, conservar, compartir entre contenedores, etc. Si había algo en /var/lib/mysql en la capa 1, entonces el contenido de este volumen se anula. Si realiza cambios en el contenedor, se realizan en el volumen (saltándose la capa 2).
Finalmente, tenemos directorios externos que puedes montar dentro del contenedor. Esto anula todos los demás.
Dado que se basan en un directorio externo, se podrá acceder fácilmente desde el exterior a cualquier cambio realizado en el contenedor. Es de suponer que por eso intentaste este enfoque.
Comenzó con un volumen Docker (nivel 3) y luego cambió a un volumen externo (nivel 4). Dado que el nivel 4 anula el nivel 3, lo que sucede es que el contenido de su directorio externo (probablemente sin contenido), anula el volumen de Docker. Por lo tanto, el contenedor solo ve un directorio vacío.
Sus archivos todavía están allí. Simplemente deshaga el montaje externo y vuelva al volumen de Docker; estarán esperando allí.
EDITAR : como Carlos señala en los comentarios, docker cp es más simple, editando para usar ese enfoque en su lugar.
docker cp <container-id>:/var/lib/mysql ./mydata Esto copiará el contenido de /var/lib/mysql en la carpeta mydata .