Entries filed under: Services

Back to Index

Managing F5 BIG-IP Network Devices with Puppet

Posted on
By
Nan Liu
in
Blog, Community, DevOps, Extending Puppet, How to, Modules, Open Source, Puppet Enterprise, Services, Tips
Responses
4 Comments »

Management of network devices is one of the exciting new features in Puppet Enterprise 2.0 and Puppet 2.7. In the initial release, support is limited to Cisco devices, but because Puppet is extensible via modules, we are able to build upon the existing framework and add support for F5 BIG-IP. Like most network appliances, installation of third party software is prohibited, which eliminates the ability to run an agent. Instead, Puppet takes advantage of F5 iControl API to interact and manage the device. F5 BIG-IP network appliances are capable of load balancing, SSL offloading, application monitoring, as well as many other advanced features, and now Puppet can manage these functionalities. Compared to traditional management methodologies and other third party tools that interact with F5, Puppet not only bridges the gap from deploying applications to bringing the service online to your customers, it also brings the unique benefit of the Puppet resource model to network devices. More specifically, the integration offers the ability to compare if a running configuration matches the desired configuration, and then enforce the changes once they’ve been reviewed.

In this blog post, we will step through the process of installing the F5 module, configuring connectivity, and writing a simple manifest to manage an F5 device with Puppet. If you are unfamiliar with BIG-IP devices, you may want to consult devcentral.f5.com for more information on F5 features such as iRules and iControl API.

In the following output, Puppet detects that the F5 device has the wrong iRule. We are running in simulation mode (--noop option) so Puppet only shows the changes that would be applied if we were enforcing the configuration.

$ puppet device --noop
...
notice: /Stage[main]//F5_rule[redirect_404]/definition: current_value: when HTTP_RESPONSE {
if { [HTTP::status] eq "404" } {
redirect to "http://www.puppetlabs.com/404/"
}
}, should be when HTTP_RESPONSE {
if { [HTTP::status] eq "404" } {
redirect to "http://www.puppetlabs.com/redirect/404/"
}
} (noop)
notice: Finished catalog run in 5.69 seconds

Now running Puppet with out the --noop option set, the iRules are changed to match our resource declaration.

$ puppet device
…
notice: /Stage[main]//F5_rule[redirect_404]/definition: definition changed when HTTP_RESPONSE {
if { [HTTP::status] eq "404" } {
redirect to "http://www.puppetlabs.com/404/"
}
}, to when HTTP_RESPONSE {
if { [HTTP::status] eq "404" } {
redirect to "http://www.puppetlabs.com/redirect/404/"
}
}
notice: Finished catalog run in 5.74 seconds

In addition to iRules, the initial release supports key features to configure the device certificate, manage applications pool/poolmember/virtualserver, and monitor application health. The module is published on the Puppet Forge, along with comprehensive documentation of supported F5 resources. The latest development release is available on GitHub. The ability to extend Puppet is not limited to network devices, and the commands shown later in this post to install the module is applicable for other Puppet modules available on the Puppet Forge and GitHub.

The puppet device command is a new application mode in Puppet intended to manage devices that can’t install Ruby/Puppet and run puppet agent. If you haven’t checked it out yet, I would review Brice’s introduction to network devices first. The high level overview of the entire communication process:

Devices are managed through an intermediate proxy system where Puppet agent is installed. The proxy system stores a certificate on behalf of the device. In the case of F5, it should have iControl gem installed, as well as the account information in device.conf to communicate with the device. The proxy connects to the Puppet master to retrieve the catalog on behalf of the F5 and applies changes as necessary.

F5 module installation

Before we get started with the installation process, there are two ways to install F5 module. First, via puppet-module tool which retrieves it from forge.puppetlabs.com (for stable releases of the module). The latest development release from GitHub is accessible via git. The instructions below are specific for Puppet Enterprise, but open source users can also install the module with some changes to the puppet module path. Puppet Enterprise currently ships with the puppet-module gem, and it’s freely available on rubygems.org. Eventually this will become a Puppet Face and turn into the command ‘puppet module’(expected in later release of 2.7). Onwards to the install process:

# Puppet Enterprise:
cd /etc/puppetlabs/puppet/modules
puppet-module install puppetlabs-f5

This should create a directory called f5. Older versions of puppet-module tool might create a puppetlabs-f5 directory in the modules directory—in that case, change it to f5.

Installing from GitHub:

# Puppet Enterprise:
cd /etc/puppetlabs/puppet/modules
git clone git@github.com:puppetlabs/puppetlabs-f5.git
ln -s puppetlabs-f5 f5

In Puppet 2.7, the transport between proxy agent and device supports telnet/ssh, however neither is suitable for F5 devices. Instead, we rely on F5’s iControl API. The iControl gem should be installed on both the master and the proxy system. This gem is available in the F5 module files directory.

# Puppet Enterprise:
/opt/puppet/bin/gem install /etc/puppetlabs/puppet/modules/f5/files/f5-icontrol-10.2.0.2.gem

Configuration and management

At this point we have the module installed, so we should configure connectivity for the device. The configuration for network devices by default are stored in /etc/puppet/device.conf:

[f5.puppetlabs.lan]
type f5
url https://username:password@f5.puppetlabs.lan/partition
[f5.dev.puppetlabs.lan]
type f5
url https://username:password@f5.dev.puppetlabs.lan/partition

You can also break down each device into it’s own configuration file such as /etc/puppet/f5_device1.conf, /etc/puppet/f5_device2.conf …, which is especially helpful if you wish to run against each device separately. In the square brackets is the device certificate name, and certificate management process is the same as puppet agent certs. The device type is f5, and the url is https instead of telnet/ssh. Because F5 supports different partitions we can optionally specify them at the end, and it will default to the ‘Common’ partition if it’s not provided. In the module, f5::config define resource type simplifies management of this configuration file on the proxy system:

f5::config { 'f5.puppetlabs.lan':
    username => 'admin',
    password => 'password',
    url      => 'f5.puppetlabs.lan',
    target   => '/etc/puppetlabs/puppet/device/f5.puppetlabs.lan.conf',
}

Once this configuration file is in place, we can initiate a puppet device run on the proxy server.

# execute on proxy server
$ puppet device --deviceconf /etc/puppetlabs/puppet/device/f5.puppetlabs.lan.conf

This should generate a certificate request on the master which should be signed:

# execute on puppet master
$ puppet cert -l
f5.puppetlabs.lan (2A:0C:A0:F8:C6:EE:EF:9B:B3:49:74:D1:27:31:1B:60)
$ puppet cert -s f5.puppetlabs.lan

At this point the master should have a node name f5.puppetlabs.lan in site.pp with the appropriate f5 resources:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
node f5.puppetlabs.lan {
  f5_rule { 'redirect_404':
    ensure     => 'present',
    definition => 'when HTTP_RESPONSE {
if { [HTTP::status] eq "404" } {
redirect to "http://www.puppetlabs.com/redirect/404"
}
}',
  }
 
  f5_pool { 'webapp':
    ensure                          => 'present',
    action_on_service_down          => 'SERVICE_DOWN_ACTION_NONE',
    allow_nat_state                 => 'STATE_ENABLED',
    allow_snat_state                => 'STATE_ENABLED',
    lb_method                       => 'LB_METHOD_ROUND_ROBIN',
    member                          => {
      '10.10.0.1:80' => {'connection_limit' => '0',
                         'dynamic_ratio'    => '1',
                         'priority'         => '0',
                         'ratio'            => '1'},
      '10.10.0.2:80' => {'connection_limit' => '0', 
                         'dynamic_ratio'    => '1', 
                         'priority'         => '0',
                         'ratio'            => '1'},
      '10.10.0.3:80' => {'connection_limit' => '0',
                         'dynamic_ratio'    => '1',
                         'priority'         => '0',
                         'ratio'            => '1'}
    },
    minimum_active_member           => '1',
    minimum_up_member               => '0',
  }
}

When the puppet device command is executed again this will update the iRule and ensure the appropriate members are in the webapp pool:

$ puppet device --deviceconf /etc/puppetlabs/puppet/device/f5.puppetlabs.lan.conf

A limitation to watch out for in the current Puppet release is that ‘puppet apply’ and ‘puppet resource’ cannot modify network resources. However, we implemented a feature to allow puppet resource to query a F5 device. (For authors of types/providers, making changes to resources aren’t supported until apply_to_device in resources type are handled differently by puppet apply/resource commands). For now we use url facts to establish connectivity to specific F5 devices:

export RUBYLIB=/etc/puppetlabs/puppet/modules/f5/lib/
export FACTER_url=https://admin:password@f5.puppetlabs.lan/Common
puppet resource f5_rule
f5_rule { '_sys_https_redirect':
  ensure     => 'present',
  definition => '    when HTTP_REQUEST {
set host [HTTP::host]
HTTP::respond 302 Location "https://$host/"
}',
}
f5_rule { '_sys_auth_ssl_cc_ldap':
  ensure     => 'present',
  definition => '    when CLIENT_ACCEPTED {
set tmm_auth_ssl_cc_ldap_sid 0
set tmm_auth_ssl_cc_ldap_done 0
}
when CLIENTSSL_CLIENTCERT {
…

If you don’t have Puppet Enterprise 2.0 in your environment yet, you can either download the Learning Puppet VM, or Puppet Enterprise installation packages. F5 also provides F5 LTM Virtual Edition (VE) for trial on VMWare. Please report any issues or bugs to http://projects.puppetlabs.com/projects/modules/issues under the modules section.

Additional Resources

A Question of Style

Posted on
By
James Turnbull
in
Blog, Community, How to, Services, Systems Management, Tips
Responses
0 Comments

One of the most common questions from the Puppet community is, “What’s the best way to write a module/class/resource? What style does Puppet Labs use when they write manifests?” So internally we all got together and decided to write the definitive Puppet Style Guide. To do this we gathered the experience from the Professional Services, Operations, and Product teams and hashed out our individual styles, preferences, and ideas into a single document. (This sounds much more professional than it actually was… in reality, we locked the teams in a conference room with spiked clubs and let them have at it, Thunderdome-style. Many styles enter. One style leaves.)

The new style guide covers visual style and form as well as approaches for creating resources, classes and modules. It also includes advice on best practices and useful tips and tricks. The guide is primarily aimed at people using Puppet 2.6.x and later—although the guide describes some solutions and techniques that rely on new syntax introduced in the 2.6.0 release, it also has material that is relevant to people using earlier releases of Puppet.

Our Style Guide is a work in progress and we’ll be updating it as new features and syntax are added or as changes are made to how Puppet operates. We’ll also be using the Style Guide when updating and adding new modules to the Puppet Forge so you’ll be able to see the new styles reflected in modules we release and maintain.

If you have feedback or suggestions we’d love to hear from you about it, or you can log a ticket here.

Why Do I Need Puppet Training?

Posted on
By
jose
in
Blog, Community, Conferences and Workshops, General News, Services, Training
Responses
0 Comments

Attending the Puppet Master training course is an investment in time and resources with an immediate return. The information you will learn will give you the ability to deploy puppet and begin automating your infrastructure quickly and with confidence. This article describes the information covered in the Puppet Master training course, the experience and expertise of the instructors, and the specific benefits we provide to help you get more work done in a shorter time.

Basics

The goal of training is to give you are comprehensive review of Puppet’s features and potential. Puppet Master training is a mix of lecture and labs designed to prepare new members of an organization already using Puppet, and to empower experienced sysadmins wanting to get the most from Puppet by learning the advanced features. During the 3-day class attendees will learn how to configure Puppet and a Puppetmaster, they will learn different resource types, and will learn how to define virtual and exported resources, meta-parameters, dependencies, and events. Puppet Labs uses the exact same curriculum as part of its new employee orientation and often sends new employees to public trainings. At the end of training an attendee will have the knowledge they need to use Puppet to tackle difficult problems quickly.

Several members of Solbright Operations team attended Puppet training in New York this year. We are happy to report that we realized excellent value, and readily recommend the experience to shops considering,
implementing, or already running Puppet. Training is ran by hands-on experts who are deeply involved in the ongoing development of Puppet, and have implemented Puppet-based solutions for environments across the world. Sessions are structured to ensure key concepts are thoroughly explained and hammered home with well-designed hands-on labs. Presentations and handouts are of excellent quality and are kept in sync with the evolution of Puppet software.

Alex Fomin, Technical Operations Manager, Solbright Inc.

Teaching Philosophy

Our courses are designed to be hands on learning experiences. Attendees aren’t just lectured at, they are engaged. Our class sizes hover around 12-14 people but often times are hosted with as few as 5 and all classes are capped at 20. Often times our Sales and Professional Services teams are in the same area as our trainings and will drop in to talk with students during lunch. At a recent training in the bay area 7 Puppet Labs employees were present at lunch. During training students are able to engage 1:1 with Puppet Labs Staff. They are able to ask questions and can learn how to use Puppet to solve the specific issues ailing their organization.

Cost & Take Away

During the training students receive a light breakfast, lunch, and usually a slew of snacks in addition to instruction. Students also receive a copy of the Puppet Labs Training Slides, are invited to join the Puppet Master LinkedIn network, and a Puppet Labs T-shirt. The fee for each student is usually set at $2,395 but an $200 Early Bird Discount is offered for students registering at least 2 weeks in advance. Private training, along with a variety of other servies are also available.

We’re happy to announce dates for January, February, and March:

  • DC Area: Jan 11-13
  • Boston Area: Jan 31-3
  • Austin Area: Feb 15-17
  • Bay Area: Mar 1-3
  • Singapore: Mar 15-17
  • Australia: Mar 22-24

    See our full training schedule for more information.

    Puppet training gave me a great foundation for using Puppet in our environment. We have been able to use the best practices that I learned to effectively leverage Puppet.

    Paul Nguyen, Genentech

    See what others are saying

    Meet our Professional Services Team

    Dan Bode

    Jeff McCune

    Cody Herriges

    Nan Liu

    Hunter Haugen

    Garrett Honeycutt