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

[TOC]

1. Why optimize Dockerfile

If we use Dockerfile to build Docker images, if we are not careful, the size of the image will exceed 1G, which is very scary. It's usually hundreds of trillions. Larger images often lead to migration, slow migration and slow deployment.

Dockerfile, like code, needs to be continuously optimized. Using the following optimization schemes, the size of the mirror can be greatly reduced.

two。 Optimization 2.1 reduce the number of mirror layers

The most important factor is to reduce the number of layers of the mirror, which can greatly reduce the size of the mirror.

Of course, it can be properly measured in reducing the number of layers and increasing the number of layers but reducing the compilation time.

Description:

Docker image can be seen to be layered, and the direction of layering is opposite to that of Dockerfile, from bottom to top. Each layer of the docker image is shared, that is, in the same machine, if the previous content is the same when the Dockerfile is compiled, then the corresponding layer references are the same. Of course, the content from the Dockerfile should be the same from top to bottom, and when there are different layers, the subsequent layer content will be different. Based on this principle, without any modification, the subsequent compilation will use the previous image cache. A new layer of commands forms a new layer, and if a disk update is involved and is not deleted at the same layer, it will be taken to the next layer regardless of whether the file is last deleted or not.

Based on the above instructions, the smaller the number of layers, the smaller the size of each layer, and the smaller the overall mirror image.

The following is an example of optimization based on the use of & & between adjacent commands to form only one layer.

# basic image FROM node:10.16-alpine as builder# copies static resource file COPY. / app/# working directory WORKDIR / appRUN yarn config set registry https://registry.npm.taobao.org\ & & yarn config set sass-binary-site http://npm.taobao.org/mirrors/node-sass\ & & yarn global add http-server@0.9.0\ & & yarn install\ & yarn build# exposes port EXPOSE 8 startup parameters CMD ["http-server", "build", "- p", "80"]

However, there is a situation where layering is better and the common purpose is to reduce docker compilation time, such as:

FROM alpine:latest# command1 takes a long time and is relatively stable. RUN command1# command2 involves updating content frequently, RUN command2.

Because command1 takes a long time, such as installing dependent packages, and command2 updates are frequent, such as code changes. In this scenario, if you need to install a dependency package for a long time for each compilation, the experience is very poor, because the part of installing the dependency package rarely changes, so if you separate the two layers, the previous installation of the dependency package will use the cache, so the compilation is very fast.

2.2 based on smaller mirrors

Under the premise of ensuring the function, try to use a smaller mirror image. For example, use an image based on alpine, or a mirror with alpine tag.

And using Google Distroless.

Alpine Linux is a lightweight security-oriented Linux distribution based on musl libc and busybox.

In other words, it is a smaller and more secure Linux distribution.

For example, for the following example, choose with alpine

FROM node:lts-alpineRUN apk-- no-cache add ca-certificates curl git\ & & rm-rf / var/cache/apk/*\ & & update-ca-certificates2.3 cleans up the resulting junk or temporary files at each layer

The following is a summary of the commonly used cleanup commands for basic images:

Basic image cleaning command alpinerm-rf / var/cache/apk/*centos/oraclelinuxrm-rf / var/cache/yum/*ubuntu/debianapt autoclean-y & & apt autoremove-y & & rm-rf / var/lib/apt/*

Again, this example contains the delete cache command rm-rf / var/cache/apk/*.

FROM node:lts-alpineRUN apk-- no-cache add ca-certificates curl git\ & & rm-rf / var/cache/apk/*\ & & update-ca-certificates2.4 uses .dockerboards

The .dockerkeeper file acts like .gitignore in the git project. The difference is that .dockerkeeper applies to the construction of docker images, which exists in the root directory of the docker build context and is used to exclude files or directories that do not need to be uploaded to the docker server.

When building an image, docker first looks for a .dockerkeeper file from the build context, and if so, ignores the list of files in the .dockerkeeper when uploading the context to the docker server. The obvious benefits of this are:

When building an image, it can avoid uploading unwanted large files to the server, thus slowing down the speed of construction, the consumption of network bandwidth, and reducing the volume of the image; it can avoid packaging some sensitive files and other unneeded files into the image when building the image, so as to improve the security of the image.

Example of .dockerkeeper:

. codeclimate.gitlab-ci.ymlDockerfile.git.gitignoreci

For more information on how to use it:

Https://docs.docker.com/engine/reference/builder/#dockerignore-file

2.5 use the multi-stage feature

Prerequisite: docker version 17.05 or higher

Sample Dockerfile

# basic image FROM node:10.16-alpine as builder# copies static resource file COPY. / app/# working directory WORKDIR / app# Old version uses the http-server plug-in # # Old run Command # RUN yarn config set registry https://registry.npm.taobao.org\ # & & yarn config set sass-binary-site http://npm.taobao.org/mirrors/node-sass\ # & & yarn Global add http-server@0.9.0\ # & & yarn install\ # & & yarn build## exposed port # EXPOSE 80 initiate # startup parameter # CMD ["http-server" Build ","-p " "80"] # the old version uses the http-server plug-in # # the new run command RUN yarn config set registry https://registry.npm.taobao.org\ & & yarn config set sass-binary-site http://npm.taobao.org/mirrors/node-sass\ & & yarn install\ & & yarn buildFROM nginx: 1.17.5-alpine# maintainer LABEL maintainer= "ygqygq2" # working directory WORKDIR / usr/share/nginx/htmlcopy-- from=builder / app/build. # use default It is not necessary to add # expose port # EXPOSE 8 launch commands and parameters # ENTRYPOINT ["nginx", "- g", "daemon off" "] # use default, but there is no need to add #

The key point is that

FROM image:tag AS name

Copy-- from name / path/ / path/

Reference:

[1] https://docs.docker.com/engine/reference/builder/#dockerignore-file

[2] https://docs.docker.com/develop/develop-images/multistage-build/

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.