github.com/brahmaroutu/docker@v1.2.1-0.20160809185609-eb28dde01f16/docs/swarm/how-swarm-mode-works/services.md (about)

     1  <!--[metadata]>
     2  +++
     3  title = "How services work"
     4  description = "How swarm mode services work"
     5  keywords = ["docker, container, cluster, swarm mode, node"]
     6  [menu.main]
     7  identifier="how-services-work"
     8  parent="how-swarm-works"
     9  weight="4"
    10  +++
    11  <![end-metadata]-->
    12  
    13  # How services work
    14  
    15  To deploy an application image when Docker Engine is in swarm mode, you create a
    16  service. Frequently a service will be the image for a microservice within the
    17  context of some larger application. Examples of services might include an HTTP
    18  server, a database, or any other type of executable program that you wish to run
    19  in a distributed environment.
    20  
    21  When you create a service, you specify which container image to use and which
    22  commands to execute inside running containers. You also define options for the
    23  service including:
    24  
    25  * the port where the swarm will make the service available outside the swarm
    26  * an overlay network for the service to connect to other services in the swarm
    27  * CPU and memory limits and reservations
    28  * a rolling update policy
    29  * the number of replicas of the image to run in the swarm
    30  
    31  ## Services, tasks, and containers
    32  
    33  When you deploy the service to the swarm, the swarm manager accepts your service
    34  definition as the desired state for the service. Then it schedules the service
    35  on nodes in the swarm as one or more replica tasks. The tasks run independently
    36  of each other on nodes in the swarm.
    37  
    38  For example, imagine you want to load balance between three instances of an HTTP
    39  listener. The diagram below shows an HTTP listener service with three replicas.
    40  Each of the three instances of the listener is a task in the swarm.
    41  
    42  ![services diagram](../images/services-diagram.png)
    43  
    44  A container is an isolated process.  In the swarm mode model, each task invokes
    45  exactly one container. A task is analogous to a “slot” where the scheduler
    46  places a container. Once the container is live, the scheduler recognizes that
    47  the task is in a running state.  If the container fails health checks or
    48  terminates, the task terminates.
    49  
    50  ## Tasks and scheduling
    51  
    52  A task is the atomic unit of scheduling within a swarm.  When you declare a
    53  desired service state by creating or updating a service, the orchestrator
    54  realizes the desired state by scheduling tasks. For instance, the you define a
    55  service that instructs the orchestrator to keep three instances of a HTTP
    56  listener running at all times. The orchestrator responds by creating three
    57  tasks. Each task is a slot that the scheduler fills by spawning a container. The
    58  container is the instantiation of the task. If a HTTP listener task subsequently
    59  fails its health check or crashes, the orchestrator creates a new replica task
    60  that spawns a new container.
    61  
    62  A task is a one-directional mechanism. It progresses monotonically through a
    63  series of states: assigned, prepared, running, etc.  If the task fails the
    64  scheduler removes the task and its container and then creates a new task to
    65  replace it according to the desired state specified by the service.
    66  
    67  The underlying logic of Docker swarm mode is a general purpose scheduler and
    68  orchestrator.  The service and task abstractions themselves are unaware of the
    69  containers they implement.  Hypothetically, you could implement other types of
    70  tasks such as virtual machine tasks or non-containerized process tasks.  The
    71  scheduler and orchestrator are agnostic about their type of task. However, the
    72  current version of Docker only supports container tasks.
    73  
    74  The diagram below shows how swarm mode accepts service create requests and
    75  schedules tasks to worker nodes.
    76  
    77  ![services flow](../images/service-lifecycle.png)
    78  
    79  ## Replicated and global services
    80  
    81  There are two types of service deployments, replicated and global.
    82  
    83  For a replicated service, you specify the number of identical tasks you want to
    84  run. For example, you decide to deploy an HTTP service with three replicas, each
    85  serving the same content.
    86  
    87  A global service is a service that runs one task on every node. There is no
    88  pre-specified number of tasks. Each time you add a node to the swarm, the
    89  orchestrator creates a task and the scheduler assigns the task to the new node.
    90  Good candidates for global services are monitoring agents, an anti-virus
    91  scanners or other types of containers that you want to run on every node in the
    92  swarm.
    93  
    94  The diagram below shows a three-service replica in yellow and a global service
    95  in gray.
    96  
    97  ![global vs replicated services](../images/replicated-vs-global.png)