Blog

  • Docker Swarm is a clustering and planning tool for Docker compartments. With Swarm, IT administrators and designers can set up and deal with a bunch of Docker nodes as one virtual system. Clustering is a vital component for container technology since it makes an agreeable gathering of frameworks that can give repetition, empowering Docker Swarm failover in the event that at least one nodes encounter an outage. A Docker Swarm cluster additionally gives administrators and engineers the capacity to include or subtract container iterations as computing requests change.

    And to unleash the beast provided by swarm mode and use it on full capacity, the must thing one needs is to make a proper stack file for that. There are multiple components present which can assist the containers to remove any downtime issue and give it a healing capability.

    Here is a full-fledged stack file for swarm mode.

     

    web:
       image: ubuntu:16.04
       deploy:
         mode: global
         replicas: 1
         resources:
           limits:
             cpus: '0.5'
             memory: 500M
           reservations:
             cpus: '0.2'
             memory: 200M
         restart_policy:
           condition: on-failure
           deplay: 3s
           max_attempts: 5
         update_config:
           parallelism: 2
           delay: 5s
           failure_action: rollback
           monitor: 200s
           order: start_first
           max_failure_ratio: 0.2
         placement:
           constraints: [node.role == manager]
       networks:
         - webmaster
    

    There parameters depend on the version of compose you are using. But there are many parameters added after the version 3.

     

    Deploy Key

    The deploy key enables you to indicate design related to the deployment and running of services. The deploy key can likewise be utilized to constrain a few services to run just on the manager node or only on the worker nodes.

     

    deploy:
      mode: replicated
      replicas: 5
      update_config:
        parallelism: 2
        delay: 10s
        order: start_first
      restart_policy:
        condition: on-failure
      resources:
        reservations:
          cpus: '0.3'
          memory: 200M
      rollback_config:
        parallelism: 1
        delay: 80s
        failure_action: continue
        monitor: 180s
        max_failure_ratio: 0.1
        order: start-first
    

    Labels:

    Specify labels on any docker service. Labels are specified only on the services and not on container.

    deploy:
      labels: com.eg.description: "The label here will appear on web services"
    

    Mode:

    Modes can be of two types,

    Replicated and Global. Global: Exactly one container per swarm mode and Replicated: a specified no of containers in total.

    deploy:
      mode: global
    

    Placement:

    To specify the placement constraints and other preferences if the service.

    deploy:
          placement:
            constraints:
              - node.role == manager
            preferences:
              - spread: node.labels.zone
    

     

    Replicas:

    If the mode of service is replicated (or default), this parameter specifies the no of containers to run.

    deploy:
          mode: replicated
          replicas: 6
    

     

    Update_Config:

    This key provides the conditions how the service should be updated.

    deploy:
          replicas: 6
          update_config:
            parallelism: 2
            delay: 20s
            order: stop-first
    

     

    Similarily there are many more keys provided by docker in their 3 and above versions. These keys are very useful for a proper self sustained environment creation and is provides a smooth continuous updates and rollbacks.

    Some other important keys are:

    - Rollback_Config

    - Resources

    - depends_on

    - entrypoint

    - env_file

     

    We will explain all these keys and their usage in the next part of this. If you want to add some environment variables, or to define the conditions for rollbalk in case of failure, or the amount of resources the container will consume, and many more keys and their usage, please refer to the part 2 of this blog.

     

     

     

     

Tags: DevOps