Shulou(Shulou.com)06/02 Report--

This article focuses on "what are the common ways to optimize the size of Docker images". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn what are the common ways to optimize the size of Docker images.

Manual management

The way we can think of directly is to directly modify the official Redis image Dockerfile file, manually delete the components that are not needed after the container is running, and then rebuild a new image. This method is feasible in theory, but it is error-prone, and the effect is not particularly obvious. It is mainly unable to synchronize with the official mirror in real time.

Multi-stage construction

Docker has provided multi-stage construction since version 17.05 to solve this problem, which is achieved by discarding the middle tier and providing information about how to create the final image and its contents through the middle tier, only by retaining the components needed for containerized applications. The implementation at a higher level is as follows:

Use some images as the basis for building

Run commands as usual to build your application

Copy the required artifacts to another separate mirror

Distroless

After relying heavily on containerization technology, especially Docker, Google has long recognized the drawbacks of using bloated images. So they provide their own way to solve this problem, that is, distroless mirroring. Unlike a typical Linux basic image (bundled with a lot of software), your application is docker on distroless, and the final image contains only the application and its runtime dependencies, and standard software included in most Linux distributions, such as package managers and even shell, will be excluded. Similarly, to use the distroless image of Google, you need to use the multi-phase build we mentioned above, as follows:

FROM redis:latest AS build ARG TIME_ZONE RUN mkdir-p / opt/etc & &\ cp-a-- parents / lib/x86_64-linux-gnu/libm.so.* / opt & &\ cp-a-- parents / lib/x86_64-linux-gnu/libdl.so.* / opt & &\ cp-a-- parents / lib/x86_64-linux-gnu/libpthread.so.* / opt &\ cp-a -- parents / lib/x86_64-linux-gnu/libc.so.* / opt & &\ cp-a-- parents / usr/local/bin/redis-server / opt & &\ cp-a-- parents / usr/local/bin/redis-sentinel / opt & &\ cp / usr/share/zoneinfo/$ {TIME_ZONE:-UTC} / opt/etc/localtime FROM gcr.io/distroless/base COPY-- from=build / opt/ VOLUME / data WORKDIR / data ENTRYPOINT ["redis-server"]

Use the redis:latest-based image, then keep some of the required binaries (redis-server binaries and all related dependencies), and then use the distroless image as the basis for the final image you build to copy the contents of the opt directory into that image directory.

Then we just need to rebuild the image:

$docker build-t redis:distroless. $docker imagesREPOSITORY TAG IMAGE ID CREATED SIZEredis distroless 7d50bd873bea 15 seconds ago 28.2MBredis latest 1319b1eaa0b7 3 days ago 104MB

We can see that the image has changed from 104MB to 28.2MB, which greatly reduces the size of the image.

Note: under Linux we can use the ldd tool to find the dependencies required by the specified binaries, such as $ldd $(which redis-server).

Using distroless image to reduce the size of Docker image is a very effective method, but there is also an obvious disadvantage that there is no shell program in the final image, which makes it very difficult to debug the Docker container. Of course, this also reduces the risk of application attack and makes it more secure. If we deploy the application to the Kubernetes cluster, we can use tools like kubectl-debug to help debug the application.

Alpine Linux

Another common approach is to choose to build application images on top of Alpine Linux, a distribution that is particularly suitable for creating minimized Docker images. Apline Linux replaces glibc with the smaller musl C library and links it statically, which means that programs compiled for musl will become relocatable binaries, eliminating the need to contain shared objects, which can significantly reduce the size of the image.

The redis:alpine image is about 30MB, but the disadvantage of this is that the performance of musl is generally not as good as glibc. Of course, there is another advantage, that is, compared with the above distroless, Alpine is a mature Linux distribution, which provides basic shell access, making it more convenient to debug Docker container applications. You can also find Alpine versions of almost all popular software on Docker Hub, such as Redis, Nginx, MySQL, and so on.

GNU Guix

Finally, we can use GNU Guix, a versatile package management tool, which includes a feature to create Docker images. Guix distinguishes between package runtime dependencies and build dependencies, so Docker images built by Guix will contain only explicitly specified programs, plus their runtime dependencies, just like distroless's method. But unlike distroless, where distroless requires you to check the runtime dependencies of the program (and write Dockerfile, of course), Guix only needs to run a single command: $guix pack-f docker redis.

The size of the Redis image created by the above command is about 70MB, which is significantly smaller than the original image, and although slightly larger than the image created by the distroless and Alpine methods, using Guinx does provide some other advantages. For example, if you want your final image to include a shell to debug like Alpine, you only need to specify it when the Guxi is packaged: $guix pack-f docker redis bash, or you can continue to add it later if you want to include other software.

The functionality of Guix means that the package can be reused, so we can add Guix support to the CI/CD pipeline so that the build process is very smooth.

Some people may think Guix sounds cool, but they don't want to download and install another tool in order to build a smaller Docker image, not to mention that Guix only works under Linux, and many developers are MacOS users, so it's troublesome to configure Guix. Don't worry about this. Guix itself has a Docker image on Docker Hub, so it's not too complicated to use, just use the $docker run guix command.

In addition to Guix, it is worth mentioning that there is a package management tool called Nix, which is equally effective for every point described by Guix and applies to Nix.

At this point, I believe you have a deeper understanding of "what are the common ways to optimize the size of Docker images?" you might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.