A set of resources for managing F5 load balancers. Currently a WIP, but it will create VIPs and pools, and add nodes to pools
node['f5']['gem_version'] - Sets the version of the gem that will be installed via the resourcenode['f5']['enabled_status'] - Can take one of three values:
:manual - the default, the f5_pool resource does not touch the node's enabled status on load balancer, allowing it to be managed manually on the load balancer:disabled - if a node does not exist or does exist but is enabled, the load balancer will be asked to disable the node:enabled - if a node does not exist or does exist but is disabled, the load balancer will be asked to enable the nodeYour node will also need access to the credentials for the load balancer either in the attributes or a data bag:
If you're using a data bag, call it f5 and the default item is called default.
$ knife data bag show f5 default
Unencrypted data bag detected, ignoring any provided secret options.
host: lb1.example.com
id: default
password: TopSecret
username: chef-apiOr, if no data bag is found, attributes are used
default[:f5][:credentials][:default] = {
host: "lb1.example.com",
username: "chef-api",
password: "TopSecret"
}In an application's recipe:
# Creates the pool if missing and adds this node to the pool
# (currently using node.ipaddress and node.fqdn for the node)
f5_pool 'mypool' do
host 'value'
port 'value'
lb_method 'method' # LB_METHOD_ROUND_ROBIN default
end
# Creates the VIP if missing
f5_vip 'myvip' do
address 'vipaddress' # IPv4 or FQDN, see below
port 'vipport'
protocol 'protocol' # TCP default
pool 'mypool'
# this is optional; defaults to :manual so won't touch your setting
# unless you specify one of the valid options.
snat_pool :automap
# this is optional; defaults to :manual so won't touch your setting
# unless you specify one of the valid options.
# :none disables the firewall_policy,
# anything else is a named firewall_policy
enforced_firewall_policy
# this is optional; defaults to :manual so won't touch your setting
# unless you specify one of the valid options.
# :none disables the firewall_policy,
# anything else is a named firewall_policy
staged_firewall_policy
# this is optional; If this VIP has IRules on the F5, this resource
# will remove them and insert exactly what is specified
# here. The attribute takes in an array of irules. The order
# describes the priority of the irules.
# When changing priority of IRules, be aware that the F5
# doesn't provide an API for re-ordering associations therefore
# the re-ordered rules must be deleted then re-added in the correct
# order.
irules %w(test-irule test-irule-2)
# this is optional; Sets the http profile of the VIP. The default value is `nil`.
# When value is `nil` it will not modify the http profile. Setting
# to `:none` will remove the http profile. Otherwise
# it sets the http profile. Note, the HTTP Profile must already
# exist on the f5.
http_profile :none
end
# Create a F5 monitor template
f5_monitor 'test-monitor' do
# Required properties
template_type 'TTYPE_HTTP' # F5 template type
parent_template 'http'
interval 5 # frequency to check in seconds
timeout 3 # seconds to respond
#optional properties (default values are shown)
dest_ip '0.0.0.0' # tells f5 what address to test. Default indicates to test the node the monitor is applied to
dest_port '0' # tells f5 which port to test; Default indicates to test the port the monitor is applied to
read_only false # specifies if this template is read only
is_directly_usable true # specifies if the template can be directly used
end
# Create an F5 IRule
f5_irule 'test-irule' do
# IRule definition
definition <<-EOL
# For hosts that serve both http but attached to http and https vips,
# this lets them know if the request
# originally came in on https
when HTTP_REQUEST {
HTTP::header insert HTTPS true
}
EOL
endSee the documentation for LocalLB::LBMethod and protocol.
This is an experimental feature. Some of the corner cases might not work :)
If you pass a FQDN to the VIP's address, this resource will attempt to resolve the name through DNS. If a match is found, the first address returned is used for the VIP. If no match is found, the resource will not be processed.
f5_pool Actionsf5_pool's default action is :create which manages the pool and its settings, as well as the node and its settings. If the pool has already been created outside of this recipe and the desired behavior is for chef to fail when the pool doesn't exist use the :add action.
The :add action will only ensure the node is in the pool and configured correctly, but will not modify the pool. Pool-related attributes are ignored.
The f5_pool resource exposes an enabled_status property which allows you to explicitly take control of a node's enabled/disabled status within a pool via chef recipes and attributes.
f5_pool 'mypool' do
host 'value'
port 'value'
enabled_status :disabled
endThough more commonly this is delegated to an attribute, which is the default behavior when this property is not specified explicitly:
f5_pool 'mypool' do
host 'value'
port 'value'
endis equivalent to
f5_pool 'mypool' do
host 'value'
port 'value'
enabled_status node['f5']['enabled_status']
endand node['f5']['enabled_status'] defaults to :manual so it won't touch the enabled status of your node in the pool unless you explicitly ask it to.
The f5_vip resource exposes a pair or properties which allow you to add client and server SSL profiles to a virtual server.
f5_vip 'myvip' do
address 'vipaddress'
port 'vipport'
protocol 'protocol' # TCP default
pool 'mypool'
client_ssl_profile 'client.cert'
server_ssl_profile 'server.cert'
endThese two properties are optional and only take effect if they are specified.
They will converge to ensure that profile is applied to the given vip, but there is currently no option to remove an SSL profile.
The f5_pool and f5_vip resources can be used as-is in a chef-provisioning environment. Options exists for some resources that are especially catered to chef-provisioning.
f5_poolIf the host attribute on the f5_pool resource is excluded the resource will not attempt to add a node but instead simply manage the pool itself.
This coobkook provides custom chefspec matchers so you can write specs like this:
require 'chefspec'
describe 'example::default' do
let(:chef_run) { ChefSpec::SoloRunner.new(platform: 'ubuntu', version: '16.04').converge(described_recipe) }
it 'creates the example_com pool (if needed) and adds this node to it' do
expect(chef_run).to create_f5_pool('example_com').with(
ip: '10.0.0.2',
host: 'examplenode01.internaldomain.com',
port: 80,
monitor: 'test-monitor'
)
end
it 'creates the example.com vip' do
expect(chef_run).to create_f5_vip('example.com').with(
address: '86.75.30.9',
port: '80',
protocol: 'PROTOCOL_TCP',
pool: 'reallybasic'
)
end
endNOTE: these matches verify only the presence (or absence via expect(chef_run).to_not) of a resource and the configuration of its properties according to hash passed to the optional with method.
The matchers cannot be used to validate whether convergence of an f5_pool or f5_vip resource took place.
NOTE: Due to this issue you can't test multiple calls to a resource in chefspec if the resource name is the same.
All resources have an optional <RESOURCE_NAME>_name attribute that you can use to override the chef resource's name. E.g.
f5_pool 'pool_name_create' do
pool_name 'pool_name'
monitor 'tcp'
end
f5_pool 'pool_name_add_node1' do
pool_name 'pool_name'
host 'node1'
ip '1.2.3.4'
port 443
end
f5_pool 'pool_name_add_node2' do
pool_name 'pool_name'
host 'node2'
ip '1.2.3.5'
port 443
endIn the above example, if pool_name wasn't specified then the resource name would have to be pool_name for each call to f5_pool. This would work as expected in chef but chefspec would only register the
last invocation of f5_pool. By using the pool_name resource the chef resource can be uniquely named and therefore tested.
Run bundle exec rake test to run the chefspec tests.
bundle exec rake guard starts a guard listener which watches files and auto-runs rspec to provide faster feedback
bundle exec rake lint will run rubocop
Author:: Sean Walberg (sean@ertw.com)