Skip to content

Use service labels#

Interlock uses service labels to configure how applications are published, to define the host names that are routed to the service, to define the applicable ports, and to define other routing configurations.

The following occurs when you deploy or update a Swarm service with service labels:

  1. The ucp-interlock service monitors the Docker API for events and publishes the events to the ucp-interlock-extension service.

  2. The ucp-interlock-extension service generates a new configuration for the proxy service based on the labels you have added to your services.

  3. The ucp-interlock service takes the new configuration and reconfigures ucp-interlock-proxy to start using the new configuration.

This process occurs in milliseconds and does not interrupt services.

The following table lists the service labels that Interlock uses:

Label Description Example
com.docker.lb.hosts Comma-separated list of the hosts for the service to serve. example.com, test.com
com.docker.lb.port Port to use for internal upstream communication. 8080
com.docker.lb.network Name of the network for the proxy service to attach to for upstream connectivity. app-network-a
com.docker.lb.context_root Context or path to use for the application. /app
com.docker.lb.context_root_rewrite Changes the path from the value of label com.docker.lb.context_root to / when set to true. true
com.docker.lb.ssl_cert Docker secret to use for the SSL certificate. example.com.cert
com.docker.lb.ssl_key Docker secret to use for the SSL key. example.com.key
com.docker.lb.websocket_endpoints Comma-separated list of endpoints to be upgraded for websockets. /ws,/foo
com.docker.lb.service_cluster Name of the service cluster to use for the application. us-east
com.docker.lb.sticky_session_cookie Cookie to use for sticky sessions. app_session
com.docker.lb.redirects Semicolon-separated list of redirects to add in the format of <source>, <target>. http://old.example.com, http://new.example.com
com.docker.lb.ssl_passthrough Enables SSL passthrough when set to true. false
com.docker.lb.backend_mode Selects the backend mode that the proxy should use to access the upstreams. The default is task. vip
com.docker.lb.max_fails Available as of MKE 3.9.6 Sets the number of failed connection attempts to an upstream server, within the fail_timeout window, after which NGINX considers the server unavailable. A higher value makes the proxy more tolerant of transient failures. Must be a non-negative integer. Interlock treats 0 as an unset label.

For the procedure, refer to Configure passive health checks for upstream servers.

Default: 1		 1000
com.docker.lb.fail_timeout Available as of MKE 3.9.6 Sets the time window over which NGINX counts max_fails failures, and the length of time NGINX considers the server unavailable once that threshold is reached. Accepts an NGINX time value such as 10s, 30s, or 1m. NGINX interprets a bare number as seconds.

For the procedure, refer to Configure passive health checks for upstream servers.

Default: 10s		 2s