python - compose - ¿Virtualenv tiene un propósito(en producción) cuando se usa docker?
docker python virtualenv (5)
Introducir virtualenv es muy fácil, así que diría que comience sin él en su contenedor acoplable.
Si surge la necesidad, entonces quizás pueda instalarlo. Ejecutar "pip freeze> require.txt" le dará todos sus paquetes de Python. Sin embargo, dudo que alguna vez necesite virtualenv dentro de un contenedor acoplable, ya que crear otro contenedor sería una alternativa más preferible.
No recomendaría tener más de una aplicación en un solo contenedor. Cuando llegas a este punto, tu contenedor está haciendo demasiado.
Para el desarrollo utilizamos virtualenv para tener un desarrollo aislado cuando se trata de dependencias. A partir de esta pregunta , parece que se recomienda implementar aplicaciones Python en un virtualenv .
Ahora estamos comenzando a usar docker para la implementación. Esto proporciona un entorno más aislado, por lo que estoy cuestionando el uso de virtualenv dentro de un contenedor acoplable. En el caso de una sola aplicación, no creo que virtualenv tenga un propósito, ya que Docker ya proporciona aislamiento. En el caso de que se implementen múltiples aplicaciones en un solo contenedor acoplable, creo que virtualenv tiene un propósito ya que las aplicaciones pueden tener dependencias conflictivas.
¿Debería usarse virtualenv cuando se implementa una sola aplicación en un contenedor acoplable?
¿Debe Docker contener múltiples aplicaciones o solo una aplicación por contenedor?
Si es así, ¿se debe usar virtualenv al implementar un contenedor con múltiples aplicaciones?
Si alguien quiere reemplazar virtualenv completamente usando docker, puede hacerlo.
Simplemente cree un Dockerfile diferente para un entorno diferente y use puertos y volúmenes según lo necesite para el entorno.
Como ejemplo para el desarrollo, puede usar este project . Ejecute docker compose y comience a codificar. Escriba sus propios Dockerfiles para diferentes entornos como prueba, preparación y producción poniendo su registro y datos en volumen.
Este enlace también es útil https://vsupalov.com/docker-python-development/ .
Si. Aún debe usar virtualenv. Además, ahora deberías construir ruedas en lugar de huevos. Finalmente, debe asegurarse de mantener su imagen de Docker delgada y eficiente construyendo sus ruedas en un contenedor con las herramientas de construcción completas e instalando sin herramientas de construcción en el contenedor de la aplicación.
Deberías leer este excelente artículo. https://glyph.twistedmatrix.com/2015/03/docker-deploy-double-dutch.html
La clave para llevar es
Es cierto que en muchos casos, tal vez incluso en la mayoría, simplemente instalar cosas en el sistema Python con Pip funciona bien; sin embargo, para aplicaciones más elaboradas, es posible que desee invocar una herramienta proporcionada por su contenedor base que se implementa en Python, pero que requiere dependencias administradas por el host. Al poner las cosas en un virtualenv independientemente, mantenemos las cosas configuradas por el sistema de paquetes de la imagen base ordenadamente separadas de las cosas que está construyendo nuestra aplicación, lo que significa que no debe haber interacciones imprevistas, independientemente de cuán complejo sea el uso de Python por la aplicación ser.
Utilizo ambos porque con eso puedes usar más fácilmente las compilaciones de varias etapas y simplemente mover tus dependencias que construiste en una etapa a las imágenes / capas posteriores. El ejemplo se puede encontrar here .
Virtualenv fue creado mucho antes de Docker. Hoy, me inclino hacia docker en lugar de virtualenv por estas razones:
- Virtualenv todavía significa que las personas que consumen su producto necesitan descargar huevos. Con Docker, obtienen algo que "se sabe que funciona". Sin ataduras.
- Docker puede hacer mucho más que virtualenv (como crear un entorno limpio cuando tienes productos que necesitan diferentes versiones de Python).
El principal inconveniente de Docker fue el pobre soporte de Windows. Eso cambió con la versión para Windows 10.
En cuanto a "cuántas aplicaciones por contenedor", la política habitual es 1.