Skip to content

Generic cloud-cli to spin up clusters in your cloud

Notifications You must be signed in to change notification settings

sperka/lusheeta

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

73 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

lusheeta

This set of scripts helps you to manage separate clusters in your cloud. The tool lets you create and cleanup a cluster of your choice (see #Configuration).


Usage

$ ./main.py -h
usage: main.py [-h] -a {create,cleanup,prepare_ansible,run_ansible}
               [-c CONFIG] [-v]
               project

Cloud CLI tool

positional arguments:
  project               the name of the project

optional arguments:
  -h, --help            show this help message and exit
  -a | --action {create,cleanup,prepare_ansible,run_ansible}
                        the action to do
  -c | --config CONFIG
                        path to the configuration file
  -v, --verbose         set verbosity mode

The following examples will show how to setup a cluster (after configuring all necessary settings in the config file):

    # create cluster with an external config.yml + show debug messages
    $ ./main.py --action create --config /path/to/config.yml -vvv myproject
    
    # after cluster has been created, generate necessary ansible files + show only 'info' level logging
    $ ./main.py --action prepare_ansible --config /path/to/config.yml -vv myproject
    
    # run ansible playbook to setup software infrastructure
    $ ./main.py -a run_ansible -c /path/to/config.yml myproject
    
    # cleanup cluster from the cloud
    $ ./main.py -a cleanup -vvv myproject

Configuration

You can find the configuration files in the ./config dir.

default.yml - main config

This configuration file is the main configuration for the CLI tool. You can set the following parameters:

  • project

    the name of the project (cluster) you want to manage.

  • projects_dir - the path to the default projects directory

    • default: ./projects
  • platform - the cloud platform of your choice

    • default: openstack
    • currently supported platforms: openstack
  • platform_settings_file optional - the path to settings_file for the platform. It's the same as settings_file in supported_platforms.yml but if defined, has a higher priority (easier to define openstack credentials outside the source)

  • network dict - the network settings for your cluster (when creating)

    • cidr - the CIDR for your cluster's network.
      • default: auto
      • possible values: auto or XXX.XXX.XXX.0/24
    • cidr_template - the CIDR template. Currently the script will substitute the X character from the template.
      • default: 10.X.100.0/24
      • Required when cidr == auto, otherwise optional
    • ext_net_name - the name of the gateway for your network to connect to the external network
      • default: ext-net
  • vm_management dict - vm management settings for your cluster (when creating)

    • default_image_name - the default name of the image to use to spin up a vm. If you don't specify the image_name property for a host, this value will be used.
      • default: Ubuntu 14.04.2_20150505
    • default_vm_flavor - the name of the flavor to spin up a vm. If you don't specify the vm_flavor property for a host, this value will be used.
      • default: m1.medium
    • hosts_startup_timeout - the amount of time (in seconds) to wait to spin up all the vms and then keep executing the rest of the script
      • default: 600
    • terminate_vm_poll - the amount of time (in seconds) to wait between polls when terminating vms
      • default: 5
  • hosts array - the section to setup host configs. Each array item is a host dict, which is a configuration for one host

    • name required - the name of the host

    • vm_flavor optional - the name of the flavor to spin up a vm. This property overrides vm_management.default_vm_flavor

    • count optional - the number of vms to spin up with these properties. If this field is missing, default value of 1 will be used.

    • image_name optional - the name of the image to spin up a vm. This property overrides vm_management.default_image_name

    • cloud_vars optional array - implementation specific special variables. Each item in the array must be a dict that contains the following parameter:

      • index all | <number> - the index to which host to apply the current special var

        • possible values can be all or the index <number> of the host
        • see config/default.yml as example

        Implemented options so far:

        • assignPublicIP boolean - when true, a public IP will be assigned to the index-th host
    • ansible_settings array - the section to setup the ansible settings for the host. Each item in the array is a dict with the following parameters:

      • ansible_group - which ansible group this host will belong to

      • group_vars array - an array of dict items to describe group-level variables. Each item must contain an index key and the desired parameter key with its value

        • index - which item in the list should have the parameter key
        • parameter_key: parameter_value - the parameter key-value to add in the inventory file for the current host
      • item_vars array - an array of key-value pairs that every item should contain in the group

  • ansible dict - ansible settings to setup the software infrastructure

    • ansible_dir - the path to directory where your ansible project files reside
    • playbook - relative path to the playbook to run your setup
    • templates_path - path to folder that contains template files
    • inventory_template optional - a jinja2 template file for your inventory to use
    • ssh_config_template optional - a jinja2 template file for the ssh.config file
    • ansible_cfg_template optional - a jinja2 template file for the ansible.cfg file
    • ansible_bin_path required - the folder that holds ansible, ansible-playbook, etc

** For OpenStack networking the official OpenStack SDK was used as libcloud doesn't support the required functionalities (i.e. creating/removing subnets, networks, routers, etc).

UPDATE libcloud dropped completely.


Extension

./config/supported_platforms.yml contains the implementations of different platforms (so far only openstack is supported).

About

Generic cloud-cli to spin up clusters in your cloud

Topics

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages