Docker For Mac 17.12 GA is the first release which includes both the orchestrators – Docker Swarm & Kubernetes under the same Docker platform. As of 1/7/2018 – Experimental Kubernetes has been released under Edge Release(still not available under D4M Stable Release). Experimental Kubernetes is still not available for Docker for Windows & Linux platform. It is slated to be available for Docker for Windows next month(mid of February) and then for Linux by March or April.
Now you might ask why Docker Inc. is making this announcement? What is the fun of having 2 orchestrator under the same roof? To answer this, let me go little back to the past and see how Docker platform looked like:
~ Source – Docker Inc.
Docker platform is like a stack with various layers. The first base layer is called containerd. Containerd is an industry-standard core container runtime with an emphasis on simplicity, robustness and portability. Based on the Docker Engine’s core container runtime, it is available as a daemon for Linux and Windows, which can manage the complete container lifecycle of its host system: image transfer and storage, container execution and supervision, low-level storage and network attachments, etc. Containerd is designed to be embedded into a larger system, rather than being used directly by developers or end-users. It basically includes a daemon exposing gRPC API over a local UNIX socket. The API is a low-level one designed for higher layers to wrap and extend. It also includes a barebone CLI (ctr) designed specifically for development and debugging purpose. It uses runC to run containers according to the OCI specification. The code can be found on GitHub, and here are the contribution guidelines. Let us accept the fact that over the last few years, there has been lots of iteration around this layer but now Docker Inc. has finalised it to a robust, popular and widely accepted container runtime.
On top of containerd, there is an orchestration layer rightly called Docker Swarm. Docker Swarm ties all of your individual machines together which runs container runtime. It allows you to deploy application not on a single machine at a time but into a whole system, thereby making your application distributed.
To take advantage of these layers, as a developer you need tools & environment which can build & package your application that takes advantage of your environment, hence Docker Inc. provides Community Edition like Docker for Mac, Docker for Windows etc. If you are considering to move your application to the production, Docker Enterprise Edition is the right choice.
If the stack looks really impressive, why again the change in architecture?
The reason is – Not everybody uses Swarm.
~ Source – Docker Inc.
Before Swarm & Kubernetes Integration – If you are a developer and you are using Docker, the workflow look something like as shown below. A Developer typically uses Docker for Mac or Docker for Windows.Using a familiar docker build, docker-compose build tool you build your environment and ensure that it gets deployed across a single node cluster OR use docker stack deploy to deploy it across the multiple cluster nodes.
~ Source – Docker Inc.
If your production is in swarm, then you can test it locally on Swarm as it is already inbuilt in Docker platform. But if your production environment runs in Kubernetes, then surely there is lot of work to be done like translating files, compose etc. using 3rd party open source tools and negotiating with their offerings. Though it is possible today but it is not still smooth as Swarm Mode CLI.
With the newer Docker platform, you can seamlessly use both Swarm and Kubernetes flawlessly. Interestingly, you use the same familiar tools like docker stack ls, docker stack deploy, docker ps, `docker stack ps`to display Swarm and Kubernetes containers. Isn’t it cool? You don’t need to learn new tools to play around with Kubernetes cluster.
~ Source – Docker Inc.
The new Docker platform includes both Kubernetes and Docker Swarm side by side and at the same level as shown below. Please note that it is a real kubernetes sitting next to Docker Swarm and NOT A FORK OR WRAPPER.
~ Source – Docker Inc.
Still not convinced why this announcement?
~ Source – Docker Inc.
How does SWARM CLI builds Kubernetes cluster side-by-side?
The docker compose file analyses the input file format and convert it to pods along with creating replicas set as per the instruction set. With the newer Docker for Mac 17.12 release, a new stack command has been added as the first class citizen to Kubernetes CLI.
[simterm]
Ajeets-MacBook-Air:~ ajeetraina$ kubectl get stacks -o wide
NAME AGE
webapp 1h
[/simterm]
Important Points –
- Future Release of Docker Platform will include both orchestration options available – Kubernetes and Swarm
- Swarm CLI will be used for Cluster Management while for orchestration you have a choice of Kubernetes & Swarm
- Full Kubernetes API is exposed in the stack, hence support for overall Kubernetes Ecosystem is possible.
- Docker Stack Deploy will be able to target both of Swarm or Kubernetes.
- Kubernetes is recommended for the production environment
- Running both Swarm & Kubernetes is not recommended for the production environment.
- AND by now, you must be convinced – “SWARM MODE CLI is NOT GOING ANYWHERE”
Let us test drive the latest Docker for Mac 17.12 beta release and see how Swarm CLI can be used to bring up both Swarm and Kubernetes cluster seamlessly.
- Ensure that you have Docker for Mac 17.12 Edge Release running on your Mac system. If you still don’t see 17.12-kube_beta client version, I suggest you to go through my last blog post.
A First Look at Kubernetes Integrated Docker For Mac Platform
Please note that Kubernetes/kubectl comes by default with Docker for Mac 17.12 Beta release. YOU DON”T NEED TO INSTALL KUBERNETES. By default, a single node cluster is already setup for you by default.
As we have Kubernetes & Swarm Orchestration already present, let us head over to build NGINX services as piece of demonstration on this single node Cluster node.
Writing a Docker Compose File for NGINX containers
Let us write a Docker compose file for nginx image and deploy 3 containers of that image. This is how my docker-compose.yml looks like:
https://gist.github.com/ajeetraina/926a4522203deb57e1237546fd77581b
Deploying Application Stack using docker stack deploy
[simterm]
Ajeets-Air:mynginx ajeetraina$ DOCKER_ORCHESTRATOR=kubernetes docker stack deploy –compose-file docker-compose.yml webapp
Stack webapp was created
Waiting for the stack to be stable and running…
– Service nginx has one container running
Stack webapp is stable and running
[/simterm]
Verifying the NGINX replica sets through the below command:
As shown above, there are 3 replicas of the same NGINX image running as containers.
Verify the cluster using Kubectl CLI displaying the stack information:
[simterm]
Ajeets-MacBook-Air:mynginx ajeetraina$ kubectl get stack -o wide
NAME AGE
webapp 8h
[/simterm]
As you see, kubectl and stack deploy displays the same cluster information.
Verifying the cluster using kubectl CLI displaying YAML file:
You can verify that Docker analyses the docker-compose.yaml input file format and convert it to pods along with creating replicas set as per the instruction set which can be verified using the below YAML output format.
We can use the same old stack deploy CLI to verify the cluster information
Managing Docker Stack
[simterm]
Ajeets-MacBook-Air:mynginx ajeetraina$ docker stack services webapp
ID NAME MODE REPLICAS IMAGE PORTS
20e31598-e4c nginx replicated 3/3 nginx *:82->80/tcp,*:444->443/tcp
[/simterm]
It’s time to verify if the NGINX webpage comes up well:
Hence, we saw that NGINX service is running both on Kubernetes & Swarm Cluster side by side.
Cleaning up
Run the below Swarm CLI related command to clean up the NGINX service as shown below:
[simterm]
$docker stack ls
$docker stack rm webapp
$kubectl get pods
[/simterm]
Output:
Want to see this in action?
https://asciinema.org/a/8lBZqBI3PWenBj6mSPzUd6i9Y
Did you find this blog helpful? Feel free to share your experience. Get in touch @ajeetsraina.
If you are looking out for contribution/discussion, join me at Docker Community Slack Channel.
Comments are closed.