This is the fourth day of my participation in the August Text Challenge.More challenges in August

First, write first

We also mentioned that ENTRYPOINT and CMD can specify the container start command. Because these two commands are the core of how to write a dockerfile, so I will separate them out and talk about them again.

CMD is different from ENTRYPOINT

CMD and ENTRYPOINT are both commands used to specify start container execution. The difference is that:

  • The daemon ignores CMD commands when there are arguments in the Docker run command.
  • Using the ENTRYPOINT directive is not ignored and receives the Docker Run argument attached to the command line.

The dockerFile we write must contain a CMD or ENTRYPOINT directive for the container to start properly.

CMD and ENTRYPOINT

1.CMD

CMD directives come in three forms:

  • CMD ["executable","param1","param2"](execForm, this is the preferred form)
  • CMD ["param1","param2"](asDefault parameters for ENTRYPOINT)
  • CMD command param1 param2(Shell form)

When a dockerfile contains more than one CMD, only the last one is loaded and used.

Dockerhub = dockerHub = dockerHub = dockerHub

Basically, each official image will provide us with a link to their own version of dockerfile, as follows:

Let’s look at the Dockerfile for the latest TAB

FROM scratch
ADD centos-8-x86_64.tar.xz /
LABEL org.label-schema.schema-version="1.0"     org.label-schema.name="CentOS Base Image"     org.label-schema.vendor="CentOS"     org.label-schema.license="GPLv2"     org.label-schema.build-date="20201204"
CMD ["/bin/bash"]
Copy the code

There are only four lines, and that’s all the dockerfile that builds a latest version of centos8.3.2011 image. Specify the base image (in this case, build from scratch, an empty image), add rootfs content, label, and specify the startup command through CMD.

In addition to centos, debian, Ubuntu, busybox and other images only need to specify the startup command through CMD. Busybox, for example, is more minimalist:

FROM scratch
ADD busybox.tar.xz /
CMD ["sh"]
Copy the code

To build this base class, utility class image we need only specify a necessary CMD to start the container. But we’re not writing a Dockerfile to start the container, most of the time we’re going to run our app, run our services in the container.

It is also possible to start using CMD, but there is a drawback to this. The CMD start command we mentioned above will be replaced by the Docker run parameter.

We have the following Dockerfile

[root@localhost dockerfiles]# cat Dockerfile 
FROM centos
CMD ["/bin/top","-b"]
Copy the code

After the build, start the container with the ps parameter.

[root@localhost dockerfiles]# docker run  -it  centos_top:v1  ps
  PID TTY          TIME CMD
    1 pts/0    00:00:00 ps
Copy the code

You can see that after starting the container, top-b has been replaced with ps instead of implementing the parameter replacement. Obviously that’s not what we want. Is there a way to start the application by default and still load the Docker Run parameter? This is where ENTRYPOINT and CMD come in.

2. The ENTRYPOINT combining with CMD

Exec and shell forms of ENTRYPOINT:

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

As mentioned above, the CMD [“param1″,”param2”] form can be used as an ENTRYPOINT parameter, and the command specified by ENTRYPOINT cannot be replaced by the docker run parameter. If we combine CMD and ENTRYPOINT directives, then we can receive the Docker run parameter through CMD and pass the parameter to ENTRYPOINT for execution.

Nginx official Dockerfile latest version 1.21 as an example

First we look at the Dockerfile, here we only focus on the start command, as follows:

. COPY docker-entrypoint.sh / COPY 10-listen-on-ipv6-by-default.sh /docker-entrypoint.d COPY 20-envsubst-on-templates.sh /docker-entrypoint.d COPY 30-tune-worker-processes.sh /docker-entrypoint.d ENTRYPOINT ["/docker-entrypoint.sh"] EXPOSE 80 STOPSIGNAL SIGQUIT CMD ["nginx", "-g", "daemon off;"]Copy the code

To start the nginx container, run the docker-entrypoint.sh script and run the nginx -g “daemon off;” command. Pass it in. That is, starting the container when docker run does not add parameters is equivalent to executing the following script and default parameters.

#docker-entrypoint.sh nginx -g "daemon off;"
Copy the code

What happens when we pass in a parameter using docker Run?

I passed in nginx – the debug

#docker run -dt nginx nginx-debug -g "daemon off;"
Copy the code

To start the container, execute the following script and parameters

#docker-entrypoint.sh nginx-debug -g "daemon off;"
Copy the code

Let’s take a look at the container we started through Photoshop

[root@localhost dockerfiles]# ps -ef|grep nginx
root      6327  6306  0 Aug12 pts/0    00:00:00 nginx: master process nginx -g daemon off;
101       6384  6327  0 Aug12 pts/0    00:00:00 nginx: worker process
101       6385  6327  0 Aug12 pts/0    00:00:00 nginx: worker process
root     16800 16780  3 12:51 pts/0    00:00:00 nginx: master process nginx-debug -g daemon off;
101      16857 16800  0 12:51 pts/0    00:00:00 nginx: worker process
101      16858 16800  0 12:51 pts/0    00:00:00 nginx: worker process
​
Copy the code

Nginx and nginx-debug containers have been started successfully.

That means we passENTRYPOINT ["/docker-entrypoint.sh"]The specified command is executed at startup anyway, and can receive arguments to docker Run.

What is docker-entrypoint.sh? Docker-entrypoint. sh this is a preprocessing script that is usually used to filter command-line arguments or execute exec to start the process in container 1.

Implementing default command arguments via ENTRYPOINT+CMD or accepting Docker run arguments is a very popular and useful way to write dockerfiles.

I hope the essay is helpful to you. If there are any mistakes, please correct them.

You are free to reprint, modify, publish this article, without my consent. Iqsing.github. IO

\