反馈请求 – 在文件更改时重新启动Docker容器
我有这个工作，但想知道是否有任何潜在的副作用，甚至更好的方式来做到这一点。 下面的例子是通用的。
我有一个docker-compose文件，包含两个容器（ container_1和container_2 ）。
container_1公开了一个卷，其中包含用于运行已安装服务的各种configuration文件。
container_2从container_2安装卷，并定期运行一个脚本，用于提取文件并更新container_1运行的服务的configuration。
每次configuration更新时，我都想重新启动container_1的服务，而不必使用cron或我已经讨论过的其他一些方法。
我的解决scheme
我在container_1上放了一个脚本，检查configuration文件是否已经更新（文件最初是空的，md5sum存储在一个单独的文件中），如果文件已经根据md5sum进行了更改，它会更新当前散列并杀死进程。
在撰写文件中，我有一个healthcheck ，定期运行脚本，并restart设置为always 。 当container_2的脚本运行并更新container_2的configuration文件monitor_configs.sh ， container_1上的脚本将monitor_configs.sh该服务的进程，容器将重新启动并重新加载configuration。
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的预期用途，但它似乎是最简单的方法来获得所需的效果，同时仍然保持每个容器中只有一个运行过程。
我尝试了在container_1使用和不使用tini ，并且在两种情况下都像预期的那样工作。
我计划将健康检查的interval延长到24小时，因为container_2的脚本每天只运行一次。
用例
我正在container_1运行Suricata，并且在container_1拔出猪肉以更新Suricata的规则。 我想每天运行一次pullpork，如果规则已更新，请重新启动Suricata以加载新规则。
您可能想要了解像confd这样的工具如何工作，这些工具将作为container_1入口点运行。 它在前台运行，轮询外部configuration源，并在更改后重写容器内的configuration文件并重新启动生成的应用程序。
要使自己的工具像confd，你需要包括你的重启触发器，也许你的健康监测脚本，然后使stdin / stdout / stderr通过任何信号，以便您的重启工具变得透明的容器内。