Drivers¶

VmShepherd is designed to cover most of its functionalities by separable drivers. It is easy to change some logic by writing your own driver and using it.

Entry points¶

To make it easier to create and use other drivers without code changes within VmShepherd itself, python’s entry point mechanism are used (https://packaging.python.org/specifications/entry-points/).

Entry points for drivers:

vmshepherd.driver.iaas - IaaS Driver
vmshepherd.driver.presets - Preset Driver
vmshepherd.driver.runtime - Runtime Driver
vmshepherd.driver.healthcheck - Healthcheck Driver

Config example for an IaaS Driver:

iaas:
  driver: DummyIaasDriver
  driver_arg_1: val1
  driver_arg_2: val2

Search rules for entry points are vmshepherd.driver.{name}. IaaS Driver with a name DummyIaasDriver will be searched in the vmshepherd.driver.iaas entrypoint.

Iaas Driver¶

IaaS Driver provides abstraction layer which unifies API methods, making it easier to use many IaaS providers.

Implemented IaaS Drivers:

DummyIaasDriver - iaas simulation driver

OpenStackDriver - asyncopenstackclient library wrapper

Runtime Driver¶

Runtime Driver implements methods to lock preset before managing it. It can be very useful when many VmShepherd instances work on the same list of presets. It can also hold runtime data - information that should be available in later iterations. That data can be for example: a number of failed checks for VM with ID X.

Implemented Runtime Drivers:

InMemoryDriver - To use for only one VmShepherd instance. It holds all data in local memory

PostgresDriver - Runtime driver that utilizes PostgreSQL database engine, supplied by a separate package

ZookeeperDriver - Plugin runtime driver that takes advantage of Zookeeper configuration maintainer

Preset Driver¶

Preset Driver is used to get information about preset configurations from its own store.

Implemented Preset Drivers:

DirectoryDriver - read preset configurations from local files

GitRepoDriver - get preset configuration from git repositories

Preset global configuration:

name: NAME # preset name
count: COUNT_OF_VMS # count of vms to keep running in this preset
manage_interval: SECONDS_TO_NEXT_MANAGE # run manage after manage_interval delay
manage_expire: SECONDS_TO_MANAGE_EXPIRE # run manage procedure even if lock acquire failed
image: ubuntu16 # system image name
flavour: small # vm flavour
userdata_source_root: ''
userdata: 'file://user_data' # cloud-init user data to use
meta_tags:
  role: httpserver
  environment: prod
key_name: user@domain # ssh key name
network:
  security_groups:
    - security_gorup_id1  # priv
    - security_gorup_id2  # global
    - security_gorup_id3  # adm
  availability_zone: az1
  subnets:
    - net-id: network_id

Parameters:

name - preset’s name used to define VMs group. Example: PROD_apps_cluster_1.
count - count of virtual machines in group.
manage_interval - Delay to next manage iteration.
manage_expire - After this delay lock acquire failed manage procedure is called.
image - Image name available in iaas.
flavour - Virtual machine flavor/size.
userdata - User data (cloud-init config) can be defined like a string or a file. Content of user data can be a jinja template. To generate final config it uses all preset configuration. Example below.
userdata_source_root - If userdata parameter is defined like ‘file://’ userdata_source_root is start path to find it.
meta_tags - Virtual Machine metadata.
key_name - SSH public key name.
network - Configuration block used to define virtual machine networking.

User data example:

#cloud-config
write_files:
- path: /etc/salt/grains
  owner: root:root
  permissions: '0744'
  content: |
    {% for key, value in meta_tags.items() %}
    {{ key }}: {{ value }}
    {% endfor %}

Healthcheck Driver¶

Healthcheck Driver provides methods to check if your application (or other process) is running on a VM, and works properly.

Implemented Healthcheck Drivers:

DummyHealthcheck - a healthcheck simulation driver returning always positive check result

HttpHealthcheck - uses HTTP request