De Meester, Ben

Della Valle, E

Heyvaert, Pieter

Mannens, Erik

Tommasini, R

Verborgh, Ruben

Ghent University Academic Bibliography

Representing Dockerfiles in RDFRiccardo Tommasini1, Ben De Meester2, Pieter Heyvaert2, Ruben Verborgh2,Erik Mannens2, Emanuele Della Valle11 Politecnico di Milano, DEIB, Milan, Italy{riccardo.tommasini,emanuele.dellavalle}@polimi.it2 Ghent University – imec – IDLab,Department of Electronics and Information Systems, Ghent, Belgium{ben.demeester,pheyvaer.heyvaert,ruben.verborgh,erik.mannens}@ugent.beAbstract. Containers – lightweight, stand-alone software executables –are everywhere. Industries exploit container managers to orchestratecomplex cloud infrastructures and researchers in academia use them tofoster reproducibility of computational experiments. Among existing so-lutions, Docker is the de facto standard in the container industry. In thispaper, we advocate the value of applying the Linked Data paradigm tothe container ecosystem’s building scripts, as it will allow adding ad-ditional knowledge, ease decentralized references, and foster interoper-ability. In particular we defined a vocabulary Dockeronto that allows tosemantically annotate Dockerfiles.Keywords: container, Docker, Linked Data, vocabulary1 IntroductionLinux Containers3 (e.g., lxc) are an operating system-level virtualization tech-nique that revolutionized the way software is packaged and distributed. Com-panies exploit lxc to manage complex infrastructures, either internally, e.g., bymeans of OpenStack4, or deployed on one of the available cloud solutions, e.g.,Microsoft Azure5 and Amazon Web Services6. Among the available containersolutions, Docker7 rapidly became the de facto standard and, more recently,it started influencing academic research, because it helps solving a number offundamental concerns that address reproducibility and repeatability of experi-ments, as put forward by Boettiger [2]. Docker guarantees (i) modular reuse ofsoftware packages, (ii) a portable environment, (iii) public sharing by means ofweb repositories (Docker Registry), and (iv) versioning.Docker provides a set of concepts for the creation and initialization of con-tainers: (i) a Docker Image is a software package containing a single application,3 https://linuxcontainers.org/4 https://www.openstack.org/5 https://azure.microsoft.com/6 https://aws.amazon.com/7 https://www.docker.com/2 R. Tommasini et al.1 FROM ubuntu : l a t e s t2 RUN apt−get update apt−get i n s t a l l −y python python−pip wget3 RUN pip i n s t a l l Flask4 ADD h e l l o . py /home/ h e l l o . pyListing 1.1: A Dockerfile that installs a Python application on Ubuntu.(ii) a Dockerfile is the script that contains the instructions used to build theimage, and (iii) a Docker Container is a runable instance of an image.The build instructions are at the core of what functionality a container offers.Although, this works in the Docker ecosystem, outside this ecosystem these in-structions are not sharable and extendable in a machine-understandable manner.For example, (i) providing additional information about specific instructions isonly limited through the use of comments in the script, (ii) refering to specificinstructions outside of the complete context of its specific script is not easilyachievable, and (iii) machine-understandibility is limited as the build instruc-tions are not self-descriptive. Therefore, we advocate the use of Linked Dataprinciples8 to make these build instructions available. However, to apply theseprinciples a vocabulary is required to semantically annotate these instructions.Therefore, in previous efforts, Label-Schema.org9 and Smart Containers [4]were introduced. However, they do not consider the build instructions. Label-Schema.org proposes a set of build-time labels for containers in the form oforg.label-schema.[key]=[value] that can be used to add metadata to thebuilt Docker Image. Smart Containers model Docker concepts using prov-o [1],focusing on the environment where computational experiments are executed, butthey remain high level.In this paper, we present Dockeronto10. It is a vocabulary that builds on theidea of Smart Containers to semantically annotate Dockerfiles. Furthermore, ituses the Function Ontology (fno) [5] to represent a Dockerfile’s instructions.2 Dockeronto in a NutshellIn this section, we introduce Dockeronto via an example11. The Dockerfile ofListing 1.1 installs and runs a Python application on top of the latest availableUbuntu image and executes the following types of instructions:1. FROM specifies the base image from which the current Dockerfile inheritsall the functionalities,2. RUN executes a command within the image (at build time), and3. ADD copies a file from the host file systems into the image file system.8 https://www.w3.org/DesignIssues/LinkedData.html9 http://label-schema.org/rc1/10 https://github.com/riccardotommasini/dockeronto11 The documentation and more elaborate examples are available at https://github.com/riccardotommasini/dockeronto.Representing Dockerfiles in RDF 31 do : from a fno : Function , do : I n s t r u c t i o n ;2 fno : expect s ( do : imageInputParam ) ;3 fno : r e tu rns ( do : imageOutputParam ) .45 do : run a fno : Function , do : I n s t r u c t i o n ;6 fno : expect s ( do : imageInputParam do : runInputCommand ) ;7 fno : r e tu rns ( do : imageOutputParam ) .89 do : runInputCommand a fno : Parameter ;10 fno : p r ed i c a t e do : runCmd ; fno : type do :Command .11 do : imageInputParam a fno : Parameter ;12 fno : p r ed i c a t e do : imageInput ; fno : type do : Image .13 do : imageOutputParam a fno : Output ;14 fno : p r ed i c a t e do : imageOutput ; fno : type do : Image .Listing 1.2: from and run instruction in Dockerontoex : d o c k e r f i l e 1 a do : Dock e r f i l e ;do : conta in s ( ex : in s1 ex : in s2 ex : i n s3 ex : in s4 ) ;ex : i n s1 fno : execute s do : from ; do : fromValue <ubuntu : l a t e s t >;r d f s : l a b e l ” I n s t a l l l a t e s t Ubuntu ” ;r d f s : comment ”We always want to have the l a t e s t Ubuntu updates . ” ;dcterms : c r e a t o r ex : r i c c a rdo .ex : in s2 fno : execute s do : run ; do : runCmd ”apt−get update && . . . ” .r d f s : l a b e l ” I n s t a l l nece s sa ry dependenc ies . ”ex : in s3 fno : execute s do : run ; do : runCmd ”pip i n s t a l l Flask ” .dcterms : c r e a t o r ex : ben .ex : in s4 fno : execute s do : add ; do : s r c ” h e l l o . py ” ; do : dst ”/home/ h e l l o . py ” ;r d f s : comment ”This s c r i p t shows h e l l o world . ” .Listing 1.3: rdf representation of a Dockerfile with Dockeronto.We represent these instructions using the Function Ontology (fno) [5]. List-ing 1.2 shows the fno descriptions for FROM and RUN. For example, the RUNinstruction expects an image and a command as input parameters (line 6):the image is the intermediate image from the previous instruction, and the com-mand is, e.g., apt-get update && apt-get install -y python python-pipwget (Listing 1.1, line 2). Note that the modeling of the individual run commandsis not in scope of this work, as this is not specific to the Dockerfile syntax. Forthe time being, they are described as string values. The instruction’s output is anew image (line 7), either to be used for the next instruction, or as the resultingimage of the Dockerfile.Listing 1.3 shows the Turtle serialization of the example Dockerfile usingDockeronto. This representation is queryable yet still executable, because weuse an rdf:List to retain the ordering of the Dockerfile instructions since itinfluences the output Docker Image. We consider intermediate images, whichare generated during build time, but since they can be inferred we did notdescribe them explicitly. Last but not least, we added additional information tothe instructions, such as labels, comments, and their creators.Outside the context of this Dockerfile it is also possible to refer to specificinstructions without the need to know the complete Dockerfile or even the fact4 R. Tommasini et al.ex : r i c c a rdo dbo : c reated ex : ins2 , ex : i n s4 ;ex : r ev i ewIns3 a schema : Review ;schema : itemReviewed ex : in s3 ;schema : con t r i bu to r ex : r i c c a rdo .Listing 1.4: Knowledge about specific instructions outside the Dockerfile context.that the instructions are related to Docker . For example, in Listing 1.4 additionalknowledge about who created the instructions is provided, together with a reviewof one specific instruction.3 ConclusionThe development of Dockeronto is an important step to improve the use of Dockerbuild instructions outside the context of a Dockerfile. This in turn allows to worktowards applying the Linked Data principles. The extensibility and shareabilityis improved, and the build instructions are now self-descriptive. As was shownin the example, (i) additional knowledge can be easily added to the instructions,(ii) (references to) instructions can be shared outside the context of a Dockerfile,and (iii) the use of semantic annotations via Dockeronto allows for self-descriptiveinstructions that are understandable even outside of the Docker ecosystem.For the future, we envision an Linked Container ecosystem, where semantictechnologies are used to empower development workflows, track provenance anddevelop semantic microservices [3].References1. Belhajjame, K., Cheney, J., Corsar, D., Garijo, D., Soiland-Reyes, S., Zednik, S.,Zhao, J.: PROV-O: The PROV Ontology. Recommendation, World Wide Web Con-sortium (W3C) (Apr 2013), https://www.w3.org/TR/prov-o/, accessed June 14th,20172. Boettiger, C.: An introduction to docker for reproducible research. Operating Sys-tems Review 49(1), 71–79 (2015), http://doi.acm.org/10.1145/2723872.27238823. Ferna´ndez-Villamor, J.I., Iglesias, C.A., Garijo, M.: Microservices - lightweight ser-vice descriptions for REST architectural style. In: ICAART 2010 - Proceedings ofthe International Conference on Agents and Artificial Intelligence, Volume 1 - Ar-tificial Intelligence, Valencia, Spain, January 22-24, 2010. pp. 576–579 (2010)4. Huo, D., Nabrzyski, J., Vardeman, C.: Smart container: an ontology towards con-ceptualizing docker. In: Proceedings of the ISWC 2015 Posters & DemonstrationsTrack, Bethlehem, PA, USA, October 11, 2015. (2015)5. Meester, B.D., Dimou, A., Verborgh, R., Mannens, E.: An ontology to semanticallydeclare and describe functions. In: The Semantic Web - ESWC 2016 Satellite Events,Heraklion, Crete, Greece, May 29 - June 2, 2016, Revised Selected Papers. pp. 46–49(2016), https://doi.org/10.1007/978-3-319-47602-5_10

Representing dockerfiles in RDF

https://biblio.ugent.be/publication/8540841/file/8540843.pdf

Representing dockerfiles in RDF

Abstract

Similar works

Full text

Available Versions

Ghent University Academic Bibliography