Why tutorials say that in terms of docker swarm task = running container?

[berpcor]

Hello, Bret, I am watching you lessons about docker + docker swarm and can't understand one thing.

How I understand the part I understand. )

Docker service command replaces docker run command. Docker run is about single container. Docker service is about running multiple containers as one managable unit. And service is a part if the unit.

In fact, in terms of docker swarm, service is a container, but from another (group) point of view (in current point of reasoning). But why service, why not just container?

Because docker run just simply runs a container. Docker service runs container as service. What the service means here?

Service here is some fault-tolerant entity, that provide some service (in a wide sense - you ask something, it does something). But what are criterias of fault-tolerance? What may happen to container?

It may be stopped for some reasons - you need to restart it, container can be out of resources - you need to edit resources limits, one container may not be enough to handle the current load, so you need more instances to balance the load (*so since now I understand why service is not just one container, so it can't be named just container, we need another word here. One more thing I can state here - in terms of service we can have only one image, it is always about only one, the same image, but we can have multiple containers based on that image *).

You can control all that, manually or automatically - another question, but you are able to do that in a system way now. So here we have not just a launched container, we have a goal - keep the service (in a wide sense) always running. To reach the goal some tasks should be completed. As you see, I already started talking using docker thesaurus (but came to that point from point of view of logic).

What tasks we are talking about when we are talking about the described goal?
Let's say, load has increased. We need, let's say, two more replicas of a container. Let's decompose that subgoal.

Subgoals (or tasks):

1. Create container №1.
2. Create container №2.
3. Create container №3.

Amazing, here we have three tasks we need (orchestrator needs actually) to perform.
Here task closely connected to container. That is what I often see in many-many tutorials. Task = running container instance.

But let's move forward in reasoning. Now we need to edit avaliable resources for container. So our goal is to change some resources limits. Our task here is to change resources. And since that moment we have that task != running container instance, this is not connected to container creation, we just change settings for some current running container.

What I can't understand.

Why different tutorials say that always task = running container? In described case, we are not restart container by hand, we just edit available resources, so the primary task for us not to run container (like when we create new replicas), but change available resources for it.

I want to understand logic of creators behind names (terminology).

[BretFisher]

Hey there, I see lots of questions, but I'm not sure what the primary question is.

docker run creates a single container, and its settings can't be changed once created. It's an imperative command. The millisecond you hit on a run command, the container is created and started.

service create is not imperative, it is declarative, much like Kubernetes kubectl create deployment. Swarm services default to a single replica (the terms replica and task are interchangeable in Swarm nomenclature). Each replica/task will start a container using the definition defined in the service. If you change the service (let's say you change resource limits), then the service will create new replica containers from that updated service definition, and then stop the old containers (using a rolling update style deployment).

I hope that helps. Let me know if you have more questions.