Docker daemon optimizations

In a recently published paper, Arif Ahmed and Guillaume Pierre [1] face the prob- lem of slow Docker container deployment in the context of Fog computing environ-

44 CHAPTER 2. TECHNICAL BACKGROUND

ments. The article focuses on Docker daemons running on commodity machines such as Raspberry Pis, since they are likely to act as Fog nodes in next-generation infrastructures. Such low-end platforms are usually characterized by limited storage capacity, which can entail the need for frequent pulls, and low I/O performances, which can make the pull process remarkably slow. The usage of a standard Docker platform on Fog nodes can therefore induce large delays that are unacceptable for real-time applications. This paper aims to address such issue.

The authors perform a monitoring of different kinds of activities performed by the Docker daemon during the pull process in order look for the causes of such bad performances. The paper identifies three sources of inefficiency and proposes as many optimizations to address them.

1. The parallel download of layers, which is the default behavior of a Docker daemon, threatens to slow down the whole pull process whenever the network bandwidth is constrained. Since the download of the first layer takes longer to complete, the moment in which the extraction process can start is postponed as well. The paper proposes to replace the concurrent download of layers with a sequential procedure. Results show that the more the bandwidth is reduced, the more this optimization gets effective.

2. Docker layers are shipped over the network in the form of compressed archives and then locally extracted by the daemon. The process is carried out by means of a single-threaded decompression function. It turns out that this choice does not exploit at best the computational power of most ma- chines, given that even low-end computers, such as Raspberry Pis, often of- fer a multi-core architecture. For this reason, Ahmed proposes the usage of an alternative multi-threaded implementation of the standard decompression function, which is able to increase the CPU utilization and therefore reduce the overall deployment time.

3. A third observed inefficiency is the under-utilization of hardware re- sources. Indeed, the standard deployment process begins with a network- intensive phase, during which CPU and disk are not used; then, it alternates between periods of high CPU usage (decompression of the archives) and high disk usage (copy of the extracted files). However, there is no reason to keep the sequential order of download, extraction and decompression. For this rea-

2.5. RELATED WORK 45

son, the paper proposes to arrange the three activities in separate threads, each of which pumps the resulting data to the next through pipelining. The simultaneous execution of the operations better exploits hardware resources of the host machine, thus significantly reducing their total duration.

Experimental results confirm the validity of the approach and of the proposed so- lution. The suggested optimizations are able to achieve a significant speedup of the deployment process, whose time is reduced by 60% to 70%, depending on the image that is taken into account.

All things considered, the overall objective of Ahmed’s work is substantially similar to the one we aspire to; also, both works share the same constraints deriving from the adoption of the Fog computing paradigm. Our purpose is to continue the work on the same direction. In this thesis we try to find new ways to optimize the deployment of containers in order to deliver a tool which is able to meet the requirements of novel applications running on a Fog computing infrastructure.

Chapter 3

System design

In this chapter we are going to describe the structure and functioning of the solution implemented over the course of this thesis. The work is set in the context of Fog computing, a novel paradigm that brings storage and computing resources close to the user in order to face the growth in the number of connected devices and to meet the requirements of latency-sensitive applications. In a Fog architecture, Docker seems to be a valuable tool to gain all the advantages of deploying virtualized services without compromising the performance of the system. However, the considerable size of Docker images threatens to slow down the deployment of containers. This is a clear obstacle for a widespread adoption of the technology in Fog computing, given that fast deployment of services across different nodes is essential to follow the user along his movements. Moreover, the issue of slow deployment is particularly relevant in this context, where the usage of resource-constrained commodity machines and slow public Internet connections is likely to exacerbate the problem.

The objective of this work is to devise a system that is able to substantially reduce the time spent during the deployment of a container. As said in Section 2.5.3, researchers have shown that in spite of the large size of Docker images, only a fraction of the data (6.4% in average, to be precise) turns out to be actually useful. The key idea of this work is to improve the performances of the pull by deploying those essential files first, letting the container start its execution and the proceed with the download of the rest at run time. We have seen that Docker images are not treated as unitary objects; on the contrary, their content is distributed across different layers. For this reason, it seems reasonable to put the essential files into

48 CHAPTER 3. SYSTEM DESIGN

an additional layer of the image, which will be called “base layer”. This is the component that can be downloaded in advance with respect to the rest.

In order to realize a concrete implementation on the basis of our idea, the following research questions must be addressed:

• how to identify the essential files needed for the execution of a container? • what to put inside the new base layer?

• how to change the Docker source code so that its behavior mirrors our expec- tations?

• what happens if the container tries to access a file that is not present because its download has not been completed yet?

The following sections of the chapter organize the exposition of the system design by addressing all of the abovementioned matters.

3.1

Profiling the container execution

It has been shown that Docker containers make use of just a limited part of their file-system content during the initial phase of execution. Harter et al. [13], for example, have carried out an extensive study of the matter. They consider a highly- representative subset of Docker images by choosing 57 samples from the public Docker Hub repository; Linux distributions, databases, programming languages, web servers and frameworks are just some of the involved categories. For each image, a block-level tracing tool is employed in order to measure the exact number of bytes read by the containerized process from the file system. Results indicate that, on average, only 6.4% of the data is accessed. In particular, the highest absolute waste in terms of unused files occurs when dealing with languages and web frameworks; the highest relative waste, instead, is within Linux distribution containers.

The first challenge that has to be addressed during the design of our solution is understanding which files are effectively accessed by a container. There are multiple ways to produce a reliable list of the files that are accessed by a process during exe- cution. The following subsections are going to discuss the approaches that have been

3.1. PROFILING THE CONTAINER EXECUTION 49

attempted until the one that has been finally chosen; furthermore, some additional possibilities are mentioned as well.