Experience the health of docker containers at a fast speed

Experience the health of docker containers at a fast speed

The purpose of this article is to experience the health check function of the docker container. It is based on experience and does not involve development. The content related to development will be detailed in a later article.

About container health check

Consider this situation: In the docker environment, the container of the springboot application is still there, but it can no longer provide services (for example, data or files are destroyed, resources such as thread pools are exhausted, etc.). At this time, a way is needed to obtain Know this state. At this point, the container health check (HEALTHCHECK) comes in handy. As long as the container provides its own state information according to Docker's rules, the container health information can be notified to the outside world in various ways;

Version requirements

The official docker documentation states that the HEALTHCHECK function has been provided since version 1.12. Here is a brief introduction to the version number of the docker community edition:

  1. Version 1.12 was released on July 28, 2016;
  2. Version 1.13.1 was released on February 08, 2017. After this version, the docker version naming rules have changed and changed to "YY.MM" format;
  3. The 17.03.0-ce version was released on March 1, 2017, and the "YY.MM" format version naming has been since then;
  4. The actual docker environment today is version 19.03.2;

Actual combat environment information

  1. Operating system: macOS Catalina 10.15
  2. Docker: 19.03.2

Start to experience

  1. Enter the following command in the console to create a container with health check information:
docker run --rm/
--name=healthcheck/
-p 8080:8080/
--health-cmd="curl --silent --fail localhost:8080/getstate || exit 1"/
--health-interval=15s/
--health-retries=10/
--health-timeout=5s/
bolingcavalry/dockerhealthcheck:0.0.1-SNAPSHOT 
  1. There are four parameters related to health check in the above command. Here is an explanation:
parameter name effect
health-cmd The specified command is executed in the container to check the health status of the container
health-interval The interval of each health check, the default is 30 seconds
health-retries Assuming the value is 3, it means that if the returned results of three consecutive tests are all unhealthy, the container is judged to be unhealthy, and the default value is 3.
health-timeout Timeout period, 30 seconds by default

  1. Regarding the health-cmd parameter, the most commonly used shell command is, for example, curl --silent --fail localhost:8080/getstate || exit 1 in this example, which means to initiate an http request to port 8080 of the container. If the http responds The code is 200, and the return value of the entire shell is 0. At this time, docker determines that the container is healthy. If the http response code is not 200, the return value of the shell is 1, and docker determines that the container is unhealthy at this time;
  2. Open another console window and execute docker ps to view the status of the container. Pay attention to the STATUS field. It can be seen that when the container is just created, it is in the health: starting state, and it will change to the healthy state later:
(base) zhaoqindeMacBook-Pro:~ zhaoqin$ docker ps
CONTAINER ID        IMAGE                                            COMMAND                  CREATED             STATUS                             PORTS               NAMES
d86c11321cef        bolingcavalry/dockerhealthcheck:0.0.1-SNAPSHOT   "java -Xms1g -Xmx1g  "   13 seconds ago      Up 12 seconds (health: starting)   8080/tcp            healthcheck
(base) zhaoqindeMacBook-Pro:~ zhaoqin$ docker ps
CONTAINER ID        IMAGE                                            COMMAND                  CREATED             STATUS                    PORTS               NAMES
d86c11321cef        bolingcavalry/dockerhealthcheck:0.0.1-SNAPSHOT   "java -Xms1g -Xmx1g  "   17 seconds ago      Up 16 seconds (healthy)   8080/tcp            healthcheck 
  1. The actual combat image provides http interface localhost:8080/getstate, which is used to return the state of the container. Each time it is called, a line of information will be printed on the console. The container log is as follows:
2019-10-20 03:05:02.350  INFO 1 --- [nio-8080-exec-1] o.s.web.servlet.DispatcherServlet        : Initializing Servlet 'dispatcherServlet'
2019-10-20 03:05:02.364  INFO 1 --- [nio-8080-exec-1] o.s.web.servlet.DispatcherServlet        : Completed initialization in 14 ms
2019-10-20 03:05:02.384  INFO 1 --- [nio-8080-exec-1] c.b.d.DockerhealthcheckApplication       : step probe return success
2019-10-20 03:05:17.584  INFO 1 --- [nio-8080-exec-2] c.b.d.DockerhealthcheckApplication       : step probe return success
2019-10-20 03:05:32.748  INFO 1 --- [nio-8080-exec-3] c.b.d.DockerhealthcheckApplication       : step probe return success 

It can be seen that after the container is started, this interface will be called every 15 seconds;

Simulate unhealthy state

  1. In the previous operation, we know that as long as the return code of the container's http interface localhost:8080/getstate is 200, the container is judged to be healthy;
  2. To see what the unhealthy state looks like, as long as the return code of the http interface localhost:8080/getstate is not 200;
  3. This image provides another interface to observe the unhealthy state. Assuming that the IP address of the host computer is 102.168.0.3, enter 192.168.0.3:8080/setstate?state=false in the browser. After the interface is called, localhost:8080/The return code of getstate changed from 200 to 403;
  4. Look at the console information of the container again. This time the content has changed, from step probe return success to step probe return fail. At this time, the return code of the getstate interface is 403:
2019-10-20 03:38:51.428  INFO 1 --- [nio-8080-exec-3] c.b.d.DockerhealthcheckApplication       : step probe return success
2019-10-20 03:39:06.592  INFO 1 --- [nio-8080-exec-9] c.b.d.DockerhealthcheckApplication       : step probe return fail
2019-10-20 03:39:21.757  INFO 1 --- [io-8080-exec-10] c.b.d.DockerhealthcheckApplication       : step probe return fail
2019-10-20 03:39:36.912  INFO 1 --- [nio-8080-exec-3] c.b.d.DockerhealthcheckApplication       : step probe return fail 
  1. The value of the health-retries parameter when creating the container is 10, which means that the return code of localhost:8080/getstate 10 times in a row will be judged as unhealthy if the return code is not 200. Therefore, the console should output step probe return fail ten times in a row. Execute the docker ps command to observe the status of the container. It should still be healthy. After more than ten step probe return fail output, check the container status again, and it becomes healthy:
(base) zhaoqindeMacBook-Pro:~ zhaoqin$ docker ps
CONTAINER ID        IMAGE                                            COMMAND                  CREATED             STATUS                      PORTS                    NAMES
070e56cc99f2        bolingcavalry/dockerhealthcheck:0.0.1-SNAPSHOT   "java -Xms1g -Xmx1g  "   18 minutes ago      Up 18 minutes (unhealthy)   0.0.0.0:8080->8080/tcp   healthcheck 
  1. To restore the health status: Enter 192.168.0.3:8080/setstate?state=true in the browser, so the return code of the localhost:8080/getstate interface becomes 200 again. Observe the console, as long as "step probe return success" is output once, The health status of the container is restored to healthy;

Observe container events

  1. Enter docker events --filter event=health_status in the console to observe all container health status events on the host;
  2. According to the above operation, enter 192.168.0.3:8080/setstate?state=true or 192.168.0.3:8080/setstate?state=false in the browser, change the health state of the container several times, and observe the container event changes:
(base) zhaoqindeMacBook-Pro:~ zhaoqin$ docker events --filter event=health_status
2019-10-20T12:19:18.349588676+08:00 container health_status: unhealthy 2d538f8752ae1e94ce23f34b7fb71c8f2ea3a075df82943ffdbe62c49ad4d6c8 (image=bolingcavalry/dockerhealthcheck:0.0.1-SNAPSHOT, name=healthcheck)
2019-10-20T12:20:19.030857534+08:00 container health_status: healthy 2d538f8752ae1e94ce23f34b7fb71c8f2ea3a075df82943ffdbe62c49ad4d6c8 (image=bolingcavalry/dockerhealthcheck:0.0.1-SNAPSHOT, name=healthcheck) 

At this point, the docker container health experience is complete, and we have a basic understanding of this function. In actual combat, we will try to make our application container support the health check function;

Welcome to pay attention to the public account: programmer Xin Chen