Marathon-LB HAProxy endpoints
Marathon-LB automatically generates configuration information for the HAProxy program, then reloads and restarts HAProxy, as needed. Marathon-LB generates the HAProxy configuration based on application data available from the Marathon API. It can also subscribe to the Marathon Event Bus for real-time updates.
When an application starts, stops, relocates, or has any change in health status, Marathon-LB automatically regenerates the HAProxy configuration and reloads HAProxy.
Marathon-LB exposes the following endpoints on port 9090
by default.
Endpoint | Description |
---|---|
public-node:9090/haproxy?stats |
The Statistics endpoint produces an HTML page that provides statistical information about the current HAProxy instance and its load balancing activity. You can view the statistics from this endpoint in your browser. |
public-node:9090/haproxy?stats;csv |
The Statistics CSV endpoint provides statistical information about the current HAProxy instance and load balancing activity as comma-separated values (CSV). In CSV format, the information can be consumed by other tools. For example, this endpoint produces the results used in the zdd.py script. |
public-node:9090/_haproxy_health_check |
The Health check endpoint returns 200 OK if HAProxy is healthy. |
public-node:9090/_haproxy_getconfig |
The Configuration endpoint returns the HAProxy configuration file as it was when HAProxy was started. Implemented in getconfig.lua . |
public-node:9090/_haproxy_getvhostmap |
The Virtual-host-to-backend endpoint returns the HAProxy virtual host to backend map if the --haproxy-map flag is enabled. If you are not using the --haproxy-map option, the endpoint returns an empty string. Implemented in getmaps.lua . |
public-node:9090/_haproxy_getappmap |
The App-ID-to-backend endpoint returns the HAProxy application identifier to backend map. Like _haproxy_getvhostmap , this endpoint requires you to enable the --haproxy-map option and returns an empty string otherwise. Also implemented in getmaps.lua . |
public-node:9090/_haproxy_getpids |
The Process identifiers endpoint returns the PIDs for all HAProxy instances within the current process namespace. The endpoint literally returns the output of $(pidof haproxy ). Implemented in getpids.lua . This endpoint is also used by the zdd.py script to determine if connections have finished draining during a deployment. |
public-node:9090/_mlb_signal/hup |
The Reload configuration endpoint sends a SIGHUP signal to the marathon-lb process, causing it to fetch the running apps from Marathon and reload the HAProxy configuration as though an event was received from Marathon. |
public-node:9090/_mlb_signal/usr1 |
The Restart configuration endpoint sends a SIGUSR1 signal to the marathon-lb process, causing it to restart the HAProxy load balancer with the existing configuration, without checking Marathon for changes. |
Marathon-LB command reference
Marathon-LB manages operations for the HAProxy
program to provide high availability for applications running on high-volume websites. Marathon-LB relies on the marathon_lb.py
script to perform the following key tasks:
-
Connects to the Marathon API to retrieve information about all running apps.
-
Generates and validates the Marathon-LB
HAProxy
configuration file settings. -
Reloads the
HAProxy
program.
By default, Marathon-LB binds to the service port of every application and sends incoming requests to the application instances. Services are exposed on their service port as defined in their Marathon app definition. Furthermore, apps are only exposed on the load balancers that have the same load balancer group
setting. The group
setting is defined globally or in the app definition file by specifying the HAPROXY_GROUP
label for individual applications.
Invoking marathon-lb directly
In most cases, the marathon_lb.py
script runs in the background. However, you can also run the script directly from the command-line. For example, you can generate the HAProxy
configuration information from Marathon by running the marathon_lb.py
script for localhost:8080
with the following command:
./marathon_lb.py --marathon http://localhost:8080 --group external --strict-mode --health-check
Specifying credentials when running marathon-lb
If Marathon requires authentication, you can include a user name and password using the --auth-credentials
configuration option. For example:
./marathon_lb.py --marathon http://localhost:8080 --auth-credentials=admin:password
You can also provide credentials from the VAULT if you define the following environment variables before running Marathon-LB:
VAULT_TOKEN
VAULT_HOST
VAULT_PORT
VAULT_PATH
If you set these environment variables, you should set the VAULT_PATH
to the root path where your user account and password are located.
Skipping configuration validation
Running the marathon-lb.py
script refreshes the haproxy.cfg
configuration file. If there are any changes to the configuration file, the script automatically reloads the HAProxy
program with the changes. You can skip the configuration file validation process if you don’t have HAProxy
installed or if you are running HAProxy
on Docker containers.
To skip validation of configuration settings, run the following command:
./marathon_lb.py --marathon http://localhost:8080 --group external --skip-validation
Viewing complete usage information
If you run the marathon-lb.py
script directly from the command line, you can specify additional functionality such as sticky sessions, HTTP to HTTPS redirection, SSL offloading, virtual host support, and the configuration templates to use.
To get the full command reference, run the following command:
./marathon_lb.py --help
Running Docker commands for Marathon-LB
Marathon supports both Universal Container Runtime (using cgroups
) and Docker containers and images. You can run Marathon-LB using a command similar to the following for Docker images:
docker run -e PORTS=$portnumber --net=host mesosphere/marathon-lb ...
This command uses the -e
option to set the PORTS
environment variable. The port number is required to allow the HAProxy
program bind to this port. The -net
option enables the command to connect a container to a specified network.
For example, to expose load-balanced applications from a Docker image on port 9090, you might run the following command:
docker run -e PORTS=9090 mesosphere/marathon-lb sse [other arguments]
Using server-sent events (sse)
If you specify the sse
option, the Marathon-LB script connects to the Marathon events endpoint to get notified about state changes.
You can use a command similar to the following to capture server-sent events (sse
).
docker run mesosphere/marathon-lb sse [other arguments]
Determining the current status for Marathon-LB instances
If you can’t use the HTTP callbacks, you can run a command similar to the following to poll the scheduler state periodically:
docker run mesosphere/marathon-lb poll [other args]
You can also use environment variables to set other configuration options for Marathon-LB. For example, you can set the POLL_INTERVAL
environment variable to change the poll interval from its default of 60 seconds.
Usage and command arguments
You can run the Marathon load balancer script (marathon_lb.py
) directly from the command-line in a shell terminal or programmatically. The script accepts the following command-line options and arguments.
Usage
marathon_lb.py [-h] [--longhelp] [--marathon MARATHON [MARATHON ...]] [--haproxy-config HAPROXY_CONFIG] [--group GROUP] [--command COMMAND] [--max-reload-retries MAX_RELOAD_RETRIES] [--reload-interval RELOAD_INTERVAL] [--strict-mode] [--sse] [--archive-versions ARCHIVE_VERSIONS] [--health-check] [--lru-cache-capacity LRU_CACHE_CAPACITY] [--haproxy-map] [--dont-bind-http-https] [--group-https-by-vhost] [--ssl-certs SSL_CERTS] [--skip-validation] [--dry] [--min-serv-port-ip-per-task MIN_SERV_PORT_IP_PER_TASK] [--max-serv-port-ip-per-task MAX_SERV_PORT_IP_PER_TASK] [--syslog-socket SYSLOG_SOCKET] [--log-format LOG_FORMAT] [--log-level LOG_LEVEL] [--marathon-auth-credential-file MARATHON_AUTH_CREDENTIAL_FILE] [--auth-credentials AUTH_CREDENTIALS] [--dcos-auth-credentials DCOS_AUTH_CREDENTIALS] [--marathon-ca-cert MARATHON_CA_CERT]
Required arguments
Argument | Description |
---|---|
-m, --marathon MARATHON [MARATHON ...] | Specifies one or more Marathon endpoints. This argument specifies the location of the Marathon containers for Marathon-LB to use. The default endpoint is http://master.mesos:8080. For example, you can use this argument to specify two Marathon instances like this: -m http://marathon1:8080 http://marathon2:8080. |
--group GROUP | Generates configuration information only for the apps with the specified group names. Use `*` to match all groups, including groups without a group name specified. The default is an empty string. |
Optional arguments
Argument | Description |
---|---|
-h, --help | Show this help message and exit. |
--longhelp | Print out configuration details. The default is false. |
--haproxy-config HAPROXY_CONFIG | Specifies the location of the `haproxy` configuration file. The default is /etc/haproxy/haproxy.cfg | .
--command COMMAND, -c COMMAND | If set, run this command to reload haproxy. The default is none. |
--max-reload-retries MAX_RELOAD_RETRIES | Specifies the maximum number if reload retries before failure. Reloads happen every --reload-interval seconds. Set to 0 to disable reloading attempts or -1 for infinite retries. The default is 10. |
--reload-interval RELOAD_INTERVAL | Waits the specified number of seconds between reload retries. The default is 10. |
--strict-mode | Enables backends to be advertised only if HAPROXY_{n}_ENABLED=true. Strict mode might be enabled by default in a future release. The default is false. |
--sse, -s | Uses server-sent events. The default is false. |
--archive-versions ARCHIVE_VERSIONS | Specifies the number of configuration versions to archive. The default is 5. |
--health-check, -H | Determines Marathon's health check status before adding the app instance into the backend pool. The default is false. |
--lru-cache-capacity LRU_CACHE_CAPACITY | Specifies the LRU cache size (in number of items). This argument should be at least as large as the number of tasks exposed to marathon-lb. The default is 1000. |
--haproxy-map | Uses HAProxy maps for domain name to backend mapping. The default is false. |
--dont-bind-http-https | Prevents binding to HTTP and HTTPS frontends. The default is false. |
--group-https-by-vhost | Groups https frontends by virtual host. The default is false. |
--ssl-certs SSL_CERTS | Lists SSL certificates separated by commas for frontend marathon_https_in. The default is /etc/ssl/cert.pem. For example: /etc/ssl/site1.co.pem,/etc/ssl/site2.co.pem |
--skip-validation | Skips haproxy configuration file validation. The default is false. |
--dry, -d | Only prints configuration information to the console. The default is false. |
--min-serv-port-ip-per-task MIN_SERV_PORT_IP_PER_TASK | Specifies the minimum port number to use when auto-assigning service ports for IP-per-task applications. The default is 10050. |
--max-serv-port-ip-per-task MAX_SERV_PORT_IP_PER_TASK | Specifies the maximum port number to use when auto-assigning service ports for IP-per-task applications. The default is 10100. |
--syslog-socket SYSLOG_SOCKET | Specifies the socket to write syslog messages to. Use /dev/null to disable logging to syslog. The default is /dev/log. |
-log-format LOG_FORMAT | Sets the log message format. The default is %(asctime)-15s %(name)s: %(message)s. |
--log-level LOG_LEVEL | Sets the log level, The default is DEBUG. |
--marathon-auth-credential-file MARATHON_AUTH_CREDENTIAL_FILE | Specifies the path to file containing a user name and password for the Marathon HTTP API in the format of user:pass. The default is none. |
--auth-credentials AUTH_CREDENTIALS | Specifies the user name and password for the Marathon HTTP API in the format of user:pass. The default is none. |
--dcos-auth-credentials DCOS_AUTH_CREDENTIALS | Specifies the DC/OS service account credentials. The default is none. |
--dcos-auth-credentials DCOS_AUTH_CREDENTIALS | Specifies the DC/OS service account credentials. The default is none. |
--marathon-ca-cert MARATHON_CA_CERT | Specifies the CA certificate for Marathon HTTPS connections. The default is none. |
Template and label reference
The following is a list of the available HAProxy
configuration templates. Some templates are global-only (such as HAPROXY_HEAD
), but most can be specified on a per service port basis as app labels to override the global settings.
The templates and app labels that can be set per-service-port include an index identifier {n} in the template or label name. The index identifier corresponds to the service port index, beginning at 0, to which the app label applies. For example, you could specify HAPROXY_0_BACKEND_HEAD
to override the global template HAPROXY_BACKUP_HEAD
for the first port of a given application.
Backend template settings
Use the following template and app labels to configure backend settings for the load balancer.
Template name | Description and examples |
---|---|
HAPROXY_BACKEND_HEAD | Defines the type of load balancing and the connection mode for a backend. The default load balancing type (algorithm) is roundrobin . The default connection mode is tcp .
The valid values for the load balancing type include:
You can set the connection mode to The default template for You can override this template using the following app label for the first port ( |
HAPROXY_BACKEND_HSTS | Specifies the backend options to use where the HAPROXY_{n}_USE_HSTS app label that enables the HSTS response header for HTTP clients is set to true.
The default template for You can override this template using the following app label for the first port ( |
HAPROXY_BACKEND_HTTP | Sets HTTP health check options, such as the health check timeout interval and consecutive failures allowed.
The valid options for the first health check or the first health check for a given service are exposed as follows:
The default template for You can override this template using the following app label for the first port ( |
HAPROXY_BACKEND_HTTP | Sets HTTP headers, for example, X-Forwarded-For and X-Forwarded-Proto.
The default template for You can override this template using the following app label for the first port ( |
HAPROXY_BACKEND_REDIRECT | Redirects backends if the HAPROXY_{n}_REDIRECT_TO_HTTPS label is set to true.
The default template for You can override this template with the following app label for the first port ( |
HAPROXY_BACKEND_REDIRECT | Redirects backends if the `HAPROXY_{n}_REDIRECT_TO_HTTPS_WITH_PATH` label is set to true, but includes a path.
The default template for You can override this template with the following app label for the first port ( |
HAPROXY_BACKEND_SERVER | Sets HTTP health check options, such as the health check timeout interval, for a single server.
The valid options for the first health check or the first health check for a given service are exposed as follows:
The default template for You can override this template with the following app label for the first port ( |
HAPROXY_BACKEND_SERVER | Specifies the options for each server added to a backend.
The default template for HAPROXY_BACKEND_SERVER_OPTIONS is:
You can override this template with the following app label for the first port ( |
HAPROXY_BACKEND_SERVER | Sets TCP health check options, such as the health check timeout interval, for a single server.
The valid options for the first health check or the first health check for a given service are exposed as follows:
The default template for You can override this template with the following app label for the first port ( |
HAPROXY_BACKEND_STICKY_OPTIONS | Sets a cookie for services where HAPROXY_{n}_STICKY is true.
The default template for You can override this template with the following app label for the first port ( |
HAPROXY_BACKEND_TCP | Sets TCP health check options,such as the timeout check.
The valid options for the first health check or the first health check for a given service are exposed as follows:
The default template for The following example sets a timeout check:
You can override this template with the following app label for the first port ( |
HAPROXY_HTTPS_GROUPED | Defines the HTTPS backend for vhost.
You must enable the The default template for |
HAPROXY_HTTP_BACKEND | Denies access for all IP addresses (or IP ranges) that are not explicitly allowed to access the HTTP backend. Use this template with HAPROXY_HTTP_BACKEND_NETWORK_ALLOWED_ACL. This template is a global template that cannot be modified by service port or per application.
The default template for |
HAPROXY_HTTP_BACKEND | Specifies the IP addresses (or IP ranges) that have access to the HTTP backend. This template is a global template that cannot be modified by service port or per application.
The default template for You can override this template with the following app label for the first port ( |
HAPROXY_HTTP_BACKEND | Specifies the backend glue for HAPROXY_{n}_HTTP_BACKEND_PROXYPASS_PATH.
The default template for You can override this template with the following app label for the first port ( |
HAPROXY_HTTP_BACKEND_REDIR | Sets the path to which you want to redirect the root of the domain.
The default template for You can override this template with the following app label for the first port ( |
HAPROXY_HTTP_BACKEND | Specifies the backend glue for HAPROXY_{n}_HTTP_BACKEND_REVPROXY_PATH.
The default template for You can override this template with the following app label for the first port ( |
HAPROXY_TCP_BACKEND | Denies access for all IP addresses (or IP address ranges) that are not explicitly allowed to access the TCP backend. This global template cannot be overridden by service port or application.
The default template for |
HAPROXY_TCP_BACKEND | Specifies the IP addresses (or IP address ranges) that have been granted access to the TCP backend.
The default template for You can override this template with the following app label for the first port ( |
Frontend template settings
Use the following template and app labels to configure frontend settings for the load balancer.
Template name | Description and examples |
---|---|
HAPROXY_FRONTEND_BACKEND_GLUE | Glues the backend to the frontend.
The default template for You can override this template with the following app label for the first port ( |
HAPROXY_FRONTEND_HEAD | Defines the address and port to bind to for this frontend.
The default template for You can override this template with the following app label for the first port ( |
HAPROXY_HTTPS_FRONTEND | Specifies the ACL that performs the SNI based hostname matching for the HAPROXY_HTTPS_FRONTEND_HEAD template.
The default template for You can override this template with the following app label for the first port ( |
HAPROXY_HTTPS_FRONTEND | Defines the access control list (ACL) frontend that matches a particular host name with a path. This template is similar to HTTP_FRONTEND_ACL_ONLY_WITH_PATH, but is only applicable for HTTPS requests.
The default template for You can override this template with the following app label for the first port ( |
HAPROXY_HTTPS_FRONTEND | Specifies the access control list (ACL) that glues a backend to the corresponding virtual host of the HAPROXY_HTTPS_FRONTEND_HEAD through HTTP Basic authentication.
The default template for You can override this template with the following app label for the first port ( |
HAPROXY_HTTPS_FRONTEND | Specifies the ACL that glues a backend to the corresponding virtual host with path of the HAPROXY_HTTPS_FRONTEND_HEAD through HTTP Basic authentication.
The default template for You can override this template with the following app label for the first port ( |
HAPROXY_HTTPS_FRONTEND | Specifies the ACL that performs the SNI based hostname matching with path for the HAPROXY_HTTPS_FRONTEND_HEAD template.
The default template for You can override this template with the following app label for the first port ( |
HAPROXY_HTTPS_FRONTEND | Specifies the HTTP authentication ACL for the corresponding virtual host.
The default template for You can override this template with the following app label for the first port ( |
HAPROXY_HTTPS_FRONTEND | Specifies the HTTP authentication request forthe corresponding virtual host.
The default template for You can override this template with the following app label for the first port ( |
HAPROXY_HTTPS_FRONTEND_HEAD | Specifies an HTTPS frontend for encrypted connections that binds to port *:443 by default and gathers all virtual hosts as defined by the HAPROXY_{n}_VHOST label. This template is a global template that cannot be modified by service port or per application.
You must modify this template setting if you want to include your SSL certificate. The default template for |
HAPROXY_HTTPS_FRONTEND | Works in combination with HAPROXY_HTTP_FRONTEND_ACL_ONLY_WITH_PATH to glue ACL names to the appropriate backend.
The default template for `HAPROXY_HTTPS_FRONTEND_ROUTING_ONLY_WITH_PATH_AND_AUTH` is:
http-request auth realm "{realm}" if host_{cleanedUpHostname} path_{backend} !auth_{cleanedUpHostname}
use_backend {backend} if host_{cleanedUpHostname} path_{backend}
You can override this template with the following app label for the first port ( |
HAPROXY_HTTPS_GROUPED | Defines the HTTPS frontend for encrypted connections that binds to port *:443 by default and gathers all virtual hosts as defined by the HAPROXY_{n}_VHOST label. This template is useful for adding client certificates per domain.
You must enable the The default template for |
HAPROXY_HTTPS_GROUPED | Specifies a route rule HTTPS entrypoint.
You must enable the The default template for |
HAPROXY_HTTPS_GROUPED | Specifies the HTTPS frontend for the virtual host.
You must enable the |
HAPROXY_HTTP_FRONTEND_ACL | Specifies the access control list (ACL) that glues a backend to the corresponding virtual host of the HAPROXY_HTTP_FRONTEND_HEAD.
The default template for You can override this template with the following app label for the first port ( |
HAPROXY_HTTP_FRONTEND | Defines the access control list (ACL) that matches a particular host name. Unlike HAPROXY_HTTP_FRONTEND_ACL, this template only includes the ACL portion. It does not glue the access control list (ACL) to the backend. You should only use this template if you have multiple virtual hosts routing to the same backend.
The default template for You can override this template with the following app label for the first port ( |
HAPROXY_HTTP_FRONTEND | Defines the access control list (ACL) that matches a particular host name with a path. Unlike HAPROXY_HTTP_FRONTEND_ACL_WITH_PATH, this template only includes the ACL portion. It does not glue the access control list (ACL) to the backend. You should only use this template if you have multiple virtual hosts routing to the same backend.
The default template for You can override this template with the following app label for the first port ( |
HAPROXY_HTTP_FRONTEND | Defines the access control list (ACL) that matches a particular host name with a path and authentication method. Unlike HAPROXY_HTTP_FRONTEND_ACL_WITH_PATH, this template only includes the ACL portion. It does not glue the access control list (ACL) to the backend. You should only use this template if you have multiple virtual hosts routing to the same backend.
The default template for You can override this template with the following app label for the first port ( |
HAPROXY_HTTP_FRONTEND | Specifies the access control list (ACL) that glues a backend to the corresponding virtual host specified by the HAPROXY_HTTP_FRONTEND_HEAD setting through HTTP Basic authentication.
The default template for You can override this template with the following app label for the first port ( |
HAPROXY_HTTP_FRONTEND | Specifies the access control list (ACL) that glues a backend to the corresponding virtual host with the path specified by the HAPROXY_HTTP_FRONTEND_HEAD setting through HTTP Basic authentication.
The default template for You can override this template with the following app label for the first port ( |
HAPROXY_HTTP_FRONTEND | Specifies the access control list (ACL) that glues a backend to the corresponding virtual host with the path specified by the HAPROXY_HTTP_FRONTEND_HEAD setting.
The default template for You can override this template with the following app label for the first port ( |
HAPROXY_HTTP_FRONTEND | Specifies the access control list (ACL) that glues a backend to the corresponding app specified by the HAPROXY_HTTP_FRONTEND_APPID_HEAD setting.
The default template for You can override this template with the following app label for the first port ( |
HAPROXY_HTTP_FRONTEND | Specifies the HTTP frontend that binds to port *:9091 by default and gathers all apps in HTTP mode. To use this frontend to forward to your app, configure the app with HAPROXY_0_MODE=http then you can access it via a call to the :9091 with the header "X-Marathon-App-Id" set to the Marathon AppId. Note multiple HTTP ports being exposed by the same marathon app are not supported. Only the first HTTP port is available using this frontend.
This template is a global template that cannot be modified by service port or per application. The default template for |
HAPROXY_HTTP_FRONTEND_HEAD | Specifies the HTTP frontend that binds to port *:80 by default and gathers all virtual hosts as defined by the HAPROXY_{n}_VHOST label. This template is a global template that cannot be modified by service port or per application.
The default template for |
HAPROXY_HTTP_FRONTEND | Works in combination with the HAPROXY_HTTP_FRONTEND_ACL_ONLY setting to map access control list (ACL) names to their appropriate backends.
The default template for You can override this template with the following app label for the first port ( |
HAPROXY_HTTP_FRONTEND | Works in combination with the HAPROXY_HTTP_FRONTEND_ACL_ONLY setting to map the access control list name to the appropriate backend and to add HTTP Basic authentication.
The default template for You can override this template with the following app label for the first port ( |
HAPROXY_HTTP_FRONTEND | Works in combination with the HAPROXY_HTTP_FRONTEND_ACL_ONLY_WITH_PATH setting to map access control list (ACL) names to the appropriate backend.
The default template for You can override this template with the following app label for the first port ( |
HAPROXY_HTTP_FRONTEND | Works in combination with the HAPROXY_HTTP_FRONTEND_ACL_ONLY_WITH_PATH setting to map access control list names to the appropriate backend.
The default template for You can override this template with the following app label for the first port ( |
HAPROXY_MAP_HTTPS | Specifies the access control list (ACL) that performs the SNI-based host name matching for the HAPROXY_HTTPS_FRONTEND_HEAD template using HAProxy maps.
The default template for You can override this template with the following app label for the first port ( |
HAPROXY_MAP_HTTP | Specifies the access control list (ACL) that glues a backend to the corresponding virtual host specified by the HAPROXY_HTTP_FRONTEND_HEAD setting using HAProxy maps.
The default template for You can override this template with the following app label for the first port ( |
HAPROXY_MAP_HTTP | Defines the access control list (ACL) that matches a particular host name, You should only use this template if you have multiple virtual hosts routing to the same backend in the HAProxy map.
The default template for You can override this template with the following app label for the first port ( |
HAPROXY_MAP_HTTP | Specifies the access control list (ACL) that glues a backend to the corresponding app specified by the HAPROXY_HTTP_FRONTEND_APPID_HEAD setting using HAProxy maps.
The default template for You can override this template with the following app label for the first port ( |
User authentication list setting
Use the following template and app label to configure basic user name and password settings for the load balancer.
Template name | Description and examples |
---|---|
HAPROXY_USERLIST_HEAD | Specifies the user list for HTTP Basic authentication.
The default template for You can override this template with the following app label for the first port ( |
Global header settings
Use the following template to configure default header settings for the load balancer.
Template name | Description and examples |
---|---|
HAPROXY_HEAD | Specifies header information for the HAProxy configuration file. This template contains global settings and defaults. This template cannot be overridden by service port or application-based settings.
The default template for global log /dev/log local0 log /dev/log local1 notice spread-checks 5 max-spread-checks 15000 maxconn 50000 tune.ssl.default-dh-param 2048 ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:!aNULL:!MD5:!DSS ssl-default-bind-options no-sslv3 no-tlsv10 no-tls-tickets ssl-default-server-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:!aNULL:!MD5:!DSS ssl-default-server-options no-sslv3 no-tlsv10 no-tls-tickets stats socket /var/run/haproxy/socket expose-fd listeners server-state-file global server-state-base /var/state/haproxy/ lua-load /marathon-lb/getpids.lua lua-load /marathon-lb/getconfig.lua lua-load /marathon-lb/getmaps.lua lua-load /marathon-lb/signalmlb.lua defaults load-server-state-from-file global log global retries 3 backlog 10000 maxconn 10000 timeout connect 3s timeout client 30s timeout server 30s timeout tunnel 3600s timeout http-keep-alive 1s timeout http-request 15s timeout queue 30s timeout tarpit 60s option dontlognull option http-server-close option redispatch listen stats bind 0.0.0.0:9090 balance mode http stats enable monitor-uri /_haproxy_health_check acl getpid path /_haproxy_getpids http-request use-service lua.getpids if getpid acl getvhostmap path /_haproxy_getvhostmap http-request use-service lua.getvhostmap if getvhostmap acl getappmap path /_haproxy_getappmap http-request use-service lua.getappmap if getappmap acl getconfig path /_haproxy_getconfig http-request use-service lua.getconfig if getconfig acl signalmlbhup path /_mlb_signal/hup http-request use-service lua.signalmlbhup if signalmlbhup acl signalmlbusr1 path /_mlb_signal/usr1 http-request use-service lua.signalmlbusr1 if signalmlbusr1 |
Additional application labels
You can use the following labels to configure additional application settings.
Label name | Description and examples |
---|---|
HAPROXY_{n}_AUTH |
Specifies the HTTP authentication method to use for the application on the given service port index.
For example, you can use this label to specify the realm name for Basic authentication:
HAPROXY_0_AUTH = realm:username:encryptedpassword
For details on configuring authentication methods, see HTTP Basic authentication |
HAPROXY_{n}_BACKEND_ |
Sets the index of the port to use as the dedicated port for the backend health checks associated with a given service port. By default, the index for the backend health check is the same as the index used for the service port.
For example, if an app exposes two ports–
You can then specify that you want to use port 9001 to perform the backend health checks:
HAPROXY_0_BACKEND_HEALTHCHECK_PORT_INDEX=1
|
HAPROXY_{n}_BACKEND |
Sets the IP addresses (or IP address ranges) that have been granted access to the backend.
For example, you could set the following app label to restrict access to the specified IP addresses
HAPROXY_0_BACKEND_NETWORK_ALLOWED_ACL = '10.1.40.0/24 10.1.55.43'
By default, every IP address is allowed. |
HAPROXY_{n}_BACKEND_ |
Specifies the order in which to enforce permissions if there are multiple backends sharing the access control lists for virtual hosts and paths. For example, if you are using a virtual host and have path access control lists that are shared by multiple backends, the order of the ACLs affects how permissions are granted for the application.
With If you don’t specify a value, the default weight of zero (0) is used. By default, any backends that use
|
HAPROXY_{n}_BALANCE |
Sets the load balancing algorithm to be used in a backend. The default is `roundrobin`.
For example:
HAPROXY_0_BALANCE = 'leastconn'
|
HAPROXY_{n}_BIND_ADDR |
Binds the load balancer to the specific address for the service.
For example:
HAPROXY _0_BIND_ADDR = '10.0.0.42'
|
HAPROXY_{n}_BIND_ | Sets additional bind options.
For example:
HAPROXY_0_BIND_OPTIONS = 'ciphers AES128+EECDH:AES128+EDH force-tlsv12 no-sslv3 no-tlsv10'
|
HAPROXY_DEPLOYMENT |
Specifies an alternate service port to be used during a blue/green deployment. |
HAPROXY_DEPLOYMENT |
Specifies the color to use for blue/green deployment. This label is used if you run the `bluegreen_deploy.py` script to determine the state of a deployment. You generally do not need to modify this label setting unless you implement your own deployment orchestrator. |
HAPROXY_DEPLOYMENT |
Specifies the deployment group to which this app belongs. |
HAPROXY_DEPLOYMENT |
Specifies the time at which a deployment started. You generally do not need to modify this unless you implement your own deployment orchestrator. |
HAPROXY_DEPLOYMENT_ |
Specifies the target number of app instances to seek during deployment. You generally do not need to modify this unless you implement your own deployment orchestrator. |
HAPROXY_{n}_ENABLED |
Enables this backend. By default, all backends are enabled. To disable backends by default, specify the `--strict-mode` option.
For example:
|
HAPROXY_{n}_GROUP |
Specifies the HAProxy group per service. This app label enables you to use a different HAProxy group per service port. This label setting overrides `HAPROXY_GROUP` for the particular service. If you have both external and internal services running on same set of instances on different ports, you can use this setting to add them to different HAProxy configurations.
For example:
HAPROXY_0_GROUP = 'external'
HAPROXY_1_GROUP = 'internal'
If you run Similarly, if you run For example, you might have a load balancing configuration where a service running on
HAPROXY_0_GROUP = 'external'
HAPROXY_GROUP = 'internal'
In this example, there is no group setting defined for the second service. With this configuration, |
HAPROXY_{n}_HTTP_ |
Sets the location to use for mapping local server URLs to remote servers + URL.
For example:
|
HAPROXY_{n}_HTTP_ |
Sets the URL in HTTP response headers sent from a reverse proxied server. This label only updates the Location, Content-Location, and URL fields.
For example:
|
HAPROXY_{n}_MODE |
Sets the connection mode to either TCP or HTTP. The default is TCP.
The following exceptions apply:
If you don’t specify the If you have configured a health check for the given port and the protocol field is set to one of ‘HTTP’, ‘HTTPS’, ‘MESOS_HTTP’, ‘MESOS_HTTPS’, the mode is overridden to ‘http’, regardless of the value of the
HAPROXY_0_MODE = 'http'
|
HAPROXY_{n}_PATH |
Specifies the HTTP path to match, starting at the beginning. You can specify multiple paths separated by spaces. The syntax matches that of the `path_beg` configuration option used in other templates and labels.
To use the path routing, you must also define a virtual host. If you have multiple backends which share virtual hosts or paths, you can manually specify the order of the backend ACLs with the For example: |
HAPROXY_{n}_PORT |
Binds to the specified port number for the service. This setting overrides the servicePort which has to be unique. For example:
HAPROXY_0_PORT = 80
|
HAPROXY_{n}_REDIRECT_ |
Redirects HTTP traffic to HTTPS. Requires at least one virtual host be set. For example:
HAPROXY_0_REDIRECT_TO_HTTPS = true
|
HAPROXY_{n}_SSL_CERT |
Enables the given SSL certificate for TLS/SSL traffic.
For example:
HAPROXY_0_SSL_CERT = '/etc/ssl/cert.pem'
|
HAPROXY_{n}_STICKY |
Enables sticky request routing for the service. For example:
|
HAPROXY_{n}_USE_HSTS |
Enables the HSTS response header for the HTTP clients that support it. For example:
|
HAPROXY_{n}_VHOST |
Specifies the Marathon HTTP virtual host proxy host name(s) to gather.
If you have multiple backends that share the same virtual host names or paths, you might need to manually specify the appropriate order to use for the backend access control lists using the For example:
HAPROXY_0_VHOST = 'marathon.mesosphere.com'
|