You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

如何使用Docker Swarm Mode实现容器间数据共享?多主机部署咨询

Hey there! Since you're moving your single-host Compose setup over to a Docker Swarm cluster (1 manager, 2 workers) and need to handle container data sharing, let's walk through the most practical options tailored to your setup (7 replicas of process A, 1 each of B and C).

1. Docker Volumes (Swarm-Native, Best for Dynamic Data)

Volumes are the Docker-recommended way to share persistent data, and Swarm has built-in support for them. The key is choosing the right volume type based on whether you need cross-node access:

Cluster-Aware Volumes (For Cross-Node Sharing)

Since your 7 replicas of process A might spread across multiple worker nodes, you'll need a volume driver that works across the entire Swarm cluster. These drivers sync data across nodes, so any container (regardless of which node it's on) can access the same shared data.

Here's how to define one in your Compose file:

volumes:
  app-shared-data:
    driver: glusterfs  # Or use Ceph, AWS EBS, Azure Disk, etc.
    driver_opts:
      volname: swarm-shared-storage

services:
  process-a:
    image: your-process-a-image
    deploy:
      replicas: 7
    volumes:
      - app-shared-data:/app/data
  process-b:
    image: your-process-b-image
    volumes:
      - app-shared-data:/app/data
  process-c:
    image: your-process-c-image
    volumes:
      - app-shared-data:/app/data

Most cloud providers offer managed cluster-aware volume drivers out of the box, or you can use open-source tools like GlusterFS or Ceph if you're self-hosting.

Local Volumes (For Same-Node Sharing)

If you only need containers on the same node to share data (e.g., grouping some A replicas with B/C on one node), use a local volume. Just add deployment constraints to ensure dependent containers land on the same node:

volumes:
  local-shared-data:
    driver: local

services:
  process-a:
    image: your-process-a-image
    deploy:
      replicas: 7
      placement:
        constraints: [node.labels.data-node == true]
    volumes:
      - local-shared-data:/app/data
  process-b:
    image: your-process-b-image
    deploy:
      placement:
        constraints: [node.labels.data-node == true]
    volumes:
      - local-shared-data:/app/data

Don't forget to label your target node first with docker node update --label-add data-node=true <node-name>.

2. Swarm Configs (For Read-Only Configuration Files)

If you're sharing static, read-only data like app configs, certificates, or environment files, Swarm Configs are a better fit. Swarm automatically distributes configs to any node running a container that needs them, and they're mounted as read-only files inside containers.

First create a config from your local file:

docker config create app-settings ./config/app-settings.json

Then reference it in your Compose file:

services:
  process-a:
    image: your-process-a-image
    deploy:
      replicas: 7
    configs:
      - source: app-settings
        target: /app/config/settings.json
        mode: 0444  # Set read-only permissions
  process-b:
    image: your-process-b-image
    configs:
      - app-settings

3. Swarm Secrets (For Sensitive Data)

For sensitive data like API keys, database passwords, or private keys, use Swarm Secrets instead of volumes or configs. Secrets are encrypted at rest, not exposed in container metadata, and mounted as read-only files inside containers.

Create a secret from your local file:

docker secret create db-password ./secrets/db-pass.txt

Then use it in your Compose file:

services:
  process-a:
    image: your-process-a-image
    deploy:
      replicas: 7
    secrets:
      - db-password
secrets:
  db-password:
    external: true  # References the secret we created earlier

4. Bind Mounts with Shared Filesystems (e.g., NFS)

If you already have a shared filesystem like NFS set up, you can use bind mounts to connect containers to it. Just ensure every Swarm node has the shared filesystem mounted at the same path.

First mount the NFS share on each node:

mount -t nfs nfs-server:/exported-path /mnt/swarm-shared

(Add this to /etc/fstab on each node to mount it automatically on boot.)

Then define the bind mount in your Compose file:

services:
  process-a:
    image: your-process-a-image
    deploy:
      replicas: 7
    volumes:
      - /mnt/swarm-shared:/app/data

This works, but it requires more manual maintenance than cluster-aware volumes, so only use it if you already have a shared filesystem in place.

Quick Recommendation for Your Setup

  • For dynamic, writable data shared across all components (A, B, C), go with a cluster-aware volume driver. This ensures all 7 replicas of process A can access the same data no matter which node they're on.
  • For static configs, use Swarm Configs—they're secure, easy to manage, and don't require extra storage infrastructure.
  • For sensitive data like passwords, always use Swarm Secrets to keep them encrypted and hidden from container metadata.

内容的提问来源于stack exchange,提问作者Tanmay Bhattacharya

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.05.26 10:24:13