iEx.ec application deployment

Published in

iExec

3 min readFeb 21, 2017

Following the EDCON conference, we continue our series of articles to introduce the technology behind the iEx.ec Blockchain-based Distributed Cloud. The XtremWeb-HEP being introduced in previous posts, this article presents the Application Deployment.

Introduction

As described in a previous article, iExec belongs to the well known paradigm of global computing platforms that implement a three tier architecture where a set of centralized services are instantiated and reachable via an Internet connection by decentralized services: the “client” and the “worker”.

The client, on one hand, offers the interface that permits users to interact with the platform; using the client, one can easily register applications as shown in the next section. The worker, on another hand, aggregates volunteer IT resources to run applications that process end user data.

The following figure shows the different applications available in iEx.ec from http://xw.iex.ec/dashboard/ where we can see the iEx.ec platform is very versatile and suited to multiple types of applications.

iEx.ec allows to execute very large parallel scientific applications at the fraction of the cost of a traditional supercomputer.

Communication

iEx.ec distributes applications to volunteer resources on demand using communication initiated by decentralized services only because of firewalls, roaming etc.

Applications are securely stored on server side. They are distributed according to a two phases process. They are sent from the client to the scheduler, and then from the scheduler to the workers. Application distribution is under security control as described in our “security” article.

Application registration

Using the decentralized client, a user may register their own application. Doing so consists of sending expected metadata, as well as providing binary, package, library or any expected resource with which to run the application. These application resources may be sent to an iExec scheduler or described by an endpoint (i.e: a URI) in order to retrieve these resources. It is the user’s responsibility to ensure application resources are accessible. As described in the “security” article, registration follows the security rules.

Using the client, an application can be registered as follows:

$> xwsendapp [name] DEPLOYABLE ARCH OS <URI | FILE>

Where:

xwsendapp: is the iEx.ec client
DEPLOYABLE: is a reserved verb that authorizes to send the binary to workers.
name: the application name (must be unique)
ARCH: is the architecture for this application (e.g: x86_64)
OS: is this operating system for this application (e.g: Linux)
URI | FILE: is the application binary or a URI link pointing to the application binary. Data may be automatically registered for any local file. Data registration will be the subject of a forthcoming article.

The iEx.ec client accepts a lot more options we won’t detail here for simplicity (library, different architectures, OSes etc.). Please refer to the documentation for more details.

Example

Let’s take a very simple example: we want to insert the “ls” application with the Linux binary, for X86_64 architecture.

Using the client, an application can be registered as follows:

$> xwsendapp ls DEPLOYABLE X86_64 linux /bin/ls

Retrieve applications

Using the decentralized client, a user may retrieve an application. As described in the “security” article, retrieval follows the security rules.

Using the client, an application can be retrieved as follows:

$> xwapps
UID=’3fb96415-be5d-4300–8ae5–87af64733826', NAME=’ls’

Remove application

Using the decentralized client, a user may remove registered applications. As described in the “security” article, removal follows the security rules.

Using the client, an application can be retrieved as follows:

$> xwrm UID|URI

Where:

xwrm: is the iEx.ec client
UID | URI : is the application identifier

Application deployment

Using a decentralized worker, an application is automatically deployed as soon as an execution task has been submitted by the user. The worker retrieves the metadata and all resources described in the metadata (binary, package, library etc.). If any metadata or file is not reachable, the worker cowardly refuses the application. As described in the “security” article, deployment follows the security rules.