In this blog post we´ll take a look at how the scheduler controls in Docker UCP interact with Kubernetes taints and tolerations. Both are used to control what workloads are allowed to run on manager and DTR (Docker Trusted Registry) nodes. Docker EE UCP mangers nodes are also Kubernetes master nodes, and in production systems it is important to restrict what runs on the manager (master) and DTR nodes. We’ll walk through deploying a Kubernetes workload on every node in a Docker EE cluster.Continue reading
Recently I’ve been hosting workshops for a customer who is exploring migrating from Docker Swarm orchestration to Kubernetes orchestration. The customer is currently using Docker EE (Enterprise Edition) 2.1, and plans to continue using that platform, just leveraging Kubernetes rather than Swarm. There are a number of advantages to continuing to use Docker EE including:
- Pre-installed Kubernetes.
- Group (team) and user management, including corporate LDAP integration.
- Using the Docker UCP client bundle to configure both your Kubernetes and Docker client environment.
- Availability of an on-premises registry (DTR) that includes advanced features such image scanning and image promotion.
I had already conducted a workshop on deploying applications as Docker services in stack files (compose files deployed as Docker stacks), demonstrating self-healing replicated applications, service discovery and the ability to publish ports externally using the Docker ingress network. Continue reading
Docker Trusted Registry (DTR) in a Docker Enterprise Edition (EE) cluster allows users to create a private image repository for their own use. They may want to do this when they want to use the cluster for their work but don’t want to or can’t use their own system or they’re not ready yet to share it with others. However, using a private image repository in a Kubernetes deployment requires some additional steps. In this post, I will show you how to setup the repository and use it in your deployment.
The Docker Universal Control Plane provides a wealth of information about the Docker cluster. There is information for both Swarm and Kubernetes. There are tons of detailed information about stacks, services, containers, networks, volumes, pods, namespaces, service accounts, controllers, load balancers, pods, configurations, storage, etc. (I think you get the point).Continue reading
The Single-Cluster architecture utilizes a single Docker Swarm cluster with multiple collections to separate the dev, test, and prod worker machines and combined with RBAC it enforces work load isolation of applications across the various runtime environments. Applications deployed to this Single-Cluster can utilize the Interlock reverse proxy capabilities of SSL termination and path based routing. This single Interlock application supports all three collections and the routing of application traffic.
In this article I will show you how to configure Interlock to run in a multi-service-cluster configuration which gains you isolation and dedication of Interlock Proxy instances to each of the dev, test, and prod collections.Continue reading
For Kubernetes in a Docker Enterprise Edition (EE) 2.1 cluster, namespaces can be used to segregate objects and, with Role Based Access Control (RBAC), designate which users or groups can do what within each of them. In this post, we are going to create three namespaces for development, test and production environments, four groups for the development, test, operations and management teams and access controls defining what each of these groups can do in each of these namespaces.
I recently helped a development team that was running into problems while deploying their containerized application to a Docker Swarm cluster. This application was written in .NET and its primary purpose is to listen on a socket for messages and then process the data. The application was working standalone outside of a container, but we ran into issues whenever we tried accessing it via the Docker Ingress network. The socket server never received any messages from the client. I thought it might help if I showed you how we worked the issue.Continue reading
When you create a user in Docker Enterprise Edition (EE), that user can immediately create a Swarm service on the cluster. All they need to do is generate, download, unzip and “execute” their client bundle. However, on the Kubernetes side Role Based Access Control (RBAC) and the default user permissions are quite a bit different. I will show you how to get a similar experience with Kubernetes that you get with the out-of-the-box experience of Swarm.
Most enterprises have a structured release management process that allows phased deployment between multiple environments including development, test, model (stage or acceptance), and production. https://en.wikipedia.org/wiki/Deployment_environment.
With Docker Enterprise Swarm you can generally setup these environments in one of the following ways: Single Cluster, Multi-Env Cluster, Geo-Single Clusters, and Geo-Multi-Env Cluster. I will explain these different approaches and help you determine when each approach might be useful in your enterprise. Of course, there are a myriad of variations on each of these that you could employ to suit your own needs.
It’s been nearly 3 months since my last blog about new the Layer 7 Routing (aka Interlock) in Docker Enterprise 2.0. It’s been a journey of up’s and down’s to get this to work, scale, and become stable enough for a production environment. I’m not sure we can declare total success just yet.
Near the end of my previous blog post I mentioned that there is an alternative configuration for Interlock regarding overlay networks. You could utilize Interlock’s host mode networking. Docker states the following:
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.