反饋請求 - 重新啓動文件更改的Docker容器

Question

我有這個工作，但想知道是否有任何潛在的副作用，甚至更好的方式來做到這一點。下面的例子是通用的。

我有一個有兩個容器（container_1和container_2）的docker-compose文件。

container_1公開包含用於運行已安裝服務的各種配置文件的卷。

container_2從container_1掛載卷，並定期運行一個腳本，該腳本會拉取文件並更新在container_1中運行的服務的配置。

每次更新配置時，我都想重新啓動container_1中的服務，而不必使用cron或我已經討論過的一些其他方法。

我的解決辦法：

我把劇本上container_1來檢查，如果配置文件已經更新（該文件最初是空的，並且的md5sum被儲存在一個單獨的文件），如果該文件已經改變基於md5sum它會更新當前散列並殺死進程。

在撰寫文件中，我有一個healthcheck定期運行腳本，restart設置爲always。當container_2中的腳本運行並更新container_1monitor_configs.sh中的配置文件時，container_1上的腳本將終止服務進程，容器將重新啓動並重新加載配置。

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但它似乎得到最徹底的方法期望的效果，同時仍然在每個容器中僅保持一個運行過程。

我嘗試過，沒有tini在container_1，它似乎在兩種情況下都按預期工作。

我計劃將healthcheck的interval延長至24小時，因爲container_2中的腳本每天只運行一次。

使用情況

我跑Suricata在container_1和手撕豬肉在container_2以更新Suricata規則。我想每天運行一次pullpork，如果規則已更新，請重新啓動Suricata以加載新規則。

Answer 1

您可能想要了解像confd這樣的工具如何工作，這些工具將作爲container_1入口點運行。它在前臺運行，輪詢外部配置源，並在更改時重寫容器內的配置文件並重新啓動生成的應用程序。

爲了讓自己的工具像confd一樣，你需要包含重啓動觸發器，也許你的運行狀況監控腳本，然後使stdin/stdout/stderr和任何信號一起通過，這樣你的重啓工具變得透明集裝箱。