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

This article introduces the knowledge of "how to build a private image in Dockerfile". Many people will encounter this dilemma in the operation of actual cases, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

1. Use Dockerfile to customize the image

The customization of the image is actually customizing the configuration and files added by each layer. We can write the commands for each layer to modify, install, build, and operate into a script, which is called Dockerfile.

Dockerfile is a text file that contains instructions, each of which builds a layer, so the content of each instruction is to describe how the layer should be built.

Take nginx as an example.

1. Create a Dockerfile file

In a blank directory, create a text file and name it Dockerfile:

Mkdir mynginxcd mynginxtouch Dockerfile

The content is:

FROM nginxRUN echo 'Hello, Docker' > / usr/share/nginx/html/index.html

FROM: specify the base image

If you use scratch-based mirroring, it means that you are not based on any mirrors, and the following instructions will exist as the first layer of the mirrors.

For Linux statically compiled programs, you don't need an operating system to provide run-time support, and all the libraries you need are already in the executable, so direct FROM scratch makes the image smaller. Many applications developed in the Go language use this way to create images, which is one of the reasons why some people think that Go is a particularly suitable language for container microservice architecture.

The so-called custom image must be based on an image and be customized on it. The base image must be specified, and FROM is the specified base image, so FROM in a Dockerfile is a necessary instruction and must be the first instruction. There are many high-quality official images on Docker Hub, and there are images of service classes that can be used directly, such as nginx, redis, mysql, tomcat, and so on. You can customize the image based on one that best meets our ultimate goal.

If the corresponding service image is not found, some more basic operating system images are also provided in the official image, such as ubuntu, debian, centos, alpine and so on. The software libraries of these operating systems provide us with more room for expansion.

In addition to selecting an existing mirror as the base mirror, Docker also has a special mirror called scratch. This image is a virtual concept, does not actually exist, it identifies a blank image.

FROM scratch...

RUN: execute command

Shell format: RUN

RUN echo 'Hello, Docker' > / usr/share/nginx/html/index.html

Exec format: RUN ["executable file", "parameter 1", "parameter 2"]

RUN tar-zxf redis.tar.gz-C / usr/src/redis-- strip-components=1RUN make-C / usr/src/redisRUN make-C / usr/src/redis install

The RUN instruction is used to execute command-line commands. Because of the power of the command line, the RUN instruction is one of the most commonly used instructions when customizing images. There are two formats:

two。 Build an image

Above, we customized the nginx image using Dockerfile, and then we need to build the image.

Execute in the same directory as the Dockerfile file:

Docker build-t nginx:v3.

From the output of the command, we can clearly see the process of building the image. In Step2, the RUN directive starts a container xxx1, executes the required command, and finally submits this layer of xxx2, and then deletes the container xxx1 used.

2. Dockerfile instruction explains COPY copy file in detail

Format:

COPY...

COPY [",..."]

The COPY directive copies the file / directory in the build context directory to the location in the mirror of the new layer. For example:

COPY package.json / usr/src/app/

The source path can be multiple or even wildcards, such as:

COPY hom* / mydir/COPY hom?.txt / mydir/

ADD more advanced copy files

The format and nature of the ADD instruction and COPY are basically the same. But some functions have been added to COPY. For example, the source path can be a URL, in which case the Docker engine will try to download the linked file.

In Docker's official Dockerfile best practices document, you are required to use COPY as much as possible, because the semantics of COPY is clear, just copying files, while ADD contains more complex functions, its behavior is not necessarily clear, and is most suitable for scenarios where ADD is used, which is the situation mentioned that requires automatic decompression.

When choosing between the COPY and ADD instructions, you can follow the principle that all file copies use the COPY command, and use ADD only where automatic decompression is required.

CMD Container start Command

The format of the CMD instruction is similar to that of RUN, but there are also two formats:

Shell format: CMD

Exec format: CMD ["executable", "parameter 1", "parameter 2".]

Parameter list format: CMD ["Parameter 1", "Parameter 2",...]. After the ENTRYPOINT instruction is specified, specify the specific parameters with CMD.

Docker is either a virtual machine or a container is a process. Since it is a process, you need to specify the program and parameters to run when you start the container. The CMD directive is used to specify the default container main process startup command.

ENTRYPOINT entry point

The purpose of ENTRYPOINT, like CMD, is to start the program and parameters in the specified container. ENTRYPOINT can also be replaced at run time, but it is slightly more cumbersome than CMD and needs to be specified by the parameter entrypoint of docker run.

When ENTRYPOINT is specified, the meaning of CMD changes. Instead of running its command directly, it passes the contents of CMD to the ENTRYPOINT instruction as an argument, in other words, when it is actually executed, it becomes:

"

ENV sets environment variables

There are two formats:

ENV

ENV = =

This instruction is very simple, just set the environment variable, whether it is other subsequent instructions, such as RUN, or run-time applications, you can directly use the environment variables defined here.

ENV VERSION=1.0 DEBUG=on NAME= "Happy Feet" $VERSION # uses environment variables

The following directives can support environment variable expansion: ADD, COPY, ENV, EXPOSE, LABEL, USER, WORKDIR, VOLUME, STOPSIGNAL, ONBUILD.

ARG construction parameters

Format:

ARG [=]

The build parameters have the same effect as ENV, setting environment variables. The difference is that the environment variables of the build environment set by ARG will not exist when the container runs in the future. But don't use ARG to save information like passwords, because docker history can still see all the values.

The ARG instruction in Dockerfile is to define the parameter name and define its default value. This default value can be overridden with-- build-arg = in the build command docker build.

VOLUME defines Anonymous Volume

Format:

VOLUME [","...]

VOLUME

When the container is running, we should try to keep the container storage layer from writing operations. For applications where database classes need to save dynamic data, the database files should be saved in volume. In order to prevent users from forgetting to hang the directories saved by dynamic files as volumes, in Dockerfile, we can specify some directories to be mounted as anonymous volumes, so that if the user does not specify to mount them at run time, Its application can also run normally without writing a large amount of data to the container storage layer.

VOLUME / data

The / data directory here is automatically mounted as anonymous volumes at run time, and any information written to / data will not be recorded in the container storage layer, thus ensuring that the container storage layer is stateless. Of course, the runtime can override this mount location. For example:

Docker run-d-v mydata:/data xxxx

EXPOST declaration port

Format: EXPOSE [...]

The EXPOSE directive declares that the runtime container provides the service port, which is just a declaration that the application of the service will not be opened at run time because of this declaration.

Writing such a declaration in Dockerfile has two benefits:

Is to help mirror consumers understand the daemon port of the mirror service to facilitate the configuration of mapping.

When random ports are mapped at runtime, that is, docker run-P, EXPOST ports are automatically randomly mapped.

WORKDIR specifies the working directory

Format: WORKDIR

Use the WORKDIR directive to specify the working directory (or current directory). Later, the current directory of each layer will be changed to the specified directory. If the directory does not exist, WORKDIR will help you set up the directory.

I mentioned earlier that some common mistakes made by beginners equate Dockerfile with Shell scripts. This misunderstanding may also lead to errors such as the following:

RUN cd / appRUN echo "hello" > world.txt

If you run the build image via this Dockerfile, you will find that / app/world.txt is not found.

Reason:

In Shell, two consecutive lines are the same process execution environment, so the memory state modified by the previous command will directly affect the latter command.

In Dockerfile, the execution environments of these two lines of RUN commands are fundamentally different, and they are two completely different containers. This is the error caused by a lack of understanding of Dockerfile's concept of building tiered storage.

Each RUN starts a container, executes commands, and then commits changes to the storage layer files.

The execution of the first layer of RUN cd / app is just a change in the working directory of the current process, a change in memory, and the result does not cause any file changes. On the other hand, when you get to the second layer, you start a brand new container, which has nothing to do with the first layer container, so it is naturally impossible to inherit the memory changes in the previous layer.

If you need to change the location of the working directory for future layers, you should use the WORKDIR directive.

USER specifies the current user

Format: USER

USER instructions are similar to WORKDIR in that they change the state of the environment and affect subsequent layers. WORKDIR is to change the working directory, and USER is to change the identity of the layer to execute commands such as RUN, CMD, and ENTRYPOINT.

Of course, like WORKDIR, USER only helps you switch to a designated user, who must be established in advance, otherwise you can't switch.

RUN groupadd-r redis & & useradd-r-g redis redisUSER redisRUN ["redis-server"]

HEALTHCHECK health check

Format:

HEALTHCHECK [options] CMD: sets the command to check the health of the container.

HEALTHCHECK NONE: if the basic image has a health check instruction, you can block its health check instruction.

The HEALTHCHECK instruction, which tells Docker how to determine whether the state of the container is normal, is a new instruction introduced by Docker 1.12. Specify a line of command through this instruction, and use this command to determine whether the service status of the container main process is really long, so as to reflect the actual state of the container.

After a HEALTHCHECK instruction is specified in an image, the container is started with it. The initial state will be starting. After the health check is successful, it will become healthy. If it fails for a certain number of times in a row, it will become unhealthy.

HEALTHCHECK supports the following options:

-- the interval between two health check-ups in interval=:. Default is 30 seconds.

-- the timeout=: health check command runs for a timeout. If this time is exceeded, this health check is considered to have failed. The default is 30 seconds.

-- retries=: after a specified number of consecutive failures, the container status is regarded as unhealthy, with a default of 3 times.

To help troubleshoot, the output of the health check command (including stdout and stderr) is stored in the health check status and can be viewed with docker inspect.

ONBUILD makes clothes for others.

Format: ONBUILD

ONBUILD is a special instruction that is followed by other instructions, such as RUN, COPY, and so on, which are not executed during the current image build. It is executed only when the image is based on the current image to build the next level of mirror.

Other instructions in Dockerfile are step-by-step to customize the current image, but ONBUILD is prepared to help others customize themselves.

3. Other mirror production methods docker save and docker load

Docker also provides docker save and docker load commands to save the image as a tar file, transfer it to another location, and load it in. This is the practice when there is no Docker Registry, and it is no longer recommended that you use Docker Registry directly for image migration, whether you use Docker Hub directly or private Registry in the private network.

For example: save nginx image

Docker save nginx | gzip > nginx-latest.tar.gz

Then we copy the nginx-latest.tar.gz file to another machine and load the image again:

That's all for docekr load-I nginx-latest.tar.gz, "how to build a private image with Dockerfile". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.