[{"_1":2,"_162":-5,"_163":-5},"loaderData",{"_3":4,"_18":19,"_25":26,"_141":142},"root",{"_5":-5,"_6":-7,"_7":8,"_9":-7,"_10":11,"_12":-7,"_13":14,"_15":16,"_17":11},"currentUser","primaryEmail","siteVerification","6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI","toast","enableDev",false,"incidentStatus","theme","system","contrast","normal","dockerRebrandTour","routes/_layout",{"_20":-5,"_21":22,"_23":11,"_24":22},"username","isAskGordonEnabled",true,"showMinimalLanding","showHoneypotTrap","routes/_layout.r.$namespace.$reponame",{"_27":28,"_29":-5,"_30":11,"_31":11,"_32":33,"_34":35,"_36":-5,"_37":11,"_38":39,"_88":-5,"_89":90,"_129":-5,"_130":11,"_131":22,"_132":11,"_133":11,"_134":-5,"_135":11,"_136":-5,"_137":138,"_139":91,"_140":-7},"canonicalUrl","https://hub.docker.com/r/nossapps/entry-point/tags","mcpServer","canSeeDockerfile","canSeeAutobuilds","namespace","nossapps","reponame","entry-point","cloudBuildSource","isAutobuildsAvailable","repo",{"_40":41,"_42":43,"_45":46,"_47":48,"_49":11,"_50":51,"_52":53,"_54":55,"_57":35,"_32":33,"_58":59,"_60":44,"_61":62,"_63":64,"_65":66,"_67":-5,"_68":62,"_69":70,"_71":11,"_72":33,"_73":74,"_79":22,"_80":81,"_85":33,"_86":87},"categories",[],"content_types",[44],"image","date_registered","2018-08-30T05:00:13.742315Z","description","lb","is_private","last_updated","2018-08-30T05:13:42.107891Z","last_modified","2024-10-16T13:48:34.145251Z","media_types",[56],"application/vnd.docker.container.image.v1+json","name","pull_count",869,"repository_type","star_count",0,"status",1,"status_description","active","source","collaborator_count","full_description","<<<<<<< HEAD\n# marathon-lb\nScript to update haproxy based on marathon state.\n\nYou can run the script directly or using the Docker image.\n\n## Architecture\nThe marathon-lb script `marathon-update-haproxy.py` connect to the marathon API\nto retrieve all apps running, generates a haproxy config and reloads haproxy.\nBy default, marathon-lb binds to the service port of every application and\nsends incoming requests to the application instances.\nTo create a virtual host the HAPROXY_0_VHOST label needs to be set on the\ngiven application.\n\nSee [comments in script](marathon-update-haproxy.py) for all available options.\n\n## Deployment\n=======\n# marathon-lb [![Build Status](https://travis-ci.org/mesosphere/marathon-lb.svg?branch=master)](https://travis-ci.org/mesosphere/marathon-lb)\nMarathon-lb is a tool for managing HAProxy, by consuming [Marathon's](https://github.com/mesosphere/marathon) app state.\n\n### Features\n\n * **Stateless design**: no direct dependency on any third-party state store like ZooKeeper or etcd (_except through Marathon_)\n * **Real-time LB updates**, via [Marathon's event bus](https://mesosphere.github.io/marathon/docs/event-bus.html)\n * Support for Marathon's **health checks**\n * **Multi-cert SSL** support\n * Per-service **HAProxy templates**\n * DCOS integration\n * Automated Docker image builds ([mesosphere/marathon-lb](https://hub.docker.com/r/mesosphere/marathon-lb))\n * Global HAProxy templates which can be supplied at launch\n\n## Architecture\nThe marathon-lb script `marathon_lb.py` connects to the marathon API\nto retrieve all running apps, generates a HAProxy config and reloads HAProxy.\nBy default, marathon-lb binds to the service port of every application and\nsends incoming requests to the application instances.\n\nServices are exposed on their service port (see\n[Service Discovery & Load Balancing](https://mesosphere.github.io/marathon/docs/service-discovery-load-balancing)\nfor reference) as defined in their Marathon definition. Furthermore, apps are\nonly exposed on LBs which have the same LB tag (or group) as defined in the Marathon\napp's labels (using `HAPROXY_GROUP`). HAProxy parameters can be tuned by specify labels in your app.\n\nTo create a virtual host or hosts the `HAPROXY_{n}_VHOST` label needs to be set on the\ngiven application. Applications with a vhost set will be exposed on ports 80\nand 443, in addition to their service port. Multiple virtual hosts may be specified\nin `HAPROXY_{n}_VHOST` using a comma as a delimiter between hostnames.\n\nAll applications are also exposed on port 9091, using the `X-Marathon-App-Id`\nHTTP header. See the documentation for `HAPROXY_HTTP_FRONTEND_APPID_HEAD` in\nthe [templates section](#templates)\n\nYou can access the HAProxy statistics via `:9090/haproxy?stats`, and you can\nretrieve the current HAProxy config from the `:9090/_haproxy_getconfig` endpoint.\n\n## Deployment\nThe package is currently available [from the multiverse](https://github.com/mesosphere/multiverse).\n>>>>>>> 2d32fca325fef502450548207182bac4ebc2138f\nTo deploy the marathon-lb on the public slaves in your DCOS cluster,\nsimply run:\n\n```\ndcos package install marathon-lb\n```\n\nTo configure a custom ssl-certificate, set the dcos cli option `ssl-cert`\nto your concatenated cert and private key in .pem format. For more details\n<<<<<<< HEAD\nsee the [haproxy documentation](https://cbonte.github.io/haproxy-dconv/configuration-1.7.html#crt (Bind options)).\n\nFor further customization, templates can be added by pointing the dcos cli\noption `template-url` to a tarball containing a directory `templates/`.\nSee [comments in script](marathon-update-haproxy.py) on how to name those.\n\n## Caveats and Limitations\nSince marathon-lb needs to bind to the service ports dynamically and allocating\nthem is not possible with a simple marathon scheduled application, this\nimplementation it prone to port conflicts. To avoid those, ideally you only run\nthis service in your public slaves.\n\n### Docker\nSynopsis: `docker run mesosphere/marathon-lb event|poll ...`\n\nYou can pass in your own certificates for the SSL frontend by setting\nthe HAPROXY_SSL_CERT environment variable.\n\n#### sse mode\nIn SSE mode, the script connects to the marathon events endpoint to get\nnotified about state changes.\n\nSyntax: `docker run mesosphere/marathon-lb sse [other args]`\n\n#### event mode\nIn event mode, the script registers a http callback in marathon to get\n=======\nsee the [HAProxy documentation](https://cbonte.github.io/haproxy-dconv/configuration-1.7.html#crt (Bind options)).\n\nFor further customization, templates can be added by pointing the dcos cli\noption `template-url` to a tarball containing a directory `templates/`.\nSee [comments in script](marathon_lb.py) on how to name those.\n\n### Docker\nSynopsis: `docker run -e PORTS=$portnumber --net=host mesosphere/marathon-lb sse|event|poll ...`\n\nYou must set `PORTS` environment variable to allow haproxy bind to this port.\nSyntax: `docker run -e PORTS=9090 mesosphere/marathon-lb sse [other args]`\n\nYou can pass in your own certificates for the SSL frontend by setting\nthe `HAPROXY_SSL_CERT` environment variable.\n\n#### `sse` mode\nIn SSE mode, the script connects to the marathon events endpoint to get\nnotified about state changes. This only works with Marathon 0.11.0 or\nnewer versions.\n\nSyntax: `docker run mesosphere/marathon-lb sse [other args]`\n\n#### `event` mode\nIn event mode, the script registers a HTTP callback in marathon to get\n>>>>>>> 2d32fca325fef502450548207182bac4ebc2138f\nnotified when state changes.\n\nSyntax: `docker run mesosphere/marathon-lb event callback-addr:port [other args]`\n\n<<<<<<< HEAD\n#### poll mode\nIf you can't use the http callbacks, the script can poll the APIs to get\nthe schedulers state periodically.\n\nSynatax: `docker run mesosphere/marathon-lb poll [other args]`\n\nTo change the poll interval (defaults to 60s), you can set the POLL_INTERVALL\n=======\n#### `poll` mode\nIf you can't use the HTTP callbacks, the script can poll the APIs to get\nthe schedulers state periodically.\n\nSyntax: `docker run mesosphere/marathon-lb poll [other args]`\n\nTo change the poll interval (defaults to 60s), you can set the `POLL_INTERVAL`\n>>>>>>> 2d32fca325fef502450548207182bac4ebc2138f\nenvironment variable.\n\n### Direct invocation\nYou can also run the update script directly.\n<<<<<<< HEAD\nTo generate an HAProxy configuration from Marathon running at `localhost:8080` with the `marathon-update-haproxy.py` script, run:\n\n``` console\n$ ./marathon-update-haproxy.py --marathon http://localhost:8080 --haproxy-config /etc/haproxy/haproxy.cfg\n```\n\nThis will refresh haproxy.cfg, and if there were any changes, then it will automatically reload HAproxy.\n\n`marathon-update-haproxy.py` has a lot of additional functionality like sticky sessions, HTTP to HTTPS redirection, SSL offloading,\nVHost support and templating capabilities.\n\nTo get the full documentation run:\n``` console\n$ ./marathon-update-haproxy.py --help\n```\n=======\nTo generate an HAProxy configuration from Marathon running at `localhost:8080` with the `marathon_lb.py` script, run:\n\n``` console\n$ ./marathon_lb.py --marathon http://localhost:8080 --group external\n```\n\nIt is possible to pass `--auth-credentials=` option if your Marathon requires authentication:\n```\n$ ./marathon_lb.py --marathon http://localhost:8080 --auth-credentials=admin:password\n```\n\nThis will refresh `haproxy.cfg`, and if there were any changes, then it will\nautomatically reload HAProxy. Only apps with the label `HAPROXY_GROUP=external`\nwill be exposed on this LB.\n\n`marathon_lb.py` has a lot of additional functionality like sticky sessions, HTTP to HTTPS redirection, SSL offloading, virtual host support and templating capabilities.\n\nTo get the full documentation run:\n``` console\n$ ./marathon_lb.py --help\n```\n\n### Providing SSL certificates\nYou can provide your SSL certificate paths to be placed in frontend marathon_https_in section with `--ssl-certs`.\n\n``` console\n$ ./marathon_lb.py --marathon http://localhost:8080 --group external --ssl-certs /etc/ssl/site1.co,/etc/ssl/site2.co\n```\n\nIf you are using the script directly, you have two options:\n\n * Provide nothing and config will use `/etc/ssl/mesosphere.com.pem` as the certificate path. Put the certificate in this path or edit the file for the correct path.\n * Provide `--ssl-certs` command line argument and config will use these paths.\n\nIf you are using the provided `run` script or Docker image, you have three options:\n\n * Provide your certificate text in `HAPROXY_SSL_CERT` environment variable. Contents will be written to `/etc/ssl/mesosphere.com.pem`. Config will use this path unless you specified extra certificate paths as in the next option.\n * Provide SSL certificate paths with `--ssl-certs` command line argument. Your config will use these certificate paths.\n * Provide nothing and it will create self-signed certificate on `/etc/ssl/mesosphere.com.pem` and config will use it.\n\n\n### Skipping configuration validation\nYou can skip the configuration file validation (via calling HAProxy service) process if you don't have HAProxy installed. This is especially useful if you are running HAProxy on Docker containers.\n\n``` console\n$ ./marathon_lb.py --marathon http://localhost:8080 --group external --skip-validation\n```\n\n\n## HAProxy configuration\n\n### App labels\nApp labels are specified in the Marathon app definition. These can be used to override HAProxy behaviour. For example, to specify the `external` group for an app with a virtual host named `service.mesosphere.com`:\n\n```json\n{\n \"id\": \"http-service\",\n \"labels\": {\n \"HAPROXY_GROUP\":\"external\",\n \"HAPROXY_0_VHOST\":\"service.mesosphere.com\"\n }\n}\n```\n\nSome labels are specified _per service port_. These are denoted with the `{n}` parameter in the label key, where `{n}` corresponds to the service port index, beginning at `0`.\n\nThe full list of labels which can be specified are:\n```\n HAPROXY_GROUP\n The group of marathon-lb instances that point to the service.\n This is a global group for all services running on different vhosts in a application\n This can be overrided for each service port. If it is not overriden this will be default group.\n Load balancers with the group '*' will collect all groups.\n\n HAPROXY_DEPLOYMENT_GROUP\n Deployment group to which this app belongs.\n\n HAPROXY_DEPLOYMENT_ALT_PORT\n Alternate service port to be used during a blue/green deployment.\n\n HAPROXY_DEPLOYMENT_COLOUR\n Blue/green deployment colour. Used by the bluegreen_deploy.py script to determine the state of a deploy. You generally do not need to modify this unless you implement your own deployment orchestrator.\n\n HAPROXY_DEPLOYMENT_STARTED_AT\n The time at which a deployment started. You generally do not need to modify this unless you implement your own deployment orchestrator.\n\n HAPROXY_DEPLOYMENT_TARGET_INSTANCES\n 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.\n\n HAPROXY_{n}_VHOST\n The Marathon HTTP Virtual Host proxy hostname(s) to gather.\n Ex: HAPROXY_0_VHOST = 'marathon.mesosphere.com'\n Ex: HAPROXY_0_VHOST = 'marathon.mesosphere.com,marathon'\n\n HAPROXY_{n}_PATH\n The HTTP path to match, starting at the beginning. To specify multiple paths,\n pass a space separated list. The syntax matches that of the `path_beg` config\n option in HAProxy. To use the path routing, you must also define a VHost.\n Ex: HAPROXY_0_PATH = '/v2/api/derp'\n Ex: HAPROXY_0_PATH = '-i /multiple /paths'\n\n HAPROXY_{n}_STICKY\n Enable sticky request routing for the service.\n Ex: HAPROXY_0_STICKY = true\n\n HAPROXY_{n}_REDIRECT_TO_HTTPS\n Redirect HTTP traffic to HTTPS. Requires at least a VHost be set.\n Ex: HAPROXY_0_REDIRECT_TO_HTTPS = true\n\n HAPROXY_{n}_USE_HSTS\n Enable the HSTS response header for HTTP clients which support it.\n Ex: HAPROXY_0_USE_HSTS = true\n\n HAPROXY_{n}_SSL_CERT\n Enable the given SSL certificate for TLS/SSL traffic.\n Ex: HAPROXY_0_SSL_CERT = '/etc/ssl/certs/marathon.mesosphere.com'\n\n HAPROXY_{n}_BIND_OPTIONS\n Set additional bind options\n Ex: HAPROXY_0_BIND_OPTIONS = 'ciphers AES128+EECDH:AES128+EDH force-tlsv12 no-sslv3'\n\n HAPROXY_{n}_BIND_ADDR\n Bind to the specific address for the service.\n Ex: HAPROXY_0_BIND_ADDR = '10.0.0.42'\n\n HAPROXY_{n}_PORT\n Bind to the specific port for the service.\n This overrides the servicePort which has to be unique.\n Ex: HAPROXY_0_PORT = 80\n\n HAPROXY_{n}_GROUP\n Haproxy group per service. This helps us have different HA Proxy groups per service port.\n This overrides HAPROXY_GROUP for the particular service.\n If you have both external and internal services running on same set of instances on\n different ports, you can use this feature to add them to different haproxy configs.\n Ex: HAPROXY_0_GROUP = 'external'\n HAPROXY_1_GROUP = 'internal'\n\n Now if you run marathon_lb with --group external, it just adds the service on HAPROXY_0_PORT\n (or first service port incase HAPROXY_0_HOST is not configured) to haproxy config and similarly\n if you run it with --group internal, it adds service on HAPROXY_1_PORT to haproxy config.\n If the configuration is a combination of HAPROXY_GROUP and HAPROXY_{n}_GROUP,\n the more specific definition takes precedence.\n Ex: HAPROXY_0_GROUP = 'external'\n HAPROXY_GROUP = 'internal'\n\n Considering the above example where the configuration is hybrid, Service running on\n HAPROXY_0_PORT is associated with just 'external' haproxy group and not 'internal' group.\n And since there is no Haproxy group mentioned for second service (HAPROXY_1_GROUP not defined)\n it falls back to default HAPROXY_GROUP and gets associated with 'internal' group.\n\n\n HAPROXY_{n}_MODE\n Set the connection mode to either TCP or HTTP. The default is TCP.\n Ex: HAPROXY_0_MODE = 'http'\n\n HAPROXY_{n}_BALANCE\n Set the load balancing algorithm to be used in a backend. The default is roundrobin.\n Ex: HAPROXY_0_BALANCE = 'leastconn'\n```\n\n### Templates\n\nMarathon-lb searches for configuration files in the `templates/`\ndirectory. The `templates/` directory is located in a relative\npath from where the script is run. Some templates can also be\n[overridden _per app service port_](#overridable-templates). You may add your\nown templates to the Docker image, or provide them at startup.\n\n```\n HAPROXY_HEAD\n The head of the HAProxy config. This contains global settings\n and defaults.\n\n HAPROXY_HTTP_FRONTEND_HEAD\n An HTTP frontend that binds to port *:80 by default and gathers\n all virtual hosts as defined by the HAPROXY_{n}_VHOST variable.\n\n HAPROXY_HTTP_FRONTEND_APPID_HEAD\n An HTTP frontend that binds to port *:9091 by default and gathers\n all apps in HTTP mode.\n To use this frontend to forward to your app, configure the app with\n \"HAPROXY_0_MODE=http\" then you can access it via a call to the :9091 with\n the header \"X-Marathon-App-Id\" set to the Marathon AppId.\n Note multiple HTTP ports being exposed by the same marathon app are not\n supported. Only the first HTTP port is available via this frontend.\n\n HAPROXY_HTTPS_FRONTEND_HEAD\n An HTTPS frontend for encrypted connections that binds to port *:443 by\n default and gathers all virtual hosts as defined by the\n HAPROXY_{n}_VHOST variable. You must modify this file to\n include your certificate.\n\n HAPROXY_BACKEND_REDIRECT_HTTP_TO_HTTPS\n This template is used with backends where the\n HAPROXY_{n}_REDIRECT_TO_HTTPS label is set to true.\n\n HAPROXY_BACKEND_REDIRECT_HTTP_TO_HTTPS_WITH_PATH\n Same as HAPROXY_BACKEND_REDIRECT_HTTP_TO_HTTPS,\n but includes a path.\n\n HAPROXY_BACKEND_HSTS_OPTIONS\n This template is used for the backend where the\n HAPROXY_{n}_USE_HSTS label is set to true.\n\n HAPROXY_BACKEND_HTTP_OPTIONS\n Sets HTTP headers, for example X-Forwarded-For and X-Forwarded-Proto.\n\n HAPROXY_BACKEND_HTTP_HEALTHCHECK_OPTIONS\n Sets HTTP health check options, for example timeout check and httpchk GET.\n Parameters of the first health check for this service are exposed as:\n * healthCheckPortIndex\n * healthCheckPort\n * healthCheckProtocol\n * healthCheckPath\n * healthCheckTimeoutSeconds\n * healthCheckIntervalSeconds\n * healthCheckIgnoreHttp1xx\n * healthCheckGracePeriodSeconds\n * healthCheckMaxConsecutiveFailures\n * healthCheckFalls is set to healthCheckMaxConsecutiveFailures + 1\n * healthCheckPortOptions is set to \" port {healthCheckPort}\"\n Defaults to empty string.\n Example:\n option httpchk GET {healthCheckPath}\n timeout check {healthCheckTimeoutSeconds}s\n\n\n HAPROXY_BACKEND_TCP_HEALTHCHECK_OPTIONS\n Sets TCP health check options, for example timeout check.\n Parameters of the first health check for this service are exposed as:\n * healthCheckPortIndex\n * healthCheckPort\n * healthCheckProtocol\n * healthCheckTimeoutSeconds\n * healthCheckIntervalSeconds\n * healthCheckGracePeriodSeconds\n * healthCheckMaxConsecutiveFailures\n * healthCheckFalls is set to healthCheckMaxConsecutiveFailures + 1\n * healthCheckPortOptions is set to \" port {healthCheckPort}\"\n Defaults to empty string.\n Example:\n timeout check {healthCheckTimeoutSeconds}s\n\n HAPROXY_BACKEND_STICKY_OPTIONS\n Sets a cookie for services where HAPROXY_{n}_STICKY is true.\n\n HAPROXY_FRONTEND_HEAD\n Defines the address and port to bind to.\n\n HAPROXY_BACKEND_HEAD\n Defines the type of load balancing, roundrobin by default,\n and connection mode, TCP or HTTP.\n\n HAPROXY_HTTP_FRONTEND_ACL\n The ACL that glues a backend to the corresponding virtual host\n of the HAPROXY_HTTP_FRONTEND_HEAD.\n\n HAPROXY_HTTP_FRONTEND_ACL_ONLY\n Define the ACL matching a particular hostname, but unlike\n HAPROXY_HTTP_FRONTEND_ACL, only do the ACL portion. Does not glue\n the ACL to the backend. This is useful only in the case of multiple\n vhosts routing to the same backend\n\n HAPROXY_HTTP_FRONTEND_ROUTING_ONLY\n This is the counterpart to HAPROXY_HTTP_FRONTEND_ACL_ONLY which\n glues the acl name to the appropriate backend.\n\n HAPROXY_HTTP_FRONTEND_ACL_WITH_PATH\n The ACL that glues a backend to the corresponding virtual host with path\n of the HAPROXY_HTTP_FRONTEND_HEAD.\n\n HAPROXY_HTTP_FRONTEND_ACL_ONLY_WITH_PATH\n Define the ACL matching a particular hostname with path, but unlike\n HAPROXY_HTTP_FRONTEND_ACL_WITH_PATH, only do the ACL portion. Does not glue\n the ACL to the backend. This is useful only in the case of multiple\n vhosts routing to the same backend\n\n HAPROXY_HTTP_FRONTEND_ACL_ONLY_WITH_PATH\n Same as HAPROXY_HTTP_FRONTEND_ACL_ONLY_WITH_PATH except for HTTPS.\n\n HAPROXY_HTTP_FRONTEND_ROUTING_ONLY_WITH_PATH\n This is the counterpart to HAPROXY_HTTP_FRONTEND_ACL_ONLY_WITH_PATH which\n glues the acl names to the appropriate backend.\n\n HAPROXY_HTTP_FRONTEND_APPID_ACL\n The ACL that glues a backend to the corresponding app\n of the HAPROXY_HTTP_FRONTEND_APPID_HEAD.\n\n HAPROXY_HTTPS_FRONTEND_ACL\n The ACL that performs the SNI based hostname matching\n for the HAPROXY_HTTPS_FRONTEND_HEAD.\n\n HAPROXY_HTTPS_FRONTEND_ACL_WITH_PATH\n The ACL that performs the SNI based hostname matching with path\n for the HAPROXY_HTTPS_FRONTEND_HEAD.\n\n HAPROXY_BACKEND_SERVER_OPTIONS\n The options for each physical server added to a backend.\n\n\n HAPROXY_BACKEND_SERVER_HTTP_HEALTHCHECK_OPTIONS\n Sets HTTP health check options for a single server, e.g. check inter.\n Parameters of the first health check for this service are exposed as:\n * healthCheckPortIndex\n * healthCheckPort\n * healthCheckProtocol\n * healthCheckPath\n * healthCheckTimeoutSeconds\n * healthCheckIntervalSeconds\n * healthCheckIgnoreHttp1xx\n * healthCheckGracePeriodSeconds\n * healthCheckMaxConsecutiveFailures\n * healthCheckFalls is set to healthCheckMaxConsecutiveFailures + 1\n * healthCheckPortOptions is set to \" port {healthCheckPort}\"\n Defaults to empty string.\n Example:\n check inter {healthCheckIntervalSeconds}s fall {healthCheckFalls}\n\n HAPROXY_BACKEND_SERVER_TCP_HEALTHCHECK_OPTIONS\n Sets TCP health check options for a single server, e.g. check inter.\n Parameters of the first health check for this service are exposed as:\n * healthCheckPortIndex\n * healthCheckPort\n * healthCheckProtocol\n * healthCheckTimeoutSeconds\n * healthCheckIntervalSeconds\n * healthCheckGracePeriodSeconds\n * healthCheckMaxConsecutiveFailures\n * healthCheckFalls is set to healthCheckMaxConsecutiveFailures + 1\n * healthCheckPortOptions is set to \" port {healthCheckPort}\"\n\n Defaults to empty string.\n Example:\n check inter {healthCheckIntervalSeconds}s fall {healthCheckFalls}\n\n HAPROXY_FRONTEND_BACKEND_GLUE\n This option glues the backend to the frontend.\n```\n#### Overridable templates\n\nSome templates may be overridden using app labels,\nas per the [labels section](#app-labels). Strings are interpreted as literal\nHAProxy configuration parameters, with substitutions respected (as per the\n[templates section](#templates)). The HAProxy configuration will be validated\nfor correctness before reloading HAProxy after changes. **Note:** Since the\nHAProxy config is checked before reloading, if an app's HAProxy\nlabels aren't syntactically correct, HAProxy will not be reloaded and may\nresult in stale config.\n\nHere is an example for a service called `http-service` which requires that\n`http-keep-alive` be disabled:\n\n```json\n{\n \"id\": \"http-service\",\n \"labels\":{\n \"HAPROXY_GROUP\":\"external\",\n \"HAPROXY_0_BACKEND_HTTP_OPTIONS\":\" option forwardfor\\n no option http-keep-alive\\n http-request set-header X-Forwarded-Port %[dst_port]\\n http-request add-header X-Forwarded-Proto https if { ssl_fc }\\n\"\n }\n}\n```\n\nThe full list of per service port templates which can be specified are:\n```\nHAPROXY_{n}_FRONTEND_HEAD\nHAPROXY_{n}_BACKEND_REDIRECT_HTTP_TO_HTTPS\nHAPROXY_{n}_BACKEND_HEAD\nHAPROXY_{n}_HTTP_FRONTEND_ACL\nHAPROXY_{n}_HTTP_FRONTEND_ACL_ONLY\nHAPROXY_{n}_HTTP_FRONTEND_ROUTING_ONLY\nHAPROXY_{n}_HTTP_FRONTEND_ACL_WITH_PATH\nHAPROXY_{n}_HTTP_FRONTEND_ACL_ONLY_WITH_PATH\nHAPROXY_{n}_HTTPS_FRONTEND_ACL_ONLY_WITH_PATH\nHAPROXY_{n}_HTTP_FRONTEND_ROUTING_ONLY_WITH_PATH\nHAPROXY_{n}_HTTP_FRONTEND_APPID_ACL\nHAPROXY_{n}_HTTPS_FRONTEND_ACL\nHAPROXY_{n}_HTTPS_FRONTEND_ACL_WITH_PATH\nHAPROXY_{n}_BACKEND_HTTP_OPTIONS\nHAPROXY_{n}_BACKEND_HSTS_OPTIONS\nHAPROXY_{n}_BACKEND_HTTP_HEALTHCHECK_OPTIONS\nHAPROXY_{n}_BACKEND_TCP_HEALTHCHECK_OPTIONS\nHAPROXY_{n}_BACKEND_STICKY_OPTIONS\nHAPROXY_{n}_BACKEND_SERVER_OPTIONS\nHAPROXY_{n}_BACKEND_SERVER_TCP_HEALTHCHECK_OPTIONS\nHAPROXY_{n}_BACKEND_SERVER_HTTP_HEALTHCHECK_OPTIONS\nHAPROXY_{n}_FRONTEND_BACKEND_GLUE\n```\n\n## Zero downtime deployments\n\nMarathon-lb is able to perform canary style blue/green deployment with zero downtime. To execute such deployments, you must follow certain patterns when using Marathon.\n\nThe deployment method is described [in this Marathon document](https://mesosphere.github.io/marathon/docs/blue-green-deploy.html). Marathon-lb provides an implementation of the aforementioned deployment method with the script [`bluegreen_deploy.py`](bluegreen_deploy.py). To perform a zero downtime deploy using `bluegreen_deploy.py`, you must:\n\n\n- Specify the `HAPROXY_DEPLOYMENT_GROUP` and `HAPROXY_DEPLOYMENT_ALT_PORT` labels in your app template\n - `HAPROXY_DEPLOYMENT_GROUP`: This label uniquely identifies a pair of apps belonging to a blue/green deployment, and will be used as the app name in the HAProxy configuration\n - `HAPROXY_DEPLOYMENT_ALT_PORT`: An alternate service port is required because Marathon requires service ports to be unique across all apps\n- Only use 1 service port: multiple ports are not yet implemented\n- Use the provided `bluegreen_deploy.py` script to orchestrate the deploy: the script will make API calls to Marathon, and use the HAProxy stats endpoint to gracefully terminate instances\n- The marathon-lb container must be run in privileged mode (to execute `iptables` commands) due to the issues outlined in the excellent blog post by the [Yelp engineering team found here](http://engineeringblog.yelp.com/2015/04/true-zero-downtime-haproxy-reloads.html)\n- If you have long-lived TCP connections using the same HAProxy instances, it may cause the deploy to take longer than necessary. The script will wait up to 5 minutes (by default) for connections to drain from HAProxy between steps, but any long-lived TCP connections will cause old instances of HAProxy to stick around.\n\nAn example minimal configuration for a [test instance of nginx is included here](tests/1-nginx.json). You might execute a deployment from a CI tool like Jenkins with:\n\n```\n./bluegreen_deploy.py -j 1-nginx.json -m http://master.mesos:8080 -f -l http://marathon-lb.marathon.mesos:9090 --syslog-socket /dev/null\n`","has_starred","hub_user","immutable_tags_settings",{"_75":11,"_76":77},"enabled","rules",[78],".*","is_automated","permissions",{"_82":22,"_83":11,"_84":11},"read","write","admin","user","storage_size",354119422,"orgData","recentTags",[91],{"_92":44,"_93":94,"_95":96,"_97":98,"_99":100,"_50":118,"_119":94,"_120":33,"_121":56,"_57":122,"_123":124,"_125":109,"_126":118,"_127":66,"_128":22},"content_type","creator",696152,"full_size",199710429,"id",34216783,"images",[101],{"_102":103,"_104":105,"_106":107,"_108":109,"_110":111,"_112":113,"_114":107,"_115":-5,"_116":96,"_63":66,"_117":-5},"architecture","amd64","digest","sha256:75d792914cc2bce537c1bf084094803876fca19228cb40c393bc14e0f3eec77a","features","","last_pulled","2026-10-19T21:04:17.429981823Z","last_pushed","2018-08-30T05:13:41Z","os","linux","os_features","os_version","size","variant","2018-08-30T05:13:41.010959Z","last_updater","last_updater_username","media_type","latest","repository",5951024,"tag_last_pulled","tag_last_pushed","tag_status","v2","sbxKitMetadata","isPotentialSpam","isHubSbxKitsEnabled","showSbxRunInCloud","showSbxLogoOverride","sbxTrademarkText","displaySecurityMetadata","tagAttestations","tagsHaveAttestations",[],"selectedTag","attestationsUrl","routes/_layout.r.$namespace.$reponame.tags",{"_38":143,"_150":151,"_137":160,"_161":11},{"_40":144,"_42":145,"_45":46,"_47":48,"_49":11,"_50":51,"_52":53,"_54":146,"_57":35,"_32":33,"_58":59,"_60":44,"_61":62,"_63":64,"_65":66,"_67":-5,"_68":62,"_69":70,"_71":11,"_72":33,"_73":147,"_79":22,"_80":149,"_85":33,"_86":87},[],[44],[56],{"_75":11,"_76":148},[78],{"_82":22,"_83":11,"_84":11},"tags",{"_152":64,"_153":-5,"_154":-5,"_155":156},"count","next","previous","results",[157],{"_92":44,"_93":94,"_95":96,"_97":98,"_99":158,"_50":118,"_119":94,"_120":33,"_121":56,"_57":122,"_123":124,"_125":109,"_126":118,"_127":66,"_128":22},[159],{"_102":103,"_104":105,"_106":107,"_108":109,"_110":111,"_112":113,"_114":107,"_115":-5,"_116":96,"_63":66,"_117":-5},[],"canDeleteTags","actionData","errors"]

nossapps/entry-point

Tags for nossapps/entry-point