Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
En esta página, se describe cómo compilar imágenes de Docker más eficaces.
Compila contenedores más eficientes
Cuando creas contenedores para una aplicación, los archivos que no se necesitan en el entorno de ejecución, como las dependencias de tiempo de compilación y los archivos intermedios, se pueden incluir inadvertidamente en la imagen del contenedor. Estos archivos innecesarios pueden aumentar el tamaño de la imagen del contenedor y agregar tiempo y costo adicionales cuando la imagen se mueve entre tu registro de Docker y el entorno de ejecución de tu contenedor.
Para ayudar a reducir el tamaño de la imagen de tu contenedor, separa la compilación de la aplicación, junto con las herramientas usadas para compilarla, del ensamblaje del contenedor de entorno de ejecución.
Cloud Build proporciona una serie de contenedores de Docker con herramientas para desarrolladores comunes como Git, Docker y Google Cloud CLI. Usa estas herramientas a fin de definir un archivo de configuración de compilación con un paso de compilación de la aplicación y otro paso para ensamblar su entorno de ejecución final.
Por ejemplo, si compilas una aplicación Java, que requiere archivos como el código fuente, las bibliotecas de la aplicación, los sistemas de compilación, las dependencias del sistema de compilación y el JDK, es posible que tengas un Dockerfile similar al siguiente:
FROM java:8
COPY . workdir/
WORKDIR workdir
RUN GRADLE_USER_HOME=cache ./gradlew buildDeb -x test
RUN dpkg -i ./gate-web/build/distributions/*.deb
CMD ["/opt/gate/bin/gate"]
En el ejemplo anterior, Gradle, que se usa a fin de compilar el paquete, descarga muchas bibliotecas para funcionar. Estas bibliotecas son indispensables para la compilación del paquete, pero no son necesarias en el entorno de ejecución. Todas las dependencias del entorno de ejecución se juntan en el paquete.
Con cada comando en el Dockerfile, se crea una capa nueva en el contenedor. Si se generan datos en esa capa y no se borran en el mismo comando, ese espacio no se puede recuperar. En este caso, Gradle descarga cientos de megabytes de bibliotecas en el directorio cache para realizar la compilación, pero las bibliotecas no se borran.
Una forma más eficaz de realizar la compilación es usar Cloud Build a fin de separar la compilación de la aplicación de la compilación de su capa de entorno de ejecución.
El ejemplo siguiente separa el paso de compilación de la aplicación Java del paso de ensamblaje del contenedor del entorno de ejecución:
YAML
Compila la aplicación: En cloudbuild.yaml, agrega un paso para compilar la aplicación.
Con el siguiente código, se agrega un paso que compila la imagen java:8, que contiene el código de Java.
Ensambla el contenedor de entorno de ejecución: En cloudbuild.yaml, agrega un paso para ensamblar el contenedor de entorno de ejecución.
Con el siguiente código, se agrega un paso llamado gcr.io/cloud-builders/docker que ensambla el contenedor de entorno de ejecución. Define el contenedor de entorno de ejecución en un archivo diferente llamado Dockerfile.slim.
En el ejemplo, se usa la capa base de Alpine Linux openjdk:8u111-jre-alpine, que es increíblemente eficiente. Además, incluye el JRE, en lugar del JDK más voluminoso que era necesario para compilar la aplicación.
Ensambla el contenedor de entorno de ejecución: En cloudbuild.json, agrega un paso para ensamblar el contenedor de entorno de ejecución.
Con el siguiente código, se agrega un paso llamado gcr.io/cloud-builders/docker que ensambla el contenedor de entorno de ejecución. Define el contenedor de entorno de ejecución en un archivo diferente llamado Dockerfile.slim.
En el ejemplo, se usa la capa base de Alpine Linux openjdk:8u111-jre-alpine, que es increíblemente eficiente. Además, incluye el JRE, en lugar del JDK más voluminoso que era necesario para compilar la aplicación.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-04 (UTC)"],[[["\u003cp\u003eBuilding leaner Docker images involves separating the application build process from the assembly of the runtime environment.\u003c/p\u003e\n"],["\u003cp\u003eUnnecessary files, such as build-time dependencies and intermediate files, can bloat container image sizes, adding extra time and cost.\u003c/p\u003e\n"],["\u003cp\u003eCloud Build can be used to define separate steps for building the application and assembling its runtime environment, leveraging tools like Git, Docker, and the Google Cloud CLI.\u003c/p\u003e\n"],["\u003cp\u003eUsing a separate, lean base layer like Alpine Linux (e.g., \u003ccode\u003eopenjdk:8u111-jre-alpine\u003c/code\u003e) in a \u003ccode\u003eDockerfile.slim\u003c/code\u003e can significantly reduce the final image size by only using the JRE instead of the JDK.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003ecloudbuild.yaml\u003c/code\u003e or \u003ccode\u003ecloudbuild.json\u003c/code\u003e files define the build steps to build and assemble the runtime container, using a separate \u003ccode\u003eDockerfile.slim\u003c/code\u003e and creating the final Docker image.\u003c/p\u003e\n"]]],[],null,["# Building leaner containers\n\nThis page describes how to build leaner Docker images.\n\nBuilding leaner containers\n--------------------------\n\nWhen you containerize an application, files that are not needed at runtime, such\nas build-time dependencies and intermediate files, can be inadvertently included\nin the container image. These unneeded files can increase the size of the\ncontainer image and thus add extra time and cost as the image moves between your\nDocker registry and your container runtime.\n\nTo help reduce the size of your container image, separate the building of the\napplication, along with the tools used to build it, from the assembly of the\nruntime container.\n\nCloud Build provides a [series of Docker\ncontainers](https://github.com/GoogleCloudPlatform/cloud-builders) with common\ndeveloper tools such as Git, Docker, and the Google Cloud CLI. Use\nthese tools to define a build config file with one step to build the\napplication, and another step to assemble its final runtime environment.\n\nFor example, if you're building a Java application, which requires files such as\nthe source code, application libraries, build systems, build system\ndependencies, and the JDK, you might have a Dockerfile that looks like the\nfollowing: \n\n FROM java:8\n\n COPY . workdir/\n\n WORKDIR workdir\n\n RUN GRADLE_USER_HOME=cache ./gradlew buildDeb -x test\n\n RUN dpkg -i ./gate-web/build/distributions/*.deb\n\n CMD [\"/opt/gate/bin/gate\"]\n\nIn the above example, Gradle, which is used to build the package, downloads a\nlarge number of libraries in order to function. These libraries are essential to\nthe building of the package, but are not needed at runtime. All of the runtime\ndependencies are bundled up in the package.\n\nEach command in the `Dockerfile` creates a new layer in the container. If data\nis generated in that layer and is not deleted in the same command, that space\ncannot be recovered. In this case Gradle is downloading hundreds of megabytes of\nlibraries to the `cache` directory in order to perform the build, but the\nlibraries are not deleted.\n\nA more efficient way to perform the build is to use Cloud Build to\nseparate building the application from building its runtime layer.\n\nThe following example separates the step for building the Java application from\nthe step for assembling the runtime container: \n\n### YAML\n\n1. **Build the application** : In `cloudbuild.yaml`, add\n a step to build the application.\n\n The following code adds a step that builds the `java:8` image,\n which contains the Java code. \n\n ```\n steps:\n\n - name: 'java:8'\n env: ['GRADLE_USER_HOME=cache']\n entrypoint: 'bash'\n args: ['-c', './gradlew gate-web:installDist -x test']\n\n ```\n2. **Assemble the runtime container** : In `cloudbuild.yaml`, add a step to assemble the runtime container.\n\n \u003cbr /\u003e\n\n The following code adds a step named\n `gcr.io/cloud-builders/docker` that assembles the runtime\n container. It defines the runtime container in a separate file named\n `Dockerfile.slim`.\n\n The example uses the Alpine Linux base layer\n `openjdk:8u111-jre-alpine`, which is incredibly lean. Also, it\n includes the JRE, instead of the bulkier JDK that was necessary to build the\n application. \n\n ```\n cloudbuild.yaml\n\n steps:\n - name: 'java:8'\n env: ['GRADLE_USER_HOME=cache']\n entrypoint: 'bash'\n args: ['-c',\n './gradlew gate-web:installDist -x test']\n\n - name: 'gcr.io/cloud-builders/docker'\n args: ['build',\n '-t', 'gcr.io/$PROJECT_ID/$REPO_NAME:$COMMIT_SHA',\n '-t', 'gcr.io/$PROJECT_ID/$REPO_NAME:latest',\n '-f', 'Dockerfile.slim',\n '.'\n ]\n\n\n Dockerfile.slim\n\n FROM openjdk:8-jre-alpine\n\n COPY ./gate-web/build/install/gate /opt/gate\n\n CMD [\"/opt/gate/bin/gate\"]\n ```\n3. **Create the Docker images** : In `cloudbuild.yaml`, add a step to create the images. \n\n ```\n steps:\n - name: 'java:8'\n env: ['GRADLE_USER_HOME=cache']\n entrypoint: 'bash'\n args: ['-c', './gradlew gate-web:installDist -x test']\n - name: 'gcr.io/cloud-builders/docker'\n args: ['build',\n '-t', 'gcr.io/$PROJECT_ID/$REPO_NAME:$COMMIT_SHA',\n '-t', 'gcr.io/$PROJECT_ID/$REPO_NAME:latest',\n '-f', 'Dockerfile.slim', '.']\n images:\n - 'gcr.io/$PROJECT_ID/$REPO_NAME:$COMMIT_SHA'\n - 'gcr.io/$PROJECT_ID/$REPO_NAME:latest'\n ```\n\n### JSON\n\n1. **Build the application** : In `cloudbuild.json`, add a step to\n build the application.\n\n The following code adds a step named `java:8` for\n building the Java code. \n\n ```\n {\n \"steps\": [\n {\n \"name\": \"java:8\",\n \"env\": [\n \"GRADLE_USER_HOME=cache\"\n ],\n \"entrypoint\": \"bash\",\n \"args\": [\n \"-c\",\n \"./gradlew gate-web:installDist -x test\"\n ]\n },\n }\n ```\n2. **Assemble the runtime container** : In `cloudbuild.json`, add a\n step to assemble the runtime container.\n\n The following code adds a step named\n `gcr.io/cloud-builders/docker` that assembles the runtime\n container. It defines the runtime container in a separate file named\n `Dockerfile.slim`.\n\n The example uses the Alpine Linux base layer\n `openjdk:8u111-jre-alpine`, which is incredibly lean. Also, it\n includes the JRE, instead of the bulkier JDK that was necessary to build the\n application. \n\n ```\n cloudbuild.json:\n\n {\n \"steps\": [\n {\n \"name\": \"java:8\",\n \"env\": [\n \"GRADLE_USER_HOME=cache\"\n ],\n \"entrypoint\": \"bash\",\n \"args\": [\n \"-c\",\n \"./gradlew gate-web:installDist -x test\"\n ]\n },\n {\n \"name\": \"gcr.io/cloud-builders/docker\",\n \"args\": [\n \"build\",\n \"-t\",\n \"gcr.io/$PROJECT_ID/$REPO_NAME:$COMMIT_SHA\",\n \"-t\",\n \"gcr.io/$PROJECT_ID/$REPO_NAME:latest\",\n \"-f\",\n \"Dockerfile.slim\",\n \".\"\n ]\n }\n ],\n }\n\n Dockerfile.slim:\n\n FROM openjdk:8u111-jre-alpine\n\n COPY ./gate-web/build/install/gate /opt/gate\n\n CMD [\"/opt/gate/bin/gate\"]\n ```\n3. **Create the Docker images** : In `cloudbuild.json`, add a step to create the images. \n\n ```\n {\n \"steps\": [\n {\n \"name\": \"java:8\",\n \"env\": [\n \"GRADLE_USER_HOME=cache\"\n ],\n \"entrypoint\": \"bash\",\n \"args\": [\n \"-c\",\n \"./gradlew gate-web:installDist -x test\"\n ]\n },\n {\n \"name\": \"gcr.io/cloud-builders/docker\",\n \"args\": [\n \"build\",\n \"-t\",\n \"gcr.io/$PROJECT_ID/$REPO_NAME:$COMMIT_SHA\",\n \"-t\",\n \"gcr.io/$PROJECT_ID/$REPO_NAME:latest\",\n \"-f\",\n \"Dockerfile.slim\",\n \".\"\n ]\n }\n ],\n \"images\": [\n \"gcr.io/$PROJECT_ID/$REPO_NAME:$COMMIT_SHA\",\n \"gcr.io/$PROJECT_ID/$REPO_NAME:latest\"\n ]\n }\n ```"]]
