Construcción lenta de gradle en Docker. Almacenamiento en caché de gradle

Estoy haciendo un proyecto universitario donde necesitamos ejecutar múltiples aplicaciones Spring Boot a la vez.

Ya había configurado la compilación de varias etapas con la imagen de gradle docker y luego ejecuté la aplicación en openjdk: jre image.

Aquí está mi Dockerfile:

FROM gradle:5.3.0-jdk11-slim as builder
USER root
WORKDIR /usr/src/java-code
COPY . /usr/src/java-code/

RUN gradle bootJar

FROM openjdk:11-jre-slim
EXPOSE 8080
WORKDIR /usr/src/java-app
COPY --from=builder /usr/src/java-code/build/libs/*.jar ./app.jar
ENTRYPOINT ["java", "-jar", "app.jar"]

Estoy construyendo y ejecutando todo con docker-compose. Parte de docker-compose:

 website_server:
    build: website-server
    image: website-server:latest
    container_name: "website-server"
    ports:
      - "81:8080"

Por supuesto, la primera construcción lleva años. Docker está sacando todas sus dependencias. Y estoy de acuerdo con eso.

Todo está funcionando bien por ahora, pero cada pequeño cambio en el código causa alrededor de 1 minuto de tiempo de compilación para una aplicación.

Parte del registro de compilación: docker-compose up --build

Step 1/10 : FROM gradle:5.3.0-jdk11-slim as builder
 ---> 668e92a5b906
Step 2/10 : USER root
 ---> Using cache
 ---> dac9a962d8b6
Step 3/10 : WORKDIR /usr/src/java-code
 ---> Using cache
 ---> e3f4528347f1
Step 4/10 : COPY . /usr/src/java-code/
 ---> Using cache
 ---> 52b136a280a2
Step 5/10 : RUN gradle bootJar
 ---> Running in 88a5ac812ac8

Welcome to Gradle 5.3!

Here are the highlights of this release:
 - Feature variants AKA "optional dependencies"
 - Type-safe accessors in Kotlin precompiled script plugins
 - Gradle Module Metadata 1.0

For more details see https://docs.gradle.org/5.3/release-notes.html

Starting a Gradle Daemon (subsequent builds will be faster)
> Task :compileJava
> Task :processResources
> Task :classes
> Task :bootJar

BUILD SUCCESSFUL in 48s
3 actionable tasks: 3 executed
Removing intermediate container 88a5ac812ac8
 ---> 4f9beba838ed
Step 6/10 : FROM openjdk:11-jre-slim
 ---> 0e452dba629c
Step 7/10 : EXPOSE 8080
 ---> Using cache
 ---> d5519e55d690
Step 8/10 : WORKDIR /usr/src/java-app
 ---> Using cache
 ---> 196f1321db2c
Step 9/10 : COPY --from=builder /usr/src/java-code/build/libs/*.jar ./app.jar
 ---> d101eefa2487
Step 10/10 : ENTRYPOINT ["java", "-jar", "app.jar"]
 ---> Running in ad02f0497c8f
Removing intermediate container ad02f0497c8f
 ---> 0c63eeef8c8e
Successfully built 0c63eeef8c8e
Successfully tagged website-server:latest

Cada vez que se congela después Starting a Gradle Daemon (subsequent builds will be faster)

Estaba pensando en agregar volumen con dependencias de gradle en caché, pero no sé si ese es el núcleo del problema. Además, no pude encontrar buenos ejemplos para eso.

¿Hay alguna forma de acelerar la construcción?

La compilación lleva mucho tiempo porque Gradle cada vez que se construye la imagen de Docker descarga todos los complementos y dependencias.

No hay forma de montar un volumen en el momento de creación de la imagen. Pero es posible introducir una nueva etapa que descargará todas las dependencias y se almacenará en caché como capa de imagen de Docker.

FROM gradle:5.6.4-jdk11 as cache
RUN mkdir -p /home/gradle/cache_home
ENV GRADLE_USER_HOME /home/gradle/cache_home
COPY build.gradle /home/gradle/java-code/
WORKDIR /home/gradle/java-code
RUN gradle clean build -i --stacktrace

FROM gradle:5.6.4-jdk11 as builder
COPY --from=cache /home/gradle/cache_home /home/gradle/.gradle
COPY . /usr/src/java-code/
WORKDIR /usr/src/java-code
RUN gradle bootJar -i --stacktrace

FROM openjdk:11-jre-slim
EXPOSE 8080
USER root
WORKDIR /usr/src/java-app
COPY --from=builder /usr/src/java-code/build/libs/*.jar ./app.jar
ENTRYPOINT ["java", "-jar", "app.jar"]

El complemento Gradle y la caché de dependencia se encuentran en $GRADLE_USER_HOME/caches. GRADLE_USER_HOMEdebe establecerse en algo diferente a /home/gradle/.gradle. /home/gradle/.gradleen la imagen principal de Gradle Docker se define como volumen y se borra después de cada capa de imagen.

En el código de muestra GRADLE_USER_HOMEse establece en /home/gradle/cache_home.

En la builderetapa de caché Gradle se copia para evitar la descarga de las dependencias de nuevo: COPY --from=cache /home/gradle/cache_home /home/gradle/.gradle.

El escenario cachese reconstruirá solo cuando build.gradlese cambie. Cuando las clases Java son cambios, la capa de imagen en caché con todas las dependencias se reutiliza.

Esta modificación puede reducir el tiempo de construcción, pero de forma más limpia de la construcción de imágenes acoplables con las aplicaciones Java es la horca por Google. Hay un complemento Jib Gradle que permite crear imágenes de contenedor para aplicaciones Java sin crear manualmente Dockerfile. Crear una imagen con la aplicación y ejecutar el contenedor es similar a:

gradle clean build jib
docker-compose up

Docker almacena en caché sus imágenes en "capas". Cada comando que ejecuta es una capa. Cada cambio que se detecta en una capa dada invalida las capas que le siguen. Si la memoria caché está invalidada, las capas invalidadas deben construirse desde cero, incluidas las dependencias .

Sugeriría dividir sus pasos de compilación. Tenga una capa anterior que solo copie la especificación de dependencia en la imagen, luego ejecute un comando que hará que Gradle descargue las dependencias. Una vez que esté completo, copie su fuente en la misma ubicación donde acaba de hacer eso y ejecute la compilación real.

De esta manera, las capas anteriores se invalidarán solo cuando cambien los archivos gradle.

No he hecho esto con Java / Gradle, pero he seguido el mismo patrón con un proyecto Rust, guiado por esta publicación de blog.

Puede probar y usar BuildKit (ahora activado por defecto en la última versión de Docker -compose 1.25 )

Consulte " Acelere la creación de imágenes Docker de su aplicación java con BuildKit! " De Aboullaite Med .

(Esto fue para Maven, pero la misma idea se aplica a Gradle)

Consideremos el siguiente Dockerfile:

FROM maven:3.6.1-jdk-11-slim AS build  
USER MYUSER  
RUN mvn clean package  

La modificación de la segunda línea siempre invalida la memoria caché de Maven debido a una falsa dependencia, lo que expone un problema de almacenamiento en caché ineficiente.

BuildKit resuelve esta limitación al introducir el solucionador de gráficos de compilación concurrente, que puede ejecutar los pasos de compilación en paralelo y optimizar los comandos que no tienen un impacto en el resultado final.

Además, Buildkit rastrea solo las actualizaciones realizadas a los archivos entre invocaciones de compilación repetidas que optimizan el acceso a los archivos de origen locales. Por lo tanto, no es necesario esperar a que los archivos locales se lean o carguen antes de que el trabajo pueda comenzar.

No sé mucho sobre los componentes internos de Docker, pero creo que el problema es que cada nuevo docker buildcomando copiará todos los archivos y los compilará (si detecta cambios en al menos un archivo). Entonces, lo más probable es que esto cambie varios frascos y los segundos pasos también deben ejecutarse.

Mi sugerencia es construir en la terminal (fuera de Docker) y solo Docker construye la imagen de la aplicación.

Esto incluso se puede automatizar con un complemento de gradle:

• https://github.com/Transmode/gradle-docker (un ejemplo, no busqué a fondo)

Del mismo modo que responde una adición a otras personas, si su conexión a Internet es lenta, ya que descarga dependencias cada vez, es posible que desee configurar sonatype nexus, para mantener las dependencias ya descargadas.

Como las otras respuestas han mencionado, la ventana acoplable almacena en caché cada paso de una capa. Si de alguna manera pudiera obtener solo las dependencias descargadas en una capa, entonces no tendría que volver a descargarse cada vez, suponiendo que las dependencias no hayan cambiado.

Desafortunadamente, gradle no tiene una tarea incorporada para hacer esto. Pero aún puedes solucionarlo. Esto es lo que hice:

# Only copy dependency-related files
COPY build.gradle gradle.properties settings.gradle /app/

# Only download dependencies
# Eat the expected build failure since no source code has been copied yet
RUN gradle clean build --no-daemon > /dev/null 2>&1 || true

# Copy all files
COPY ./ /app/

# Do the actual build
RUN gradle clean build --no-daemon

Además, asegúrese de que su .dockerignorearchivo tenga al menos estos elementos, para que no se envíen en el contexto de compilación de la ventana acoplable cuando se genera la imagen:

.gradle/
bin/
build/
gradle/