I’d like to cover some information about how you can test puppet modules. I’ve seen a lot of companies creating puppet modules and testing them via direct deployments onto machines. Or worst yet making changes to manifests without any testing at all. The world of puppet testing can seem quite daunting but with the following paragraphs I hope to show you that you can make some very small changes to how you develop puppet modules that will hopefully save you from some very bad situations.
In a previous post I wrote about how we can use Auto-Scaling Groups (ASG’s) to quickly adapt to user load. In this post I intend to explain a method to create custom Amazon Machine Image’s (AMI’s) using a project called packer.io
what is packer? Packer is an open source tool for creating identical machine images for multiple platforms from a single source configuration. Packer is lightweight, runs on every major operating system and is able to create machine images for multiple platforms in parallel.
The following explains how I utilize Auto Scaling Group’s (ASG’s) and puppet to automatically expand clusters during high load.
asg Auto Scaling allows you to scale your Amazon EC2 capacity up or down automatically according to conditions you define. With Auto Scaling, you can ensure that the number of Amazon EC2 instances you’re using increases seamlessly during demand spikes to maintain performance, and decreases automatically during demand lulls to minimize costs.
/images/razor_overview.jpg
Most system administrators prefer to use an automated installation method to install Linux on their machines. To satisfy this need different distributions of Linux have created a number of methods (kickstart, preseed etc). This offers the advantage of allowing a single file solution that contains logic ordered questions that are asked during a typical installation.
Razor is a next-generation hardware provisioning solution developed by Puppet Labs in collaboration with EMC.
