DISTRIBUTED SYSTEM

USING DOCKER
SWARM
PEMPROGRAMAN TERDISTRIBUSI DAN PARALLEL
PERTEMUAN 14

DOSEN : SENIMAN, S.KOM., M.KOM

INTRODUCTION

• With applications needing more and more computing resources and uptime of nearly
100% it becomes very hard to maintain and scale your software without some kind of
management system.
• This is where Docker swarm comes into play. Docker Swarm provides an easy way to
scale and maintain your containers and services.
WHAT IS DOCKER SWARM

• Docker Swarm is a cluster management and orchestration tool that makes it easy to scale
and manage your already existing docker services. A swarm consists of multiple Docker
hosts that run in the so-called swarm mode and act eighter as managers (managing member
relationships) or as workers (run the services). A given Docker host can be a manager,
worker or can perform both roles.
• When creating a service in a swarm you define the optimal state of your service (number of
replicas, ports of the service, network and storage resources, and more). Docker will try to
maintain this desired state by restarting/rescheduling unavailable tasks and balancing the
load between different nodes.
• Load balancing
• Swarm has a built-in load balancer that lets you specify how to distribute service and
container between your different nodes. You can also expose ports for external load
balancing services.

• Integrated into the Docker Engine:

• Swarm is directly integrated into the Docker CLI and doesn't require any additional
orchestration software or other tools to create or manage a swarm.
• Scaling
• Swarm lets you define the number of tasks you want to run for each service. This number
can be changed using a single command which is handled by the swarm manager.
• Rolling updates
• Swarm lets you apply service updates incrementally which means that it updates a
specific amount of replicas at a time and your service will always be up even while
updating.
NODES

• A node is an instance of the Docker engine participating in the swarm. You can run one or
multiple nodes on a single device, but production deployments typically include Docker
nodes distributed across multiple physical devices.
MANAGERS NODES

• Manager nodes distribute and schedule incoming tasks onto the Worker nodes, maintain
the cluster state and perform orchestration and cluster management functions. Manager
Nodes can also optionally run services for Worker nodes.
• Cluster management tasks include:
 Maintaining the cluster state
 Scheduling services
 Serving swarm mode to HTTP API endpoints
• There should always be multiple manager nodes in your swarm because of the following
reasons:
 Maintaining high availability
 Easily recover from a manager node failure without downtime
• That is why Docker recommends you implement an odd number of nodes according to
your projects availability requirements.
• Note: Docker recommends a maximum of seven manager nodes for a swarm.
WORKER NODES

• Worker nodes are also instances of the Docker Engine whose sole purpose is to execute
containers and services as instructed by the Manager Nodes.
• To deploy your application to a swarm, you need at least one manager node. By default,
all manager nodes are also workers. To prevent the scheduler from placing tasks on your
manager node in a multi-node swarm, you need to set the availability to Drain.
SERVICES

• A service is the definition of the tasks to execute on the nodes. It is the primary root of user
interaction with the swarm.
• When you create a service, you specify which container image to use and which commands to
execute inside running containers. You also define other options for the service including:
 the port you want to expose
 CPU and memory limitations
 the number of replicas of the image to run in the swarm
 a rolling update policy
EXAMPLE OF AN HTTP SERVER BALANCING ITS
LOAD ON THREE REPLICAS
• As you can see the service has three
different tasks and each task invokes
exactly one container.  A task represents
a slot where the scheduler can place a
container. Once the container is live,
the scheduler recognizes that the task is
in a running state.
TASK SCHEDULING

• A task carries a Docker container and the command that is executed inside of the
container. It is the atomic scheduling unit of the swarm. Tasks are assigned by the
manager node to worker nodes according to the number of replicas set in the service.
• When a service is created or updated, the orchestrator realizes the desired state by
scheduling tasks. Each task is a slot that the scheduler fills by spawning a container which
is the instantiation of a task. Now when one of these containers fails its health check or
crashes, the orchestrator creates a new replica task that spawns a new container to replace
the failing one.
• The diagram in the right side shows
you how swarm mode accepts services
and schedules tasks for the worker
nodes.
REPLICATED AND GLOBAL SERVICES

• There are two different ways you can deploy a service, replicated and global.
• Replicated services specify the number of identical tasks (replicas) you want to run.
These replicas will then be split up on the different worker nodes and each serves the
same content.
• A global service is a service that runs one task on every node you have in your swarm and
doesn't need a pre-specified number of tasks. Global services are usually used for monitor
agents or any other type of container that you want to run on every node.
• Visual representation of a
three-service replica and
a global service