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