Container Software Orchestration with Docker

Source: blog.kulakowski.fr

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

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

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:

Source: researchgate.net

Advantages of Using Docker Container Orchestration

  1. 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.
  2. 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.
  3. Agility. The portability and performance benefits of container orchestration mentioned above can help us make our development process more agile and responsive.
  4. 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

Source: Aqua Cloud Native Academy
  • 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 run

Our Docker Orchestration Implementation

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.

Saat masa development, kami developer lebih intensif melakukan testing saat masih di localhost. Ketika program di deploy ke server, ada masalah environment yang membuat kami khawatir sehingga terkadang harus testing ulang di server. Hal ini dapat diminimalisir dengan unit test, namun perhatikan bahwa unit test hanya di jalankan di pipeline gitlab, tidak di deployment server yang menggunakan environemtn yang beda lagi.

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!

a computer science major in university of indonesia.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store