It is recommended for you to understand what container and containerization actually are. Also the difference about VMs or virtualization including what it was in bare metal computing. Head to 

Docker is a platform that allows developers and system administrators to create, deploy, and run distributed applications. It packages and isolates portable software and their dependencies using a process known as containerization. This makes it possible to deploy consistently and dependably across many environments, from local development to production.


Containers share the host's kernel and only contain the libraries and resources required for the app to execute, in contrast to virtual machines (VMs), which build a complete duplicate of the host operating system and hardware. As a result, containers are lighter and more effective than virtual machines (VMs) since they don't need as much memory, storage, or computing power.


Because it makes it simple and reliable for developers and system administrators to bundle and deploy their programs, Docker has grown in popularity. Additionally, it enables users to run numerous apps on the same server without interfering by allowing them to build separate environments for testing and development.

🤜 It works on my machine ¯\_(ツ)_/¯

Docker solves the "it works on my machine" problem, is a common issue faced by developers when trying to deploy an application on different environments. The app may work perfectly on the developer's local machine, but when deployed to a different environment, it may encounter bugs or compatibility issues. This problem is particularly prevalent in situations where different developers are working on the same codebase, or when the app is deployed to different environments, such as production, staging, or testing.


Docker addresses this problem by providing a consistent and isolated environment for the app to run in. When using Docker, developers can package their app and its dependencies in a container. Because the container contains everything the app needs to run, it eliminates the need for developers to worry about compatibility issues or missing dependencies. This means that if the app runs in the container, it will run in any environment.

This term might sound familiar to you. Yes, it is Java's tagline which made it widely used even until today. WORA is a principle that aims to make it easier to write code that can be run on different platforms and environments without modification.


In this sense, Docker can be considered as a technology that enables WORA for applications. With Docker, developers can package their applications into a single container and run it on any machine that has the Docker Engine installed, regardless of the host's operating system.

To install Docker, you will first need to go to the 

 and download the Docker Community Edition (CE) for your specific operating system.

Once the installer has been downloaded, run it and follow the prompts to install Docker.

After the installation is complete, open a terminal and run the command 

 to verify that Docker has been installed correctly and to check the version number. You should see your version like this.

To run a container, we will first need to pull an image from a public registry, or build your own image. In more descriptive way, the most basic steps to start a container is shown below.

In term of pulling images, the official public registry available is 

. According to the definition, it is the world’s largest repository of container images with an array of content sources including container community developers, open source projects and independent software vendors (ISV) building and distributing their code in containers. Users get access to free public repositories for storing and sharing images or can choose subscription plan for private repos.

To the Hub, developers can push their built images to be shared with others. And from the Hub, another developers pull the images to run it as container in their own machine. This makes sharing Docker images easier and faster.

However, sharing images into Docker Hub is allowing it to be consumed publicly. Which means, if your code base is confidential, you don't want to publish your image there. There are several ways to mitigate this such as implementing private registry.

We are going to learn how to create our own image so we will not pull from Docker Hub but write our own Dockerfile instead. First, let's pick a very easy code base to run. Clone 

 which I created for the purpose of this post. It is a very simple Spring Boot application with a Hello World API endpoint. However, it uses Spring Boot version 

 which is the latest when this post is written, and also utilizing Java 17 which pretty new at this moment. 


Now with these variants mentioned, we will see that Docker will give portability and isolation I mentioned earlier. Assuming that we don't have Java 17 installed, we will still be able to run our image in an isolated environment.


Now to create our image, we're gonna need to create a Dockerfile. A Dockerfile is similar to a blueprint of our image. It contains every detail that we need to build an image so that the image will run smoothly. All properties, commands need to be run, configurations, platform variants, dependencies, you name it, are written here.

 style, but both ways works. The difference between them is just you will need to add more parameter when building the image later. To simplify, we will use the first way. In many ways to create a file, I'm gonna run 

Now we need to write several things in our Dockerfile. First, the base image. Technically, a container consists of images layer. The base image is mostly Linux Base Image since it is relatively small. This is why in Windows, you are required to enable Windows Subsystem Linux (WSL).

Also, for me personally this also promotes  Linux advantages of its compatibility to work across multiple platforms such as Windows or MacOS, and this give me more reason to recommend every developer to learn it.  

I'm not gonna explain about how to write Dockerfile specifically, you can find another better versions out there, but here are some references to learn from.


All  containers (not only Docker) need Linux base image and the Linux base images to use vary. The most common to use is Alpine distribution because of its small size and only contain what necessary.


Since our application is a Maven project, there are several ways to build image of it. There are two that come to my mind. First, we build the project using Maven and then use 

 command in the Dockerfile to copy the built 

 file into the base image specific directory and then run 


Or the second method, which I'm gonna use, is to 

 Maven command to build the project, then 

 file  into the base image and then run it. Pretty similar, but notice that we add the Maven compile process into the Dockerfile itself. To make it short, here is the full Dockerfile contents.

Don't be overwhelmed 😵‍💫 let's break it down.

 : The base image we use is an Linux image with JDK 18 and Maven installed on it. This way, we don't need to RUN another command to install Maven or Java anymore. Thanks to many variants available we can use according to our needs.

 command in wherever the current position is. We can inspect this later but the default directory depends on what base image we are using.

 : means we set our building process base directory to 

 folder which contains our main source code to 

 in advance, the expected outcome structure would be 

 : Run the Maven package command. It equals to what we usually run in terminal while compiling Maven project such as 

ENTRYPOINT ["java", "-jar", "/app/target/tracc-0.0.1-SNAPSHOT.jar"]

 : Like other Maven project, the outcome of the built process will be a 

 folder containing our built files including the 

 command like our usual way to run Java app. The 

 command will tell the container built later where and how to run the image.

Here is the folder structure will be generated in our Docker image.

Now our Dockerfile is ready. Time to build our image! There are several essential Docker command that we must know.

 : execute commands in container, like shell.

 : to list containers we run. I usually add 

Please note that these commands are just the basics and I don't even include the options or additional parameters of each command. You can learn it 

 parameter, it means tag. It is recommended to always tag our image because it will make it easier for us to version them. And the second parameter is the path, which I stated as 

This means build a Docker image in the current folder. Because I named our Dockerfile as Dockerfile, it will automatically pick that file as the blueprint. However as I mentioned earlier, if we named our Dockerfile as 

, we need to specify the Dockerfile with 

, the build process will begin and don't worry your terminal goes a bit crazy with those words written there. With the Dockerfile above, I made sure that the build process will be successful. However, if you create your own Dockerfile, sometimes it will take trial and error process until you get your working image.


And after a while, we will get our Docker image. You may be expecting a file generated from this process and probably start to look for it in your folder and it's not there. The image we built will be stored in our local Docker repository installed in our machine. You can find it using 

You may only have one image if this is your first time building one, here I have several images I used before.

Now that we have our image, we can run it as a container. The command we use is 

. While there are many parameters available for this command, I usually add:

 is for exposing our container into our machine port, then add the image name (include the tag if you have several images with a same name).

To run our image, I will expose the port to 

 and since we know the default Tomcat port run in our Spring Boot application is 

In detach mode, the terminal will only give us a container ID printed. To get more information about our container, run 

 command and our container will be listed.

Our container is now live and running. It is a Spring Boot application with a REST API endpoint at 

Nice! Our endpoint works. But there is nothing special about this so far. We haven't see how Docker portability and isolation benefits us. Say no more!

The easiest way to transport our image is throught Docker Hub. But as I mentioned earlier we are not going to upload our image there even though it's free. We are going to "conventional" way instead. First, we will export our image to a 

 command and then send it to our teamates. The 

 file need to be "loaded" into their local Docker repository using 

 command. And finally, run the loaded image as before.

 parameter means output, and we add the path and filename we want for our exported image, and lastly the image we want to export. And voila! We have our image in 


Now we can transfer this image to our teamates to let them run it. But before they able to run it, they need to load it.

 file into their local Docker repository and from here you know how to run it don't you?


After running the image, each of our teamates can call the 

 API on their own machine and I guarantee it will work. This shows us the portability and isolation of Docker. The portability refers to the ability of a Docker container to run consistently across different environments, regardless of the underlying infrastructure.


In this project we see that our application is portable across different machines of our teamates, and I want to mention specifically about the Java version we use. Regardless what version of Java they installed on their own machine, could be 8, 11, or even 19, our application still runs on Java 17 (see 

And the isolation is shown by that the app uses Java 17 and even if the host has Java 8 or 19 installed, it will not conflict with the other Java versions installed on it.

Imagine if our app provides important task and live in long run, but if a problem occurs we don’t have the facility to know what’s going on, or at least check log we wrote in the code.

Docker is quickly becoming one of the most popular tools for app deployment, and for good reason. This powerful platform allows developers to create, deploy, and run applications in a consistent and reliable environment, regardless of the underlying infrastructure. Whether you're working on a small, single-page app or a large, complex enterprise system, Docker has the tools and features you need to ensure your app runs smoothly and reliably, every time.

Docker: The Key to Consistent and Reliable App Deployment

VMs and Containers are the most common infrastructure types used nowadays. However before they all began its era, the granddaddy of these is Bare Metal. Bare Metal is basically a physical computer act as servers. You can imagine this as a computer in your house, with a different shape of course. Once upon a time, all servers are Bare Metals.

A bare metal server is a single tenant physical server that is dedicated to a single user or organization and often used in situations where high performance, low latency, and/or specialized hardware is required, such as in high-performance computing, gaming, and big data analytics.

Since bare metal servers are isolated in physical way, this gives us benefits of:

This occures when one tenant's performance is impacted because of another tenant's activities. Bare metal shares nothing in terms of computing resources so this problem won't happen. Software applications will get absolute highest performance of the hardware.

In a bare metal environment, the security measures are implemented on the physical level. This means that the security perimeter is defined by the physical boundaries of the server, and access to the server can be controlled through physical security measures such as locked server rooms, security cameras, and biometric authentication.

Bare metal servers can also be secured through traditional security measures such as firewalls, intrusion detection and prevention systems, and security information and event management (SIEM) systems. This allows organizations to monitor and protect their servers against potential threats.


However, bare metal also comes with downsides. Imagine if you have a computer to run Adobe Photoshop for example, than you need Corel Draw but because of your current computer performance is already at its peak, the only choice is to add another computer to run Corel Draw.

But before you are able to do it, first you might buy the peripherals itself, then install the OS, what about the license? And after some complicated steps, you get to install your Corel Draw software. However, running a single software on a highend computer might be overkill and too much. This simple example describes the disadvantages of bare metals.


When it comes to provisioning and managing bare metal servers, it can be more complex than virtualized environments. Traditional bare metal servers require manual provisioning, OS installation and configuring, and ongoing maintenance. It short, it is expensive, hard to maintain, hard to scale and take a lot of stuffs to do.

Bare metal disadvantages need to be handled, right? Computer experts start to think about how we can make use of the computer power in more efficient way.  Then it comes the era of Virtual Machines. 

Virtualization is the process of creating a virtual version of a 

, usually a hardware platform, operating system, or storage device. With the existence of virtualization, we can run mulitple virtual machines on a single bare metal servers. The magic of this is a special piece of software called Hypervisor.

Hypervisor will create an abstraction layer between the hardware and the OS. In VMs, the hardware specification is virtualized. Meaning, you will have your own spec in it, such as CPU cores, memory and storage.


Some will tell you about Bare Metal Hypervisor. To compare with the image above, Bare Metal Hypervisor does not rely on the Host OS, which means you can imagine that the orange part is not there. This type of Hypervisor will take full control of the hardware resulting better performance but it also comes with more expensive price.

With VMs, we can get a more cheaper way to run multiple computers while these computers can be controlled according to our needs. Also VMs are easier to scale. Because we can define our own specification, as long as the server itself has the capability to provide our needs, we can have as high specification as possible. Nowadays, servers to provide VMs are very powerful with hundreds of CPU cores and terrabytes of memory / storages.


Contrast to bare metals where everything is isolated in physical form, VMs have potential of having noisy neighbor problems because the host server's hardwares are shared. No matter how good the hypervisor function is, it still needs resources and time to think and do its job sharing the hardwares.

 are most known vulnerabilities in modern processors able to be virtualized. Meltdown breaks the most fundamental isolation between user applications and the operating system. This attack allows a program to access the memory, and thus also the secrets, of other programs and the operating system.

And Spectre breaks the isolation between different applications. It allows an attacker to trick error-free programs, which follow best practices, into leaking their secrets.

Containerization, on the other hand, is a form of virtualization that focuses on 

 apps and their dependencies in a portable and consistent way. It is considered a light weight form of virtualization.

You may have used Virtual Machines (VMs) because they've been popular for longer. And then containers on the other side which may be a bit newer to you,
but you've probably seen them if you're working in the spaces of app modernization, or you're dealing with microservices, or anything that demands this new way of building and architecting applications.

Now, the first main thing to point out the difference with VMs is 

the level at which the virtualization happens

. These two technologies are different ways of achieving virtualization. Instead of using Hypervisor to orchestrate the hardware, containerization using something called container engine. The most popular one is 

. This engine itself is a piece of software installed on the host OS machine and will take responsibility to run containers.


So you can see now that in VMs the virtualization happens at the hardware level thus it is often called "

" because it takes place at the OS level.

A container will be a lightweight, standalone, and executable software package that includes everything needed to run a piece of software, including the code, runtime, system tools, libraries, and settings. However, unlike virtual machines, containers 

, instead they make use of the host machine's operating system kernel.

If you are planning to run multiple containers on your computer or let's say a bare metal, obviously you can. But what if I told you containers can also run on VMs. 

So imagine, a bare metal is divided to many VMs, and on that VMs are divided into smaller containers. You can have a lot stuffs running on a single powerful bare metal!

Talking about virtualization, you might be familiar with tools like 

. You probably use it in your daily life to virtualize your computer to many purposes like having another clean workstation, or simply if you're on MacOS and you also want to run Windows on it, the easiest way to do that is with these tools. 

But in which level is VirtualBox, VMWare, etc compared to Hypervisor? Most likely, you've never met Hypervisor in your computer with its graphical form right? That brings us to acknowledge that there are types in virtualization.

Hypervisor in VMs is what it is called Type-1 virtualization, which it virtualizes at the hardware level. Well, we've discussed it already, so now there is the second type called Type-2 virtualization. This is where VMWare, VirtualBox, Parallels, etc are on.

Type-2 virtualization lies on a bit higher level than the Type-1, almost similar to the operating system virtualization or container, but not to be mistaken since they do not have the same concept.

Containerization is the beginning of next level computing paradigm such as serverless and edge computing. I dare to say, to start your learning into cloud computing, having knowledge of containerization will surely help you to understand the upcoming concepts, architectures and terminologies you would face later on. We could talk about these matters in a different blog post, but few introductions won't hurt.


Serverless is a cloud computing paradigm that allows developers to run their code without having to manage or provision servers. This makes it easier to build and run applications, and can also reduce costs by only paying for the resources used.

And edge computing is a distributed computing paradigm that brings computation and data storage closer to the edge of the network, where data is generated and consumed. This allows for faster and more efficient processing of data, and can be used to improve the performance of IoT and mobile applications.

A bare-metal server is a single physical machine that runs one or more applications on it, all the applications share the same resources, such as CPU, memory, and storage.


A virtual machine (VM) is like creating multiple virtual computers on a single physical machine. Each virtual computer runs its own operating system and applications, and they are isolated from each other. Each virtual machine has its own set of resources, like CPU, memory and storage.


A container is a way to package an application and its dependencies together and run it in an isolated environment on a single operating system. Instead of creating a whole virtual machine, a container shares the host operating system kernel and runs the application in an isolated environment.

VMs isolation happens at the machine thus sometimes it's called 


So in simpler terms, a bare-metal server is a single computer, a virtual machine is like having multiple computers on a single machine, and a container is like having multiple isolated environments on a single computer.

Big Misconceptions about Bare Metal, Virtual Machines, and Containers

Containers vs VMs: What's the difference?

You probably have heard about VMs and Containers. These terms are so widely used nowadays. But what are they actually? And how do they fit into our way of building and architecting applications? Let's talk about it.

Containers vs VMs? What differs?

I'm updating this topic, please stay tuned! 🙏

Tulisan ini adalah bagian dari serangkaian materi dari Advisory Program BCA, untuk 


Container has been around and popular nowadays. The benefits of it are inescapable. Let’s try to make our application as a container using Docker. The end result is a Docker image file that we can share and run anywhere!

Advisory Program 2022 (Chapter 4) - Containerize Your App!

Docker is a set of platform as a service products that use OS-level virtualization to deliver software in packages called containers. The service has both free and premium tiers. The software that hosts the containers is called Docker Engine. It was first started in 2013 and is developed by Docker, Inc.

BLOG TAG

Docker

Here are some articles tagged with "Docker" :