Puppet Blog - Page 4Culture

Bridging the Two Worlds: IT and Networking

Jeremy Schulman, Global Solutions Architect at Juniper Networks, is responsible for developing the Puppet for Junos OS netdev module. This post originally appeared on his blog on the Juniper Networks website on April 2, 2013. It has been reprinted with permission.

The role of Junos technology is to address the problems of today’s networks in a way that is aligned with broader challenges facing IT infrastructure automation as a whole. We all know that managing networks is complex, hard, costly, and requires highly trained engineers. This post is going to talk about managing networks in a whole new way. The concepts in it will change your life. They changed mine.

There is no doubt that something big is happening. Our industry is going through a paradigm shift. Everyone is excited about the idea of “programming” the network. People want to build network solutions independent of hardware vendors; to use open APIs, open software, to collaborate, and to innovate. But most importantly, they need to deliver a network focused on the needs of the consumer of the network. A similar paradigm shift happened a while ago for the IT system administrators (sysadmins) and DevOps – you know, the guys in the data center deploying all those servers or virtual machines driving the need for more networking. As we look forward to how the networking industry may evolve let’s take a quick look back at the history of the sysadmins.

At one point, sysadmins were manually deploying servers, configuring services, and managing the installation of applications – applications that ultimately drive their business. These sysadmins may have had some simple Bash- or Perl- based scripting tools they created themselves, but it was largely ad-hoc. Fast forward to today: sysadmins now use sophisticated configuration management products like Puppet or Chef to fully automate large-scale data center deployments. They write programs to “glue” together these tools with APIs from other vendors like VMware, Amazon, Google, or from other software they download from the open source community. These sysadmins, who were not formally trained software engineers, picked up new programming skills and began focusing on automation as a key business driver, and as a personal asset. They use open APIs and open software. They collaborate. They innovate. They are driving the success of their business. They can (and will) become key influencers in deciding which vendor is deployed in the network.

Puppet and Junos: What’s this Networking Automation Solution All About?

A few weeks ago, I had the honor of co-presenting at the Bay Area Juniper Users Group (BAJUG), which meets once a quarter in Sunnyvale, CA. Jeremy Schulman from Juniper Networks invited me to co-present with him on the Puppet for Junos OS solution, which became available in February. Haven’t heard about this networking automation solution before this blog? I’ll explain more, but first, I want to briefly summarize my experience at BAJUG.

I really loved the format of the user group. It kicked off with a one-hour keynote presentation from Jeremy on the Puppet for Junos OS solution, which was followed by a series of 10-minute lightning talks. Those talks were given by network guys from Facebook, IETF, Zygna, and more. The event ended with a free-form social. It was a sold out event, attended by about 250 people. Here’s a photograph I took right before my talk.

Secure Puppet Code Collaboration

Did you know that you can use workflow and testing to ensure you get the configurations you asked for in a secure manner? In this post, we discuss how.

Puppet compiles a catalog using Puppet DSL code and data that’s usually at rest on the local filesystem of the puppet master. An agent requests a catalog from a master, and subsequently enforces the catalog locally. It’s common for multiple teams to collaborate on the configuration code and data, with the different teams being responsible for different modules. Often times, this means that the Puppet module path is actually made up of two or more module paths, where each modulepath entry is a different version control system repository managed by a different team.

  modulepath = /data/puppet/core/modules:/data/puppet/webapps/modules

I will have a manifest (maybe an ENC too, but let’s just talk about manifests here):

  manifest = /data/puppet/manifests/site.pp

I am more likely to have my core security modules in the first part of my module path. Potentially I *could* have a class security {..} in both halves of my module path; however, the module found first by the autoloader will take precedence, and the module in the web apps part of the path won’t be evaluated. It’s important to get the configurations that you want in first, especially because there’s no hard and fast rule that will restrict resource definitions for security configurations to that security module. Any resource declaration might be in any module, subject to uniqueness constraints, and so forth.

Thus, my security class manages a resource:

   user { 'root': 
    password => 'myspecialpasswordhash',
  } 

If another class attempts to manage the same resource, Puppet will return a catalog compilation error, and no configurations will be managed. This is good. My root user won’t get hosed by a rogue configuration. However, there’s a twist to this story. What if my manifest (site.pp) declares another class ‘configurethewebserver‘? That class is defined in the the second half of my module path (which is where the modules that deploy my applications live, as opposed to the core standard operating environment), and gets declared, quite legitimately, in a node definition in the site manifest.

Introducing the Latest VMware and Puppet Labs Integration

Nan Liu is Senior Systems Engineer at VMware. 

Disclaimer: This is a repost from Nan’s personal blog. The opinions expressed herein are Nan’s personal opinions and do not necessarily represent those of VMware.

Last week, we released a set of open source Puppet modules for managing VMware cloud environments, specifically VMware vCenter Server Appliance 5.1 and VMware vCloud Network and Security 5.1 (vCNS, previously known as vShield). They provide a framework for managing resources within vCenter and vCNS via Puppet (read Nick Weaver’s blog for more information).

puppet_device

Puppet Around The World: Opening Offices in London, Australia, and San Francisco

2012 was a huge year for us—we more than doubled in size, tripled our PuppetConf attendance, and saw overwhelming demand for and consumption of all things Puppet (Puppet Enterprise, Puppet Forge modules, Puppet Camps, and more). We’re only three months in to 2013, but we predict another stellar year. Bolstered by VMware’s recent $30 million investment, we opened offices in London, Australia, and San Francisco to build awesome new products for our growing customer-base. We also tripled the office space of our headquarters in Portland, OR, and we’re hiring like crazy!

Module of the Week: java_ks – Build Java Keystores From Existing Keys and Certificates

Purpose Build Java keystores form existing keys and certificates.
Module puppet/java_ks
Puppet Version 2.7+
Platforms OpenJDK 6, OpenJDK 7

This module attempts to ease and shorten the workflow associated with Java applications.

  • When building a Java keystore outside of the Java tool chain, you have to go through a process that spans a couple different tools and intermediary formats before you have a valid keystore. The java_ks module attempts to relieve this by giving you one interface: Puppet. Puppet handles the conversion and intermediary formats for you.
  • This module contains no manifests, only a composite namevar type and its supporting provider.
  • This module allows for keystores to be provisioned along with your Puppet deployed Java application servers.

The reason this module came to life was my frustration over the workflow needed to get a SSL protected ActiveMQ broker set up. When I wanted to integrate the Java keystore build workflow into the rest of ActiveMQ’s setup using a Puppet manifest… well, it got ugly. Converting a string of shell commands into Puppet exec resources eventually led me to a dark dark place. Personally I find that if you are running into a need for a lot of exec resources, especially when they are using the same command or operating on the same file, it is time to grab a copy of Puppet Types and Providers and get your hands dirty with some Ruby. You’ll usually notice a speed increase of your agent runs after a conversion to a type/provider to replace all the exec resources and always end up with easier to maintain manifests.

The Fact Is…

One of the major interfaces to extend functionality with Puppet is the use of Facter and custom facts. A fact is a key/value data pair that represents some aspect of node state, such as its IP address, uptime, operating system, or whether it’s a virtual machine. Custom facts are able to provide catalog compile time data to the puppet master to customise the configurations for a specific node (using PuppetDB, this data becomes available even when you’re doing things elsewhere). Facts are provided by Facter, an independent, cross-platform Ruby library designed to gather information on all the nodes you will be managing with Puppet.

For an example of using a custom fact within Puppet, you can use this data in the context of a catalog compile to make a decision about the catalog that you sent back to the node. A fact that tells us the node’s operating system could cause some conditional logic in a class that tells the node the right set of packages to use to configure ntp on that particular system. Because the package names differ between Linuxes (let alone between Linux and Windows), this fact simplifies ntp configuration. Alternatively, you could use the $::ipaddress fact to customise the appropriate listen directive in Apache or SSH.

Puppet sites use proprietary and third-party cookies. By using our sites, you agree to our cookie policy.