フィードバックリクエスト - ファイル交換時のDockerコンテナの再起動

Question

私はこれを動作させていますが、潜在的な副作用があるかどうか、さらにこれを行うためのより良い方法があるかどうか疑問に思っていました。以下の例は一般的なものです。

私は2つのコンテナ（container_1とcontainer_2）を持つドッカー作成ファイルを持っています。

container_1は、インストールされたサービスを実行するために使用するさまざまな設定ファイルを含むボリュームを公開します。

container_2は、ボリュームをcontainer_1からマウントし、定期的にファイルを取得して、container_1で実行されているサービスの設定を更新するスクリプトを実行します。

configsが更新されるたびに、やその他のいくつかの方法を使用せずにcontainer_1でサービスを再開したいと考えています。

私のソリューション：私は、configファイルが更新されているかどうかをチェックcontainer_1でスクリプトを置く

が（ファイルが最初は空であり、そのmd5sumを別のファイルに保存されている）と、ファイルが変更された場合md5sumに基づいて、現在のハッシュを更新し、プロセスを強制終了します。

作成ファイルには、healthcheckというスクリプトが定期的に実行され、restartはalwaysに設定されています。 container_2のスクリプトが実行され、container_1の設定ファイルがmonitor_configs.shに更新されると、container_1のスクリプトはサービスのプロセスを強制終了し、コンテナが再起動され、configsがリロードされます。

monitor_config.sh

# current_hash contains md5sum of empty file initially 
#!/bin/sh 

echo "Checking if config has updated" 
config_hash=$(md5sum /path/to/config_file) 
current_hash=$(cat /path/to/current_file_hash) 

if [ "$rules_hash" != "$current_hash" ] 
then 
    echo "config has been updated, restarting service" 
    md5sum /path/to/config_file > /path/to/current_file_hash 
    kill $(pgrep service) 
else 
    echo "config unchanged" 
fi 

ドッキングウィンドウ-compose.yml

version: '3.2' 
services: 
    service_1: 
    build: 
     context: /path/to/Dockerfile1 
    healthcheck: 
     test: ["CMD-SHELL", "/usr/bin/monitor_config.sh"] 
     interval: 1m30s 
     timeout: 10s 
     retries: 1 
    restart: always 
    volumes: 
     - type: volume 
     source: conf_volume 
     target: /etc/dir_from_1 

    service_2: 
    build: 
     context: /path/to/Dockerfile2 
    depends_on: 
     - service_1 
    volumes: 
     - type: volume 
     source: conf_volume 
     target: /etc/dir_from_1 

volumes: 
    conf_volume: 

私は、これはhealthcheckの使用目的ではありません知っているが、それは取得するためのクリーンな方法のように思えました各コンテナ内に1つの実行中のプロセスのみを維持しながら、所望の効果を得ることができる。

tiniをcontainer_1に入れて試してみましたが、どちらの場合も期待どおりに動作しているようです。

healthcheckのintervalを24時間に延長する予定です。container_2のスクリプトは1日に1回しか実行されません。

ユースケース

私ははSuricataのルールを更新するために、container_2にcontainer_1とプルドポークではSuricataを実行しています。 1日に1回プルダウンを実行し、ルールが更新されている場合は、新しいルールをロードするためにSuricataを再起動します。

Answer 1

confdのようなツールがコンテナ1のエントリポイントとしてどのように動作するかを見てみてください。これはフォアグラウンドで実行され、外部の設定ソースをポーリングし、変更が行われるとコンテナ内の設定ファイルを書き換えて、生成されたアプリケーションを再起動します。

confdのような独自のツールを作成するには、再起動トリガー、おそらくあなたのヘルスモニタリングスクリプトを含めてから、stdin/stdout/stderrをシグナルとともに通過させて再起動ツールが内部で透明になるようにする必要がありますコンテナ