DockerのPID 1ゾンビの収獲問題

こんにちは、Habr！

Hexletでは、Dockerを使用して、アプリケーション自体と関連サーバーを起動し、実際のプログラミング演習でカスタムコードを実行しています。 これらの軽量コンテナがなければ、これらのタスクに対処することははるかに困難になります。 Dockerは素晴らしいテクノロジーですが、予期しない問題が発生する場合があります。 これらの問題の1つ（およびその解決策）は、Phusionブログ（Phusion Passengerの作成者です）で説明されています。今日、その翻訳を公開しています。



約1年前、Dockerがバージョン0.6であったときに、Baseimage-dockerを初めて導入しました。 これは、Docker用に特別に変更された最小限のUbuntuイメージです。 人々はこの基本的なイメージをDockerレジストリから取得し、イメージのベースとして使用できます。



私たちはDockerの初期ユーザーであり、CIを使用して、バージョン1.0のリリースよりもずっと前に作業環境を作成しました。 Dockerの原則に固有の問題を解決するための基本的なイメージを作成しました。 たとえば、Dockerは、子プロセスを正しく処理する特別なinitプロセスの下でプロセスを開始しないため、ゾンビプロセスが多数の問題を引き起こす可能性があります。 Dockerはsyslogに対しても何もしないため、重要なメッセージが失われる可能性があります。 などなど。



しかし、多くの人が私たちが直面している問題を理解していないことがわかりました。 はい、これらはかなり低レベルのUnixシステムメカニズムであり、誰もが理解しているわけではありません。 したがって、この投稿では、私たちが解決する最も重要な問題、PID 1ゾンビの収獲問題について説明します。







それは判明した：

1. 私たちが解決する問題は多くの人々に関連しています。
2. 多くの人は自分の存在を知らないので、ある時点で予期しない問題が必ず発生します（マーフィーの法則）。
3. 誰もが自分で問題を解決する場合、それは非常に無効になります。

そのため、誰でも使用できるユニバーサルベースイメージであるBaseimage-dockerで決定しました。 このイメージは、Dockerイメージの開発者に（必要と思われるように）必要な多数の便利なツールを追加します。 すべての画像のベースとしてBaseimage-dockerを使用します。



コミュニティは私たちの仕事を気に入っています。私たちの画像は、UbuntuとCentOSの公式画像に続いて、Dockerレジストリで3番目に人気があります。

PID 1の問題：ゾンビの収集

Unixのすべてのプロセスは、ツリー形式で表示されます。 各プロセスは子プロセスを生成し、各プロセスには最上位（またはルート）を除く親があります。



ルートプロセスはinitです。 システムの起動時にカーネルによって起動されます。 initは、SSHデーモン、Dockerデーモン、Apache / Nginxの起動、GUIの起動など、システムの残りの部分を起動します。 次に、それぞれが子プロセスを起動します。







異常なことは何もありません。 しかし、プロセスが終了するとどうなりますか？ bashプロセス（PID 5）が完了したとしましょう。 「ゾンビプロセス」とも呼ばれる、いわゆる「無効プロセス」に変わります。







なぜこれが起こっているのですか？ Unixは、終了ステータスコードを取得するために、親プロセスが子プロセスの完了を待機する方法で作成されます。 親プロセスがシステムコールのwaitpid（）ファミリを使用してこのアクションを完了するまで、ゾンビプロセスが存在します。 これが男からの引用です：

終了したが、待機していない子は「ゾンビ」になります。 カーネルは、親が後で子に関する情報を取得するために待機を実行できるように、ゾンビプロセスに関する最小限の情報（PID、終了ステータス、リソース使用情報）を保持します。

通常、ゾンビプロセスは混乱を引き起こす何らかの暴走プロセスであると考えられます。 しかし、正式には、Unixオペレーティングシステムの観点から、ゾンビプロセスには明確な定義があります。 これらは完了したプロセスですが、親プロセスはまだ完了するのを待っています。



ほとんどの場合、これは問題ではありません。 ゾンビを処理するためのwaitpid（）システムコールは、「リーピング」（収集、処理）と呼ばれます。 多くのアプリケーションは、子プロセスを正しく処理します。 上記のsshdの例では、bashが終了すると、OSはsshdプロセスにSIGCHLDシグナルを送信して起動します。 Sshdはこれに気づき、子プロセスを処理（「リープ」）します。







しかし、特別な場合があります。 親プロセスが意図的またはユーザーのアクションにより終了したと想像してください。 その子プロセスはどうなりますか？ 彼らにはもはや親がいないので、彼らは「孤児」になります（これは専門用語です）。



ここで、initプロセスが役立ちます。 初期化プロセスのPID 1には、孤立したプロセスを「採用」するという特別なタスクがあります（これもまた実際の技術用語です）。 これは、initが実際にinitによって生成されたわけではないにもかかわらず、initがそのようなプロセスの親になることを意味します。



デフォルトで悪魔化されているNginxの例を考えてみましょう。 Nginxは最初に子プロセスを作成します。 その後、メインのNginxプロセスが終了します。 Nginxの子プロセスがinitに採用されました。







OSのカーネルは、initから特別な動作を期待します。カーネルは、initが採用されたプロセスも処理（収集、「獲得」）する必要があると考えています。



これはUnixで非常に重要な機能です。 それは非常に基本的であるため、多くのプログラムは正しい動作のために設計されています。 ほとんどのデーモンは、initによってデーモン化されたプロセスが採用および処理されるように設計されています（つまり、ゾンビになった後に正しく完了します）。



例として悪魔を使用しますが、このメカニズムは悪魔だけにまで及びません。 子を持つプロセスが終了するたびに、initはその背後にあるすべてのものをクリーンアップすることを期待しています。 これについては、 オペレーティングシステムの概念とUNIX環境での高度なプログラミングの 2つの非常に優れた書籍で詳しく説明されています 。

ゾンビプロセスが有害なのはなぜですか？

ゾンビプロセスが完了したプロセスであるにもかかわらず、なぜ有害なのですか？ 結局、確かにプロセスに割り当てられたメモリは既に解放されており、ゾンビはpsの単なる行ですか？



はい、このプロセスのメモリはすでに解放されています。 しかし、プロセスがpsでまだ見えるという事実は、カーネルリソースを使用することを意味します。 waitpidの男からの引用です：

ゾンビが待機によってシステムから削除されない限り、カーネルプロセステーブルのスロットを消費し、このテーブルがいっぱいになると、それ以上プロセスを作成できなくなります。



ゾンビが待機を使用してシステムから削除されるまで、カーネルプロセステーブルのスロットを使用します。このテーブルがいっぱいの場合、新しいプロセスを作成することはできません。

そして、ここでDocker

Dockerはどうですか？ 多くの人は、コンテナで1つのプロセスのみを実行します。 しかし、ほとんどの場合、このプロセスは適切な初期化のようには動作しません。 つまり、採用されたプロセスを正しく処理する代わりに、別の初期化プロセスがこれを行うべきであると考えています。 そして彼はとても正しいと考えています。



特定の例を見てみましょう。 コンテナに、bashで記述されたCGIスクリプトを実行するWebサーバーが含まれているとします。 スクリプトはgrepを呼び出します。 次に、Webサーバーは、スクリプトの処理が長すぎると判断し、それを強制終了します。 ただし、grepは実行されたままです。 作業が完了すると、ゾンビに変わり、PID 1プロセス（Webサーバー）に採用されます。 Webサーバーはgrepについて何も知らないため、完了を処理せず、ゾンビgrepはシステムに残ります。



問題は他の状況にも当てはまります。 多くは、PostgreSQLなどのサードパーティアプリケーション用のコンテナを作成し、これらのアプリケーションをコンテナ内の唯一のプロセスとして実行します。 他の誰かのコードを実行すると、それが子プロセスを生成せず、それがゾンビに変わりませんか？ コードを実行し、コードとコードが使用するライブラリを確実に知っていれば、すべて問題ありません。 ただし、一般的な場合、問題を解決するには正しいinitを実行する必要があります。

しかし、完全なシステムinitを開始すると、コンテナーは仮想マシンのような重いものに変わりませんか？

initシステムは必ずしも重いとは限りません。 おそらく、Upstart、Systemd、SysVなどを考えているでしょう。 おそらく、コンテナ内ではシステム全体を実行する必要があると思われます。 そうではありません。 「完全な初期化システム」はオプションであり、必要ありません。



必要なシステムは、アプリケーションを起動し、採用されたプロセスを収集することがタスクである単純な小さなプログラムです。 このような単純なinitシステムの使用は、Dockerの哲学と完全に一致しています。

シンプルな初期化システム

おそらく既製のソリューションがありますか？ ほぼ。 古き良きbash。 Bashは採用されたプロセスを処理します。 Bashは何でも実行できます。 Dockerfileのこのような行の代わりに...

CMD ["/path-to-your-app"]()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

書ける

 CMD ["/bin/bash", "-c", "set -e && /path-to-your-app"]()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

（-eディレクティブは、bashがスクリプトを単純なコマンドとして認識し、exec（）が直接認識することを禁止します）。



結果はプロセスの階層です：







しかし、残念ながら、このアプローチには問題があります。 信号は処理しません！ killを使用してSIGTERMシグナルをbashプロセスに送信するとします。 Bashは終了しますが、SIGTERMをその子プロセスに送信しません！







bashが終了すると、カーネルは内部のすべてのプロセスでコンテナー全体を終了します。 これらのプロセスはSIGKILLで終了します。 したがって、これらのプロセスを完全に完了する方法はありません。 アプリケーションがファイルに何かを書き込むとしましょう。 記録中にアプリケーションがこの方法で終了した場合、ファイルが破損する可能性があります。 プロセスの異常終了は悪いです。 サーバーから電源コードを引くようなものです。



しかし、initプロセスがSIGTERMシグナルで終了することに注意する必要があるのはなぜですか？ docker stopはSIGTERMをinitプロセスに送信するためです。 「Docker stop」は、「docker start」を使用して起動できるように、コンテナを正しく停止する必要があります。



Bashの専門家は、おそらく次のように、子にシグナルを送信する通常のEXITハンドラーを作成することをお勧めします。

 # !/bin/bash function cleanup() { local pids=`jobs -p` if [\\[ "$pids" != "" ]()]; then kill $pids \\>/dev/null 2\\>/dev/null fi } trap cleanup EXIT /path-to-your-app
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

残念ながら、これは問題を解決しません。 子プロセスにシグナルを送信するだけでは不十分です。 initは、子プロセスが完了するのを待ってから終了する必要もあります。 initが早く終了すると、すべての子プロセスが（純粋にではなく）カーネルによって強制終了されます。



明らかに、少し複雑なソリューションが必要ですが、Upstart、Systemd、およびSysVを備えた完全なinitシステムは、軽量のDockerコンテナには太すぎます。 幸いなことに、Baseimage-dockerにはソリューションが含まれています。 Dockerコンテナ内で使用するために、独自の軽量initシステムを作成しました。 より良いものを発明することなく、 my_initという名前を付けました 。 これは350行のPythonプログラムです。



my_initの主要な機能：

• 子プロセスの処理（刈り取り）
• サブプロセスを起動します
• 最大タイムアウトで、すべてのサブプロセスの完了を待ってから完了します
• Dockerログにアクティビティを記録します

Dockerはこの問題を自分で解決しますか？

理想的には、PID 1の問題はDocker自身でネイティブに解決する必要があります。 素晴らしいことですが、これまでのところ、2015年1月には、Dockerチームからこのようなことは聞いていません。 これは批判ではありません-Dockerは非常に野心的であり、彼らのチームにはより重要な問題があると確信しています。 PID 1の問題は、ユーザーレベルで簡単に解決できます。 したがって、Dockerがこの問題を公式に解決するまで、上記のようなシステムを使用して、人々が自分で解決することをお勧めします。

これはまったく問題ですか？

この問題は仮説のように思えるかもしれません。 コンテナ内でゾンビを見たことがない場合、すべてが正常であると考えるかもしれません。 ただし、問題がないことを確認する唯一の方法は、すべてのコード、すべてのライブラリ、およびライブラリで使用されているすべてのライブラリをチェックすることです。 これを行わなかった場合、おそらくどこかに子プロセスを開始する行があり、それがゾンビに変わります。



マーフィーの法則を忘れないでください。



ゾンビはカーネルリソーステーブルを詰まらせるという事実に加えて、プロセスをチェックするプログラムの正しい動作を妨害する可能性もあります。 たとえば、 Phusion Passengerはプロセスを管理します。 プロセスがクラッシュすると、プロセスを再起動します。 psの出力を解析し、プロセスにシグナル0を送信します。 ゾンビはpsで表示され、シグナル0に応答するため、Phusion Passengerはプロセスがまだ生きていると判断します。



ゾンビの問題から身を守るために必要なのは、Baseimage-dockerの接続または350行のmy_initのインポートに5分費やすことだけです。 ディスクとメモリの追加コストは最小限です。数メガバイトだけがメモリに追加されます。

おわりに

PID 1の問題は現実です。 これを解決する1つの方法は、 Baseimage-dockerを使用することです。 これが唯一の方法ですか？ もちろん違います。 Baseimage-dockerの目標は次のとおりです。

1. Dockerコンテナを使用する際のいくつかの重要なポイントについて人々に伝えるため。
2. ターンキーソリューションを提供して、人々が車輪を再発明しないようにします。

この場合、いくつかの解決策が可能です。主なことは、それらが説明されたタスクに対処することです。 C、Go、Rubyなどで独自のバージョンを作成できます。



基本的なUbuntuイメージを使用したくない場合があります。 たぶんあなたはCentOSを使用しています。 ただし、Baseimage-dockerは引き続き有用です。 たとえば、 ourpassenger_rpm_automationプロジェクトはCentOSコンテナーを使用します。 my_initを抽出してそこに挿入しました。



幸せな証拠！