Puppet Labs Blog

I'm going to comment solely on the adoption of Dev Ops, which I personally consider to include change management, incident management, deployment, monitoring, metrics, and file distribution.

I believe that the barrier to adopting solid Dev Ops practices is so low that for most startups, adopting them early is a smart move. Sure, today, your startup doesn't need to use Puppet or Chef to ensure that all of your servers (whether they're VMs or baremetal) are running the same pieces of software with the same configuration files, because manually installing those is easy. Once those same VMs have had features X, Y, and Z added to them, and files have been changed over and over, and then all of a sudden, you need more servers because your startup has been featured on Hacker News, you're probably going to need to re-invent the wheel and figure out all of those steps that you've done to your initial servers. Puppet and Chef make consistency across your entire environment possible, and getting them up and running is not difficult. Puppet (and probably Chef, although I'm not Chef fluent) can be run in serverless mode, if desired, too, which makes the installation and use even easier.

If you manually manipulate your servers now, you're going to need to automate later. You might as well spend a little time creating your "Dev Ops way" now, so that when tomorrow comes, you'll be spooling up identical servers that are monitored and have metrics coming out of them, you won't break a…

I know it's kind of tangential, but one of the MASSIVE benefits of using EC2 and clouds for hosting is the simplicity of provisioning new machines when problems occur (nodes dying, high traffic, etc.).

One attitude to take when using Infrastructure as a Service (IaaS) is to always expect failure - nodes can easily disappear when a problem occurs and take out your entire website.

The best backup plan you can have for this is to capture the entire configuration of your stack in some version controlled way. One of the tools I use for this falls under the domain of "configuration management", with the best products being Chef[1] or Puppet[2], or just writing a normal bash script that installs your Rails stack and checks out your code from github.

When utilizing these technologies, I usually do the following:

1. Create a virtual image that has your CM tools + dependencies installed on it.
2. Add a bootstrap script that runs at boot (usually /etc/rc.local on Linux). This script will acquire and parse user-data[3] that is provided in the provisioning request to EC2[4], an then kick off your main configuration logic.
3. Capture the image and use it as your base image that you perform deployments from.

Feel free to let me know if you have any questions with this method! It's a bit overkill at the learning phases of IaaS clouds and OS administration, but it will save you a TON of time down the road as a programmer.

[1] Chef: http://www.opscode.com/chef/
[2] Puppet:…

I'm a little sad because most of these issues (as I understand your description them) are already fixed or well underway :( It's probably too late for your specific case but I'd like to reply anyway since a lot of this is "conventional wisdom" based on old information. Full disclosure: I'm the product owner for Puppet and before I worked here, I ran it in large-scale production since 2008.

Not quite sure what you mean by 'native support', but gem and pip package providers are built-in. there are high-quality modules for git (puppetlabs-vcsrepo), virtualenv (stankevich-python), npm (puppetlabs-nodejs), etc -- it's a design decision to move much of this into modules and out of core so they can iterate faster.

Totally agree that loops make many language constructs much easier, and there's looping in the rewritten parser -- https://docs.puppetlabs.com/puppet/3.6/reference/experiments_lambdas.html -- which will be on by default in the next semver major.

While the model definitely wants you to describe relationships between resources if you need to send subscribe/refresh messages, there's toggle-able ordering algorithms that will let you run them in manifest order -- I blogged about it here: http://puppetlabs.com/blog/introducing-manifest-ordered-resources

The parser and evaluator are undergoing a total rewrite to be an expression based grammar, which is explicitly to make better definition around the language and eliminate the gotchas --…

Puppet Labs is trying to rock the DevOps/Sysadmin world with our model-driven approach to config management.

We're based in Portland, OR, and aren't looking for remote workers as yet.

We're looking for both Core Developers and Pro Services Engineers, and no matter what, you'll be working with open source software and a highly engaged user community, as well as on a project that is included in most of the major *nix distributions in one way or another.

Puppet itself is written entirely in Ruby, so strong experience in Ruby is great, but experience in an equivalently flexible language is fine too.

We've recently moved into our new offices:
http://twitpic.com/3ckay1
http://twitpic.com/3cksg3
(things are more organized than that now :)

Portland is freaking awesome.

I moved up here recently after working for Google in the Bay Area, and I couldn't be happier. Cheap rent, amazing food and beer, huge bike culture and a city full of incredibly friendly and nice people.

http://www.puppetlabs.com/company/jobs/

Puppet Labs in Portland, OR, is hiring for several new positions on our Technical Operations team:
* Support Engineer - Linux/Unix SysAdmin background preferred
* Technical Writer - 3+ years experience required
* Technical Training Manager - 10+ years experience in technical training management role with experience training IT professionals in Linux/Unix based programs

We are also hiring an Intern for our Release Engineering team for a 16 week paid assignment.

In addition, we're always looking for strong Professional Services Engineers and Software Developers as our team continues to grow in 2012. Note: Senior PSEs can be based out of remote offices anywhere in the US, not just Portland.

For more information on these positions and to apply online, please go to http://www.puppetlabs.com/jobs.

Thanks!
Aimee Fahey
Talent Acquisition Manager
Puppet Labs

2cents about this:

1. If you are setting up Sentinel with puppet you can do audit of a file instead of modifying it on every run http://puppetlabs.com/blog/all-about-auditing-with-puppet this way you can install, configure and start sentinel and puppet will notice that the content changed. You can decide if you want to change the file or if you would like puppet to notice about it.

2. About sentinel, don't know how you are triggering the failover but we discovered a bug on versions prior to 2.8.12 on manual failovers, https://groups.google.com/forum/#!searchin/redis-db/rhommel/redis-db/OvkSDZj4V6k/bSw4YC63VsUJ so it was fixed in 2.8.12 and never seen redis taking more than a second.