Even if you know your way around a set of tools and consider yourself an efficient user, some little helpers can still save you lots of time. Today, at Warsaw Ruby Users Group evening, we have officially released such a helper for Chef users. Chef Browser is an open source tool we created to support your daily work. As the name unsurprisingly suggests, Chef Browser lets you browse the data in your Chef server. If you use
knife search and
knife show a lot to find out detailed information, you might be pleased to know you don’t have to re-type the same commands over and over again to access certain data.
You’ll need Ruby 1.9.3 or 2.0.0 (Rubinius and JRuby are also supported) with Rubygems and Bundler. Download the code from the GitHub repository. Run
bundle install to install the needed gems. Create a
settings.rb file, which will override default settings. To do that, follow the examples in the settings.rb.example file, providing details of your Chef server (url, client name, client key). When you’re ready, run
puma -e production. If not specified otherwise, Chef Browser will be available at
http://localhost:9292; for production deployment, tell your Apache or Nginx to proxy from that port.
The main page of Chef Browser lists all known nodes. You can navigate to other resources from there: roles, environments, data bags and data bag items. After clicking on any item on the list, you will be taken to a page showing this item’s details.
Let’s use nodes as an example: when viewing details of a node, the accessible data is close to what you’d get by typing knife raw /nodes/node_name . The difference lies in formatting: Chef Browser presents nested attributes with their JSONPath. This makes it easier not to get lost in (sometimes quite deeply) nested attributes, and to find the one you’re looking for without having to navigate down the hierarchy – especially handy if you’re not sure in which part of the attribute hierarchy your data lives. Since it won’t be uncommon for a table of JSON attributes to be over a thousand rows long, the table is supported by a jQuery live filter, narrowing the visible data to just what’s necessary.
We aimed at linking data together where possible. For example, tags and the environment of a given node will link to other nodes sharing the same tag or environment.
Configurable saved searches
How often do you need to find some nodes across the servers by their content, and you have to use (and remember) queries like like
knife search mysql_server_root_password:* -i? (Long) search queries that you run often can be saved and accessed from the search bar’s dropdown menu:
It’s enough to edit your
settings.rb file, adding one line per saved search, like so:
node_search['MySQL'] = 'mysql_server_root_password:*'
Under the hood
We decided to make Chef Browser as light-weight as possible. Since all data is acquired by queries to the Chef server, there’s no necessity to have a separate database. Hence, Sinatra became our web framework of choice. The app is based on Bootstrap 3, which is 100% responsive and looks well on tablets and mobiles – a small thing people on pager duty might appreciate. To talk with the Chef server, we use Ridley, a Chef API client gem made available by Riot Games
This is the first release. We’ve done our best to test Chef Browser, and we already use it everyday. We also plan to keep working on it: on the roadmap there’s at least cookbook browsing and access to encrypted data bags. We’re also very open to suggestions, bug reports as well as seeing new issues and pull requests on Github.