docker
/
docs
mirror of https://github.com/docker/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

add disclaimer for consistency across layer7 docs (#9774) 

* add disclaimer for consistency across layer7 docs

added disclaimer found in /ee/ucp/interlock/deploy/upgrade/

* Fix formatting
This commit is contained in:
Carlton Caven 2019-12-16 10:17:53 -08:00 committed by Traci Morrison
parent f2f78508c7
commit 75f0949927
1 changed files with 25 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

48
ee/ucp/interlock/index.md
View File

@ -1,20 +1,23 @@
--- ---
title: Layer 7 routing overview title: Layer 7 routing overview
description: Learn how to route layer 7 traffic to your Swarm services description: Learn how to route Layer 7 traffic to your Swarm services
keywords: routing, UCP, interlock, load balancing keywords: routing, UCP, interlock, load balancing
--- ---
Application-layer (Layer 7) routing is the application routing and load balancing (ingress routing) system included with Docker Enterprise for Swarm orchestration. Interlock architecture takes advantage of the underlying Swarm components to provide scalable Layer 7 routing and Layer 4 VIP mode functionality. Application-layer (Layer 7) routing is the application routing and load balancing (ingress routing) system included with Docker Enterprise for Swarm orchestration. Interlock architecture takes advantage of the underlying Swarm components to provide scalable Layer 7 routing and Layer 4 VIP mode functionality.
> Note
>
> The HTTP routing mesh functionality was redesigned in UCP 3.0 for greater security and flexibility. The functionality was also renamed to “Layer 7 routing” to make it easier for new users to get started.
Interlock is specific to the Swarm orchestrator. If you're trying to route Interlock is specific to the Swarm orchestrator. If you're trying to route
traffic to your Kubernetes applications, check traffic to your Kubernetes applications, refer to [Layer 7 routing with Kubernetes](../kubernetes/layer-7-routing.md) for more information.
[layer 7 routing with Kubernetes.](../kubernetes/layer-7-routing.md)
Interlock uses the Docker Remote API to automatically configure extensions such as NGINX or HAProxy for application traffic. Interlock is designed for: Interlock uses the Docker Remote API to automatically configure extensions such as NGINX or HAProxy for application traffic. Interlock is designed for:
- Full integration with Docker (Swarm, Services, Secrets, Configs) - Full integration with Docker (Swarm, Services, Secrets, Configs)
- Enhanced configuration (context roots, TLS, zero downtime deploy, rollback) - Enhanced configuration (context roots, TLS, zero downtime deploy, rollback)
- Support for external load balancers (nginx, haproxy, F5, etc) via extensions - Support for external load balancers (NGINX, HAProxy, F5, etc) via extensions
- Least privilege for extensions (no Docker API access) - Least privilege for extensions (no Docker API access)
Docker Engine running in swarm mode has a routing mesh, which makes it easy Docker Engine running in swarm mode has a routing mesh, which makes it easy
@ -28,22 +31,22 @@ 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 WordPress using the domain name or IP of any of the nodes that are part of
the swarm. the swarm.
UCP extends this one step further with layer 7 layer routing (also known as UCP extends this one step further with Layer 7 layer routing (also known as
application layer 7), allowing users to access Docker services using domain names application Layer 7), allowing users to access Docker services using domain names
instead of IP addresses. This functionality is made available through the Interlock component. instead of IP addresses. This functionality is made available through the Interlock component.
![layer 7 routing](../images/interlock-overview-2.svg) ![layer 7 routing](../images/interlock-overview-2.svg)
Using Interlock in the previous example, users can access the WordPress service using Using Interlock in the previous example, users can access the WordPress service using
`http://wordpress.example.org`. Interlock takes care of routing traffic to `http://wordpress.example.org`. Interlock takes care of routing traffic to
the right place. the correct place.
## Terminology ## Terminology
- Cluster: A group of compute resources running Docker - Cluster: A group of compute resources running Docker
- Swarm: A Docker cluster running in Swarm mode - Swarm: A Docker cluster running in Swarm mode
- Upstream: An upstream container that serves an application - Upstream: An upstream container that serves an application
- Proxy Service: A service that provides load balancing and proxying (such as Nginx) - Proxy Service: A service that provides load balancing and proxying (such as NGINX)
- Extension Service: A helper service that configures the proxy service - Extension Service: A helper service that configures the proxy service
- Service Cluster: A service cluster is an Interlock extension+proxy service - Service Cluster: A service cluster is an Interlock extension+proxy service
- gRPC: A high-performance RPC framework - gRPC: A high-performance RPC framework
@ -51,27 +54,26 @@ the right place.
![Interlock Design](../images/interlock-design.png) ![Interlock Design](../images/interlock-design.png)
## Interlock services ## Interlock services
Interlock has Interlock has three primary services:
three primary services:
* **Interlock**: This is the central piece of the layer 7 routing solution. * **Interlock**: This is the central piece of the Layer 7 routing solution.
The core service is responsible for interacting with the Docker Remote API and building The core service is responsible for interacting with the Docker Remote API and building
an upstream configuration for the extensions. It uses the Docker API to monitor events, and manages the extension and an upstream configuration for the extensions. It uses the Docker API to monitor events, and manages the extension and
proxy services. This is served on a gRPC API that the proxy services. This is served on a gRPC API that the
extensions are configured to access. extensions are configured to access.
* **Interlock-extension**: This is a helper service that queries the Interlock gRPC API for the * **Interlock-extension**: This is a helper service that queries the Interlock gRPC API for the
upstream configuration. The extension service uses this to configure upstream configuration. The extension service uses this to configure
the proxy service. For proxy services that use files such as Nginx or HAProxy, the 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 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. then updates the corresponding Docker Config object for the proxy service.
* **Interlock-proxy**: This is a proxy/load-balancing service that handles requests for the upstream application services. These * **Interlock-proxy**: This is a proxy/load-balancing service that handles requests for the upstream application services. These
are configured using the data created by the corresponding extension service. By default, this service is a containerized are configured using the data created by the corresponding extension service. By default, this service is a containerized
NGINX deployment. NGINX deployment.
Interlock manages both extension and proxy service updates for both configuration changes Interlock manages both extension and proxy service updates for both configuration changes
and application service deployments. There is no intervention from the operator required. and application service deployments. There is no intervention from the operator required.
The following image shows the default Interlock configuration, once you enable layer 7 The following image shows the default Interlock configuration, once you enable Layer 7
routing in UCP: routing in UCP:
![](../images/interlock-architecture-1.svg) ![](../images/interlock-architecture-1.svg)
@ -87,7 +89,7 @@ components run on manager nodes.
Layer 7 routing in UCP supports: Layer 7 routing in UCP supports:
* **High availability**: All the components used for layer 7 routing leverage * **High availability**: All the components used for Layer 7 routing leverage
Docker swarm for high availability, and handle failures gracefully. Docker swarm for high availability, and handle failures gracefully.
* **Automatic configuration**: Interlock uses the Docker API for configuration. You do not have to manually * **Automatic configuration**: Interlock uses the Docker API for configuration. You do not have to manually
update or restart anything to make services available. UCP monitors your services and automatically update or restart anything to make services available. UCP monitors your services and automatically
@ -97,20 +99,20 @@ operator to individually customize and scale the proxy layer to handle user requ
* **TLS**: You can leverage Docker secrets to securely manage TLS Certificates * **TLS**: You can leverage Docker secrets to securely manage TLS Certificates
and keys for your services. Both TLS termination and TCP passthrough are supported. and keys for your services. Both TLS termination and TCP passthrough are supported.
* **Context-based routing**: Interlock supports advanced application request routing by context or path. * **Context-based routing**: Interlock supports advanced application request routing by context or path.
* **Host mode networking**: By default, layer 7 routing leverages the Docker Swarm * **Host mode networking**: By default, Layer 7 routing leverages the Docker Swarm
routing mesh, but Interlock supports running proxy and application services in "host" mode networking, allowing routing mesh, but Interlock supports running proxy and application services in "host" mode networking, allowing
you to bypass the routing mesh completely. This is beneficial if you want you to bypass the routing mesh completely. This is beneficial if you want
maximum performance for your applications. maximum performance for your applications.
* **Security**: The layer 7 routing components that are exposed to the outside * **Security**: The Layer 7 routing components that are exposed to the outside
world run on worker nodes. Even if they are compromised, your cluster aren't. world run on worker nodes. Even if they are compromised, your cluster is not affected.
* **SSL**: Interlock leverages Docker Secrets to securely store and use SSL certificates for services. Both * **SSL**: Interlock leverages Docker Secrets to securely store and use SSL certificates for services. Both
SSL termination and TCP passthrough are supported. SSL termination and TCP passthrough are supported.
* **Blue-Green and Canary Service Deployment**: Interlock 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 * **Blue-Green and Canary Service Deployment**: Interlock 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 easily reversible. can scale the older version to zero. If there is a problem, the operation is easily reversible.
* **Service Cluster Support**: Interlock supports multiple extension+proxy combinations allowing for operators to partition load * **Service Cluster Support**: Interlock supports multiple extension+proxy combinations allowing for operators to partition load
balancing resources for uses such as region or organization based load balancing. balancing resources for uses such as region or organization based load balancing.
* **Least Privilege**: Interlock supports (and recommends) being deployed where the load balancing * **Least Privilege**: Interlock supports (and recommends) being deployed where the load balancing
proxies do not need to be colocated with a Swarm manager. This makes the 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. deployment more secure by not exposing the Docker API access to the extension or proxy services.
## Next steps ## Next steps