Si trabajas en macOS o en Windows, llevas todo el curso ejecutando contenedores dentro de una máquina virtual Linux sin verla. Docker Desktop es esa VM, más una interfaz gráfica y un puñado de extras. Esta lección abre la caja: qué hay dentro, por qué eso explica que los bind mounts vayan lentos, qué aporta de verdad, cuánto cuesta —incluida la letra pequeña de la licencia— y qué alternativas tienes en cada sistema.

1. Qué es exactamente Docker Desktop
2. La arquitectura por dentro
3. Por qué los bind mounts van lentos
4. La VM y sus recursos
5. El disco virtual que crece y no se encoge
6. Windows: WSL 2 frente a Hyper-V
7. macOS: Apple Silicon, Rosetta y VirtioFS
8. Lo que aporta la interfaz
9. Docker Scout, el Kubernetes de un clic y las extensiones
10. docker init, docker debug y los contenedores de desarrollo
11. Licencia y coste
12. Alternativas al escritorio
13. Recomendación por perfil

Docker Desktop no es Docker. Es un paquete que contiene, entre otras cosas:

El punto clave está en la primera fila: los contenedores son una función del kernel de Linux —namespaces y cgroups, tal como viste en 05-07—. macOS y Windows no tienen ese kernel, así que hace falta uno. En Linux, Docker Desktop es opcional precisamente porque el kernel ya está: ahí docker habla directamente con dockerd sin ninguna VM de por medio.

Todo lo que cruce la frontera entre el anfitrión y la VM tiene un coste. Y hay dos cosas que la cruzan constantemente: los ficheros de los bind mounts y los paquetes de red de los puertos publicados.

Cuando montas ./src:/app/src en Linux, no pasa nada especial: el contenedor ve el mismo sistema de ficheros del host a través del namespace de montaje. En macOS o Windows, cada open(), cada stat() y cada read() viaja del contenedor a la VM, de la VM al anfitrión y vuelta.

Ahí está el motivo de una recomendación que verás en todas partes y que ahora entiendes: node_modules nunca en un bind mount. Instalar dependencias de aurora-api con la carpeta montada desde macOS puede tardar minutos; con un volumen nombrado, segundos.

Mídelo tú mismo, que es más convincente que cualquier tabla:

La VM tiene un tamaño fijo que le has asignado, y todo lo que ejecutan tus contenedores compite dentro de él. Cuando un docker compose up de Aurora Libros va lento sin motivo aparente, este es el primer sitio donde mirar.

Un síntoma frecuente y confuso: PostgreSQL muere con código 137 al importar los nueve títulos del catálogo. No es un fallo de la base de datos, es el OOM killer del kernel de la VM. Si la VM tiene 2 GB y los contenedores piden 3, alguien muere; súbela y el problema desaparece.

El disco de la VM es un fichero disperso en tu anfitrión —Docker.raw en macOS, un .vhdx en Windows— que crece cuando escribes y no mengua cuando borras. Puedes tener 8 GB de imágenes según Docker y 90 GB ocupados en tu portátil.

Recuperar espacio son dos pasos, y el orden importa:

La advertencia del tercer comando es seria: --volumes se lleva por delante aurora-datos si en ese momento no hay ningún contenedor usándolo. Los nueve títulos del catálogo desaparecen sin preguntar. Usa docker volume ls antes y, en general, prefiere prune selectivo.

La integración con distribuciones es lo que hace cómodo el día a día: en Settings → Resources → WSL Integration activas tu Ubuntu, y desde su terminal el comando docker funciona sin instalar nada dentro.

Y la regla que más rendimiento te dará en Windows: guarda el código en el sistema de ficheros de Linux, no en el de Windows.

La diferencia no es de matiz: un npm install de aurora-api puede pasar de tres minutos a veinte segundos solo por mover la carpeta. Si necesitas editar desde Windows, VS Code con la extensión WSL abre el proyecto remoto sin sacar los ficheros de Linux.

En un Mac con Apple Silicon, la VM es arm64. Tus imágenes se construyen y ejecutan en arm64 de forma nativa, y todo va rápido... hasta que aparece una imagen que solo existe para amd64.

Rosetta se activa en Settings → General → Use Rosetta for x86/amd64 emulation y mejora mucho la experiencia, pero no es magia: hay binarios que fallan, extensiones de CPU que no están y cargas que siguen siendo lentas.

Por eso el trabajo multiarquitectura del módulo 5 no era académico. Tu ghcr.io/auroralibros/aurora-api:2.0.0 está publicada para linux/amd64 y linux/arm64, así que el Mac descarga la variante arm64 y el servidor de producción la amd64, sin emulación en ninguno de los dos lados. Es la solución correcta al problema.

En cuanto a ficheros, macOS usa VirtioFS con el framework de virtualización de Apple: es notablemente más rápido que el antiguo gRPC-FUSE, aunque sigue sin llegar a lo nativo. Verifica que está activo en Settings → General → Choose file sharing implementation.

La GUI no hace nada que la CLI no pueda hacer, pero hay tareas donde ver es más rápido que teclear.

El panel de Builds es el más infravalorado: te dice qué paso del Dockerfile de aurora-api está costando los segundos y si la caché acertó o no, que es exactamente lo que optimizaste a ciegas en 05-04.

Docker Scout viene integrado y analiza las imágenes locales:

Es cómodo para una revisión rápida en el escritorio, pero no sustituye al escaneo del pipeline: el que decide si una imagen se publica es el Trivy de tu GitHub Actions (06-02), que corre sin intervención humana y falla el build. Scout es la comprobación temprana; el pipeline es la puerta.

El Kubernetes de un clic activa un clúster de un solo nodo dentro de la misma VM.

Frente a kind, minikube o k3d (06-04), su ventaja es que ya está ahí; su desventaja es que consume memoria de la misma VM y no puedes tener varios clústeres ni elegir versión con comodidad. Para experimentar con varias versiones o simular varios nodos, kind sigue siendo mejor.

Las extensiones añaden herramientas de terceros al panel (visores de logs, clientes de bases de datos, gestores de discos). Son útiles con una precaución: son código de terceros con acceso a tu daemon. Instala solo las que necesites y de origen conocido.

docker init genera un andamiaje razonable: multietapa, usuario sin privilegios y .dockerignore. Es un excelente punto de partida y un mal punto de llegada: no fija la base por digest, no añade las tres sondas de 06-01 ni el apagado ordenado. Úsalo para arrancar y aplica encima lo que sabes.

docker debug resuelve el problema clásico de las imágenes mínimas: cuando aurora-api:2.0.0 no tiene ni sh ni curl, docker exec no te sirve de nada.

No instala nada en el contenedor ni cambia la imagen: monta un conjunto de utilidades en una capa aparte. Es la alternativa cómoda al netshoot que verás en 07-04, y una función de la suscripción de pago.

Por último, los contenedores de desarrollo de VS Code: un .devcontainer/devcontainer.json describe el entorno completo —imagen, extensiones, puertos, comandos— y el editor se ejecuta dentro del contenedor.

Con esto, alguien nuevo en Aurora Libros clona el repositorio, abre VS Code y tiene Node 22, PostgreSQL 16 y Redis 7 funcionando. Es la respuesta definitiva a los quince pasos de onboarding manual con los que empezó el curso en 01-07.

Docker Desktop es software propietario con licencia comercial, aunque el Docker Engine que lleva dentro sea de código abierto. En los términos vigentes en 2026:

El umbral ha cambiado más de una vez desde 2021, y la letra concreta —qué cuenta como empleado, si incluye a los contratistas, qué pasa en un grupo de empresas— determina si tu organización debe pagar.

Advertencia práctica: no instales Docker Desktop en un equipo corporativo dando por hecho que es gratis. Consulta los términos vigentes en la web oficial en el momento de instalarlo y valídalo con el departamento legal o de compras de tu empresa. Ha habido auditorías de licencias con facturas retroactivas, y la responsabilidad no recae en quien lo instaló, sino en la compañía. Si tu empresa decide no pagar, la buena noticia es que hay alternativas plenamente funcionales y ninguna de ellas afecta a tus imágenes, que son OCI estándar.

Fíjate en el detalle: todas estas alternativas se integran mediante contextos de Docker, el mecanismo de la lección anterior. Y en todas ellas tus imágenes y tu compose.yaml funcionan sin cambios, porque nada de lo que has construido durante el curso depende de Docker Desktop.

La última fila no admite matices: en un servidor o en un runner de integración continua se instala Docker Engine, nunca Docker Desktop.

• Trabajar desde /mnt/c/... en WSL 2. Es la causa número uno de lentitud en Windows. Mueve el proyecto a ~/ dentro de la distribución.
• Bind-montar node_modules. Miles de ficheros pequeños cruzando la frontera. Usa un volumen nombrado para esa ruta.
• Extrañarse del código 137. Es el OOM killer de la VM. Sube la memoria en Resources o pon límites por servicio.
• Creer que borrar imágenes libera espacio en el portátil. El disco virtual no se encoge solo: hay que compactarlo o purgarlo aparte.
• docker system prune -a --volumes sin mirar. Se lleva aurora-datos y con él los nueve títulos. Comprueba docker volume ls antes.
• Instalarlo en la empresa sin comprobar la licencia. Los términos cambian y las auditorías existen. Verifica y consulta con legal o compras.
• Usar el Kubernetes de Docker Desktop como si fuese producción. Es un nodo único: no prueba disponibilidad, ni reprogramación, ni el CNI real.
• Consejo: activa Rosetta en Apple Silicon, pero resuelve el problema de raíz publicando imágenes multiarquitectura como hiciste en 05-05.
• Consejo: revisa el panel Builds cuando un docker compose build se haga lento. Te dirá el paso culpable en segundos.
• Consejo: guarda un .devcontainer/devcontainer.json en el repositorio. Convierte el onboarding en «clona y abre».

Ejercicio 1 — Mide la frontera. Diseña y ejecuta una medición que compare el tiempo de crear 3 000 ficheros pequeños en tres ubicaciones: un bind mount desde tu carpeta del anfitrión, un volumen nombrado y el sistema de ficheros interno del contenedor. Anota los tres tiempos, calcula la proporción y explica el resultado con la arquitectura de §2. Si estás en Linux, explica por qué los tres números se parecen.

Ejercicio 2 — Auditoría de espacio y recuperación. Averigua cuánto ocupa Docker según su propia contabilidad y cuánto ocupa realmente el disco virtual en tu anfitrión. Explica la diferencia. Después libera espacio de forma segura, dejando intacto el volumen aurora-datos, y comprueba el resultado en ambas medidas. Indica qué comando habría destruido los datos y por qué.

Ejercicio 3 — Decisión de herramienta de escritorio. Aurora Libros crece a 14 desarrolladores: 6 en macOS con Apple Silicon, 5 en Windows y 3 en Linux. La empresa supera el umbral de la licencia gratuita. Compras pregunta si hay que pagar 14 suscripciones. Prepara una recomendación con: qué se necesita realmente en cada sistema, qué alternativa propones para cada grupo, qué se pierde con cada alternativa, y qué preguntas concretas hay que hacer a legal antes de decidir.

Solución 1.

Resultados típicos en un Mac con Apple Silicon y VirtioFS: bind mount alrededor de 8-12 s, volumen nombrado 0,6-1,2 s, capa del contenedor 0,5-1 s. La proporción del bind mount ronda 10×. La explicación es la de §2: cada open(), write() y close() de los 3 000 ficheros atraviesa la capa de compartición entre la VM y el anfitrión, y son 9 000 viajes de ida y vuelta; el volumen nombrado vive dentro del disco de la VM y no cruza nada, igual que la capa de escritura de overlay2 (05-07).

En Linux los tres números salen casi idénticos —décimas de segundo— porque no hay frontera que cruzar: el bind mount es el mismo sistema de ficheros visto desde otro namespace de montaje. Ese es exactamente el motivo por el que un compañero con Linux no reproduce tu problema de lentitud, y por el que la solución no es «tener mejor portátil» sino mover los ficheros al lado correcto de la frontera.

Solución 2.

La diferencia es que el disco virtual es un fichero disperso que crece al escribir y nunca se reduce al borrar: cuando eliminas una imagen, los bloques quedan libres dentro de la VM pero el fichero sigue reservando ese tamaño en tu portátil.

El comando destructivo es docker system prune -a --volumes: la opción --volumes incluye los volúmenes sin ningún contenedor asociado, y si en ese momento aurora-db está parado, aurora-datos entra en la criba y los nueve títulos del catálogo desaparecen sin confirmación por volumen. Como red de seguridad, haz docker run --rm -v aurora-datos:/v -v "$PWD":/b alpine tar czf /b/aurora-datos.tgz -C /v . antes de cualquier limpieza agresiva, exactamente el patrón de copia de 05-02.

Solución 3. Recomendación por grupos:

Análisis: de 14 licencias, 3 sobran de inmediato porque en Linux Docker Desktop no aporta nada. En macOS, Colima cubre el caso completo con la CLI de siempre y los mismos contextos; se pierden funciones de escritorio que el equipo probablemente use poco, y conviene preguntarlo antes de decidir por ellos. Windows es donde la integración con WSL 2 tiene más valor real, así que ahí puede compensar pagar unas pocas licencias en lugar de forzar una alternativa. Una salida intermedia razonable: 5 licencias para Windows y alternativas libres en macOS y Linux, revisable en seis meses.

Preguntas para legal y compras, antes de decidir nada: ¿qué dicen exactamente los términos vigentes sobre el umbral, y contamos empleados totales o solo desarrolladores?; ¿los contratistas externos y las filiales cuentan dentro del grupo?; ¿existe ya un acuerdo marco con Docker o un contrato de suscripción de otro producto que cubra esto? Añade una cuarta pregunta interna, que a menudo es la que resuelve el debate: ¿qué funciones concretas de Docker Desktop usa de verdad el equipo cada semana? Si la respuesta es «arrancar Compose y ver logs», la decisión se toma sola.

Ya sabes qué es esa VM que llevabas usando sin verla. Docker Desktop no es Docker: es una máquina virtual Linux con dockerd dentro, más una GUI, plugins y extras, y existe porque los contenedores son una función del kernel de Linux que macOS y Windows no tienen. En Linux es opcional justamente por eso.

De esa arquitectura sale todo lo demás. Entiendes por qué los bind mounts van entre 2 y 30 veces más lentos según el sistema y el protocolo, por qué node_modules debe vivir en un volumen nombrado, y por qué en WSL 2 mover el proyecto de /mnt/c/... a ~/ puede convertir tres minutos en veinte segundos. Sabes dimensionar la VM, diagnosticar un código 137 como lo que es —el OOM killer, no un fallo de PostgreSQL— y recuperar espacio en los dos niveles, con la advertencia de que --volumes se lleva aurora-datos sin preguntar.

Conoces el terreno de cada sistema: WSL 2 frente a Hyper-V y la integración con distribuciones en Windows; Apple Silicon, Rosetta y VirtioFS en macOS, con la constatación de que el trabajo multiarquitectura de 05-05 es la solución de raíz al problema de la emulación. Y sabes qué aporta la herramienta de verdad: el panel de Builds con la duración por paso, Scout como comprobación temprana que no sustituye al escaneo del pipeline, el Kubernetes de un clic con sus límites honestos, docker init como buen punto de partida y mal punto de llegada, docker debug para las imágenes sin shell, y los contenedores de desarrollo como respuesta definitiva a los quince pasos de onboarding de 01-07.

Y te llevas lo que no es técnico: es software propietario con umbrales de licencia que han cambiado varias veces, así que se verifica en la web oficial y se valida con legal o compras antes de instalarlo en la empresa. Si la respuesta es que no se paga, tienes la tabla de alternativas —Engine nativo, Rancher, Podman Desktop, Colima, OrbStack, lima—, todas integradas por contextos y todas ejecutando tus imágenes sin cambiar una línea, porque nada de lo que has construido depende de Docker Desktop.

En la lección siguiente salimos del escritorio para equipar el flujo de trabajo: las herramientas y plugins de terceros que rodean a Docker en un proyecto real. Cómo funciona la extensibilidad de la CLI —construirás tu propio docker aurora—, qué merece la pena en interfaces, inspección, seguridad, registros propios, desarrollo y construcción alternativa, y con qué criterios se decide adoptar una herramienta o dejarla fuera.