Ya sabes qué problema resuelve Docker; toca instalarlo. Esta lección te lleva de la mano por la instalación en los tres sistemas operativos habituales, explicando en cada paso qué estás haciendo y por qué, en lugar de pedirte que copies comandos a ciegas. Verás primero la diferencia fundamental entre Docker Engine y Docker Desktop —dos productos distintos que mucha gente confunde—, incluida la cuestión de la licencia, que puede ser relevante si trabajas en una empresa grande. Después harás la instalación completa de Docker Engine en Ubuntu/Debian desde el repositorio oficial, los pasos posteriores imprescindibles en Linux (con una advertencia de seguridad que no debes saltarte), y las instalaciones en Windows con WSL 2 y en macOS. Terminarás verificando que todo funciona y descifrando, línea a línea, la salida de tu primer contenedor.

1. Docker Engine y Docker Desktop: dos productos distintos
2. La licencia de Docker Desktop en empresas
3. Requisitos previos
4. Instalación de Docker Engine en Ubuntu/Debian
5. Pasos posteriores a la instalación en Linux
6. Instalación en Windows con el backend WSL 2
7. Instalación en macOS (Intel y Apple Silicon)
8. Verificación: docker version, docker info y hello-world
9. Desinstalar y limpiar

Este es el primer punto donde la gente se pierde, así que vamos despacio.

Docker Engine es el motor: el servicio que realmente crea y ejecuta contenedores, más la herramienta de línea de comandos docker que habla con él. Se ejecuta nativamente solo en Linux, porque los contenedores se apoyan en funcionalidades del kernel de Linux. No tiene interfaz gráfica. Es lo que corre en los servidores.

Docker Desktop es una aplicación de escritorio para Windows, macOS y Linux que incluye Docker Engine dentro de una máquina virtual Linux gestionada automáticamente, más una interfaz gráfica, más herramientas adicionales (Kubernetes de un clic, gestión de extensiones, escaneo de vulnerabilidades). En Windows y macOS es prácticamente la única forma cómoda de trabajar, porque esos sistemas no tienen kernel Linux: Docker Desktop se lo proporciona.

Esa es la clave conceptual: cuando ejecutas un contenedor Linux en un Mac o en Windows, siempre hay una máquina virtual Linux de por medio, aunque no la veas.

En Linux tienes las dos opciones. La recomendación general para aprender y para servidores es Docker Engine: menos capas, menos consumo, y es lo que encontrarás en producción. Docker Desktop como herramienta de trabajo diario se estudia aparte, en la lección 07-03; aquí solo lo instalamos.

Es un detalle práctico que conviene conocer antes de instalar nada en el portátil de tu empresa.

• Docker Engine es software libre bajo licencia Apache 2.0. Es gratuito en cualquier contexto, incluido el comercial.
• Docker Desktop es gratuito para uso personal, educativo, proyectos de código abierto y pequeñas empresas, pero requiere una suscripción de pago para uso profesional en organizaciones que superan un umbral (históricamente, más de 250 empleados o más de 10 millones de dólares de facturación anual; los términos exactos los fija Docker, Inc. y conviene consultarlos en su web).

Traducción práctica: si trabajas en una empresa grande, no instales Docker Desktop sin comprobar con tu departamento de IT si hay licencias. En Linux siempre puedes usar Docker Engine sin ninguna restricción, y existen alternativas al escritorio que se comentan en la lección 07-05.

Vamos a instalar desde el repositorio oficial de Docker, no desde los paquetes que trae la distribución. ¿Por qué? Porque el paquete docker.io de Ubuntu suele ir varias versiones por detrás y no incluye los plugins modernos (buildx, compose) que usarás durante todo el curso.

Este bucle recorre una lista de paquetes que pueden entrar en conflicto con la instalación oficial y los desinstala. Si no tienes ninguno instalado, apt te dirá simplemente que el paquete no está presente y seguirá adelante; no es un error. Fíjate en que se elimina docker-compose: es la versión antigua de Compose (la del guion), que sustituiremos por el plugin moderno.

Desmenucemos cada línea:

• apt update refresca la lista de paquetes disponibles.
• ca-certificates y curl son necesarios para descargar de forma segura por HTTPS.
• install -m 0755 -d /etc/apt/keyrings crea el directorio donde se guardan las claves de firma de repositorios, con permisos correctos.
• curl -fsSL ... -o ... descarga la clave pública GPG de Docker. Las opciones significan: -f falla silenciosamente ante errores HTTP, -s modo silencioso, -S pero muestra errores, -L sigue redirecciones. Esta clave es lo que permite a apt verificar que los paquetes que descargue vienen realmente de Docker y no han sido manipulados.
• chmod a+r hace la clave legible por todos los usuarios, que es lo que apt necesita.

Si usas Debian en lugar de Ubuntu, cambia ubuntu por debian en la URL de la clave y en la del repositorio del paso siguiente.

Este comando escribe una línea en /etc/apt/sources.list.d/docker.list. Las partes dinámicas son:

• $(dpkg --print-architecture) inserta la arquitectura de tu máquina (amd64 o arm64), para que apt descargue los binarios correctos.
• signed-by=... ata este repositorio a la clave que descargaste: solo se aceptarán paquetes firmados con ella.
• $(. /etc/os-release && echo "$VERSION_CODENAME") inserta el nombre en clave de tu versión (por ejemplo noble en Ubuntu 24.04). Si este trozo devuelve vacío, sustitúyelo a mano por el nombre en clave de tu distribución.
• sudo tee ... > /dev/null escribe el fichero con permisos de root sin volcar el contenido por pantalla.

El apt update final vuelve a leer las fuentes, ahora incluyendo la de Docker.

Cinco paquetes, y conviene saber qué hace cada uno porque reaparecerán en la lección 01-03:

Los dos últimos son plugins de la CLI: por eso el comando moderno es docker compose y no docker-compose. La forma con guion es el binario antiguo (Compose v1, en Python), hoy retirado; solo la mencionaremos para reconocerla en documentación vieja.

La instalación deja Docker funcionando, pero solo para root. Estos pasos lo dejan usable en el día a día.

• enable hace que el servicio arranque automáticamente en cada reinicio.
• --now además lo arranca en este mismo momento, sin esperar a reiniciar.
• status muestra el estado; deberías ver una línea Active: active (running). Sal de la vista con q.

En la mayoría de instalaciones desde el repositorio oficial el servicio ya queda habilitado y arrancado; ejecutar el comando igualmente no hace daño y te confirma el estado.

Por defecto, el daemon escucha en un socket Unix (/var/run/docker.sock) que pertenece al usuario root y al grupo docker. Si tu usuario no está en ese grupo, cada comando exigirá sudo:

• usermod -aG docker $USER añade (-a, append) tu usuario al grupo (-G) docker. Sin -a borrarías el resto de grupos de tu usuario, así que no lo omitas nunca.
• newgrp docker aplica la pertenencia al grupo en la sesión actual sin cerrar sesión. Alternativamente, cierra sesión y vuelve a entrar.

Comprueba que ha funcionado ejecutando docker version (sin sudo): si no da error de permisos, ya está.

Esto no es un detalle menor, léelo con atención.

Pertenecer al grupo docker es equivalente a tener permisos de root en la máquina. No es una exageración: quien puede hablar con el daemon puede pedirle que arranque un contenedor privilegiado que monte el sistema de archivos completo del anfitrión y modificarlo a voluntad. El daemon corre como root y ejecuta lo que le pidas.

Consecuencias prácticas:

• En tu portátil de desarrollo, donde ya tienes sudo, añadirte al grupo docker es perfectamente razonable y es lo normal.
• En un servidor compartido, meter a alguien en el grupo docker es darle root. Trátalo con el mismo cuidado que un acceso privilegiado.
• Si necesitas evitarlo, existe el modo rootless de Docker, que ejecuta el daemon con tu usuario sin privilegios. Tiene algunas limitaciones y se aborda en la lección 05-03, junto al resto de buenas prácticas de seguridad.

En Windows, Docker Desktop se apoya en WSL 2 (Windows Subsystem for Linux 2), que proporciona un kernel Linux real dentro de una máquina virtual ligera integrada en el sistema. Ese kernel es el que ejecuta tus contenedores.

Abre PowerShell como administrador y ejecuta:

• wsl --install activa las características de Windows necesarias (WSL y Plataforma de máquina virtual) e instala una distribución Linux por defecto (normalmente Ubuntu).
• wsl --set-default-version 2 fija WSL 2 como versión por defecto. WSL 1 no sirve para Docker: no tiene kernel Linux real.
• wsl --update actualiza el kernel de WSL a la última versión.

Reinicia el equipo cuando te lo pida. Si wsl --install falla, casi siempre es porque la virtualización está desactivada en la BIOS/UEFI: búscala como Intel VT-x, AMD-V o SVM Mode y actívala.

Descarga el instalador desde la web oficial de Docker, ejecútalo y, en las opciones, asegúrate de dejar marcada la casilla "Use WSL 2 instead of Hyper-V". Al terminar, inicia Docker Desktop y espera a que el indicador de la barra de estado se ponga en verde ("Engine running").

En Settings → Resources → WSL Integration, activa la integración para las distribuciones de WSL que uses. Eso hace que el comando docker esté disponible dentro de tu terminal Ubuntu de WSL, hablando con el mismo motor.

Un consejo de rendimiento que ahorra muchísimo sufrimiento: guarda tus proyectos dentro del sistema de archivos de Linux (por ejemplo \\wsl$\Ubuntu\home\tu-usuario\proyectos), no en C:\Users\.... El acceso de los contenedores a ficheros que viven en el disco de Windows atraviesa una capa de traducción y es notablemente más lento.

Puedes trabajar desde PowerShell o desde la terminal de WSL indistintamente; los comandos docker son los mismos.

En macOS ocurre lo mismo que en Windows: no hay kernel Linux, así que Docker Desktop levanta una máquina virtual Linux ligera (usando el framework de virtualización de Apple) donde vive el motor.

1. Descarga el .dmg correcto para tu procesador. Es importante:
   • Apple Silicon (M1, M2, M3, M4…) → versión arm64.
   • Intel → versión amd64. Si no lo sabes, ve al menú Apple → Acerca de este Mac, o ejecuta uname -m en el terminal (arm64 frente a x86_64).
2. Abre el .dmg y arrastra Docker a la carpeta Aplicaciones.
3. Lanza Docker desde Aplicaciones. Pedirá tu contraseña de administrador la primera vez para instalar componentes privilegiados.
4. Espera a que el icono de la ballena en la barra de menús deje de animarse.

Una nota importante para Apple Silicon: tu Mac es arm64, y algunas imágenes antiguas solo se publican para amd64. Docker puede ejecutarlas mediante emulación (Rosetta / QEMU), pero será más lenta y ocasionalmente inestable. Verás un aviso del tipo:

No es un fallo: es un aviso de que se está emulando. Las imágenes multiplataforma y cómo construirlas se ven en la lección 05-05.

Da igual el sistema operativo: estas tres comprobaciones son la prueba de fuego.

Salida (abreviada y anotada):

Lo relevante:

• Hay dos bloques: Client y Server. El cliente es el comando que acabas de teclear; el servidor es el daemon. Que aparezcan los dos significa que la comunicación funciona.
• Si solo aparece Client seguido de un error Cannot connect to the Docker daemon, el motor no está arrancado (Linux: sudo systemctl start docker) o tu usuario no tiene permisos sobre el socket (revisa el apartado 5).
• Verás también containerd y runc: son los componentes de bajo nivel que explicaremos en la lección 01-03.

Salida (extracto anotado):

Aquí lo que debes confirmar en una instalación recién hecha:

• En Plugins aparecen buildx y compose. Si no están, te faltó instalar docker-buildx-plugin o docker-compose-plugin.
• Storage Driver: overlay2 es el driver de almacenamiento moderno y el esperado.
• Containers: 0 e Images: 0: normal, aún no has hecho nada.
• Docker Root Dir es donde el daemon guarda imágenes, contenedores y volúmenes. Si esa partición se llena, Docker deja de funcionar.

Interpretaremos esta salida con más profundidad en la lección 01-03.

Este es el examen final de la instalación:

Salida completa:

Vamos línea a línea, porque cada una enseña algo:

Si ves ese saludo, tienes Docker instalado y funcionando. El contenedor, por cierto, ya ha terminado: ejecutó su único proceso, este imprimió el texto y murió. Sigue existiendo en estado "parado", como comprobarás en la lección 01-04.

Por si necesitas empezar de cero en Ubuntu/Debian:

• apt purge elimina los paquetes y sus ficheros de configuración.
• Los dos rm -rf borran los datos: todas tus imágenes, contenedores y volúmenes. Es irreversible, así que asegúrate antes.

En Windows y macOS, desinstala Docker Desktop como cualquier otra aplicación; la propia app ofrece además un botón Troubleshoot → Clean / Purge data para vaciar los datos sin desinstalar.

• Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? Es el error número uno. Dos causas: el servicio no está arrancado (sudo systemctl start docker en Linux; abrir Docker Desktop en Windows/macOS) o tu usuario no está en el grupo docker. Para distinguirlas, prueba sudo docker version: si con sudo funciona, es un problema de permisos, no del servicio.
• Instalar docker.io desde los repositorios de la distribución. Funciona para lo básico, pero suele traer una versión antigua y sin los plugins buildx y compose, con lo que la mitad del curso no te funcionará. Usa el repositorio oficial.
• Usar docker-compose con guion. Si ese comando existe en tu sistema, tienes instalada la versión 1, ya retirada. El comando correcto en 2026 es docker compose, sin guion, como subcomando de docker. Compruébalo con docker compose version.
• Olvidar -a en usermod. Escribir sudo usermod -G docker $USER (sin -a) elimina a tu usuario de todos los demás grupos, incluido sudo. Es una forma rápida de quedarte sin permisos de administrador. Siempre -aG.
• Esperar contenedores de Windows en Linux, o viceversa. El contenedor usa el kernel del anfitrión (o el de la VM). En Linux ejecutas contenedores Linux, punto.
• Consejo: no reinicies sesión sin necesidad. Tras usermod, newgrp docker aplica el cambio en la terminal actual. En otras terminales ya abiertas seguirá haciendo falta reabrirlas.
• Consejo: vigila el espacio en disco. Docker Root Dir (por defecto /var/lib/docker) crece con cada imagen que descargas. Si tienes /var en una partición pequeña, tenlo en cuenta desde el principio. En la lección 01-04 verás docker system df y docker system prune para controlarlo.

Instala Docker en tu sistema siguiendo el apartado que corresponda y responde, con la evidencia de los comandos:

1. ¿Qué versión de Docker Engine tienes en el cliente y cuál en el servidor?
2. ¿Están disponibles los plugins buildx y compose? ¿En qué versión?
3. ¿Qué storage driver usa tu instalación y en qué directorio guarda los datos?
4. ¿Puedes ejecutar docker sin sudo?

Un compañero acaba de instalar Docker en Ubuntu y te escribe:

Responde: (a) ¿cuál es la causa?, (b) ¿qué dos comandos lo arreglan?, (c) ¿por qué no es buena idea resolverlo simplemente ejecutando siempre sudo docker ...?, y (d) ¿qué implicación de seguridad tiene la solución que propones?

Ejecuta docker run hello-world dos veces seguidas y compara ambas salidas. ¿Qué líneas desaparecen en la segunda ejecución y por qué? A continuación, sin usar comandos que aún no conoces, razona qué habrá pasado con los contenedores creados: ¿cuántos hay?, ¿siguen en ejecución?

Solución al ejercicio 1

Comentario de cada comando:

• docker version --format ... usa una plantilla Go para extraer solo los dos campos que interesan, en lugar de leer la salida completa. Deberían coincidir cliente y servidor (por ejemplo 28.1.1 / 28.1.1); una diferencia grande entre ambos puede provocar incompatibilidades de API.
• docker compose version y docker buildx version confirman que los plugins están instalados. Si responden docker: 'compose' is not a docker command, falta el paquete correspondiente.
• docker info --format ... extrae el driver de almacenamiento (esperado: overlay2) y el directorio de datos (esperado: /var/lib/docker en Linux).
• Que docker run hello-world funcione sin sudo responde a la cuarta pregunta.

Solución al ejercicio 2

(a) La causa es que el usuario no pertenece al grupo docker y por tanto no tiene permiso de lectura/escritura sobre el socket /var/run/docker.sock. Nota que el error dice permission denied y no Cannot connect: el socket existe y el daemon está corriendo; es puramente un problema de permisos.

(b) Los comandos:

El primero añade el usuario al grupo sin quitarle los demás (-a); el segundo activa la pertenencia en la sesión actual. Cerrar sesión y volver a entrar es equivalente.

(c) Usar sudo docker siempre es incómodo y, sobre todo, engañoso: los ficheros que Docker cree quedarán con propietario root, los scripts y herramientas de tu editor que invoquen docker sin sudo seguirán fallando, y no ganas seguridad real, porque el daemon sigue ejecutándose como root de todas formas.

(d) La implicación es importante: pertenecer al grupo docker equivale a tener root en la máquina, porque desde el daemon se puede arrancar un contenedor privilegiado que monte y modifique el sistema de archivos del anfitrión. En un portátil personal es aceptable; en un servidor compartido hay que tratarlo como una concesión de privilegios, y considerar el modo rootless (lección 05-03).

Solución al ejercicio 3

En la segunda ejecución desaparecen estas líneas:

Y son sustituidas directamente por el saludo Hello from Docker!. El motivo es que la imagen ya está en la caché local del daemon tras la primera descarga: no hace falta contactar con Docker Hub, así que se salta todo el bloque de descarga y crea el contenedor de inmediato. Esta es una primera pista de algo central en Docker: la imagen se descarga una vez y se reutiliza tantas veces como quieras.

Sobre los contenedores: se han creado dos, uno por cada docker run (recuerda que run siempre crea un contenedor nuevo, no reutiliza el anterior). Ninguno sigue en ejecución: el proceso de hello-world imprime su mensaje y termina, y cuando el proceso principal de un contenedor termina, el contenedor pasa a estado Exited. Los dos siguen existiendo en el disco, ocupando espacio, hasta que los borres. En la lección 01-04 los verás con docker ps -a y aprenderás a eliminarlos.

Ya tienes Docker instalado y verificado. Por el camino has aprendido a distinguir Docker Engine (el motor nativo de Linux, libre y sin GUI) de Docker Desktop (la aplicación de escritorio con VM incluida para Windows, macOS y Linux, con condiciones de licencia en empresas grandes), y sabes que en Windows y macOS siempre hay una máquina virtual Linux por debajo, porque los contenedores necesitan un kernel Linux.

Has instalado los cinco paquetes que importan —docker-ce, docker-ce-cli, containerd.io, docker-buildx-plugin y docker-compose-plugin—, has dejado el servicio habilitado con systemctl enable --now docker, has añadido tu usuario al grupo docker sabiendo que eso equivale a conceder root, y has descifrado la salida de docker version, docker info y hello-world.

En esa última salida, el propio mensaje de Docker te ha adelantado el guion de la siguiente lección: el cliente contacta con el daemon, el daemon descarga la imagen del registro, crea el contenedor y devuelve la salida. En Arquitectura de Docker vas a abrir esa caja: qué es exactamente el daemon, qué pintan containerd y runc, qué es el socket /var/run/docker.sock y cómo encajan todas las piezas en un simple docker run.