Containers { lightweight, stand-alone software executables { are everywhere. Industries exploit container managers to orchestrate complex cloud infrastructures and researchers in academia use them to foster reproducibility of computational experiments. Among existing solutions, Docker is the de facto standard in the container industry. In this paper, we advocate the value of applying the Linked Data paradigm to the container ecosystem's building scripts, as it will allow adding additional knowledge, ease decentralized references, and foster interoperability. In particular we de ned a vocabulary Dockeronto that allows to semantically annotate Docker les.
Linux Containers 3 (e.g., lxc) are an operating system-level virtualization
technique that revolutionized the way software is packaged and distributed.
Companies exploit lxc to manage complex infrastructures, either internally, e.g., by
means of OpenStack4, or deployed on one of the available cloud solutions, e.g.,
Microsoft Azure5 and Amazon Web Services6. Among the available container
solutions, Docker 7 rapidly became the de facto standard and, more recently,
it started in uencing academic research, because it helps solving a number of
fundamental concerns that address reproducibility and repeatability of
experiments, as put forward by Boettiger [
Docker provides a set of concepts for the creation and initialization of containers: (i) a Docker Image is a software package containing a single application,
4 https://www.openstack.org/ 5 https://azure.microsoft.com/ 6 https://aws.amazon.com/ 7 https://www.docker.com/ 1 FROM ubuntu : l a t e s t 2 RUN apt get update apt get i n s t a l l y python python pip wget 3 RUN pip i n s t a l l Flask 4 ADD h e l l o . py /home/ h e l l o . py
Listing 1.1: A Docker le that installs a Python application on Ubuntu. (ii) a Docker le is the script that contains the instructions used to build the image, and (iii) a Docker Container is a runable instance of an image.
The build instructions are at the core of what functionality a container o ers. Although, this works in the Docker ecosystem, outside this ecosystem these instructions are not sharable and extendable in a machine-understandable manner. For example, (i) providing additional information about speci c instructions is only limited through the use of comments in the script, (ii) refering to speci c instructions outside of the complete context of its speci c script is not easily achievable, and (iii) machine-understandibility is limited as the build instructions are not self-descriptive. Therefore, we advocate the use of Linked Data principles8 to make these build instructions available. However, to apply these principles a vocabulary is required to semantically annotate these instructions.
Therefore, in previous e orts, Label-Schema.org9 and Smart Containers [
In this paper, we present Dockeronto10. It is a vocabulary that builds on the
idea of Smart Containers to semantically annotate Docker les. Furthermore, it
uses the Function Ontology (fno) [
In this section, we introduce Dockeronto via an example11. The Docker le of Listing 1.1 installs and runs a Python application on top of the latest available Ubuntu image and executes the following types of instructions: 1. FROM speci es the base image from which the current Docker le inherits all the functionalities, 2. RUN executes a command within the image (at build time), and 3. ADD copies a le from the host le systems into the image le system.
9 http://label-schema.org/rc1/ 10 https://github.com/riccardotommasini/dockeronto 11 The documentation and more elaborate examples are available at https://github. com/riccardotommasini/dockeronto. 1 do : from a fno : Function , do : I n s t r u c t i o n ; 2 fno : e x p e c t s ( do : imageInputParam ) ; 3 fno : r e t u r n s ( do : imageOutputParam ) . 4 5 do : run a fno : Function , do : I n s t r u c t i o n ; 6 fno : e x p e c t s ( do : imageInputParam do : runInputCommand ) ; 7 fno : r e t u r n s ( do : imageOutputParam ) . 8 9 do : runInputCommand a fno : Parameter ; 10 fno : p r e d i c a t e do : runCmd ; fno : type do : Command . 11 do : imageInputParam a fno : Parameter ; 12 fno : p r e d i c a t e do : imageInput ; fno : type do : Image . 13 do : imageOutputParam a fno : Output ; 14 fno : p r e d i c a t e do : imageOutput ; fno : type do : Image .
Listing 1.2: from and run instruction in Dockeronto ex : d o c k e r f i l e 1 a do : D o c k e r f i l e ;
do : c o n t a i n s ( ex : i n s 1 ex : i n s 2 ex : i n s 3 ex : i n s 4 ) ;
Listing 1.3: rdf representation of a Docker le with Dockeronto.
We represent these instructions using the Function Ontology (fno) [
Listing 1.3 shows the Turtle serialization of the example Docker le using Dockeronto. This representation is queryable yet still executable, because we use an rdf:List to retain the ordering of the Docker le instructions since it in uences the output Docker Image. We consider intermediate images, which are generated during build time, but since they can be inferred we did not describe them explicitly. Last but not least, we added additional information to the instructions, such as labels, comments, and their creators.
Outside the context of this Docker le it is also possible to refer to speci c instructions without the need to know the complete Docker le or even the fact ex : r i c c a r d o dbo : c r e a t e d ex : i n s 2 , ex : i n s 4 ; ex : r e v i e w I n s 3 a schema : Review ; schema : itemReviewed ex : i n s 3 ; schema : c o n t r i b u t o r ex : r i c c a r d o .
Listing 1.4: Knowledge about speci c instructions outside the Docker le context. that the instructions are related to Docker . For example, in Listing 1.4 additional knowledge about who created the instructions is provided, together with a review of one speci c instruction.
The development of Dockeronto is an important step to improve the use of Docker build instructions outside the context of a Docker le. This in turn allows to work towards applying the Linked Data principles. The extensibility and shareability is improved, and the build instructions are now self-descriptive. As was shown in the example, (i) additional knowledge can be easily added to the instructions, (ii) (references to) instructions can be shared outside the context of a Docker le, and (iii) the use of semantic annotations via Dockeronto allows for self-descriptive instructions that are understandable even outside of the Docker ecosystem.
For the future, we envision an Linked Container ecosystem, where semantic
technologies are used to empower development work ows, track provenance and
develop semantic microservices [