iEx.ec logo iEx.ec logo
iEx.ec logo iEx.ec logo
iEx.ec logo
iexec joins the Enterprise Ethereum Alliance!

Partnership announcement: Signals on top of iExec V1

Read More
Partnership announcement: Signals on top of iExec V1

Partnership announcement: Signals on top of iExec V1

Read More
, ,

iExec Development Letter #5

iExec Development Letter #5

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.

Conclusion

This article goes deeper in the iExec “provider’s sharing” paradigm and shows the management of container over a decentralized cloud.

Media

You are kindly invited to:

Resources

Source : https://medium.com/iex-ec/iexec-devel-letter-5-e2647a195007

About the author

Team iExec

Select Language