iExec Dev Letter #5: Docker Management — 18 Jul 2017

Published in

iExec

3 min readJul 18, 2017

In this bi-weekly level letter, we are happy to propose a new article that goes deeper in the technology behind the iExec Blockchain-based Distributed Cloud. This article presents the iExec Docker container management.

Introduction

In a previous article, we introduced the iExec paradigm of “provider’s sharing” and focused on virtual machine (VM) management as first use case. In this article we show how this paradigm applies to Docker container.

Containers aim to create and run virtual environments (VE) permitting to isolate application executions without the need to launch a separate operating system (OS). This last specificity -no need to add another OS layer- is the major difference from VM that greatly reduces overhead and footprint compared to other technologies. Your are invited to read this introduction article, if interested.

iExec provider’s sharing architecture, security and use case have already been detailed in this previous article. Today, we would like to detail how we manage such sharings; how we register, deploy, start and stop jobs.

Deployment

Traditionally, global computing platforms determine what to send and where: a job referring to an application with a Linux binary can only be sent to a resource running the Linux operating system. Our “Provider’s sharing” paradigm allows to declare components that are local to a node, and that will not transit over the network. This is useful when software components cannot be installed on the fly: it may be too heavy, too complicated, or even requires some privileged rights.

Our technology permits to reverse the deployment scheme: “provider’s sharing” are software components that are not supposed to be deployed and never transported.

Registration

Users must still be able to refer and use data and computations. To do so, the registration process remains the same: assets, shared or distributed, must be registered on scheduler side.

Application registration is done using the “xwsendapp” client tool, provided by the middleware. But registering shared one may be quite tricky and require several steps that could lead to errors or misunderstandings. To ease shared assets registration, the middleware offers ad hoc tools, one per class of software components:

“xwaddvbapp.sh” (aka “xtremweb add virtualbox application”)
“xwadddocker.sh” (aka “xtremweb add docker application”)

These tools register shared applications -Virtualbox and Docker- so that users can submit VM and containers, respectively. This shared applications can then be retrieved using “xwapps” client tool.

Usage

As soon as Docker is registered as a shared application, end users can submit and manage containers, using “xwsubmit”, “xwworks”, “xwresult” etc. client tools, as for any job type.