Journal Information

Title: Enfoque UTE
Copyright: 2023, Enfoque UTE
Abbreviated Title: Enfoque UTE
Volume: 15
Issue: 1
ISSN (electronic): 1390-6542
Copyright statement: License (open-access,
https://creativecommons.org/licenses/by/3.0/ec/):

Article Information

Date received: 22 September 2023
Date revised: 08 November 2023
Date accepted: 27 November 2023
Publication date: Dec. 2023
Publisher: Universidad UTE (Quito, Ecuador)
Pages: 36-44
DOI: https://doi.org/10.29019/enfoqueute.1005
http://ingenieria.ute.edu.ec/enfoqueute/



Containers-Based Network Services Deployment: A Practical Approach

Andrés Yazán1, Christian Tipantuña2, and Jorge Carvajal-Rodriguez3


Abstract

In recent years, virtualizing network services and functions has enabled optimizing hardware resources on resource-constrained devices, such as CPU, memory, and storage. Traditional virtualization is achieved through virtual machines using a layer known as a hypervisor. While this form of virtualization offers advantages such as scalability and portability, it has disadvantages in terms of performance compared to nonvirtualized deployments. In this context, alternative virtualization technologies (like containers) allow virtualization on the same physical infrastructure, improving overall performance, portability, and service scalability. This paper implements the deployment of network services on the Raspberry Pi development platform, which has limited resources. This is achieved through a multi-container virtualization solution using the Docker Compose tool, based on Docker containerization technology. Finally, a performance analysis of the implemented virtualization solution is conducted in terms of resource utilization by each service.

Keywords

Virtualization; Virtual Machines; Container Raspberry Pi; Docker; Docker Compose; Performance.

Resumen

En los últimos años, la virtualization de servicios y funciones de red ha permitido optimizar los recursos de hardware, como CPU, memoria y almacenamiento, en equipos con limitaciones de recursos. La virtualization tradicional se lleva a cabo mediante máquinas virtuales, utilizando una capa conocida como hipervisor. A pesar de que esta forma de virtualization ofrece ventajas como escalabilidad y portabilidad, presenta desventajas en términos de rendimiento en comparación con un despliegue no virtualizado. En este contexto, han surgido tecnologías alternativas de virtualization (como los contenedores) que permiten la virtualization en la misma infraestructura física, mejorando el rendimiento general, la portabilidad y la escalabilidad de los servicios. En este artículo se implementa el despliegue de servicios de red en la plataforma de desarrollo Raspberry Pi que cuenta con recursos limitados. Esto se logra mediante una solución de virtualization multicontenedor utilizando la herramienta Docker Compose, basada en la tecnología de contenerización Docker. Finalmente se lleva a cabo un análisis del rendimiento de la solución de virtualization implementada en términos de la utilization de recursos por parte de cada uno de los servicios.

Palabras Clave

Virtualization; Máquinas Virtuales; Contenedor; Raspberry Pi; Docker; Docker Compose; Rendimiento.



I. Introduction

THE growing demand for network services, applications, and resources from end-users has created limitations in the capacity of service providers to meet these needs due to a shortage of necessary hardware resources to scale proportionally to the demands. Service providers have had to adopt new technologies to meet current demands, maximize resource efficiency, and offer end-users high-quality service (QoS). In this context, virtualization technologies plays a fundamental role in the information technology industry. While virtualization technologies such as Virtual Machines (VMs) provide virtualized services, they present significant performance and resource efficiency problems. For this reason, container-based virtualization technologies have become the preferred choice, as they offer highly efficient virtualized services by operating directly on a device’s native software infrastructure, leveraging the features of an operating system kernel to create virtualization. These features include ‘namespaces’ and ‘cgroups’, which provide an isolated and independent environment within the native infrastructure in which they run [1].

This paper aims to describe, implement, and analyze a solution for network services based on Docker containers. Is analyzed the performance of containerized services in environments with limited CPU, memory, and storage resources, such as Raspberry Pi development boards. To achieve this, the work is structured as follows:

Section II: A brief description of concepts and related work on virtualization technologies, virtual machines, Docker containers, network services, and microservices is provided.

Section III: Describes the methodology, test environment, software tools, and hardware used for designing and implementing network services using Docker containers.

Section IV: are presented the results obtained in the implementation, and evaluated the performance of the implemented containerization system based on CPU usage, memory usage, and load.

Section V: Provides concluding remarks about the work developed.

II. Background and Related Work

This section presents the fundamental concepts of virtualization architectures based on Virtual Machines (VMs), followed by container-based virtualization, emphasizing Docker technology. Additionally, we will provide a brief description of microservices infrastructure.

Virtualization is a process or technology that allows the segmentation of software and hardware resources from a physical architecture to deploy multiple dedicated resources in virtual environments for processes or applications. The main virtualization technologies include those based on hypervisors and container-based technologies. Hypervisor-based technology adds a layer of software to the conventional computational architecture, specifically to the underlying operating system, also known as the hypervisor. This layer virtualizes and manages the system’s physical resources, such as CPU, RAM, and storage, distributing them optimally for each Virtual Machine (VM). Thus, the hypervisor creates an isolated environment for each VM with its complete operating system, allowing independent execution from the main operating system [2], However, this hypervisor-based approach may decrease overall performance, especially in environments with high resource demand. It is important to note that this hypervisor layer is present in all traditional virtualization technologies, meaning its negative impact on performance is constant in any implementation case, as mentioned [3].

On the other hand, containerization technologies are software that represents a virtualization operating at the kernel level of the operating system. They enable the execution of applications and services in isolated and portable environments within the same physical system, called containers [2], Additionally, using namespaces and cgroups, this technology allows the isolation and resource management for each container [4].

In practice, container processes outperform hypervisorbased solutions by eliminating the virtualization layer and operating directly on the host system’s kernel, as shown in Figure 1 [2], In addition to this advantage, containers have inherent characteristics derived from underlying technologies, such as autonomy and independence between containers in resource usage and deployment. Portability is also noteworthy, as containers use lightweight application images, usually in the order of MBs, compared to the GBs images of VMs that include a complete operating system. These features enable services to achieve high scalability and easy migration. Furthermore, they ensure high service availability by allowing the execution of multiple instances of the same application to maintain uninterrupted service, even if one or more containers of the same image stop working [1], [3], [5]. These advantages are enhanced when combined with a microservices- based architecture, which defines a software design model with functions of a service distributed through autonomous and independent modules (Figure 2b), unlike the traditional architecture of monolithic applications, where functions are integrated into a single structure and are interdependent (Figure 2a) [6]. Container characteristics allow leveraging this type of model to optimize service deployment, unlike those based on VMs.

On the other hand, containers also have disadvantages compared to VMs. For example, although containers are independent and isolated entities, they do not provide complete isolation with the operating system where they share kernel resources, as in the case of VMs. This, in turn, poses a security issue, as any impact at the operating system level can affect containers, as indicated in previous lines [7], [8], [9].

In environments with limited hardware resources, such as the one in this study, a container-based approach leverages these characteristics for optimal and scalable service deployment. In this case, security is not a parameter of study, this work focuses exclusively on measuring resource usage.

Docker is an open-source containerization technology that creates, runs, and manages fightweight, portable, and self- sufficient containers. These features have established Docker as a leader in the containerization technology market [10]. Docker implements its architecture on the operating system kernel to achieve container deployment with these characteristics, utilizing namespaces and cgroups to isolate and manage container resources. Docker also uses a file system known as the ‘Advanced Union File System’ (AUFS) for layer based image construction, contributing to storage resource optimization during Docker image creation [11].


(a) Virtualization Architecture based on Hypervisor

(b) Virtualization Architecture based on Containers

Fig. 1. Virtualization Architectures Comparison, based on [2], [4].


(a) Monolithic Architecture.

(b) Microservices-based Architecture.

Fig. 2. Comparison of service architectures, based on [6].


Above the underlying technologies, there is Docker’s architecture known as ‘Docker engine’, which is the specific name for the containerization technology developed by Docker. This architecture comprises ‘Docker objects’, representing functionalities within the Docker environment. These functionalities relate to storage, networking, container images, and containers. These elements can have different types depending on their utility and characteristics. Docker objects related to storage functionality are called ‘Docker volumes’. These are storage mechanisms created from directories or files stored on the host. Once created, directories are mounted into the container to access a file system outside the isolated environment, as shown in Figure 3a [12].

On the other hand, storage mechanisms are similar to volumes known as ‘bind mounts’. Unlike volumes, these are not managed by Docker. They allow data to be mounted to a specific folder on the host into a container, and the stored data persists beyond the container’s lifecycle, as illustrated in Figure 3b [13]. ‘Volumes’ and ‘bind mounts’ can be used by multiple containers to share the same storage space. Additionally, these mechanisms can be employed for migrating data from containerized services, considering their functionality and ability to maintain data persistence between containers and over time.

Regarding network functionalities, Docker offers what are known as ‘Docker networks’, entities responsible for providing basic network functionalities through ‘network drivers’, which share the same name as the network they manage [14]. Docker provides three default networks:

(a) Volumes

(b) Bind Mount

Fig. 3. Docker storage mechanisms: Volumes, Bind Mounts, Tmpfs Mounts, based on [12], [13].

It is worth mentioning that, according to [18], [19], [20], ‘bridge’ type networks tend to have lower performance than other types of networks. On the other hand, ‘host’ type networks, due to their network characteristics, do not have an abstraction level that limits their performance, as is the case with ‘Bridge’ type networks.

III. Methodology

This section describes the process and methodology for implementing network services in Docker containers. All files used for deploying the services, such as ‘dockerfiles’ and ‘Docker compose’, along with the employed procedure, are available in [21]. The images corresponding to the implemented services are also hosted in the Docker Hub repository in [22].

A. Scenario

The implemented solution is based on Docker Compose and utilizes two Raspberry Pi boards to carry out a multi-container deployment of services. These services constitute a traditional Internet architecture, including DHCP, DNS, FTP, Web, VoIP, and Routing. All of this is achieved through a YAML file. In this approach, one of the Raspberry Pi boards serves as the main host for the containerized services, while the second one is used for remote client connections through the containerized DHCP and Routing services.

In this work, the performance of containerized services is examined in a wired connection, taking into account the delays that a wireless network may introduce. This approach is essential for delay-sensitive services, such as VoIP services, which require delays below 150 ms. A more detailed exploration of this approach is reserved for future work.

B. Physical and logical configurations

Each Raspberry Pi board uses USB-Ethernet adapters from the Realtek brand, model RTL8152, with up to l00baseT/FullDuplex capacity. This is done to expand the number of physical ports available for the routing service. There are 4 Ethernet interfaces, 1 WLAN interface, and five virtual WLAN interfaces. These interfaces are associated with both an IPv4 address of a containerized service and a monitoring application, as shown in Figure 5, representing the logical distribution of the implementation on the Raspberry Pi board. Figure 6, illustrates the topology for the joint implementation through Docker Compose. The Access Point function is also used on one of the Raspberry Pi boards using Hostap software. This is done to establish a wireless connection for network monitoring. The SSH remote access service installs the board’s dependencies, access, and configuration. This enables wireless access to the equipment’s configuration or through any available Ethernet cable.

C. Base images for docker containers

The base images for Docker containers are based on Alpine Linux, the recommended choice for conserving storage resources in both the resulting images and container instances, as shown in [23]. As for service images, Nginx, Asterisk, and FRRouting are already available as dedicated images in the ARM32v7 architecture. Therefore, instead of building these services completely, files based on these images are generated to leverage their functionality.


(a) None Networks

(b) Bridge Networks

(c) Host Networks

Fig. 4. Docker networks: None, Bridge, and Host Networks, based on [18].


D. Storage

Two types of volumes are used for storage: Named Volumes and Bind Mounts. Named Volumes are used to maintain the persistence of logs from containerized services and to share them with other containers. On the other hand, bind mounts are used to configure container files directly from the host.


Fig. 5. Design: Logical distribution of Docker Containers on the Raspberry Pi board.


E. Docker networks

Regarding Docker networks, the ‘host’ type network is used exclusively. This choice is based on previous considerations about Docker network performance and aims to optimize the implementation’s performance.

F. Measurement tools, metrics ant testing setup

For the performance analysis of containerized services, various general performance parameters are considered, such as CPU usage, memory usage, CPU load average, network traffic in and out, and a physical parameter, CPU temperature, for each containerized service. To perform this task, two computing devices are used to test the services: i) One to evaluate the service’s operation and ii) A second to monitor the host’s performance. Detailed descriptions of these devices can be found in Table I.

Client 2, acting as a monitoring device in the topology shown in Figure 6, connects wirelessly via SSH to collect these metrics using various software tools. Among them is the ‘docker stats’ command from Docker, which measures CPU and memory usage performance, and ‘Htop’ as a tool for visualizing CPU and RAM system resources and processes. Additionally, the RPI-Monitor tool, a monitoring software based on a web interface, is employed for system usage statistics visualization on Raspberry Pi devices. This allows access to performance metric data such as CPU load average, memory usage, and additional parameters like temperature.


Fig. 6. Design: Container-Based Service Deployment Topology using Docker Compose.


Table I. Hardware Used for the Test Scenario

Model

Processor

Ram Memory

Operative System

LENOVO IdeaPad S410p

Intel(R) Core(TM) i5-4200 de 64bits CPU@1.6GHz

8 GB

Windows 10 Pro

HP 15-ef1xxx

AMD Ryzen 5 4500U de 64bits CPU@2.38GHz

8GB

Windows 11 Home

Raspberry Pi 4B

Broadcom BCM2711 Cortex-A72 (ARM v8) de 64bit @1.8GHz

4GB

Debian 11 (Bullseye)


Furthermore, it is essential to consider the analysis of services such as VoIP and assess Quality of Service (QoS) parameters like delay and jitter [24], For this purpose, Wireshark software is used on each device in Figure 6, allowing the capture and analysis of data packets based on SIP and RTP protocols. This provides a deeper insight into the quality of real-time communication. For the measurement process, measurements are taken during specific periods for each containerized service, and then the data is tabulated according to the respective measurement period. The data from each service’s test period is used and averaged in the case of results obtained through the RPI-Monitor tool. For data obtained through HTOP and Docker stats, the maximum values for each metric are taken, as visualized in the open SSH terminals during the test period.

G. Service software

The network services implemented in Docker containers are based on Linux servers following a client-server architecture. In this context, each service incorporates a daemon that runs and manages the services according to predefined configuration parameters. Below are the details of each software, its configuration, and the type of implementation in containers:

IV. Results

A. CPU and Memory Performance Analysis

In this section, are presented the results obtained from the implementation using Docker Compose. As initial indicators of the results, data collected through the ‘Rpi-Monitor’ tool are obtained, which display CPU utilization statistics in Figure 7a, memory usage in Figure 7b, and CPU temperature in Figure 7c, over an entire testing interval for each of the containerized services. For the deployment using Docker Compose, the CPU load average indicator starts with an initial value of 1.88 (47.08 %) at the host’s startup. Subsequently, this load decreases to 0.37 (9.25 %). From this point onwards, the network service tests are initiated and divided into sections as detailed below.

(a) Resource Usage: CPU Load Average.

(b) Resource Usage: Memory Usage.

(c) Resource Usage: Temperature.

Fig. 7. Resource Usage Using RPI-MONTTOR for Docker Compose.

Figure 7b shows the system memory usage, which remains constant as the tests run. The available free memory starts at 3 280 MB during the host’s startup and remains close to 3 176.5 MB. This reflects a constant memory usage of approximately 617.8 MB, concerning a total of 3 794.32 MB of available memory.

In Figure 7c the CPU temperature can be observed, which goes from 35.95°C at startup and increases to maintain an average temperature of 38.6°C, with a maximum of 39.2°C during the HTTP tests. After the VoIP tests, it drops to 36.7°C.

The second performance indicator obtained through the ‘docker stats’ and ‘htop’ tools is detailed in Table II. The DNS service stands out with a maximum CPU usage of 15.02 %, followed by the FTP service with usage of up to 11.89 %, and the VoIP service with 5.18 %. The other containerized services show relatively low values, all below 1 %.

Regarding memory usage, the DNS service also has the highest value, with 1.1 %, followed by the VoIP service, with 0.8 %. It is important to note that these memory values are constant for all services during the Docker Compose implementation.

B. Quality of Service Analysis

The analysis of RTP traffic provides information about the QoS of the VoIP service, as detailed in Figure 8. The results for VoIP calls are similar to those implemented previously, including:

V. Conclutions

Table II. Resource Usage: CPU Usage Via Docker Stats and Etop

Server

Docker Stats - Max.

CPU Usage (%)

HTOP - Max

CPU Usage (%)

HTOP - Max. RAM

Memory Usage (%)

DHCP WlanO

0.11

0.0

0.2

DHCP Ethl

0.11

0.0

0.2

DHCP Eth2

0.11

0.0

0.2

DNS

15.02

7.3

1.1

FTP

11.89

8.5

0.0

HTTP (www, web 1, web2)

0.47

0.7

0.1

VoIP

5.18

5.3

0.8

Routing

0.12

0.10

0.1


(a) VoIP Service: RTP Details of Calls for Client 1

(b) VoIP Service: RTP Details of Calls for Client 2


Fig. 8. VoIP Service: SIP Call Details for VoIP Calls.

Authors acknowledge the support provided by Escuela Politécnica National in the project PIIF-21-04. Corresponding author: christian.tipantuna@epn. edu.ec.

1 Andrés Yazán is in the Department of Electronics, Telecommunications and Information Networks of the National Polytechnic School, Quito 170517, Ecuador, (e-mail: andres.yazan@epn.edu.ec). ORCID number 0009-0001- 7811-1275.

2 Christian Tipantuña is in the Department of Electronics, Telecommunications and Information Networks of the National Polytechnic School, Quito 170517, Ecuador, (e-mail: christian.tipantuna@epn.edu.ec). ORCID number 0000-0002-8655-325X.

3 Jorge Carvajal-Rodriguez is in the Department of Electronics, Telecommunications and Information Networks of the National Polytechnic School, Quito 170517, Ecuador, (e-mail: jorge.carvajal@epn.edu.ec). ORCID number 0000-0003-0369-9964.

References

[1] A. Khan. Key Characteristics of a Container Orchestration Platform to Enable a Modem Application. Vol. 4. 2017, pp. 42-48. Available: doi: 10.1109/MCC.2017. 4250933.

[2] T. Salah, M. J. Zemerly, C. Y. Yeun, M. Al-Qutayri, and Y. Al-Hammadi. Performance Comparison Between Container-Based and Vm-Based Services. Institute of Electrical and Electronics Engineers Inc., 2017, pp. 185-190. isbn: 9781509036721. Available: doi: 10.1109/ICIN.2017.7899408.

[3] Z. Kozhirbayev and R. O. Sinnott. A Performance Comparison of Container-Based Technologies for the Cloud. Vol. 68. North-Holland, 2017, pp. 175-182. Available: doi: 10.1016/J.FUTURE.2016.08.025.

[4] A. Bhardwaj and C. R. Krishna. Virtualization in Cloud Computing: Moving from Hypervisor to Containerization — A Survey. Vol. 46. Springer Science and Business Media Deutschland GmbH, 2021, pp. 8585-8601. Available: doi: 10.1007/s13369-021-05553-3.

[5] V. G. da Silva, M. Kirikova, and G. Alksnis. Containers for Virtualization: An Overview. Vol. 23. Walter de Gruyter GmbH, 2018, pp. 21-27. Available: doi: 10. 2478/acss-2018-0003.

[6] V. Singh and S. K. Peddoju. Container-based Microservice Architecture for Cloud Applications. 2017. ISBN: 9781509064717. Available:

[7] S. Sultan, I. Ahmad, and T. Dimitriou. Container Security: Issues, Challenges, and the Road Ahead. Vol. 7. Institute of Electrical and Electronics Engineers Inc., 2019, pp. 52976-52996. Available: doi: 10.1109/ ACCESS.2019.2911732.

[8] E. Casalicchio and S. lannucci. The State-of-the-Art in Container Technologies: Application, Orchestration and Security. Vol. 32. John Wiley and Sons Ltd, 2020. Available: doi: 10.1002/cpe.5668.

[9] J. Chelladhurai, P. R. Chelliah, and S. A. Kumar. Securing Docker Containers from Denial of Service (DoS) Attacks. Institute of Electrical and Electronics Engineers Inc., 2016, pp. 856-859. isbn: 9781509026289. Available: doi: 10.1109/SCC.2016.123.

[10] C. C. Chen, M. H. Hung, K. C. Lai, and Y. C. Lin. Docker and Kubemetes. In Industry 4.1: Intelligent Manufacturing with Zero Defects. 2022. Vol. 1, pp. 169- 213. Available: doi: 10.1002/9781119739920.ch5.

[11] K. Kumar and M. Kurhekar. Economically Efficient Virtualization Over Cloud Using Docker Containers. Institute of Electrical and Electronics Engineers Inc., 2016, pp. 95-100. isbn: 9781509045730. Available: doi: 10.1109/CCEM.2016.24.

[12] S. Bhat. Understanding Docker Volumes. In Practical Docker with Python: Build, Release, and Distribute Your Python App with Docker. Berkeley, CA: Apress, 2022, pp. 105-132. isbn: 978-1-4842-7815-4. Available: doi: 10.1007/978-1-4842-7815-4_5.

[13] N. G. Bachiega, P. D. Souza, S. M. Bruschi, and S. D. Souza. Performance Evaluation of Container’s Shared Volumes. Institute of Electrical and Electronics Engineers Inc., 2020, pp. 114-123. isbn: 9781728110752. Available: doi: 10.1109/ICSTW50294.2020.00031.

[14] Dockerinc. Networks Overview - Docker Documentation. Available: [Online]. Available: https://docs.docker. com/network/.

[15] Dockerinc. Disable Networking for a Container - Docker Documentation. Available: [Online]. Available: https://docs.docker.com/network/none/.

[16] Dockerinc. Use Bridge Networks - Docker Documentation. Available: [Online]. Available: https://docs.docker. com/network/bridge/.

[17] Dockerinc. Use Host Networking - Docker Documentation. Available: [Online]. Available: https://docs.docker. com/network/host/.

[18] R. Dua, S. K. Konduri, and V. Kohli. Learning Docker Networking: Become a Proficient Linux Administrator by Learning the Art of Container Networking with Elevated Efficiency Using Docker. 1st ed. Packt Publishing Ltd., 2016. Vol. 1, pp. 2-11. isbn: 9781785280955. Available:

[19] S. Kun, Z. Yong, C. Wei, and R. Jia. An Analysis and Empirical Study of Container Networks. Institute of Electrical and Electronics Engineers Inc., 2018, pp. 189-197. isbn: 9781538641286. Available: doi: 10.1109/INFOCOM.2018.8485865.

[20] L. L. Mentz, W. J. Loch, and G. P. Koslovski. Comparative Experimental Analysis of Docker Container Networking Drivers. Institute of Electrical and Electronics Engineers Inc., 2020, pp. 1-7. ISBN: 9781728194868. Available: doi: 10. 1109 / CloudNet51028 . 2020 . 9335811.

[21] A. Endara. Network Service on Containers. 2023. Available: [Online]. Available: https://github.com/AndresYE/Network_Service_on_Containers_a_Practical-Approach.

[22] A. Endara. Network Service on Containers - Docker Hub. 2023. Available: [Online]. Available: https://hub.docker.eom/u/andresye.

[23] J. Islam, E. Harjula, T. Kumar, P. Karhula, and M. Ylianttila. Docker Enabled Virtualized Nanoservices for LocalloT Edge Networks. 2019. ISBN: 9781728108643. Available:

[24] M. Mejia, C. Ortiz, W. Ramos, and L. Moscoso. Network Traffic Management in the Quality of Service ‘QoS’ WAN in Tambopata-Peru 2021. Vol. 28. 2022, pp. 300-318. Available:

[25] W. Kithulwatta, K. Jayasena, B. Kumara, and R. Rathnayaka. Performance Evaluation of Docker-based Apache and Nginx Web Server. In 2022 3rd International Conference for Emerging Technology (INCET). 2022, pp. 1-6. Available: doi: 10.1109/INCET54531. 2022.9824303.