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

The way to generate the image:

Dockerfile is based on containers.

This article introduces Dockerfile.

Document description

Dockerfile is a text document that contains commands for combining images. Docker automatically generates mirrors by reading instructions in Dockerfile.

Basic structure

Basic format:

# CommentINSTRUCTION arguments

There are mainly two types of sentences, the first line is a comment and the second line is an instruction.

Instructions (INSTRUCTION) are case-insensitive, and instructions are usually used in all uppercase in order to distinguish instructions from parameters or other content.

Docker runs the instructions of Dockerfile in order from top to bottom. In order to specify the base image, the first instruction must be FROM. A declaration that begins with a # character is considered a comment. You can use instructions such as RUN,CMD,FROM,EXPOSE,ENV in the Docker file.

Working directory

To make an image, you must first have a file directory, that is, the working directory.

The files referenced by the image must be in the working directory.

Dockerfile file, the file name is Dockerfile (the first letter is capitalized), write docker instruction.

.dockeringore file, the path written in this file will not be packaged when it is packaged.

The docker build command is used to build an image from Dockerfile. You can use the-f flag in the docker build command to point to a Dockerfile anywhere in the file system.

Environment variable

In the process of making a mirror, you can use environment variables.

Directly assign a value to a variable name, which is only valid in the current shell. However, it is not valid for other shell (child shells) started in the current shell (parent shell). For example, after the assignment, a .sh script is called, in which there are no previously assigned variables.

It is common to use the export command to create environment variables, which are valid globally.

In either case, as long as the session is closed, it is all invalidated. To be permanent, you need to edit the file.

Reference variable

You can use $KEY or ${KEY} to use environment variables. A format without curly braces must be followed by a space, and if there is no space but something else, you need to use the format with curly braces.

In addition, the form ${KEY} supports a special format for variable substitution:

\ ${KEY:-VALUE}: VALUE is the default value. If the variable does not exist, use the default value\ ${KEY:+VALUE}: return VALUE if VALUE has a value, otherwise return an empty Dockerfile instruction

Some commonly used instructions are listed here.

FROM

The FROM assignment is the most important one, and the first non-comment line at the beginning of the Dockerfile file must be used to specify the base image for the image file construction process, and subsequent instructions run in the running environment provided by this benchmark image.

In practice, the base image can be any available image file. By default, dockerfile looks for the specified image file on the docker host and automatically pulls it from the Registry if it does not exist.

Syntax format:

FROM [:] FROM @

Both of the above formats are fine. The first line is the same as pulling or running an image, there can be multiple versions of an image, which can be specified through tag. The format of the second line is specified by the ID of the mirror, and because the ID is unique, the mirror can be verified in this way. Referencing images based on names may have security issues to prevent references to images containing malicious code whose names have been modified.

MAINTAINER

Maintainer information. This directive is used in older versions and is recommended to be specified with the following LABEL.

Syntax format:

MAINTAINER

It can be any form of text message, but it is customary to use the author's name and email address:

MAINTAINER Steed Xu LABEL

Users can specify a variety of metadata for mirrors.

Syntax format:

LABEL =...

When using LABEL to specify metadata, a LABEL specification can specify one or more pieces of metadata, and when specifying multiple pieces of metadata, different metadata is separated by spaces. It is recommended that all metadata be specified through a LABEL instruction to avoid generating too many intermediate images.

COPY

Used to copy files from the Docker host to the new image file that was created.

Syntax format:

COPY... COPY [",..."]

Src is the source file or directory to be copied. The wildcard question mark (?) is supported. ) and asterisk (*). A relative path is generally used, and the starting path is the working directory.

Dest is the target path, which is generally an absolute path. If it is a relative path, the starting path is specified as WORKDIR (described later).

Both of the above formats are fine, and the list format of the second row can support paths that contain spaces.

File replication guidelines:

Src must be in the working directory if src is a directory, its internal files and subdirectories will be copied recursively, but src itself will not be replicated. If multiple src are specified, or wildcards are used in src, dest must be a directory and must end with /. If dest does not exist, it will be created automatically, including the path ADD of its parent directory.

ADD is similar to COPY in that ADD supports the use of tar files and url paths. The tar file is automatically unzipped and url downloads something like wget.

Syntax format:

ADD... ADD [",..."]

Operating guidelines:

If src is url and dest does not end with /, download the file and create it as dest. If the dest is / result, download the file to the directory of dest. Only local tar files are automatically expanded. If it is url, the downloaded file is the tar file, which will no longer be automatically expanded. If you have more than one src, or if you use wildcards, and dest ends with /, all files are downloaded to the dest directory. If the dest does not end with /, it is considered a file and the contents of the src are written directly to the dest. WORKDIR

Used to set the working directory for all RUN, CMD, ENTRYPOINT, COPY, and ADD instructions in Dockerfile.

The working directory affects not only the starting path of the subsequent command, but also the working directory after the container is started, which is the root directory by default.

Syntax format:

WORKDIR

The WORKDIR can appear multiple times, or the path can be a relative path. The relative path is the path specified relative to the previous WORKDIR.

WORKDIR can also call variables defined by the ENV (later) instruction.

Example:

# working directory is / aWORKDIR / a # working directory is / a/bWORKDIR b# working directory is / a/b/cWORKDIR cVOLUME

Used to create a mount point directory in image.

In dockerfle, you can only specify the mount point, not the path on the host. So what is mounted here can only be docker-managed volumes.

Syntax format:

VOLUME VOLUME [",", "]

If files exist before the mount point directory path, the docker run command copies all previous files to the newly mounted volume after the volume mount is complete.

EXPOSE

Used to open the specified port for the container to listen to for external communication.

Syntax format:

EXPOSE [...]

The default is the TCP protocol, which can be specified using / tcp or / udp. Directive can also specify more than one port at a time, for example:

EXPOSE 11211/tcp 11211/udpENV

Used to define the required environment variables for the image and can be called by other instructions that follow in the Dockerfile file. The invocation environment variable has been mentioned at the beginning.

Syntax format:

ENV ENV =.

In the first format, everything after key is treated as value, so only one variable can be set at a time.

In the second format, you can set more than one variable at a time, escape with a backslash (\) if the value contains spaces, or identify it by putting quotation marks on the value. In addition, the backslash can also be used for line continuation.

It is recommended that when using the second format, use a backslash to continue the line, and set a pair of key-value pairs on one line:

ENV key1=value1\ key2=value2

Environment variables of the container

In addition to setting the environment variable when making the image, you can also set the environment variable when you start the container. The docker container run startup container uses the-e parameter:

-e-- env list Set environment variables

The environment variable set when making the mirror will affect the instructions after the ENV statement. And this environment variable is retained all the time and remains in effect while the container is running. You can set a new environment variable or replace the value of the previous environment variable when you start the container. This does not affect the value of the environment variable used in the previous mirroring process. If you encounter an environment variable when making an image, you will directly obtain the current value of the variable and operate it.

Summary:

The environment variables set when making an image are not only valid in the process of making an image, but also can be set up in advance when the container is running. The environment variables set by the container runtime will only affect the process of the container running, but will not affect the previous operations in the image production process. There are exceptions to the above situation, such as the default command executed by the container contains environment variables, and the content of this command is the environment variable rather than the value of the environment variable, so write the reference of the environment variable directly to the default command. Wait until the container starts to run this command, which will not get the value of the current environment variable, that is, the value changed by the-e parameter of the run command.

Printenv view environment variables

Use the printenv command to view environment variables, as does the env command without arguments:

$docker container run-- rm-e k1=v1-e k2=v2 tinyweb1 printenvPATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/binHOSTNAME=ee6793a43c8ck1=v1k2=v2HOME=/root$

This is where you specify to run the printenv command when you start the container.

RUN

Used to specify the program to run during the docker build process, which can be any command.

Syntax format:

RUN RUN ["executable", "param1", "param2"]

The RUN instruction can be used multiple times. However, for a series of related instructions, it is recommended to use & & concatenation between multiple instructions to form an instruction, and then use a continuation character to make an instruction write one line to increase readability.

Start the instruction through shell

In the first format, command is a complete shell command and runs as / bin/sh-c.

The second format is an array, where executable is the command to run, followed by parameters to be passed. Commands in this format are not initiated with / bin/sh-c, but instead create processes directly from the kernel. As a result, common shell features such as variable substitution and wildcards are invalid. However, if you need to rely on the shell feature, you can use the following format:

RUN ["/ bin/bash", "- c", "executable param1 param2"]

Note here that the final command to be executed, including the parameters of this command, needs to be written as a complete string as an element of the list and cannot be taken apart. There will be an analysis in a later example of making a mirror.

Install the application

Most images are compiled and installed when you install an application based on the underlying image. This compilation and installation process requires the RUN directive.

Of course, you can also use yum installation. It is important to note, however, that caching is generated during yum installation. These caches are not automatically deleted and should be cleared to save mirror space. The following command clears the yum cache:

Yum clean all

In addition, the contents of the cache are saved in the / var/cache/yum/ directory. So you can also delete the files in the directory.

Clear cach

The content of this part has not been verified and may have the same effect as above.

The intermediate images created by the RUN directive are cached and used in the next build (the use here is not really needed, but because these caches are useless, but take up mirror space and should be cleared). If you do not want to use these cache images, you can specify the-- no-cache parameter at build time:

Docker build-no-cacheCMD

Specifies the program to run by default for the startup container. This is the process with a PID of 1 in the container, and the container will be terminated when it is finished. The CMD specification is similar to the RUN instruction, which also runs any command or application, but at a different point in time. RUN is performed when making an image. CMD is executed after the container starts, and only the last CMD instruction is valid, which is the main process of the specified container.

Syntax format:

CMD CMD ["executable", "param1", "param2"] CMD ["param1", "param2"]

The syntax format is the same as RUN. Just compare the instruction format description of RUN and the difference between the two formats.

There is a third format, and there is no difference between the content and the second (both are strings in form, not whether they are commands or arguments). When ENTRYPOINT is set (I'll talk about it later), all the elements in the CMD list are used as arguments to the ENTRYPOINT instruction, so there are no commands.

The following two paragraphs are derived and have nothing to do with the use of containers.

Exec command

The purpose of this short paragraph is to understand how commands started in the container become the main process with a PID of 1.

Like the RUN command, the first format is started with / bin/sh-c by default. This means that the started process does not have a PID of 1 in the container and cannot receive Unix signals. Therefore, when the container is stopped using the docker stop command, the process does not receive a SIGTERM signal. And shell is the process with PID 1, so after the program is started, the container stops. The default should be to use the mechanism of the exec command, call the process to be started and the new process will replace the parent process, that is, the process with PID 1.

Run the program in the background

This short paragraph has nothing to do with the container and is about how the traditional practice is to start the daemon directly on the host.

The traditional way to run an application on a host is to start these services by using the systemctl start command.

Another way to start manually is to execute the command on the command line. Each process should be a child of a process. Manually started programs exist by default as child processes of shell. Some programs will occupy the terminal of the current shell after startup. You can add a & symbol to the command to let the program run in the background. However, this does not change that the application is a child of shell. Once you exit the current shell, when any process terminates, its child process will be terminated first. To avoid this, you also need the nobub command to split the process started by the subsequent command from the relationship of the current shell process, so that the program can continue to run when it exits shell.

So you can start the program and keep it running in the following ways:

Nohup COMMAND & nohup COMMAND > / dev/null 2 > & 1 & ENTRYPOINT

A function similar to the CMD directive that specifies the default running program for the container. However, programs started by ENTRYPOINT will not be overwritten by the parameters specified by the docker run command. And the command-line arguments are passed as arguments to the program specified by the ENTRYPOINT instruction.

In docker run, you can still override the program specified by the ENTRYPOINT instruction with the-- entrypoint parameter.

Syntax format:

ENTRYPOINT ENTRYPOINT ["executable", "param1", "param2"]

The command arguments passed in by the docker run command override the contents of the CMD directive and are appended to the ENTRYPOINT command and finally used as its arguments.

With regard to the application of ENTRYPOINT, let's take a look at the example of dynamically generating configuration files.

USER

Used to specify the user name or UID when running image, or when running any program specified by the RUN, CMD, ENTRYPOINT instructions in Dockerfile. By default, container runs as the root user.

Syntax format:

USER userUSER user:groupUSER uidUSER uid:gidUSER user:gidUSER uid:group

The uid and gid here can be any number, but they must be valid, or the docker run command will fail.

HEALTHCHECK

The HEALTHCHECK directive tells Docker how to test the container to see if it is still working. Even if the server process is still running, this can detect situations such as Web servers that are stuck in an infinite loop and are unable to handle new connections.

Syntax format:

HEALTHCHECK [OPTIONS] CMD HEALTHCHECK NONE

On the first line, check the health of the container by running the command inside the container.

The second line disables any health checks inherited from the underlying image.

The container can have a health detection method by default. It's just that the default method does not apply to some scenarios, so you need to customize it. CMD is the keyword, followed by a command for health monitoring.

Parameter description:

-- interval: polling time. Default is 30 seconds-timeout: timeout. Default is 30 seconds-- start-priod: how long after the container starts testing. Default is 0 seconds. If the main process starts slowly, you need to set a parameter retries: confirm that the health check fails, and the number of times you need to check the failure. Default is 3 times.

The CMD keyword is followed by a health check command, and docker determines the health status based on the return value of this command. The meaning of the returned value of the run result:

0: success 1: unhealthy 2: reserved value, meaningless

Instruction example

This is a simple example:

HEALTHCHECK-- interval=5m-- timeout=3s\ CMD curl-f http://localhost/ | | exit 1

There may be no curl command, and it is the same with the wget command:

CMD wget-O-Q http://localhost/

This command may also need to be modified, and a message will be output each time wget succeeds. Although the log output is silenced with-Q, the content downloaded by wget is still output. The-O parameter is used here to specify the standard output. Hopefully it will be solved by redirecting to / dev/null if there is no output.

If the logic of the check is not that simple, you may need to write a script to call:

HEALTHCHECK-interval=10s-timeout=5s-retries=3\ CMD / bin/sh / opt/health_test.sh

Contents of the health check script:

#! / bin/shss-antl | grep 80if [$? = = 0]; then exit 0else exit 1fi

Check the health of the container

When a container specifies a health check, it has a health state in addition to its normal state. This state was originally starting. Every time the health check passes, it becomes healthy (the previous state). After a certain number of successive failures, it becomes unhealthy.

Use the docker ps command to check the status of the container, and you can see the status of the health check:

[root@Docker img4] # docker psCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMESb6dea4e8a808 ngx1-1 "nginx-g'daemon of..." 2 seconds ago Up 1 second (health: starting) 0.0.0.0 health 32776-> 80/tcp ngx1 [root@Docker img4] # docker psCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMESb6dea4e8a808 ngx1-1 "nginx-g 'daemon of …" 4 seconds ago Up 3 seconds (healthy) 0.0.0.0 healthy 32776-> 80/tcp ngx1 [root@Docker img4] # docker psCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES21c80cbd2898 ngx1-1 "nginx-g'daemon of …" 19 seconds ago Up 18 seconds (unhealthy) 0.0.0.0 unhealthy 32777-> 80/tcp ngx1 [root@Docker img4] #

There are three states, those that are not checked after startup (health: starting), those that check for success (healthy), and those that confirm failure (unhealthy).

SHELL

The SHELL directive allows you to override the default shell for the command line. The default shell on Linux is ["/ bin/sh", "- c"], while on Windows ["cmd", "/ S", "/ C"].

Syntax format:

SHELL ["executable", "parameters"]

There is only one format, and you must use the JSON format.

Get to know it, it's generally useless.

STOPSIGNAL

The STOPSIGNAL instruction sets the system call signal that will be sent to the container to exit. This signal can be a valid unsigned number that matches the location in the kernel's system call table, such as 9, or a signal name in SIGNAME format, such as SIGKILL.

Syntax format:

STOPSIGNAL signal

It is also a matter of understanding, but it is generally not necessary, and it is not clear here.

ARG

The set variable command, which specifies the variables that are passed to the build runtime. The ARG command defines a variable that specifies parameters when docker build creates a mirror using the options of the following build command:

-- build-arg =

If you have multiple variables, use this option multiple times.

Syntax format:

ARG [=]

When you use ARG to define variables, you can add default values.

When docker build is called, there is no-- env option to pass the value of the environment variable. So to use environment variables, you can only use the default values of environment variables. Using the ARG variable, you can pass a value to the ARG variable.

This feature allows a dockerfile to be applied to many different scenarios.

ONBUILD

Used to define a trigger in Dockerfile. When the constructed image is used as the base mirror for other mirrors, the trigger in that mirror will be triggered.

Syntax format:

ONBUILD

The keyword is followed by a normal dockerfile instruction.

Images built with Dockerfile containing ONBUILD instructions should use special tags, such as ruby:2.0-onbuild

Make a mirror image

Here, let's make some images and try the above instructions.

Httpd Mirror

Create a working directory:

[root@Docker ~] # mkdir img1 [root@Docker ~] # cd img1/ [root@Docker img1] # echo "Dockerfile httpd v1" > index.html```

Go to the working directory and create an index.html file.

Create a Dockerfile file:

[root@Docker img1] # vim Dockerfile# Description: First imageFROM busyboxLABEL maintainer= "Steed Xu" COPY index.html / var/www/VOLUME / var/www/EXPOSE 80

Create an image in the working directory:

[root@Docker img1] # pwd/root/img1 [root@Docker img1] # docker build-t tinyweb1 .Sending build context to Docker daemon 3.072kBStep 1 db8ee88ad75fStep 5: FROM busybox-- > db8ee88ad75fStep 2 db8ee88ad75fStep 5: LABEL maintainer= "Steed Xu"-- > Running in 786069882d16Removing intermediate container 786069882d16-- > 890d4ab97cd1Step 3 Steed Xu 5: COPY index.html / var/www/-- > 5ba063c97abbStep 4 hand 5: VOLUME / var/www/-- > Running in 18351ed13a43Removing intermediate container 18351ed13a43-- > 50c1ae0d6350Step 5max 5: EXPOSE 80-- > Running in 2e7885323425Removing intermediate container 2e7885323425-> 0656cb8b15bcSuccessfully built 0656cb8b15bcSuccessfully tagged tinyweb1:latest [root@Docker img1] # docker imagesREPOSITORY TAG IMAGE ID CREATED SIZEtinyweb1 latest 0656cb8b15bc About a minute ago 1.22MBbusybox latest db8ee88ad75f 7 days ago 1.22MB [root@Docker img1] #

Run the image:

[root@Docker img1] # docker container run-- name app1-- rm-d-P tinyweb1 httpd-f-h / var/www/ [root@Docker img1] # docker container port app180/tcp-> 0.0.0.0 name app1 32769 [root@Docker img1] #

The-P parameter is used here, and the mapped port is random. Use the command to see the port mapping.

Enter the inside of the mirror. The command executed in this container is httpd, and there is no shell in it, so you need to start a shell with exec before you can enter the internal operation:

[root@Docker img1] # docker container exec-it app1 / bin/sh/ # psPID USER TIME COMMAND 1 root 0:00 httpd-f-h / var/www/ 7 root 0:00 / bin/sh 11 root 0:00 ps/ #

Use the mount command inside the container to view the mounted volumes:

[root@Docker ~] # docker container exec app1 mount | grep / var/www/dev/mapper/centos-root on / var/www type xfs (rw,seclabel,relatime,attr2,inode64,noquota) [root@Docker ~] # use environment variables

Similar to the example above, the environment variable is used this time, and the CMD command is specified:

[root@Docker img2] # pwd/root/img2 [root@Docker img2] # vi Dockerfile # Description: Second imageFROM busyboxLABEL maintainer= "Steed Xu"\ app= "httpd" ENV WEB_DOC_ROOT= "/ var/www/" COPY index.html $WEB_DOC_ROOTRUN echo 'Hello' > > ${WEB_DOC_ROOT} / index.htmlCMD httpd-f-h ${WEB_DOC_ROOT} VOLUME $WEB_DOC_ROOTEXPOSE 80

Create a mirror:

[root@Docker img2] # docker build-t tinyweb2 .Sending build context to Docker daemon 3.072kBStep 1 httpd 8: FROM busybox-> db8ee88ad75fStep 2 httpd 8: LABEL maintainer= "Steed Xu" app= "httpd"-- > Running in e32a21495f34Removing intermediate container e32a21495f34-- > 67f721eaedfaStep 3 httpd 8: ENV WEB_DOC_ROOT= "/ var/www/"-- > Running in ba2d4b1b2cf1Removing intermediate container ba2d4b1b2cf1-- > 844a0dc0bbccStep 4 docker build 8: COPY index.html $WEB_DOC_ROOT-- > 1af7b350289fStep 5max 8 : RUN echo 'Hello' > ${WEB_DOC_ROOT} / index.html-- > Running in f61511fe6020Removing intermediate container f61511fe6020-- > 2305f131626eStep 6e24a76680fb0Step 8: CMD httpd-f-h ${WEB_DOC_ROOT}-- > Running in aff5ee08fb46Removing intermediate container aff5ee08fb46-- > e24a76680fb0Step 7max 8: VOLUME $WEB_DOC_ROOT-- > Running in b59115d147c3Removing intermediate container b59115d147c3-- > a2e176849eafStep 8max 8: EXPOSE 80-> Running in c981ab7e0137Removing intermediate container c981ab7e0137-- > b8f7225afb7aSuccessfully built b8f7225afb7aSuccessfully tagged tinyweb2:latest [root@Docker img2] #

Run the container:

[root@Docker img2] # docker container run-- name app2-- rm-dP tinyweb27cbf240f0b323c329deb3dd36fd2ae6f1fe630c394f035f723f6124d5d6c5094 [root@Docker img2] # docker container port app280/tcp-> 0.0.0.0 name app2 32770 [root@Docker img2] #

There's no problem here.

Use the inspect command to view the container default startup command. You can view the inspect of the image:

[root@Docker img2] # docker image inspect tinyweb2

You can also view the inspect of the container:

[root@Docker img2] # docker container inspect app2

View the content of Cmd as follows:

"Cmd": ["/ bin/sh", "- c", "httpd-f-h ${WEB_DOC_ROOT}"]

Here, take a look back at the CMD instruction in Dockerfile:

CMD httpd-f-h ${WEB_DOC_ROOT}

/ bin/sh-c is automatically added here. Because the above CMD instruction uses the first format. If you use the second format of the instruction, you need to write:

CMD ["/ bin/sh", "- c", "httpd-f-h ${WEB_DOC_ROOT}"]

Or avoid using environment variables, instead of using / bin/sh-c, which is started directly from the kernel:

CMD ["httpd", "- f", "- h", "/ var/www/"]

Wrong specified parameter for CMD

In the second format of CMD, the first element of the list is the command to be executed, and the subsequent elements are the arguments to the command. A parameter as an element. The httpd command here, including all its parameters, adds up to the parameters of a complete / bin/sh command.

The following instruction is incorrect:

CMD ["/ bin/sh", "- c", "httpd", "- f", "- h ${WEB_DOC_ROOT}"]

Use docker ps-a-- no-trunc to view the COMMAND field

"/ bin/sh-c httpd-f'- h ${WEB_DOC_ROOT}'"/ bin/sh-c 'httpd-f-h ${WEB_DOC_ROOT}'"

The first line is what the error format looks like here, where the logic is to execute the command / bin/sh, and this command takes four parameters. The reality, however, is that the / bin/sh command has only two arguments, one is-c, and the other is all the rest.

The second line is what it looks like to parse correctly, with two parameters for a command.

The following instruction is also wrong:

CMD ["httpd", "- f", "- h / var/www/"]

You need to take the path as a separate parameter.

If you encounter a problem, there is a way to check it.

Start the container without the-- rm parameter to ensure that it will not be deleted automatically if the container fails to start.

Use the docker logs command to view the logs in the container, mainly the error message after the default startup command is executed.

Use docker ps-a-- no-trunc to see the complete startup command, and here you can see what the command looks like when it is executed.

Use the-it parameter of the docker run command and modify the default startup command to / bin/sh so that you can go inside the container and execute the command. Debug a command that can be executed correctly.

Dynamically generate configuration files

What is implemented here is the dynamic generation of configuration files based on environment variables. First, run a script with the ENTRYPOINT instruction to complete the dynamic generation of the configuration file, and finally, by calling the exec "$@" command, the contents of the CMD instruction can be called and replaced as the main process.

Customize a script to dynamically write to the configuration file:

[root@Docker img3] # pwd/root/img3 [root@Docker img3] # vi entrypoint.sh #! / bin/shcat > / etc/nginx/conf.d/www.conf 55ceb2abad47Step 2 nginx 7: LABEL maintainer= "Steed Xu" app= "nginx"-- > Running in 41050cf8bb89Removing intermediate container 41050cf8bb89-- > 3bfa564b1ac3Step 3 nginx 7: ENV NGX_DOC_ROOT= "/ usr/share/nginx/html/"-- > Running in b8c929746310Removing intermediate container b8c929746310-- > 2cb3fc5f5c8dStep 4 3bfa564b1ac3Step 7: ADD entrypoint. Sh / bin/-> ecf314c9c29cStep 5 nginx 7: CMD ["nginx" "- g", "daemon off "]-- > Running in 93d44caaa473Removing intermediate container 93d44caaa473-- > eaf4da71e3c7Step 6 bin/entrypoint.sh 7: ENTRYPOINT [" / bin/entrypoint.sh "]-> Running in ecffdcda0486Removing intermediate container ecffdcda0486-- > 71f4222fc33eStep 7 EXPOSE 7: EXPOSE 80-> Running in 4582fa6067d2Removing intermediate container 4582fa6067d2-- > 24de242b6dfcSuccessfully built 24de242b6dfcSuccessfully tagged ngx1:latest [root@Docker img3] #

Take a look at the configuration file:

[root@Docker img3] # docker container run-- name app3-- rm ngx1 cat / etc/nginx/conf.d/www.confserver {server_name 38dd4a661a6f; listen 0.0.0.0 etc/nginx/conf.d/www.confserver 80; root / usr/share/nginx/html/;} [root@Docker img3] # docker container run-- name app3-- rm-e HOSTNAME=ngx1 ngx1 cat / etc/nginx/conf.d/www.confserver {server_name ngx1; listen 0.0.0.0 Root / usr/share/nginx/html/;} [root@Docker img3] #

The configuration file changes dynamically according to the environment variables.

Most dockerfile starts the service after accepting the parameters through the ENTRYPOINT script. That's what it does here.

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.