Sugar, Spice, and Docker,
Orchestrate Your Symphony With Docker!
Disclaimer: Docker is not Hibike Euphonium, do not attempt an actual Orchestra with Docker
This article was written under the purpose of individual assignment for PPL CSUI 2021, and also to educate readers on docker.
Introduction
Docker is a software platform for building applications based on the idea of containerization. With containerization, we are able to bundle an application with all of the parts it needs, such as libraries and other dependencies, and deploy them as a unit. Since a container is run in an isolated environment and has all the required dependencies to run, they are very portable and is less dependent on the host environment. Since they are less dependent on their host, Dockers containers are lightweight and run faster compared to their undockerized counterpart on your VM. This enables your VM to run multiple Docker containers at once, increasing your application effectiveness and efficiency.
How Docker Works
Docker works under a client-server architecture. When using Docker, the client has three main things to do, which are build, pull, and run.
First, when the client runs docker build command, Docker will build an image based on Dockerfile that the user has created. A Dockerfile specifies all the command users would do when assembling a docker image.
Secondly, when the client runs docker pull command, we will pull an image or a repository from a registry that has been specified in the command. You can check Docker registries under Docker hub to find an image or a repository to pull. Under the example below, you can see a “docker pull command” section when you checked on a specific registry under the docker hub. copy this code and run them on your device to do a docker pull.
Lastly, when the client runs have pulled or build their docker image and do docker run command, docker will create a container from the given image and start the container using a given command.
Other than these three main commands, there are other commands that the client can do on their docker. When doing communication, the Docker client talks to the Docker daemon using REST API, in which then the Docker daemon does the heavy lifting of building, running, and distributing your Docker containers.
The Million Dollar Question…
So Zakiy, did you actually uses Docker on your PPL project?
No, I didn’t.
Wait, what? Why?
Few reasons why I didn’t use Docker. Here’s why:
The Perceived Benefit of Docker isn’t Tempting Enough:
When we are discussing Docker, one of the key points that are brought up is their benefits which allows your application to be able to be run anywhere with less processing burden on your device. However, this benefit becomes null on our project since our project works on Android Mobile App. Even though there is some possibilities to run Docker for Android using an emulator, we need to consider our client who most likely won’t use an android emulator at all, thus, rendering the benefits kind of useless.
Storing Data in Docker isn’t Possible
For security reasons, you are somewhat expected to also containerize your database under a docker container. It is possible to connect another database source towards Docker, but that isn’t recommended due to a possible hack from malicious users between the two engines. In our project, we have been offered a “pre-made database” under the guise of Firebase API. Since the database have already been made and is maintained by our client, another point shows out why we shouldn’t use Docker on our project
Better Options Exists
Let’s face the truth, in our case, a better solution exists for us compared to using Docker on our project. Instead of using Docker as our application distribution source, we could have simply used Google Play Store with our project .apk file! Even then, our project didn’t really take that action, since deploying our application to Play Store has a price. Since our project software is meant to be used for a specific set of clients, we could just distribute the .apk file to the client. Not only does this option is better from benefit, deploying and maintaining dockerized program has an added burden to our team that could have been spent elsewhere (which is very crucial since there are only four of us compared to other teams that consist of five members!). Hence, we didn’t use Docker in the end.
As a closing, I do have to admit that I have tried using Docker in the past for my TA job in Computer Network:
Guess I still need to learn and try more to build and deploy a program in Docker, after all!
After reading this article, I hope you learned about Docker. See you in my next article!
References:
https://www.freecodecamp.org/news/7-cases-when-not-to-use-docker/
https://docs.docker.com/get-started/overview/
https://blog.codemagic.io/how-to-dockerize-flutter-apps/
https://www.infoworld.com/article/3204171/what-is-docker-the-spark-for-the-container-revolution.html
https://hentsu.com/docker-containers-top-7-benefits/