‫Todo bien. Los volúmenes parecen bastante simples desde el principio, pero en realidad hay mucho que hacer.
‫La primera forma de decirle a un contenedor que necesita preocuparse por un volumen es en un archivo Docker.
‫Vamos a ver algunos de ellos.
‫Voy a hacer lo que hago mucho.
‫Voy a buscar MySQL.
‫Así es como aprendí mucho sobre Dockerfiles, y cómo usarlos correctamente, es que los repositorios oficiales tienen
‫muy buenos valores predeterminados y las mejores prácticas incorporadas en ellos.
‫Cuando vaya a MySQL uno, voy a hacer clic en el último archivo Docker aquí. probablemente tenga un comando de volumen.
‫Te apuesto porque es una base de datos,
‫Aquí vamos.
‫Esta es la ubicación predeterminada de las bases de datos MySQL. Esta imagen está programada para decirle a Docker
‫que cuando comencemos un nuevo contenedor desde allí, realmente cree una nueva ubicación de volumen
‫y asígnela a este directorio en el contenedor. Lo que significa que cualquier archivo que coloquemos allí, en el
‫contenedor, sobrevivirá al contenedor hasta que eliminemos manualmente el volumen.
‫Y eso es algo que debemos señalar aquí es que los volúmenes necesitan borrado manual.
‫No puedes limpiarlos simplemente quitando un contenedor.
‫Son un paso extra. Eso es solo para el seguro en realidad, porque el objetivo
‫de un comando de volumen es decir que esta información es particularmente importante, al menos mucho más importante que el contenedor en sí.
‫Si hacemos un docker tirando de MySQL, y luego
‫hago una inspección de la imagen de Docker en MySQL, no vemos el archivo Docker porque el archivo Docker no
‫es realmente parte de los metadatos de la imagen, que notará en este área de configuración, que
‫especificó ese volumen allí.
‫Siempre puedo decir que la configuración, que vino del archivo Docker cuando se creó, asignó un volumen
‫a esa ruta.
‫Vamos a ejecutar un contenedor desde allí.
‫Entonces contenedor acoplador run -d --name mysql.
‫Si recuerda desde antes, el MySQL es poco especial.
‫Ahora requiere una variable de
‫entorno antes de que funcione.
‫Es MYSQL_ALLOW_EMPTY_PASSWORD.
‫DE ACUERDO.
‫Lo que ves es MySQL ejecutándose. la configuración que hay un volumen.
‫Si hacemos un contenedor docker inspecciona mysql, deberíamos ver lo mismo donde nos dice en
‫Aquí.
‫También podemos verlo aquí debajo de las monturas. Lo que es esto, es realmente el contenedor en funcionamiento que obtiene su
‫propia ubicación única en el host, para almacenar esos datos, y luego está en segundo plano, mapeado o montado, en esa ubicación del contenedor, de modo que
‫la ubicación en el contenedor en realidad solo piensa que está escribiendo en
‫/ var / lib / mysql.
‫En este caso, podemos ver que los datos realmente están viviendo en esa ubicación en el host. docker, y podemos ver que
‫ahora tenemos un volumen.
‫Así que hagamos un volumen Ahora notamos que tiene una ID única que nunca
‫sabremos qué diablos va,
‫¿verdad?
‫Entonces, hagamos una inspección sobre eso.
‫No tiene que escribir todo.
‫Puede escribir los primeros dos caracteres y presionar Tab para completarlo. Obtendrá esa información similar
‫sobre el volumen en sí.
‫en una máquina Linux, puede navegar a esa ubicación en su disco duro y ver los datos.
‫Si realmente está haciendo esto
‫En realidad, habrá algunas bases de datos allí.
‫Si está en una Mac o Windows, recuerde que Docker para Windows y Docker para Mac están
‫haciendo un poco de fondo que está oculto para nosotros en donde está creando una máquina virtual Linux.
‫Entonces, esta información está técnicamente dentro de esa VM de Linux. No podrá ir a esa ruta en su máquina
‫Windows o Mac y ver los datos. En realidad está dentro de esa máquina virtual.
‫Veremos en un momento, con volúmenes montados, cómo podemos superar esa limitación también.
‫fácil de usar en términos de decirnos qué contiene o a qué se asigna este volumen.
‫Al observar esto, observa que no es muy
‫Podemos ver desde la perspectiva del contenedor qué volumen está usando, pero no podemos ver desde el punto de vista
‫del volumen con qué está conectado.
‫¿Derecha?
‫Si solo tuviera que presionar la flecha hacia arriba y, a ver, crear un mysql2.
‫Ahora se creó otro servidor MySQL ejecutándose en segundo plano.
‫Si hago otro volumen docker, verá dos de ellos.
‫Comienzas a ver el problema, ¿verdad?
‫Aquí no hay una manera muy fácil de distinguir uno de otro.
‫Si solo, para demostrar un punto, hacemos un contenedor docker stop mysql, y un docker un contenedor
‫detiene mysql2.
‫Hacemos un contenedor docker ls, no veremos ningún contenedor en ejecución. Si hacemos un ls -a,
‫podemos verlos a todos. Y note que están detenidos. Y luego hacemos un volumen docker ls,
‫nota que todavía tenemos los dos volúmenes.
‫Si hago un contenedor docker rm mysql, y luego mysql2, porque puedo hacer ambas cosas
‫en un solo comando, eliminará ambos contenedores. un volumen docker ls, mis volúmenes siguen ahí.
‫Si ahora hago Mis datos aún están seguros.
‫Entonces, hemos resuelto un problema.
‫Las bases de datos sobreviven al ejecutable.
‫¿Cómo hacemos esto un poco más amigable para el usuario?
‫Ahí es donde entran los volúmenes nombrados y la capacidad de especificar cosas en el comando de
‫ejecución del acoplador.
‫Si toco la flecha hacia arriba un par de veces hasta que llegue al contenedor contenedor, realmente no importa
‫cuál vas a ejecutar nuevamente.
‫En este caso, vamos a lanzar un comando -v. A -v nos permite especificar un nuevo volumen que
‫queremos crear para este contenedor que está a punto de ejecutarse, o nos permite otras
‫dos opciones.
‫Uno de ellos aquí es crear un volumen con nombre.
‫Si solo hiciera -v, y luego var lib mysql, eso haría lo mismo es lo que hizo
‫nuestro comando de volumen en Dockerfile.
‫Realmente no necesitamos hacer eso aquí. Pero lo que podemos hacer es ponerle un
‫nombre con dos puntos. Eso se conoce como un "volumen nombrado". un nombre descriptivo.
‫"Cuando hago eso, y luego hago un volumen de portador ls, verá que mi nuevo contenedor está usando un nuevo volumen
‫y está usando
‫Si hacemos un volumen de docker inspeccionando ese mysql, verás que aquí es más fácil de usar.
‫Si eliminé mi contenedor de nuevo, y tenemos que poner un
‫-f porque aún se está ejecutando, y luego ejecuto otro. Y esta vez, le
‫daré un nombre diferente. Y luego hacemos otro volumen docker ls, verá que
‫parece que no hemos creado un nuevo volumen. Todavía está usando el mismo volumen.
‫Hagamos un contenedor docker inspeccionando el mysql3. es lo que se configuró, pero ¿qué estamos ejecutando?
‫Entonces, lo que veremos aquí es, sí, esto
‫Este es nuestro soporte aquí.
‫Veremos aquí que no solo el nombre es más amigable, sino que también cambió la ubicación de la fuente para
‫ser un poco más amigable también.
‫aquí es que cuando estoy corriendo por días o semanas a la vez, una base de datos particular, en un contenedor particular que
‫necesito seguir usando una y otra vez y no quiero un servidor de base de datos
‫en blanco, Terminaré creando mis contenedores de esta manera y nombrándolos para el proyecto, de modo que sé para qué sirve ese volumen y
‫que debe mantenerse.
‫Para mí, un pequeño consejo
‫Una última cosa aquí.
‫¿Por qué querrías crear docker volume create?
‫Si podemos crearlos desde un comando de ejecución de contenedor acoplable en tiempo de ejecución, y podemos crearlos al especificarlos en el archivo Docker, solo hay unos pocos
‫casos en los que desearía crearlo antes de tiempo. Y en realidad puedes descubrirlo
‫rápidamente usando el comando de ayuda.
‫Porque esta es la única forma en que podemos especificar un controlador diferente.
‫¿Recuerdas ese complemento de cosas de las que voy a hablar más adelante?
‫Luego, cualquier opción de controlador que deseemos usar -o on.
‫Luego, si queremos poner etiquetas en él, de lo cual también hablaremos más adelante en la sección de producción.
‫En ocasiones, en casos especiales, es necesario crear el volumen de Docker con anticipación, pero generalmente para fines de desarrollo
‫local, solo especificarlo en un archivo Docker o en el comando de ejecución es correcto.