cookbook 'bjn_dsh', '= 1.0.11'
bjn_dsh (4) Versions 1.0.11 Follow0
Install and configure DSH
cookbook 'bjn_dsh', '= 1.0.11', :supermarket
knife supermarket install bjn_dsh
knife supermarket download bjn_dsh
bjn_dsh
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.
