A Server Dashboard for Chef repositories
Python HTML Ruby JavaScript CSS
Latest commit b6c3bc9 Oct 6, 2015 @thekorn thekorn Merge pull request #115 from edelight/fix_cluster_name
dashboard graphs: replace the dash with an underscrore
Permalink
Failed to load latest commit information.
kitchen
.gitignore Added .coverage to .gitignore Nov 21, 2012
CHANGELOG Fix README typos Nov 19, 2012
LICENSE
NOTICE Fixed typo in is_view() docstring Nov 21, 2012
README.md Tag 0.3.0 Nov 20, 2012
manage.py make manage.py executable Apr 12, 2012
requirements.txt
test_requirements.txt

README.md

Kitchen

Example list view

Kitchen is a Dashboard where you can visualize and browse your servers. It has a node list view, a hardware centric virt view where nodes are grouped by host, and a graph view that dynamically generates graphs of your infrastructure. It never has been easier to find and organize all your nodes!

How it works

A Chef repository is kept in sync and the node data bag is created. From that, nodes, roles and environments will be detected, resulting in a browseable web interface to your server infrastructure.

Installation

We will need:

  • python 2.6+
  • Django 1.4+
  • logbook
  • littlechef 1.2+
  • graphviz
  • pydot 1.0.26+ (for graphviz graphs)

For tests:

  • django-nose
  • mock

Distro package dependencies can be installed on Debian or Ubuntu by typing:

$ apt-get install sqlite3 graphviz

while all Python dependencies can be install by using requirements.txt and test_requirements.txt:

$ pip install -r requirements.txt && pip install -r test_requirements.txt

Running the development server

To give the web interface a try use the development server on localhost:8000:

$ python manage.py runserver

Repo syncing

To resync a repo at any time you can run the repo_sync.py script:

$ python repo_sync.py

When deploying kitchen to a server a cron job should be added that runs the script periodically.

You should be able to play around with the test kitchen straightaway. You can configure you own repo in settings.py by properly configuring the REPO_BASE_PATH and REPO variables.

Deploying

We also provide a chef cookbook for Kitchen for deploying Kitchen on a server.

Tags

The tag column will show any string in the list defined by top-level Chef "tags" attribute.

It is possible to assign different colors to the tag buttons by mapping tag names to css styles:

TAG_CLASSES = {
    "WIP": "btn-warning",
    "dummy": "btn-danger",
    "Node*": "btn-info"
}

Available bootstrap CSS styles: btn-danger, btn-info, btn-inverse, btn-primary, btn-success and btn-warning

Links

The dashboard will show any links to external systems (for example monitoring or admin interfaces) it finds on kitchen/data/links/. The format is:

{
    "url": "http://testnode1:22002",
    "img": "http://your.image.domain/haproxy-logo.png",
    "title": "haproxy"
}

If the "img" field is not present, a text link will be shown instead of an image.

If you don't want to clutter your node files with link data, you can use link plugins to generate the links on the fly. Just save the plugin in the backends/plugins/ dir and add the plugin name to ENABLE_PLUGINS.

The link column can be deactivated with the option SHOW_LINKS.

Views

Virt

Example virt view

Virt groups nodes by host to present a close-to-the-hardware view to your nodes. That is done by fetching all nodes with the Chef attribute virtualization/role set to host, looking at all the virtualization/guests entries, and adding the corresponding "guest" nodes to the list.

This view is optional and can be deactivated in settings.py by setting SHOW_VIRT_VIEW to False.

Note: Filtering by using the left nav bar will show all hosts with all their guests that have at least a guest containing one of the selected roles. Filtering by using the search field will only show matching guests.

Graphs

Example graph

The graph view dynamically generates a graph of your repository, acording to the current node selection. Dependencies between nodes are defined by the attributes client_roles and needs_roles.

Using the test repo as an example:

  • The webserver role defines:
    "default_attributes": {
        "apache2": {"client_roles": ["loadbalancer"]}
    }

That will generate an arrow from loadbalancer nodes to webserver nodes, with apache2 as label.

  • The worker role defines:
    "default_attributes": {
        "mysql": {"needs_roles": ["dbserver"]}
    }

That will generate a dashed arrow from worker nodes to dbserver nodes, with mysql as label.