Great question—you absolutely don’t need to bolt on a web service just to execute shell scripts in a network-isolated container with Docker Compose. Web services add unnecessary complexity, overhead, and attack surface when your only goal is running scripts. Here are the most practical, efficient approaches:

1. Direct Execution with docker-compose exec #

This is the simplest and most straightforward method, especially for manual operations or CI/CD pipelines. Docker’s daemon has direct access to all containers, regardless of their network configuration, so you can run commands directly against the network-isolated container:

docker-compose exec <your-service-name> /path/to/your/script.sh

Use Cases: #

• Ad-hoc script runs (e.g., debugging, one-off maintenance tasks)
• Automated workflows where an external process (like a CI runner) needs to trigger the script

2. Shared Volume + Trigger Mechanism #

If you need another container in your Compose stack to trigger the script (instead of an external process), use a shared volume to pass a "trigger" signal. This works entirely without network communication.

Step-by-Step Setup: #

1. Define a shared volume in your docker-compose.yml:

   version: '3.8'
   services:
     isolated-service:
       image: your-networkless-image
       network_mode: none
       volumes:
         - script-trigger:/shared
       command: /path/to/monitor-trigger.sh
   
     trigger-service:
       image: some-base-image
       volumes:
         - script-trigger:/shared
   
   volumes:
     script-trigger:
   

2. Create a monitoring script (monitor-trigger.sh) for the isolated container to watch for triggers:

   #!/bin/bash
   # Keep running and check for a trigger file
   while true; do
     if [ -f /shared/run-script.trigger ]; then
       echo "Trigger detected—running script..."
       /path/to/your-target-script.sh
       # Remove the trigger to avoid re-running
       rm /shared/run-script.trigger
     fi
     sleep 2 # Adjust polling interval as needed
   done
   

3. From the trigger container, create the trigger file to start the script:

   touch /shared/run-script.trigger
   

Use Cases: #

• Cross-container workflow automation where one service needs to signal the isolated service to run a task
• No external access to the Docker daemon (e.g., restricted environments)

3. Docker API Access (Carefully!) #

If your trigger container needs more control (e.g., dynamic script execution), you can mount the Docker socket to let it interact with the Docker daemon directly. Note: This grants the container full access to your host’s Docker environment, so only use this in trusted setups.

Setup in docker-compose.yml: #

trigger-service:
  image: docker:cli
  volumes:
    - /var/run/docker.sock:/var/run/docker.sock
  command: docker exec <isolated-container-id> /path/to/script.sh

Use Cases: #

• Advanced automation where you need to dynamically run different commands/scripts
• Environments where you already trust the trigger container with elevated privileges

Key Takeaway: Skip the Web Service #

Adding a web service to your network-isolated container is overkill here. All the methods above work without exposing any network ports, keeping your container secure and your setup simple. Only consider a web service if you already need it for other functionality (e.g., exposing an API for unrelated tasks).

内容的提问来源于stack exchange，提问作者John13