피드백 요청 - 파일 변경시 Docker 컨테이너 다시 시작

Question

나는이 작업을 수행하고 있지만 잠재적 인 부작용이 있는지 또는 더 좋은 방법이 있는지 궁금해하고 있습니다. 아래 예는 일반적인 것입니다.

두 개의 컨테이너 (container_1 및 container_2)가있는 도킹 스테이션 작성 파일이 있습니다.

container_1은 설치된 서비스를 실행하는 데 사용되는 다양한 구성 파일이 들어있는 볼륨을 노출합니다.

container_2은 볼륨을 container_1에서 마운트하고 파일을 가져오고 container_1에서 실행되는 서비스 구성을 업데이트하는 스크립트를 주기적으로 실행합니다.

configs가 업데이트 될 때마다 또는 내가 본 것으로 설명한 일부 방법을 사용하지 않고 container_1에서 서비스를 다시 시작하려고합니다.

내 솔루션 : 나는 설정 파일이 업데이트되었는지 확인 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의 용도 아니라는 것을 알고 있지만를 얻을 수있는 가장 깨끗한 방법처럼 보였다 각 컨테이너에서 하나의 실행중인 프로세스 만 유지하면서 원하는 효과를 얻을 수 있습니다.

나는 tini을 container_1에 넣고 시도했지만 두 경우 모두 예상대로 작동하는 것 같습니다.

container_2의 스크립트는 하루에 한 번만 실행되므로 healthcheck의 interval을 24 시간 연장 할 계획입니다.

사용 사례

내가 Suricata에 대한 규칙을 업데이트 container_2에 container_1 및 풀드 포크에 Suricata를 실행하고 있습니다. 하루에 한 번 뽑아서 껍질을 벗기고 규칙을 업데이트 한 경우 Suricata를 다시 시작하여 새 규칙을로드합니다.

Answer 1

confd과 같은 도구가 컨테이너 _ 진입 점으로 실행되는 방법을 살펴볼 수 있습니다.포 그라운드에서 실행되고 외부 구성 소스를 폴링하고 변경시 컨테이너 내부의 구성 파일을 다시 작성하고 생성 된 응용 프로그램을 다시 시작합니다.

confd와 같은 도구를 만들려면 다시 시작 트리거 (어쩌면 상태 모니터링 스크립트)를 포함시킨 다음 stdin/stdout/stderr을 신호와 함께 통과시켜 다시 시작 도구가 내부에서 투명 해지도록해야합니다 컨테이너.