<p>A container is nothing more than a process that has been partitioned from the host system and other processes using some linux process isolation technology.</p>
<p>Docker - even swarm's - role in this is to setup the parameters for this isolation and then hand the execution over to the OS to handle - this is partially what makes containers so lightweight - docker literally adds nothing to the execution of a containerised app.</p>
<p>This does mean, out the box, swarm is very good at orchestrating stateless containers. And anything that's stateful needs to have native support for being run in some kind of clustered/multi node configuration because docker swarm is not implementing anything magical. If you want to run a clustered Postgres db for example, you figure out how to run 3 Postgres instances without docker, and then write a swarm stack that spins up 3 replicas configured that way, solving problems like how each instance is going to persist its data: Swarm assumes tasks are stateless and will assume it can re-start any Postgres instance on any node, so its up to you to use cluster aware volumes, or use constrains to pin specific instances to specific nodes so they always use the same mounted data volumes etc.</p>

CC BY-SA 4.0
2023-08-23T08:58:05.020Z
2023-08-23T08:58:05.020Z
Chris Becke
<p>I've been reasearching docker swarms and found out that a swarm is a collection of nodes, nodes are computers that run services, services are schedulers of tasks, and tasks are running containers. Services are made out of a single container image and can be made out of multiple redundant tasks.</p>
<p>My question is: if tasks are instances of container images, how is memory and storage shared between them, assuming your service is running a stateful application like a database (storage) or a website backend (memory)?</p>
<ul>
<li>Are the resource requirements multiplied and sinchronized regularly or in real-time? By that logic shouldn't there be a &quot;master task&quot;?</li>
<li>If not, then stateful applications should have at maximum 1 task replica per service, and each redundancy unit should be a new actively mantained service (like databases, for instance)?</li>
</ul>
<p>The core of my question is that I assume that services are general-purpose, so most types of applications could benefit from this task replication thing. Otherwise, isn't this core feature only suitable for stateless applications like rest apis? I imagine core features of general-purpose tools to also be general-purpose.</p>

<docker><docker-swarm>
How is memory and storage shared between tasks running stateful applications?
marcosdly
# How is memory and storage shared between tasks running stateful applications?

(Asked by: username_0 on 2023-06-02)

I've been reasearching docker swarms and found out that a swarm is a collection of nodes, nodes are computers that run services, services are schedulers of tasks, and tasks are running containers. Services are made out of a single container image and can be made out of multiple redundant tasks.

My question is: if tasks are instances of container images, how is memory and storage shared between them, assuming your service is running a stateful application like a database (storage) or a website backend (memory)?

* Are the resource requirements multiplied and sinchronized regularly or in real-time? By that logic shouldn't there be a "master task"?
* If not, then stateful applications should have at maximum 1 task replica per service, and each redundancy unit should be a new actively mantained service (like databases, for instance)?

The core of my question is that I assume that services are general-purpose, so most types of applications could benefit from this task replication thing. Otherwise, isn't this core feature only suitable for stateless applications like rest apis? I imagine core features of general-purpose tools to also be general-purpose.

**Tags:** docker, docker-swarm


---

## 1 answers

### Answer by username_1 on 2023-08-23. Score: 1

A container is nothing more than a process that has been partitioned from the host system and other processes using some linux process isolation technology.

Docker - even swarm's - role in this is to setup the parameters for this isolation and then hand the execution over to the OS to handle - this is partially what makes containers so lightweight - docker literally adds nothing to the execution of a containerised app.

This does mean, out the box, swarm is very good at orchestrating stateless containers. And anything that's stateful needs to have native support for being run in some kind of clustered/multi node configuration because docker swarm is not implementing anything magical. If you want to run a clustered Postgres db for example, you figure out how to run 3 Postgres instances without docker, and then write a swarm stack that spins up 3 replicas configured that way, solving problems like how each instance is going to persist its data: Swarm assumes tasks are stateless and will assume it can re-start any Postgres instance on any node, so its up to you to use cluster aware volumes, or use constrains to pin specific instances to specific nodes so they always use the same mounted data volumes etc.


---

