A Longshoreman for Your Application
When you want to distribute your application to the production server, you usually have to install several things first there, such as the OS, Database, Runtime Application, Libraries, etc. Then, you can finally deploy your application. But, what if I tell you that you can do this whilst you build your application.
“Wait, you can do that?”
“Yes, it’s possible today, thanks to Docker.”
“Docker? Huh never heard of that”
Based on Google itself, a docker is a longshoreman who loads and unloads a container to the ship. To make it easier, think of the container as a bag, a school bag, a tote, or even a designer bag. Usually, what do you use it for? It helps you carry your stuffs so that your hands are not full of it right. You can just throw all of the things that you want to bring into your bag, simple. Well, Docker, the application for container manager, is exactly like that. We put all kinds of dependencies that we needed and, of course, the application in a container before we deploy it to the production server. Therefore, we do not need to worry about installing some stuff on the server.
What makes it different from a virtual machine is that containers don’t have any OS on it but share the OS below it with other containers.
Docker Architecture
Docker Client
A terminal application, used by developers to input a docker command. It can be run without the Docker Host, but every time we type a command (like docker info), it actually sends the command to the host and then returns it to the client with the things that the user wants.
Docker Host
Or the Docker Server is a place where we manage the docker images, containers, which are connected to the registry container.
Container Registry
A place where we store our Docker images. Why we need a registry? It’s because of the reusability to reduce the workload so that one person can use the other’s docker image. In bisaGo, we used another person docker image for the Flutter and Android dependency. We use cirrusci/flutter:latest as the docker image for the Flutter and Android dependency. Hence we do not need to know the script for building that image. To use it, simply use the keyword FROM then followed by the docker image like this:
FROM cirrusci/flutter:latestDocker Image
A bundled or packaged version of our application consists of dependencies. This image later will be deployed to the registry. To build a docker image, we must first create a file named Dockerfile. This file will consist of all the commands a user could call on the command line to assemble an image. Some syntax that bisaGo used in the Dockerfile
- FROM image, use another person image as the parent image
FROM cirrusci/flutter:latest- ENV VARIABLE=variable, define the variable which we will use later when building the image
ENV SONAR_SCANNER_CLI_VERSION=4.2.0.1873- RUN command, run the command inside the image filesystem
RUN wget -qO sonar-scanner-cli.zip https://binaries.sonarsource.com/Distribution/sonar-scanner-cli/sonar-scanner-cli-${SONAR_SCANNER_CLI_VERSION}-linux.zipAfter you are done creating the Dockerfile, you can proceed to build the image. Run the following command to build the image:
docker build -t <your_username>/<your-repository> .The -t flag is to specify the name of the image. To test your image locally, use the following command:
docker run <your_username>/<your-repository>Docker Container
As I’ve mentioned above, it’s a place where we put all dependencies and our application in one place. A docker image that we’re going to run.
Implementation in bisaGo
We recently updated the docker image that we used for the application since it’s outdated and causes many irrelevant errors. When we’re creating a custom widget, some of the attributes aren’t recognized but run smoothly on our local device. We also thought that it causes an error in the login feature (turns out this doesn’t fix the login feature, the AppCenter, where we deploy our application for the staging environment, causes the problem). Hence, we decided to update the docker image.
The first thing that we did is that creating the Dockerfile. With the Scrum Master’s help, we decided to use cirrusci’s docker image for the Flutter and Android dependency. As I’ve mentioned above, we use the keyword FROM to include it in our image. We also need SonarQube so that we can track the bugs, code smells, and many more. Our Dockerfile ended up looking like this:
After that, in order to use it, we must first build the image. To build it, simply run the following command:
docker build -t poipole/bisago .
For this image, we gave it the name “poipole/bisago”. To check your docker image in your local device, run the command docker image ls and the result will be like this:
As we can see. there are two images. One for the Flutter and Android SDK dependency, and the other one for our application (SonarQube etc.).
After we’ve finished building the image, we can now push it to the Docker repository. But first, we must create a repository in our Docker account. Please refer to this link to help you create your repository. Then finally, you can push it using this command:
docker push <your_docker_image_name> OR in this case
docker push poipole/bisago
And we’re done…. building the docker image and pushing it to the repository. We haven’t set it up in our project. In bisaGo, to use the docker image, simply edit the .gitlab-ci.yml. Note that we’ve previously already build a docker image name “poipole/bisago-be”.
Check your pipeline to see whether it uses the correct image or not.
As we can see that, it uses the correct image of “poipole/bisago-be”.
Docker might look intimidating since there are many new concepts and terminologies. Try to practice more using Docker, and eventually, you’ll get used to it. Good luck!
References:
