反馈请求 - 重新启动文件更改的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和任何信号一起通过，这样你的重启工具变得透明集装箱。