Hub documentation
Espacios de Docker
Espacios de Docker
Spaces admit contenedores de Docker personalizados para aplicaciones que están fuera del alcance de Streamlit y Gradio. Los Spaces de Docker permiten a los usuarios ir más allá de los límites de lo que era posible con los SDK estándar. Desde endpoints de FastAPI y Go hasta aplicaciones de Phoenix y herramientas de ML Ops, los Spaces de Docker pueden ser útiles en muchas configuraciones diferentes.
Configuración de Docker Spaces
Seleccionar Docker como SDK al crear un nuevo Space inicializará tu Space estableciendo la propiedad sdk en docker dentro del bloque YAML de tu archivo README.md. Alternativamente, dado un repositorio de Space existente, establece sdk: docker dentro del bloque YAML en la parte superior del archivo README.md de tus Spaces. También puedes cambiar el puerto expuesto por defecto 7860 estableciendo app_port: 7860. Después, puedes crear un Dockerfile habitual.
---
title: Basic Docker SDK Space
emoji: 🐳
colorFrom: purple
colorTo: gray
sdk: docker
app_port: 7860
---Internamente puedes tener tantos puertos abiertos como quieras. Por ejemplo, puedes instalar Elasticsearch dentro de tu Space y llamarlo internamente en su puerto predeterminado 9200.
Si desea exponer al mundo exterior aplicaciones servidas en varios puertos, una solución alternativa es usar un proxy inverso como Nginx para enrutar las solicitudes de internet (en un solo puerto) a diferentes puertos internos.
Gestión de secretos y variables
Puedes gestionar las variables de entorno de un Space en la configuración del Space. Lee más aquí.
Variables
Tiempo de compilación
Las variables se pasan como build-args al construir tu Docker Space. Consulta la documentación dedicada de Docker para obtener una guía completa sobre cómo usar esto en el Dockerfile.
# Declare your environment variables with the ARG directive
ARG MODEL_REPO_NAME
FROM python:latest
# [...]
# You can use them like environment variables
RUN predict.py $MODEL_REPO_NAMETiempo de ejecución
Las variables se inyectan en el entorno del contenedor en tiempo de ejecución.
Secretos
Tiempo de compilación
En Docker Spaces, la gestión de secretos es diferente por razones de seguridad. Una vez que crees un secreto en la pestaña Settings, puedes exponer el secreto añadiendo la siguiente línea en tu Dockerfile:
Por ejemplo, si SECRET_EXAMPLE es el nombre del secreto que creaste en la pestaña Settings, puedes leerlo en tiempo de compilación montándolo en un archivo y luego leyéndolo con $(cat /run/secrets/SECRET_EXAMPLE).
Vea un ejemplo a continuación:
# Expose the secret SECRET_EXAMPLE at buildtime and use its value as git remote URL
RUN --mount=type=secret,id=SECRET_EXAMPLE,mode=0444,required=true \
git init && \
git remote add origin $(cat /run/secrets/SECRET_EXAMPLE)# Expose the secret SECRET_EXAMPLE at buildtime and use its value as a Bearer token for a curl request
RUN --mount=type=secret,id=SECRET_EXAMPLE,mode=0444,required=true \
curl test -H 'Authorization: Bearer $(cat /run/secrets/SECRET_EXAMPLE)'Tiempo de ejecución
Al igual que con las Variables públicas, en tiempo de ejecución puedes acceder a los secretos como variables de entorno. Por ejemplo, en Python usarías os.environ.get("SECRET_EXAMPLE"). Consulta este ejemplo de un Espacio de Docker que utiliza secretos.
Permisos
El contenedor se ejecuta con el ID de usuario 1000. Para evitar problemas de permisos, debe crear un usuario y establecer su WORKDIR antes de cualquier COPY o descarga.
# Set up a new user named "user" with user ID 1000
RUN useradd -m -u 1000 user
# Switch to the "user" user
USER user
# Set home to the user's home directory
ENV HOME=/home/user \
PATH=/home/user/.local/bin:$PATH
# Set the working directory to the user's home directory
WORKDIR $HOME/app
# Try and run pip command after setting the user with `USER user` to avoid permission issues with Python
RUN pip install --no-cache-dir --upgrade pip
# Copy the current directory contents into the container at $HOME/app setting the owner to the user
COPY --chown=user . $HOME/app
# Download a checkpoint
RUN mkdir content
ADD --chown=user https://<SOME_ASSET_URL> content/<SOME_ASSET_NAME>Always specify the `--chown=user` with `ADD` and `COPY` to ensure the new files are owned by your user.
Si aún tienes problemas de permisos, es posible que necesites usar chmod o chown en tu Dockerfile para otorgar los permisos adecuados. Por ejemplo, si quieres usar el directorio /data, puedes hacer lo siguiente:
RUN mkdir -p /data
RUN chmod 777 /dataDebes evitar siempre los chowns innecesarios.
Actualizar los metadatos de un archivo crea una nueva copia almacenada en la nueva capa. Por lo tanto, un chown recursivo puede resultar en una imagen muy grande debido a la duplicación de todos los archivos afectados.
En lugar de corregir los permisos ejecutando chown:
COPY checkpoint .
RUN chown -R user checkpointsiempre debe hacer lo siguiente:
COPY --chown=user checkpoint .(lo mismo aplica para el comando ADD)
Persistencia de datos
Los datos escritos en el disco se pierden cada vez que tu Docker Space se reinicia. Para mantener los datos entre reinicios, puedes adjuntar un Storage Bucket a tu Space.
En este momento, el volumen
/datasolo está disponible en tiempo de ejecución, es decir, no puedes usar/datadurante el paso de compilación de tu Dockerfile.
También puedes usar nuestro Datasets Hub para casos específicos, donde puedes almacenar estado y datos en un repositorio git LFS. Puedes encontrar un ejemplo de persistencia aquí, que utiliza la librería huggingface_hub para subir archivos de forma programática a un repositorio de datasets. Este ejemplo de Space junto con esta guía te ayudará a definir qué solución se adapta mejor a tu tipo de datos.
Por último, en algunos casos, es posible que desees utilizar una solución de almacenamiento externo desde el código de tu Space, como una DB alojada externamente, S3, etc.
Contenedor de Docker con GPU
Puedes ejecutar contenedores de Docker con soporte para GPU utilizando uno de nuestros Hardware de Spaces con GPU.
Recomendamos usar nvidia/cuda de Docker Hub como imagen base, que viene con CUDA y cuDNN preinstalados.
During Docker buildtime, you don't have access to a GPU hardware. Therefore, you should not try to run any GPU-related command during the build step of your Dockerfile. For example, you can't run `nvidia-smi` or `torch.cuda.is_available()` building an image. Read more [here](https://github.com/NVIDIA/nvidia-docker/wiki/nvidia-docker#description).