FastAPI en Contenedores - Docker¶

Al desplegar aplicaciones de FastAPI, un enfoque común es construir unaimagen de contenedor de Linux. Normalmente se realiza usandoDocker. Luego puedes desplegar esa imagen de contenedor de varias formas.

Usar contenedores de Linux tiene varias ventajas, incluyendoseguridad,replicabilidad,simplicidad, y otras.

FROMpython:3.14WORKDIR/codeCOPY./requirements.txt/code/requirements.txtRUNpipinstall--no-cache-dir--upgrade-r/code/requirements.txtCOPY./app/code/appCMD["fastapi","run","app/main.py","--port","80"]# Si estás detrás de un proxy como Nginx o Traefik añade --proxy-headers# CMD ["fastapi", "run", "app/main.py", "--port", "80", "--proxy-headers"]

Qué es un Contenedor¶

Los contenedores (principalmente contenedores de Linux) son una forma muyligera de empaquetar aplicaciones incluyendo todas sus dependencias y archivos necesarios, manteniéndolos aislados de otros contenedores (otras aplicaciones o componentes) en el mismo sistema.

Los contenedores de Linux se ejecutan utilizando el mismo núcleo de Linux del host (máquina, máquina virtual, servidor en la nube, etc.). Esto significa que son muy ligeros (en comparación con las máquinas virtuales completas que emulan un sistema operativo completo).

De esta forma, los contenedores consumenpocos recursos, una cantidad comparable a ejecutar los procesos directamente (una máquina virtual consumiría mucho más).

Los contenedores también tienen sus propios procesos de ejecuciónaislados (normalmente solo un proceso), sistema de archivos y red, simplificando el despliegue, la seguridad, el desarrollo, etc.

Qué es una Imagen de Contenedor¶

Uncontenedor se ejecuta desde unaimagen de contenedor.

Una imagen de contenedor es una versiónestática de todos los archivos, variables de entorno y el comando/programa por defecto que debería estar presente en un contenedor.Estático aquí significa que laimagen de contenedor no se está ejecutando, no está siendo ejecutada, son solo los archivos empaquetados y los metadatos.

En contraste con una "imagen de contenedor" que son los contenidos estáticos almacenados, un "contenedor" normalmente se refiere a la instance en ejecución, lo que está siendoejecutado.

Cuando elcontenedor se inicia y está en funcionamiento (iniciado a partir de unaimagen de contenedor), puede crear o cambiar archivos, variables de entorno, etc. Esos cambios existirán solo en ese contenedor, pero no persistirán en la imagen de contenedor subyacente (no se guardarán en disco).

Una imagen de contenedor es comparable al archivo deprograma y sus contenidos, por ejemplo,python y algún archivomain.py.

Y elcontenedor en sí (en contraste con laimagen de contenedor) es la instance real en ejecución de la imagen, comparable a unproceso. De hecho, un contenedor solo se está ejecutando cuando tiene unproceso en ejecución (y normalmente es solo un proceso). El contenedor se detiene cuando no hay un proceso en ejecución en él.

Imágenes de Contenedor¶

Docker ha sido una de las herramientas principales para crear y gestionarimágenes de contenedor ycontenedores.

Y hay unDocker Hub público conimágenes de contenedores oficiales pre-hechas para muchas herramientas, entornos, bases de datos y aplicaciones.

Por ejemplo, hay unaImagen de Python oficial.

Y hay muchas otras imágenes para diferentes cosas como bases de datos, por ejemplo para:

• PostgreSQL
• MySQL
• MongoDB
• Redis, etc.

Usando una imagen de contenedor pre-hecha es muy fácilcombinar y utilizar diferentes herramientas. Por ejemplo, para probar una nueva base de datos. En la mayoría de los casos, puedes usar lasimágenes oficiales, y simplemente configurarlas con variables de entorno.

De esta manera, en muchos casos puedes aprender sobre contenedores y Docker y reutilizar ese conocimiento con muchas herramientas y componentes diferentes.

Así, ejecutaríasmúltiples contenedores con diferentes cosas, como una base de datos, una aplicación de Python, un servidor web con una aplicación frontend en React, y conectarlos entre sí a través de su red interna.

Todos los sistemas de gestión de contenedores (como Docker o Kubernetes) tienen estas funcionalidades de redes integradas.

Contenedores y Procesos¶

Unaimagen de contenedor normalmente incluye en sus metadatos el programa o comando por defecto que debería ser ejecutado cuando elcontenedor se inicie y los parámetros que deben pasar a ese programa. Muy similar a lo que sería si estuviera en la línea de comandos.

Cuando uncontenedor se inicia, ejecutará ese comando/programa (aunque puedes sobrescribirlo y hacer que ejecute un comando/programa diferente).

Un contenedor está en ejecución mientras elproceso principal (comando o programa) esté en ejecución.

Un contenedor normalmente tiene unproceso único, pero también es posible iniciar subprocesos desde el proceso principal, y de esa manera tendrásmúltiples procesos en el mismo contenedor.

Pero no es posible tener un contenedor en ejecución sinal menos un proceso en ejecución. Si el proceso principal se detiene, el contenedor se detiene.

Construir una Imagen de Docker para FastAPI¶

¡Bien, construyamos algo ahora! 🚀

Te mostraré cómo construir unaimagen de Docker para FastAPIdesde cero, basada en la imagenoficial de Python.

Esto es lo que querrías hacer enla mayoría de los casos, por ejemplo:

• UsandoKubernetes o herramientas similares
• Al ejecutar en unRaspberry Pi
• Usando un servicio en la nube que ejecutaría una imagen de contenedor por ti, etc.

Requisitos del Paquete¶

Normalmente tendrías losrequisitos del paquete para tu aplicación en algún archivo.

Dependería principalmente de la herramienta que uses parainstalar esos requisitos.

La forma más común de hacerlo es tener un archivorequirements.txt con los nombres de los paquetes y sus versiones, uno por línea.

Por supuesto, usarías las mismas ideas que leíste enAcerca de las versiones de FastAPI para establecer los rangos de versiones.

Por ejemplo, turequirements.txt podría verse así:

fastapi[standard]>=0.113.0,<0.114.0pydantic>=2.7.0,<3.0.0

Y normalmente instalarías esas dependencias de los paquetes conpip, por ejemplo:

$pipinstall-rrequirements.txt---> 100%Successfully installed fastapi pydantic

Crear el Código deFastAPI¶

• Crea un directorioapp y entra en él.
• Crea un archivo vacío__init__.py.
• Crea un archivomain.py con:

fromfastapiimportFastAPIapp=FastAPI()@app.get("/")defread_root():return{"Hello":"World"}@app.get("/items/{item_id}")defread_item(item_id:int,q:str|None=None):return{"item_id":item_id,"q":q}

Dockerfile¶

Ahora, en el mismo directorio del proyecto, crea un archivoDockerfile con:

# (1)!FROMpython:3.14# (2)!WORKDIR/code# (3)!COPY./requirements.txt/code/requirements.txt# (4)!RUNpipinstall--no-cache-dir--upgrade-r/code/requirements.txt# (5)!COPY./app/code/app# (6)!CMD["fastapi","run","app/main.py","--port","80"]

1. Comenzar desde la imagen base oficial de Python.

2. Establecer el directorio de trabajo actual a/code.

   Aquí es donde pondremos el archivorequirements.txt y el directorioapp.

3. Copiar el archivo con los requisitos al directorio/code.

   Copiarsolo el archivo con los requisitos primero, no el resto del código.

   Como este archivono cambia a menudo, Docker lo detectará y usará lacaché para este paso, habilitando la caché para el siguiente paso también.

4. Instalar las dependencias de los paquetes en el archivo de requisitos.

   La opción--no-cache-dir le dice apip que no guarde los paquetes descargados localmente, ya que eso solo sería sipip fuese a ejecutarse de nuevo para instalar los mismos paquetes, pero ese no es el caso al trabajar con contenedores.

   Nota

   El--no-cache-dir está relacionado solo conpip, no tiene nada que ver con Docker o contenedores.

   La opción--upgrade le dice apip que actualice los paquetes si ya están instalados.

   Debido a que el paso anterior de copiar el archivo podría ser detectado por lacaché de Docker, este paso tambiénusará la caché de Docker cuando esté disponible.

   Usar la caché en este paso teahorrará muchotiempo al construir la imagen una y otra vez durante el desarrollo, en lugar dedescargar e instalar todas las dependenciascada vez.

5. Copiar el directorio./app dentro del directorio/code.

   Como esto contiene todo el código, que es lo quecambia con más frecuencia, lacaché de Docker no se utilizará para este u otrospasos siguientes fácilmente.

   Así que es importante poner estocerca del final delDockerfile, para optimizar los tiempos de construcción de la imagen del contenedor.

6. Establecer elcomando para usarfastapi run, que utiliza Uvicorn debajo.

   CMD toma una lista de cadenas, cada una de estas cadenas es lo que escribirías en la línea de comandos separado por espacios.

   Este comando se ejecutará desde eldirectorio de trabajo actual, el mismo directorio/code que estableciste antes conWORKDIR /code.

UsarCMD - Forma Exec¶

La instrucción DockerCMD se puede escribir usando dos formas:

✅Forma Exec:

# ✅ Haz estoCMD["fastapi","run","app/main.py","--port","80"]

⛔️Forma Shell:

# ⛔️ No hagas estoCMDfastapirunapp/main.py--port80

Asegúrate de siempre usar laforma exec para garantizar que FastAPI pueda cerrarse de manera adecuada y quelos eventos de lifespan sean disparados.

Puedes leer más sobre esto en lasdocumentación de Docker para formas de shell y exec.

Esto puede ser bastante notorio al usardocker compose. Consulta esta sección de preguntas frecuentes de Docker Compose para más detalles técnicos:¿Por qué mis servicios tardan 10 segundos en recrearse o detenerse?.

Estructura de Directorios¶

Ahora deberías tener una estructura de directorios como:

.├── app│   ├── __init__.py│   └── main.py├── Dockerfile└── requirements.txt

Detrás de un Proxy de Terminación TLS¶

Si estás ejecutando tu contenedor detrás de un Proxy de Terminación TLS (load balancer) como Nginx o Traefik, añade la opción--proxy-headers, esto le dirá a Uvicorn (a través de la CLI de FastAPI) que confíe en los headers enviados por ese proxy indicando que la aplicación se está ejecutando detrás de HTTPS, etc.

CMD["fastapi","run","app/main.py","--proxy-headers","--port","80"]

Caché de Docker¶

Hay un truco importante en esteDockerfile, primero copiamosel archivo con las dependencias solo, no el resto del código. Déjame decirte por qué es así.

COPY./requirements.txt/code/requirements.txt

Docker y otras herramientasconstruyen estas imágenes de contenedorincrementalmente, añadiendouna capa sobre la otra, empezando desde la parte superior delDockerfile y añadiendo cualquier archivo creado por cada una de las instrucciones delDockerfile.

Docker y herramientas similares también usan unacaché interna al construir la imagen, si un archivo no ha cambiado desde la última vez que se construyó la imagen del contenedor, entonces reutilizará la misma capa creada la última vez, en lugar de copiar el archivo de nuevo y crear una nueva capa desde cero.

Solo evitar copiar archivos no mejora necesariamente las cosas mucho, pero porque se usó la caché para ese paso, puedeusar la caché para el siguiente paso. Por ejemplo, podría usar la caché para la instrucción que instala las dependencias con:

RUNpipinstall--no-cache-dir--upgrade-r/code/requirements.txt

El archivo con los requisitos de los paquetesno cambiará con frecuencia. Así que, al copiar solo ese archivo, Docker podráusar la caché para ese paso.

Y luego, Docker podráusar la caché para el siguiente paso que descarga e instala esas dependencias. Y aquí es dondeahorramos mucho tiempo. ✨ ...y evitamos el aburrimiento de esperar. 😪😆

Descargar e instalar las dependencias de los paquetespodría llevar minutos, pero usando lacaché tomaríasegundos como máximo.

Y como estarías construyendo la imagen del contenedor una y otra vez durante el desarrollo para comprobar que los cambios en tu código funcionan, hay una gran cantidad de tiempo acumulado que te ahorrarías.

Luego, cerca del final delDockerfile, copiamos todo el código. Como esto es lo quecambia con más frecuencia, lo ponemos cerca del final, porque casi siempre, cualquier cosa después de este paso no podrá usar la caché.

COPY./app/code/app

Construir la Imagen de Docker¶

Ahora que todos los archivos están en su lugar, vamos a construir la imagen del contenedor.

• Ve al directorio del proyecto (donde está tuDockerfile, conteniendo tu directorioapp).
• Construye tu imagen de FastAPI:

$dockerbuild-tmyimage.---> 100%

Iniciar el Contenedor Docker¶

• Ejecuta un contenedor basado en tu imagen:

$dockerrun-d--namemycontainer-p80:80myimage

Revísalo¶

Deberías poder revisarlo en la URL de tu contenedor de Docker, por ejemplo:http://192.168.99.100/items/5?q=somequery ohttp://127.0.0.1/items/5?q=somequery (o equivalente, usando tu host de Docker).

Verás algo como:

{"item_id":5,"q":"somequery"}

Documentación Interactiva de la API¶

Ahora puedes ir ahttp://192.168.99.100/docs ohttp://127.0.0.1/docs (o equivalente, usando tu host de Docker).

Verás la documentación interactiva automática de la API (proporcionada porSwagger UI):

Documentación Alternativa de la API¶

Y también puedes ir ahttp://192.168.99.100/redoc ohttp://127.0.0.1/redoc (o equivalente, usando tu host de Docker).

Verás la documentación alternativa automática (proporcionada porReDoc):

Construir una Imagen de Docker con un FastAPI de Un Solo Archivo¶

Si tu FastAPI es un solo archivo, por ejemplo,main.py sin un directorio./app, tu estructura de archivos podría verse así:

.├── Dockerfile├── main.py└── requirements.txt

Entonces solo tendrías que cambiar las rutas correspondientes para copiar el archivo dentro delDockerfile:

FROMpython:3.14WORKDIR/codeCOPY./requirements.txt/code/requirements.txtRUNpipinstall--no-cache-dir--upgrade-r/code/requirements.txt# (1)!COPY./main.py/code/# (2)!CMD["fastapi","run","main.py","--port","80"]

1. Copia el archivomain.py directamente al directorio/code (sin ningún directorio./app).

2. Usafastapi run para servir tu aplicación en el archivo únicomain.py.

Cuando pasas el archivo afastapi run, detectará automáticamente que es un archivo único y no parte de un paquete y sabrá cómo importarlo y servir tu aplicación FastAPI. 😎

Conceptos de Despliegue¶

Hablemos nuevamente de algunos de los mismosConceptos de Despliegue en términos de contenedores.

Los contenedores son principalmente una herramienta para simplificar el proceso deconstrucción y despliegue de una aplicación, pero no imponen un enfoque particular para manejar estosconceptos de despliegue, y hay varias estrategias posibles.

Labuena noticia es que con cada estrategia diferente hay una forma de cubrir todos los conceptos de despliegue. 🎉

Revisemos estosconceptos de despliegue en términos de contenedores:

• HTTPS
• Ejecutar en el inicio
• Reinicios
• Replicación (el número de procesos en ejecución)
• Memoria
• Pasos previos antes de comenzar

HTTPS¶

Si nos enfocamos solo en laimagen de contenedor para una aplicación FastAPI (y luego elcontenedor en ejecución), HTTPS normalmente sería manejadoexternamente por otra herramienta.

Podría ser otro contenedor, por ejemplo, conTraefik, manejandoHTTPS y la adquisiciónautomática decertificados.

Alternativamente, HTTPS podría ser manejado por un proveedor de la nube como uno de sus servicios (mientras que la aplicación aún se ejecuta en un contenedor).

Ejecutar en el Inicio y Reinicios¶

Normalmente hay otra herramienta encargada deiniciar y ejecutar tu contenedor.

Podría serDocker directamente,Docker Compose,Kubernetes, unservicio en la nube, etc.

En la mayoría (o todas) de las casos, hay una opción sencilla para habilitar la ejecución del contenedor al inicio y habilitar los reinicios en caso de fallos. Por ejemplo, en Docker, es la opción de línea de comandos--restart.

Sin usar contenedores, hacer que las aplicaciones se ejecuten al inicio y con reinicios puede ser engorroso y difícil. Pero altrabajar con contenedores en la mayoría de los casos, esa funcionalidad se incluye por defecto. ✨

Replicación - Número de Procesos¶

Si tienes unclúster de máquinas conKubernetes, Docker Swarm Mode, Nomad, u otro sistema complejo similar para gestionar contenedores distribuidos en varias máquinas, entonces probablemente querrás manejar lareplicación a nivel decluster en lugar de usar ungestor de procesos (como Uvicorn con workers) en cada contenedor.

Uno de esos sistemas de gestión de contenedores distribuidos como Kubernetes normalmente tiene alguna forma integrada de manejar lareplicación de contenedores mientras aún soporta elload balancing para las requests entrantes. Todo a nivel decluster.

En esos casos, probablemente desearías construir unaimagen de Docker desde cero como seexplica arriba, instalando tus dependencias, y ejecutandoun solo proceso de Uvicorn en lugar de usar múltiples workers de Uvicorn.

Load Balancer¶

Al usar contenedores, normalmente tendrías algún componenteescuchando en el puerto principal. Podría posiblemente ser otro contenedor que es también unProxy de Terminación TLS para manejarHTTPS o alguna herramienta similar.

Como este componente tomaría lacarga de las requests y las distribuiría entre los workers de una manera (esperablemente)balanceada, también se le llama comúnmenteLoad Balancer.

Y al trabajar con contenedores, el mismo sistema que usas para iniciarlos y gestionarlos ya tendría herramientas internas para transmitir lacomunicación en red (e.g., requests HTTP) desde eseload balancer (que también podría ser unProxy de Terminación TLS) a los contenedores con tu aplicación.

Un Load Balancer - Múltiples Contenedores Worker¶

Al trabajar conKubernetes u otros sistemas de gestión de contenedores distribuidos similares, usar sus mecanismos de red internos permitiría que el únicoload balancer que está escuchando en elpuerto principal transmita la comunicación (requests) a posiblementemúltiples contenedores ejecutando tu aplicación.

Cada uno de estos contenedores ejecutando tu aplicación normalmente tendríasolo un proceso (e.g., un proceso Uvicorn ejecutando tu aplicación FastAPI). Todos seríancontenedores idénticos, ejecutando lo mismo, pero cada uno con su propio proceso, memoria, etc. De esa forma, aprovecharías laparalelización endiferentes núcleos de la CPU, o incluso endiferentes máquinas.

Y el sistema de contenedores distribuido con elload balancerdistribuiría las requests a cada uno de los contenedores con tu aplicaciónen turnos. Así, cada request podría ser manejada por uno de los múltiplescontenedores replicados ejecutando tu aplicación.

Y normalmente esteload balancer podría manejar requests que vayan aotras aplicaciones en tu cluster (p. ej., a un dominio diferente, o bajo un prefijo de path de URL diferente), y transmitiría esa comunicación a los contenedores correctos paraesa otra aplicación ejecutándose en tu cluster.

Un Proceso por Contenedor¶

En este tipo de escenario, probablemente querrías tenerun solo proceso (Uvicorn) por contenedor, ya que ya estarías manejando la replicación a nivel de cluster.

Así que, en este caso,no querrías tener múltiples workers en el contenedor, por ejemplo, con la opción de línea de comandos--workers. Querrías tener solo unproceso Uvicorn por contenedor (pero probablemente múltiples contenedores).

Tener otro gestor de procesos dentro del contenedor (como sería con múltiples workers) solo añadiríacomplejidad innecesaria que probablemente ya estés manejando con tu sistema de cluster.

Contenedores con Múltiples Procesos y Casos Especiales¶

Por supuesto, haycasos especiales donde podrías querer tenerun contenedor con variosworker processes de Uvicorn dentro.

En esos casos, puedes usar la opción de línea de comandos--workers para establecer el número de workers que deseas ejecutar:

FROMpython:3.14WORKDIR/codeCOPY./requirements.txt/code/requirements.txtRUNpipinstall--no-cache-dir--upgrade-r/code/requirements.txtCOPY./app/code/app# (1)!CMD["fastapi","run","app/main.py","--port","80","--workers","4"]

1. Aquí usamos la opción de línea de comandos--workers para establecer el número de workers a 4.

Aquí hay algunos ejemplos de cuándo eso podría tener sentido:

Una Aplicación Simple¶

Podrías querer un gestor de procesos en el contenedor si tu aplicación eslo suficientemente simple que pueda ejecutarse en unservidor único, no un cluster.

Docker Compose¶

Podrías estar desplegando en unservidor único (no un cluster) conDocker Compose, por lo que no tendrías una forma fácil de gestionar la replicación de contenedores (con Docker Compose) mientras se preserva la red compartida y elload balancing.

Entonces podrías querer tenerun solo contenedor con ungestor de procesos iniciandovarios worker processes dentro.

El punto principal es que,ninguna de estas sonreglas escritas en piedra que debas seguir a ciegas. Puedes usar estas ideas paraevaluar tu propio caso de uso y decidir cuál es el mejor enfoque para tu sistema, verificando cómo gestionar los conceptos de:

• Seguridad - HTTPS
• Ejecutar en el inicio
• Reinicios
• Replicación (el número de procesos en ejecución)
• Memoria
• Pasos previos antes de comenzar

Memoria¶

Si ejecutasun solo proceso por contenedor, tendrás una cantidad de memoria más o menos bien definida, estable y limitada consumida por cada uno de esos contenedores (más de uno si están replicados).

Y luego puedes establecer esos mismos límites de memoria y requisitos en tus configuraciones para tu sistema de gestión de contenedores (por ejemplo, enKubernetes). De esa manera, podráreplicar los contenedores en lasmáquinas disponibles teniendo en cuenta la cantidad de memoria necesaria por ellos, y la cantidad disponible en las máquinas en el cluster.

Si tu aplicación essimple, probablemente estono será un problema, y puede que no necesites especificar límites de memoria estrictos. Pero si estásusando mucha memoria (por ejemplo, con modelos deMachine Learning), deberías verificar cuánta memoria estás consumiendo y ajustar elnúmero de contenedores que se ejecutan encada máquina (y tal vez agregar más máquinas a tu cluster).

Si ejecutasmúltiples procesos por contenedor, tendrás que asegurarte de que el número de procesos iniciados noconsuma más memoria de la que está disponible.

Pasos Previos Antes de Comenzar y Contenedores¶

Si estás usando contenedores (por ejemplo, Docker, Kubernetes), entonces hay dos enfoques principales que puedes usar.

Múltiples Contenedores¶

Si tienesmúltiples contenedores, probablemente cada uno ejecutando unproceso único (por ejemplo, en un cluster deKubernetes), entonces probablemente querrías tener uncontenedor separado realizando el trabajo de lospasos previos en un solo contenedor, ejecutando un solo proceso,antes de ejecutar los contenedores worker replicados.

Si en tu caso de uso no hay problema en ejecutar esos pasos previosmúltiples veces en paralelo (por ejemplo, si no estás ejecutando migraciones de base de datos, sino simplemente verificando si la base de datos está lista), entonces también podrías simplemente ponerlos en cada contenedor justo antes de iniciar el proceso principal.

Un Contenedor Único¶

Si tienes una configuración simple, con uncontenedor único que luego inicia múltiplesworker processes (o también solo un proceso), entonces podrías ejecutar esos pasos previos en el mismo contenedor, justo antes de iniciar el proceso con la aplicación.

Imagen Base de Docker¶

Solía haber una imagen official de Docker de FastAPI:tiangolo/uvicorn-gunicorn-fastapi. Pero ahora está obsoleta. ⛔️

Probablementeno deberías usar esta imagen base de Docker (o cualquier otra similar).

Si estás usandoKubernetes (u otros) y ya estás configurando lareplicación a nivel de cluster, con múltiplescontenedores. En esos casos, es mejor queconstruyas una imagen desde cero como se describe arriba:Construir una Imagen de Docker para FastAPI.

Y si necesitas tener múltiples workers, puedes simplemente utilizar la opción de línea de comandos--workers.

Desplegar la Imagen del Contenedor¶

Después de tener una Imagen de Contenedor (Docker) hay varias maneras de desplegarla.

Por ejemplo:

• ConDocker Compose en un servidor único
• Con un cluster deKubernetes
• Con un cluster de Docker Swarm Mode
• Con otra herramienta como Nomad
• Con un servicio en la nube que tome tu imagen de contenedor y la despliegue

Imagen de Docker conuv¶

Si estás usandouv para instalar y gestionar tu proyecto, puedes seguir suguía de Docker de uv.

Resumen¶

Usando sistemas de contenedores (por ejemplo, conDocker yKubernetes) se vuelve bastante sencillo manejar todos losconceptos de despliegue:

• HTTPS
• Ejecutar en el inicio
• Reinicios
• Replicación (el número de procesos en ejecución)
• Memoria
• Pasos previos antes de comenzar

En la mayoría de los casos, probablemente no querrás usar ninguna imagen base, y en su lugarconstruir una imagen de contenedor desde cero basada en la imagen oficial de Docker de Python.

Teniendo en cuenta elorden de las instrucciones en elDockerfile y lacaché de Docker puedesminimizar los tiempos de construcción, para maximizar tu productividad (y evitar el aburrimiento). 😎