Generador de comandos Docker y Podman
Comandos docker y podman de uso diario: shell, logs, exec, run, build, compose.
Acerca de esta herramienta
Elige lo que quieres hacer, como abrir una shell en un contenedor, seguir sus logs, ejecutar un comando, copiar archivos, inspeccionarlo, construir o limpiar imágenes, o manejar Docker Compose, y obtén el comando docker o podman exacto con cada opción explicada. El generador de run también convierte un contenedor en un archivo Compose, y los comandos run pegados se pueden importar y editar.
Cómo se usa
- Elige Docker o Podman; los comandos son iguales salvo el nombre del programa.
- Elige una tarea a la izquierda, como Abrir una shell, Ver logs o Liberar espacio en disco.
- Rellena el nombre del contenedor y las opciones. El nombre que escribas se mantiene en las demás tareas.
- Copia el comando y lee qué hace cada parte. Con Ejecutar un contenedor nuevo también puedes obtener un archivo Compose.
Preguntas
- ¿Cómo abro una shell dentro de un contenedor en ejecución?
- Ejecuta docker exec -it CONTAINER sh. Usa bash en lugar de sh si la imagen lo tiene; las imágenes slim y Alpine normalmente solo tienen sh. Escribe exit para salir sin detener el contenedor.
- ¿Cómo sigo los logs de un contenedor?
- docker logs -f --tail 100 CONTAINER muestra las últimas 100 líneas y sigue mostrando las nuevas. Añade --since 10m para ver solo las líneas recientes, y pásalo por grep -i --line-buffered error para filtrar las líneas según llegan.
- ¿Cómo convierto un comando docker run en docker compose?
- Pega el comando en el cuadro de importación y cambia el resultado a Archivo Compose. Se conservan los puertos, los volúmenes, las variables de entorno, la política de reinicio, la red y los límites de recursos.
- ¿Qué significa -p 8080:80?
- El número de la izquierda es el puerto de tu máquina y el de la derecha, el puerto dentro del contenedor. Añade delante 127.0.0.1: para que el puerto solo sea accesible desde tu propio equipo.
- ¿Qué diferencia hay entre un volumen con nombre y un bind mount?
- Un bind mount como ./data:/data asigna una carpeta de tu máquina. Un volumen con nombre como pgdata:/var/lib/postgresql/data es almacenamiento gestionado por Docker, que sobrevive al contenedor y es la opción habitual para bases de datos.
- ¿Los comandos de Docker y Podman son iguales?
- Casi: podman run acepta las mismas opciones. Las principales diferencias son que funciona sin root de forma predeterminada, así que los puertos del host por debajo de 1024 necesitan configuración adicional, y que los sistemas con SELinux suelen necesitar :Z en los bind mounts.
- ¿Debo poner contraseñas en opciones -e?
- Acaban en el historial de tu shell y en docker inspect. Para todo lo que vaya más allá de pruebas locales, usa un --env-file fuera del control de versiones o la función de secretos de tu plataforma.
- ¿Cómo encuentro la dirección IP de un contenedor?
- Elige Inspeccionar un contenedor y luego Dirección IP: la herramienta escribe por ti la plantilla de docker inspect --format. Eso sí, rara vez necesitas la IP. Los contenedores de la misma red definida por el usuario o del mismo proyecto Compose se comunican entre sí por nombre, como db:5432, y la IP puede cambiar cada vez que se recrea un contenedor.
- ¿Puedo copiar archivos de un contenedor detenido?
- Sí. docker cp CONTAINER:/var/log/app.log ./ funciona tanto si el contenedor está en ejecución como si está detenido, lo que lo hace útil para recoger logs o volcados tras un fallo. También copia carpetas completas. Usa Copiar archivos dentro o fuera para obtener el comando en cualquiera de los dos sentidos.
- ¿Qué diferencia hay entre docker stop y docker kill?
- docker stop envía SIGTERM, espera 10 segundos (puedes cambiarlo con -t) y después envía SIGKILL. docker kill envía SIGKILL de inmediato, sin ninguna oportunidad de limpiar. Si stop siempre tarda los 10 segundos completos, probablemente tu programa ignora SIGTERM, a menudo porque una shell se ejecuta como proceso 1 y no reenvía la señal.
docker exec vs docker run
docker run crea un contenedor nuevo a partir de una imagen y lo inicia. docker exec ejecuta un comando dentro de un contenedor que ya está en ejecución. Un error habitual es usar docker run -it nginx bash para “entrar” en un servidor: inicia un contenedor nuevo junto al real, y todo lo que cambies ahí desaparece. Sin --rm, cada intento deja además un contenedor detenido que mostrará docker ps -a.
docker exec solo funciona mientras el contenedor está en ejecución, así que no sirve de nada con un contenedor que falla al arrancar. Lee primero docker logs --tail 50 CONTAINER. Después inicia la imagen con una shell en lugar de su programa habitual: docker run -it --rm --entrypoint sh IMAGE. Para esto, el generador de run tiene los campos Entrypoint y Comando en Más opciones.
Cómo liberar el espacio en disco que usa Docker
Empieza con docker system df, que muestra cuánto espacio ocupan las imágenes, los contenedores, los volúmenes locales y la caché de construcción. docker image prune elimina solo las imágenes colgantes (dangling), los restos sin etiqueta de las reconstrucciones. docker image prune -a elimina todas las imágenes que no usa ningún contenedor, así que tendrás que volver a descargarlas la próxima vez. docker container prune elimina los contenedores detenidos, lo que también libera sus capas de escritura.
Ten cuidado con los volúmenes: contienen archivos de bases de datos y subidas. docker volume prune elimina los volúmenes que no usa ningún contenedor, y en Docker 23 y versiones posteriores solo elimina los volúmenes anónimos, salvo que añadas -a. docker system prune -a --volumes elimina de una vez casi todo lo que no se usa. Los comandos prune piden confirmación salvo que añadas -f, y nada va a una papelera, así que lee el aviso antes de confirmar.
Políticas de reinicio de Docker: unless-stopped vs always
Con --restart always, Docker reinicia el contenedor cada vez que termina, y también cuando se inicia el daemon de Docker, aunque antes hubieras detenido el contenedor a mano. unless-stopped se comporta igual, salvo que un contenedor que hayas detenido tú sigue detenido tras un reinicio. on-failure solo reinicia tras un código de salida distinto de cero. El valor predeterminado, no, nunca reinicia. Para servicios de larga duración, unless-stopped suele ser la opción adecuada.
En un archivo Compose, el mismo ajuste es restart: unless-stopped. El valor “no” tiene que ir entre comillas, porque los parsers de YAML antiguos leen un no sin comillas como false, y la salida Compose de aquí lo pone entre comillas por ti. Podman es distinto: no tiene un daemon siempre en ejecución, así que los contenedores con política de reinicio solo vuelven tras un reinicio si el servicio podman-restart está habilitado o si los ejecutas con systemd.
¿Algo no funciona o un resultado parece incorrecto? Informar de un problema con esta herramienta