Thursday, January 22, 2015

Chef Analytics 1.1.0 Release [feedly]



----
Chef Analytics 1.1.0 Release
// Chef Blog

We are happy to announce the release of the Chef analytics 1.1.0 package (opscode-analytics-1.1.0). 1.1.0 is the new production release, and has many new features over the 1.0.x series.

You can download the release from the Chef analytics download page.

Dependencies

Chef Server

Chef Server 12 is required for Chef analytics 1.1.0.

We support Chef server version 12.0.0 or higher.

This is available from the Chef Server download page.

Reporting

We suggest Chef reporting version 1.2.3 for full features and functionality.

You can use a lower version of opcode-reporting (e.g. 1.1.7), but you will not be able to send notifications or audits on Chef client runs.

This is available from the Reporting add-on download page

Chef Client

Chef Analytics 1.1.0 requires either Chef Client 11 or Chef Client 12.

In order to use the Chef Client Audit Controls you need Chef client 12.2.0.alpha.0

You can install it as follows:

curl -L https://www.chef.io/chef/install.sh | sudo bash -s -- -v 12.2.0.alpha.0

Upgrade

You can upgrade from Chef analytics 1.0.4 to 1.1.0. You will need to follow the same steps on your Chef server as in the fresh install process

  • Stop Chef analytics

opscode-analytics-ctl stop

  • Install package, e.g.

dpkg -i opscode-analytics_1.1.0_amd64.deb

  • run the preflight check

opscode-analytics-ctl preflight-check

  • Reconfigure

opscode-analytics-ctl reconfigure

  • Start Chef analytics

opscode-analytics-ctl restart

Features

Alternative deployment topologies

We have added the possibility to deploy Chef analytics as a tiered topology, with the persistence services running on the backend nodes and the API services running on the frontend nodes.

https://docs.chef.io/install_analytics.html contains full installation instructions for installation in both standalone and tiered mode.

NOTE: Due to resource utilization on the analytics server, we no longer support the combined topology where you could install the Chef server and Chef analytics on the same node.

OAuth 2.0 based authentication

We now use OAuth 2.0 to authenticate all user interaction with Chef analytics. This means you now need the oc-id service which is bundled with Chef 12.

OAuth 2.0 is a token based authentication scheme where an application, such as Chef analytics can use tokens issued by a provider like oc-id. It means you need no special credential (e.g webui_priv.pem, a privledged Chef key) stored on the analytics server.

NOTE: Some extra initialization is needed (setting oc_id['applications'] in the private-chef.rb).

Command Line tools

We have added a knife plugin which currently allows read-only access to all the objects stored in the analytics database. There is also a lower-level API abstraction library which includes the code to convert your Chef client certificate into an OAuth 2.0 token transparently.

Documentation

http://docs.chef.io/analytics/ is the main source for Chef Analytics documentation.

API documentation is provided as part of the web application and is also available on http://docs.chef.io/api_analytics.html

Updated Actions

Due to changes in Chef 12, we now can show actions on user invitations and association and dissociation with an organization. We also show details of permission changes for both permissions on individual objects in the Chef server and Global permissions.

analytics_timeline

Chef Client audit controls

Chef client audit mode uses "controls" defined as part of your Chef cookbooks to check if auditable conditions are true or false on a node. It addresses the cases of:

  1. Infrastructure audits. Convert an unmanaged infrastructure to a Chef managed infrastructure. Use audits to ensure nodes fall into existing 'known states' categories, expose unknown issues and report information to Chef analytics for record keeping. As Chef is used to start converging these nodes, audits should be replaced with managed resources.

  2. Infrastructure validations. An example is checking a service alive check after using Chef to perform a service deploy. This information is sent to Chef analytics for reporting and auditing purposes.

New Analytics pipeline

We have added an enhanced Analytics Pipeline which can process a wide variety of events emitted by the Chef server.

Chef Analytics High Level Architecture

Rules

In order to let you respond to events flowing through the pipeline, we have a flexible rules engine. This allows a Analytics user to match on specific conditions occurring in events and carry out a variety of actions including:

  • Sending notifications to SMTP, HTTP webhooks, or Hipchat
  • Creating Alert messages (at various levels of priority) to log exceptional conditions
  • Add tags to the event messages for display and filtering in the web interface and via the command line tools

analytics_rules

New event types

Along with actions, which were available in Chef analytics 1.0, we have added integration with Run Reporting and Chef Client audit controls.

The following message types have been introduced in 1.1.0:

  • run_start – This is sent at the start of each Chef Client run
  • run_converge – This is sent at the end of a Chef Client run and contains summary information about resources that converged during the run.
  • run_resource – This is sent for each resource that converged during a Chef Client run and contains details such as the differences in state and the delta of the resource.
  • run_control_group – This is sent at the end of a Chef Client run and contains summary information about controls that were checked during the run.
  • run_control – This is sent for each control that was checked during a run.

Notifications

We have expanded the destinations you can send notifications to in Chef analytics 1.1, adding a configurable Webhook as well as E-mail notifications. In order to ease integration we have published an example Webhook server which you can extend and modify.

Notifications can be created directly in the web user interface and then references in rules via the notify() function.

Diffs

Users can now view Github-style diffs of Chef actions via the Chef Analytics gui:

analytics_diffs

Release Notes

A web page detailing all the new features in Chef Analytics can be found here.

If you have a support contract and find a bug please open a support ticket. Otherwise, all feedback can be send to analytics@getchef.com or by raising an issue in GitHub in the chef-analytics project.

Changelog

The change log is available here.

1.1.0 (20150121)

  • Actions upgraded to support Diff-View
  • Changed alaska_rules regex operator from ~= to =~ so users don't confuse it with the Ruby/Chef regex operator.
  • audit:info(), audit:warn(), audit:error() rules functions have been renamed to alert:info(), alert:warn(), alert:error()
  • Chef Client control_group message upgraded from 0.1.0 to 0.1.1

1.1.0-rc.4 (20141217)

  • Apache Zookeeper upgraded to 0.9.3
  • Added the --standalonezk flag to enable the use of standalone Zookeeper.

1.1.0-rc.2 (20141125)

  • Added user and password for alaska in rabbitmq
  • Set ip/port for rabbitmq to be the local rabbitmq for all internal communication in standalone mode

1.1.0-rc.1 (20141124)

  • Initial Release Candidate

----

Shared via my feedly reader


Sent from my iPhone

Todd Pigram

Data Center Engineer  

1801 Superior Ave. Ste. 300 | Cleveland, OH  44114

(800) 777-7178 | toll free

(440) 268-3297 | office

(216) 224-5769 | mobile

Architects of the anyplace workspace™

Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)