Why you should understand containers now

A series on PostgreSQL with Docker and Kubernetes

Container technologies have revolutionized the way we develop and deploy software. They offer flexibility, scalability, and efficiency that are essential in today's increasingly complex IT landscape. In the coming weeks, we will take you on a journey into the world of PostgreSQL in containers. We will discuss both Docker and Kubernetes with corresponding examples. In this initial post, we will explain the advantages of containers over VMs and why you should get more involved with containers. 

Containers - efficient, portable and scalable

Containers are essentially isolated environments that contain all the necessary software components to run a specific application or function. However, compared to virtual machines, containers are considerably leaner. They share the host's operating system instead of requiring their own, which makes them resource-efficient and fast. This lightness, combined with the microservice approach where each container unit fulfills a specific function, enables efficient and flexible scaling. For example, a web shop could consist of nginx containers, a database container (or more for High Availability) and a connector for the CRM system. Like physical containers on a ship, software containers can be easily moved, replicated and scaled, making them an ideal solution for dynamic and growth-oriented projects. 

Containers offer the following benefits:

• Portability: Independent of the operating system - runs wherever containers are supported. 
• Resource efficiency: Lower overhead than with VMs, as the host kernel is shared. 
• Fast deployment: Containers start and stop in a matter of seconds. 
• Scalability: Containers can be scaled at lightning speed and efficiently. Thanks to their lean design, many instances of an application can be deployed with minimal resource requirements. With tools such as Kubernetes, the number of containers automatically adapts to the load, which enables flexible and simple management of many instances. 
• Consistency: Standardized environment from development to production. 
• Modularity: Applications can be divided into smaller, easy-to-manage services. 
• Lightweight: Smaller size compared to VMs, less storage space required. 
• Automation: Easy integration into CI/CD pipelines. 

Containers have the following drawbacks:

• Security risks: Containers share the host kernel, which harbors potential security risks if a container is compromised. 
• Orchestration complexity: Managing and scaling many containers requires complex orchestration tools such as Kubernetes, which demand specialized knowledge. 
• Performance overhead: Containers can offer lower performance than bare metal hardware or VMs in certain scenarios, especially for I/O-intensive applications. 
• Persistence and data management: Containers are stateless by nature, which can complicate the management of persistent data and external storage solutions. 
• Monitoring and debugging: Monitoring and debugging can be more difficult as logs and metrics are often spread across many containers.

Difference to VMs

One of the biggest differences between VMs and containers lies in the type of virtualisation. As is well known, a VM virtualizes a physical machine and therefore operates at the hardware level. This means that a VM contains a complete OS and requires a hypervisor on the host to run multiple VMs independently.

A container places the virtualisation on top of the operating system. Containers therefore share the kernel of the host. The applications are isolated on the basis of Linux namespaces and Cgroups.

By using the shared kernel and dispensing with a separate OS, containers have a lower overhead than VMs, but at the same time they provide weaker isolation. 

Isolation of containers

As containers have weaker isolation than VMs, it is important to shed light on this topic. As already mentioned, containers share the system kernel. Isolation takes place on the Linux namespaces and cgroups. However, this means that vulnerable kernels or container runtimes can enable attacks on the running containers. Conversely, this also means that a successful breakout from a container can have serious consequences for the host and the other containers.

Root or not-root

There are two particularly well-known container engines. Docker on the one hand and Podman on the other. The engine handles deploying and managing the containers, providing everything necessary for the user to interact with the system. The containers are then executed in the container runtime. The runtime takes care of the container processes and their isolation.

A major difference between Docker and Podman can be seen in the debate about processes that run as root. While Docker or the Docker daemon runs as root, which can have devastating effects, especially if an attacker breaks out of the container, Podman does without a daemon and runs containers directly in the user context. A potential attacker who breaks out of the container, therefore, does not have root rights per se. 

Your first container: A Simple 'Hello World' with Docker

Enough talk, let's put our words into action and build our first, fairly simple container. To do this, we need Docker and a Dockerfile, which contains all the instructions for building a container image. We can start with either a completely empty image or use a base image. The advantage of a base image is that it allows us to integrate an already familiar environment into the container. Our example is based on Rocky Linux 9, i.e. we carry out all further steps in the Dockerfile in the same way as we would in Rocky Linux. 

Firstly, we create a small bash script that we want to start later in the container. 

Now we create the following Dockerfile

We use dumb-init as ENTRYPOINT to execute a process with PID 1 in the container. This is important to act as an init process that handles signals correctly and avoids zombie processes. Even though it is not mandatory in our simple example, we recommend checking out this article by Laurenz Albe, which explains the importance of an init process for PostgreSQL containers. 

Difference between ENTRYPOINT and CMD

1. ENTRYPOINT: Specifies the main command that is executed when the container is started. The command in ENTRYPOINT runs as PID 1 and controls the behavior of the container. If ENTRYPOINT and CMD are used together, CMD provides the standard arguments for the command defined by ENTRYPOINT. 
2. CMD: Defines the default command or the default arguments that are executed when the container is started. CMD can be overwritten if other commands are specified when the container is started. It can be used alone or together with ENTRYPOINT to provide default arguments for the main command. 

Let's build and launch our container

Finally, we now want to build and launch the container.

Preview

The next post in the series will focus more on the topic of container construction. We will build our first PostgreSQL container and look at various concepts for the structure of Dockerfiles.  

In order to receive regular updates on important changes in PostgreSQL, subscribe to our newsletter, or follow us on Facebook or LinkedIn.