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: simple-service
images: images/testdir
services:
- name: simpleservice
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: test500, status: stopped}
- {name: test501, status: stopped, retry: 10, sleep: 10}
- name: scheduler-tcp-tests
images: images/testdir
services:
- name: test504
image: testuser/netcat:latest
priority: 550
ports:
- 0.0.0.0:1234:1234
command: "nc -l 1234"
- name: test520
image: testuser/arch_base:latest
priority: 560
depends-on:
- {name: test504, 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 %}