Mover docker-desktop-data fuera de la Unidad del Sistema

Docker es una tecnología que con el devenir de los años ha ido cogiendo cada vez mayor relevancia. Sirve tanto como herramienta de desarrollo para trabajar de manera más ágil y eficiente con entornos y/o ciertas herramientas, a la vez que se consolida como pieza base en los despliegues de infraestructura orientada a servicio.

En su origen, inició su camino en sistemas GNU/Linux con el firme objetivo de facilitar los despliegues de software, automatizando y abstrayendo los mismos. Originalmente su primera implementación para sistemas Windows fue usando VirtualBox, para luego pasar a la virtualización de Hyper-V propietaria de Microsoft que supuso una mejora muy importante del rendimiento de Docker en Windows. El problema es que esta actualización supuso que al requerir de Hyper-V, obligaba a que se contara al menos con una versión Windows 10 Pro o superior. No fue hasta junio de 2019 cuando con la llegada de WSL2 (evolución de la primera versión de WSL de agosto de 2016) cuando se pudo contar con Docker en cualquier versión del sistema de Windows.

Pero aunque Docker es estupendo, ocupa bastante a nada que empiezas a trabajar con imágenes y pones en marcha contenedores...😅 Esto sumado a que la tónica habitual es instalar cualquier software en la unidad del sistema por defecto, o en el peor de los casos instalar en la unidad del sistema sin opción a elegir; hace que sea un fastidio que Docker se instale en la unidad del sistema C y además vaya aumentando el espacio que utiliza. Aunque realmente, lo que ocupa si estas usando WSL2 como backend de funcionamiento de Docker en Windows, son los datos de los contenedores que se guardan en docker-desktop-data.

Por defecto Docker Desktop para Windows creará la siguientes dos distros:

  • docker-desktop
  • docker-desktop-data

Si accedemos a la ruta "%LOCALAPPDATA%/Docker/wsl", veremos dos carpetas, y dentro de cada una de ellas hay un archivo vhdx. Para más detalle:

  • data/ext4.vhdx que es consumido por docker-desktop-data
  • distro/ext4.vhdx que es consumido por docker-desktop

En el que docker-desktop-data se usa para almacenar imágenes, etc. Por lo tanto, su tamaño aumentará en el futuro, y en consecuencia, nuestra unidad de sistema (C:) se quedará sin espacio. A continuación, se muestra paso a paso cómo sacar docker-desktop-data fuera de la unidad del sistema, por ejemplo, D:\desktop-docker\data.

🐋⚙️ Procedimiento

Paso1: Parar Docker

(Creo que esto ya te lo esperabas 😉)

Paso2: Exportar, desregistrar e importar la distro

1- Apagar todas las distros WSL

wsl --shutdown

2- Exportar docker-desktop-data a un fichero TAR

wsl --export docker-desktop-data E:\docker-desktop\docker-desktop-data.tar

3- Desregistrar la distro actual docker-desktop-data

wsl --unregister docker-desktop-data

4- Importar la distro docker-desktop-data desde el fichero TAR

wsl --import docker-desktop-data E:\docker-desktop\data E:\docker-desktop\docker-desktop-data.tar --version 2

👀 Nota: En este paso, podemos encontrarnos con el error de no poder crear una red específica. Simplemente vuelve a ejecutar el comando de importación.

Paso 3: Arrancar Docker

(Creo que esto TAMBIÉN te lo esperabas 😁)

Con este procedimiento ya tendremos Docker en una unidad que no es la del sistema, en la que el crecimiento de la distro docker-desktop-data no supondrá un problema, evitando degradar el rendimiento del sistema por llenar la unidad del sistema.

Feliz Navidad y Próspero Año 2022

Otro año más nos encontramos en el "día de la marmota", seguimos con el COVID19 y casi parece que vamos a tener que aprender a convivir con él. No obstante partiendo de la reflexión del año pasado, siento que mi orden de prioridades ahora sí es el correcto. He podido alimentar Mascando Bits con algunas entradas interesantes, a la vez que como siempre, me sigo quedando con ganas y sin tiempo de hacer otras que se me quedan en la recámara (cosas que pasan 😅 ).

He tenido la mala suerte de haber pasado este año el COVID19, pero también la buena suerte de haberlo pasado de una manera razonablemente buena, gracias a la nueva situación en la que nos encontramos, tras un año de vacunas y medidas, a veces acertadas y otras muchas contradictorias y descordinadas. Seguir siempre es un motivo para mirar hacia delante y estar agradecido. 😄

Como años anteriores y sabiendo que me repito, no quiero dejar de agradecer a todos aquellos que habéis dedicado unos minutos durante este año, para plasmar en comentarios de los distintos artículos que os han gustado, os han sido de ayuda, o incluso algunas correcciones y aportes… Anima mucho y siempre seguirá animando. 😊 A los lectores, muchas veces silenciosos, también daros las gracias por leerme y compartir mis artículos cuando así lo habéis creido oportuno. Puede parecer que no os tenga en cuenta, pero el número de visitas, claramente me dice que estáis ahí. !Gracias por ello! 😊

Sólo me resta desearos con mis mejores deseos ¡Felices Fiestas! (para los agnósticos y ateos), ¡Feliz Navidad! (para los creyentes) y ¡Feliz Año 2022! (para TODOS 😉 ). ¡Nos vemos a la vuelta!

Cambiar de Branch en un Shallow Clone

Si estas usando sistemas de integración continua (Continuous Integration), trabajas con repositorios pesados o simplemente no quieres pasar por un un clonado de Git que te traiga todo el árbol de un repositorio, seguro que estás familiarizado con el concepto shallow clone o clonado superficial.

Un shallow clone o cloando superficial permite traerse los últimos commits y no todo el histórico del repositorio Git. Aunque pueda parecer una solución maravillosa para desprenderse de los problemas de un clonado completo del histórico del árbol Git , presenta ciertos problemas a la hora de operarlo como un repositorio clonado de manera normal cuando se ha clonado bajo estas condiciones específicas de clonado.

🐑 Crear un clonado superficial

Para ejecutar un clonado superficial o shallow clone lo haremos con el siguiente comando:

git clone -–depth [depth] [remote-url]

Donde depth la profundidad es el número de commits que nos vamos a traer durante el clonado y remote-url es la dirección URL de origen de donde vamos a clonar el repositorio. 👀 El uso de --depth implica --single-branch.

Para ejecutar clonado superficial o shallow clone de una rama o branch podemos hacerlo con:

git clone [remote-url] -–branch [name] -–single-branch

Donde name es el nombre de la rama o branch que queremos clonar.

Si aún queremos hilar más fino y resulta que tenemos repositorios con submódulos (repositorios Git incluidos en otro repositorio), los cuales tienes su propio árbol Git y se inicializan usando alguno de los siguientes comandos:

git clone -–recursive [remote-url]  # Git version >= 1.6.5
git clone -–recurse-submodules -–jobs [num-jobs] [remote-url]   # Git version >= 2.13

La primera sintaxis con recursive puede resultar más cómoda, aunque resulta más rápida y eficiente la segunda con recurse-submodules, la cual es la sintaxis vigente que permite especificar el número de submódulos operados concurrentemente mediante jobs.

Si este es tu caso, no tiene sentido hacer un clonado superficial si se hace un clonado completo de los submódulo. Para ello ejecutaremos el siguiente comando:

git clone -–depth [depth] -–shallow-submodules [remote-url]

La opción --shallow-submodules implica que todos los submódulos se clonarán con una profundidad de 1.

🐏 Convertir un repositorio con clonado superficial en uno de tipo clonado completo

Si has seguido los pasos anteriores, te darás cuenta que si quieres cambiarte por ejemplo a otra rama no puedes. Eso es debido a que se ha omitido el resto del histórico según se lo hemos especificado. ¿Eso significa que no existe? No, eso sólo quiere decir que no lo conocemos.

Si ejecutamos el siguiente comando sobre un repositorio clonado superficialmente, veremos los remotos que conocemos y los remotos existentes en el local:

git branch -–all

Si intentamos hacer un fetch del remoto veremos que tampoco conseguimos ver el histórico completo del repositorio:

git fetch -–verbose

Esto es debido a que nuestro remoto no está convenientemente configurados debido al clonado superficial. Podemos restaurar su funcionalidad completa partiendo de que nuestro remoto origin, de donde clonamos el repositorio, contiene la remote -url que metimos. Por ello podemos restaurar el acceso a todo el histórico del remoto para nuestro repositorio, usando el siguiente comando:

git remote set-branches origin "*"

Mediante la opción set-branches podemos cambiar la lista de ramas que son seguidas por el remoto conocido y por defecto que es origin.

Ahora volvemos a ejecutar el comando fetch de nuevo y en este caso podremos apreciar que la totalidad de ramas aparecen:

git fetch -–verbose

Adicionalmente también restauramos el histórico completo de la rama actual donde nos encontramos:

git fetch --unshallow

Con esto ya tenemos acceso al historial completo del repositorio y podremos cambiarnos a otra rama a la cual antes no podíamos:

git checkout rama-que-estaba-buscando

Si quieres comprobar el último commit de la rama local para cotejarlo con el último commit disponible el remoto y comprobar que está todo correcto, puedes hacerlo con:

git show

💡 Conclusiones

El clonado superficial o shallow clone es una gran herramienta, pero puede echarnos el lazo al cuello si no sabemos y necesitamos deshacerlo. No obstante aunque siempre existe la opción de hacer un clonado clásico de nuevo, no resulta una opción elegante y eficiente que nos obliga a duplicar y volver a clonar el repositorio.

Frase Memorable 11


Antonio Machado dijo, “En cuestiones de cultura y de saber sólo se pierde lo que se guarda; sólo se gana lo que se da”.