SciELO - Scientific Electronic Library Online

 
vol.15 número1Powder Detergent Packaging Line Improvement by Lean Six Sigma DMAIC Methodology índice de autoresíndice de materiabúsqueda de artículos
Home Pagelista alfabética de revistas  

Servicios Personalizados

Revista

Articulo

Indicadores

Links relacionados

  • No hay articulos similaresSimilares en SciELO

Compartir


Enfoque UTE

versión On-line ISSN 1390-6542versión impresa ISSN 1390-9363

Enfoque UTE vol.15 no.1 Quito ene./mar. 2024

https://doi.org/10.29019/enfoqueute.1005 

Miscellaneous

Containers-Based Network Services Deployment: A Practical Approach

Andrés Yazán1 
http://orcid.org/0009-0001-7811-1275

Christian Tipantuña2 
http://orcid.org/0000-0002-8655-325X

Jorge Carvajal-Rodriguez3 
http://orcid.org/0000-0003-0369-9964

1Department of Electronics, Telecommunications and Information Networks of the National Polytechnic School, Quito 170517, Ecuador, e-mail: andres.yazan@epn.edu.ec.

2Department of Electronics, Telecommunications and Information Networks of the National Polytechnic School, Quito 170517, Ecuador, e-mail: christian.tipantuna@epn.edu.ec.

3Department of Electronics, Telecommunications and Information Networks of the National Polytechnic School, Quito 170517, Ecuador, e-mail: jorge.carvajal@epn.edu.ec.


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 inFigure 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).

Fig. 1 Virtualization Architectures Comparison, based on(2),(4)

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 inFigure 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 inFigure 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:

None: This Docker network has no network interface outside the container. It only has a connection between the container and the loopback interface, and it is commonly used for offline testing, as illustrated inFigure 4a (15).

Bridge: The ‘bridge’ network is Docker’s default network and uses Linux’s bridge functionality to allow communication between containers. Docker creates virtual connections between containers and the virtual network interface called ‘dockerO’, as shown inFigure 4b. An internal network is created when this connection is established, and IP addresses are automatically assigned to each container, enabling communication within this network. However, initially, they cannot communicate outside of this network. Nevertheless, using iptables and Docker’s Network Address Translation (NAT), it is possible to configure the port mapping to allow communication from the container network to the external network(16).

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

Host: The ‘host’ network allows the container to share the same network namespace as the host. In other words, the container shares all network interfaces of the host without any level of abstraction between them, as shown inFigure 4c. Due to this configuration, this network offers better performance than other networks, as it does not require addressing, port mapping, or NAT for container connections to an external network since the container network is identical to the host network. However, it is important to mention that if two or more containers attempt to use the same port under a host network, conflicts may arise(17).

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 inFigure 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.

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 inTable I.

Client 2, acting as a monitoring device in the topology shown inFigure 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 

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 inFigure 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:

Domain name resolution service: It uses a server based on the Internet Systems Consortium’s Berkeley Internet Name Domain (Bind9), one of the most popular DNS servers in Linux distributions. This server acts as a master server, locally hosting primary DNS zone records and responding to pre-configured name resolution requests for each containerized service and the monitoring service.

Addressing service: It is based on the Internet Systems Consortium DHCP (ISC DHCP) server, widely used for IP address assignment and network configuration. The implementation follows a basic configuration of IPv4 address assignment to DHCP clients, providing the addresses of the containerized DNS server and the gateway address configured for each of the Raspberry Pi’s Ethernet ports.

File transfer service: It uses the Very Secure File Transfer Protocol (VSFTP) server, which allows secure and efficient file or directory transfers. The implementation uses active mode and supports custom file transfers for configured local users. These users are within a chroot environment containing a 64KB file and 70KB of storage space for file transfers with the FTP client.

Web service: It uses a server based on Nginx, known for its high performance, scalability, and low resource consumption(25). The web service implements a default web server along with two virtual web servers based on Nginx virtual blocks, allowing the hosting of multiple web pages. These pages are accessed along with the aforementioned containerized DNS service.

VoIP service: It is based on the Sangoma Asterisk server, an open-source framework under the GPL license that enables the development of real-time multiprotocol communication applications, such as high-quality voice and video applications. This service implements a PBX server to configure and manage VoIP extensions. Four IP phone station extensions are configured, of which two are used for functional tests between two clients connected to the Raspberry Pi’s Ethernet ports to evaluate the containerized VoIP service without the limitations of wireless connections.

Routing service: It is based on the open-source FRRouting software, providing traditional router functionality. For the current implementation, the OSPF protocol is one of the most widely used routing protocols today. This protocol is the routing system between the Raspberry Pi boards, enabling connection to the services.

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 inFigure 7a, memory usage inFigure 7b, and CPU temperature inFigure 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.

Section I (11:30 am - 11:40 am) - Routing: During the connection between the RPI devices, a maximum load value of approximately 1.0 (25 %) can be observed. This value corresponds to the initial OSPF routing process between the devices.

Section II (11:45 am - 11:50 am) - End-to-end Connection: When starting the end-to-end connection tests between the clients. During this period, the maximum load value reached is 0.518 (12.95 %).

Section III (11:52 am - 11:53 am) - Connection to servers: The maximum load reached during the tests for connections to the containerized servers is 0.5 (12.5 %).

Section IV (11:53 am - 11:54 am) - DNS: In this section, the load reaches values of 0.44 (11 %).

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

Section V (11:59 am - 12:00 pm) - HTTP: The load reached during the access to the HTTP pages obtains a maximum value of 0.863 (21.575 %). Additionally, according to the DNS traffic I/O graphs analysis, the traffic increases considerably during the HTTP testing period and remains elevated after this test.

Section VI (12:00 pm - 12:04 pm) - FTP: During the tests of the 2 FTP connections, maximum load values of 0.801 (20.025 %) are recorded for client 1.

Section VII (12:04 pm - 12:22 pm) - VoIP: During the VoIP tests, it is observed that during the call from extension 2001 to extension 2002, the CPU load reaches its peak, reaching 0.413 (0.33 %). The load remains low for the rest of the calls at an average of 0.180 (4.5 %).

Figure 7bshows 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.

InFigure 7cthe 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 inTable 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 inFigure 8. The results for VoIP calls are similar to those implemented previously, including:

Payload codec: g711U vocoder.

Packet loss: 0 % packet loss for all calls.

Delays: Minimal delays are recorded, with slightly higher values for client 1 than for client 2. The averages of these values are 18.39 ms for client 1 and 7.63 ms for client 2. The average delay is 19.99 ms for both clients, with maximum delays of 21.74 ms for client 1 and 32.87 ms for client 2.

Jitter: Regarding jitter, values vary significantly for client 2, where they can reach up to 7, while client 1 experiences jitters of up to 1.46.

V. CONCLUTIONS

Implementing network services through containers allows for effective deployment on systems with limited CPU, memory, and storage resources, such as Raspberry Pi boards. As demonstrated in services like HTTP and VoIP, these instances achieved a final product, a web page, or a voice call without significant degradation in service quality and with optimal resource usage. For example, three web pages were loaded without errors in the implementation using Docker CLI for HTTP, with CPU usage as low as 0.47 % and memory consumption as 0.1 %. Regarding the VoIP service, calls were made without distortions, delays, or audio loss, maintaining CPU usage at 5.18 % and memory consumption at 0.8 %.

The implementation of network services through containers has shown minimal resource usage in most cases. Services like DHCP, HTTP, and Routing show zero CPU and memory consumption. In contrast, services like DNS, FTP, and VoIP show high consumption. This can be partly explained by factors such as the volume of request traffic, which, in the case of DNS, was considerably higher than other services. It can also be due to the transfer of information, as in the case of FTP. Additionally, their position in the network architecture should be considered. This is because their location may imply implicit involvement in other services, which, in turn, can increase resource consumption. This is evident in the case of the DNS service when used implicitly to support web services when making domain name resolutions to access a web page.

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

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

The architecture of containerized services also significantly influences their performance. This is because the underlying software has a variety of architectures to offer the service. Some services, like DHCP, DNS, and FTP, adopt a simple client-server architecture based on daemons and configuration files. Others, like HTTP, VoIP, and Routing, have more complex architectures with dedicated modules to provide the service. For example, the HTTP service, based on NGINX, which allows for efficient deployment without containerization, highlights the importance of decentralization, even when dealing with a single application. Its structure consists of modules with internal management that favors efficiency. In contrast, services like VoIP and Routing have architectures that can be more challenging regarding management and performance.

Containerizing services provide a high level of scalability, allowing the deployment of multiple containers to provide versatile, flexible, and efficient services. An example is the DHCP service, where multiple containers based on the same image are deployed. This provides a highly flexible addressing service with multiple configurations available for deployment. This achievement is partly due to using environment variables, which allow modifying a containerized service without directly modifying it. This creates a scalable, dynamic, and adaptable service that can be efficiently offered to users, as determined by CPU usage and memory consumption.

Docker is a highly versatile tool that brings significant benefits to the deployment of network services. Its diverse ecosystem encompasses essential plugins, such as storage through volumes and bind mounts. In this context, it has been observed that these mechanisms allow interaction with a container’s file system, making it easier to modify and configure a service without the need to directly access the containerized environment or altogether remove the isolated environment to make changes. Additionally, it has been found that rebuilding containers using volumes is a valuable mechanism for migrating services. An example of this is the use of containers to store configuration logs, as in the case of routing services with ‘daemon’ and ‘zebra.config’ files or in the case of the DHCP service with lease records in ‘dhcpd.lease’. These records allow replicating the same configurations in other containers, ensuring the continuity of the service. However, it is important to note that logs stored via volumes can be prone to corruption. This is because, over time, these files can begin to record incomprehensible strings of characters, affecting the service’s operation.

Another highly versatile tool for service deployment is network controllers through network objects. These networks enable the configuration and modification of service management and communication, providing essential features such as network isolation, traffic control, access, and scalability. This flexibility is evident when implementing services with ‘bridge’-type networks. In this configuration, services were mapped to specific ports to allow external access through the container. As observed, using ports different from the default value for Network Address Translation (NAT) between the container and the external network provided greater isolation and security for the service. It also allowed the incorporation of multiple containers offering the same service but mapped to different ports to receive the service. This is especially useful in services like HTTP, where high scalability is achieved using a different port for each container. However, in services like passive FTP and VoIP, port mapping involves maintaining constant NAT over a range of ports (FTP: for transfer, random port >1 048, and VoIP: audio transmission via RTP, random port between 10 000 and 20 000). In these cases, considering a NAT that covers the entire port range to obtain service connection on a non-specific port was impractical as it affects performance, as mentioned in (19), (20). For this reason, using ‘host’-type networks, which remove the isolation level between containers and share the network with the host, allowed for services with low resource usage but limited scalability.

Regarding the containerized VoIP service, significantly high performance and QoS are observed when using Ethernet cable transmission. This is confirmed through RTP parameters captured with Wireshark, where the average delay of calls is 20 ms, compared to the maximum allowable delay of 150 ms, and maximum Jitter values of 7 ms between both implementations, staying below the maximum allowable of 50 ms. In summary, containerizing VoIP services for end-to-end calls through wired connections does not affect this QoS.

VI. REFERENCES

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

(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 20th Conference on Innovations in Clouds, Internet and Networks (ICIN), Paris, France, 2017, pp. 185-190. isbn: 9781509036721. Available: doi: 10.1109/ICIN.2017.7899408. [ Links ]

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

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

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

(6) V. Singh and S. K. Peddoju. “Container-based Microservice Architecture for Cloud Applications,” IEEE. 2017 International Conference on Computing, Communication and Automation (ICCCA). Greater Noida, India. 2017. ISBN: 9781509064717. Available: doi: 10.1109/CCAA.2017.8229914 [ Links ]

(7) S. Sultan, I. Ahmad, and T. Dimitriou. “Container Security: Issues, Challenges, and the Road Ahead,” IEEE Access, vol. 7, pp. 52976-52996, 2019, Available: doi: 10.1109/ ACCESS.2019.2911732. [ Links ]

(8) E. Casalicchio and S. lannucci. “The State-of-the-Art in Container Technologies: Application, Orchestration and Security,” Concurrency and Computation: Practice and Experience, vol. 32. John Wiley and Sons Ltd, 2020. Available: doi: 10.1002/cpe.5668. [ Links ]

(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 IEEE International Conference on Services Computing (SCC), 2016, pp. 856-859. isbn: 9781509026289. Available: doi: 10.1109/SCC.2016.123. [ Links ]

(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. [ Links ]

(11) K. Kumar and M. Kurhekar. “Economically efficient virtualization over cloud using docker containers,” Institute of Electrical and Electronics Engineers Inc., 2016 IEEE International Conference on Cloud Computing in Emerging Markets (CCEM), Oct. 2016, pp. 95-100, ISBN: 9781509045730. DOI: 10. 1109/CCEM.2016.24. [ Links ]

(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. DOI: 10.1007/978-1-4842-7815-4_5. [ Links ]

(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 IEEE International Conference on Software Testing, Verification and Validation Workshops (ICSTW), Oct. 2020, pp. 114-123, ISBN: 9781728110752. DOI: 10.1109/ICSTW50294.2020.00031. [ Links ]

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

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

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

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

(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., Feb. 2016, vol. 1, pp. 2-11, ISBN: 9781785280955. [ Links ]

(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., IEEE INFOCOM 2018 - IEEE Conference on Computer Communications, Apr. 2018, pp. 189-197, ISBN: 9781538641286. DOI: 10.1109/INFOCOM.2018.8485865. [ Links ]

(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 IEEE 9th International Conference on Cloud Networking (CloudNet), Nov. 2020, pp. 1-7. ISBN: 9781728194868. DOI: 10.1109/CloudNet51028.2020.9335811. [ Links ]

(21) A. Endara. Network Service on Containers. Aug. 2023. Available: (Online). Available:https://github.com/AndresYE/Network_Service_on_Containers_a_Practical_Approach. [ Links ]

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

(23) J. Islam, E. Harjula, T. Kumar, P. Karhula, and M. Ylianttila. “Docker enabled virtualized nanoservices for localiot edge networks,” IEEE, 2019 IEEE Conference on Standards for Communications and Networking (CSCN), 2019, ISBN: 9781728108643. [ Links ]

(24) M. Mejia, C. Ortiz, W. Ramos, and L. Moscoso. “Network traffic management in the quality of service “qos” wan in tambopata-peru 2021,” Revista de Ciencias Sociales (RCS), vol. 28, pp. 300- 318, 2 Jun. 2022, ISSN: 1315-9518. [ Links ]

(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), IEEE, 2022, pp. 1-6. DOI: 10.1109/INCET54531.2022.9824303. [ Links ]

Received: September 22, 2023; Revised: November 08, 2023; Accepted: November 27, 2023

Corresponding author: E-mail: christian.tipantuna@epn.edu.ec

Creative Commons License This is an open-access article distributed under the terms of the Creative Commons Attribution License