Easily browse through Chef data in a user-friendly format using your favorite browser. Chef-browser allows you to list (and search through) nodes, environments, roles and data bags (and items) as well as view their details: basic information plus pre-formatted JSON data. Shorten the time necessary to access often used information with saved searches.
To install chef-browser, run:
$ bundle install
Note: You might have to install icu4c (MacOS) or libicu-dev (Debian/Ubuntu) to successfully install the required charlock_holmes gem.
Create a settings.rb file. Provide your server url, client name and the path to the client key. You can add additional connection options, but that's not necessary to run chef-browser properly. A full list of available options can be found in Ridley's yard documentation.
Run:
$ rackup -o 0.0.0.0 config.ru
Puma 2.6.0 starting...
* Min threads: 0, max threads: 16
* Environment: development
* Listening on tcp://0.0.0.0:9292
Go to http://0.0.0.0:9292.
You can define saved searches. To do that, open your settings.rb file and follow this syntax:
node_search['MySQL Servers'] = 'mysql_server_root_password:*'
node_search['Staging'] = 'chef_environment:staging'You can define as many saved searches as you like. Your saved searches will appear as a dropdown list next to the search box. Right now this option works only for nodes.
Chef-browser mimics knife's fuzzy searches, so entering "foo*" in the search box will result in performing a search for "tags:foo OR roles:foo OR fqdn:foo OR addresses:foo".
In order to save on bandwidth and memory, partial searches are enabled for users of Chef 11.0. If you use Chef 10.x, disable the use_partial_search option in your settings.rb file.
Chef-browser allows you to access the following:
- nodes, environments, roles, data bags and cookbooks available on your server,
- details of each node:
- name, ip address, fqdn, environment, tags, run list,
- attributes presented using JSONpath in a handy, filterable table,
- details of each environment:
- cookbooks and their versions,
- default and override attributes,
- details of each role:
- run lists and env_run_lists (if present),
- default and override attributes,
- details of bags and data bag items,
- details of each cookbook:
- name, description, metadata,
- file list, recipe list,
- display and/or download every file in a cookbook.
Where possible, tags, environment names and role views link to appropriate nodes, while run list elements link to other roles.
Chef-browser is a Sinatra-based app. It uses Ridley to communicate with the Chef server. Handling configuration settings is done using the Tinyconfig library. CSS & Javascript are provided by Twitter's Bootstrap. jQuery.FilterTable was used to help present data.
By default, chef-browser publishes content without any access control, and authentication is left to the proxy server. If you use Chef below version 12.0, content can be secured by a login page, which requires a username and password to validate against users registered in the Chef server (just as the original Chef Web UI). To limit access with a login page, set the login option to true in the settings file.
When login is required, Chef-browser uses Rack sessions. By default, on each restart, a fresh, random session secret is generated. This logs out every user, and can be annoying. To save secret across restarts, generate a random string (e.g. by running ruby -rsecurerandom -e 'puts SecureRandom.base64(36)') and add it to settings.rb as cookie_secret.
Chef-browser works with following Ruby versions:
- 2.4.3,
- 2.5.0.
- Fork the repo.
- Create a branch from the develop branch and name it 'feature/name-of-feature':
git checkout -b feature/my-new-feature(We follow [this branching model] (http://nvie.com/posts/a-successful-git-branching-model/)) - Make sure you test your new feature.
- Commit your changes together with specs for them:
git commit -am 'Add some feature' - Push your changes to your feature branch.
- Submit a pull request to the develop branch. Describe your feature in the pull request. Make sure you commit the specs.
- A pull request does not necessarily need to represent the final, finished feature. Feel free to treat it as a base for discussion.