{"id":329,"date":"2024-04-27T02:21:00","date_gmt":"2024-04-27T02:21:00","guid":{"rendered":"https:\/\/blog.ngocha.biz\/?p=329"},"modified":"2024-04-27T02:21:00","modified_gmt":"2024-04-27T02:21:00","slug":"reduce-docker-image-size","status":"publish","type":"post","link":"https:\/\/blog.ngocha.biz\/?p=329","title":{"rendered":"How to Reduce Docker Image Size: 6 Optimization Methods"},"content":{"rendered":"

If you want to reduce docker image size<\/strong>, you need to use the standard best practices in building a Docker Image<\/a>.<\/p>\n

This blog talks about different optimization techniques that you can quickly implement to make the smallest and minimal docker image<\/strong>. We will also look at some of the best tools for Docker Image Optimization<\/strong>.<\/p>\n

Docker<\/a> as a container engine makes it easy to take a piece of code & run it inside a container. It enables engineers to collect all the code dependencies and files into a single location which can be run anywhere, quite quickly & easily.<\/p>\n

The whole concept of “run anywhere<\/strong>” images starts from a simple configuration file called Dockerfile. First, we add all the build instructions, such as the code dependencies, commands, and base image details, in Dockerfile.<\/p>\n

Need for Docker Image Optimization<\/h2>\n

Even though the Docker<\/a> build process is easy, many organizations make the mistake of building bloated Docker images<\/strong> without optimizing the container images.<\/p>\n

In typical software development, each service will have multiple versions\/releases, and each version requires more dependencies, commands, and configs. This introduces a challenge in Docker image build<\/a>, as now – the same code requires more time & resources to be built before it can be shipped as a container.<\/p>\n

I have seen cases where the initial application image started with 350MB, and over time it grew to more than 1.5 GB.<\/p>\n

Also, by installing unwanted libraries, we increase the chance of a potential security risk<\/strong> by increasing the attack surface.<\/p>\n

Therefore, DevOps engineers must optimize the docker images<\/strong> to ensure that the docker image is not getting bloated after application builds or future releases. Not just for production environments, at every stage in the CI\/CD process, you should optimize your docker images.<\/p>\n

Also, with container orchestration tools<\/a> like Kubernetes, it is best to have small-sized images to reduce the image transfer and deploy time<\/strong>.<\/p>\n

How to Reduce Docker Image Size?<\/h2>\n

If we take a container image of a typical application, it contains a base image, Dependencies\/Files\/Configs<\/strong>, and cruft<\/strong> (unwanted software).<\/p>\n

\"Docker<\/figure>\n

So it all boils down to how efficiently we can manage these resources inside the container image.<\/p>\n

Let’s look at different established methods of optimizing Docker images.<\/strong> Additionally, we have given practical examples to understand docker image optimization in real time.<\/p>\n

Either you use the examples given in the article or try the optimization techniques on existing Dockerfiles.<\/p>\n

The following are the methods by which we can achieve docker image optimization.<\/p>\n

    \n
  1. Using distroless\/minimal base images<\/li>\n
  2. Multistage builds<\/li>\n
  3. Minimizing the number of layers<\/li>\n
  4. Understanding caching<\/li>\n
  5. Using Dockerignore<\/li>\n
  6. Keeping application data elsewhere<\/li>\n<\/ol>\n
    \n
    Docker Excercise Files:<\/strong><\/b> All the application code, Dockerfiles, and configs used in this article are hosted this Github repository<\/a>. You can clone it and follow along the tutorial.<\/div>\n<\/div>\n

    Method 1: Use Minimal Base Images<\/h2>\n

    Your first focus should be on choosing the right base image with a minimal OS footprint.<\/p>\n

    One such example is alpine base images. Alpine images can be as small as 5.59MB<\/strong>. It’s not just small; it’s very secure as well.<\/p>\n

    alpine       latest    c059bfaa849c     5.59MB<\/code><\/pre>\n
    Nginx alpine base image is only 22MB.<\/strong><\/p>\n
    By default, it comes with the sh shell that helps debug the container by attaching it.<\/p>\n
    You can further reduce the base image size using distroless images<\/a>. It is a stripped-down version of the operating system. Distroless base images are available for Java, Node.js, Python, Rust, etc.<\/p>\n
    Distroless images are so minimal that they don’t even have a shell in them<\/strong>. So, you might ask, then how do we debug applications? They have the debug version of the same image that comes with the busybox for debugging.<\/p>\n
    Also, most of the distributions now have minimal base images.<\/p>\n
    \n
    Note:<\/strong><\/b>You cannot directly use the publicly available base images in project environments. You need to get approval from the enterprise security team to use the base image. In some organizations, the security team itself publishes base images every month after testing & security scanning. Those images would be available in the common organization docker private repository.<\/div>\n<\/div>\n
    Method 2: Use Docker Multistage Builds<\/h2>\n
    The multistage build pattern<\/strong> is evolved from the concept of builder pattern<\/a> where we use different Dockerfiles for building and packaging the application code. Even though this pattern helps reduce the image size, it puts little overhead when it comes to building pipelines.<\/p>\n
    In multistage build, we get similar advantages as the builder pattern. We use intermediate images<\/strong> (build stages) to compile code, install dependencies, and package files in this approach. The idea behind this is to eliminate unwanted layers<\/strong> in the image.<\/p>\n
    After that, only the necessary app files required to run the application are copied over to another image with only the required libraries, i.e., lighter to run the application.<\/p>\n
    Let’s see this in action, with the help of a practical example<\/strong> where we create a simple Nodejs application and optimize its Dockerfile.<\/p>\n
    First, let’s create the code. We will have the following folder structure.<\/p>\n
    \u251c\u2500\u2500 Dockerfile1\n\u251c\u2500\u2500 Dockerfile2\n\u251c\u2500\u2500 env\n\u251c\u2500\u2500 index.js\n\u2514\u2500\u2500 package.json<\/code><\/pre>\n
    Save the following as index.js<\/code>.<\/p>\n
    const dotenv=require('dotenv'); \ndotenv.config({ path: '.\/env' });\n\ndotenv.config();\n\nconst express=require(\"express\");\nconst app=express();\n\napp.get('\/',(req,res)=>{\n  res.send(`Learning to Optimize Docker Images with DevOpsCube!`);\n});\n\n\napp.listen(process.env.PORT,(err)=>{\n    if(err){\n        console.log(`Error: ${err.message}`);\n    }else{\n        console.log(`Listening on port ${process.env.PORT}`);\n    }\n  }\n)<\/code><\/pre>\n
    Save the following as package.json<\/code>.<\/p>\n
    {\n  \"name\": \"nodejs\",\n  \"version\": \"1.0.0\",\n  \"description\": \"\",\n  \"main\": \"index.js\",\n  \"scripts\": {\n    \"test\": \"echo \\\"Error: no test specified\\\" && exit 1\"\n  },\n  \"keywords\": [],\n  \"author\": \"\",\n  \"license\": \"ISC\",\n  \"dependencies\": {\n    \"dotenv\": \"^10.0.0\",\n    \"express\": \"^4.17.2\"\n  }\n}<\/code><\/pre>\n
    Save the following port variable in a file named env<\/code>.<\/p>\n
    PORT=8080<\/code><\/pre>\n
    A simple Dockerfile<\/code> for this application would like this – Save it as Dockerfile1<\/code>.<\/p>\n
    FROM node:16\n\nCOPY . .\n\nRUN npm installEXPOSE 3000\n\nCMD [ \"node\", \"index.js\" ]<\/code><\/pre>\n
    Let’s see the storage space that it requires by building it.<\/p>\n
    docker build -t devopscube\/node-app:1.0 --no-cache -f Dockerfile1 .<\/code><\/pre>\n
    After the build is complete. Let’s check its size using –<\/p>\n
    docker image ls<\/code><\/pre>\n
    This is what we get.<\/p>\n
    devopscube\/node-app   1.0       b15397d01cca   22 seconds ago   910MB<\/code><\/pre>\n
    So the size is 910MBs<\/code>.<\/p>\n
    Now, let’s use this method to create a multistage build.<\/p>\n
    We will use node:16<\/code> as the base image, i.e., the image for all the dependencies & modules installation, <\/strong>after that, we will move the contents into a minimal and lighter ‘alpine<\/code>‘ based image. The ‘alpine<\/code>‘ image has the bare minimum utilities & hence is very light.<\/p>\n
    Here is a pictorial representation of a Docker multistage build.<\/p>\n
    \"Docker<\/figure>\n
    Also, in a single Dockerfile<\/code>, you can have multiple stages with different base images. For example, you can have different stages for build, test, static analysis, and package <\/strong>with different base images.<\/p>\n
    Let’s see what the new Dockerfile might look like. We are just copying over the necessary files from the base image to the main image.<\/p>\n
    Save the following as Dockerfile2<\/code>.<\/p>\n
    FROM node:16 as build\n\nWORKDIR \/app\nCOPY package.json index.js env .\/\nRUN npm install\n\nFROM node:alpine as main\n\nCOPY --from=build \/app \/\nEXPOSE 8080\nCMD [\"index.js\"]<\/code><\/pre>\n
    Let’s see the storage space that it requires by building it.<\/p>\n
    docker build -t devopscube\/node-app:2.0 --no-cache -f Dockerfile2 .<\/code><\/pre>\n
    After the build is complete. Let’s check its size using<\/p>\n
    docker image ls<\/code><\/pre>\n
    This is what we get.<\/p>\n
    devopscube\/node-app   2.0       fa6ae75da252   32 seconds ago   171MB<\/code><\/pre>\n
    So the new reduced image size is 171MBs<\/strong> as compared to the image with all dependencies.<\/p>\n
    That’s an optimization of over 80%!<\/em><\/p>\n
    However, if we would have used the same base image we used in the build stage, we wouldn’t see much difference.<\/p>\n
    You can further reduce the image size using distroless images<\/strong>. Here is the same Dockerfile<\/code> with a multistage build step that uses the Google nodeJS distroless image instead of alpine.<\/p>\n
    FROM node:16 as build\n\nWORKDIR \/app\n\nCOPY package.json index.js env .\/\n\nRUN npm install\n\nFROM gcr.io\/distroless\/nodejs\n\nCOPY --from=build \/app \/\n\nEXPOSE 3000\n\nCMD [\"index.js\"]<\/code><\/pre>\n
    If you build the above Dockerfile, your image will be 118MB<\/strong>,<\/p>\n
    devopscube\/distroless-node   1.0       302990bc5e76     118MB<\/code><\/pre>\n
    Method 3: Minimize the Number of Layers<\/h2>\n
    Docker images work in the following way – each RUN, COPY, FROM<\/code> Dockerfile instructions add a new layer & each layer adds to the build execution time & increases the storage requirements of the image.<\/p>\n
    Let’s see this in action, with the help of a practical example: let’s create a ubuntu image with updated & upgraded libraries, along with some necessary packages installed such as vim, net-tools, dnsutils.<\/p>\n
    A Dockerfile<\/code> to achieve this would be as follows – Save this as Dockerfile3<\/code>.<\/p>\n
    FROM ubuntu:latest\n\nENV DEBIAN_FRONTEND=noninteractive\n\nRUN apt-get update -y\n\nRUN apt-get upgrade -y\n\nRUN apt-get install vim -y\n\nRUN apt-get install net-tools -y\n\nRUN apt-get install dnsutils -y<\/code><\/pre>\n
    We wish to also look into the build time for this image.<\/p>\n
    The Docker daemon has an in-built capability to display the total execution time that a Dockerfile is taking.<\/p>\n
    To enable this feature, take the following steps –<\/p>\n
      \n
    1. Create a daemon.json<\/code> file with the following contents at \/etc\/docker\/<\/code><\/li>\n<\/ol>\n
      {\n  \"experimental\": true\n}<\/code><\/pre>\n
      2. Execute the following command to enable the feature.<\/p>\n
      export DOCKER_BUILDKIT=1<\/code><\/pre>\n
      Let’s build it and see the storage & build time.<\/p>\n
      time docker build -t devopscube\/optimize:3.0 --no-cache -f Dockerfile3 .<\/code><\/pre>\n
      It would display the execution times in the terminal.<\/p>\n
      time docker build -t devopscube\/optimize:3.0 --no-cache -f Dockerfile3 .\n\n\n[+] Building 117.1s (10\/10) FINISHED                                                                   \n => [internal] load build definition from Dockerfile                                              \n.\n.\n.\n.                                                                       \n => => writing image sha256:9601bcac010062c656dacacbc7c554b8ba552c7174f32fdcbd24ff9c7482a805      0.0s \n => => naming to docker.io\/devopscube\/optimize:3.0                                                0.0s \n                                                                                                       \nreal    1m57.219s                                                                                      \nuser\t0m1.062s\nsys\t0m0.911s<\/code><\/pre>\n
      After the build is complete – the execution time comes to be 117.1 seconds<\/strong>.<\/p>\n
      Let’s check its size using<\/p>\n
      docker image ls<\/code><\/pre>\n
      This is what we get.<\/p>\n
      devopscube\/optimize  3.0   9601bcac0100   About a minute ago   227MB\n<\/code><\/pre>\n
      So the size is 227MBs<\/strong>.<\/p>\n
      Let’s combine the RUN commands into a single layer & save it as Dockerfile4.<\/p>\n
      FROM ubuntu:latest\n\nENV DEBIAN_FRONTEND=noninteractive\n\nRUN apt-get update -y && \\\n    apt-get upgrade -y && \\\n    apt-get install --no-install-recommends vim net-tools dnsutils -y<\/code><\/pre>\n
      In the above RUN command, we have used --no-install-recommends<\/code> flag to disable recommended packages. It is recommended whenever you use install<\/code> in your Dockerfiles<\/code><\/p>\n
      Let’s see the storage & build time required by building it.<\/p>\n
      time docker build -t devopscube\/optimize:4.0 --no-cache -f Dockerfile4 .<\/code><\/pre>\n
      It would display the execution times in the terminal.<\/p>\n
      time docker build -t devopscube\/optimize:0.4 --no-cache -f Dockerfile4 .\n\n\n[+] Building 91.7s (6\/6) FINISHED                                                                      \n => [internal] load build definition from Dockerfile2                                             0.4s\n.\n.\n.  \n => => naming to docker.io\/devopscube\/optimize:4.0                                                0.0s \n                                                                                                       \nreal    1m31.874s                                                                                      \nuser\t0m0.884s\nsys\t0m0.679s<\/code><\/pre>\n
      After the build is complete – the execution time comes to be 91.7 seconds.<\/strong><\/p>\n
      Let’s check its size using<\/p>\n
      docker image ls<\/code><\/pre>\n
      This is what we get.<\/p>\n
      devopscube\/optimize  4.0   37d746b976e3   42 seconds ago      216MB<\/code><\/pre>\n
      So the size is 216MBs.<\/p>\n
      Using this optimization technique, the execution time was reduced from 117.1s to 91.7s & the storage size was reduced from 227MBs to 216MBs.<\/strong><\/p>\n
      Method 4: Understanding Caching<\/h2>\n
      Often, the same image has to be rebuilt again & again with slight modifications in code.<\/p>\n
      As Docker uses layered filesystem, each instruction creates a layer. Due to which, Docker caches the layer and can reuse it if it hasn’t changed.<\/p>\n
      Due to this concept, it’s recommended to add the lines<\/strong> which are used for installing dependencies & packages earlier inside the Dockerfile<\/code> – before the COPY<\/strong> commands.<\/p>\n
      The reason behind this is that docker would be able to cache the image with the required dependencies, and this cache can then be used<\/strong> in the following builds when the code gets modified.<\/p>\n
      Also, COPY<\/code> and ADD<\/code> instructions in a Dockerfile<\/code><\/strong> invalidate the cache for subsequent layers. Which means, Docker will rebuild all the layers after COPY and ADD.<\/p>\n
      This means, it is recomended to add instructions that are less likely to change<\/strong> earlier in the Dockerfile.<\/p>\n
      For example, let’s take a look at the following two Dockerfiles.<\/p>\n
      Dockerfile 5<\/strong> (Good Example)<\/p>\n
      FROM ubuntu:latest\n\nENV DEBIAN_FRONTEND=noninteractive\n\nRUN apt-get update -y && \\\n    apt-get upgrade -y && \\\n    apt-get install -y vim net-tools dnsutils\n\nCOPY . .<\/code><\/pre>\n
      Dockerfile 6<\/strong> (Less Optimal Example)<\/p>\n
      FROM ubuntu:latest\n\nENV DEBIAN_FRONTEND=noninteractive\n\nCOPY . .\n\nRUN apt-get update -y && \\\n    apt-get upgrade -y && \\\n    apt-get install -y vim net-tools dnsutils<\/code><\/pre>\n
      Docker would be able to use the cache functionality better<\/strong> with Dockerfile5<\/code> than Dockerfile6<\/code> due to the better placement of the COPY command.<\/p>\n
      Method 5: Use Dockerignore<\/h2>\n
      As a rule, only the necessary files need to be copied over the docker image.<\/p>\n
      Docker can ignore the files present in the working directory if configured in the .dockerignore<\/code> <\/strong>file.<\/p>\n
      It also improves caching by ignoring unnecessary files and prevents unnecessary cache invalidation.<\/strong><\/p>\n
      This feature should be kept in mind while optimizing the docker image.<\/p>\n
      Method 6: Keep Application Data Elsewhere<\/h2>\n
      Storing application data<\/strong> in the image will unnecessarily increase the size of the images.<\/p>\n
      It’s highly recommended to use the volume feature<\/strong> of the container runtimes to keep the image separate from the data.<\/p>\n
      If you are using Kubernetes, ensure<\/p>\n
      Docker Image Optimization Tools<\/h2>\n
      Following are some of the open-source tools that will help you optimize the Docker images. You can choose a tool and make it part of your Docker Image Pipeline to ensure only optimized images get created for application deployments.<\/p>\n
        \n
      1. Dive<\/strong>: It is an image explorer tool that helps you discover layers in the Docker & OCI containers images. Using Dive, you can find ways to optimize your Docker images. Check out the Dive Github repo<\/a> for more details.<\/li>\n
      2. SlimtoolKit<\/strong><\/a>: <\/strong>It helps you optimize your Docker images for security and size. Check out the Docker Slim Github repo<\/a> for more details. You can reduce the docker image size up to 30x using Slim.<\/li>\n
      3. Docker Squash:<\/strong><\/a> This utility helps you to reduce the image size by squashing image layers. The squash feature is also available in the Docker CLI using squash flag.<\/a><\/li>\n<\/ol>\n
        I will keep adding tools to this list.<\/p>\n
        Summary<\/h2>\n
        The above methods should help you build optimized Docker images and write better Dockerfiles.<\/p>\n
        Also, If you follow all the standard container best practices, you can reduce the docker image size<\/strong> to have lightweight image deployments.<\/p>\n
        Also, from a DevSecOps perspective, you can use open-source vulnerability scanning tools like Trivy<\/a> to scan Docker images<\/p>\n
        If you are getting started with your Docker journey, you can check out my article on 3 methods to run docker in docker.<\/a><\/p>\n
        If you are learning container orchestration using Kubernetes, check out comprehensive Kubernetes tutorials for beginners<\/a>.<\/p>\n
        \n
        Ngu\u1ed3n:<\/strong> How to Reduce Docker Image Size: 6 Optimization Methods \u2014 DevOpsCube<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
        Source: https:\/\/devopscube.com\/reduce-docker-image-size\/<\/p>\n","protected":false},"author":1,"featured_media":330,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-329","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops"],"_links":{"self":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/329","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=329"}],"version-history":[{"count":0,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/329\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/media\/330"}],"wp:attachment":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=329"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=329"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=329"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}