Docker Swarm rolling update on Raspberry Pi leaves in‑memory cache stale after task replacement

Answer

Use a shared storage location (a Docker volume or a tmpfs mount) together with a lightweight side‑car container that flushes the cache before the main task stops, and let the healthcheck wait for a readiness signal that the new task has loaded the cache.

Likely explanation

Docker Swarm’s rolling update stops the old task only after the replacement passes its healthcheck; there is no built‑in pre‑stop hook, so any purely in‑memory state is lost unless the application moves it elsewhere before termination.

Confirmed facts from the research brief

• Update parameters (update-delay, update-parallelism, failure-action) control timing but do not invoke user scripts.
• The only extension points are healthchecks and the ability to run a side‑car that shares a volume or uses IPC.
• A side‑car receives SIGTERM before the main container, allowing it to run a cleanup step and effectively act as a custom pre‑stop.

Steps for this case (Raspberry Pi Swarm)

1. Create a named volume or mount a tmpfs (e.g., docker volume create cache-shared or --mount type=tmpfs,destination=/cache) and attach it to both the main and side‑car containers.
2. In the main container, on startup, attempt to read a cache snapshot from the shared location (e.g., /cache/snapshot.dat). If present, load it into memory; otherwise start with an empty cache.
3. Before shutting down, the main container writes the current in‑memory cache to the shared location (e.g., a serialized file) and then signals readiness—this can be a simple file touch (/cache/ready) or a UDP/Unix‑socket message to the side‑car.
4. Deploy a side‑car container in the same service spec that:
• Mounts the same shared volume.
• Runs a script that blocks on SIGTERM (or watches for the readiness file).
• When it receives the signal, it triggers the main container’s cache‑dump (if not already done), waits for the snapshot to appear, then exits.
5. Define the service healthcheck to return 0 only when the readiness file (/cache/ready) exists, indicating the new task has loaded the cache. Example:

healthcheck:
  test: ["CMD", "test", "-f", "/cache/ready"]
  interval: 5s
  timeout: 2s
  retries: 3

Missing diagnostic detail

If the cache is large (> 10 MiB) or the Pi’s SD‑card I/O is slow, a tmpfs mount may be preferable to avoid wear and latency. Please confirm the approximate size of the in‑memory cache you need to preserve so we can advise whether a tmpfs or a persistent volume is appropriate.