Optimizar para compilar en la nube

Docker Build Cloud ejecuta tus compilaciones de forma remota y no en la máquina donde invocas la compilación. Esto significa que las transferencias de archivos entre el cliente y el builder ocurren a través de la red.

La transferencia de archivos a través de la red tiene una mayor latencia y un menor ancho de banda que las transferencias locales. Docker Build Cloud cuenta con varias características para mitigar esto:

• Utiliza volúmenes de almacenamiento adjuntos para la caché de compilación, lo que hace que la lectura y escritura de la caché sea muy rápida.
• Cargar los resultados de la compilación de vuelta al cliente solo descarga las capas que se modificaron en comparación con las compilaciones anteriores.

A pesar de estas optimizaciones, la compilación remota aún puede generar transferencias de contexto y cargas de imágenes lentas para proyectos grandes o si la conexión de red es lenta. A continuación, se presentan algunas formas de optimizar tus compilaciones para que la transferencia sea más eficiente:

• Archivos dockerignore
• Imágenes base reducidas
• Compilaciones multi-stage
• Obtener archivos remotos en la compilación
• Herramientas multihilo

Para obtener más información sobre cómo optimizar tus compilaciones, consulta Buenas prácticas de compilación.

Archivos dockerignore

Utilizando un archivo .dockerignore, puedes definir explícitamente qué archivos locales no deseas incluir en el contexto de compilación. Los archivos que coincidan con los patrones de búsqueda (glob patterns) que especifiques en tu archivo ignore no se transferirán al builder remoto.

Algunos ejemplos de elementos que podrías querer añadir a tu archivo .dockerignore son:

• .git — evita enviar el historial de control de versiones en el contexto de compilación. Ten en cuenta que esto significa que no podrás ejecutar comandos de Git en los pasos de compilación, como por ejemplo git rev-parse.
• Directorios que contengan artefactos de compilación, como archivos binarios. Artefactos de compilación creados localmente durante el desarrollo.
• Directorios de dependencias para gestores de paquetes, como node_modules.

En general, el contenido de tu archivo .dockerignore debería ser similar al de tu archivo .gitignore.

Imágenes base reducidas

Seleccionar imágenes más pequeñas para tus instrucciones FROM en el Dockerfile puede ayudar a reducir el tamaño de la imagen final. La imagen de Alpine es un buen ejemplo de una imagen de Docker mínima que proporciona todas las utilidades del sistema operativo que esperarías de un contenedor Linux.

También existe la imagen especial scratch, que no contiene nada en absoluto. Es útil para crear imágenes de binarios enlazados estáticamente, por ejemplo.

Compilaciones multi-stage

Las compilaciones multi-stage pueden hacer que la compilación se ejecute más rápido, ya que las etapas se pueden ejecutar en paralelo. También permiten que el resultado final sea de menor tamaño. Escribe tu Dockerfile de manera que la etapa final de ejecución (runtime) utilice la imagen base más pequeña posible, conteniendo solo los recursos que tu programa requiere para ejecutarse.

También es posible copiar recursos de otras imágenes o etapas utilizando la instrucción COPY --from del Dockerfile. Esta técnica permite reducir el número de capas y el tamaño de las mismas en la etapa final.

Obtener archivos remotos en la compilación

Cuando sea posible, se deben obtener los archivos desde una ubicación remota durante la compilación, en lugar de empaquetar los archivos en el contexto de compilación. Descargar archivos directamente en el servidor de Docker Build Cloud es mejor, ya que probablemente sea más rápido que transferir los archivos junto con el contexto de compilación.

Puedes obtener archivos remotos durante la compilación utilizando la instrucción ADD del Dockerfile, o en tus instrucciones RUN con herramientas como wget y rsync.

Herramientas multihilo

Es posible que algunas herramientas utilizadas en las instrucciones de compilación no aprovechen múltiples núcleos de forma predeterminada. Un ejemplo de esto es make, que utiliza un único hilo de forma predeterminada, a menos que especifiques la opción make --jobs=<n>. Para los pasos de compilación que involucren este tipo de herramientas, comprueba si puedes optimizar la ejecución mediante la paralelización.