This is what we do, using puppet's erb templating system:
<% haproxy_https_servers.keys.each do |server| %>
<% haproxy_https_servers[server].each do |subserver| %>
<% extra_conditions=''
if subserver.has_key?('extra_conditions')
extra_conditions=subserver['extra_conditions']
end %>
# content switching based on cookie, having had them set in
previous sessions
use_backend <%= server %>-https-<%= subserver['name'] %> if {
hdr_sub(cookie) SITE=<%= server %> } <%= extra_conditions %>
# content switching based on SNI
use_backend <%= server %>-https-<%= subserver['name'] %> if {
ssl_fc_sni -i <%= server %> } <%= extra_conditions %>
<% end %>
<% end %>
-Robin
On Tue, Feb 05, 2013 at 02:53:13PM -0700, William Attwood wrote:
> I would imagine you would dynamically create the haproxy configuration
> based on the sources you're using to fill your variables. I'll be doing
> something similar, soon, where the configuration is dynamically built based
> on entries in a database.
>
>
> Thank you,
> William Attwood
> System Engineer, Co-Founder
> Open Box I.T. Solutions, LLC
> c. 801-634-6479
>
>
> On Tue, Feb 5, 2013 at 2:50 PM, Joel Krauska <[email protected]> wrote:
>
> > I know there's been some pushback about adding 'include' support in to
> > haproxy config files.
> >
> > One of the main reasons I would like that feature is to allow for more
> > dynamic configs.
> >
> > I've come to wonder if some templating/loops couldn't be built in to the
> > haproxy config parser itself.
> >
> > eg.
> >
> > backend foo
> > # List of servers
> > %
> > for (var i=1;i<8;i++)
> > {server app-$i app-$1:8080 maxconn 255 weight 10}
> > %
> >
> > Any other interest in seeing this?
> >
> > I imagine there are standardized approaches for doing this sort of thing.
> >
> > --Joel
> >
