sous-chefs/haproxy

Development repository for the haproxy cookbook

haproxy Cookbook

Installs and configures HAProxy.

Maintainers

This cookbook is maintained by the Sous Chefs. The Sous Chefs are a community of Chef cookbook maintainers working together to maintain important cookbooks. If you’d like to know more please visit sous-chefs.org or come chat with us on the Chef Community Slack in #sous-chefs.

Requirements

• HAProxy stable or LTS
• Chef 13.9+

Platforms

This cookbook officially supports and is tested against the following platforms:

• debian: 9 & 10
• ubuntu: 20.04 & 21.04
• centos: 7 & 8
• centos-stream: 8
• fedora: latest
• amazonlinux: 2

PRs are welcome to add support for additional platforms.

Examples

Please check for working examples in the test cookbook.

Common Resource Features

HAProxy has many configurable options available, this cookbook makes the most popular options available as resource properties.

If you wish to use a HAProxy property that is not listed the extra_options hash is available to take in any number of additional values.

For example, the ability to disable listeners is not provided out of the box. Further examples can be found in either test/fixtures/recipes or spec/test/recipes. If you have questions on how this works or would like to add more examples so it is easier to understand, please come talk to us on the Chef Community Slack on the #sous-chefs channel.

haproxy_listen 'disabled' do
  bind '0.0.0.0:1337'
  mode 'http'
  extra_options('disabled': '')
end

The extra_options hash is of String => String or String => Array. When an Array value is provided. The values are looped over mapping the key to each value in the config.

For example:

haproxy_listen 'default' do
  extra_options(
    'http-request' => [ 'set-header X-Public-User yes', 'del-header X-Bad-Header' ]
    )
end

Becomes:

listen default
  ...
  http-request set-header X-Public-User yes
  http-request del-header X-Bad-Header

Resources

• haproxy_acl
• haproxy_backend
• haproxy_cache
• haproxy_config_defaults
• haproxy_config_global
• haproxy_fastcgi
• haproxy_frontend
• haproxy_install
• haproxy_listen
• haproxy_mailer
• haproxy_peer
• haproxy_resolver
• haproxy_service
• haproxy_use_backend
• haproxy_userlist

Configuration Validation

The haproxy.cfg file has a few specific rule orderings that will generate validation errors if not loaded properly. If using any combination of the below rules, avoid the errors by loading the rules via extra_options to specify the top down order as noted below in config file.

frontend & listen

  tcp-request connection
  tcp-request session
  tcp-request content
  monitor fail
  http-request
  reqxxx (any req excluding reqadd, e.g. reqdeny, reqallow)
  reqadd
  redirect
  use_backend

  extra_options(
    'tcp-request' => 'connection set-src src,ipmask(24)',
    'reqdeny' => '^Host:\ .*\.local',
    'reqallow' => '^Host:\ www\.',
    'use_backend' => 'dynamic'
  )

backend

  http-request
  reqxxx (any req excluding reqadd, e.g. reqdeny, reqallow)
  reqadd
  redirect

  extra_options(
    'http-request' => 'set-path /%[hdr(host)]%[path]',
    'reqdeny' => '^Host:\ .*\.local',
    'reqallow' => '^Host:\ www\.',
    'redirect' => 'dynamic'
  )

Contributors

This project exists thanks to all the people who contribute.

Backers

Thank you to all our backers!

Sponsors

Support this project by becoming a sponsor. Your logo will show up here with a link to your website.

haproxy's Issues

[question] is there a way to provide a static haproxy config file ?

Hi would like to use this recipe but apply a static haproxy config files.
From what I've read one option is to modify haproxy cookbook to override default provided template, but I don't like it because it modify the cookbook.

Is there a way to achieve this goal but modifying the cookbook ?

From the doc that's say that we can : "supply your own and override the cookbook and source by reopening the template[/etc/haproxy/haproxy.cfg] resource"

Could someone elaborate on this as I'm new to chef and need some pointer to understand what's behind this phrase ... Do we need to define our own recipe that extends this one, use a node configuration or there is a simpler way ?

Thanks for your help and I apologize if this not the best place to ask but I do it we the hopes that we could enhance he README.md to make things clearer.

to fix syslog

After a fresh install on Debian/Ubuntu, you have to restart rsyslog as a one-time action:

service 'rsyslog' do
action :restart
end

Otherwise logging still goes in /var/log/syslog and not /var/log/haproxy.log.
So the cookbook should send a notify to restart the rsyslog service.

Do not include non provisioned nodes

Hi,

When a node is defined in a Chef server but not yet provisioned, ip address is not set.
The HAProxy configuration is wrong and prevents the service to start.

As you can see, there are no ip in this case:

backend servers-http
  server  :8080 weight 1 maxconn 100 check

So at lthis line https://github.com/hw-cookbooks/haproxy/blob/master/recipes/app_lb.rb#L28, pool_members without ipaddress should be excluded.

Thoughts ?
Olivier.

HAProxy search functionality and test/example

Cookbook version

4.0.2

Chef-client version

12.19.36

Platform Details

CentOS 6.x

Scenario:

Testing issue

Steps to Reproduce:

N/A

Expected Result:

N/A

Actual Result:

N/A

Looking to add tests for search functionality and perhaps also examples of code to provide the user more context around dynamic utilization of the haproxy providers.

backend_array = search(:node, "roles:app AND chef_environment:#{environment}")
backend_array.each do |b|
  haproxy_backend b['id'] do
  end
end

Missing method "with_run_context"

Cookbook version

v4.0.0

Chef-client version

12.7.2

Platform Details

CentOS

Scenario:

Install HAProxy via

haproxy_install 'package' do

end

Steps to Reproduce:

Trigger a chef-client run and install HAProxy via the haproxy_install resource.

Expected Result:

HAProxy is installed on the host.

Actual Result:

Error during a run of the chef-client:

================================================================================
Error executing action `create` on resource 'haproxy_install[package]'
================================================================================

NoMethodError
-------------
No resource or method named `with_run_context' for `Custom resource haproxy_install from cookbook haproxy action provider "package"'

Cookbook Trace:
---------------
/tmp/kitchen/cookbooks/haproxy/resources/install.rb:95:in `block in class_from_file'

Using HAproxy cookbook as reverse proxy

Hi,

I am using this cookbook with the manual recipe to create an HAcluster instance, but I'm running into an issue which presumably is a limitation with the community cookbook.

To support an reverse proxy function I need to split every service into a seperate backend on which I can place ACL's.

Two things are unclear for me:

Does the manual recipe support acls?
Does the cookbook supports multiple backends with the manual recipe?

Thanks in advance

Drop Chef Search for Cluster management

As this is not recommended behaviour for a cluster (we should be using something else like consul) do we want to remove the _discovery mechanism?

Or make it just accept an array that some other tool can populate?

Haproxy Service Doesn't Start on Ubuntu 14.04

I know Ubuntu 14.04 is not listed as a supported platform. But I tried to use it. The cookbook installs and configures haproxy successfully. But when you run the init script, it does not start the service. After reviewing the cookbook, I noticed it does not place the cookbook file 'haproxy-default' on the system and init start up remains disabled. Is there a reason 'haproxy-default' is no longer installed?

Cookbook version

4.0.1

Chef-client version

12.18.31

Platform Details

Ubuntu 14.04 (AWS)

Scenario:

Install haproxy on a new instance, configure it and have the service running.

Steps to Reproduce:

Using the cookbook as documented

Expected Result:

haproxy running

Actual Result:

haproxy doesn't start via init

How do I add auth to the admin interface?

I tried

haproxy_lb 'admin' do
  params({
    'stats realm' => 'Haproxy-Statistics',
    'stats auth' => 'user:pwd'
  })
end

in my recipe, but it's not showing up in my admin section which looks like

# Set up application listeners here.

listen admin
  bind 0.0.0.0:1337
  mode http
  stats uri /

retries not configuring correctly

Cookbook version

4.0.2

Chef-client version

12.19.36

Platform Details

CentOS 6

Scenario:

Configure the number of retries

Steps to Reproduce:

haproxy_config_defaults ''  do
  balance 'leastconn'
  mode 'http'
  maxconn 1000
  haproxy_retries 5
end

Expected Result:

retries in the haproxy.cfg file with a value of 5

Actual Result:

retries in the haproxy.cfg file with a value of 0

Multiple values for a param key don't work

I was using the LWRP provided this cookbook to build a haproxy config file for my Openstack configuration, one of the LWRP blocks looks like so

dashboard_nodes = search(:node, "roles:os-dashboard AND chef_environment:#               {node.chef_environment} NOT fqdn:#{node['fqdn']}")
dashboard_nodes.push(node) if node.run_list.expand(node.chef_environment).roles.include?('os-    dashboard')
haproxy_lb 'openstack_dashboard_http_cluster' do
  type 'listen'
  bind "#{node['bluereef-mis']['os-ha-proxy']['virtual-ip']}:80"
  params({
    'balance' => 'source',
    'option' => [ 'tcpka', 'httpchk', 'tcplog' ]
  })  
  servers dashboard_nodes.map! { |n| 
    "#{n['fqdn'].split('.').first} #{n['ipaddress']}:85 check inter 2000 rise 2 fall 5"
  }
end

But when I ran this the config ended up like this

listen openstack_dashboard_http_cluster
  bind 10.16.16.29:80
  balance source
  option ["tcpka", "httpchk", "tcplog"]

What I am needing is to have it look like this

listen openstack_dashboard_http_cluster
  bind 10.16.16.29:80
  balance source
  option tcpka
  option httpchk
  option tcplog

Including `haproxy::app_lb` in run list doesn't write proper haproxy.cfg

@slyness This is an issue only in master. In develop, I'm able to put haproxy::app_lb in my run list with the following role and /etc/haproxy.cfg is written properly. If I do this same thing with the master branch of this cookbook, /etc/haproxy.cfg remains unchanged as the default file installed with the haproxy package. This is on Centos 6.5. Can I help out?

p.s. Whazzup?!

name 'haproxy_lb'
default_attributes(
  :haproxy => {
    :app_server_role => 'fit_api_server',
    :enable_default_http => false
  }
)
run_list 'recipe[haproxy::app_lb]'

Having haproxy/members attribute hashed based on backend names

As of now the haproxy/members attribute adds the following 2 entries by default to the servers-http backend.
https://github.com/hw-cookbooks/haproxy/blob/master/attributes/default.rb#L26-L36
https://github.com/hw-cookbooks/haproxy/blob/master/recipes/default.rb#L57-L64

This haproxy/members can be made more helpful if we can hash the members based on backend names

node.set['haproxy']['members']['servers-http'] = [{
...
}]

This would make this attribute more helpful when we want to create additional backend sections with their own list of servers attached.

node.set['haproxy']['members']['new_backend'] = [{
...
}]

It would also be helpful to have a helper method that does this - https://github.com/hw-cookbooks/haproxy/blob/master/recipes/default.rb#L57-L59
We can probably have a options hash to set these values to the server entry - weight #{member['weight'] || member_weight} maxconn #{member['max_connections'] || member_max_conn} check"

options = {
  weight: member['weight'] || member_weight
  maxconn: member['max_connections'] || member_max_conn
  check: true
}

Wasn't this the purpose of having a haproxy/members attribute? Or I am going in the wrong direction?

Update haproxy from source

Hi,

when I get it right it is not possible to upgrade a haproxy version from source out of the box. First you have to delete the binary did I get the code right this far?

Would it be possible to use ark instead of bash, to get version updates easier to run?

Regards
Dieter

haproxy service not properly configured through AWS OpsWorks stacks

Cookbook version

4.1.0

Chef-client version

chef-client 12.18.31
OpsWorks Stacks uses Chef Zero (logs show 12.13.37)

Platform Details

The configuration is done using the latest Amazon AMI with OpsWorks Stacks

Scenario:

I try to achieve a very basic installation of haproxy from sources using AWS OpsWorks Stacks.
Note that everything is fine when executed the recipe with Kitchen on centos 6.8 (I tried this because Amazon AMI seems to be derivated from centos 6).

Steps to Reproduce:

Create an OpsWorks Stacks layer configured to run a very basic recipe with all default values performing the installation from sources, and launch an ec2 instance with the latest AMI.
There may be another simpler way.

Expected Result:

The haproxy service should be up and running

Actual Result:

The service cannot start because the exec path is invalid.
The resulting init.d/haproxy file shows
config="/haproxy.cfg" exec="/sbin/haproxy"

The variables @conf_dir and @Prefix seems to be left blank

frontend with no default backend

Cookbook version

latest

Chef-client version

12.x

Platform Details

Latest amazon linux

Scenario:

frontend with no default backend

in a case where ssl forwarding is needed, a default_backend should not be required no?

ie:

frontend http-in
  bind *:80
  maxconn 50000
  redirect scheme https code 301 if !{ ssl_fc }

Unable to override conf template

I'm using a wrapper cookbook and installing from source on Ubuntu 12.04. Below are the attributes in my wrapper. Those related to installation work correctly, however the conf_cookbook and conf_template_source attributes do not. I've tried both setting these to override and to the chef role however the default template is still loaded from the haproxy cookbook rather than my wrapper (cpf-haproxy).

default['haproxy']['conf_cookbook'] = "cpf-haproxy"
default['haproxy']['conf_template_source'] = "tabproxy.cfg.erb"

default['haproxy']['source']['version'] = '1.5.15'
default['haproxy']['install_method'] = 'source'
default['haproxy']['source']['url'] = 'http://www.haproxy.org/download/1.5/src/haproxy-1.5.15.tar.gz'
default['haproxy']['source']['checksum'] = '5af46e1438601d0919f5628081f660f9533087d88af3d9274f245395475663e1'

Compiling from source does not start service

Problem: When installing from source with include_recipe 'haproxy::install_source', the file /etc/default/haproxy is not created.

To work around this, I have copied the cookbook_file '/etc/default/haproxy' resource from the def haproxy_default_file method in the default provider into my recipe.

This is what I am doing in my own recipe:

cookbook_file '/etc/default/haproxy' do
  source 'haproxy-default'
  cookbook 'haproxy'
  owner 'root'
  group 'root'
  mode 00644
  notifies :restart, 'service[haproxy]', :delayed
end

include_recipe 'haproxy::install_source'

service 'haproxy' do
  supports :status => true, :restart => true, :reload => true
  action [ :enable, :start ]
end

Without the default file, the haproxy service will not start. Is the above recipe behaviour by design, or am I looking at a bug?

ordering of configuration

Inside an haproxy backend, you might have "default-server" and also "server". It turns out these are order dependent, and "default-server" must go first.

However, the haproxy_lb provider in the cookbook prints out servers first, and then params. default-server is (or could be) a customized param, and so the results are out-of-order.

A code fix is to move params to the beginning, or servers to the end, in the file providers/lb.rb

Is this cookbook still being maintained and supported?

Supermarket and GitHub repository are out of sync

supermarket has version 1.6.7
github has metadata 1.6.6

what is going on?

haproxy Chef-13

Cannot select version of HAProxy

Cookbook version

4.2.0

Chef-client version

12.13

Platform Details

Opsworks Amazon Linux 2017.03

Scenario:

I am trying to run any version of HAProxy besides 1.5.2 which is what it seems to be defaulting to

haproxy_install 'package' do
  source_version node[:haproxy][:source_version]
  source_url node[:haproxy][:source_url]
  source_checksum node[:haproxy][:source_checksum]
end

default[:haproxy][:source_version] = '1.7.5'
default[:haproxy][:source_url] = 'http://www.haproxy.org/download/1.7/src/haproxy-1.7.5.tar.gz'
default[:haproxy][:source_checksum] = 'b04d7db6383c662eb0a421a95af7becac6d9744a1abf0df6b0280c1e61416121'

I copied these values over from the install.rb file in the repo, but for some reason 1.5.2 keeps being installed. I also see no mention int he repo of 1.5 or 1.5.2 so I'm not sure why it's installing that version.

I would like to protect master, and also set squash merge only.

I would like to protect the master branch, and then set the merge rule to "squash merge" only. What are your thoughts on this?

ACL Resource

Cookbook version

4.0.2

Chef-client version

All

Platform Details

So I have two thoughts on possible syntax for the haproxy_acl resource
first possibility

make use of the name property to hold the rule, since this will generally be pretty unique
section and section_name seem cumbersome but not sure what would be a better name
but quickly explodes into a lot of extra typing or doing some sort of each over an array of acls

haproxy_acl 'gina_host hdr(host) -i foo.bar.com' do
section 'frontend'
section_name 'http'
end

haproxy_use_backend 'gina if gina_host' do
section 'frontend'
section_name 'http'
end

second posibility

don't use name for the rule, but provide the array of acls to add to the section, implementing adding the rules to the resource variables would just require updating it do something like variables[new_resource.section][new_resource.section_name]['acl'] += Array(new_resource.acls)

haproxy_acl 'acls for frontend:http' do
section 'frontend'
section_name 'http'
acls [
'kml_request path_reg -i /kml/',
'bbox_request path_reg -i /bbox/',
'gina_host hdr(host) -i foo.bar.com',
'rrhost_host hdr(host) -i dave.foo.bar.com foo.foo.com',
'tile_host hdr(host) -i dough.foo.bar.com',
]
end

haproxy_use_backend 'use_backends for frontend:http' do
section 'frontend'
section_name 'http'
use_backends [
'gina if gina_host',
'rrhost if rrhost_host',
'abuser if source_is_abuser',
'tiles_public if tile_host'
]
end

For complete examples of how these two thoughts could be applied to config-2 tests see:

https://gist.github.com/teknofire/c6969955bfeafa903629b30f4575d93c

Not possible to create multi instance of haproxy

The recipe install_ operate on the same name of init file, which is "/etc/init.d/haproxy"
We have a need to create several instances of haproxy, each with init file.
Example: an haproxy insatnce for service1, with /etc/init.d/haproxy_service1
A second instance of haproxy for service2, with /etc/init.d/haproxy_service2

Is it possible to allter this recipe, to include this need ?
thank you

Strange behaviour with haproxy_lb LWRP

I'm currently working on a wrapper cookbook that wraps this haproxy cookbook and I've noticed that, at least in test-kitchen, the haproxy_lb LWRP isn't functioning correctly. The node['haproxy']['listeners'] attribute is unchanged after calling the LWRP.

While trying to debug, I noticed that adding a log line (https://gist.github.com/amdprophet/db1fba1fe4f84fc4b12c#file-lb-rb-L20) fixes the problem. I'm quite unsure of how adding the log line could possibly fix the LWRP; but it did.

Currently using test-kitchen 1.2.1 w/Chef 11.10.4.

The wrapper recipe: https://gist.github.com/amdprophet/508981de036090d3100f

no haproxy package on debian7

Hello,

The cookbook doesn't seem to work on debian 7 with default apt repo.
It works on debian 6 and debian 8.

Debian 8 :

vagrant@lwrp-package-debian-82:~$ apt-cache policy haproxy
haproxy:
  Installed: 1.5.8-3+deb8u2
  Candidate: 1.5.8-3+deb8u2
  Version table:
 *** 1.5.8-3+deb8u2 0
        500 http://httpredir.debian.org/debian/ jessie/main amd64 Packages
        100 /var/lib/dpkg/status
     1.5.8-3+deb8u1 0
        500 http://security.debian.org/ jessie/updates/main amd64 Packages

Debian 7 :

vagrant@lwrp-package-debian-79:~$ apt-cache policy haproxy
N: Unable to locate package haproxy

Debian6 :

vagrant@lwrp-package-debian-6010:~$ apt-cache policy haproxy
haproxy:
  Installed: 1.4.8-1+squeeze1
  Candidate: 1.4.8-1+squeeze1
  Version table:
 *** 1.4.8-1+squeeze1 0
        500 http://mirrors.kernel.org/debian/ squeeze/main amd64 Packages
        500 http://security.debian.org/ squeeze/updates/main amd64 Packages
        100 /var/lib/dpkg/status

Allow multiple ACL's inside haproxy_lb provider

https://github.com/sous-chefs/haproxy/blob/master/providers/lb.rb#L13

This line makes it impossible to have an array of ACL's.
Is it possible to change the line to incorporate 'sub'-array's / hashes?

I would like to be able to define multiple 'acl' lines and multiple 'use_backend' lines to incorporate header switching.

Service fails to start when installing from source with systemd

When installing from source on Debian 8, the service will fail to start because systemd does not recognize it. Have not tested other systemd distros yet. Would assume it does.

Running systemctl daemon-reload works with the current init.d script or a systemd unit file could be generated instead. Would require a platform version check either way.

thought on adding in sysctl setting in recipes/tuning.rb

what are the thoughts on updating the sysctl settings in recipes/tuning.rb
net.ipv4.tcp_tw_reuse = 1
net.ipv4.ip_local_port_range = 1024 65535
and possibly limits. Here are a couple of references:
http://pastebin.com/8Hsv3n0u
https://wiki.mikejung.biz/Sysctl_tweaks

Sane HAProxy Config

This is an issue for saving several haproxy configs

Service reload/restart can cause multiple instances of haproxy process

The restart and reload logic in the CentOS service script (templates/centos/haproxy-init.erb) doesn't have enough locking and can result in multiple haproxy processes. It is very easy to reproduce

service haproxy reload & service haproxy reload

or

service haproxy restart & service haproxy restart

The problem is most likely to arise when you have automated logic to reload as the configuration changes.

Changes to default haproxy member attributes not sticking

I'm running haproxy 2.0.2 that I obtained through the knife cookbook site haproxy install command on my workstation running Chef v12.16.42. I deployed haproxy to my Ubuntu 16.04 node successfully; however, my tweaks to the default['haproxy']['members'] attribute did not get carried over when it was added to the node.

Here is a snippet of my cookbooks/haproxy/attributes/default.rb file on my workstation:

default['haproxy']['incoming_port'] = 80
default['haproxy']['members'] = [{
'hostname' => 'webserver1', 
'ipaddress' => '192.168.1.136'
}, {
'hostname' => 'webserver2', 
'ipaddress' => '192.168.1.137'
}]

Here is a snippet of the resulting /etc/haproxy/haproxy.cfg on the load_balancer node:

frontend http
   maxconn 2000
   bind 0.0.0.0:80
   default_backend servers-http

backend servers-http
   mode http

As you can see, the member attributes were not added to the backend servers-http section :( Am I doing something wrong?

Here is the process I went through:

• Tweaked the attributes/default.rb file to reflect my new members
• Added the cookbook to the chef server
• Set the node's run_list to be recipe[haproxy::app_lb]
• Ran sudo chef-client on the node. No errors reported.

When I manually add my webservers to the /etc/haproxy/haproxy.cfg file on the node, everything works perfectly, but of course, this is not optimal :(

Help!! :)

Kitchen Test fails for centos

  * service[haproxy] action restart[2013-12-01T02:08:21+00:00] INFO: Processing service[haproxy] action restart (haproxy::default line 106)

       ================================================================================
       Error executing action `restart` on resource 'service[haproxy]'
       ================================================================================


       Mixlib::ShellOut::ShellCommandFailed
       ------------------------------------
       Expected process to exit with [0], but received '1'
       ---- Begin output of /sbin/service haproxy restart ----
       STDOUT: 
       STDERR: /etc/init.d/haproxy: line 33: /lib/lsb/init-functions: No such file or directory
       ---- End output of /sbin/service haproxy restart ----
       Ran /sbin/service haproxy restart returned 1


       Resource Declaration:
       ---------------------
       # In /tmp/kitchen/cookbooks/haproxy/recipes/default.rb

       106: service "haproxy" do
       107:   supports :restart => true, :status => true, :reload => true
       108:   action [:enable, :start]
       109: end



       Compiled Resource:
       ------------------
       # Declared in /tmp/kitchen/cookbooks/haproxy/recipes/default.rb:106:in `from_file'

       service("haproxy") do
         action [:enable, :start]
         updated true
         supports {:restart=>true, :status=>true, :reload=>true}
         retries 0
         retry_delay 2
         service_name "haproxy"
         enabled true
         pattern "haproxy"
         startup_type :automatic
         cookbook_name :haproxy
         recipe_name "default"
       end

Add support for a single frontend and multiple backends

I just wrote a wrapper cookbook that will accomplish this. It uses most of what is already in the haproxy cookbook and does some additional things with attributes. Do you think there is an interest to have this option in the upstream cookbook? I could fork it and setup a PR. It could basically offer an option specify an array of app roles instead of just one.

My _discovery recipes does the same thing as the current _discovery except it iterates additionally through an array of app roles. Then my wrapper's default recipe sets up the frontend and backends with the LWRPs.

I imagine there are others that want to use one load balancer in front of multiple different app clusters. We're doing this currently in our infrastructure because it means less nodes to manage. If we load balanced each app cluster, we would have 7 load balancers.

HAProxy init script does not work when HAProxy is installed from source package

In the install_source recipe, the haproxy configuration directory is set to /usr/local//etc/haproxy/haproxy.cfg which does not make sense. The bug is here in this line - https://github.com/hw-cookbooks/haproxy/blob/master/recipes/install_source.rb#L34

In the attributes file
node['haproxy']['source']['prefix'] is set to /usr/local
node['haproxy']['conf_dir'] is set to /etc/haproxy

Hence the resulting string from line 34 is /usr/local//etc/haproxy which is not a vaild path.

I don't understand why the /usr/local prefix is added to the configuration directory. The configuration directory could just be in the path specified by node['haproxy']['conf_dir'].

cookie support

For the cookie functionality to work, each "server" must specify a cookie.

The commit on Aug 24, 2013 entitled "[COOK-3237] Add node['haproxy']['cookie'] to set a cookie …" correctly added these extra options to each "server" entry in templates/default/haproxy.cfg.erb:

check <% if node['haproxy']['cookie'] %>cookie <%= member['hostname'] %><% end %>

Great. Although, why it was added to http servers and not to https servers is a bit of a mystery and perhaps an omission?

Then the commit on Sept 25, 2013 "Make lb provider more generic", the code was relocated to default.rb recipe, and the cookie section removed.

That code, of "check <% if node['haproxy']['cookie'] %>cookie <%= member['hostname'] %><% end %>" should be added back to each server line in recipes/manual.rb , unless I am missing something here.

How to reload haproxy if the configuration has changed?

Cookbook version

4.0.1

Chef-client version

12.7.2

Platform Details

CentOS 7.2

Scenario:

Reload HAProxy configuration in case the configuration changed.

Steps to Reproduce:

I'm using this recipe for testing:

haproxy_install 'package' do
  action :create
end

haproxy_config_global 'global' do
  action :create
end

haproxy_config_defaults 'defaults' do
  action :create
end

haproxy_listen 'test' do
  bind ':9000'
  extra_options ({ 'stats' => 'enable' })

  notifies :reload, 'haproxy_install[package]', :delayed
  action :create
end

haproxy_install 'package' do
  action :reload
end

To trigger a change, set bind ':9000' to bind ':9001' and trigger another run of the recipe.

Expected Result:

A reload of the configuration is triggered and HAProxy is listening on port 9001.

Actual Result:

HAProxy still listens on port 9000. After running sudo systemctl reload haproxy, HAProxy listens on port 9001.

Log output of a Kitchen run:

Starting Chef Client, version 12.7.2
Compiling Cookbooks...
[2017-04-21T10:08:09+00:00] WARN: Cloning resource attributes for haproxy_install[package] from prior resource (CHEF-3694)
[2017-04-21T10:08:09+00:00] WARN: Previous haproxy_install[package]: /tmp/kitchen/cookbooks/sabio-haproxy/recipes/test.rb:1:in `from_file'
[2017-04-21T10:08:09+00:00] WARN: Current  haproxy_install[package]: /tmp/kitchen/cookbooks/sabio-haproxy/recipes/test.rb:21:in `from_file'
Converging 5 resources
Recipe: sabio-haproxy::test
 * haproxy_install[package] action create
   * poise_service_user[haproxy] action create
     * group[haproxy] action create (up to date)
     * user[haproxy] action create (up to date)
(up to date)
   * yum_package[haproxy] action install (up to date)
    (up to date)
 * directory[/etc/haproxy] action create (up to date)
 * template[/etc/haproxy/haproxy.cfg] action nothing (skipped due to action :nothing)
 * poise_service[haproxy] action nothing (skipped due to action :nothing)
 * haproxy_config_global[global] action create (up to date)
 * haproxy_config_defaults[defaults] action create (up to date)
 * haproxy_listen[test] action create (up to date)
 * haproxy_install[package] action reload (up to date)
 * poise_service[haproxy] action reload
   * service[haproxy] action reload
     - reload service service[haproxy]

 * template[/etc/haproxy/haproxy.cfg] action nothing (skipped due to action :nothing)
 * template[/etc/haproxy/haproxy.cfg] action create
   - update content in file /etc/haproxy/haproxy.cfg from 32b537 to a722a2
   --- /etc/haproxy/haproxy.cfg	2017-04-21 10:02:18.516422500 +0000
   +++ /etc/haproxy/.haproxy.cfg20170421-13323-1ryp4v6	2017-04-21 10:08:11.105629000 +0000
   @@ -26,7 +26,7 @@

    listen test
mode http
   -  bind :9000
   +  bind :9001
maxconn 2000
stats uri /

   - restore selinux security context
 * poise_service[haproxy] action enable
   * execute[systemctl daemon-reload] action nothing (skipped due to action :nothing)
   * template[/etc/systemd/system/haproxy.service] action create (up to date)
   * service[haproxy] action enable (up to date)
   * service[haproxy] action start (up to date)
    (up to date)

Running handlers:
Running handlers complete
Chef Client finished, 3/21 resources updated in 02 seconds
Finished converging <default-centos-72> (0m4.07s).

Add attribute for default.retries

There is no attribute to define retries parameter in default section. The default value, 3, is forced, and we do not want that.
This PR fixes this : #93
Can you please merge it?

Sticky Sessions when Cookies are used

It looks like the ability to create sticky sessions when cookies are used was added in COOK-3237 but was removed in COOK-3660. Was that intentional? Am I missing a new way to configure this?

Update stats on frontend, listen, backend, defaults providers to be hash

Cookbook version

4.0.2

Chef-client version

12.19.36

Platform Details

CentOS 6

Scenario:

Documentation compliance with HAProxy documented features on the stats segment

Steps to Reproduce:

N/A - Providers implement various pieces of stats at different levels, this is to bring them in-line with documentation

Expected Result:

Documentation compliance configuration

Actual Result:

stats is a hash only at the config_defaults provider. Various settings of stats can be performed at different levels per documentation:
https://cbonte.github.io/haproxy-dconv/1.7/configuration.html#3.4

Instead of handling all the various settings levels of the stats directive, we should configure the stats directive as a hash and allow reasonable sane defaults. One default in the current version is within the stats hash setting uri to /haproxy-stats in config_defaults, then using stats_uri defaulted to / in listen. This is likely unintended and shouldn't be conflicting

Reference documentation mentioned above, various stats directives are available at different configuration levels - we should allow the user to fail and if we want to get fancy detect the stats blunder and redirect them to the correct documentation; or just to the head of the docs in general.

Feature: support userlist

Cookbook version

4.0.2

Chef-client version

12.19.36

Platform Details

CentOS 6

Scenario:

Create userlist blocks:

userlist stats-auth
    group admin    users admin
    user  admin    insecure-password AdMiN123
    group readonly users haproxy
    user  haproxy  insecure-password haproxy

backend stats_auth
    stats enable
    acl AUTH       http_auth(stats-auth)
    acl AUTH_ADMIN http_auth_group(stats-auth) admin
    stats http-request auth unless AUTH
    stats admin if AUTH_ADMIN

Steps to Reproduce:

Feature request. The backend or listen providers can handle via extra_options the additional stats directives, or in the case of haproxy_config_default via the hash.

Expected Result:

Create the above desired configuration without having to customize a template

Reference: https://cbonte.github.io/haproxy-dconv/1.7/configuration.html#3.4

Actual Result:

N/A

update default['haproxy']['source']['target_os'] from generic to 'linux26' or 'linux2628'

As this cookbook only supports the following versions: https://github.com/sous-chefs/haproxy/blob/master/metadata.rb#L12, I would like to update target_os to a newer setting. Thoughts?

[COOK-4194] Bug in setting node.haproxy.members

I am providing attributes

'haproxy' => {
            'enable_admin' => false,
            'incoming_port' => '80',
            'members' => [
                { 'hostname' => 'localhost',
                  'ipaddress' => '127.0.0.1',
                  'port' => 3000
                }, {
                'hostname' => 'test-server',
                'ipaddress' => '10.1.23.2',
                'port' => 3000,
                'ssl_port' => 3001
                }
            ]
        }

But in haproxy.cfg configuration members are configured as

---

backend servers-http
server ipaddress127.0.0.1hostnamelocalhostport3000
server ssl_port3001ipaddress10.1.23.2hostnametest-serverport3000

---

What happened to spaces ?

I am using version 1.6.2 of the cookbook in ubuntu 12.04 with vagrant.

Compiling from source with SSL enabled does not work

The default source method of install doesn't work with SSL enabled because the source package (1.4.22) does not support SSL.

order of operations can leave a broken state

Because of how the cookbook handles the haproxy service, if a broken haproxy.cfg is pushed then a 'correct' haproxy configuration can't be subsequently pushed to fix the problem.

This is because the install recipe starts the haproxy service before the template resource executed. That being said, there doesn't seem to be a need to start haproxy before a configuration file is laid down?

Anyway, solved this locally by just enabling the service in my wrapper cookbook.

edit_resource!(:service, 'haproxy') do
  action [:enable]
end

PRs open for a long time

Is there anything the community can do to help pulling in some of the PRs open?
Some add good features to the cookbook but there doesn't seem to be much traction.

Thanks!

haproxy::install_source fails

The URL http://haproxy.1wt.eu/download/1.4/src/haproxy-1.4.22.tar.gz now 404s. 😕

haproxy lwrp resource does not generate syntactically correct frontend and backend sections in haproxy.cfg

According to the README, I created the config Mash as follows

{"global"=>
  {"maxconn"=>4096,
   "user"=>"haproxy",
   "group"=>"haproxy",
   "daemon"=>true,
   "quiet"=>true,},
 "defaults"=>
  {"timeout"=>{"client"=>"10s", "server"=>"10s", "connect"=>"10s"},
   "log"=>"global",
   "mode"=>"http"},
 "frontend"=>
  {"all_requests"=>{"bind"=>"10.0.0.1:80", "default_backend"=>"app1"}},
 "backend"=>
  {"default"=>
    {"mode"=>"http"},
   "app1"=>
    {"mode"=>"http",
     "balance"=>"roundrobin"}

This is the haproxy.cfg file the template created

global
     maxconn 4096
     user haproxy
     group haproxy
     daemon
     quiet
defaults
     timeout client 10s
     timeout server 10s
     timeout connect 10s

     log global
     mode http
frontend
     all_requests bind 10.0.0.1:80
     all_requests default_backend app3
backend
     default mode http

     app1 mode http
     app1 balance roundrobin

As you can notice the frontend and backend section don't look quite right. It should be generated in this format

frontend all_requests
     bind 10.0.0.1:80
     default_backend app1
backend default
     mode http

backend app1
     mode http
     balance roundrobin

The template and config generator needs to be modified to provide a syntactically correct haproxy.cfg - https://github.com/hw-cookbooks/haproxy/blob/master/templates/default/haproxy.dynamic.cfg.erb#L1-L4