The Shaddock Definiton Model

Your model consist in a set of files that describe your general architecture, It can be a simple Yaml few lines, a more complete Jinja2 templated multi files hierarchy or an integrated Python module that you interface with the rest of your infratsructure.

Defining a service

The following examples resume how you can describe a service in a cluster:

You will need at least the following options:

clusters: 
  - name: complete-service
    images: images/testdir
    services:
      - name: test900
        image: testuser/arch_base:latest

The following options are currenlty implemented:

clusters: 
  - name: complete-service
    images: images/testdir
    hosts: !include site01/hosts_dc01.yml
    vars: !include site01/test-variables01.yml
    services:
      - name: test900
        image: testuser/arch_base:latest
        priority: 900
        host: node001-socket
        ports:
          - 0.0.0.0:4321:4322
          - 0.0.0.0:4325
          - 4326:4327
          - 4329
        volumes: 
          - /home/user1/:/mnt/vol2:rw
          - /var/www:/mnt/vol1:ro
          - /var/ww:/mnt/vol3
        env:
          VAR001: '{{ var_001 }}'
        depends-on:
          - {host: 127.0.0.1, type: http, get: '/', code: 200, useproxy: False}
        command: "echo $VAR001"

Including other files

Shaddock allow you to split your definition model into multiple yaml files using the !include notation.

This, conbined with the templating allow you to design very complex architectures without repetitions or loosing in readabality of your model.

clusters: 

  - name: include-test
    vars: !include site01/test-variables01.yml
    images: images/testdir
    services:
      - name: test120
        image: testuser/arch_base:latest
        priority: 120
        env:
          VAR001: '{{ var_001 }}'
        command: "echo $VAR001"

  - name: command-test
    vars: 
        foo: bar
    images: images/testdir
    services:
      - name: test121
        image: testuser/arch_base:latest
        priority: 121
        env:
          FOO_BAR: '{{ foo }}'
        command: "echo $VAR001"

Using the scheduler

The Shaddock scheduler will ensure that all the requirements you provide are matched before starting a new service.

You can check: - A container status - If a port is open (tcp or udp) - The return code of a http GET

You can also specify the number of retry, the time to wait before 2 checks, and if the check should use the system proxy vars or not.

- {name: nova, status: stopped}
- {name: nova, port: 8774, type: tcp}
- {name: nova, port: 8774, state: down, type: tcp}
- {host: google.com, port: 8774, state: down, type: tcp}
- {name: nova, type: http, get: '/v2.0', port: 5000, code: 200}
- {host: google.com, type: http, get: '/v2.0', port: 5000, code: 200}
- {host: 127.0.0.1, type: http, get: '/', code: 200, useproxy: False }
- {name: nova, sleep: 20} # defaults to 10
- {name: nova, retry: 10} # defaults to 5
clusters: 
  - name: scheduler-tests
    images: images/testdir
    services:
      - name: test500
        image: testuser/arch_base:latest
        priority: 500
      
      - name: test501
        image: testuser/arch_base:latest
        priority: 510

      - name: test503
        image: testuser/arch_base:latest
        priority: 520
        depends-on:
          - {name: test001, status: stopped}
          - {name: test002, status: stopped, retry: 10, sleep: 10}


  - name: scheduler-tcp-tests
    images: images/testdir
    services:     
      - name: test504
        image: testuser/netcat:latest
        priority: 550
        ports:
          - 1234:1234
        command: "nc -l 1234"

      - name: test520
        image: testuser/arch_base:latest
        priority: 560
        depends-on:
          - {name: test006, port: 1234, type: tcp}

Managing multiple hosts

Shaddock is able to schedule your services on different hosts accros your datacenter. The only prerequirements for a host to be part of a Shaddock cluster is toi have the Docker API installed and listening on a port. You can then configure your hosts in your cluster defintion.

- name: node001-socket
  url: unix://var/run/docker.sock

- name: node002-tcp
  url: tcp://127.0.0.1:2376
  verion: 1.12

- name: node003-tls
  url: tcp://127.0.0.1:2376
  tls: False
  cert_path: None
  key_path: None
  cacert_path: None
  tls_verify: False
clusters: 
  - name: host-cluster1
    images: images/testdir/
    hosts: !include site01/hosts_dc01.yml
    services:
      - name: service202
        image: testuser/arch_base:latest
        priority: 210

      - name: service203
        image: testuser/arch_base:latest
        host: node001-socket
        priority: 211

  - name: host-cluster2
    images: images/testdir/
    hosts: !include site01/hosts_dc02.yml
    services:
      - name: service204
        image: testuser/arch_base:latest
        host: node002-tcp
        priority: 212

      - name: service205
        image: testuser/arch_base:latest
        host: node003-tls
        priority: 213

Using the templating functionalities

The model definition variables {{ your_var }} are templated using Jinja2 before being interpreted by Shaddock. You can define any variables value in the vars: section of a cluster definiton.

refs: http://jinja.pocoo.org/

clusters: 
  - name: jinja2-tests01
    vars: !include site01/test-variables01.yml
    images: images/testdir
    services: |
      {% for service in servicelist %}
        - name: clu1-{{service}}
          image: testuser/arch_base:latest
          priority: 401
          env:
            VAR001: {{var_001}}
          command: env
      {% endfor %}

  - name: jinja2-tests02
    vars: !include 'site01/test-variables01.yml'
    images: images/testdir
    services: |
      {% for service in largeservicelist %}
        - name: clu2-{{service}}
          image: testuser/arch_base:latest
          priority: 401
          env:
            VAR001: {{var_001}}
          command: env
      {% endfor %}