Merge branch 'master' of https://github.com/docker/docs-private into landing-pages

.ruby-version

@@ -1 +1 @@
-2.3.1
+2.3.6

ee/ucp/interlock/index.md

@@ -1,20 +1,23 @@
 ---
 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
 ---
 
 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
-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:
 
 - Full integration with Docker (Swarm, Services, Secrets, Configs)
 - 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)
 
 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
 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.
 
 ![layer 7 routing](../images/interlock-overview-2.svg)
 
 Using Interlock in the previous example, users can access the WordPress service using
 `http://wordpress.example.org`. Interlock takes care of routing traffic to
-the right place.
+the correct place.
 
 ## Terminology
 
 - 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)
+- 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
@@ -51,27 +54,26 @@ the right place.
 ![Interlock Design](../images/interlock-design.png)
 
 ## 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
 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
 extensions are configured to access.
 * **Interlock-extension**: This is a helper service that queries the Interlock 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
+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.
-* **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
 NGINX deployment.
 
 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:
 
 ![](../images/interlock-architecture-1.svg)
@@ -87,7 +89,7 @@ components run on manager nodes.
 
 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.
 * **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
@@ -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
 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.
-* **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
 you to bypass the routing mesh completely. This is beneficial if you want
 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.
-* **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
 balancing resources for uses such as region or organization based 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.
 
 ## Next steps

ee/ucp/interlock/usage/redirects.md

@@ -1,12 +1,15 @@
 ---
 title: Implement application redirects
-description: Learn how to implement redirects using swarm services and the
+description: Learn how to implement redirects using swarm services and the Layer 7 routing solution for UCP.
-  layer 7 routing solution for UCP.
 keywords: routing, proxy, redirects, interlock
 ---
 
 The following example publishes a service and configures a redirect from `old.local` to `new.local`.
 
+> Note
+>
+> There is currently a limitation where redirects do not work if a service is configured for TLS passthrough in Interlock proxy.
+
 First, create an overlay network so that service traffic is isolated and secure:
 
 ```bash

ee/ucp/kubernetes/storage/use-azure-files.md

@@ -6,15 +6,15 @@ redirect_from:
 ---
 
 Platform operators can provide persistent storage for workloads running on
-Docker Enterprise and Microsoft Azure by using Azure Files. You can either 
+Docker Enterprise and Microsoft Azure by using Azure Files. You can either
 pre-provision Azure Files Shares to be consumed by
 Kubernetes Pods or can you use the Azure Kubernetes integration to dynamically
 provision Azure Files Shares on demand.
 
 ## Prerequisites
 
-This guide assumes you have already provisioned a UCP environment on 
+This guide assumes you have already provisioned a UCP environment on
-Microsoft Azure. The cluster must be provisioned after meeting all 
+Microsoft Azure. The cluster must be provisioned after meeting all
 prerequisites listed in [Install UCP on
 Azure](/ee/ucp/admin/install/install-on-azure.md).
 
@@ -29,8 +29,8 @@ Access](/ee/ucp/user-access/cli/).
 You can use existing Azure Files Shares or manually provision new ones to
 provide persistent storage for Kubernetes Pods. Azure Files Shares can be
 manually provisioned in the Azure Portal using ARM Templates or using the Azure
-CLI. The following example uses the Azure CLI to manually provision 
+CLI. The following example uses the Azure CLI to manually provision
-Azure Files Shares. 
+Azure Files Shares.
 
 ### Creating an Azure Storage Account
 
@@ -40,7 +40,7 @@ a Storage Account, you can skip to [Creating an Azure Files
 Share](#creating-an-azure-file-share).
 
 > **Note**: the Azure Kubernetes Driver does not support Azure Storage Accounts
-> created using Azure Premium Storage. 
+> created using Azure Premium Storage.
 
 ```bash
 $ REGION=ukwest
@@ -81,7 +81,7 @@ $ az storage share create \
 After a File Share has been created, you must load the Azure Storage
 Account Access key as a Kubernetes Secret into UCP. This provides access to
 the file share when Kubernetes attempts to mount the share into a pod. This key
-can be found in the Azure Portal or retrieved as shown in the following example by the Azure CLI: 
+can be found in the Azure Portal or retrieved as shown in the following example by the Azure CLI:
 
 ```bash
 $ SA=mystorageaccount
@@ -140,7 +140,7 @@ Classes](https://kubernetes.io/docs/concepts/storage/storage-classes/).
 
 > Today, only the Standard Storage Class is supported when using the Azure
 > Kubernetes Plugin. File shares using the Premium Storage Class will fail to
-> mount. 
+> mount.
 
 ```bash
 $ cat <<EOF | kubectl create -f -
@@ -156,6 +156,8 @@ mountOptions:
   - gid=1000
 parameters:
   skuName: Standard_LRS
+  storageAccount: <existingstorageaccount> # Optional
+  location: <existingstorageaccountlocation> # Optional
 EOF
 ```
 
@@ -171,14 +173,13 @@ azurefile  kubernetes.io/azure-file   1m
 
 After you create a Storage Class, you can use Kubernetes
 Objects to dynamically provision Azure Files Shares. This is done using
-Kubernetes Persistent Volumes Claims
+Kubernetes [Persistent Volumes Claims](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#introduction).
-[PVCs](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#introduction).
+Kubernetes uses an existing Azure Storage Account if one exists inside of the
-Kubernetes uses an existing Azure Storage Account if one exists inside of the 
 Azure Resource Group. If an Azure Storage Account does not exist,
-Kubernetes creates one. 
+Kubernetes creates one.
 
 The following example uses the standard storage class and creates a 5 GB Azure
-File Share. Alter these values to fit your use case. 
+File Share. Alter these values to fit your use case.
 
 ```bash
 $ cat <<EOF | kubectl create -f -
@@ -196,7 +197,7 @@ spec:
 EOF
 ```
 
-At this point, you should see a newly created Persistent Volume Claim and Persistent Volume: 
+At this point, you should see a newly created Persistent Volume Claim and Persistent Volume:
 
 ```bash
 $ kubectl get pvc
@@ -238,6 +239,50 @@ spec:
 EOF
 ```
 
+### Troubleshooting
+
+When creating Persistent Volume Claims, the volume may constantly stay in a
+`Pending` state.
+
+```
+$ kubectl get pvc
+NAME             STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
+azure-file-pvc   Pending                                      standard       32s
+```
+
+If that is the case, the `persistent-volume-binder` service account does not
+have the relevant Kubernetes RBAC permissions. The storage account creates a
+Kubernetes secret to store the Azure Files Storage Account Key.
+
+```
+$ kubectl describe pvc azure-file-pvc
+...
+Warning    ProvisioningFailed  7s (x3 over 37s)  persistentvolume-controller
+Failed to provision volume with StorageClass "standard": Couldn't create secret
+secrets is forbidden: User "system:serviceaccount:kube-system:persistent-volume-binder"
+cannot create resource "secrets" in API group "" in the namespace "default": access denied
+```
+
+To grant the `persistent-volume-binder` service account the relevant the RBAC
+permissions, create the following RBAC ClusterRole.
+
+```
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRoleBinding
+metadata:
+  labels:
+    subjectName: kube-system-persistent-volume-binder
+  name: kube-system-persistent-volume-binder:cluster-admin
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: ClusterRole
+  name: cluster-admin
+subjects:
+- kind: ServiceAccount
+  name: persistent-volume-binder
+  namespace: kube-system
+```
+
 ## Where to go next
 
 - [Deploy an Ingress Controller on

ee/ucp/release-notes.md

@@ -432,9 +432,9 @@ leading to a gap in permissions checks.  (ENGORC-2781)
 | Component      | Version |
 | ----------- | ----------- |
 | UCP      | 3.1.12 |
-| Kubernetes   | 1.14.3 |
+| Kubernetes   | 1.11.10 |
-| Calico      | 3.5.7 |
+| Calico      | 3.8.2 |
-| Interlock   | 2.4.0 |
+| Interlock   | 3.0.0 |
 | Interlock NGINX proxy | 1.14.2 |
 
 ## 3.1.11