From 980528ec05aa77480535d9a604e96c41948c8c4c Mon Sep 17 00:00:00 2001 From: William Ribasczky Date: Sun, 21 Jul 2024 13:14:32 -0300 Subject: [PATCH 1/3] Update _index.md Improving documentation, explaining that installing dependencies within the Dockerfile can be overwritten by volumes in development environments --- content/build/cache/_index.md | 62 +++++++++++++++++++++++++++++++++++ 1 file changed, 62 insertions(+) diff --git a/content/build/cache/_index.md b/content/build/cache/_index.md index f61cda7aff8..ad8bee18b54 100644 --- a/content/build/cache/_index.md +++ b/content/build/cache/_index.md @@ -269,6 +269,68 @@ EOF (Note the `set -e` command to exit immediately after any command fails, instead of continuing.) +## Dealing with dependencies in development + +In previous examples we saw the importance of layer caching to deal with dependencies when packaging the application within the container, being an ideal scenario for production environments. + +But remember, in development environments most of the time the application code is shared with the container through volumes, and is not copied into the image through Dockerfile + +In these cases: +Do not run your package manager (NPM, Composer, Maven, Pip, etc.) inside the image, leave the installation to CMD or ENTRYPOINT. This is important so that the volume that we will normally share when developing does not overwrite the files installed by the package manager in the Dockerfile. + +Exemple: + +- app.js +- package.json +- Dockerfile +- docker-compose.yaml +- entrypoint.sh + +**Dockerfile** +```dockerfile +FROM node + +WORKDIR /app + +RUN mkdir -p /dockerfiles + +COPY ./entrypoint.sh /dockerfiles/entrypoint.sh + +RUN chmod +x /dockerfiles/entrypoint.sh + +ENTRYPOINT [ "/dockerfiles/entrypoint.sh" ] +``` + +**entrypoint.sh** +```shell +#!/bin/bash + +npm install + +tail -f /dev/null +``` + + +**docker-compose.yaml**: +```ỳaml +services: + node: + build: . + container_name: node + volumes: + - .:/app + networks: + - default + +networks: + default: + driver: bridge +``` + +In this case, the volume is sharing the application code with the container, completely overwriting the installation of dependencies made within the Dockerfile. + +The installation of the dependencies must be persisted in the volume that was created to handle the application code, in this case, the entrypoint will install the dependencies when the container is started. + ## Other resources For more information on using cache to do efficient builds, see: From ea651827fc5ed843bde7325a48300a8f257fe33d Mon Sep 17 00:00:00 2001 From: William Ribasczky Date: Sun, 21 Jul 2024 15:52:26 -0300 Subject: [PATCH 2/3] Update _index.md Links with document references --- content/build/cache/_index.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/content/build/cache/_index.md b/content/build/cache/_index.md index ad8bee18b54..edc669f23e8 100644 --- a/content/build/cache/_index.md +++ b/content/build/cache/_index.md @@ -273,12 +273,12 @@ of continuing.) In previous examples we saw the importance of layer caching to deal with dependencies when packaging the application within the container, being an ideal scenario for production environments. -But remember, in development environments most of the time the application code is shared with the container through volumes, and is not copied into the image through Dockerfile +But remember, in development environments most of the time the application code is shared with the container through [`volumes`](../../storage/volumes.md), and is not copied into the image through Dockerfile In these cases: -Do not run your package manager (NPM, Composer, Maven, Pip, etc.) inside the image, leave the installation to CMD or ENTRYPOINT. This is important so that the volume that we will normally share when developing does not overwrite the files installed by the package manager in the Dockerfile. +Do not run your package manager (NPM, Composer, Maven, Pip, etc.) inside the image, leave the installation to **CMD** or **ENTRYPOINT**. This is important so that the volume that we will normally share when developing does not overwrite the files installed by the package manager in the Dockerfile. -Exemple: +Exemple, In an application with this structure: - app.js - package.json @@ -327,9 +327,9 @@ networks: driver: bridge ``` -In this case, the volume is sharing the application code with the container, completely overwriting the installation of dependencies made within the Dockerfile. +The volume is sharing all the application code with the container, completely overwriting the installation of dependencies made within the Dockerfile. -The installation of the dependencies must be persisted in the volume that was created to handle the application code, in this case, the entrypoint will install the dependencies when the container is started. +The installation of the dependencies must be persisted in the volume that was created to handle the application code, in this case, the **ENTRYPOINT** will install the dependencies when the container is started. ## Other resources From 52e3a1a2db21236cba374474cfeb534f7f8a1715 Mon Sep 17 00:00:00 2001 From: William R Date: Thu, 21 Nov 2024 20:12:49 -0300 Subject: [PATCH 3/3] Update with new docs versions --- .../building-images/using-the-build-cache.md | 63 +++++++++++++++++++ 1 file changed, 63 insertions(+) diff --git a/content/get-started/docker-concepts/building-images/using-the-build-cache.md b/content/get-started/docker-concepts/building-images/using-the-build-cache.md index bbe9a328221..b73e2a713dc 100644 --- a/content/get-started/docker-concepts/building-images/using-the-build-cache.md +++ b/content/get-started/docker-concepts/building-images/using-the-build-cache.md @@ -314,11 +314,74 @@ In this hands-on guide, you will learn how to use the Docker build cache effecti By following these optimization techniques, you can make your Docker builds faster and more efficient, leading to quicker iteration cycles and improved development productivity. +## Alert in development: Dealing with dependencies in development + +In previous examples we saw the importance of layer caching to deal with dependencies when packaging the application within the container, being an ideal scenario for production environments. + +But remember, in development environments most of the time the application code is shared with the container through [`volumes`](/engine/storage/volumes/#start-a-container-with-a-volume), and is not copied into the image through Dockerfile + +In these cases: +Do not run your package manager (NPM, Composer, Maven, Pip, etc.) inside the image, leave the installation to **CMD** or **ENTRYPOINT**. This is important so that the volume that we will normally share when developing does not overwrite the files installed by the package manager in the Dockerfile. + +Exemple, In an application with this structure: + +- app.js +- package.json +- Dockerfile +- docker-compose.yaml +- entrypoint.sh + +**Dockerfile** +```dockerfile +FROM node + +WORKDIR /app + +RUN mkdir -p /dockerfiles + +COPY ./entrypoint.sh /dockerfiles/entrypoint.sh + +RUN chmod +x /dockerfiles/entrypoint.sh + +ENTRYPOINT [ "/dockerfiles/entrypoint.sh" ] +``` + +**entrypoint.sh** +```shell +#!/bin/bash + +npm install + +tail -f /dev/null +``` + + +**docker-compose.yaml**: +```ỳaml +services: + node: + build: . + container_name: node + volumes: + - .:/app + networks: + - default + +networks: + default: + driver: bridge +``` + +The volume is sharing all the application code from your machine with the container, completely overwriting the installation of dependencies made within the Dockerfile. + +The installation of the dependencies must be persisted in the volume that was created to handle the application code, in this case, the **ENTRYPOINT** will install the dependencies when the container is started. + ## Additional resources * [Optimizing builds with cache management](/build/cache/) * [Cache Storage Backend](/build/cache/backends/) * [Build cache invalidation](/build/cache/invalidation/) +* [Volumes](/engine/storage/volumes/#start-a-container-with-a-volume) ## Next steps