As i start digging around my requirements, i found three potential players who are doing great job under their defined context. Kubernetes, Mesos and Docker swarm. I personally more convinced to use kubernetes for my production environment solutions. I found it more logical and lesser learning curve.
Kubernetes is the quickest, easiest and lightest way to kick the tires and start experimenting with cluster oriented development. It offers a very high level of portability. It works very well with modern operating system environments like; Ubuntu, Red Hat, Project Atomic/CentOS, or CoreOS. These OSes offer up lightweight computing “nodes” that are managed for you. Kubernetes is written in the programming language Go and is lightweight, modular, portable as well as extensible. Some of these core concepts include:
Pods: are a co-located group of Docker containers with shared volumes. They’re the smallest deployable units that can be created, scheduled, and managed with Kubernetes. Pods can be created individually, but it’s recommended that you use a replication controller even if creating a single pod.
Replication controllers: manage the lifecycle of pods. They ensure that a specified number of pods are running at any given time, by creating or killing pods as required.
Labels: are used to organize and select groups of objects based on key value pairs.
Services: Provide a single, stable name and address for a set of pods. They act as basic load balancers.
So, with Kubernetes alone you will have something that’s simple, easy to get up-and-running, portable and extensible. While adding the word “cluster” as a noun to the things that you manage in a truly lightweight way. Run an application on the cluster, and stop worrying about individual machines. In this case, a cluster is a flexible resource just like with a VM. It’s a logical computing unit you can turn it up, use it, resize it, turn it down both quickly and easily.
Mesos is a distributed systems kernel that stitches together a lot of different machines into a logical computer. It was born for a world where you own a lot of physical resources that you use to create a large static compute cluster. The great thing about it is that lots of modern scalable data processing application run well on Mesos (Hadoop, Kafka and Spark). Now Mesos is currently being adapted to add a lot of the Kubernetes concepts and to also support the Kubernetes API. So it will be a gateway to getting more capabilities for Kubernetes app.
If you have existing specialized workloads (Spark, Hadoop, Kafka, etc), Mesos gives a framework that let’s interleave those workloads with each other, and mix-in some of the new stuff including whole Kubernetes apps.
Mesos can require a custom framework to be written, such as a framework for running MariaDB for example. With Kubernetes containerized app can run without any further modification.
Docker swarm is a scheduling backend for Docker.It turns a pool of Docker hosts into a single virtual host. To enable communication between the Swarm manager and the Swarm node agent on each node, each node must listen to the same network interface (tcp port). Swarm requires the Docker Remote API to be available at TCP port 2375. If swarm master service is down subsequently it will not show any sort of effect on swarm node agent.
As far as questions i was looking for in day – 1. I have pretty good work flow now. Following are questions with my findings.
- Programmer should be able to launch machine corresponding to any branch in our remote environment. Docker composer is the best solution for development environment.
- QA should be able to launch machine corresponding to any branch it was to test. Docker composer is the best solution here. To make it more simply, we can write Makefile.
- How deployment of new releases will happen from Development Environment to Staging and Staging to Production without interrupting running services of old code? Kubernetes suppose to do this for me.
- How this echo system would work where new machines comes in with new updated code and old get away. Kubernetes will lift all such hassles by it’s own.
- Since docker is recognised as light weight machines. So 500+ mb image size does not make sense. So How can i keep the size of the machine as small as possible with the minimum set of libraries to keep my application running? Nested DockerFile is the solution to keep your images as small as possible.
Next i will try to have some working model of whole development life cycle.