updated compose files and swarm lab

Author: jordiblasco

admin-training/containers/01-docker-swarm-introduction.md

@@ -24,15 +24,15 @@ This guide assumes that:
 2. The sNow! server will also provide access to share file system via NFS (/home and /sNow). Check the [sNow! documentation](https://hpcnow.github.io/snow-documentation) in order to integrate other cluster file systems like BeeGFS, Lustre or IBM Spectrum Scale.
 
 ## Installation
-Docker Swarm manager nodes implement the Raft Consensus Algorithm to manage the global cluster state.
+Docker Swarm manager nodes implement the *Raft Consensus Algorithm* to manage the global cluster state.
 This is key for managing and scheduling tasks in the cluster, and also storing the same consistent state.
 
-Raft tolerates up to (N-1)/2 failures and requires a majority or quorum of (N/2)+1 members to agree on values proposed to the cluster. This means that the size of the cluster should be at least 3 to resist one node failure or 5 to resist 3 nodes failures.
+Raft *tolerates* up to *(N-1)/2 failures* and requires a majority or quorum of (N/2)+1 members to agree on values proposed to the cluster. This means that the size of the cluster should be at least 3 to resist one node failure or 5 to resist 3 nodes failures.
 
 This hands-on assumes that you have already deployed three VMs (domains) dedicated for Docker Swarm cluster or three compute nodes (production solution).
 
 By default manager nodes also act as a worker nodes. For a small systems or non-critical services, this is relatively low-risk.
-However, because manager nodes use the Raft consensus algorithm to replicate data in a consistent way, they are sensitive to resource starvation. In sNow! environment you can isolate managers in VMs without running other services and deploy few bare metal nodes as Docker Swarm workers. In order to do so, you can drain manager nodes to make them unavailable as worker nodes:
+However, because manager nodes use the Raft consensus algorithm to replicate data in a consistent way, they are sensitive to resource starvation. In sNow! environment you can *isolate managers in VMs without running other services* and deploy few bare metal nodes as Docker Swarm workers. In order to do so, you can drain manager nodes to make them unavailable as worker nodes:
 ```
 docker node update --availability drain <NODEID>
 ```
@@ -196,9 +196,11 @@ docker service rm sleep_app
 The following example represents much better the benefits of adopting this technology.
 
 ### Defining a stack of services
-Docker Swarm allows to deploy a complete application stack to the swarm. The deploy command accepts a stack description in the form of a Compose file.
+Docker Swarm allows to deploy a complete application stack to the swarm. The deploy command accepts a stack description in the form of a [compose-file](https://docs.docker.com/compose/compose-file/).
 
-In the container folder there is a file called monitoring-stack.yml which contains an example of a complete monitoring stack including a ElasticSearch cluster, kibana, InfluxDB, grafana, etc.
+In the container folder there are two compose files:
+* [gui-stack.yml](gui-stack.yml) which contains an example of two popular Swarm GUIs stack, [Portainer](https://portainer.io) and [Swarmpit](https://swarmpit.io/).
+* [monitoring-stack.yml](monitoring-stack.yml) which contains an example of a complete monitoring stack including a ElasticSearch cluster, Kibana, InfluxDB, Grafana, etc.
 
 Download this file to your swarm01 and execute the following command to orchestrate the monitoring stack example:
 ```

admin-training/containers/gui-stack.yml

@@ -0,0 +1,82 @@
+# This example deploys two popular swarm GUIs
+# portainer: https://portainer.io
+# swarmpit: https://swarmpit.io/
+version: "3"
+services:
+
+  portainer:
+    image: portainer/portainer
+    command: -H unix:///var/run/docker.sock
+    ports:
+      - "9000:9000"
+    volumes:
+      - /etc/portainer:/data
+      - /var/run/docker.sock:/var/run/docker.sock
+    networks:
+      - net
+    deploy:
+      placement:
+        constraints: [node.role == manager]
+
+  app:
+    image: swarmpit/swarmpit:latest
+    environment:
+      - SWARMPIT_DB=http://db:5984
+    volumes:
+      - /var/run/docker.sock:/var/run/docker.sock:ro
+    ports:
+      - 888:8080
+    networks:
+      - net
+    deploy:
+      resources:
+        limits:
+          cpus: '0.50'
+          memory: 1024M
+        reservations:
+          cpus: '0.25'
+          memory: 512M
+      placement:
+        constraints:
+          - node.role == manager
+
+  db:
+    image: klaemo/couchdb:2.0.0
+    volumes:
+      - db-data:/opt/couchdb/data
+    networks:
+      - net
+    deploy:
+      resources:
+        limits:
+          cpus: '0.30'
+          memory: 512M
+        reservations:
+          cpus: '0.15'
+          memory: 256M
+
+  agent:
+    image: swarmpit/agent:latest
+    environment:
+      - DOCKER_API_VERSION=1.35
+    volumes:
+      - /var/run/docker.sock:/var/run/docker.sock:ro
+    networks:
+      - net
+    deploy:
+      mode: global
+      resources:
+        limits:
+          cpus: '0.10'
+          memory: 64M
+        reservations:
+          cpus: '0.05'
+          memory: 32M
+
+networks:
+  net:
+    driver: overlay
+
+volumes:
+  db-data:
+    driver: local

admin-training/containers/monitoring-stack.yml

@@ -22,6 +22,9 @@ services:
       - influxbd:/var/lib/influxdb
     deploy:
       replicas: 1
+      update_config:
+        parallelism: 1
+        delay: 10s
       placement:
         constraints:
           - node.role == manager
@@ -36,6 +39,9 @@ services:
       - influxbd
     deploy:
       replicas: 1
+      update_config:
+        parallelism: 1
+        delay: 10s
       placement:
         constraints:
           - node.role == manager
@@ -53,6 +59,9 @@ services:
       - influx
     deploy:
       mode: global
+      update_config:
+        parallelism: 1
+        delay: 10s
 
 
   elasticsearch:
@@ -67,6 +76,11 @@ services:
       memlock:
         soft: -1
         hard: -1
+    deploy:
+      mode: global
+      update_config:
+        parallelism: 1
+        delay: 10s
     volumes:
       - esdata1:/elasticsearch/data
     ports:
@@ -86,6 +100,11 @@ services:
       memlock:
         soft: -1
         hard: -1
+    deploy:
+      mode: global
+      update_config:
+        parallelism: 1
+        delay: 10s
     volumes:
       - esdata2:/elasticsearch/data
     networks:
@@ -103,6 +122,11 @@ services:
       memlock:
         soft: -1
         hard: -1
+    deploy:
+      mode: global
+      update_config:
+        parallelism: 1
+        delay: 10s
     volumes:
       - esdata3:/elasticsearch/data
     networks:
@@ -113,6 +137,11 @@ services:
     environment:
       SERVER_NAME: kibana.local
       ELASTICSEARCH_URL: http://elasticsearch:9200
+    deploy:
+      mode: global
+      update_config:
+        parallelism: 1
+        delay: 10s
     ports:
       - '5601:5601'
     networks: