-
Notifications
You must be signed in to change notification settings - Fork 102
silverware
Cookbooks repeatably express these and other aspects:
- "I launch these daemons: ..."
- "I have a collection of logs at '/var/log/lol'"
- "I have a dashboard at 'http://....:...'"
- ... and much more.
Wouldn't it be nice if announcing a log directory caused...
- my log rotation system to start rotating my logs?
- a 'disk free space' gauge to be added to the monitoring dashboard for that service?
- Flume (or whatever) began picking up my logs and archiving them to a predictable location?
- in the case of standard apache logs, a listener to start counting the rate of requests, 200s, 404s and so forth? Similarly, announcing ports should mean
- the firewall and security groups configure themselves correspondingly
- the monitor system starts regularly pinging the port for uptime and latency
- and pings the interfaces that it should not appear on to ensure the firewall is in place?
Ironfan makes those aspects standardized and predictable, and provides integration and discovery hooks. The key is to make integration inevitable: No more forgetting to rotate or monitor a service, or having a config change over here screw up a dependent system over there.
Attributes are scoped by cookbook and then by component.
- If I declare
announce(:redis), it will look innode[:redis]. - If I declare
announce(:hadoop, :namenode), it will look innode[:hadoop]for cookbook-wide concerns andnode[:hadoop][:namenode]for component-specific concerns. - The cookbook scope is always named for its cookbook. Its attributes live in
node[:cookbook_name]. If everything in the cookbook shares a concern, it sits at cookbook level. So the Hadoop log directory (shared by all its components) is at(scratch_root)/hadoop/log. - If there is only one component, it can be implicitly named for its cookbook. In this case, it is omitted: the component attributes live in
node[:cookbook_name](which is the same as the component name). - If there are multiple components, they will live in
node[:cookbook_name][:component_name](eg[:hadoop][:namenode]or[:flume][:master].
Allow nodes to discover the location for a given service at runtime, adapting when new services register.
- register for a service. A timestamp records the last registry.
- discover all chef nodes that have registered for the given service.
- discover the most recent chef node for that service.
- get the 'public_ip' for a service -- the address that nodes in the larger world should use
- get the 'private_ip' for a service -- the address that nodes on the local subnet / private cloud should use
Nodes register a service by calling announce(<service>[,<component>]), which adds a hash to node[:announces][][], containing 'timestamp' (the time of registry) and other metadata passed in. Nodes discover services by calling discover(<service>[,<component>[,<realm>]]), where realm is the scope of the discovery (the current cluster, by default).
-
default- Base configuration for silverware
Supports platforms: Debian and Ubuntu
-
[:silverware][:conf_dir]- (default: "/etc/silverware") -
[:silverware][:log_dir]- (default: "/var/log/silverware") -
[:silverware][:home_dir]- (default: "/etc/silverware") -
[:silverware][:user]- (default: "root") -
[:users][:root][:primary_group]- (default: "root")
Author:: Philip (flip) Kromer - Infochimps, Inc (coders@infochimps.com) Copyright:: 2011, Philip (flip) Kromer - Infochimps, Inc
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
readme generated by ironfan's cookbook_munger