Puppet Blog - Page 49

In the wake of recent events on the East Coast of the United States, disaster recovery (DR) planning has reared its head again. Of course, it’s a bad time to think about disaster recovery right after an event with such a large impact. However, it’s even worse to never think about it.

Prior to working at Puppet Labs, I spent a lot of time on disaster recovery. For nearly two years, I led a team designing multi-site replication, creating reference architectures for availability and recovery, and selling our business partners on disaster recovery investments. This was for one of the top performing business units at a Fortune 100 company with seven and eight figure budgets for DR.

Disaster recovery is a huge proposition. It’s costly, time consuming, difficult to test correctly and often the first thing cut when doing budget reviews. DR planning is also never complete. You evolve. You change. Your plans need to as well.

The starting points for DR planning can be difficult to find. Infrastructure engineers often jump to technical solutions. Before you figure out the newest wizbang in storage replication technologies and failover, take a step back.

The International Securities Exchange (ISE), a leading US options exchange, has just completed the first phase of its Puppet Enterprise deployment. For a company exceeding trading volumes of 2.5 million contracts per DAY, the decision to ‘puppetize’ their infrastructure not at random — it was carefully determined and deliberate. Trevor Pott, reporter from The Register, […]

Hi, I’m Eric Sorenson (eric0 on #puppet IRC), and in June 2012 I moved from being a community member and Puppet administrator in the field, to working at Puppet Labs as the Product Owner for our open source projects. At the time, my first goal was to help get a great release of the next major version of Puppet (code-named “Telly”) shipped to the world, which launched late last month. Now with the release of Puppet 3.0.1 — which addressed and fixed the biggest issues that our awesome community of early-adopters found in the 3.0.0 release — it seemed like a good time to blog from the rooftops.

I’m new to Puppet Labs, but I have been running Puppet in large-scale production operations since 2009 and, somewhat naïvely, felt like I had a good idea of what Puppet 3 was supposed to look like. There had been, after all, a few dozen bugs in Redmine over the past couple of years in which the “Target Release” field I’d seen James or Nigel set to “Telly” … it was going to fix all the bad behavior we’d all reported over the years, right? Well, not exactly.

The tough thing about major releases of popular products is that the burden of expectations becomes so great, there’s no way reality can measure up. In some cases (The Phantom Menace, Guns n’ Roses “Chinese Democracy”) when the release does come, it’s universally panned on its own merits; other times, the release might have been fantastic if it had come when it was promised, but the timing was such that it had already gone stale (Duke Nukem Forever).

Puppet and Puppet Enterprise come with a basic file server, allowing agents to fetch files from the master. This capability is suitable for small files, but when used with large binaries it can cause performance issues on the master.

S3file provides a simple Puppet type to fetch and update files stored in an Amazon S3 bucket or in your private OpenStack Swift storage environment. This allows you to store large files outside of Puppet, while still keeping the resource model provided by the existing Puppet file types.

S3file is written to be compatible with the old Puppet 2.7 as well as the latest Puppet 3.0, making it easy to integrate with any Puppet deployment.

Module of the Week: puppetlabs/puppetdb – PuppetDB Management – Install and manage the PuppetDB server and database, and configure the Puppet master to use PuppetDB

Puppet Enterprise can be used to do anything from automating repetitive tasks to managing large, complex infrastructure, but it can also solve real problems in small doses. We’ve compiled a list of awesome things that you can do—or do better, faster, stronger—with 10 nodes or less of Puppet Enterprise.

A wiki is a very popular way to share information within an organization as well as with the general public. Organizations and individual users who share information using a wiki often need to separate unrelated topics into distinct domains. Although most wiki software such as MediaWiki does not allow for this separation into isolated spaces by design, it is possible to achieve it via multitenancy. In the context of MediaWiki deployment, multitenancy means configuring multiple distinct wiki instances to use the same wiki installation. The objective of this module is to automate the process of Mediawiki installation and allow system administrators to get multiple instances of MediaWiki up and running very easily and quickly.

We’re always looking to add awesome Puppet modules to the Puppet Forge. We often get requests for modules for stuff we aren’t working on, but we know there are community members with tons of experience, or private modules covering the material. We’re launching a contest to get these modules polished and published on the Puppet Forge. In short, we’re hoping to generate interest in a few of our favorite tools.

Rules of the Contest

A huge thank you to everyone who submitted—the SysAdmin Day animated gif contest was extremely close, so much so that we had to hold a run-off voting session. But, finally, we have winners!

Module of the Week: stahnma/epel – Add EPEL to your EL systems

My name is Mateusz Lenik, I study at Technical University in Wrocław, Poland. For the past two months, I’ve been working on expanding features of the Ruby DSL for Puppet. I’m a Ruby programmer and I was looking for Google Summer of Code projects in Ruby, which is how I came to Puppet Labs. My […]