[Actualizado a 26 de septiembre de 2026]

Ejemplos de Dockerfiles¶

Aplicación cli¶

1. Aplicación python¶

import sys

def main():
    version = sys.version.split()[0]
    print(f"¡Hola Mundo desde Docker con Python {version}!")

if __name__ == "__main__":
    main()

2. Dependencias¶

Crea un requirements.txt con el listado de módulos necesarios.

En nuestro caso, un archivo vacío.

3. Dockerfile¶

# Imagen base oficial de Python (versión slim para reducir tamaño)
FROM python:3.11-slim

# Directorio de trabajo dentro del contenedor
WORKDIR /app

# Copia e instala las dependencias primero para aprovechar el caché de Docker
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Copia el código fuente al contenedor
COPY hola_mundo.py .

# Comando por defecto que se ejecuta al iniciar el contenedor
CMD ["python", "hola_mundo.py"]

4. Uso¶

Crear: docker build -t mi-python:cli .
Correr: docker run --rm mi-python:cli

5. Ejecución programada¶

En ocasiones realizaremos aplicaciones que deseamos se ejecuten en un tiempo dado at o con recursividad cron.

Existen múltiples formas de resolver este problema por lo que vamos a plantear algunas posibles soluciones:

comando `at` + `docker run`¶

# Execute a command from standard input at 10:00 AM today:
echo "docker run --rm mi-python:cli" | at 1000

Aunque con at es lo más sencillo, a menudo no está instalado en el sistema.

Ejecución con `at.py`+ `docker run`¶

🔗 Trata de arrancarlo

Recurrente con `cron`¶

No es ideal realizarlo así debido a que tendríamos 2 servicios en un contendor, desaconsejado por diseño y por concepto, pero 🔗 si eres un revelde...

Aplicación backend¶

1. Aplicación flask¶

...

Distroless¶

Ahora que entendemos cómo funciona la construcción multistage, el enfoque distroless, es lo mismo pero llevado a su máxima expresión, sin "distribución", lo esencial para ejecutar linux. El mayor impulsor de estas imágenes es Google, que tiene un surtido para los principales lenguajes en el repositorio GoogleContainerTools/Distroless.

Estas imágenes están pensadas para ejecutar con lo mínimo necesario, están basadas en debian y, por no tener, no tienen ni intérprete de comandos. Esto último a veces hace más complicado de depurar las imágenes en producción. Para esto recordemos el artículo de Docker Debug, que si hay interés, también podría extenderlo a kubernetes.

Fuente: PPZ Pabpereza

Y la propuesta de distroless para crear imágenes python:

# Build a virtualenv using the appropriate Debian release
# * Install gcc and libc6-dev to compile C Python modules
# * In the virtualenv: Update pip setuputils and wheel to support building new packages
FROM python:3.13-slim-trixie AS build
RUN apt-get update && \
    apt-get install --no-install-suggests --no-install-recommends --yes gcc libc6-dev && \
    # Symlink the distroless path for python: /usr/bin/python to the build 
    # image path: /usr/local/bin/python to ensure the runtime image's venv has
    # the right python paths.
    ln -s /usr/local/bin/python /usr/bin/python && \
    /usr/bin/python -m venv /venv && \
    /venv/bin/pip install --upgrade pip setuptools wheel

# Build the virtualenv as a separate step: Only re-execute this step when requirements.txt changes
FROM build AS build-venv
COPY requirements.txt /requirements.txt
RUN /venv/bin/pip install --disable-pip-version-check -r /requirements.txt

# Copy the virtualenv into a distroless image
FROM gcr.io/distroless/python3-debian13
COPY --from=build-venv /venv /venv
COPY . /app
WORKDIR /app
ENTRYPOINT ["/venv/bin/python3", "hola_mundo.py"]

Usando docker image ls podremos ver que baja al 50 % aproximado con respecto a la versión slim de Debian.