Dockerコンテナ: アプリケーションを正常に終了させる方法

[[411410]]

ビジネスの継続的な更新と反復により、コンテナは頻繁に起動および停止されます。コンテナが停止しているときに、コンテナ内のプログラムが実行されないと、特に一部の分散トランザクションではデータが不完全になり、データの不整合が発生する可能性があります。このため、コンテナではエレガントなシャットダウン機能が導入されています。

前回のコンテナ内で kill -9 を使用してコンテナを強制終了する方法に関する記事では、シグナルをキャプチャする方法を紹介しました。 docker stop コマンドを実行すると、docker はコンテナ内のプロセス ID 1 のプロセスに SIGTERM (kill -15) シグナルを送信します。しばらく待ってもプログラムが終了しない場合は、SIGKILL (kill -9) シグナルを送信してプロセスを強制終了します。待機時間はパラメータで設定できます

# docker stop ----time=30 foo  

ただし、docker kill コマンドを使用すると、待機時間は発生せず、SIGKILL シグナルが直接送信されます。 Kubernetes は、コンテナがシャットダウンされるときに、docker stop コマンドを通じてコン​​テナを正常にシャットダウンします。コンテナ内のアプリケーションは SIGTERM シグナルを受信すると、新しいアクセス要求を拒否し、未処理のタスクを完了して占有されているリソースを再利用します。以下は、SIGTERM シグナルを取得して正常に終了する方法を示す Go コードの例です。

用語:= make(chan os.Signal)
シグナル.Notify(term, os.Interrupt, syscall.SIGTERM)
キャンセル := make(chan 構造体{})
選択{
ケース<-用語:
 level .Warn(logger).Log(“msg“, “SIGTERM を受信しました。正常に終了します...“)
  #特定のリサイクルアクションを実行する
}

他のプログラミング言語でも同様ですが、ここで注意すべき落とし穴があります。 Docker がシャットダウンされると、プロセス ID 1 のプロセスにのみシグナルが送信されます。つまり、アプリケーションのプロセス ID が 1 でない場合、Docker から送信されたシグナルは受信されません。次の例がこれを示しています。まず、通常の JAVA プログラムである Kill.java を見てみましょう。

クラスキル{
    プライベート静的スレッドメイン;
公共 静的void main(String[] a)は例外をスローします{
        Runtime.getRuntime().addShutdownHook(新しいスレッド(新しいRunnable() {
パブリックボイド実行（）{
                システム。 .println( "TERM" );を出力します。
                main.interrupt();
 ( int i = 0; i < 4; i++)の場合{
                    システム。 .println( "busy" );出力
                    試す {
                        スレッドをスリープ状態にします(1000);
                    } (例外 e) をキャッチします {}
                }
                システム。 .println( "exit" );出力
            }
        }));
        メイン = Thread.currentThread();
        （真）の間{
            スレッドをスリープ状態にします(1000);
            システム。 .println( "run" );を実行します。
        }
    }
 }

「Javac Kill.java」を実行してコードをコンパイルし、Docker イメージにパッケージ化します。 Dockerfile は次のとおりです。

 openjdk:8-jre-alpineから
ADD Kill*.class /
エントリポイント [ "java" , "Kill" ]

コンテナを起動してコンテナに入り、「java Kill」プロセス番号が 1 であることを確認します。docker stop コマンドが実行されると、プログラムは TERM シグナルを受信し、正常に終了します。次に、Dockerfile を変更し、起動スクリプト start.sh を追加します。スクリプトは次のように 2 行のみで非常にシンプルです。

 #!/bin/sh
ジャバキル

イメージを再構築して起動します。新しい Dockerfile は次のとおりです。

 openjdk:8-jre-alpineから
ADD Kill*.class /
 start.shを追加します/
エントリポイント [ "sh" 、 "-c" 、 "/start.sh" ]

コンテナを起動した後、コンテナに入ると JAVA プロセスの ID が 7 になり、シェル (プロセス ID は 1) の子プロセスになることがわかります。

 # ps -ef
 IDユーザー     タイムコマンド
1 ルート 0:00 {start.sh} /bin/sh /start.sh
     ルート 0:00 java キル

このとき、docker stop コマンドを再度実行すると、コンテナは TERM シグナルを受信せず、デフォルトの 10 秒間の正常なシャットダウン時間後に直接終了します (実際には、SIGKILL によって直接強制終了されます)。したがって、エレガントな終了が必要な場合は、アプリケーションのプロセス ID は 1 である必要があります。

PID が 1 でない場合に正常に終了する他の方法はありますか?もちろん、一般的な方法は 2 つあります。

（１）コンテナをシャットダウンする前にprestopスクリプトを実行することができます。スクリプトは最初に JAVA プロセスの ID を動的に取得し、次に kill を介してプロセスに TERM シグナルを直接送信し、それによってプログラムを正常にシャットダウンします。以下のように表示されます。

 PID=`pidof java` && kill -SIGTERM $PID。
 （２）tiniコンテナを介してアプリケーションを起動することができます。 Tini は ID 1 のプロセスです。シグナルを受信すると、そのシグナルを子プロセスに転送し、子プロセスが適切な終了操作を実行できるようにします。また、tini 自体にもゾンビ プロセスをリサイクルする機能があります。

（２）tiniコンテナを介してアプリケーションを起動することができます。 Tini は ID 1 のプロセスです。シグナルを受信すると、そのシグナルを子プロセスに転送し、子プロセスが適切な終了操作を実行できるようにします。また、tini 自体にもゾンビ プロセスをリサイクルする機能があります。