問題描述
我正在使用基于 debian/jessie 的圖像 java:7u79 在 Docker 容器中運行 dropwizard Java 應用程序.
I am running a dropwizard Java application in a Docker container using the image java:7u79 based on debian/jessie.
我的 Java 應用程序處理 SIGTERM 信號以正常關閉.當我在沒有 Docker 的情況下運行應用程序時，SIGTERM 處理非常完美.
My Java application handles the SIGTERM signal to shutdown gracefully. The SIGTERM handling works perfect when I run the application without Docker.
當我在 Docker 容器中運行它時，當我發出 docker stop 命令時，SIGTERM 不會到達 Java 應用程序.它會在 10 秒后突然終止進程.
When I run it in a Docker container the SIGTERM does not reach the Java application when I issue a docker stop command. It kills the process abruptly after 10 seconds.
我的Dockerfile:
FROM java:7u79
COPY dropwizard-example-1.0.0.jar /opt/dropwizard/
COPY example.keystore /opt/dropwizard/
COPY example.yml /opt/dropwizard/
WORKDIR /opt/dropwizard
RUN java -jar dropwizard-example-1.0.0.jar db migrate /opt/dropwizard/example.yml
CMD java -jar dropwizard-example-1.0.0.jar server /opt/dropwizard/example.yml
EXPOSE 8080 8081
這個 Dockerfile 有什么問題?有沒有其他方法可以解決這個問題?
What is wrong with this Dockerfile? Is there any other way to tackle this problem?
推薦答案
假設您通過在 Dockerfile 中定義以下內容來啟動 Java 服務:
Assuming you launch a Java service by defining the following in your Dockerfile:
CMD java -jar ...
當您現在進入容器并列出進程時，例如通過 docker exec -it <containerName>ps AHf (我沒有嘗試使用 java 而是使用 ubuntu 圖像)您會看到您的 Java 進程不是根進程(不是進程PID 1) 但 /bin/sh 進程的子進程:
When you now enter the container and list the processes e.g. by docker exec -it <containerName> ps AHf (I did not try that with the java but with the ubuntu image) you see that your Java process is not the root process (not the process with PID 1) but a child process of a /bin/sh process:
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 18:27 ? 00:00:00 /bin/sh -c java -jar ...
root 8 1 0 18:27 ? 00:00:00 java -jar ...
所以基本上你有一個 Linux shell，它是 PID 1 的主進程，它有一個 PID 8 的子進程 (Java).
So basically you have a Linux shell that is the main process with PID 1 which has a child process (Java) with PID 8.
要使信號處理正常工作，您應該避免使用那些 shell 父進程.這可以通過使用內置的 shell 命令 exec 來完成.這將使子進程接管父進程.所以最后以前的父進程不再存在.并且子進程成為 PID 為 1 的進程.在 Dockerfile 中嘗試以下操作:
To get signal handling working properly you should avoid those shell parent process. That can be done by using the builtin shell command exec. That will make the child process taking over the parent process. So at the end the former parent process does not exist any more. And the child process becomes the process with the PID 1. Try the following in your Dockerfile:
CMD exec java -jar ...
然后進程列表應該顯示如下:
The process listing then should show something like:
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 18:30 ? 00:00:00 java -jar ...
現在你只有一個 PID 為 1 的進程.一般來說，一個好的做法是讓 docker 容器只包含一個進程 - PID 為 1 的那個(或者如果你真的需要更多進程，那么你應該使用例如 supervisord 作為 PID 1，它自己負責子進程的信號處理).
Now you only have that one process with PID 1. Generally a good practice is to have docker containers only contain one process - the one with PID 1 (or if you really need more processes then you should use e.g. supervisord as PID 1 which itself takes care of signal handling for its child processes).
通過該設置，Java 進程將直接處理 SIGTERM.中間沒有任何 shell 進程可以中斷信號處理.
With that setup the SIGTERM will be treated directly by the Java process. There is no shell process any more in between which could break signal handling.
編輯:
同樣的 exec 效果可以通過使用不同的 CMD 語法來實現(感謝 Andy 發表評論):
The same exec effect could be achieved by using a different CMD syntax that does it implicitly (thanks to Andy for his comment):
CMD ["java", "-jar", "..."]
這篇關于使用'docker stop'和官方java圖像的java進程沒有收到SIGTERM的文章就介紹到這了，希望我們推薦的答案對大家有所幫助，也希望大家多多支持html5模板網！