The elderly social care IT company Phoniro is developing solutions for deploying software using docker technologies. To secure quality in their deploy pipelines Phoniro would like to do automatic selenium testing within Docker containers. The project should set the framework and required technical solution to enable this and also run some basic test including suitable reporting on test success. This is a concept that is new to Phoniro that would allow them, if proven, to automate testing in a safe environment, and pushing their web applications to deployment faster. The purpose is to prove this concept by creating a framework that will easily let the user run web applications inside a Docker container. Then run this framework inside of a pipeline to see the testing capabilities. The user is supposed to be able to do this without any previous knowledge of how docker works. We have developed a framework in Python that enables the user to build and run their web application inside a docker container. We built a pipeline and connected it to the repository with the source code for the web application. The framework is run inside the pipeline to start the container, followed by simple selenium tests that we created to test the concept. We have proven the concept to run and test web applications in docker containers inside of pipelines to work. It is possible connect a web application in development to a repository, connect it to a pipeline and have it automatically test the application every time a change is made to the source code. By designing proper selenium tests the pipeline can save a lot of time and effort that is otherwise spent on manual testing

Containers are an alternative to virtual machines rapidly increasing in popularity due to their minimal overhead. To help facilitate their adoption, containers use management systems with central registries to store and distribute container images. However, these registries rely on other, preexisting services to provide load balancing and storage, which limits their scalability. This thesis introduces a new registry design for Docker, the most prevalent container management system. The new design coalesces all the services into a single, highly scalable, registry. By increasing the scalability of the registry, the new design greatly decreases the distribution time for container images. This work also describes a new Docker registry benchmarking tool, the trace player, that uses real Docker registry workload traces to test the performance of new registry designs and setups. / Master of Science

Background:  Cloud computing technology has come a long way with various technological advancements in the past few years. It has been accelerated with the evolution of various virtualization technologies. Currently almost every social platform and small-scale applications look towards cloud to deploy their services successfully and provide maximum satisfaction to their end-user. Thus, virtualizing their services becomes utmost important to deploy and develop their applications. This alone emphasizes the importance of Docker containers in the development world. Docker containers right now are playing a very important role in the field of cloud computing. Since Multimedia plays a huge role in our day to day lives and most people crave for faster and efficient responses, it is essential to develop our applications with better Real time communication capabilities. Thus, we are determining which container orchestration tool serves best for Real time communication applications.  A multimedia application is developed and deployed using WebRTC based Kurento media server and the performance of the server is measured when the application is deployed. We have chosen Kubernetes and Docker Swarm as container platforms for this thesis. The Servers and Clients are virtualized and metrics such as CPU Utilization, Network Traffic, Container overhead, Memory Utilization are measured. These metrics provide the performance overhead in different scenarios for each orchestration technology. This will be helpful to analyze and understand the effect of Kurento server on these technologies. Thus, the results are expected to determine which orchestration technology serves best for RTC applications. Objectives: The objectives of this project are:  • To implement WebRTC based Kurento server in a container orchestrated environment.  • To extract performance metrics such as Network Traffic, CPU and Memory Utilization while server is running.  • To compare WebRTC based Kurento server in Kubernetes and Docker Swarm.   Method: Kubernetes and Docker Swarm environments are setup and then docker images with video conferencing application(One-to-One call and One-to-Many call) using Kurento media server is deployed in them. Once either of the applications is running, experiments are performed for analyzing performance metrics like CPU Utilization, Memory Utilization, Network Traffic and overhead using monitoring tool, Prometheus. Along with Kubernetes and Docker Swarm, Kurento server is also deployed on a stand-alone container to estimate the performance overhead. Later, statistical analysis(ANOVA and differences of Standard error) is done over these metrics and conclusions are drawn.  Results: Based on the performed experiments and the extracted metrics, for One-to-One call application, Kubernetes showed better resource utilization for CPU and Network Traffic while it consumed more memory over Docker Swarm. Similar behaviour is observed for One-to-Many application. When application is scaled, the percent of resource utilization increase in Kubernetes is higher when compared to Docker Swarm, but overall resource utilization of Kubernetes is much lower than that of Docker Swarm.  Conclusions: WebRTC based Kurento media server is investigated in  Kubernetes and Docker Swarm. From the detailed analysis there is significant overhead in Docker Swarm than in Kubernetes for CPU Utilization and Network Traffic. For Memory Utilization, this is opposite. Packet Loss resulted in 0 percent as network transfer is within the same network . By considering all the metrics and providing evidence that numbers obtained in this thesis are statistically significant and not by fluctuations(ANOVA and post-hoc analysis), we can better recommend Kubernetes over Docker Swarm for Web based Real Time Communication.   However, not all applications need the complex deployment, scheduling, and scaling services (or the overhead) that Kubernetes offers. But to meet the increasing demand for seamless Real time communications, and to suffice user requirements, the overheard offered by it is acceptable.

Detta arbete utvärderar nyttan av att konstruera ett kluster med ett företags eller en organisations befintliga datorer. Klustret baserat på vanliga persondatorer kan blisom ett alternativ att driftsätta applikationer och tjänster. Alternativet är i stället föratt införskaffa serverar och högprestandadatorer. Detta kan bidra till att minska kostnader och återanvända resurser som redan finns. Arbetet mäter klustrets prestanda och effektivitet, därefter jämför resultatet med andra datorer och system. Arbetet utförs hos Syntronic och Högskolan i Gävle, där arbetet använder sig av de resurser som både parterna har och arbetet konstruerar varsitt kluster att mäta med.Resultatet visar att ett kluster byggd av datorer från Syntronic och högskolan presterar jämförbart med konsumentklassade processorer som kan hittas i nya datorer. Resultatet visar dock att bägge klustren har varken någon ekonomisk eller ekologisk fördel jämfört med nya datorer. Det är mer gynnsamt att sälja av Syntronics och Högskolans datorer i andrahandsmarknaden, för att sedan införskaffa nya datorer. / This thesis evaluates a cluster according to energy efficiency and performance. A cluster made of computers that a company, or an organization already owns, without purchasing any computers. The cluster based on older commodity computersacts as an alternative for operating and running software instead of buying server or high-end hardware. Reason for creating a cluster out of existing computers is mainly for reducing expenses and reuse hardware that otherwise considers as waste. This thesis measures the clusters performance and efficiency, then compares the results with other hardware and systems. This thesis uses computers from Syntronic and University of Gävle. This thesis creates a cluster each, one at Syntronic, one at University of Gävle and then measures them. The result shows that a cluster made of Syntronics computer performs equally amongst systems with a consumer grade processor. This thesis also shows that both clusters are not a viable option from an economic and environmental perspective. It is more beneficial to sell those computersfrom Syntronic and the University, for then to purchase new hardware.

Containers have been gaining popularity in recent years due to their ability to provide higher flexibility, higher reliability and dynamic scalability to enterprise software systems. In order to fully utilize containers, software developers aim to build their software using microservice architecture, meaning that instead of working on a single large codebase for the whole project, the software is split into smaller units. These microservices can be deployed in their own container instead of the traditional virtual machine setup where a server has to configured with all necessary dependencies. Moving away from the monolithic software architecture to containerized microservices is bound to bring performance penalties due to increased network calls between services and container overhead. The integration must therefor be carefully planned in order to fully utilize the container setup while minimizing the overhead. The purpose of this thesis project was to measure how much overhead can be expected due to containers in an enterprise environment. By using a combination of virtual machines and Docker containers, a microservice system was deployed with four different deployment strategies and the system’s performance was measured by analyzing request response times under various loads. The services were made to run on a single server and on multiple servers, with and without Docker. The performance measurements showed that the system performed worse in every case when Docker was used. Furthermore, the results showed that Docker can have significant negative impact on performance when there is a heavy load on the system. / Containers har blivit populärare under de senaste åren tack vare deras förmåga att ge högre flexibilitet, högre tillförlitlighet och dynamisk skalbarhet för företagsprogramvarusystem.  För att fullt ut kunna använda containers har programutvecklarna för avsikt att bygga sin programvara med hjälp av mikroservicearkitekturen, vilket innebär att programvaran delas upp i mindre enheter istället för att arbeta på en enda stor kodbas för hela projektet. Dessa mikroservices kan distribueras i sina egna containers istället för den traditionella virtuella maskininstallationen, där en server måste konfigureras med alla nödvändiga beroenden.  Att flytta sig från monolitisk mjukvaruarkitektur till containeriserade microservices kommer att få prestandaförsämringar på grund av ökade nätverksanrop mellan tjänster och container-overhead. Integrationen måste därför noggrant planeras för att fullt ut utnyttja containeruppsättningen och minimera overhead. Syftet med detta avhandlingsprojekt var att mäta hur mycket overhead kan förväntas på grund av containers i en företagsmiljö. Genom att använda en kombination av virtuella maskiner och Dockercontainers, implementerades ett microservices-system med fyra olika implementeringsstrategier och systemets prestanda mättes genom att analysera anropens svarstid under olika belastningar. Tjänsterna gjordes för att köras på en enda server och på flera servrar, med och utan Docker.  Prestandamätningarna visade att systemet var sämre i alla fall när Docker användes. Dessutom, visade resultaten att Docker kan ha signifikant negativ inverkan på prestanda när det är tung belastning på systemet.

Java is one of the more recent programming languages that in runtime free applications from manual memory management by using automatic Garbage collector (GC) threads. Although, at the cost of stop-the-world pauses that pauses the whole application. Since the initial GC algorithms new collectors has been developed to improve the performance of Java applications. Still, memory related errors occurs and developers struggle to pick the correct GC for each specific case. Since the concept of microservices were established the benefits of using it over a monolith system has been brought to attention but there are still problems to solve, some associated to garbage collectors. In this study the performance of garbage collectors are evaluated and compared in a microservice environment. The measurements were conducted in a Java SpringBoot application using Docker and a docker compose file to simulate a microservice environment. The application outputted log files that were parsed into reports which were used as a basis for the analysis. The tests were conducted both with and without a database connection. Final evaluations show that one GC does not fit all application environments. ZGC and Shenandoah GC was proven to perform very good regarding lowering latency, although not being able to handle the a microservice environment as good as CMS. ZGC were not able to handle the database connection tests at all while CMS performed unexpectedly well. Finally, the study enlightens the importance of balancing between memory and hardware usage when choosing what GC to use for each specific case.

Due to their tight isolation, low overhead, and efficient packaging of the execution environment, Docker containers have become a prominent solution for deploying modern applications. Consequently, a large amount of Docker images are created and this massive image dataset presents challenges to the registry and container storage infrastructure and so far has remained a largely unexplored area. Hence, there is a need of docker image characterization that can help optimize and improve the storage systems for containerized applications. Moreover, existing deduplication techniques significantly degrade the performance of registries, which will slow down the container startup time. Therefore, there is growing demand for high storage efficiency and high-performance registry storage systems. Last but not least, different storage systems can be integrated with containers as backend storage systems and provide persistent storage for containerized applications. So, it is important to analyze the performance of different backend storage systems and storage drivers and draw out the implications for container storage system design. These above observations and challenges motivate my dissertation. In this dissertation, we aim to improve the flexibility, performance, and efficiency of the storage systems for containerized applications. To this end, we focus on the following three important aspects: Docker images, Docker registry storage system, and Docker container storage drivers with their backend storage systems. Specifically, this dissertation adopts three steps: (1) analyzing the Docker image dataset; (2) deriving the design implications; (3) designing a new storage framework for Docker registries and propose different optimizations for container storage systems. In the first part of this dissertation (Chapter 3), we analyze over 167TB of uncompressed Docker Hub images, characterize them using multiple metrics and evaluate the potential of le level deduplication in Docker Hub. In the second part of this dissertation (Chapter 4), we conduct a comprehensive performance analysis of container storage systems based on the key insights from our image characterizations, and derive several design implications. In the third part of this dissertation (Chapter 5), we propose DupHunter, a new Docker registry architecture, which not only natively deduplicates layers for space savings but also reduces layer restore overhead. DupHunter supports several configurable deduplication modes, which provide different levels of storage efficiency, durability, and performance, to support a range of uses. In the fourth part of this dissertation (Chapter 6), we explore an innovative holistic approach, Chameleon, that employs data redundancy techniques such as replication and erasure-coding, coupled with endurance-aware write offloading, to mitigate wear level imbalance in distributed SSD-based storage systems. This high-performance fash cluster can be used for registries to speedup performance. / Doctor of Philosophy / The amount of Docker images stored in Docker registries is increasing rapidly and present challenges for the underlying storage infrastructures. Before we do any optimizations for the storage system, we should first analyze this big Docker image dataset. To this end, in this dissertation we perform the first large-scale characterization and redundancy analysis of the images and layers stored in the Docker Hub registry. Based on the findings, this dissertation presents a series of practical and efficient techniques, algorithms, optimizations to achieve high performance and flexibility, and space-efficient storage system for containerized applications. The experimental evaluation demonstrates the effectiveness of our optimizations and techniques to make storage systems flexible and space-efficacy.

Context. Light weight process virtualization has been used in the past e.g., Solaris zones, jails in Free BSD and Linux’s containers (LXC). But only since 2013 is there a kernel support for user namespace and process grouping control that make the use of lightweight virtualization interesting to create virtual environments comparable to virtual machines. Telecom providers have to handle the massive growth of information due to the growing number of customers and devices. Traditional databases are not designed to handle such massive data ballooning. NoSQL databases were developed for this purpose. Cassandra, with its high read and write throughputs, is a popular NoSQL database to handle this kind of data. Running the database using operating system virtualization or containerization would offer a significant performance gain when compared to that of virtual machines and also gives the benefits of migration, fast boot up and shut down times, lower latency and less use of physical resources of the servers. Objectives. This thesis aims to investigate the trade-off in performance while loading a Cassandra cluster in bare-metal and containerized environments. A detailed study of the effect of loading the cluster in each individual node in terms of Latency, CPU and Disk throughput will be analyzed. Methods. We implement the physical model of the Cassandra cluster based on realistic and commonly used scenarios or database analysis for our experiment. We generate different load cases on the cluster for bare-metal and Cassandra in docker scenarios and see the values of CPU utilization, Disk throughput and latency using standard tools like sar and iostat. Statistical analysis (Mean value analysis, higher moment analysis, and confidence intervals) are done on measurements on specific interfaces in order to increase the reliability of the results. Results.Experimental results show a quantitative analysis of measurements consisting Latency, CPU and Disk throughput while running a Cassandra cluster in Bare Metal and Container Environments.A statistical analysis summarizing the performance of Cassandra cluster is surveyed. Results.Experimental results show a quantitative analysis of measurements consisting Latency, CPU and Disk throughput while running a Cassandra cluster in Bare Metal and Container Environments.A statistical analysis summarizing the performance of Cassandra cluster is surveyed. Conclusions. With the detailed analysis, the resource utilization of the database was similar in both the bare-metal and container scenarios. Disk throughput is similar in the case of mixed load and containers have a slight overhead in the case of write loads for both the maximum load case and 66% of maximum load case. The latency values inside the container are slightly higher for all the cases. The mean value analysis and higher moment analysis helps us in doing a finer analysis of the results. The confidence intervals calculated show that there is a lot of variation in the disk performance which might be due to compactions happening randomly. Future work in the area can be done on compaction strategies.

Context Light weight process virtualization has been used in the past e.g., Solaris zones, jails in Free BSD and Linux’s containers (LXC). But only since 2013 is there a kernel support for user namespace and process grouping control that make the use of lightweight virtualization interesting to create virtual environments comparable to virtual machines. Telecom providers have to handle the massive growth of information due to the growing number of customers and devices. Traditional databases are not designed to handle such massive data ballooning. NoSQL databases were developed for this purpose. Cassandra, with its high read and write throughputs, is a popular NoSQL database to handle this kind of data. Running the database using operating system virtualization or containerization would offer a significant performance gain when compared to that of virtual machines and also gives the benefits of migration, fast boot up and shut down times, lower latency and less use of physical resources of the servers. Objectives This thesis aims to investigate the trade-off in performance while loading a Cassandra cluster in bare-metal and containerized environments. A detailed study of the effect of loading the cluster in each individual node in terms of Latency, CPU and Disk throughput will be analyzed. Method We implement the physical model of the Cassandra cluster based on realistic and commonly used scenarios or database analysis for our experiment. We generate different load cases on the cluster for Bare-Metal and Docker and see the values of CPU utilization, Disk throughput and latency using standard tools like sar and iostat. Statistical analysis (Mean value analysis, higher moment analysis and confidence intervals) are done on measurements on specific interfaces in order to show the reliability of the results. Results Experimental results show a quantitative analysis of measurements consisting Latency, CPU and Disk throughput while running a Cassandra cluster in Bare Metal and Container Environments. A statistical analysis summarizing the performance of Cassandra cluster while running single Cassandra is surveyed. Conclusions With the detailed analysis, the resource utilization of the database was similar in both the bare-metal and container scenarios. From the results the CPU utilization for the bare-metal servers is equivalent in the case of mixed, read and write loads. The latency values inside the container are slightly higher for all the cases. The mean value analysis and higher moment analysis helps us in doing a finer analysis of the results. The confidence intervals calculated show that there is a lot of variation in the disk performance which might be due to compactions happening randomly. Further work can be done by configuring the compaction strategies, memory, read and write rates.

Containers are being used widely as a base technology to pack applications and microservice architecture is gaining popularity to deploy large scale applications, with containers running different aspects of the application. Due to the presence of dynamic load on the service, a need to scale up or scale down compute resources to the containerized applications arises in order to maintain the performance of the application. Objectives To evaluate the impact of vertical scaling on the performance of a containerized application deployed with Docker container and Kubernetes that includes identification of the performance metrics that are mostly affected and hence characterize the eventual negative effect of vertical scaling. Method Literature study on kubernetes and docker containers followed by proposing a vertical scaling solution that can add or remove compute resources like cpu and memory to the containerized application. Results and Conclusions Latency and connect times were the analyzed performance metrics of the containerized application. From the obtained results, it was concluded that vertical scaling has no significant impact on the performance of a containerized application in terms of latency and connect times.