Un virtualenv solo encapsula las dependencias de Python. Un contenedor Docker encapsula un sistema operativo completo .

Con un virtualenv de Python, puede cambiar fácilmente entre versiones y dependencias de Python, pero está atascado con su sistema operativo anfitrión.

Con una imagen de Docker, puede intercambiar todo el sistema operativo: instale y ejecute Python en Ubuntu, Debian, Alpine e incluso Windows Server Core.

Hay imágenes de Docker disponibles con todas las combinaciones de SO y versiones de Python que se te ocurran, listas para desplegar y usar en cualquier sistema con Docker instalado.

El entorno virtual de Python "contendrá" solo el tiempo de ejecución de Python, es decir, el intérprete de Python y las bibliotecas de Python, mientras que Docker aísla todo el sistema (todo el sistema de archivos, todas las bibliotecas de espacio de usuario, las interfaces de red). Por lo tanto, Docker está mucho más cerca de una máquina virtual que de un entorno virtual.

Agregando a lo anterior: hay un caso para combinar docker y venv: algunos sistemas operativos se envían con python instalado para proporcionar aplicaciones 'cercanas al sistema operativo', por ejemplo, que yo sepa, apt en debian (y sus derivados). El venv de python permite a un desarrollador enviar una aplicación de python que requiere una versión de intérprete diferente sin afectar el python enviado con el sistema operativo. Ahora, dado que Docker 'aísla todo el sistema operativo' como se indicó anteriormente, lo mismo se aplica a una imagen de Docker. Por lo tanto, en mi opinión, si se requiere/desea una imagen de Docker, la mejor práctica es crear un venv dentro de la imagen de Docker para su aplicación de python.