3

Trying to figure out why environmental variables in haproxy.cfg aren't working in HA-Proxy version 1.5.2

on the command line, using Printenv I get a list of environmental variables like FE_PORT_8000_TCP_ADDR=172.17.0.4

Which I need to use in the haproxy.cfg. According to this and the docs How can I use environment variables in haproxy.conf using $FE_PORT_8000_TCP_ADDR or ${FE_PORT_8000_TCP_ADDR} should work. However that is not working.

In Haporxy.cfg hardcoding DOES work, and accessed in a browser it shows as expected:

backend FE # balance roundrobin server FE1 172.17.0.4:8000 maxconn 256

But environmental variable with same supposed value doesn't, in the browser it gives 503 Service Unavailable.

backend FE # balance roundrobin server FE1 $FE_PORT_8000_TCP_ADDR:8000 maxconn 256

Any ideas on what is being done wrong?

UPDATE: This person has what looks like the same issue How can I use environment variables in haproxy.conf

Improve this question
2
  • How are you starting haproxy? You're environment variables may be set for your login session but if you're starting HAProxy via an init script you'll need to set the environment variables there instead. Commented May 22, 2015 at 5:50
  • @notpeter I'm starting it by hand. e.g if i do one at a time: echo $FE_PORT_8000_TCP_ADDR service haproxy start and the echo shows the output of the environmental var I'd sort of expect haproxy to be able to see it took. Commented May 22, 2015 at 16:41

4 Answers 4

Reset to default
5

Since you're stopping/starting with the service command, you need to specify the environment variables in your init script (e.g. /etc/init.d/haproxy on ubuntu) not in your interactive terminal session where you're controlling the service (service haproxy start). You can verify the environment variables available to a specific pid in the proc filesytem. If you check yours for haproxy, it'll likely be only TERM and LANG, because that's the only environment which gets passed via service to the init script (manpage for service).

# cat /proc/$(pgrep haproxy)/environ

If instead of starting daemonized haproxy from the init script you directly run haproxy you'll likely see the behavior you're looking for:

# haproxy -f /etc/haproxy/haproxy.cfg

To solve this, edit the init script /etc/init.d/haproxy and set your variables there:

export FE_PORT_8000_TCP_ADDR=172.17.0.4
Improve this answer
3
  • aha! that was it. The trick for me is that the environmental vars are being set by docker (linked containers) so I can't currently as easily reexport them. Thank you! Commented May 22, 2015 at 18:29
  • @TroyWorks what part of this worked for you? are you running your own version of haproxy? what image are you using if not? I am running into the same issue when running haproxy directly and I can see before I run the command that all the variables are set by the user starting it. Commented Sep 17, 2015 at 18:30
  • @mschuett how haproxy is started tells it what scope of environmental variables it has access to. the way notpeter suggested vs the daemon way I was doing allowed it to reach the context where variables set in cfg files could be picked up. I don't know more than that sorry, I'm not a sys-admin. stock haproxy, tried a few actually. Commented Sep 18, 2015 at 2:23
2

Had the same problem. Fixed it by adding double quotes around the environment variable.

As explained here (2.3. Environment variables)

HAProxy's configuration supports environment variables. Those variables are interpreted only within double quotes. Variables are expanded during the configuration parsing. Variable names must be preceded by a dollar ("$") and optionally enclosed with braces ("{}") similarly to what is done in Bourne shell. Variable names can contain alphanumerical characters or the character underscore ("_") but should not start with a digit.

Improve this answer
1

I had the same problem but on Debian 8 (Jessie) and setting it in /etc/init.d/haproxy did not work. I fixed it by setting the variable in /etc/default/haproxy like this (no export needed)

FE_PORT_8000_TCP_ADDR=172.17.0.4

For more info see my question and answer about my issue.

Improve this answer
0

Assuming the fact that the /etc/init.d/haproxy file contains the following fragments of code:

#!/bin/sh ... BASENAME=haproxy ... if [ -e /etc/default/${BASENAME} ]; then . /etc/default/${BASENAME} fi ...

, then a good solution for you will be to pass additional variables through the /etc/default/haproxy file instead.

... as mentioned by Johan Gov there as well: https://serverfault.com/a/841307/608437

Improve this answer
1
  • ... also note that the export part is mandatory there as haproxy is started as a different process. Commented Jan 30, 2021 at 23:16

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.