Cheat sheet de Docker

Qué vas a provocar: Provocar los códigos 125, 127 y 137 (OOM, sin swap), y ver por qué un docker stop tarda 10 s y termina en 137 en vez de 143.

Necesitas: Docker Desktop corriendo (si no, los comandos fallan con failed to connect to the docker API) e internet para bajar busybox:1.38 y python:3.12-slim

1. Paso 1Copiar

   docker run --foo busybox:1.38; echo "exit=$?"

   Qué deberías ver: unknown flag: --foo y exit=125: el CLI lo rechaza antes de hablar con el daemon.

2. Paso 2Copiar

   docker run --rm busybox:1.38 no-existe; echo "exit=$?"

   Qué deberías ver: Un error del daemon que incluye exec: "no-existe": executable file not found in $PATH, y exit=127.

3. Paso 3Copiar

   docker run --name lab-oom --memory 32m --memory-swap 32m python:3.12-slim python -c 'x = b"x" * (200 * 1024 * 1024)'; echo "exit=$?"
   docker inspect -f '{{.State.OOMKilled}}' lab-oom

   Qué deberías ver: exit=137 y, casi siempre, true: sin swap (--memory-swap igual a --memory), el kernel mató a Python al pasar los 32 MB. Si ves false, containerd perdió el evento de OOM; un 137 sin stop ni kill ya apunta a memoria.

4. Paso 4Copiar

   docker run -d --name lab-stop busybox:1.38 sleep 300
   time docker stop lab-stop
   docker inspect -f '{{.State.ExitCode}}' lab-stop

   Qué deberías ver: Unos 10 s de espera y 137: sleep es el PID 1, no instala handler de SIGTERM y el kernel le descarta la señal; al final llega el SIGKILL.

5. Paso 5Copiar

   docker run -d --init --name lab-init busybox:1.38 sleep 300
   time docker stop lab-init
   docker inspect -f '{{.State.ExitCode}}' lab-init

   Qué deberías ver: Menos de un segundo y 143: docker-init (tini) es el PID 1, le reenvía el SIGTERM a sleep y sleep muere por esa señal (128 + 15).

6. Paso 6Copiar

   docker rm -f lab-oom lab-stop lab-init

   Qué deberías ver: Los tres nombres impresos: no queda nada del lab.

Verificado contra la documentación; no ejecutado aquí.

Qué vas a provocar: Recorrer la cadena completa contra un registry local y ver que el nombre de la imagen decide de dónde se baja.

Necesitas: Docker Desktop corriendo, curl (viene con macOS) e internet para bajar registry:3 y busybox:1.38

1. Paso 1Copiar

   docker run -d --name lab-registry -p 127.0.0.1:5001:5000 registry:3
   sleep 2; curl -s localhost:5001/v2/_catalog

   Qué deberías ver: {"repositories":[]}: un registry vacío en tu Mac. Se usa el 5001 porque en macOS el 5000 suele estar ocupado por AirPlay Receiver.

2. Paso 2Copiar

   cd "$(mktemp -d)"
   printf 'FROM busybox:1.38\nCMD ["echo", "hola desde la cadena"]\n' > Dockerfile
   docker build -t lab-hola:v1 .

   Qué deberías ver: El build muestra una línea naming to docker.io/library/lab-hola:v1: sin host en el nombre, Docker asume Docker Hub.

3. Paso 3Copiar

   docker run --rm localhost:5001/lab-hola:v1

   Qué deberías ver: Unable to find image 'localhost:5001/lab-hola:v1' locally y después un error de pull con not found: ese nombre no existe ni en tu máquina ni en el registry.

4. Paso 4Copiar

   docker tag lab-hola:v1 localhost:5001/lab-hola:v1
   docker push localhost:5001/lab-hola:v1

   Qué deberías ver: El push termina con v1: digest: sha256:… size: …

5. Paso 5Copiar

   docker rmi lab-hola:v1 localhost:5001/lab-hola:v1
   docker run --rm localhost:5001/lab-hola:v1

   Qué deberías ver: Unable to find image … locally, el pull desde localhost:5001 y la línea hola desde la cadena.

6. Paso 6Copiar

   curl -s localhost:5001/v2/_catalog

   Qué deberías ver: {"repositories":["lab-hola"]}

7. Paso 7Copiar

   docker rm -f -v lab-registry
   docker rmi localhost:5001/lab-hola:v1 registry:3

   Qué deberías ver: lab-registry, Untagged y Deleted: -v borra también el volumen anónimo del registry (/var/lib/registry). Solo queda busybox:1.38.

Verificado contra la documentación; no ejecutado aquí.

Qué vas a provocar: Ver qué hace cada instrucción en run: EXPOSE no publica, HEALTHCHECK sí corre, ENV llega al contenedor y ARG no, aunque queda en el historial.

Necesitas: Docker Desktop corriendo, curl e internet para bajar python:3.12-slim

1. Paso 1Copiar

   cd "$(mktemp -d)"
   cat > Dockerfile <<'EOF'
   FROM python:3.12-slim
   ARG BUILD_NOTE=solo-en-build
   ENV APP_PORT=8000
   WORKDIR /srv
   RUN echo "hola, build $BUILD_NOTE" > index.html
   USER 10001
   EXPOSE 8000
   HEALTHCHECK --interval=5s --timeout=2s --retries=3 \
     CMD ["python", "-c", "import urllib.request; urllib.request.urlopen('http://127.0.0.1:8000/', timeout=1)"]
   CMD ["python", "-m", "http.server", "8000"]
   EOF
   docker build -t lab-anat:1 .

   Qué deberías ver: El build muestra una línea naming to docker.io/library/lab-anat:1.

2. Paso 2Copiar

   docker run -d --name lab-anat lab-anat:1
   sleep 8; curl -sS localhost:8000; docker ps --filter name=lab-anat --format "{{.Status}}"

   Qué deberías ver: curl: (7) Failed to connect to localhost port 8000 …, pero STATUS dice Up … (healthy): el servidor responde adentro y EXPOSE no publicó nada.

3. Paso 3Copiar

   docker port lab-anat; docker exec lab-anat sh -c 'id -u; env | grep -E "APP_PORT|BUILD_NOTE"'

   Qué deberías ver: docker port no imprime nada; id -u da 10001 y solo aparece APP_PORT=8000: el ARG no llega al contenedor.

4. Paso 4Copiar

   docker history --no-trunc lab-anat:1 | grep BUILD_NOTE

   Qué deberías ver: Las filas del ARG y del RUN muestran BUILD_NOTE=solo-en-build: el valor de un ARG queda a la vista de quien tenga la imagen.

5. Paso 5Copiar

   docker rm -f lab-anat
   docker run -d --name lab-anat -p 127.0.0.1:8000:8000 lab-anat:1
   sleep 2; curl -s localhost:8000

   Qué deberías ver: hola, build solo-en-build: con -p, el puerto sí llega a tu Mac.

6. Paso 6Copiar

   docker rm -f lab-anat
   docker rmi lab-anat:1

   Qué deberías ver: El contenedor y la imagen del lab, borrados.

Verificado contra la documentación; no ejecutado aquí.

Qué vas a provocar: Ver la cascada: con COPY . . arriba, editar una línea de código reinstala numpy; con el orden del C01, no. Después, ver cómo un checkpoint en el contexto engorda la imagen y cómo lo saca .dockerignore.

Necesitas: Docker Desktop corriendo e internet para bajar python:3.12-slim y la wheel de numpy

1. Paso 1Copiar

   cd "$(mktemp -d)"
   printf 'numpy==2.5.3\n' > requirements.txt
   printf 'import numpy as np\nprint("v1", np.__version__)\n' > app.py
   cat > Dockerfile <<'EOF'
   FROM python:3.12-slim
   WORKDIR /app
   COPY . .
   RUN pip install --no-cache-dir -r requirements.txt
   CMD ["python", "app.py"]
   EOF
   docker build -t lab-cache:mal .

   Qué deberías ver: El primer build baja la base e instala numpy (unos segundos).

2. Paso 2Copiar

   printf 'import numpy as np\nprint("v2", np.__version__)\n' > app.py
   docker build --progress=plain -t lab-cache:mal . 2>&1 | grep -E 'CACHED|Collecting'

   Qué deberías ver: Collecting numpy==2.5.3 otra vez: cambió app.py, se invalidó COPY . . y todo lo que sigue. Solo los pasos de arriba salen CACHED.

3. Paso 3Copiar

   cat > Dockerfile <<'EOF'
   FROM python:3.12-slim
   WORKDIR /app
   COPY requirements.txt .
   RUN pip install --no-cache-dir -r requirements.txt
   COPY . .
   CMD ["python", "app.py"]
   EOF
   docker build -t lab-cache:bien .
   printf 'import numpy as np\nprint("v3", np.__version__)\n' > app.py
   docker build --progress=plain -t lab-cache:bien . 2>&1 | grep -B1 CACHED

   Qué deberías ver: El paso RUN pip install … aparece seguido de CACHED y no hay Collecting: solo se rehízo COPY . . al final.

4. Paso 4Copiar

   dd if=/dev/urandom of=checkpoint.pt bs=1m count=200
   docker build --progress=plain -t lab-cache:bien . 2>&1 | grep 'transferring context'
   docker images lab-cache

   Qué deberías ver: transferring context de unos 200 MB, y lab-cache:bien unos 200 MB más pesada que lab-cache:mal: COPY . . metió el checkpoint en la imagen. En Docker 29 míralo en CONTENT SIZE; DISK USAGE suma además la copia descomprimida (los datos aleatorios no se comprimen).

5. Paso 5Copiar

   printf '*.pt\n' > .dockerignore
   docker build --progress=plain -t lab-cache:bien . 2>&1 | grep 'transferring context'
   docker images lab-cache

   Qué deberías ver: El contexto vuelve a pesar unos pocos kB y la imagen vuelve a su tamaño. Ojo: *.pt solo cubre la raíz del contexto; para subcarpetas, **/*.pt.

6. Paso 6Copiar

   rm -f checkpoint.pt
   docker rmi lab-cache:mal lab-cache:bien
   docker image prune -f

   Qué deberías ver: Untagged y Deleted; prune borra las imágenes sin tag que dejaron los rebuilds (Docker 29 ya no las lista por defecto) y cualquier otra colgante de tu Mac.

Verificado contra la documentación; no ejecutado aquí.

Qué vas a provocar: Comparar en docker images una imagen de una etapa (con el compilador adentro) y la misma en multi-stage (solo el binario).

Necesitas: Docker Desktop corriendo e internet para bajar alpine:3.24 y los paquetes de apk

1. Paso 1Copiar

   cd "$(mktemp -d)"
   printf '#include <stdio.h>\nint main(void) { puts("hola"); return 0; }\n' > hola.c
   cat > Dockerfile.single <<'EOF'
   FROM alpine:3.24
   WORKDIR /src
   RUN apk add --no-cache gcc musl-dev
   COPY hola.c .
   RUN gcc -static -O2 -o /usr/local/bin/hola hola.c
   CMD ["hola"]
   EOF
   docker build -f Dockerfile.single -t lab-ms:single .

   Qué deberías ver: Una imagen que trae gcc, binutils y headers, aunque el proceso solo necesita el binario.

2. Paso 2Copiar

   cat > Dockerfile.multi <<'EOF'
   FROM alpine:3.24 AS builder
   WORKDIR /src
   RUN apk add --no-cache gcc musl-dev
   COPY hola.c .
   RUN gcc -static -O2 -o /usr/local/bin/hola hola.c
   
   FROM alpine:3.24
   COPY --from=builder /usr/local/bin/hola /usr/local/bin/hola
   USER 10001
   CMD ["hola"]
   EOF
   docker build -f Dockerfile.multi -t lab-ms:multi .

   Qué deberías ver: La etapa builder sale CACHED (son las mismas instrucciones del paso 1) y la final solo agrega el binario.

3. Paso 3Copiar

   docker images lab-ms
   docker history lab-ms:single

   Qué deberías ver: single pesa más de 10 veces lo que pesa multi (en cualquiera de las dos columnas), y en docker history la capa del apk add domina; multi son unos pocos MB: alpine más un binario estático.

4. Paso 4Copiar

   docker run --rm lab-ms:multi
   docker run --rm lab-ms:multi id -u

   Qué deberías ver: hola y 10001: corre igual, sin compilador y sin root.

5. Paso 5Copiar

   docker rmi lab-ms:single lab-ms:multi

   Qué deberías ver: Untagged y Deleted: las imágenes del lab, borradas.

Verificado contra la documentación; no ejecutado aquí.

Qué vas a provocar: Provocar los finales típicos de un contenedor (termina enseguida, falla y se reinicia, muere por OOM, se frena por CPU) y leerlos con ps -a, logs, inspect y stats.

Necesitas: Docker Desktop corriendo (si está apagado, el CLI responde failed to connect to the docker API at unix:///Users/…/.docker/run/docker.sock, o Cannot connect to the Docker daemon at …). La primera vez se baja python:3.12-slim, ≈ 44 MB para arm64.

1. Paso 1Copiar

   docker run -d --name lab-run python:3.12-slim
   docker ps --filter name=lab-run
   docker ps -a --filter name=lab-run

   Qué deberías ver: El primer comando imprime un ID. docker ps muestra solo la cabecera; docker ps -a muestra lab-run con STATUS Exited (0): el CMD de la imagen es python3 (un REPL) y, sin -i, lee fin de archivo y termina sin error.

2. Paso 2Copiar

   docker run -it --rm python:3.12-slim

   Qué deberías ver: Ahora sí aparece el prompt >>> porque -i deja stdin abierto y -t da una terminal. Sal con exit(); por el --rm, el contenedor ya no figura en docker ps -a.

3. Paso 3Copiar

   docker run -d --name lab-crash --restart on-failure:3 python:3.12-slim python -c "import sys; print('arranco y fallo', flush=True); sys.exit(1)"
   sleep 8
   docker inspect -f '{{.State.Status}} exit={{.State.ExitCode}} reinicios={{.RestartCount}}' lab-crash
   docker logs lab-crash

   Qué deberías ver: exited exit=1 reinicios=3, y cuatro líneas arranco y fallo: el arranque más 3 reinicios, separados por 100, 200 y 400 ms. Si alcanzas a correr docker ps -a durante el primer segundo, verás Restarting (1).

4. Paso 4Copiar

   docker run --name lab-oom --memory 32m --memory-swap 32m python:3.12-slim python -c "b = bytearray(300 * 1024 * 1024); print('cupo')"
   echo "exit del run: $?"
   docker inspect -f 'exit={{.State.ExitCode}} oom={{.State.OOMKilled}}' lab-oom

   Qué deberías ver: No imprime cupo: el run devuelve 137 e inspect dice exit=137 oom=true. El kernel mató a python al pasar los 32 MB, sin swap porque --memory-swap es igual a --memory (sin ese flag tendría 32 MB más de swap). oom=true confirma memoria; un false no la descarta del todo si nadie corrió stop ni kill: containerd a veces pierde el evento de OOM.

5. Paso 5Copiar

   docker run -d --name lab-cpu --cpus 0.5 --memory 128m python:3.12-slim python -c "while True: pass"
   sleep 3
   docker stats --no-stream lab-cpu

   Qué deberías ver: CPU % ronda el 50 % (medio core) y MEM USAGE / LIMIT muestra el tope de 128MiB. Pasarse de CPU no mata el contenedor: lo frena.

Verificado contra la documentación; no ejecutado aquí. No ejecutado aquí: no había daemon de Docker en la sesión. Comandos, flags, defaults y mensajes verificados contra docs.docker.com y el código de moby 29.9.1. El backoff (100 ms ×2, tope 1 min) y el conteo de on-failure:N salen de su restart manager: la doc dice que la política aplica después de 10 s arriba, pero en el código esos 10 s solo devuelven la espera a 100 ms. OOMKilled lo marca un evento de containerd que se puede perder (containerd #8893).

Qué vas a provocar: Ver quién es el PID 1, cuánto tarda docker stop y con qué código sale en cuatro casos: forma shell, forma exec con handler, PID 1 sin handler y --init.

Necesitas: Docker Desktop corriendo (si está apagado, el CLI responde failed to connect to the docker API at unix:///Users/…/.docker/run/docker.sock, o Cannot connect to the Docker daemon at …). La primera vez se baja python:3.12-slim, ≈ 44 MB para arm64.

1. Paso 1Copiar

   mkdir -p ~/lab-docker/pid1 && cd ~/lab-docker/pid1
   cat > app.py <<'EOF'
   import os, signal, sys, time
   
   def apagar(signum, frame):
       print("SIGTERM recibido: cierro limpio", flush=True)
       sys.exit(0)
   
   signal.signal(signal.SIGTERM, apagar)
   print(f"app lista, mi PID es {os.getpid()}", flush=True)
   while True:
       time.sleep(1)
   EOF
   printf 'FROM python:3.12-slim\nCOPY app.py /app.py\nCMD python -u /app.py\n' > Dockerfile.shell
   printf 'FROM python:3.12-slim\nCOPY app.py /app.py\nCMD ["python", "-u", "/app.py"]\n' > Dockerfile.exec
   docker build -t lab-pid1:shell -f Dockerfile.shell .
   docker build -q -t lab-pid1:exec -f Dockerfile.exec .

   Qué deberías ver: Dos imágenes que solo difieren en la línea CMD. El primer build termina con el aviso JSONArgsRecommended (…to prevent unintended behavior related to OS signals): BuildKit ya sospecha de la forma shell.

2. Paso 2Copiar

   docker run -d --name pid1-shell lab-pid1:shell
   sleep 1
   docker logs pid1-shell
   docker top pid1-shell

   Qué deberías ver: El log dice app lista, mi PID es N, con N distinto de 1. docker top muestra dos procesos: /bin/sh -c python -u /app.py (el PID 1 del contenedor) y su hijo python -u /app.py. En una base Debian como esta, /bin/sh es dash y se queda esperando a su hijo.

3. Paso 3Copiar

   time docker stop pid1-shell
   docker inspect -f 'exit={{.State.ExitCode}}' pid1-shell
   docker logs pid1-shell

   Qué deberías ver: docker stop tarda ≈ 10 s (zsh lo reporta al final de la línea, como … total), exit=137, y en el log no aparece SIGTERM recibido: sh, sin handler y como PID 1, descartó la señal; al vencer el plazo llegó el SIGKILL.

4. Paso 4Copiar

   docker run -d --name pid1-exec lab-pid1:exec
   sleep 1
   docker logs pid1-exec
   time docker stop pid1-exec
   docker inspect -f 'exit={{.State.ExitCode}}' pid1-exec
   docker logs pid1-exec

   Qué deberías ver: Ahora el log dice mi PID es 1, docker stop vuelve en menos de un segundo, exit=0, y el log termina con SIGTERM recibido: cierro limpio.

5. Paso 5Copiar

   docker run -d --name pid1-sinhandler python:3.12-slim python -c "import time; time.sleep(600)"
   time docker stop pid1-sinhandler
   docker run -d --name pid1-init --init python:3.12-slim python -c "import time; time.sleep(600)"
   time docker stop pid1-init
   docker inspect -f '{{.Name}} exit={{.State.ExitCode}}' pid1-sinhandler pid1-init

   Qué deberías ver: Sin handler, python como PID 1 también ignora SIGTERM: ≈ 10 s y /pid1-sinhandler exit=137. Con --init, tini es el PID 1 y le reenvía la señal a python, que ya no es PID 1 y muere con la acción por defecto: menos de un segundo y /pid1-init exit=143 (128 + 15).

Verificado contra la documentación; no ejecutado aquí. No ejecutado aquí: no había daemon de Docker en la sesión. Comandos, flags, defaults y mensajes verificados contra docs.docker.com y el código de moby 29.9.1, BuildKit, uvicorn y tini. Que dash se quede como PID 1 sale del parche 0004 de Debian, que desactiva el exec de sh -c (dash 0.5.12-12 de trixie, la base de python:3.12-slim); que tini salga con 128 + n, de su código.

Qué vas a provocar: Ver por qué localhost y el bridge por defecto no sirven entre contenedores, arreglarlo con una red propia, y provocar el error de un servidor que escucha en 127.0.0.1.

Necesitas: Docker Desktop corriendo (si está apagado, el CLI responde failed to connect to the docker API at unix:///Users/…/.docker/run/docker.sock, o Cannot connect to the Docker daemon at …). La primera vez se baja python:3.12-slim, ≈ 44 MB para arm64. curl ya viene en macOS.

1. Paso 1Copiar

   docker run -d --name lab-web python:3.12-slim python -u -m http.server 8000 --bind 0.0.0.0
   docker run --rm python:3.12-slim python -c "import urllib.request as u; print(u.urlopen('http://localhost:8000', timeout=3).status)"

   Qué deberías ver: El segundo comando termina en urllib.error.URLError: <urlopen error [Errno 111] Connection refused>: localhost es el contenedor cliente, donde nadie escucha en el 8000.

2. Paso 2Copiar

   docker run --rm python:3.12-slim python -c "import urllib.request as u; print(u.urlopen('http://lab-web:8000', timeout=3).status)"

   Qué deberías ver: Falla el DNS: urllib.error.URLError: <urlopen error [Errno -2] Name or service not known> (el resolver contestó que lab-web no existe) o, según el DNS de la VM, [Errno -3] Temporary failure in name resolution. Los dos están en el bridge por defecto, que no resuelve nombres de contenedor.

3. Paso 3Copiar

   docker network create lab-net
   docker network connect lab-net lab-web
   docker run --rm --network lab-net python:3.12-slim python -c "import urllib.request as u; print(u.urlopen('http://lab-web:8000', timeout=3).status)"

   Qué deberías ver: Imprime 200: en una red creada por ti, Docker resuelve lab-web a su IP en esa red. Compose hace lo mismo con la red del proyecto (classifier-c01_default en C01).

4. Paso 4Copiar

   docker run -d --name lab-loop -p 127.0.0.1:8001:8000 python:3.12-slim python -u -m http.server 8000 --bind 127.0.0.1
   sleep 1
   docker logs lab-loop
   curl -sS --max-time 5 127.0.0.1:8001
   docker exec lab-loop python -c "import urllib.request as u; print(u.urlopen('http://localhost:8000', timeout=3).status)"

   Qué deberías ver: El log dice Serving HTTP on 127.0.0.1 port 8000. Desde tu Mac, curl falla sin respuesta HTTP (en Docker Desktop suele ser Empty reply from server o Connection reset by peer); desde adentro, 200. Si adentro funciona y afuera no, el servidor escucha solo en el loopback del contenedor.

5. Paso 5Copiar

   docker rm -f lab-loop
   docker run -d --name lab-loop -p 127.0.0.1:8001:8000 python:3.12-slim python -u -m http.server 8000 --bind 0.0.0.0
   sleep 1
   curl -sS -o /dev/null -w "%{http_code}\n" 127.0.0.1:8001
   docker port lab-loop

   Qué deberías ver: 200, y docker port muestra 8000/tcp -> 127.0.0.1:8001: publicado solo en el loopback de tu Mac, con el servidor escuchando en todas las interfaces del contenedor.

Verificado contra la documentación; no ejecutado aquí. No ejecutado aquí: no había daemon de Docker en la sesión. Comandos, flags, defaults y mensajes verificados contra docs.docker.com y el código de moby 29.9.1. Los textos de DNS son los de glibc (la imagen es Debian); en alpine, Python (musl) dice Name does not resolve y las herramientas de busybox, bad address 'lab-web'. El error exacto de curl contra un servidor en 127.0.0.1 no está documentado; por eso van las dos variantes.

Qué vas a provocar: Provocar el Permission denied de un usuario no root en un volumen, ver de quién es la carpeta y arreglarlo desde el Dockerfile; de paso, un bind mount de solo lectura.

Necesitas: Docker Desktop corriendo (si está apagado, el CLI responde failed to connect to the docker API at unix:///Users/…/.docker/run/docker.sock, o Cannot connect to the Docker daemon at …). La primera vez se baja python:3.12-slim, ≈ 44 MB para arm64. ~/lab-docker está dentro de /Users, que Docker Desktop comparte por defecto.

1. Paso 1Copiar

   mkdir -p ~/lab-docker/vol && cd ~/lab-docker/vol
   docker volume create lab-datos
   docker run --rm --user 10001:10001 -v lab-datos:/datos python:3.12-slim sh -c 'id; ls -ldn /datos; touch /datos/ok'

   Qué deberías ver: uid=10001 gid=10001 groups=10001; la carpeta aparece como drwxr-xr-x … 0 0 … /datos (de root) y touch: cannot touch '/datos/ok': Permission denied.

2. Paso 2Copiar

   docker volume inspect -f '{{.Mountpoint}}' lab-datos

   Qué deberías ver: /var/lib/docker/volumes/lab-datos/_data: una ruta dentro de la VM de Docker Desktop, no de tu Mac; no la vas a encontrar en Finder.

3. Paso 3Copiar

   printf 'FROM python:3.12-slim\nRUN mkdir -p /datos && chown 10001:10001 /datos\nUSER 10001:10001\n' > Dockerfile
   docker build -q -t lab-vol .
   docker run --rm -v lab-datos:/datos lab-vol sh -c 'ls -ldn /datos; touch /datos/ok && echo escribí'
   docker run --rm -v lab-datos:/datos python:3.12-slim ls -ln /datos

   Qué deberías ver: Ahora /datos es de 10001 10001 e imprime escribí: el volumen estaba vacío, así que al crear el contenedor Docker copió la carpeta de la imagen con su dueño. El último comando (otro contenedor, otra imagen) sigue viendo ok: el dato vive en el volumen.

4. Paso 4Copiar

   mkdir -p config && echo 'umbral: 0.5' > config/app.yaml
   docker run --rm -v "$PWD/config:/config:ro" python:3.12-slim sh -c 'cat /config/app.yaml; touch /config/x'

   Qué deberías ver: Lee umbral: 0.5 y después falla con touch: cannot touch '/config/x': Read-only file system.

Verificado contra la documentación; no ejecutado aquí. No ejecutado aquí: no había daemon de Docker en la sesión. Comandos, flags, defaults y mensajes verificados contra docs.docker.com y el código de moby 29.9.1. La copia del contenido y del dueño a un volumen vacío sale de populateVolume en moby (solo al crear el contenedor) y de CopyDir de containerd/continuity; la doc no habla del dueño.

Qué vas a provocar: Ver a una API arrancar antes de que su dependencia acepte conexiones, y arreglarlo con healthcheck y condition: service_healthy: el patrón triton → gateway de C01, sin GPU.

Necesitas: Docker Desktop corriendo (si está apagado, el CLI responde failed to connect to the docker API at unix:///Users/…/.docker/run/docker.sock, o Cannot connect to the Docker daemon at …). La primera vez se baja python:3.12-slim, ≈ 44 MB para arm64. Compose v2 o posterior (docker compose, sin guion); start_interval necesita Engine 25 o más nuevo.

1. Paso 1Copiar

   mkdir -p ~/lab-docker/compose && cd ~/lab-docker/compose
   cat > compose.yaml <<'EOF'
   name: lab-compose
   services:
     db:
       image: python:3.12-slim
       init: true
       # Simula una base (o Triton cargando el engine): tarda 8 s en aceptar conexiones
       command: ["sh", "-c", "sleep 8 && exec python -u -m http.server 8000 --bind 0.0.0.0"]
     api:
       image: python:3.12-slim
       init: true
       # Al arrancar se conecta una vez a db, como una app que abre su pool de conexiones
       command: ["python", "-c", "import urllib.request as u; print('db respondió', u.urlopen('http://db:8000', timeout=2).status)"]
       depends_on:
         - db
   EOF
   docker compose up -d
   sleep 2
   docker compose ps -a
   docker compose logs api

   Qué deberías ver: up -d vuelve enseguida. ps -a muestra api en Exited (1) y db en Up; el log de api termina en [Errno 111] Connection refused: arrancó cuando el contenedor db ya existía, pero su servidor todavía no escuchaba.

2. Paso 2Copiar

   cat > compose.yaml <<'EOF'
   name: lab-compose
   services:
     db:
       image: python:3.12-slim
       init: true
       command: ["sh", "-c", "sleep 8 && exec python -u -m http.server 8000 --bind 0.0.0.0"]
       healthcheck:
         test: ["CMD", "python", "-c", "import urllib.request as u; u.urlopen('http://localhost:8000', timeout=1)"]
         interval: 2s
         timeout: 2s
         retries: 3
         start_period: 30s
         start_interval: 1s
     api:
       image: python:3.12-slim
       init: true
       command: ["python", "-c", "import urllib.request as u; print('db respondió', u.urlopen('http://db:8000', timeout=2).status)"]
       depends_on:
         db:
           condition: service_healthy
   EOF
   docker compose config -q && docker compose up -d --force-recreate
   docker compose ps -a
   docker compose logs api

   Qué deberías ver: Ahora up -d tarda unos 10 s: Compose muestra db en Waiting y luego Healthy, y recién entonces arranca api. El log de api dice db respondió 200 y su estado es Exited (0).

3. Paso 3Copiar

   docker inspect -f '{{.State.Health.Status}} fallos_seguidos={{.State.Health.FailingStreak}}' lab-compose-db-1

   Qué deberías ver: healthy fallos_seguidos=0. Con -f '{{json .State.Health}}' ves además la salida de los últimos chequeos: lo primero que miras cuando un healthcheck falla y no sabes por qué.

4. Paso 4Copiar

   sed -i '' 's#localhost:8000#localhost:9999#' compose.yaml
   docker compose up -d --force-recreate

   Qué deberías ver: Opcional, el caso unhealthy: el chequeo apunta a un puerto vacío. A los ≈ 34 s (30 de start_period + 2 chequeos más, cada 2 s), up falla con dependency failed to start: container lab-compose-db-1 is unhealthy, y api no arranca.

Verificado contra la documentación; no ejecutado aquí. No ejecutado aquí: no había daemon de Docker en la sesión. Comandos, flags, defaults y mensajes verificados contra docs.docker.com y el código de moby 29.9.1. Los dos compose.yaml del lab pasan docker compose config con Compose v5.0.2; los mensajes Waiting, Healthy y dependency failed to start salen del código de Compose v5.6.0, y los tiempos del healthcheck, de daemon/health.go.

Qué vas a provocar: Construir la misma imagen para arm64 y para amd64 en tu Mac, confirmar la arquitectura de cada una y medir cuánto cuesta la emulación.

Necesitas: Docker Desktop corriendo; ≈ 0.1 GB de descarga (python:3.12-slim en dos arquitecturas).

1. Paso 1Copiar

   cd "$(mktemp -d)" && printf 'FROM python:3.12-slim\nCMD ["python", "-c", "import platform; print(platform.machine())"]\n' > Dockerfile && cat Dockerfile

   Qué deberías ver: Un Dockerfile de dos líneas cuyo CMD imprime la arquitectura que ve Python.

2. Paso 2Copiar

   docker build -t w3-arch:nativa . && docker build --platform linux/amd64 -t w3-arch:amd64 .

   Qué deberías ver: Dos builds. El segundo baja la variante amd64 de python:3.12-slim (≈ 43 MB comprimida).

3. Paso 3Copiar

   for t in nativa amd64; do docker image inspect --format "$t → {{.Os}}/{{.Architecture}}" w3-arch:$t; done

   Qué deberías ver: nativa → linux/arm64 y amd64 → linux/amd64.

4. Paso 4Copiar

   docker run --rm w3-arch:nativa; docker run --rm w3-arch:amd64

   Qué deberías ver: aarch64. Después, WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested, y x86_64: corrió emulada.

5. Paso 5Copiar

   time docker run --rm w3-arch:nativa python -c "sum(i * i for i in range(10**7))"; time docker run --rm --platform linux/amd64 w3-arch:amd64 python -c "sum(i * i for i in range(10**7))"

   Qué deberías ver: Anota los dos valores total de time: la amd64 tarda claramente más. Cuánto depende de si Docker Desktop emula con QEMU o con Rosetta. Ese costo es del emulador, no de tu código.

6. Paso 6Copiar

   docker buildx imagetools inspect python:3.12-slim | grep Platform

   Qué deberías ver: Una línea por plataforma (linux/amd64, linux/arm64/v8, linux/arm/v7, linux/s390x…) y varias unknown/unknown, que son las attestations. Lo lee del registry sin bajar capas.

7. Paso 7Copiar

   docker build --platform linux/amd64,linux/arm64 -t w3-arch:multi . && docker image inspect --platform linux/amd64 --format '{{.Architecture}}' w3-arch:multi

   Qué deberías ver: amd64. Funciona en local porque Docker Desktop usa por defecto el image store de containerd, que guarda índices. Con el image store clásico necesitarías un builder docker-container y --push.

8. Paso 8Copiar

   docker rmi w3-arch:nativa w3-arch:amd64 w3-arch:multi

   Qué deberías ver: Untagged y Deleted para las tres.

Verificado contra la documentación; no ejecutado aquí.

Qué vas a provocar: Ver que un tag se mueve y un digest no: dos tags para la misma imagen, un latest que cambia de contenido y un run por digest que siempre trae lo mismo.

Necesitas: Docker Desktop corriendo e internet para bajar registry:3 y busybox:1.38

1. Paso 1Copiar

   docker run -d --name lab-registry -p 127.0.0.1:5001:5000 registry:3

   Qué deberías ver: El ID del contenedor: un registry local en localhost:5001 (si sigue corriendo del lab de la cadena, salta este paso).

2. Paso 2Copiar

   cd "$(mktemp -d)"
   printf 'FROM busybox:1.38\nCMD ["echo", "soy v1"]\n' > Dockerfile
   docker build -t localhost:5001/lab/app:a1b2c3d -t localhost:5001/lab/app:latest .
   docker images localhost:5001/lab/app

   Qué deberías ver: Dos nombres, a1b2c3d y latest, con el mismo ID: un tag es solo un nombre.

3. Paso 3Copiar

   docker push localhost:5001/lab/app:a1b2c3d
   docker push localhost:5001/lab/app:latest
   REF=$(docker image inspect --format '{{index .RepoDigests 0}}' localhost:5001/lab/app:a1b2c3d)
   echo $REF

   Qué deberías ver: Los dos push terminan con el mismo digest: sha256:…, y REF queda como localhost:5001/lab/app@sha256:…

4. Paso 4Copiar

   printf 'FROM busybox:1.38\nCMD ["echo", "soy v2"]\n' > Dockerfile
   docker build -t localhost:5001/lab/app:e4f5a6b -t localhost:5001/lab/app:latest .
   docker push localhost:5001/lab/app:latest

   Qué deberías ver: El push de latest imprime otro digest: latest ya apunta a v2, mientras a1b2c3d sigue en v1.

5. Paso 5Copiar

   docker run --rm localhost:5001/lab/app:latest
   docker run --rm localhost:5001/lab/app:a1b2c3d
   docker run --rm "$REF"

   Qué deberías ver: soy v2, soy v1, soy v1: el mismo nombre latest cambió de contenido; el digest no puede.

6. Paso 6Copiar

   docker rm -f -v lab-registry
   docker rmi localhost:5001/lab/app:latest localhost:5001/lab/app:e4f5a6b localhost:5001/lab/app:a1b2c3d

   Qué deberías ver: Untagged y Deleted; -v borra también el volumen anónimo del registry. Quedan registry:3 y busybox:1.38: bórralos con docker rmi si quieres.

Verificado contra la documentación; no ejecutado aquí.

Qué vas a provocar: Provocar cinco de las fallas en tu Mac (sale en el acto, OOM, exec format error y CRLF, puerto en 127.0.0.1, volumen sin permiso), confirmarlas con el comando de la tabla y arreglarlas.

Necesitas: Docker Desktop corriendo; alpine:3.24 y python:3.12-slim (≈ 50 MB); curl, que viene con macOS.

1. Paso 1Copiar

   docker run -d --name w3-sale python:3.12-slim python -c "print('listo')"; sleep 2; docker ps -a --filter name=w3-sale --format '{{.Status}}'; docker logs w3-sale

   Qué deberías ver: Exited (0) … y listo. No es un error: el CMD terminó. Un servidor no debe terminar.

2. Paso 2Copiar

   docker run --name w3-oom --memory 32m --memory-swap 32m python:3.12-slim python -c "x = b'x' * (512 * 1024 * 1024)"; echo "exit=$?"; docker inspect --format '{{.State.ExitCode}} {{.State.OOMKilled}}' w3-oom

   Qué deberías ver: exit=137 sin traceback, y 137 true: el kernel lo mató por memoria. Con --memory-swap igual a --memory no hay swap que lo disimule.

3. Paso 3Copiar

   mkdir -p /tmp/w3-diag && cd /tmp/w3-diag && printf 'echo hola\n' > sin-shebang.sh && printf '#!/bin/sh\r\necho hola\r\n' > crlf.sh && chmod +x sin-shebang.sh crlf.sh && printf 'FROM alpine:3.24\nCOPY sin-shebang.sh crlf.sh /\n' > Dockerfile && docker build -q -t w3-diag .

   Qué deberías ver: Imprime el id de la imagen (sha256:…). Dos scripts: uno sin shebang y otro con finales de línea CRLF.

4. Paso 4Copiar

   docker run --rm --entrypoint /sin-shebang.sh w3-diag; echo "exit=$?"; docker run --rm --entrypoint /crlf.sh w3-diag; echo "exit=$?"

   Qué deberías ver: exec /sin-shebang.sh: exec format error y exit=255; después, exec /crlf.sh: no such file or directory y exit=255. Los dos archivos existen: lo que falla es ejecutarlos.

5. Paso 5Copiar

   od -c crlf.sh | head -1; tr -d '\r' < crlf.sh > lf.sh && od -c lf.sh | head -1

   Qué deberías ver: La primera línea muestra \r \n después de #!/bin/sh; la segunda, solo \n. Ese \r convierte el intérprete en /bin/sh\r, que no existe.

6. Paso 6Copiar

   docker run -d --name w3-port -p 127.0.0.1:8000:8000 python:3.12-slim python -m http.server 8000 --bind 127.0.0.1; sleep 2; curl -sS -o /dev/null -w '%{http_code}\n' 127.0.0.1:8000

   Qué deberías ver: curl falla (Empty reply from server o Connection reset by peer, según la versión de Docker Desktop) y escribe 000: el puerto está publicado, pero el servidor escucha solo en el 127.0.0.1 del contenedor.

7. Paso 7Copiar

   docker rm -f w3-port && docker run -d --name w3-port -p 127.0.0.1:8000:8000 python:3.12-slim python -m http.server 8000 --bind 0.0.0.0; sleep 2; curl -sS -o /dev/null -w '%{http_code}\n' 127.0.0.1:8000

   Qué deberías ver: 200. El 127.0.0.1 de -p es el de tu Mac: publica solo para tu máquina. Adentro, escuchar en 0.0.0.0 es lo que hace el CMD del gateway de C01 con --host 0.0.0.0.

8. Paso 8Copiar

   docker run --rm -v w3-datos:/data --user 10001 alpine:3.24 touch /data/x; docker run --rm -v w3-datos:/data alpine:3.24 ls -ldn /data

   Qué deberías ver: touch: /data/x: Permission denied, y /data es de 0 0 (root) con drwxr-xr-x: el volumen nuevo lo creó root y el proceso es el UID 10001.

9. Paso 9Copiar

   docker run --rm -v w3-datos:/data alpine:3.24 chown 10001:10001 /data && docker run --rm -v w3-datos:/data --user 10001 alpine:3.24 sh -c 'touch /data/x && ls -ln /data'

   Qué deberías ver: x aparece con dueño 10001. En un Dockerfile se logra lo mismo creando el directorio con chown: un volumen nombrado nuevo copia el dueño y los permisos del directorio de la imagen.

10. Paso 10Copiar

    cd ~ && docker rm -f w3-sale w3-oom w3-port; docker volume rm w3-datos; docker rmi w3-diag; rm -rf /tmp/w3-diag

    Qué deberías ver: Los nombres de lo que se borró. alpine:3.24 y python:3.12-slim quedan en cache para otros labs.

Verificado contra la documentación; no ejecutado aquí.

Qué vas a provocar: Reconocer los 26 mensajes en 5 minutos: para cada uno, decir en voz alta de qué capa viene (CLI, daemon, build, runc o tu proceso), la causa más probable y el primer comando.

Necesitas: Una terminal de macOS; Docker Desktop corriendo solo para los dos últimos pasos.

1. Paso 1Copiar

   ronda() { printf '%s\n' 'Cannot connect to the Docker daemon' 'failed to connect to the docker API' 'permission denied while trying to connect to the docker API' 'exec format error' 'executable file not found in $PATH' 'exec /entrypoint.sh: no such file or directory' 'port is already allocated' 'pull access denied' 'manifest unknown · failed to resolve reference' 'no matching manifest for linux/arm64/v8' 'could not select device driver "" with capabilities: [[gpu]]' '"/requirements.txt": not found' 'did not complete successfully: exit code: 1' 'no space left on device' 'OOMKilled' 'the input device is not a TTY · cannot attach stdin to a TTY-enabled container' 'is already in use by container' 'requested access to the resource is denied' 'dependency failed to start' 'Name or service not known · Temporary failure in name resolution' '[Errno 111] Connection refused' 'ModuleNotFoundError' 'CUDA driver version is insufficient for CUDA runtime version' 'error getting credentials' 'invalid reference format' 'unknown flag' | sort -R | head -5; }; ronda

   Qué deberías ver: Cinco mensajes al azar. Para cada uno, en menos de 30 s y en voz alta: la capa, la causa probable y el primer comando. Después compáralo con la tabla.

2. Paso 2Copiar

   ronda

   Qué deberías ver: Otra ronda de cinco. Repite hasta completar 5 minutos; la meta es 5 de 5 sin mirar.

3. Paso 3Copiar

   docker run --gpu all alpine:3.24 true; echo "exit=$?"

   Qué deberías ver: unknown flag: --gpu, la línea de uso, Run 'docker run --help' for more information y exit=125. Lo rechaza el CLI, así que no necesita Docker Desktop corriendo.

4. Paso 4Copiar

   docker run MiImagen; echo "exit=$?"

   Qué deberías ver: docker: invalid reference format: repository name (library/MiImagen) must be lowercase y exit=125.

5. Paso 5Copiar

   echo | docker run -it alpine:3.24 true

   Qué deberías ver: Con Docker CLI 29.0–29.3: the input device is not a TTY. Desde 29.4: cannot attach stdin to a TTY-enabled container because stdin is not a terminal. Es el mismo problema: -t sin terminal.

Verificado contra la documentación; no ejecutado aquí.