Adoptable Cookbooks List

Looking for a cookbook to adopt? You can now see a list of cookbooks available for adoption!
List of Adoptable Cookbooks

Supermarket Belongs to the Community

Supermarket belongs to the community. While Chef has the responsibility to keep it running and be stewards of its functionality, what it does and how it works is driven by the community. The chef/supermarket repository will continue to be where development of the Supermarket application takes place. Come be part of shaping the direction of Supermarket by opening issues and pull requests or by joining us on the Chef Mailing List.

Select Badges

Select Supported Platforms

Select Status

RSS

bjn_dsh (4) Versions 1.0.14

Install and configure DSH

Policyfile
Berkshelf
Knife
cookbook 'bjn_dsh', '~> 1.0.14', :supermarket
cookbook 'bjn_dsh', '~> 1.0.14'
knife supermarket install bjn_dsh
knife supermarket download bjn_dsh
README
Dependencies
Quality 17%

bjn_dsh Version

Installs and configures DSH. Uses Chef search to generate configuration.

Requirements

This cookbook depends only on magic. The following platforms are officially
supported:

  • Ubuntu 12.04
  • Ubuntu 14.04

Attributes

Attributes are documented inline, so check out attributes/default.rb for the
final word, but the basic idea with this cookbook is we can map each node's Chef
environment and role names onto DSH group names.

The mapping is configured with attributes:

# See attributes/default.rb for more docs
default['dsh']['mappings']['environments'] = {
  'example' => true, # Default will use the environment for the group name
  'example-dev' => 'dev' # Or you can override with a new group name
}

# The keys here are actually partial matches against role names
default['dsh']['mappings']['roles'] = {
  'app' => 'app',
  'db' => 'db',
  'rails' => 'web',
  'django' => 'web'
}

With the settings above, if you have a node in the example-dev environment
with roles like app-mage, app-shaman, you'd get dev and app as your DSH
groups. Notice only the roles and environments we've explicitly mapped show up
in the groups. No surprises!

In reality, we might like the groups to be dev and app-dev to distinguish
the app group for the example environment. For this we have a suffixes (and,
similarly, prefixes):

# Add suffixes to nodes with the specified groups (group -> suffix)
# N.B. Does not add the suffix to the indicated group!
default['dsh']['mappings']['suffixes'] = {
  'dev' => '-dev'
}

With the suffix settings, our hypothetical node now gets dev and app-dev. A
similar node in the example environment would get example and app.

We can also form groups based on groups, which we call aggregates:

# Aggregate DSH groups into larger collections (group -> [group])
# N.B. Executed before prefixes and suffixes are added
default['dsh']['mappings']['aggregates'] = {
  'backend' => %w[ app db ],
  'frontend' => %w[ web ]
}

With these aggregates, our node would get dev, app-dev, and backend-dev.

The cookbook also lets you set a user and override it depending on existing
group member ship (for more complicated setups):

# Set a user for DSH hosts (none by default)
default['dsh']['mappings']['user_name'] = nil # e.g. "ubuntu"

# Shim to override user for DSH hosts in given groups
default['dsh']['mappings']['shim_user_name'] = {
  'aws' => 'ubuntu'
}

Libraries

The DSH module in the default library defines dsh_groups_from_search, which
can be used as a kind of primitive for building your own DSH coookbook. This
function takes a DSH configuration (by default provided by node.dsh) and
returns a Hash mapping DSH groups to hosts:

# Suppose the following:
# Node   Environment  Roles
# node1  example      some-db,etc
# node2  example      some-web,etc

dsh_groups_from_search \
  'environments' => {
    'example' => true
  },
  'roles' => {
    'db' => 'db',
    'web' => 'web'
  },
  'aggregates' => {
    'backend' => %w[ db ],
    'frontend' => %w[ web ]
  },
  'prefixes' => {},
  'suffixes' => {},
  'user_name' => 'user1',
  'shim_user_name' => {
    'frontend' => 'user2'
  }
#
# => {
#   'example' => [
#     'user1@node1',
#     'user2@node2'
#   ],
#   'db' => [
#     'user1@node1'
#   ],
#   'web' => [
#     'user2@node2'
#   ]
#   'backend' => [
#     'user1@node1'
#   ],
#   'frontend' => [
#     'user2@node2'
#   ]
# }
#

Recipes

This cookbook contains only a default recipe, which manages DSH.

Dependent cookbooks

magic >= 0.0.0
partial_search >= 0.0.0

Contingent cookbooks

There are no cookbooks that are contingent upon this one.

Collaborator Number Metric
            

1.0.14 failed this metric

Failure: Cookbook has 0 collaborators. A cookbook must have at least 2 collaborators to pass this metric.

Contributing File Metric
            

1.0.14 failed this metric

Failure: To pass this metric, your cookbook metadata must include a source url, the source url must be in the form of https://github.com/user/repo, and your repo must contain a CONTRIBUTING.md file

Foodcritic Metric
            

1.0.14 failed this metric

FC064: Ensure issues_url is set in metadata: bjn_dsh/metadata.rb:1
FC065: Ensure source_url is set in metadata: bjn_dsh/metadata.rb:1
FC066: Ensure chef_version is set in metadata: bjn_dsh/metadata.rb:1
FC070: Ensure supports metadata defines valid platforms: bjn_dsh/metadata.rb:1
Run with Foodcritic Version 16.3.0 with tags metadata,correctness ~FC031 ~FC045 and failure tags any

No Binaries Metric
            

1.0.14 passed this metric

Testing File Metric
            

1.0.14 failed this metric

Failure: To pass this metric, your cookbook metadata must include a source url, the source url must be in the form of https://github.com/user/repo, and your repo must contain a TESTING.md file

Version Tag Metric
            

1.0.14 failed this metric

Failure: To pass this metric, your cookbook metadata must include a source url, the source url must be in the form of https://github.com/user/repo, and your repo must include a tag that matches this cookbook version number