diff --git a/_data/toc.yaml b/_data/toc.yaml index 9ac8df4f1f..bed96aef10 100644 --- a/_data/toc.yaml +++ b/_data/toc.yaml @@ -1693,10 +1693,12 @@ manuals: path: /ee/ucp/swarm/deploy-to-collection/ - title: Use secrets in your services path: /ee/ucp/swarm/use-secrets/ - - sectiontitle: Route traffic to your apps + - sectiontitle: Layer 7 routing section: - - title: Layer 7 routing overview + - title: Overview path: /ee/ucp/interlock/ + - title: Architecture + path: /ee/ucp/interlock/architecture/ - sectiontitle: Introduction section: - title: What is Layer 7 routing diff --git a/ee/ucp/images/interlock-architecture-1.svg b/ee/ucp/images/interlock-architecture-1.svg index befd3385d3..b6382bad32 100644 --- a/ee/ucp/images/interlock-architecture-1.svg +++ b/ee/ucp/images/interlock-architecture-1.svg @@ -1,23 +1,25 @@ - + interlock-architecture-1 Created with Sketch. + + + + + - + - Docker swarm managed with UCP + Docker swarm managed with UCP - - - - - node-3 - + + + @@ -30,6 +32,52 @@ interlock-proxy:80 + + + + + worker node + + + + + + + + + + UCP + + + + + + interlock-proxy:80 + + + + + + + worker node + + + + + + + + + + UCP + + + + + + interlock-extension + + @@ -46,51 +94,16 @@ - - - node-2 - - - - - UCP - - - - - - interlock-extension - - - - - - interlock-proxy:80 - - - - - - - worker node - - - - - - - node-1 - UCP - + ucp-interlock @@ -108,21 +121,21 @@ - + - + - your load balancer + your load balancer - + - + @@ -130,13 +143,62 @@ - - + + http://wordpress.example.org:80 + + + + wordpress-net + + + + + + + + + + + + + + + + + + + + + + + + + + + ucp-interlock + + + + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/ee/ucp/interlock/architecture.md b/ee/ucp/interlock/architecture.md new file mode 100644 index 0000000000..bb1a0ecd82 --- /dev/null +++ b/ee/ucp/interlock/architecture.md @@ -0,0 +1,68 @@ +--- +title: Interlock architecture +description: Learn about Layer 7 routing, an application routing and load balancing system + for Docker Swarm. +keywords: ucp, interlock, load balancing +ui_tabs: +- version: ucp-3.0 + orhigher: false +--- + +{% if include.version=="ucp-3.0" %} + +The layer 7 routing solution for swarm workloads is known as Interlock, and has +three components: + +* **Interlock-proxy**: This is a proxy/load-balancing service that handles the +requests from the outside world. By default this service is a containerized +NGINX deployment. +* **Interlock-extension**: This service monitors changes in your services and +generates the configuration used by the proxy service. +* **Interlock**: This is the central piece of the layer 7 routing solution. +It uses the Docker API to monitor events, and manages the extension and +proxy services. + +This is what the default configuration looks like, once you enable layer 7 +routing in UCP: + +![](../images/interlock-architecture-1.svg) + +An Interlock service starts running on a manager node, an Interlock-extension +service starts running on a worker node, and two replicas of the +Interlock-proxy service run on worker nodes. + +## Routing lifecycle + +By default layer 7 routing is disabled, so an administrator first needs to +enable this service from the UCP web UI. + +Once that happens, UCP creates the `ucp-interlock` overlay network. Then the +`ucp-interlock` service starts and attaches to the Docker socket and the overlay +network that was created. This allows the Interlock service to use the +Docker API. That's also the reason why this service needs to run on a manger +node. + +The `ucp-interlock` service then starts the `ucp-interlock-extension` service +and attaches it to the `ucp-interlock` network. This allows both services +to communicate. + +The `ucp-interlock-extension` then generates a configuration to be used by +the proxy service. By default the proxy service is NGINX, so this service +generates a standard NGING configuration. + +Finally, the `ucp-interlock` service takes this configuration and uses it to +start the `ucp-interlock-proxy` service. + +At this point everything is ready for you to start using this service in your +applications. + +You deploy your service and apply labels to it describing how the proxy +service should route traffic to that service. Once this happens, the +`ucp-interlock-extension` service generates a new configuration based on those +labels and forwards it to the `ucp-interlock` service, which in turn uses this +to redeploy the `ucp-interlock-proxy` with the new settings. + +This all happens in milliseconds and with rolling updates, so that service +is never disrupted for incoming traffic. + +{% endif %} diff --git a/ee/ucp/interlock/index.md b/ee/ucp/interlock/index.md index 9516cfed88..944a84cc64 100644 --- a/ee/ucp/interlock/index.md +++ b/ee/ucp/interlock/index.md @@ -2,7 +2,7 @@ title: Layer 7 routing overview description: Learn about Layer 7 routing, an application routing and load balancing system for Docker Swarm. -keywords: ucp, layer 7, routing, load balancing +keywords: ucp, interlock, routing, proxy ui_tabs: - version: ucp-3.0 orhigher: false @@ -16,48 +16,47 @@ redirect_from: --- {% if include.version=="ucp-3.0" %} -Layer 7 routing is an application routing and load balancing system for Docker Swarm. It uses -the Docker Remote API to automatically configure extensions such as Nginx or HAProxy for -application traffic. +Docker Engine running in swarm mode has a routing mesh, which makes it easy +to expose your services to the outside world. Since all nodes participate +in the routing mesh, users can access your service by contacting any node. -## About +![swarm routing mess](../images/interlock-overview-1.svg) -- [Introduction](intro/index.md) - - [What is Layer 7 routing](intro/index.md) - - [Architecture](intro/architecture.md) +In this example the WordPress service is listening on port 8000 of the routing +mesh. Even though the service is running on a single node, users can access +WordPress using the domain name or IP of any of the nodes that are part of +the swarm. -## Deployment +UCP extends this one step further with application layer routing (also known +as layer 7 routing), allowing users to access Docker services using domain names +instead of IP addresses. -- [Get started](install/index.md) -- [Deploy Layer 7 routing manually](install/manual-deployment.md) -- [Deploy Layer 7 routing offline](install/offline.md) -- [Deploy Layer 7 routing for production](install/production.md) +![layer 7 routing](../images/interlock-overview-2.svg) -## Configuration +In this example, users can access the WordPress service using +`http://wordpress.example.org`. UCP and Docker Engine take care of routing +the traffic to the right service. -- [Layer 7 routing configuration](configuration/index.md) -- [Service labels](configuration/service-labels.md) +## Features and benefits -## Extensions +Layer 7 routing in UCP supports: -- [NGINX](extensions/nginx.md) -- [HAProxy](extensions/haproxy.md) - -## Usage - -- [Basic deployment](usage/index.md) -- [Applications with SSL](usage/ssl.md) -- [Application redirects](usage/redirects.md) -- [Persistent (sticky) sessions](usage/sessions.md) -- [Websockets](usage/websockets.md) -- [Canary application instances](usage/canary.md) -- [Service clusters](usage/service-clusters.md) -- [Context/path based routing](usage/context.md) -- [Host mode networking](usage/host-mode-networking.md) - -## Operations - -- [Updates](ops/index.md) -- [Tuning](ops/tuning.md) +* **High availability**: All the components used for layer 7 routing leverage +Docker swarm for high availability, and handle failures gracefully. +* **Automatic configuration**: UCP monitors your services and automatically +reconfigures the proxy services so that everything handled for you. +* **Scalability**: You can customize and tune the proxy services that handle +user-facing requests to meet whatever demand your services have. +* **TLS**: You can leverage Docker secrets to securely manage TLS Certificates +and keys for your services. Both TLS termination and TCP passthrough are supported. +* **Context-based routing**: You can define where to route the request based on +context or path. +* **Host mode networking**: By default layer 7 routing leverages the Docker Swarm +routing mesh, but you don't have to. You can use host mode networking for maximum +performance. +* **Blue-green and canary deployments**: You can deploy a new version of your application +while traffic is still being routed to the old one. +* **Security**: The layer 7 routing components that are exposed to the outside +world run on worker nodes. Even if they get compromised, your cluster won't. {% endif %} diff --git a/ee/ucp/interlock/intro/architecture.md b/ee/ucp/interlock/intro/architecture.md deleted file mode 100644 index a7aacef3c5..0000000000 --- a/ee/ucp/interlock/intro/architecture.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: Layer 7 routing architecture -description: Learn about Layer 7 routing, an application routing and load balancing system - for Docker Swarm. -keywords: ucp, interlock, load balancing -ui_tabs: -- version: ucp-3.0 - orhigher: false ---- - -{% if include.version=="ucp-3.0" %} - -The following are definitions that are used: - -- Cluster: A group of compute resources running Docker -- Swarm: A Docker cluster running in Swarm mode -- Upstream: An upstream container that serves an application -- Proxy Service: A service that provides load balancing and proxying (such as Nginx) -- Extension Service: A helper service that configures the proxy service -- Service Cluster: A service cluster is an Interlock extension+proxy service -- GRPC: A high-performance RPC framework - -## Services -Layer 7 routing runs entirely as Docker Swarm services. There are three core services -in an Interlock routing layer: core, extension and proxy. - -## Core -The core service is responsible for interacting with the Docker Remote API and building -an upstream configuration for the extensions. This is served on a GRPC API that the -extensions are configured to access. - -## Extension -The extension service is a helper service that queries the Layer 7 routing GRPC API for the -upstream configuration. The extension service uses this to configure -the proxy service. For proxy services that use files such as Nginx or HAProxy the -extension service generates the file and sends it to Interlock using the GRPC API. Interlock -then updates the corresponding Docker Config object for the proxy service. - -## Proxy -The proxy service handles the actual requests for the upstream application services. These -are configured using the data created by the corresponding extension service. - -Layer 7 routing manages both the extension and proxy service updates for both configuration changes -and application service deployments. There is no intervention from the operator required. - -{% endif %} diff --git a/ee/ucp/interlock/intro/index.md b/ee/ucp/interlock/intro/index.md deleted file mode 100644 index 68b7e70780..0000000000 --- a/ee/ucp/interlock/intro/index.md +++ /dev/null @@ -1,67 +0,0 @@ ---- -title: What is Layer 7 routing -description: Learn about Layer 7 routing, an application routing and load balancing system - for Docker Swarm. -keywords: ucp, interlock, load balancing -ui_tabs: -- version: ucp-3.0 - orhigher: false ---- - -{% if include.version=="ucp-3.0" %} - -Layer 7 routing is an application routing proxy service for Docker. - -## Design Goals - -- Fully integrate with Docker (Swarm, Services, Secrets, Configs) -- Enhanced configuration (context roots, TLS, zero downtime deploy, rollback) -- Support external load balancers (nginx, haproxy, F5, etc) via extensions -- Least privilege for extensions (no Docker API access) - -Layer 7 routing was designed to be a first class application routing layer for Docker. -The following are the high level features it provides: - -## Automatic Configuration -Layer 7 routing uses the Docker API for configuration. The user does not have to manually -update or restart anything to make services available. - -## Native Swarm Support -Layer 7 routing is fully Docker native. It runs on Docker Swarm and routes traffic using -cluster networking and Docker services. - -## High Availability -Layer 7 routing runs as Docker services which are highly available and handle failures gracefully. - -## Scalability -Layer 7 routing uses a modular design where the proxy service is separate. This allows an -operator to individually customize and scale the proxy layer to whatever demand. This is -transparent to the user and causes no downtime. - -## SSL -Layer 7 routing leverages Docker Secrets to securely store and use SSL certificates for services. Both -SSL termination and TCP passthrough are supported. - -## Context Based Routing -Layer 7 routing supports advanced application request routing by context or path. - -## Host Mode Networking -Layer 7 routing supports running the proxy and application services in "host" mode networking allowing -the operator to bypass the routing mesh completely. This is beneficial if you want -maximum performance for your applications. - -## Blue-Green and Canary Service Deployment -Layer 7 routing supports blue-green service deployment allowing an operator to deploy a new application -while the current version is serving. Once traffic is verified to the new application the operator -can scale the older version to zero. If there is a problem the operation is quickly reversible. - -## Service Cluster Support -Layer 7 routing supports multiple extension+proxy combinations allowing for operators to partition load -balancing resources for uses such as region or organization based load balancing. - -## Least Privilege -Layer 7 routing supports (and recommends) being deployed where the load balancing -proxies do not need to be colocated with a Swarm manager. This makes the -deployment more secure by not exposing the Docker API access to the extension or proxy services. - -{% endif %} diff --git a/ee/ucp/interlock/new-arch.md b/ee/ucp/interlock/new-arch.md deleted file mode 100644 index d7c3fc8f02..0000000000 --- a/ee/ucp/interlock/new-arch.md +++ /dev/null @@ -1,30 +0,0 @@ -# Layer 7 routing architecture - -The layer 7 routing solution for swarm workloads has three components: - -* **Interlock-proxy**: This is a proxy/load-balancing service that handles the -requests from the outside world. By default this service is an NGINX load -balancer. -* **Interlock-extension**: This service generates the configuration for the -proxy service. For this reason it needs to match the proxy service -you're using. If your proxy is NGINX, you need to use the NGINX Interlock extension. -* **Interlock**: This is the central piece of the layer 7 routing solution. -It uses the Docker API to listen for events and keep track of your services. -When something changes in your services, it uses a new configuration generated by -the extension service and automatically reconfigures the proxy service to use -the new configuration. - -This is what the default configuration looks like, once you enable layer 7 -routing in UCP: - -![](../images/interlock-architecture-1.svg) - -An Interlock service starts running on a manager node, an Interlock-extension -service starts running on a worker node, and two replicas of the -Interlock-proxy service run on worker nodes. - -## Interlock service - -## Extension service - -## Proxy service diff --git a/ee/ucp/interlock/new.md b/ee/ucp/interlock/new.md deleted file mode 100644 index 74c7e8c32a..0000000000 --- a/ee/ucp/interlock/new.md +++ /dev/null @@ -1,44 +0,0 @@ -# Layer 7 routing overview - -Docker Engine running in swarm mode has a routing mesh, which makes it easy -to expose your services to the outside world. Since all nodes participate -in the routing mesh, users can access your service by contacting any node. - -![swarm routing mess](../images/interlock-overview-1.svg) - -In this example the WordPress service is listening on port 8000 of the routing -mesh. Even though the service is running on a single node, users can access -WordPress using the domain name or IP of any of the nodes that are part of -the swarm. - -UCP extends this one step further with application layer routing (also known -as layer 7 routing), allowing users to access Docker services using domain names -instead of IP addresses. - -![layer 7 routing](../images/interlock-overview-2.svg) - -In this example, users can access the WordPress service using -`http://wordpress.example.org`. UCP and Docker Engine take care of routing -the traffic to the right service. - -## Features and benefits - -Layer 7 routing in UCP supports: - -* **High availability**: All the components used for layer 7 routing leverage -Docker swarm for high availability, and handle failures gracefully. -* **Automatic configuration**: UCP monitors your services and automatically -reconfigures the proxy services so that everything handled for you. -* **Scalability**: You can customize and tune the proxy services that handle -user-facing requests to meet whatever demand your services have. -* **TLS**: You can leverage Docker secrets to securely manage TLS Certificates -and keys for your services. Both TLS termination and TCP passthrough are supported. -* **Context-based routing**: You can define where to route the request based on -context or path. -* **Host mode networking**: By default layer 7 routing leverages the Docker Swarm -routing mesh, but you don't have to. You can use host mode networking for maximum -performance. -* **Blue-green and canary deployments**: You can deploy a new version of your application -while traffic is still being routed to the old one. -* **Security**: The layer 7 routing components that are exposed to the outside -world run on worker nodes. Even if they get compromised, your cluster won't.