From a6dafedfe235ffce5be41eb5573517151c37f115 Mon Sep 17 00:00:00 2001 From: Joao Fernandes Date: Tue, 13 Mar 2018 18:09:20 -0700 Subject: [PATCH] Review Interlock production deployment --- .../images/interlock-deploy-production-1.svg | 207 ++++++++++++++++++ ee/ucp/interlock/deploy/index.md | 30 +++ ee/ucp/interlock/deploy/production.md | 92 ++++++++ ee/ucp/interlock/enable.md | 0 ee/ucp/interlock/install/index.md | 54 ----- ee/ucp/interlock/install/production.md | 91 -------- 6 files changed, 329 insertions(+), 145 deletions(-) create mode 100644 ee/ucp/images/interlock-deploy-production-1.svg create mode 100644 ee/ucp/interlock/deploy/index.md create mode 100644 ee/ucp/interlock/deploy/production.md create mode 100644 ee/ucp/interlock/enable.md delete mode 100644 ee/ucp/interlock/install/index.md delete mode 100644 ee/ucp/interlock/install/production.md diff --git a/ee/ucp/images/interlock-deploy-production-1.svg b/ee/ucp/images/interlock-deploy-production-1.svg new file mode 100644 index 0000000000..48ccb3f7ca --- /dev/null +++ b/ee/ucp/images/interlock-deploy-production-1.svg @@ -0,0 +1,207 @@ + + + + interlock-deploy-production-1 + Created with Sketch. + + + + + + + + Docker swarm managed with UCP + + + + + + node-6 + + + + + UCP + + + + + + interlock-proxy:80 + + + + + + + worker node + + + + + + + + node-5 + + + + + UCP + + + + + + interlock-proxy:80 + + + + + interlock-proxy:80 + + + + + + + worker node + + + + + + + + node-4 + + + + + UCP + + + + + + interlock-extension + + + + + + wordpress:8000 + + + + + + + worker node + + + + + + + + + + node-3 + + + + + UCP + + + + + + + manager node + + + + + + + + node-2 + + + + + UCP + + + + + + + manager node + + + + + + + + node-1 + + + + + UCP + + + + + + ucp-interlock + + + + + + + manager node + + + + + + + + + + + + your load balancer + + + + + + + + + + + + + + + + + + + + + http://wordpress.example.org + + + + + + \ No newline at end of file diff --git a/ee/ucp/interlock/deploy/index.md b/ee/ucp/interlock/deploy/index.md new file mode 100644 index 0000000000..439df53949 --- /dev/null +++ b/ee/ucp/interlock/deploy/index.md @@ -0,0 +1,30 @@ +--- +title: Enable ayer 7 routing +description: Learn about Layer 7 routing, an application routing and load balancing system + for Docker Swarm. +keywords: ucp, layer 7, routing, load balancing +ui_tabs: +- version: ucp-3.0 + orhigher: false +- version: ucp-2.2 +--- + +{% if include.version=="ucp-3.0" %} + +To enable support for layer 7 routing, also known as HTTP routing mesh, +log in to the UCP web UI as an administrator, navigate to the **Admin Settings** +page, and click the **Routing Mesh** option. Check the **Enable routing mesh** option. + +![http routing mesh](../../images/interlock-install-3.png){: .with-border} + +By default, the routing mesh service listens on port 80 for HTTP and port +8443 for HTTPS. Change the ports if you already have services that are using +them. + +Once you save, the layer 7 routing service can be used by your swarm services. + +{% elsif include.version=="ucp-2.2" %} + +* [Configure UCP 2.2 HTTP routing mesh](/datacenter/ucp/2.2/guides/admin/configure/use-domain-names-to-access-services.md) + +{% endif %} diff --git a/ee/ucp/interlock/deploy/production.md b/ee/ucp/interlock/deploy/production.md new file mode 100644 index 0000000000..ea5b03d619 --- /dev/null +++ b/ee/ucp/interlock/deploy/production.md @@ -0,0 +1,92 @@ +--- +title: Configure layer 7 routing for production +description: Learn about Interlock, 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 solution that ships out of the box with UCP is highly available +and fault tolerant. It is also designed to work independently of how many +nodes you're managing with UCP. + +![production deployment](../../images/interlock-deploy-production-1.svg) + +For a production-grade deployment, you should tune the default deployment to +have two nodes dedicated for running the two replicas of the +`ucp-interlock-proxy` service. This makes sure: + +* The proxy services have dedicated resources to handle user requests. You +can configure these nodes with higher performance network interfaces. +* No application traffic can be routed to a manager node. This makes the +deployment secure. +* The proxy service is running on two nodes. If one node fails layer 7 routing +still works. + +To achieve this you need to: + +1. Enable layer 7 routing. [Learn how](index.md). +2. Pick two nodes that are going to be dedicated to run the proxy service. +3. Apply labels to those nodes, so that you can constrain the proxy service to +only run on nodes with those labels. +4. Update the proxy service with the constraint. +5. Configure your load balancer to route traffic to the dedicated nodes only. + +## Apply labels to nodes + +In this example, we've chose node-5 and node-6 to be dedicated just for running +the proxy service. To apply labels to those nodes run: + +```bash +docker node update --label-add nodetype=loadbalancer +``` + +To make sure the label was successfully applied, run: + +{% raw %} +```bash +docker node inspect --format '{{ index .Spec.Labels "nodetype" }}' +``` +{% endraw %} + +The command should print "loadbalancer". + +## Configure the proxy service + +Now that your nodes are labelled, you can add a constraint to the +`ucp-interlock-proxy`service, so make sure it only gets scheduled on nodes +with the right label: + +```bash +docker service update \ + --detach \ + --constraint-add node.labels.nodetype==loadbalancer \ + --stop-signal SIGTERM \ + --stop-grace-period 5s \ + $(docker service ls -f 'label=type=com.docker.interlock.core.proxy' -q) +``` + +This updates the proxy service to only be scheduled on node with the the +"loadbalancer" label. It also stops the task with a `SIGTERM` signal and gives +them five seconds to terminate, which allows the proxy service to stop accepting +new requests and finished serving existing requests from users. + +Now you can check if the proxy service is running on the dedicated nodes: + +``` +docker service ps ucp-interlock-proxy +``` + +## Configure your load balancer + +Once the proxy service is running on a dedicated node, configure your upstream +load balancer with the domain names or IP addresses of the nodes running +the proxy service. + +This makes sure all traffic is directed to these nodes. + +{% endif %} diff --git a/ee/ucp/interlock/enable.md b/ee/ucp/interlock/enable.md new file mode 100644 index 0000000000..e69de29bb2 diff --git a/ee/ucp/interlock/install/index.md b/ee/ucp/interlock/install/index.md deleted file mode 100644 index ec3b23626a..0000000000 --- a/ee/ucp/interlock/install/index.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: Get started with Layer 7 routing -description: Learn about Layer 7 routing, an application routing and load balancing system - for Docker Swarm. -keywords: ucp, layer 7, routing, load balancing -ui_tabs: -- version: ucp-3.0 - orhigher: false -- version: ucp-2.2 ---- - -{% if include.version=="ucp-3.0" %} - -Docker Enterprise Edition has a routing mesh that allows you to make your -services available to the outside world using a domain name. This is also -known as a layer 7 load balancer. - -![swarm routing mesh](../../images/interlock-install-1.svg) - -In this example, the WordPress service is being served on port 8000. -Users can access WordPress using the IP address of any node in the cluster -and port 8000. If WordPress is not running in that node, the -request is redirected to a node that is. - -Docker EE extends this and provides a routing mesh for application-layer -load balancing. This allows you to access services with HTTP and HTTPS -endpoints using a domain name instead of an IP. - -![http routing mesh](../../images/interlock-install-2.svg) - -In this example, the WordPress service listens on port 8000, but it is made -available to the outside world as `wordpress.example.org`. - -When users access `wordpress.example.org`, the HTTP routing mesh routes -the request to the service running WordPress in a way that is transparent to -them. - -## Enable the routing mesh - -To enable the HTTP routing mesh, Log in as an administrator, go to the -UCP web UI, navigate to the **Admin Settings** page, and click the -**Routing Mesh** option. Check the **Enable routing mesh** option. - -![http routing mesh](../../images/interlock-install-3.png){: .with-border} - -By default, the routing mesh service listens on port 80 for HTTP and port -8443 for HTTPS. Change the ports if you already have services that are using -them. - -{% elsif include.version=="ucp-2.2" %} - -* [Configure UCP 2.2 HTTP routing mesh](/datacenter/ucp/2.2/guides/admin/configure/use-domain-names-to-access-services.md) - -{% endif %} diff --git a/ee/ucp/interlock/install/production.md b/ee/ucp/interlock/install/production.md deleted file mode 100644 index 475d26c41f..0000000000 --- a/ee/ucp/interlock/install/production.md +++ /dev/null @@ -1,91 +0,0 @@ ---- -title: Deploy Interlock for Production -description: Learn about Interlock, 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" %} - -## Production Deployment -In this section you will find documentation on configuring Interlock -for a production environment. If you have not yet deployed Interlock please -see the [Getting Started](index.md) section as this information builds upon the -basic deployment. This example will not cover the actual deployment of infrastructure. -It assumes you have a vanilla Swarm cluster (`docker init` and `docker swarm join` from the nodes). -See the [Swarm](https://docs.docker.com/engine/swarm/) documentation if you need help -getting a Swarm cluster deployed. - -In this example we will configure an eight (8) node Swarm cluster. There are three (3) managers -and five (5) workers. Two of the workers are configured with node labels to be dedicated -ingress cluster load balancer nodes. These will receive all application traffic. -There is also an upstream load balancer (such as an Elastic Load Balancer or F5). The upstream -load balancers will be statically configured for the two load balancer worker nodes. - -This configuration has several benefits. The management plane is both isolated and redundant. -No application traffic hits the managers and application ingress traffic can be routed -to the dedicated nodes. These nodes can be configured with higher performance network interfaces -to provide more bandwidth for the user services. - -![Interlock 2.0 Production Deployment](interlock_production_deploy.png) - -## Node Labels -We will configure the load balancer worker nodes (`lb-00` and `lb-01`) with node labels in order to pin the Interlock Proxy -service. Once you are logged into one of the Swarm managers run the following to add node labels -to the dedicated ingress workers: - -```bash -$> docker node update --label-add nodetype=loadbalancer lb-00 -lb-00 -$> docker node update --label-add nodetype=loadbalancer lb-01 -lb-01 -``` - -You can inspect each node to ensure the labels were successfully added: - -```bash -{% raw %} -$> docker node inspect -f '{{ .Spec.Labels }}' lb-00 -map[nodetype:loadbalancer] -$> docker node inspect -f '{{ .Spec.Labels }}' lb-01 -map[nodetype:loadbalancer] -{% endraw %} -``` - -## Configure Proxy Service -Once we have the node labels we can re-configure the Interlock Proxy service to be constrained to those -workers. Again, from a manager run the following to pin the proxy service to the ingress workers: - -```bash -$> docker service update --replicas=2 \ - --constraint-add node.labels.nodetype==loadbalancer \ - --stop-signal SIGTERM \ - --stop-grace-period=5s \ - $(docker service ls -f 'label=type=com.docker.interlock.core.proxy' -q) -``` - -This updates the proxy service to have two (2) replicas and ensure they are constrained to -the workers with the label `nodetype==loadbalancer` as well as configure the stop signal for the tasks -to be a `SIGTERM` with a grace period of five (5) seconds. This will ensure that Nginx closes the connections -before exiting to ensure the client request is finished. - -Inspect the service to ensure the replicas have started on the desired nodes: - -```bash -$> docker service ps $(docker service ls -f 'label=type=com.docker.interlock.core.proxy' -q) -ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS -o21esdruwu30 interlock-proxy.1 nginx:alpine lb-01 Running Preparing 3 seconds ago -n8yed2gp36o6 \_ interlock-proxy.1 nginx:alpine mgr-01 Shutdown Shutdown less than a second ago -aubpjc4cnw79 interlock-proxy.2 nginx:alpine lb-00 Running Preparing 3 seconds ago -``` - -Once configured you can update the settings in the upstream load balancer (ELB, F5, etc) with the -addresses of the dedicated ingress workers. This will direct all traffic to these nodes. - -You have now configured Interlock for a dedicated ingress production environment. See the [Configuration](/config/interlock/) section -if you want to continue tuning. - -{% endif %}