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_1中的配置文件时，monitor_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，但在两种情况下似乎都按预期工作。

我计划将interval的{{1}}延长至24小时，因为healthcheck中的脚本每天只运行一次。

用例

我在container_2中运行了Suricata并在container_1中拉了一下以更新Suricata的规则。我想每天运行一次pullpork，如果规则已更新，请重新启动Suricata以加载新规则。

Answer 1

您可能希望了解confd之类的工具如何工作，这些工具将作为您的container_1入口点运行。它在前台运行，轮询外部配置源，并在更改时重写容器内的配置文件并重新启动生成的应用程序。

要使您自己的工具像confd一样，您需要包含重启触发器，可能是健康监控脚本，然后使stdin / stdout / stderr与任何信号一起通过，以便重启工具变得透明在容器内。

反馈请求 - 在文件更改时重新启动Docker容器

1 个答案: