Container Software Orchestration with Docker
I’ve been hearing about Docker since forever. But I actually had no idea what the heck that is until just recently. From what I’ve just learned, Docker is a platform built for container orchestration. It is made to ease the pain in your software development process.
Overall, Docker works by uniting all of our software dependencies and libraries at one place. It could be very helpful when deploying our project to the server, because the clients may have been using different computers or OS than us, and they might not have all the dependencies that we are using on our project, so they would need to install them again and again, and that could be pretty exhausting and obviously not so efficient.
Software Orchestration
Like what I have mentioned above, software orchestration is the automated configuration, management, and coordination of computer systems, applications, and services. The more complex a software project is, the more complex as well managing all the moving parts can be. That’s where orchestration can help by automating many complex tasks together.
There are 2 types of software orchestration that I have so far learned. They are Virtual Machine (VM) Orchestration and Container Orchestration.
Virtual Machine Orchestration vs Container Orchestration
In VM orchestration, they virtualizes the physical hardware. That will cause in each VM contains a guest OS, a virtual copy of the hardware that the OS requires to run and an application with its libraries and dependencies. VMs with different OS can be run on the same server. For example, a VMware VM can run next to a Linux VM, which runs next to a Microsoft VM, etc.
However, in container orchestration, instead of virtualizing the hardware, they would virtualize the OS (usually Linux or Windows) so each individual container only contains the application with its libraries and dependencies. Containers are small, fast, and portable because, unlike a VM, containers don’t need a guest OS in every instance. See the picture below to understand the difference about VM orchestration and container orchestration:
Advantages of Using Docker Container Orchestration
There are many advantages we can get when we are implementing container orchestration, especially with Docker. Some of them are:
- Portability. Once we have tested the application we want to containerize, we can deploy it to any other system where Docker is being ran without worrying about our app’s performance. We can be sure that it will perform exactly as it did when we tested it.
- Performance. Compared by VM orchestration as mentioned above, containers do not contain any operating system, like VMs do. That means containers are are faster to create and quicker to start.
- Agility. The portability and performance benefits of container orchestration mentioned above can help us make our development process more agile and responsive.
- Isolation. A Docker container we are using to contain our app also includes the versions of any supporting software our application needs. If the other Dockers contain different versions of those supporting software, that wouldn’t be a matter because different Docker containers are completely independent and mutually exclusive from one another.
Docker Architecture
Docker can be divided into several components like Docker Client, Docker Daemon/Engine, Docker Containers, Docker Images, and Docker Registries. Docker is using client-server architecture that connects the Docker Client with Docker Daemon using REST API.
- Docker Client and Daemon. This component allows user to interact with Docker. Docker client can be located on the same host as Docker daemon or being connected to a daemon that’s placed on a remote host. Docker client provides a CLI that enables the users to build, run, and stop application commands to a Docker daemon. Common commands that are being used by the client are:
docker build
docker pull
docker run- Docker Images. Images are some read-only binary template used to build containers as well as to store and ship applications. They contain metadata that describes the Docker container’s capability and needs. We can also build several Docker containers with one image.
- Docker Containers. Containers are encapsulated environments where we can run our apps. Since containers are much smaller than VMs, they can be spun up in few seconds, which would result in much better server density.
- Docker Registries. These registries are actually services that provide locations where we can store and download images. A Docker registry contains Docker repositories that host one or more Docker Images. We can use public registries like Docker Hub and Docker Cloud as well as private registries. It pretty much behaves like Git version control systems where we can pull existing images or push our images so it can be used by other people. Common commands when working with registries include:
docker push
docker pull
docker runOur Docker Orchestration Implementation
In the project me and my team are currently working on for Faculty of Law, University of Indonesia, we are currently using Heroku as our server, so we can’t use Docker-compose because Heroku has already had its own Docker. We have not setup Docker yet, but of course we would need it soon because the development process is coming to an end, and we perhaps need to do an application packaging in order to be able to deploy it to another server (like fh.ui.ac.id for example).
It would be pretty difficult later if we do not use Docker because we would to do a re-setup of our application again and again if we want to move from one server to another. With Docker, we would not need to do a lot of things. We have to just install Docker in the new server if it has not yet been installed setup it there.
And as mentioned above, me and my fellow developers in our team only tend to test the application more locally. When the app is deployed to the server, there were some problems on the environment that made us worried so we sometimes still need to re-test it once the app is on the server. This could be minimizes by using unit test, but unfortunately again, unit tests are only being ran on GitLab pipelines. Meanwhile later with Docker, we can reassure the quality of our application is just as good when deployed to the server.
Welp, that’s all the things that I’ve just recently learned about Docker and container orchestration. Hope you’d get a little insight too about Docker. Thank you for reading and have a great day!
