Copiar archivos a un container Docker: ¿solución rápida o mala práctica?

Copiar archivos a un container Docker en ejecución, si bien es posible y a veces necesario, es una de esas cosas que, en mi experiencia, si la usas de forma habitual en ambientes que no son de desarrollo o test, puede estar delatando que algo no está bien en tu proceso de build o de gestión de volúmenes. Dicho eso, entender cómo funciona es clave, porque igual sirve.

La herramienta directa: docker cp

La verdad es que Docker lo hizo bastante simple con el comando docker cp. Es la forma más directa y estandarizada de mover archivos entre tu host y un container en ejecución. Olvídate de intentar meterte en los directorios internos de Docker como si fuera un sistema de archivos normal; eso es buscarse problemas.

Copiar desde el host al container

Si quieres subir un archivo o directorio desde tu máquina al container, el comando es bastante intuitivo:

docker cp /ruta/en/tu/host/archivo.txt ID_o_nombre_del_container:/ruta/dentro/del/container/destino.txt

Por ejemplo, si tengo un archivo de configuración config.json en mi escritorio y quiero meterlo en /app/config/ de mi container llamado mi-aplicacion-web:

docker cp ~/Desktop/config.json mi-aplicacion-web:/app/config/config.json

Ojo que si el destino es un directorio y no especificas el nombre del archivo, se copiará con el mismo nombre que tiene en el host.

Copiar desde el container al host

Funciona al revés de la misma manera. Si necesitas sacar logs, un dump de base de datos o cualquier archivo generado por la aplicación dentro del container, docker cp es tu amigo:

docker cp ID_o_nombre_del_container:/ruta/dentro/del/container/logs.log /ruta/en/tu/host/descargas/

Aquí, estoy sacando un archivo logs.log del container y guardándolo en un directorio descargas en mi host. Si el destino en el host es un directorio, el archivo se copiará con su nombre original.

¿Cuándo usar docker cp (y cuándo no)?

Ahora viene la parte donde me pongo un poco más directo con mi opinión. docker cp es excelente para:

• Depuración rápida: ¿Necesitas probar un cambio menor en un archivo de configuración sin reconstruir la imagen? Copiarlo directamente es lo más rápido. Es una solución temporal, entiendes.
• Extracción de logs o datos: Cuando quieres sacar logs o archivos generados por la aplicación para analizarlos en tu máquina, es perfecto. Esto es justo lo que el usuario de Stack Overflow mencionaba para una solución de backup/restore ad-hoc.
• Scripts o herramientas ad-hoc: A veces, necesitas meter un pequeño script de una sola ejecución para una tarea específica dentro de un container. En mi caso, he usado esto para ejecutar algún script de migración rápida en un ambiente de staging antes de automatizarlo bien.

Pero, ¿cuándo no deberías usarlo? Aquí es donde veo la sobreingeniería o las malas prácticas:

• Para persistir datos: Si tus datos deben sobrevivir al container, o ser compartidos entre containers o con el host, usa Docker Volumes. De hecho, no hay otra forma robusta para esto. Copiar archivos manualmente en cada reinicio es una pesadilla y pierde toda la gracia de Docker.
• Para tu código fuente o configuración de aplicación: Tu código y archivos de configuración esenciales deberían ser parte de la imagen Docker en el momento de la construcción, usando la instrucción COPY o ADD en tu Dockerfile. Esto asegura que la imagen sea reproducible y autónoma. Si tu CI/CD usa docker cp para desplegar código, tienes un problema serio.
• Como parte de tu pipeline de despliegue regular: Un despliegue robusto debe ser automático y basado en imágenes inmutables. docker cp es un parche manual, no una solución de infraestructura.

No te metas donde no debes: el caso del aufs

Vi una respuesta en Stack Overflow que sugería copiar archivos directamente a los directorios internos de Docker, algo como /var/lib/docker/aufs/mnt/FULL_CONTAINER_ID/PATH-NEW-FILE. No, en serio, no hagas esto.

Esa ruta es una implementación interna de Docker (específica del driver de almacenamiento aufs, que ni siquiera es el más común hoy en día). Acceder a ella directamente es como querer cambiarle el aceite al auto metiéndole mano directamente al motor sin abrir el capó, usando una cuchara. Te arriesgas a:

• Romper la estructura interna de Docker.
• Que tu solución deje de funcionar en cualquier momento, ya que estas rutas no son parte de la API pública y cambian entre versiones de Docker o incluso entre sistemas operativos o drivers de almacenamiento.
• Problemas de permisos inexplicables.

Docker te da una herramienta clara y segura, que es docker cp. Úsala. No te compliques la vida con hacks que no sabes si funcionarán mañana.

Cierre: el tradeoff real

Entonces, docker cp es una herramienta extremadamente útil y sencilla para tareas puntuales, de desarrollo, depuración o extracción de información. Es tu atajo cuando necesitas algo rápido y no quieres pasar por todo el ciclo de construir una nueva imagen o configurar un volumen.

Sin embargo, si te encuentras usándolo para gestionar la persistencia de datos, subir código fuente de forma regular a producción, o si es parte esencial de tu proceso de despliegue, entonces es una señal de alerta. Ahí es donde tienes que evaluar seriamente si estás usando Docker de la manera más eficiente y robusta. Para esas situaciones, existen soluciones mucho mejores y más acordes con la filosofía de los containers.