Compartir comentarios
Las respuestas se generan en base a la documentación.

Problemas conocidos

  • El Monitor de Actividad de Mac informa que Docker utiliza el doble de la cantidad de memoria que realmente está consumiendo. Esto se debe a un error en macOS.

  • Diálogo "Docker.app está dañada": Si ves el diálogo "Docker.app está dañada y no se puede abrir" durante la instalación o actualización, esto suele ser causado por operaciones de copia no atómicas cuando otras aplicaciones están utilizando la CLI de Docker. Consulta Solucionar "Docker.app está dañada" en macOS para ver los pasos de resolución.

  • Expulsar a la fuerza el .dmg después de ejecutar Docker.app desde él puede hacer que el icono de la ballena deje de responder, que las tareas de Docker aparezcan como "no responde" en el Monitor de Actividad y que algunos procesos consuman una gran cantidad de recursos de CPU. Reinicia la máquina y vuelve a iniciar Docker para resolver estos problemas.

  • Docker Desktop utiliza el hipervisor HyperKit (https://github.com/docker/hyperkit) en macOS 10.10 Yosemite y versiones superiores. Si estás desarrollando con herramientas que presentan conflictos con HyperKit, como Intel Hardware Accelerated Execution Manager (HAXM), la solución temporal actual consiste en no ejecutarlos al mismo tiempo. Puedes pausar HyperKit saliendo temporalmente de Docker Desktop mientras trabajas con HAXM. Esto te permite seguir trabajando con las otras herramientas y evitar que HyperKit interfiera.

  • Si estás trabajando con aplicaciones como Apache Maven que esperan configuraciones para las variables de entorno DOCKER_HOST y DOCKER_CERT_PATH, especifícalas para conectarte a las instancias de Docker a través de sockets Unix. Por ejemplo:

    $ export DOCKER_HOST=unix:///var/run/docker.sock

  • Algunas herramientas de línea de comandos no funcionan si Rosetta 2 no está instalado.

    • La antigua versión 1.x de docker-compose. Utiliza Compose V2 en su lugar escribiendo docker compose.
    • El ayudante de credenciales docker-credential-ecr-login.

  • Algunas imágenes no son compatibles con la arquitectura ARM64. Puedes añadir --platform linux/amd64 para ejecutar (o construir) una imagen de Intel mediante emulación.

    Sin embargo, los intentos de ejecutar contenedores basados en Intel en máquinas con Apple silicon bajo emulación pueden fallar, ya que a veces QEMU no logra ejecutar el contenedor. Además, las API de notificación de cambios en el sistema de archivos (inotify) no funcionan bajo la emulación de QEMU. Incluso si los contenedores se ejecutan correctamente bajo emulación, serán más lentos y consumirán más memoria que su equivalente nativo.

    En resumen, la ejecución de contenedores basados en Intel en máquinas basadas en Arm debe considerarse únicamente como "el mejor esfuerzo" (best effort). Recomendamos ejecutar contenedores arm64 en máquinas con Apple silicon siempre que sea posible, y animar a los creadores de contenedores a producir versiones de sus contenedores para arm64 o multiarquitectura. Este problema debería ser menos común con el tiempo, a medida que más y más imágenes se vuelvan a construir admitiendo múltiples arquitecturas.

  • Ocasionalmente, los usuarios pueden experimentar pérdida de datos cuando una transmisión TCP se cierra a medias.