Under the Hood: Demystifying Docker Enterprise Edition 2.0 Architecture

Estimated Reading Time: 8 minutes

The Only Kubernetes Solution for Multi-Linux, Multi-OS and Multi-Cloud Deployments is right here…

Docker Enterprise Edition(EE) 2.0 Final GA release is available. One of the most promising feature announced with this release includes Kubernetes integration as an optional orchestration solution, running side-by-side with Docker Swarm. Not only this, this release includes Swarm Layer 7 routing improvements, Registry image mirroring, Kubernetes integration to Docker Trusted Registry & Kubernetes integration to Docker EE access controls. With this new release, organizations will be able to deploy applications with either Swarm or fully-conformant Kubernetes while maintaining the consistent developer-to-IT workflow.

Docker EE is more than just a container orchestration solution; it is a full lifecycle management solution for the modernization of traditional applications and microservices across a broad set of infrastructure platforms. It is a Containers-as-a-Service(CaaS) platform for IT that manages and secures diverse applications across disparate infrastructure, both on-premises and in the cloud. Docker EE provides an integrated, tested and certified platform for apps running on enterprise Linux or Windows operating systems and Cloud providers. It is tightly integrated to the underlying infrastructure to provide a native, easy to install experience and an optimized Docker environment.

Docker EE 2.0 GA consists of 3 major components which together enable a full software supply chain, from image creation, to secure image storage, to secure image deployment.

  • Universal Control Plane 3.0.0 (application and cluster management) – Deploys applications from images, by managing orchestrators, like Kubernetes and Swarm. UCP is designed for high availability (HA). You can join multiple UCP manager nodes to the cluster, and if one manager node fails, another takes its place automatically without impact to the cluster.
  • Docker Trusted Registry 2.5.0 – The production-grade image storage solution from Docker &
  • EE Engine 17.06.2- The commercially supported Docker engine for creating images and running them in Docker containers.

Tell me more about Kubernetes Support..

Kubernetes in Docker EE fully supports all Docker EE features, including role-based access control, LDAP/AD integration, scanning, signing enforcement, and security policies.

Kubernetes features on Docker EE include:

  • Kubernetes orchestration full feature set
  • CNCF Certified Kubernetes conformance
  • Kubernetes app deployment by using web UI or CLI
  • Compose stack deployment for Swarm and Kubernetes apps
  • Role-based access control for Kubernetes workloads
  • Pod-based autoscaling, to increase and decrease pod count based on CPU usage
  • Blue-Green deployments, for load balancing to different app versions
  • Ingress Controllers with Kubernetes L7 routing
  • Interoperability between Swarm and Kubernetes workloads for networking and storage.

But wait.. What type of workload shall I run on K8s and what on Swarm?

One of the question raised multiple times in last couple of Docker Meetup was – Good that now we have K8s and Swarm as multi-orchestrator under the single Enterprise Engine. But what type of workload shall I run on Kubernetes and what on Docker Swarm?

 

As shown above, even though there is a bigger overlap in terms of Microservices, Docker Inc. recommends specific types of workloads for both Swarm and Kubernetes.
Kubernetes works really great for large-scale workloads. It is designed to address some of the difficulties that are inherent in managing large-scale containerized environments. Example: blue-green deployments on Cloud Platform, highly resilient infrastructure with zero downtime deployment capabilities, automatic rollback, scaling, and self-healing of containers (which consists of auto-placement, auto-restart, auto-replication , and scaling of containers on the basis of CPU usage). Hence, it can be used in a variety of scenarios, from simple ones like running WordPress instances on Kubernetes, to scaling Jenkins machines, to secure deployments with thousands of nodes.

Docker Swarm, on the other hand, do provide most of the functionality which Kubernetes provides today. With notable features like easy & fast to install & configure, quick container deployment and scaling even in very large clusters, high availability through container replication and service redundancy, automated internal load balancing, process scheduling, Automatically configured TLS authentication and container networking, service discovery, routing mesh etc. Docker Swarm is best suited for MTA program – modernizing your traditional legacy application(.Net app running on Windows Server 2016)  by containerization on Docker Enterprise Edition. By doing this, you reduce the total resource requirements to run your application. This increases operational efficiency and allows you to consolidate your infrastructure.

Under this blog post, I will deep dive into Docker EE Architecture covering its individual components, how they work together and how the platform manages containers.

Let us begin with its architectural diagram –

 

At the base of the architecture, we have Docker Enterprise Engine. All the nodes in the cluster runs Docker Enterprise Edition as the base engine. Currently the stable release is 17.06 EE. It is a lightweight and powerful containerization technology combined with a work flow for building and containerizing your applications.

Sitting on top of the Docker Engine is what we call “Enterprise Edition Stack” where all of these components run as containers(shown below in the picture), except Swarm Mode. Swarm Mode is integrated into Docker Engine and you can turn it on/off based on your choice.Swarm Mode is enabled when Universal Control Plane (UCP) is up & running.

 

UCP depicting ucp-etcd, ucp-hyperkube & ucp-agent containers

In case you’re new to UCP, Docker Universal Control Plane is a solution designed to deploy, manage and scale Dockerized applications and infrastructure. As a Docker native solution, full support for the Docker API ensures seamless transition of your app from development to test to production – no code changes required, support for the Docker tool-set and compatibility with the Docker ecosystem.

 

 

From infrastructure clustering and container scheduling with the embedded Docker Swarm Mode, Kubernetes to multi-container application definition with Docker Compose and image management with Trusted Registry, Universal Control Plane simplifies the process of managing infrastructure, deploying, managing applications and monitoring their activity, with a mix of graphical dashboards and Docker command line driven user interface

There are 3 orchestrators sitting on top of Docker Enterprise Engine – Docker Swarm Mode, Classic Swarm & Kubernetes. For both Classic Swarm and Kubernetes, there is the same underlying etcd instance which is highly available based on setup you have in your cluster.

Docker EE provides access to the full API sets of three popular orchestrators:

  • Kubernetes: Full YAML object support
  • SwarmKit: Service-centric, Compose file version 3
  • “Classic” Swarm: Container-centric, Compose file version 2

Docker EE proxies the underlying API of each orchestrator, giving you access to all of the capabilities of each orchestrator, along with the benefits of Docker EE, like role-based access control and Docker Content Trust.

To manage lifecycle of orchestrator, we have a component called Agents and reconciler which manages both the promotion and demotion flows as well as certification renewal rotation and deal with patching and upgrading.

Agent is the core component of UCP and is a globally-scheduled service. When you install UCP on a node, or join a node to a swarm that’s being managed by UCP, the agent service starts running on that node. Once this service is running, it deploys containers with other UCP components, and it ensures they keep running. The UCP components that are deployed on a node depend on whether the node is a manager or a worker. In nutshell, it monitors the node and ensures the right UCP services are running.

Another important component is Reconciler. When UCP agent detects that the node is not running the right UCP components, it starts the reconciler container to converge the node to its desired state. It is expected for the UCP reconciler container to remain in an exited state when the node is healthy.

In order to integrate with K8s and support authentication, Docker Team built open ID connect provider. In case you’re completely new to OIDC, OpenID Connect is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an inter-operable and REST-like manner.

As Swarm Mode is designed, we have central certificate authority that manages all the certificates and cryptographic node identity of the cluster. All component uses mutual TLS communication and they are using nodes which are issue by certificate authority. We are using unmodified version of Kubernetes.

Sitting on the top of the stack, there is GUI which uses Swarm APIs and Kubernetes APIs. Right next to GUI, we have Docker Trusted Registry which is an enterprise-ready on-premises service for storing, distributing and securing images. It gives enterprises the ability to ensure secure collaboration between developers and sysadmins to build, ship and run applications. Finally we have Docker & Kubernetes CLI capability integrated. Please note that this uses un-modified version of Kubernetes API.

Try Free Hosted Trial

If you’re interested in a fully conformant Kubernetes environment that is ready for the enterprise,    https://trial.docker.com/

Did you find this blog helpful? Feel free to share your experience. Get in touch with me on Twitter –  @ajeetsraina

Top 10 Cool New Features in Docker Datacenter for Dev & IT Operations Team

Estimated Reading Time: 6 minutes
Docker Datacenter(DDC) provides an integrated platform for developers and IT operations teams to collaborate securely on the application life cycle. It is an integrated, end-to-end platform for agile application development and management from the datacenter to the cloud. Basically, DDC brings container management and deployment services to enterprises with a production-ready Containers-as-a-Service (CaaS) platform supported by Docker and hosted locally behind an organization’s firewall. The Docker native tools are integrated to create an on-premises CaaS platform, allowing organizations to save time and seamlessly take applications built-in dev to production.
 

finale_1

 
Under this blog, I will focus on the top 10 new cool features which comes with DDC:
 

ddc_1

Let us get started with setting up a fresh Docker Datacenter setup. I am going to leverage 6-node instances of Google Cloud Platform to share my experience with DDC UI.

dc_01

Built-in Docker 1.12 Swarm Mode Capabilities:

Run the below command on the first node where we are going to install Docker CS Engine.

$ sudo curl -SLf https://packages.docker.com/1.12/install.sh | sh

dc_0

Next, its time to install UCP:

$sudo docker run --rm -it \
--name ucp \
-v /var/run/docker.sock:/var/run/docker.sock \
docker/ucp install \
--host-address 10.140.0.5 \
--interactive

dc_1

This brings up UCP UI as shown below. Kudos to Docker UCP Team for “a very lightweight UI” with the latest release.

dc_3

Docker Inc. provides you with 30-days trial license once you register for Docker Datacenter. Upload the license accordingly.

ddc-6

Once you login, you will see that you have Swarm Mode cluster already initialized.

I was interested to see how easy it is to add nodes to the cluster. Click on Add Nodes > Select nodes as either Manager or Worker based on your requirement. Docker UCP Team has done great job in providing features like “-advertise-addr` to build up the cluster in few seconds.

ddc-11ddc-12

ucp_111

It just took 5 minutes to bring up 6 nodes cluster.

Please ensure that the following ports are not under firewall.

ddc-20ddc-21

ucp_112

 

HTTP Routing Mesh & Load Balancing

Let us try out another interesting new feature – Routing Mesh. It makes use of LB concepts.It provides global publish port for a given service. The routing mesh uses port based service discovery and load balancing. So to reach any service from outside the cluster you need to expose ports and reach them via the Published Port.

Docker 1.12 Engine creates “ingress” overlay network to achieve the routing mesh. Usually the frontend web service and sandbox are part of “ingress” network and take care in routing mesh.All nodes become part of “ingress” overlay network by default using the sandbox network namespace created inside each node.

Let us try to setup a simple wordpress application and see how Routing Mesh works.

i. Create a network called “collabnet”. UCP Team has done a great job in covering almost all the features which we use under CLI option.

ddc-14

As shown below, a network “collabnet” with the scope “swarm” gets created:

 

ddc-15

ii. Creating a wordpress application

Typically, while creating a frontend service with name “wordpressapp” we usually run the below command. If you want to pass the same parameter through UCP UI, its matter of just few seconds:

$sudo docker service create –env WORDPRESS_DB_HOST=wordpressdb1 –env WORDPRESS_DB_PASSWORD=collab123 –network collabnet –replicas 4 –name wordpressapp –publish 80:80/tcp wordpress:latest

ddc-16

ddc-17ddc-001

ddc-18

ddc-19ddc-21

ddc-22

ddc-23

ddc-24You can easily browse through the master node and get the wordpress page working.

pci2

Let us enable Routing Mesh as shown below:

hrm_1

Once Routing Mesh is enabled, you can access it from any node even if the particular node is not running any container which serves the wordpress application. Let us try accessing it from worker-5 as shown below:

pic1

Cool.. Routing Mesh just works flawlessly.

 

Integrating Notary Installation and HA as part of DTR:

Installing DTR is a matter of single on-liner command as shown below:

ddc-24

Setting up Centralized Logging through UCP

Under admin settings > Logs section, one can supply the rsyslog server details to push all the cluster logs to a centralized location.

log1

logs

TLS Mutual Authentication and Encryption:

UCP Team has done another great job in including TLS mutual authentication and encryption feature to secure communications between itself and all other nodes. There is also cert rotation, which is awesome especially from a compliance point of view. The TLS encryption also ensures that the nodes are connecting to the correct managers in the swarm.

Rotation Join tokens are secrets that allow a node to join the swarm. There are two different join tokens available, one for the worker role and one for the manager role. One usually pass the token using the --token flag when you run swarm join. Nodes use the join token only when they join the swarm. One can view or rotate the join tokens using swarm join-token. We have now these features rightly available under Docker Datacenter as shown below:

new1

Raft Consensus, Orchestrator  & Dispatcher specific Changes:

One of the compelling feature which has been introduced under the latest Docker datacenter is capability to alter and control Raft consensus parameter, orchestration and Dispatcher specific changes. These features were enabled in the recent 1.12.2 release and have been put under docker swarm update command as shown below:

one1

--snapshot-interval is an important parameter useful for performance tuning while –dispatcher-heartbeat duration controls heartbeat period which is default 5 seconds.

In the future post, I am going to talk about DTR, Docker-compose V2 specific examples and cluster configuration under the latest Docker datacenter.

Building Microservice applications on Docker-Datacenter (DDC) using Docker Compose

Estimated Reading Time: 3 minutes

Docker-Datacenter (DDC) is targeted for both developers and IT operations team. DDC provides both developers and IT operations a common option for managing containers. Developers create containers using the toolset they’re comfortable with and deliver the resulting containers to the Docker Registry Service. Operations Team then creates rules that describe how resources can be managed to run those containers, so that developers can perform self-service provisioning for their work.

DDC is an end-to-end Docker platform for enterprises. It is built as a tightly integrated enterprise product – the inclusion of Docker Swarm as the default orchestration engine and Universal Control Plane (UCP) – which sits above the Docker Swarm and provides an on-premises container management solution for Docker apps and infrastructure regardless of where your applications are running.

One of the most amazing feature which DDC provides is building Microservices using Docker compose.

If Docker compose is completely new to you, I request you to refer  https://docs.docker.com/compose/overview/ to get started with Docker compose.  In this post, we will look at how DDC provides an easy way to build wordpress applications using Docker compose.

I assume Docker-Datacenter is already up and running. If not, please refer http://collabnix.com/archives/1149 for step by step guide to setup DDC.

Let’s open up the DDC Web UI as shown below:

UCP_Image01

 

Click on Applications tab shown in the left. Click on Compose Application tab.

Pic1

DDC provides a capability to upload docker-compose.yml right from your Desktop. Also, you can manually copy-paste it from your notepad or Linux machine. Click on Create Application and that’s all you need to get your app up and running. Please refer https://github.com/ajeetraina/collabnix-wordpress/blob/master/docker-compose.yml for the complete docker-compose.yml content:

Pic2

Under Docker compose file, we didn’t specified “network” type and hence it chose the default “collabwebapp_default”. There are various ways to specify the network. In case you created an overlay network for multi-host networking, you can add this application or containers under  the pre-existing network through the following entry in docker-compose.yml:

networks:
  default:
    external:
      name: CollabNet

In case you want to specify the custom network driver, the entry should look like as shown below:

networks:
  frontend:
     driver: custom-driver-1
  backend:
     driver: custom-driver-2
    driver_opts:
      collabNet1: “1”
      collabNet2: “2”

 

While your application is being built, you have a close look at the images and containers pulled up and created respectively as shown below:

Pic-3

 

Pic-4

Pic-5

Let’s check the logs of application creation:

Pic-8

Pic-8

Pic-10

Yippee !! Your first application is up and running using Docker Compose. In the future post, we will look at how can we restrict containers to run on the particular UCP client nodes using the affinity feature of Docker Swarm.