Docker と Supervisord のチュートリアル

数日前、LXC に基づくオペレーティング システム レベルの仮想化テクノロジである Docker に関する詳細なガイドを公開しました。Docker は、コンテナ化されたアプリケーションをプロビジョニングするための高速で軽量かつ安全な方法を提供します。素晴らしい。

さて、最初のサービスである SSH と Apache をテストしたときに直面した問題の 1 つは、これらのサービスの制御でした。コンテナー内で使用できる init スクリプトや systemd はありませんでした。率直に言って、それらは必要ないかもしれません。しかし、サービスを開始、停止するための何らかのメカニズムが必要です。 Supervisord を紹介するため、このチュートリアルです。こちらへどうぞ。

一言で言えば監督者

Supervisord は、プロセスを監視および制御するように設計されたプロセス制御システムです。 init を置き換えることを目的としているのではなく、独自のフレームワーク内にプロセスをカプセル化し、必要に応じてブート時にプロセスを開始できます。この時点で、ソフトウェアについてこれ以上深く掘り下げる理由はありません。

監督者によるセットアップ

基本的に、supervisord は Python モジュールです。これは、setuptools の一部である easy_install を使用してインストールできます。これは、それ自体が Python distutils パッケージの拡張です。はい、この時点でかなり複雑になります。幸いなことに、ほとんどの Linux ディストリビューションには、今日のテスト プラットフォームである CentOS を含む easy_install が付属しています。

開始するには、コンテナー内に Supervisord をインストールする必要があります。次に、イメージをコミットし、ビルドのベースラインとして使用します。これには、前述の SSH や Apache などのサービスが含まれます。ホストに Supervisord をインストールしようとすると、問題なく成功するはずです:

easy_install スーパーバイザー
スーパーバイザーを探しています
https://pypi.python.org/simple/supervisor/ を読む
ベスト マッチ:スーパーバイザ 3.1.3
ダウンロード https://pypi.python.org/packages/source/s/supervisor/
スーパーバイザー-3.1.3.tar.gz#md5=aad263c4fbc070de63dd354864d5e552
処理中の Supervisor-3.1.3.tar.gz
/tmp/easy_install-vbOcMG/supervisor-3.1.3/setup.cfg の書き込み
Supervisor-3.1.3/setup.py -q bdist_egg --dist-dir /tmp/easy_install-vbOcMG/supervisor-3.1.3/egg-dist-tmp-i96mIs の実行
警告:ディレクトリ 'docs/.build' の下に '*' に一致する以前に含まれていたファイルが見つかりませんでした
スーパーバイザー 3.1.3 を easy-install.pth ファイルに追加する
/usr/bin への echo_supervisord_conf スクリプトのインストール
/usr/bin への pidproxy スクリプトのインストール
/usr/bin への Supervisorctl スクリプトのインストール
/usr/bin への Supervisord スクリプトのインストール

インストール済み

/usr/lib/python2.7/site-packages/supervisor-3.1.3-py2.7.egg
スーパーバイザーの依存関係の処理
meld3>=0.6.5 の検索
https://pypi.python.org/simple/meld3/ を読む
ベストマッチ：meld3 1.0.2
ダウンロード https://pypi.python.org/packages/source/m/meld3/
meld3-1.0.2.tar.gz#md5=3ccc78cd79cffd63a751ad7684c02c91
meld3-1.0.2.tar.gz の処理中
/tmp/easy_install-wnhLVS/meld3-1.0.2/setup.cfg の書き込み
meld3-1.0.2/setup.py -q bdist_egg --dist-dir /tmp/easy_install-wnhLVS/meld3-1.0.2/egg-dist-tmp-Lp88cX の実行
zip_safe フラグが設定されていません。アーカイブの内容を分析しています...
meld3 1.0.2 を easy-install.pth ファイルに追加する

インストール済み /usr/lib/python2.7/site-packages/meld3-1.0.2-py2.7.egg
スーパーバイザーの依存関係の処理が完了しました

コンテナー内では、コンテナーに追加された Python フレームワークが完全ではなく、一部のモジュールが欠落しているため、エラーが発生します。

# easy_install スーパーバイザー
トレースバック (最新の呼び出しが最後):
ファイル「/usr/bin/easy_install」、5 行目、
from pkg_resources import load_entry_point
ImportError:pkg_resources という名前のモジュールがありません

これは、手動で easy_install をセットアップする必要があることを意味します:

wget https://bitbucket.org/pypa/setuptools/raw/ ->
-> ブートストラップ/ez_setup.py -O - |パイソン

スーパーバイザ構成

次のステップは、コンテナーの構成を作成することです。ホストでファイルを作成し、Dockerfile で COPY 命令を使用して、ビルド プロセス中にイメージにコピーします。

コピー ./supervisord.conf /etc/supervisord.conf

構成自体は次のようになります:

【監修者】
のだえもん=真

[プログラム:sshd]
command=/usr/sbin/sshd -D

[プログラム:httpd]
command=/bin/bash -c "exec /usr/sbin/httpd -DFOREGROUND"

ここには何がありますか？各角括弧のペアは、セクションを定義します。 Supervisord 自体については、それ自体をデーモン化するのではなく、フォアグラウンドで開始する必要があると定義しています。これは、バックグラウンド サービスになることを意味します。

sshd という名前のプログラムに対して、関連するコマンドを実行し、基本的にバックグラウンドで SSHD を実行します。 httpd という名前のプログラムの場合、別のシェルでフォアグラウンドでサーバーを起動します。利用可能なオプションは他にもたくさんありますが、現時点では、supervisord を使用するために最低限必要なものはこれだけです。

コンテナの実行とトラブルシューティング

イメージをビルドして実行すると、supervisord が開始され、プロセスが開始されます。しかし、まず、いくつかの一般的なエラーに取り組みましょう。あなたが見るかもしれないものは次のとおりです:

docker run -ti -p 22 -p 80 image-3:latest
/usr/lib/python2.7/site-packages/supervisor-3.1.3-py2.7.egg/
Supervisor/options.py:296:UserWarning:Supervisord はルートとして実行されており、デフォルトの場所 (現在の作業ディレクトリを含む) で構成ファイルを検索しています。セキュリティを強化するために、構成ファイルへの絶対パスを指定する「-c」引数を指定することをお勧めします。
「Supervisord は root として実行されており、検索中です」
エラー:デフォルトのパス (/usr/etc/supervisord.conf、/usr/supervisord.conf、supervisord.conf、etc/supervisord.conf、/etc/supervisord.conf) に構成ファイルが見つかりません。 -c オプションを使用して、別のパスにある構成ファイルを指定します
ヘルプが必要な場合は、/usr/bin/supervisord -h を使用してください

Supervisord.conf ファイルに間違ったパスを指定した場合、または間違った名前を使用した場合、サービスは実行できません。 COPY 命令を編集し、イメージを再構築して最初からやり直す必要があります。次に発生する可能性のあるエラーは次のとおりです:

# docker run -ti -p 22 -p 80 image-3:latest
/usr/lib/python2.7/site-packages/supervisor-3.1.3-py2.7.egg/
Supervisor/options.py:296:UserWarning:Supervisord はルートとして実行されており、デフォルトの場所 (現在の作業ディレクトリを含む) で構成ファイルを検索しています。セキュリティを強化するために、構成ファイルへの絶対パスを指定する「-c」引数を指定することをお勧めします。
「Supervisord は root として実行されており、検索中です」
372 CRIT スーパーバイザーが root として実行されている (構成ファイルにユーザーがいない)
375 INFO Supervisord が pid 1 で開始されました
378 INFO が生成されました:'httpd' with pid 9
381 INFO が生成されました:'sshd' with pid 10
602 INFO exited:httpd (終了ステータス 1; 予期しない)
606 INFO が生成されました:'httpd' with pid 11
606 INFO 成功:sshd が RUNNING 状態になり、プロセスが 1 秒以上 (startsecs)
671 INFO exited:httpd (終了ステータス 1; 予期しない)
676 INFO が生成されました:pid 12 の 'httpd'
742 INFO exited:httpd (終了ステータス 1; 予期しない)
749 INFO が生成されました:pid 13 の 'httpd'
825 INFO exited:httpd (終了ステータス 1; 予期しない)
826 INFO あきらめました:httpd が FATAL 状態になりました。

あきらめました:httpd が FATAL 状態になりました。開始の再試行が多すぎて、あまりにも早く

ここにあるのは、Apache スレッドが終了し、supervisord が再起動を強制的に再試行し、最終的にあきらめて、致命的な状態につながることです。この時点では、コンテナーはほとんど役に立ちません。

ここでの解決策は、supervisord.conf ファイルを編集し、追加のディレクティブを httpd プログラム セクションに導入することです。これにより、生成プロセスがより適切に処理されます。

[プログラム:httpd]
開始秒 =0
自動再起動 =false
command=/bin/bash -c "exec /usr/sbin/httpd -DFOREGROUND"

startsecs =0 と autorestart =false を追加しました。最初のディレクティブは次のことを示しています:

起動が成功したと見なすために、起動後にプログラムが実行し続ける必要がある合計秒数。予期される終了コード (exitcodes を参照) でプログラムが終了したとしても、プログラムが開始されてからこの秒数が経過しない場合、開始は失敗と見なされます。

2 つ目は、Supervisord が Apache スレッドの再起動を処理しないことを意味します。これらは、着信 HTTP 要求を処理する Web サーバー自体によって処理されます。

false、unexpected、または true のいずれかです。 false の場合、プロセスは自動再起動されません。予期しない場合、このプロセス構成に関連付けられた終了コードのいずれでもない終了コードでプログラムが終了すると、プロセスが再起動されます (終了コードを参照)。 true の場合、プロセスは、終了コードに関係なく、終了時に無条件に再起動されます。

これで、コンテナを再度実行できます。元のガイドで遭遇した /run/httpd の問題を覚えていますか? /run ディレクトリが配置されていない場合、次のメッセージが表示されます:

docker run -ti -p 22 -p 80 image-3:latest
/usr/lib/python2.7/site-packages/supervisor-3.1.3-py2.7.egg/
Supervisor/options.py:296:UserWarning:Supervisord はルートとして実行されており、デフォルトの場所 (現在の作業ディレクトリを含む) で構成ファイルを検索しています。セキュリティを強化するために、構成ファイルへの絶対パスを指定する「-c」引数を指定することをお勧めします。
「Supervisord は root として実行されており、検索中です」
ルートとして実行されている 913 CRIT スーパーバイザー (構成ファイルにユーザーなし)
916 INFO Supervisord が pid 1 で開始されました
919 INFO が生成されました:pid 8 の 'httpd'
921 INFO が生成されました:'sshd' with pid 9
079 INFO success:httpd が RUNNING 状態になり、プロセスが 0 秒以上 (startsecs)
105 INFO exited:httpd (終了ステータス 0; 予想される)
120 INFO リープされた不明な pid 10
122 INFO 成功:sshd が RUNNING 状態になり、プロセスが 1 秒以上 (startsecs) の間稼働したままになりました

この時点で、コンテナーに接続 (BASH シェルをアタッチまたは実行) し、ログを確認して、サービスが期待どおりに実行されない理由を理解しようとする必要があります。

テスト成功

そして、最終的にすべてを整理したら:

結論

これはかなりオタクなチュートリアルです。しかし、systemd のような複雑で高価なフレームワークをインストールしなくても、コンテナー内のサービスを堅牢かつエレガントな方法で制御するために使用できる、別の便利なツールが私たちの武器庫に導入されます。また、Docker、作業方法、問題のトラブルシューティング方法などについても説明します。

Supervisord なしで sshd および httpd プロセスを実行できたため、Supervisord は厳密には必要ではありませんが、サービスを頻繁に開始および再起動する必要がある場合は特に、この方法を好む人もいます。いずれにせよ、このユーティリティに精通していると、Docker メカニズムに対する理解と自信を構築するのに役立ちます。このガイドがお役に立てば幸いです。次に何を調査する必要があるかについて、リクエストを送信してください。

乾杯。