Interlock Service Clusters

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

Functional Kubernetes Namespaces in Docker Enterprise

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.
Continue reading

Accessing .NET Sockets thru Docker Ingress

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

Create a Kubernetes User Sandbox in Docker Enterprise

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.
Continue reading