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.