Varnish High Availability


In the case of cloud instances, or any other platform featuring clusters that can shrink and grow dynamically, the nodes.conf file needs to be updated and vha-agent needs to re-read it when a change occur. This is varnish-discovery’s role.

It will watch a given source, such as the VAC api or DNS information and will create or update a nodes.conf file tracking the relevant machines, in addition, it can send a SIGHUP to vha-agent (or any process) to warn it the configuration changed.

Its package is varnish-plus-discovery.


First, vha-agent must expose a pid file using the -P argument. Starting with 2.1.1, the varnish-plus-ha packages are configured to create that file as /run/ (/var/run/vha-agent/ on sysv platforms) and varnish-discovery uses it by default.

Also, it’s recommended to run vha-agent without the -m switch, ie. let it use the hostname of the machine as varnish-discovery will use it when no node name is readily available (for DNS for example).

Getting started

varnish-discovery supports multiple backends to generate a nodes.conf, each with their own set of switches (most are optional), so to help you hit the ground running, here’s a selection of examples.

Note: if you just need to create the file then exit (eg. before you start VHA for the first time), you can just append --once to those commands.


Here, --group specifies an autoscaling group on AWS. This feature relies on the AWS SDK, so if awscli is properly configured and works, this subcommand will only require common arguments.

/usr/bin/varnish-discovery aws                           \
                  --nodefile /etc/varnish/nodes.conf     \
                  --warnpid /run/vha-agent/ \
                  --group $DOMAIN_NAME


We need to specify a domain name that will be checked every now and then (see the --every option).

/usr/bin/varnish-discovery dns                           \
                  --nodefile /etc/varnish/nodes.conf     \
                  --warnpid /run/vha-agent/ \
                  --group $DOMAIN_NAME


If running inside a pod, discovery will be able to find information about the namespace, cacert and token to access the API server , so there’s no need to specify them:

/usr/bin/varnish-discovery k8s                           \
                  --nodefile /etc/varnish/nodes.conf     \
                  --warnpid /run/vha-agent/ \
                  --api "https://$K8S_API/"              \
                  --group $ENDPOINT                      \
                  --port $PORT

If you don’t specify the port, discovery will assume it’s 80 or 443 depending on the protocol you use (http if not specified).

If your node is only listed by more than one endpoint you must use --group otherwise the node will be present in multiple clusters and VHA won’t know what to do with it.


For the Varnish Administration Console, we only need to point to the API’s address, and varnish-discovery will be able to figure out its own cluster.

/usr/bin/varnish-discovery vac                           \
                  --nodefile /etc/varnish/nodes.conf     \
                  --warnpid /run/vha-agent/ \
                  --api $LOGIN:$PASSWD@$VAC_IP


All packages offer service files, how you edit them is going to depend on your platforms. For sysv, you can edit varnish-discovery.params located in either /etc/deafult/ or in /etc/sysconfig to change the ENABLE and DAEMON_OPTS= variables.

For systemd, run you can create the file /etc/systemd/system/varnish-discovery.service.d/exec.conf and redefine the ExecStart parameter, for example:

cat > /etc/systemd/system/varnish-discovery.service.d/exec.conf << EOF
ExecStart=/usr/bin/varnish-discovery dns --group localhost --ipv4 --nodefile /etc/varnish/nodes.conf --warnpid /run/vha-agent/
systemctl daemon-reload



  • --nodefile NODEFILE (-)

    Output the cluster information in NODEFILE, with “-” meaning stdout.

  • --proto PROTO (http)

    If the source of information doesn’t explicit the protocol used, we fallback to PROTO.

  • --port PORT

    If the source of information doesn’t explicit the port used, we fallback to PORT. If port is omitted, it is inferred from the protocol, and if “0” is specified, the first port is used (useful in the kubernetes case).

  • --warnpid PIDFILE

    What pidfile should be read to warn the owners when the configuration changes. This option can be specified multiple times. PIDFILE will be read everytime a signal has to be sent.

  • --ipv4 --ipv6

    Restrict what version of the IP protocol should be used (useful in the DNS case). If none is supplied, use both.

  • --once

    By default, varnish-discovery will monitor its source of information indefinitely, but with this option it only does it once before exiting. An non-zero return indicates an error during the run.

  • --every SECONDS (2)

    This specify how frequently varnish-discovery should contact the source. For DNS and VAC, this means the duration between two requests (from start to start). In the kubernetes case, which uses long-poll, it tells varnish-discovery how long it should wait before trying again in case of failure (again, this is he time since the start of the failed request).

  • --group NAME

    This option can be used multiple times and tell varnish-discovery the name to look for. The meaning is different depending on the source, but it always represent a handle behind which multiple IPs can hide::

    • DNS: corresponds to hostname
    • k8s: corresponds to endpoint
    • VAC: corresponds to group


  • -region REGION

    If the AWS region hasn’t been configured yet (using aws configure), you may specify it here


  • --no-hostname

    By default, varnish-discovery tries to find the IP corresponding to the local machine in the resolved list and replaces it with the local hostname. This is useful because vha-agent by default, looks for the hostname to find the local machine in the list.

    This switch disables this find-and-replace behaviour.


  • --server URL (https://kubernetes/)
  • --token PATH (/var/run/secrets/
  • --cacert PATH (/var/run/secrets/
  • --namespace PATH (/var/run/secrets/

    When operating inside a pod, varnish-discovery can find how to communicate to the kubernetes api using the contional default, but they can all be overridden to work outside of a pod or to connect to a non-standard URL.

  • --group ENDPOINT

    Note that in k8s’ case, if no endpoint is specified, varnish-discovery will use the one owning the pod it’s running on. This allows for minimal configuration based on context.


  • --server URL

    Where to find the VAC API. URL must include the login and password to correctly authenticate to the API.

  • --no-hostname

    As for the dns command, varnish-discovery will try and replace the local ip with the local hostname.


version 1.0.2(2018-12-24)

  • Add AWS support

version 1.0.1 (2018-10-15)

  • Fix an out-of-bounds exception
  • Failed HTTP request are now printing as comments to help debugging (vac and k8s modules)
  • When no group is found, a comment is printed on the first resolution, instead of looping silently

version 1.0.0 (2017-12-18)

  • initial release