• Docker Swarm Creating a Complete Stack File

  Posted by Apoorv Singh | Last Updated: 14-Jan-19
  

  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