Posts on enten.fr

Les prémices d'un nouveau framework orienté micro-services

Sat, 04 Jun 2016 00:00:00 +0000

Introduction

Chaque année, les étudiants de nombreux cursus informatiques se préparent à intégrer des deux pieds le monde de l’entreprise. Jeune ingénieur en poste depuis quelques mois, je souhaite partager mon expérience d’insertion professionnelle.

A travers une série d’articles, je tenterai de présenter le contexte de travail qui m’a conduit à concevoir et à implémenter un framework pour encadrer et optimiser le développement logiciel.

Pourquoi un nouveau framework ?

Je pense que pour chaque besoin il existe une ou plusieurs solutions. Je ne suis pas de ceux qui aiment ré-inventer la roue. Au contraire. Seulement, mon contexte de travail actuel m’a amené à penser que parfois il n’existe pas de solution qui répond parfaitement à nos besoins.

J’évolue dans une PME où le service informatique est composé d’un responsable matériel (the sysadmin) et de deux développeurs (dont votre serviteur).

Aujourd’hui l’entreprise à besoin de concevoir ses systèmes en micro-services ré-utilisables. De nombreuses solutions dans différents languages existent et permettent de mettre rapidement en place ce type de plateformes.

J’ai commencé mon travail en m’appuyant sur un framework existant. J’ai pu rapidement mettre en place deux services :

Service A : gestion d’utilisateurs (création de nouveaux comptes et de jetons d’authentification)
Service B : gestion de documents (création, lecture et modification)

[Server A]                             :  [Server B]                
                                       :                            
                 Service A             :                   Service B
                     |                 :                       |    
    GET /profile/123 |                 :      GET /doc/321     |    
    ---------------->|                 :      ---------------->|    
    < - - - - - - - -|                 :      < - - - - - - - -|    
      profile(json)  |                 :        doc(json)      |    
                     |                 :                       |

Ainsi, ces services peuvent être ré-utilisés à travers différents projets. Le backend était presque complet. Il ne manquait qu’à écrire un troisième service : le service C qui conjugue et enrichi les services A et B pour proposer un service permettant de gérer des utilisateurs ayant des documents privés (sans lien direct entre un utilisateur et ses documents).

C’est là où se sont présentés différents problèmes. Des problèmes qui m’ont poussés à changer de framework. Mais les problèmes étaient toujours là.

Un problème de conception

A ce stade, nous avons déjà 2 composants implémentés : Services A (gestion des utilisateurs) et Service B (gestion de documents).

Le composant Service C doit utiliser les services A et B. Il nous faut écrire 2 autres composants qui sont les clients permettant d’utiliser les services A et B : ce sont eux qui savent comment dialoguer avec les services (appeler les bonnes routes avec les bons paramètres).

Nous appelerons ces composants Service A Client et Service B Client. Ils pourront être réutilisés par d’autres composants qui souhaiteraient s’interfacer avec un de ces services (A ou B).

[Server C]                               :  [Server A]               
                                         :                           
                 Service A Client        :         Service A         
                         |               :             |             
                         |               :             |             
    cltA.getProfile(123) |               :             |             
    -------------------->|      GET /profile/123       |             
                         |---------------------------->|             
                         |< - - - - - - - - - - - - - -|             
    < - - - - - - - - - -|       profile(json)         |             
        profile(json)    |               :             |             
                         |               :             |             
                                         :                           
                                         :...........................
                                         :                           
                                         : [Server B]                
                                         :                           
                 Service B Client        :         Service B         
                         |               :             |             
                         |               :             |             
    cltB.getDoc(321)     |               :             |             
    -------------------->|        GET /doc/321         |             
                         |---------------------------->|             
                         |< - - - - - - - - - - - - - -|             
    < - - - - - - - - - -|         doc(json)           |             
          doc(json)      |               :             |             
                         |               :             |

Nous pouvons maintenant écrire le service C. Et c’est là où émerge la principale problématique.

Si les services A et B évoluent, il faut mettre à jour les composants clients respectifs. Il en va de même pour un éventuel futur composant Service C Client.

Dans le cas du service C, lorsqu’un utilisateur souhaite récupérer son profil, le service C utilise le composant client du service utilisateur (Service A Client) pour contacter le service distant (Service A) et retransmet la réponse à l’utilisateur.

[Server C]                                                     : [Server A]    
                                                               :               
                     Service C          Service A Client       :    Service A
                         |                     |               :        |      
 ( )    GET /profile/123 |                     |               :        |      
--|--   ---------------->| clt.getProfile(123) |               :        |      
 / \                     |-------------------->|    GET /profile/123    |      
User                     |                     |----------------------->|      
                         |                     |< - - - - - - - - - - - |      
                         |< - - - - - - - - - -|     profile(json)      |      
        <- - - - - - - - |    profile(json)    |               :        |      
          profile(json)  |                     |               :        |

Si la route du service A pour afficher le profile change, il faudra modifier le client (et éventuellement le service C si on veut être cohérent avec les routes du service A) pour pointer vers la nouvelle route.

Et c’est là où la majorité des frameworks montrent leurs limites : ils sont orientés serveur et n’apportent aucune aide pour s’interfacer avec les services écris. Faire évoluer un service devient alors pénible puisqu’il faut faire évoluer ses dépendances.

La solution idéale

Nous avons constaté que les frameworks de micro-services sont orientés serveur : ils permettent d’écrire des services mais ne proposent pas de solution rapide pour s’interfacer avec ces derniers.

La solution idéale doit permettre aux développeurs :

de se concentrer sur le code métier des services ;
et de fournir des moyens simples pour les utiliser aussi bien du côté serveur que du côté client.

Nous devrions pouvoir écrire un service de la manière suivante :

// HelloService.js

class HelloService {
  sayHello(inputs) {
    return 'hello ' + (inputs.who || 'world');
  }
}

module.exports = HelloService;

Ce service ne propose qu’une seule route GET /sayHello qui retourne un message selon les paramètres d’appels :

L’appel GET /sayHello affiche Hello world ;
L’appel GET /sayHello?who=jd affiche Hello jd.

Notre framework doit être capable de charger des services et de proposer de les exécuter en mode serveur ou en mode client.

// app.js
var NotreSuperFramework = require('notre-super-framework');
var HelloService = require('./HelloService');

var app = new NotreSuperFramework();

// charge le service HelloService sur la route /hello
app.use('/hello', HelloService);

module.exports = app;

// server.js
var app = require('./app');

// lance le serveur de services http://localhost:1337
app.listen(1337);

// test.js
var app = require('./app');

// créer un client vers le serveur de services http://localhost:1337
var api = app.client(1337);

// appel la route GET http://localhost:1337/hello/sayHello?who=jd
api.HelloService.sayHello({ who: 'jd' }, function (err, res) {
  if (err) {
    console.error(err);
    return;
  }

  // affiche "Hello jd"
  console.log(res.body);
});

Nul besoin d’être un développeur NodeJS confirmé pour comprendre la simplicité d’utilisation recherchée : c’est le framework qui s’occupe de générer le serveur ou le client.

On peut même imaginer un troisième mode qui permettrait de monter automatiquement les routes de services distants.

// app-b.js
var NotreSuperFramework = require('notre-super-framework');
var appA = require('./app');

var appB = new NotreSuperFramework();

// monte les services du serveur distant http://localhost:1337
appB.use('/', appA.remote(1337));

module.exports = appB;

// server.js
var appB = require('./app-b');

// lance le serveur http://localhost:1338
appB.listen(1338);

Une requête adressée à la route GET http://localhost:1338/hello/sayHello est relayée via le client vers la route GET http://localhost:1337/hello/sayHello et la réponse retransmise à l’utilisateur à l’origine de la requête.

Conclusion

N’ayant pas trouvé de framework permettant d’écrire et d’interfacer simplement des micro-services, je vais tenter de développer une idée de framework de micro-services universels (pouvant être utiliser dans différents modes dynamiquement).

Dans les prochains articles, nous allons développer les spécifications de notre solution idéale.

Android 5.1.1 x86_64

Mon, 15 Jun 2015 00:00:00 +0000

Introduction

Le projet android-x86 est un fork d’Android Open Source Project (AOSP) permettant d’installer Android sur PC (la compilation de ses sources produit une image CD bootable). Ce fork fût longtemps la seule solution pour compiler simplement Android pour plateforme x86.

Avec Android 5 Lollipop, Google a ouvert la voix à la compilation d’AOSP pour architectures 64-bits (ARM et x86). Cette possibilité ne rend pas le fork android-x86 obsolète pour autant. En effet la compilation de ces 2 projets ne produit pas le même résultat (une unique image iso pour android-x86 contre plusieurs images de systèmes de fichiers pour AOSP).

Nous discuterons dans cette article uniquement d’AOSP et de la manière de compiler ses sources pour des architectures 64-bits.

Contexte

Peu de temps après notre expérience de virtualisation d’Android 5 Lollipop avec Qemu, nous avons constaté que des images 64-bits précompilées d’Android étaient proposées en téléchargement par le SDK Manager.

!TODO Screen SDK images/fig/sdk-manager-images-64bits.png

Le tableau ci-dessous montre les différentes images 64-bits (par version d’Android) actuellement disponibles en téléchargement via le SDK Manager.

Codename	Version	API	Images
M	5.1.1	22 MNC Preview	ARM 64 v8a System Image
M	5.1.1	22 MNC Preview	Intel x86 Atom_64 System Image
Lollipop	5.1.1	22	Intel x86 Atom_64 System Image
Lollipop	5.1.1	22	Goole APIs Intel x86 Atom-64 System Image
Lollipop	5.0.1	21	Intel x86 Atom_64 System Image
Lollipop	5.0.1	21	Goole APIs Intel x86 Atom-64 System Image

Android M est semble-t-il la première version proposant une image ARM 64-bits précompilée (ce qui évite de prendre des heures à compiler soit-même AOSP pour ARM 64-bits).

Nous sommes maintenant certains qu’il est possible de compiler AOSP pour des architectures x86_64, et ce depuis la version 5.0.1 d’Android.

Expérience

Dans cette section, nous allons compiler Android pour architecture x86_64 à partir des sources du projet officiel (AOSP). Les images résultantes de la compilation pourront être utilisées directement avec Qemu ou l’outil emulator du SDK. Nous souhaitons également recompiler un kernel Linux compatible.

L’expérience semble simple. Toute fois, des problèmes de compatibilité de versions peuvent rendrent l’expérience moins évidente.

Prérequis matériel

Processeur amd64
RAM ≥ 4 Go
Espace disque ≥ 50 Go
Système d’exploitation GNU/Linux récent

Versions

Voici les différentes versions des composants utilisés pour compiler AOSP x86_64.

Système d’exploitation : Debian GNU/Linux 8 (jessie) 64-bits
Java Development Kit : Oracle JDK 7 (1.7.0_79-b15)
Android Open Source Project : android-5.1.1_r4
Toolchain : x86_64-linux-android-4.8 (branche android-5.1.1_r4)
Kernel : android-goldfish-3.10 commit 43dbfdb838

WARNING Pour pouvoir compiler un kernel Linux compatible avec les images résultantes de la compilation d’AOSP branche android-5.1.1_r4, il est important d’utiliser la branche android-goldfish-3.10 du projet kernel/goldfish à son état du 16 sept. 2014 (commit 43dbfdb838).

Préparer l’environnement d’assemblage

JDK 7

Installer un JDK 7 (Java Open JDK 7 par exemple).

$ sudo apt-get install openjdk-7-jdk –y

Vérifier qu’il est bien utilisé par défaut.

$ sudo update-alternatives --config java
$ sudo update-alternatives --config javac

Packages requis

Installer les packages nécessaires pour compiler AOSP.

$ dpkg --add-architecture i386
$ sudo apt-get install bison g++-multilib git gperf libxml2-utils make zlib1g-dev:i386 zip

Configurer une identité utilisateur sous Git

$ git config --global user.name "John Doe"
$ git config --global user.email "jd@android.com"

Récupérer l’utilitaire repo de Google et le charger dans le PATH courrant.

$ mkdir ~/bin
$ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
$ chmod a+x ~/bin/repo
$ PATH=~/bin:$PATH

Référence : Setting up a Linux build environment

Sources d’AOSP

Nous allons maintenant récupérer les sources officielles d’Android.

Pour cela il suffit de créer un répertoire, de l’initialiser avec l’outil repo et la branche souhaitée (android-5.1.1_r4) puis de lancer le téchargement des sources.

$ mkdir ~/aosp
$ cd ~/aosp
$ repo init -u https://android.googlesource.com/platform/manifest -b android-5.1.1_r4
$ repo sync

Attention La synchronisation des sources d’AOSP dure plusieurs heures (à la faveur d’une connexion Internet grand public).

Compiler AOSP

Une fois les sources d’AOSP récupérées, quelques lignes de commandes suffisent à charger la configuration d’assemblage aosp_x86_64-eng pour produire des images x86_64 d’Android.

$ cd ~/aosp
$ source build/envsetup.sh
$ lunch aosp_x86_64-eng

Avant de lancer la compilation, vérifions que le toolchain x86_64-linux-android-4.8 figure bien dans notre PATH (il a automatiquement été chargé dedans via lunch).

$ echo $PATH | grep 'x86_64-linux-android-4.8'

# Le contenu du PATH doit s'afficher à l'écran
# avec le tooclhain dans le répertoire :
# <aosp>/prebuilts/gcc/linux_x86/x86/x86_64-linuxandroid-4.8/bin

Maintenant que tout est prêt nous pouvons lancer la compilation via plusieurs threads en fonction des capacités de l’ordinateur.

$ make –j8

Attention La compilation dure également plusieurs heures selon le nombre de threads utilisés pour compiler et les capacités de l’ordinateur :

environs 3h30 pour un PC avec un processeur 4 coeurs, 8 Go de RAM et 8 threads pour compiler ;
environs 1h30 pour un PC avec un processeur 8 coeurs, 32 Go de RAM et 32 threads pour compiler.

A la fin de la comilation, les images des systèmes de fichiers créées sont disponibles dans le répertoire <aosp>/out/target/production/generic_x86_64.

Compiler Goldfish

Goldfish est une version du kernel Linux adaptée pour Android. Lorsque l’on utilise l’AVD Manager pour créer des émulateurs, des images pré-compilées du kernel Goldfish sont utilisées.

Comme on aime les défis, nous allons le compiler nous-même. Les sources de Goldfish ne faisant pas parties d’AOSP (mais du projet Linux), elles sont stockées dans un dépôt à part entière.

Récupérer le dépôt du kernel Linux Goldfish.

$ git clone https://android.googlesource.com/kernel/goldfish.git

Une fois le dépôt récupéré, nous allons sélectionner la branche android-goldfish-3.10 et ramener les sources à leur état du 16/09/2014.

$ cd goldfish
$ git checkout android-goldfish-3.10
$ git reset --hard 43dbfdb838603e823d75cec871f0c317e8c20fc9
# HEAD is now at 43dbfdb goldfish: Disable Seccomp for Intel builds.

Avant de compiler le kernel Goldfish, il faut vérifier que le toolchain 4.8 est toujours dans notre PATH. Si ce n’est pas le cas, rajoutez le.

PATH=$PATH:~/aosp/prebuilts/gcc/linux_x86/x86/x86_64-linuxandroid-4.8/bin

Il ne nous reste qu’à préparer la configuration d’assemblage et de lancer la compilation.

make x86_64_emu_defconfig
make -j8

A la fin de la comilation, le kernel compilé est disponible dans le répertoire <goldfish>/arch/x86/boot sous le nom bzImage.

Tester

Nous disposons maintenant de tous les fichiers nécessaires pour lancer un émulateur Android x86_64 100% custom (recompilé par nos soins).

Images de systèmes de fichiers issues de la compilation d’AOSP dans le répertoire <aosp>/out/target/product/generic_x86_64/
- cache.img
- hardware-qemu.ini
- ramdisk.img
- system.img
- userdata-qemu.img
Kernel Linux adapté à Android dans le répertoire : <goldfish>/arch/x86/boot/
- bzImage

LXC et Android 5 ARM64

Tue, 30 Dec 2014 00:00:00 +0000

Introduction

LXC (contraction de Linux Containers) est un logiciel permettant de gérer des conteneurs logiciels. Conrètement, LXC peut isole l’exécution de plusieurs environnements Linux sur une même machine. L’isolation est réalisée grâce à l’exploitation des modules de gestion de namespaces du Kernel Linux.

Depuis la publication d’un article en décembre 2013 sur le blog d’un des principaux développeurs de LXC (Stéphane Graber), la communauté d’utilisateurs de conteneurs logiciels est consciente de la possibilité d’utiliser LXC sur un appareil Android. Stéphane Graber en a fait la démonstration à l’occasion de l’évènement Linux Plumbers Conference de septembre 2013.

Les gestionnaires de conteneurs boulversent progressivement les domaines de l’informatique liés à la virtualisation. Le possible usage de LXC sur Android offre des perspectives nouvelles pour l’industrie et la recherche. Un développeur a d’ailleurs démontré (durant l’évènement Droidconf de décembre 2013) le potentiel de LXC en étant capable de changer à chaud la version d’Android avec une simple application.

LXC n’étant pas une application du Google Play Store, son installation sur Android n’est pas évidente. L’utilisateur qui souhaite se lancer sur cette voie est rapidement confronté à des problèmes systèmes. Dans la sections suivantes, nous décrivons les principaux problèmes que nous avons rencontrés pour installer et utiliser LXC sur Android 5 Lollipop.

Contexte

Avant d’aborder les problèmes d’installation de LXC sur Android que nous avons rencontrés, il est important que le lecteur ait connaissance de notre plateforme de test.

Matériel

Nous avons souhaité réaliser ces tests sur un appareil disposant d’une architecture ARM 64-bits (ARMv8). Ce type d’appareil n’étant pas encore démocratisé, nous avons fait le choix d’utiliser une machine virtuelle Qemu.

Pour lancer la machine virtuelle de notre appareil fictif, nous utilisons une version dérivée de Qemu. Cette version est issue de la compilation de la branche ranchu du projet qemu-android d’AOSP. L’avantage de cette version est son support de machines virtuelles à l’architecture ARM 64-bits.

Une fois lancé, notre appareil virtuel dispose d’un CPU cortex-a57 et de 4Go de mémoire vive. Il dispose également de 16Go de mémoire disque (en modifiant la taille de l’image data.img, voir section suivante).

Système d’exploitation

Notre choix d’architecture ARM 64-bits nous impose l’utilisation de la version 5 (Lollipop) d’Android car c’est la seule version supportant ce type d’architecture.

Pour obtenir les images des systèmes de fichiers d’Android 5 utilisées pour lancer notre appareil virtuel (ramdisk.img, system.img, userdata.img et cache.img), nous avons utilisé la configuration de compilation ranchu de la branche android-5.0.0_r7 des sources du projet Android Open Source Project.

Pour obtenir un espace disque important dans notre appareil virtuel, nous avons redimensionné l’image du système de fichiers utilisateur (userdata.img).

# Augmenter la taille de l'image userdata.img d'environs 16Go
dd if=/dev/zero bs=1M count=16000 >> userdata.img
e2fsck -f userdata.img
resize2fs userdata.img
e2fsck -f userdata.img

Kernel Linux

Nous utilisons une version dérivée du noyau Linux. Cette version correspond à la version 3.10 du noyau officiel. Ce noyau est précompilé dans les sources d’AOSP et est disponible dans le répertoire prebuilts/qemu-kernel/arm64 sous le fichier kernel-qemu.

Un projet spécifique est consacré à ce noyau dans le dépôt des sources d’AOSP : kernel/goldfish. Pour recompiler ce noyau adapté à Qemu, nous avons utilisé la branche android-goldfish-3.10 du projet.

Note : goldfish désigne les modules des périphériques virtuels nécessaires pour virtualiser Android avec Qemu. Nous vous recommandons la lecture de GOLDFISH-VIRTUAL-HARDWARE.TXT pour en savoir plus.

Configuration réseau

Pour que notre appareil fictif ait sa propre adresse IP, nous avons configuré une interface réseau virtuelle connectée à la machine host (utilisée pour les tests) via une interface bridge.

Ainsi, lorsque l’appareil virtuel Android est démarré, il suffit de lancer la directive dhcpcd eth0 pour demander au DHCP du réseau l’attribution d’une adresse IP (grâce à l’interface bridge, le DHCP traite la requête de notre périphérique virtuel comme celle de n’importe quelle machine physique du réseau).

Problèmes fondamentaux

Système Unix restreint

Problème

Android est un système d’exploitation Linux destiné à piloter des systèmes embarqués. La philosophie d’Android a conduit ses développeurs à intégrer les outils systèmes uniquement nécessaire à son fonctionnement.

Cette optimisation du système fait d’Android une distribution Linux «restrictive» dans le sens où les utilisateurs, familiarisés à l’utilisation d’une des distribution Linux majeures (Debian par exemple), ne retrouvent pas les outils nécessaires à leurs usages habituels (comme un gestionnaire de paquets).

Solution

Pour pouvoir utiliser certains utilitaires UNIX absents d’Android, il est d’usage d’installer une version ARM de busybox (en copiant son binaire dans le répertoire /system/bin).

Les utilitaires fournis par busybox ne suffisent pas à combler les lacunes d’Android. Néanmoins ils nous ont permis d’installer et de configurer un rootfs Archlinux. Ainsi, nous disposons maintenant d’une distribution Archlinux embarquée dans notre appareil Android afin d’étendre son fonctionnement.

On peut alors installer facilement LXC grâce à pacman, le gestionnaire de paquets d’Archlinux.

Echec des connexions HTTPS

Problème

Une fois le rootfs Archlinux installé et configuré, nous avons souhaité mettre à jour les paquets et installer le paquet LXC. Au cours de cette manipulation, nous avons constaté l’impossibilité d’établir une connexion via le protocole https.

Solution

Ce problème est lié à la date du système. En effet, la date de notre appareil virtuel une fois lancé est assignée au 1/1/1970. Pour corriger ce problème, il suffit de mettre à jour la date du système (avec l’utilitaire rdate de busybox par exemple).

busybox rdate -s ntp.unice.fr

Modules du Kernel manquants

Problème

Après avoir installé LXC avec pacman, et avant de lancer notre premier test de conteneur, nous avons utilisé le script lxc-checkconfig. Ce script lit la configuration du kernel utilisée pour sa compilation. Il vérifit la présence de certaines constantes nécessaires à la compilation des modules requis par LXC. Avec ce script, nous avons pu constater l’absence de modules (du kernel précompilé) nécessaires au bon fonctionnement de LXC.

Solution

Nous avons recompilé le kernel à partir des sources du projet kernel/goldfish. Avant de recompiler le kernel, nous avons modifié la configuration de compilation ranchu_defconfig (fichier uniquement présent dans le répertoire arch/arm64/configs/ de la branche android-goldfish-3.10) pour y ajouter les constantes suivantes :

CONFIG_IPC_NS=y
CONFIG_PID_NS=y
CONFIG_PID_IN_CONTEXTIDR=y
CONFIG_NET_NS=y
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_CPUSETS=y
CONFIG_VETH=y
CONFIG_UTS_NS=y
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_PERF=y
CONFIG_RESOURCE_COUNTERS=y
CONFIG_MEMCG=y
CONFIG_MEMCG_SWAP=y
#CONFIG_USER_NS=y
CONFIG_BTRFS_FS=y
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_EXT4_FS_SECURITY=y
CONFIG_MACVLAN=y
CONFIG_NETFILTER_XT_MATCH_ADDRTYPE=y
CONFIG_VLAN_8021Q=y
CONFIG_BLK_CGROUP=y
CONFIG_CFQ_GROUP_IOSCHED=y

Important : La constante CONFIG_USER_NS est volontairement désactivée à cause d’un problème de compilation (lié à la version des sources de ce module).

Impossibilité de lancer des binaires non-PIE

Problème

Au cours de nos tests, nous avons rencontré une sécurité système propre à Android 5 (branche android-5.0.0_r7). Ce test de sécurité bloque l’exécution de fichiers binaires non-PIE. Pour qu’un exécutable soit PIE, il faut le spécifier à sa compilation.

Solution

Pour outre passer cette sécurité, un patch a été développé par un membre du forum XDA-Developers. Cette solution semble fonctionner selon certains utilisateurs. Nous avons préférés recompiler le code source en désactivant cette sécurité. Pour cela nous avons commenter le bloc de code ci-dessous dans le fichier bionic/linker/linker.cpp

2181    //if (elf_hdr->e_type != ET_DYN) {
2182    //    __libc_format_fd(2, "error: only position independent executables (PIE) are supported.\n");
2183    //    exit(EXIT_FAILURE);
2184    //}

Cgroups non-montés

Problème

Lorsque non consultons le fichier /proc/cgroups, nous constatons la présence plusieurs cgroups. Or lorsque nous consultons les périphériques montés (avec la commande mount), nous avons constaté que seul le cgroup memory était monté. La majorité des cgroups ne sont donc pas montés.

Solution

Il faut monter les cgroups manquants. Pour cela nous nous sommes basés sur les scripts de tianon à la différence que nous montons les cgroups dans la racine de notre rootfs Archlinux (étant donné que nous utilisons LXC à travers ce rootfs).

for i in $(busybox awk '!/^#/ { if ($4 == 1) print $1 }' /proc/cgroups); do
    if ! grep -q " $ROOTFS/$i " /proc/mounts; then
        mkdir -p $ROOTFS/$i
        /system/bin/busybox mount -n -t cgroup -o $i cgroup $ROOTFS/$i
    fi
done

Important : si l’arborescence des cgroups n’est pas montée dans le rootfs, il ne sera pas possible de lancer plus d’un conteneur à la fois.

Echec d’utilisation des cgroups dans un rootfs

Problème

Bien que les cgroups soient montés, ceux-ci sont inutilisables à cause d’un problème d’autorisation d’écriture semble-t-il. N’ayant aucune expérience en matière d’utilisation des modules de gestion des namespaces, nous ne savions pas comment corriger ce problème. Néanmoins, nous étions persuadés que le problème était propre à Android (et probablement au fait qu’on utilise LXC à travers un rootfs).

Solution

Pour tenter de résoudre ce problème, nous avons analysés les fichiers utilisés par S. Graber dans sa démonstration de décembre 2013. Nous avons constaté qu’il utilisait un programme appellé sbin pour remonter recursivement la racine du téléphone / en mode privé.

En remontant la racine de notre appareil virtuel en mode privé (avec le programme sbin) et en démarrant le programme cgmanager dans notre rootfs Archlinux, nous avons pu lancer notre premier conteneur LXC sur Android.

Note : le programme sbin récupérée dans l’archive de S. Graber est non-PIE. Il est inutilisable si le programme linker d’Android 5 n’est pas patché (comme expliqué précédemment).

Conteneur sans accès réseau

Problème

Par défaut, la configuration réseau d’un conteneur est vide. Sans configuration réseau, le conteneur ne dispose pas d’interface pour être connecté en réseau (pas d’adresse IP). La configuration réseau «vide» est indiquée dans le fichier de configuration d’un conteneur par la ligne suivante :

# Network configuration
lxc.network.type = empty

Solution

Parmis les différents types de configuration réseau supportés par LXC, le type macvlan et son mode bridge nous ont permis d’obtenir une IP propre pour nos conteneurs. Nous vous recommandons la lecture de cet excellent article du blog containerops.org pour en savoir plus sur les différents types de configuration réseau de LXC.

# Network configuration
lxc.network.type = macvlan
lxc.network.macvlan.mode = bridge
lxc.network.flags = up
lxc.network.link = eth0

Attention ! Souvenez-vous que l’utilisation d’un type de configuration réseau dépend des modules du kernel et du matériel sur lequel il est installé (par exemple l’option CONFIG_MACVLAN=y utilisée pour recompiler le kernel est nécessaire pour utiliser le type de configuration macvlan de LXC).

Démonstration

Cliquer sur l’image pour voir la vidéo.

Conclusion

L’installation de LXC sur Android requiert différentes maniputions du système. Afin de capitaliser les bonnes pratiques pour utiliser LXC sur Android, nous avons développé le script alfred. Cet outil est utilisé dans notre vidéo de démonstration.

Virtualiser Android 5 Lollipop avec Qemu

Sun, 30 Nov 2014 00:00:00 +0000

Introduction

Les dernières branches d’Android Open Source Project (AOSP) – branches android-5.x – proposent différentes configurations d’assemblages d’Android 5 Lollipop. Chaque configuration d’assemblage correspond à un produit adapté à un type de plateformes d’exécutions. Pour compiler une version complète d’Android 5 pour plateformes ARM, il faut utiliser la configuration d’assemblage aosp_arm-eng (pour les plateformes ARM 32-bits) ou aosp_arm64-eng (pour les plateformes ARM 64-bits).

D’autres produits sont proposées à la compilation notamment les produits ranchu_arm64-eng et mini_emulator_arm64-userdebug :

ranchu_arm64-eng : la compilation de ce produit permet d’obtenir une version complète d’Android 5 ARM 64-bits destinée à être exécutée dans une machine virtuelle (VM) Qemu ;
mini_emulator_arm64-userdebug : ce produit est similaire à ranchu_arm64-eng à la différence que sa compilation permet d’obtenir une version simplifiée d’Android 5 embarquant le minimum de composants nécessaires à son fonctionnement.

La compilation d’un de ces produits créer des images de systèmes de fichiers (ramdisk.img, system.img, cache.img et userdata.img) devant être utilisées avec le logiciel de virtualisation Qemu. L’initialisation d’une VM Qemu avec le produit ranchu_arm64-eng permet de virtualiser Android 5 et de le contrôler via son terminal ou son interface graphique. L’initialisation d’une VM Qemu avec le produit mini_emulator_arm64-userdebug est beaucoup plus rapide car les composants de l’environnement graphique ne sont pas chargés : seul le terminal permet de contrôler cette version allégée d’Android 5.

Les dernières versions de Qemu (2.x) permettent de virtualiser des machines ARM 64-bits. Cependant, aucun programme du projet officiel Qemu ne supporte la virtualisation de machines virtuelles pouvant exécuter le système d’exploitation (OS) Android. Google s’est chargé d’enrichir le projet Qemu pour proposer des programmes capables de virtualiser l’OS Android : c’est le projet qemu-android. La compilation des sources du projet qemu-android permet d’obtenir l’exécutable qemu-system-aarch64 nécessaire à la virtualisation de versions d’Android ARM 64-bits.

Dans les sections suivantes, nous allons voir comment compiler Android 5 (produit ranchu_arm64-eng ou mini_emulator_arm64-userdebug) et le virtualiser dans une VM Qemu.

Prérequis

Capacités processeur et mémoire importantes (la compilation nécessite parfois jusqu’à 4 Go de RAM) ;
Une configuration du bios autorisant la virtualisation ;
Environ 100 Go d’espace disque libre (pour pouvoir compiler les deux produits) ;
Une distribution d’un système d’exploitation Linux récente.

Note : les manipulations décritent ci-dessous ont été réalisées sur un ordinateur disposant d’un processeur Intel Core i5 (2 cœurs cadencés à 1.8 Ghz supportant jusqu’à 4 threads par coeur), de 8 Go de mémoire RAM et de la distribution Ubuntu 14.04.1 LTS 64-bits.

Préparer l’environnement d’assemblage

Installer la machine virtuelle Java (JVM) Open JDK 7 (nécessaire pour compiler les dernières branches d’Android)

$ sudo apt-get install openjdk-7-jdk –y

Vérifier que Open JDK 7 est la JVM utilisée par défaut

$ sudo update-alternatives --config java
$ sudo update-alternatives --config javac

Installer des packages nécessaires pour la compilation

$ sudo apt-get install bison build-essential curl flex g++-multilib git gperf lib32z1 lib32z1-dev libglib2.0-dev libpixman-1-dev libswitch-perl libxml2-utils yasm zlib1g zlib1g-dev

Configurer une identité utilisateur sous Git

$ git config --global user.name "John Doe"
$ git config --global user.email "jd@android.com"

Récupérer l’utilitaire repo de Google et le charger dans le PATH courrant

$ mkdir ~/bin && PATH=~/bin:$PATH
$ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
$ chmod a+x ~/bin/repo

Récupérer les sources d’AOSP

Créer un répertoire pour le dépôt des sources d’AOSP

$ mkdir –p ~/dev/aosp && cd ~/dev/aosp

Initialiser le dépôt avec la branche android-5.0.0_r7 d’Android

$ repo init -u https://android.googlesource.com/platform/manifest -b android-5.0.0_r7

Synchroniser le dépôt pour récupérer les sources (l’opération dure plusieurs heures à cause du volume important de données à télécharger)

$ repo sync

Corriger les configurations d’assemblage

Les premières branches d’Android 5 souffrent de petits bugs nécessitant une modification manuelle des sources pour pouvoir compiler les produits ranchu_arm64-eng et mini_emulator_arm64-userdebug :

ranchu_arm64-eng : le script permettant de proposer ce produit à la compilation n’existe pas, il faut le rajouter ;
mini_emulator_arm64-userdebug : le choix de la configuration d’assemblage de ce produit indique que les fichiers compilés sont destinés à des plateformes ARM 32-bits (armv7), il faut modifier cela pour que les fichiers soit compilés pour plateformes ARM 64-bits (armv8).

Merci à Vito Rallo qui a identifié ces bugs et qui propose une archive à décompresser dans le répertoire device/generic pour les corriger.

$ cd ~/dev
$ wget https://dl.dropboxusercontent.com/u/2930979/fixit.tar.gz
$ tar -xvf fixit.tar.gz -C aosp/device/generic

Compiler les sources d’AOSP

Se placer dans le dossier principal des sources d’AOSP

$ cd ~/dev/aosp

Initialiser l’environnement de compilation dans le terminal

$ source build/envsetup.sh

Charger la configuration d’assemblage du produit ranchu_arm64-eng ou

mini_emulator_arm64-userdebug

$ lunch ranchu_arm64-eng

Lancer la compilation en fonction des capacités de l’ordinateur (pour un processeur dual core supportant 4 threads par cœur, 8 threads peuvent être utilisés pour la compilation)

$ make –j8

A la fin de la comilation, les images des systèmes de fichiers créées sont disponibles dans un sous répertoire du dossier «out»

Pour ranchu_arm64-eng : out/target/product/generic_arm64/
Pour mini_emulator_arm64-userdebug : out/target/product/mini-emulator-arm64/

Virtualiser la version compilée d’Android avec Qemu

Pour virtualiser une version d’Android 5 ARM 64-bits, nous avons besoin du programme qemu-system-aarch64 modifié par Google pour supporter l’exécution de la machine virtuelle «ranchu» (et du type de processeur «cortex-v57»).

Initialiser le dépôt du projet qemu-android

$ cd ~/dev
$ git clone https://qemu-android.googlesource.com/qemu-android
$ cd qemu-android

Compiler l’exécutable qemu-system-aarch64

$ git submodule update --init dtc
$ git checkout origin/ranchu
$ ./configure --target-list=aarch64-softmmu
$ make -j8

Charger le programme compilée dans le PATH courrant (par lien symbolique)

$ ln -s ~/dev/qemu-android/aarch64-softmmu/qemu-system-aarch64 ~/bin/qemu-system-aarch64

Nous sommes maintenant prêt à virtualiser Android 5 pour plateformes ARM 64-bits dans une VM Qemu grâce à l’exécutable qemu-system-aarch64, nos images compilées de systèmes de fichiers et un kernel Qemu précompilé par Google.

Se positionner dans le répertoire d’un des produits compilés

$ cd ~/dev/aosp/out/product/generic_arm64

Démarrer une VM Qemu avec Android 5 Lollipop

qemu-system-aarch64 -machine type=ranchu -cpu cortex-a57 -m 2048 -serial mon:stdio -show-cursor -kernel ~/dev/aosp/prebuilts/qemu-kernel/arm64/kernel-qemu -initrd ramdisk.img -drive index=2,id=userdata,file=userdata.img -device virtio-blk-device,drive=userdata -device virtio-blk-device,drive=cache -drive index=1,id=cache,file=cache.img -device virtio-blk-device,drive=system -drive index=0,id=system,file=system.img -netdev user,id=mynet -device virtio-net-device,netdev=mynet

Explication de la commande :

-machine type=ranchu : on sélectionne le type de machine virtuelle «ranchu» adaptée à la virtualisation d’Android
-cpu cortex-a57 : on sélectionne le processeur virtuel pour plateformes ARM 64-bits
-m 2048 : on alloue 2048 Mo de mémoire à la VM
-serial mon:stdio : pour pouvoir contrôler le terminal de la VM
-show-cursor : pour afficher le pointeur de la souris dans la VM
-kernel : on utilise le kernel Qemu pour plateformes ARM 64-bits précompilé par Google
-initrd : on utilise le fichier compilé «ramdisk.img» comme disque RAM initial
-drive et -device : on monte les images de systèmes de fichiers compilés
-netdev : pour profiter de la connexion réseau

Aperçu de ranchu_arm64-eng :

Aperçu de mini_emulator_arm64-userdebug :

Références

Installer Apache Mesos 0.20.1 sur Ubuntu 14.04.1.LTS

Mon, 17 Nov 2014 00:00:00 +0000

A propos d’Apache Mesos

Mesos est un projet de la fondation Apache présenté comme un noyau de systèmes distribués. Il permet d’exploiter les ressources de plusieurs machines comme un seul système. Il assure l’isolation et la haute disponibilité d’exécutions de programmes. Mesos fournit deux composants logiciels :

mesos-slave : composant installé sur un noeud slave pour mettre à disposition ses ressources à un noeud master ;
mesos-master : composant installé sur un noeud master pour gérer un système distribué (gérer les ressources des noeuds slaves et des exécutions de programmes initiées par l’utilisateur).

En environnement de production, il est recommandé de configurer plusieurs noeuds mesos-master et d’utiliser Apache Zookeeper pour l’élection du noeud master actif. Ainsi, quand le noeud master actif rencontre un problème, Zookeeper se charge d’élire un nouveau noeud master.

Exemple d’utilisation d’Apache Mesos

Plateforme cible

L’objectif de nos manipulations est de configurer un système distribué avec Mesos. Nous allons configurer Mesos sur deux noeuds Ubuntu 14.04.1 LTS :

Noeud master (192.168.1.101) avec Zookeeper et mesos-master pour gérer le système distribué ;
Noeud slave (192.168.1.102) avec mesos-slave pour mettre à disposition les ressources du noeud au système distribué (il se connecte à mesos-master en utilisant Zookeeper).

En environnement de production, il est recommandé d’installer Zookeeper sur un noeud différent du noeud mesos-master car s’il rencontre un problème, Zookeeper ne sera plus disponible pour élire un nouveau noeud mesos-master et rediriger les noeuds mesos-slave.

Diagramme de déploiement

          192.168.1.101
+---------------------------------+
|                   +-----------+ |
|                   | zookeeper | |
|                   +--[2181]---+ |        192.168.1.102
|                       ^  ^      |   +---------------------+
| +--------------+      |  |      |   |   +-------------+   |
| | mesos-master |------+  +------|---|---| mesos-slave |   |
| +----[5050]----+                |   |   +-------------+   |
|        ^                        |   +----------|----------+
|        |                        |              |
|        +------------------------|--------------+
+---------------------------------+

Installer Apache Mesos sur plusieurs noeuds Ubuntu

Prérequis

Ubuntu 14.04.1 LTS 64-bit est installé sur les noeuds master et slave
Le paquet openjdk-7-jdk est installé sur les noeuds
La dépôt mesosphere est configurée sur les noeuds master et slave :

$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv E56151BF
$ echo "deb http://repos.mesosphere.io/ubuntu trusty main" | sudo tee /etc/apt/sources.list.d/mesosphere.list
$ sudo apt-get update -y

Configuration du noeud master

Installation du paquet mesos et du paquet zookeeper (par dépendance) :

$ sudo apt-get install mesos -y

Configuration de l’interface réseau utilisée par mesos-master :

$ echo 192.168.1.101 | sudo tee /etc/mesos-master/ip

Configuration du nom du système distribué :

$ echo MyCluster | sudo tee /etc/mesos-master/cluster

Configuration de l’URL Zookeeper pour identifier le noeud mesos-master :

$ echo zk://192.168.1.101:2181/mesos | sudo tee /etc/mesos/zk

Configuration de l’instance Zookeeper :

$ echo 1 | sudo tee /etc/zookeeper/conf/myid

Redémarrage des services Zookeeper et mesos-master :

$ sudo service zookeeper restart
$ sudo service mesos-master restart

Configuration du noeud slave

Installation du paquet mesos sans le paquet zookeeper :

$ sudo apt-get download mesos
$ dpkg -i mesos_0.20.1-1.0.ubuntu1404_amd64.deb

Configuration de l’interface réseau utilisée par mesos-slave :

$ echo 192.168.1.102 | sudo tee /etc/mesos-slave/ip
$ echo 192.168.1.102 | sudo tee /etc/mesos-slave/hostname

Configuration de l’URL Zookeeper pour identifier le noeud mesos-master :

$ echo zk://192.168.1.101:2181/mesos | sudo tee /etc/mesos/zk

Démarrage du service mesos-slave :

$ sudo service mesos-slave start

Configuration additionnelle

Pour notre test, il est intéressant de configurer le noeud master pour pouvoir intégrer ses ressources au système distribué en démarrant le service mesos-slave. Attention! Cette pratique est déconseillée en environnement de production.

Sur le noeud master :

$ echo 192.168.1.101 | sudo tee /etc/mesos-slave/ip
$ echo 192.168.1.101 | sudo tee /etc/mesos-slave/hostname

La commande sudo service mesos-slave start intégère les ressources du noeud master au système distribué (les ressources du noeud master peuvent alors être utilisées pour réaliser des traitements).

Tester l’installation d’Apache Mesos

Rendez-vous sur l’interface web de mesos-master en consultant l’URL http://192.168.1.101:5050. Le cadre à gauche indique le nombre de noeud slaves actifs (1 si mesos-slave est démarré sur le noeud slave, 2 si mesos-slave est également démarré sur le noeud master ou 0 si mesos-slave est arrêté sur les deux noeuds).

Pour tester rapidement l’exécution d’un programme, exécutez la commande suivante depuis le terminal d’un des noeuds :

$ mesos-execute --master=$(mesos-resolve zk://192.168.1.101:2181/mesos) --name="hello" --command="echo hello world" --resources="cpus:0.1;mem:16"

Note : le programme mesos-resolve permet de trouver le noeud mesos-master actif via Zookeeper.

L’installation peut être testée avec le framework Marathon. Il est disponible sur le dépôt mesosphere ajouté précédemment. Exécutez la commande suivante sur le noeud master pour installer Marathon :

$ sudo apt-get install marathon -y

Une fois installée, il suffit de démarrer le service Marathon…

$ sudo service marathon start

…et de lancer des applications via son interface web en consultant l’URL http://192.168.1.101:8080.

Marathon négocie avec Mesos l’exécution d’applications et assure quelles soient toujours actives : lorsqu’une application se termine, Marathon se charge de la relancer. Marathon fournit une API Rest pour réaliser des opérations par requêtes http.

Références

Apache Mesos : http://mesos.apache.org
Apache Zookeeper : http://zookeeper.apache.org
Marathon : https://mesosphere.github.io/marathon
Installing Mesosphere Packages on Ubuntu / Debian : https://mesosphere.com/docs/tutorials/install_ubuntu_debian

Communications dans les systèmes embarqués par l’emploi d’agents mobiles

Sun, 01 Jun 2014 00:00:00 +0000

Contexte

Les systèmes embarqués sont le support des périphériques mobiles qui ont envahi notre quotidien : ordinateurs portables, terminaux de poche (« smartphones »), tablettes tactiles, … ont profondément modifiés notre comportement. Les puissances de calculs (de plus en plus grandes) et les moyens de communications (e.g. Wifi, Bluetooth) dont ils disposent leur permettent d’interagir entre eux et avec le monde environnant. Il est possible d’échanger avec l’un de ces systèmes lorsque le périphérique destinataire est joignable par un réseau informatique. Les périodes d’indisponibilités de ces périphériques sont fréquentes au cours de leur cycle d’utilisation (par exemple la perte d’une connexion à un réseau Wifi ou téléphonique mobile lors d’un déplacement).

Le sujet de ce projet de recherche porte sur l’emploi de la mobilité logicielle dans le but de proposer un modèle de communication nouveau pouvant garantir l’aboutissement des échanges entre systèmes embarqués. La conduite des travaux de ce projet doit permettre : à la société Leuville Objects d’initier une cellule de recherche et développement destinée à améliorer et optimiser ses prestations d’ingénieries informatiques ; de former et d’intégrer progressivement un étudiant – Steven ENTEN, arrivant au terme d’un second cycle universitaire et souhaitant devenir Docteur en informatique spécialisé dans les technologies mobiles – au monde de la recherche et de l’entreprise ; de contribuer aux recherches du groupe « Mobilité », dirigé par Fabrice MOURLIN, du Laboratoire d’Algorithmique, Complexité et Logique (LACL).

La société Leuville Objects (LO) a depuis sa création en 1996, eu pour thème d’activité les architectures logicielles, leur création, leur gestion mais aussi leur mise en œuvre via l’emploi de cadres de développement (« frameworks ») novateurs pour leur époque. Ainsi, dès les premières versions de Java 2 Enterprise Edition (J2EE), des projets ont été montés dans des sociétés clientes par des ingénieurs de LO. De même, lors de l’apparition des premiers bus logiciels d’entreprise (ESB), LO a fait des choix audacieux autour de produits Open Source tels qu’Apache ServiceMix pour offrir à ses clients des solutions nouvelles à base de clusters d’ESBs.

Au cours des années passées, le thème de la virtualisation s’est développé dans toutes les sociétés, allant de la virtualisation de serveurs, jusqu’au poste client en passant par les réseaux eux même. La société LO souhaite être reconnue auprès de ses partenaires pour son expérience dans ce domaine et plus particulièrement sur le thème de la virtualisation de périphériques mobiles. Ce sujet est lié de manière très étroite à l’économie d’énergie et l’accroissement de la durée d’usage des périphériques mobiles tels que les téléphones, tablettes et autres navigateurs [1]. Le sujet de thèse proposé aborde le domaine commun de la virtualisation de périphérique mobile dans un cloud avec la possibilité d’exporter tout le contexte d’exécution pour en minimiser sa consommation énergétique [4], [7].

Les résultats obtenus dans cette thèse vont pouvoir directement être intégrés dans les travaux préparatoires effectués au sein de la société LO. Nous pouvons citer : la définition d’une architecture logicielle pour la virtualisation de poste mobile, l’isolation de machine virtuelle par container, la mise en place d’une architecture tolérante aux pannes (« fault tolerance ») pour assurer à l’utilisateur la disponibilité de son poste virtualisé. Le suivi régulier de ces travaux est aussi un moyen pour assurer la montée en compétence des ingénieurs sur ces sujets et ainsi développer l’activité de recherche et de développement de la société LO.

Objectif

Les périphériques mobiles représentent un des axes stratégiques de développement de la recherche actuelle [6]. La mise au point de ce mécanisme inédit de haute disponibilité des communications doit permettre d’ouvrir la voie à des applications industrielles innovantes. Ce mécanisme consiste à communiquer par l’emploi d’agents mobiles envoyés directement au périphérique destinataire quand celui-ci est joignable. En cas d’indisponibilité du périphérique destinataire, les agents mobiles s’adresseront à un « clone » (une image virtuelle) du périphérique destinataire présent dans un environnement cloud. De cette manière, la communication est assurée entre l’expéditeur et le destinataire. Lorsque le destinataire sera de nouveau joignable, la synchronisation avec son clone sera réalisée par des agents mobiles.

Le développement d’un prototype logiciel illustrant ce mécanisme – de communication indirecte par l’emploi d’agents mobiles dans un environnement cloud – est l’une des contributions apportées par ce projet de recherche. Avant cela, il sera impératif d’élaborer une spécification formelle qui décrit de manière unique cette haute disponibilité des communications (la garantie que les messages échangés aboutissent malgré une indisponibilité partielle du destinataire). Un modèle temporel devra également être établi afin de vérifier la spécification ainsi que les propriétés temporelles exprimées par cette logique.

Organisation des travaux de recherche

Première année

Des travaux seront menés pour valider l’applicabilité de travaux antérieurs portant sur différentes stratégies de communication directe par agents mobiles [2], [3], [8]. Il faudra ensuite les développer pour proposer une stratégie de communication indirecte par cloud.

Communication directe

Il s’agira de développer une application distribuée sur deux périphériques embarqués et connectés par un réseau Wifi : le but est de montrer la possibilité d’échanger en direct un agent mobile entre deux tablettes. L’agent échangé – disposant de droits pour s’exécuter sur la plate-forme cible – effectuera une collection d’information avant de retourner sur la plate-forme de départ. Ce cas d’étude se raffine par une configuration initiale de l’agent afin de visiter une suite de périphériques embarqués avec retour. Un point important sera placé sur la description de la demande effectuée par les plates-formes ainsi que la gestion des permissions lors des visites. Un premier rapport de développement sera fourni pour montrer que les principes sont assimilés.

Communication indirecte par cloud

Le mode de communication précédent présente des limites évidentes. La disponibilité est essentielle, or dans le cadre de périphérique mobile, il faut que ceux-ci soient joignables par le réseau. De plus, l’aspect embarqué des périphériques implique une indisponibilité partielle de parties logicielles en regard des interruptions supportées : appels entrant, alarmes, batterie insuffisante, etc. Il est indispensable d’envisager un autre mode de communication non synchrone dans le cas où le mode précédent ne peut pas être utilisé. Ce mode alternatif consistera pour la partie communicante à envoyer un agent à destination non pas du receveur mais d’une image de ce dernier dans le cloud. Ce clone assurera les services d’accueil de la plate-forme absente. Lorsque celle-ci sera de nouveau disponible, le clone se chargera de sa mise à jour. L’application illustrant ce mode de communication devra être optimisée pour un système réparti multi-échelle [5]. Un bilan de cette étude sera rédigé en mettant en valeur la pertinence des critères de réalisation. Un point important sera placé sur la description du clone et l’ensemble de son cycle de vie.

Les stratégies de communication précédemment introduites doivent donner lieu à une validation par prototypage. Chaque prototype sera défini au préalable pour s’assurer des observations faites, puis validé pour s’assurer de l’adéquation avec ce qu’il est censé montrer. Un bilan de cette première année devra être rédigé en anglais afin qu’une publication puisse paraître. Ce bilan devra conclure sur la poursuite du travail réalisé.

Deuxième année

Sur la base du travail réalisé en première année, une application type sera à définir. Elle aura pour principal concept la mobilité d’agents (le plus autonome possible) entre plates-formes nomades. La rédaction des spécifications de cette application devra être menée à son terme pour ensuite débuter sa conception.

Spécification formelle

Le langage de spécification formelle Pi calcul d’ordre supérieur sera utilisé pour la rédaction des spécifications [10] : ce langage offre un pourvoir d’expression utile pour la description d’agents mobiles. Son étude est un impératif pour pouvoir ensuite décrire de façon formelle le contexte de la communication au sein du réseau.

Preuve de propriétés

A partir des spécifications formelles, des propriétés temporelles seront exprimées par l’emploi d’une logique temporelle telle que TCTL [9]. Un modèle temporel sera construit à partir de la spécification en pi calcul. Les propriétés seront ensuite prouvées par model checking, telle que la transparence de communication. Le but est d’assurer que ces propriétés sont préservées lors de la construction du prototype résultat. Un outil tel qu’UPPAAL pourra être utilisé pour la construction d’automates temporisés.

Un bilan de cette étude formelle sera rédigé en insistant sur le cycle de vie d’un clone de plate-forme (e.g. comme la terminaison d’un clone de plate-forme).

Troisième année

Une fois l’application type spécifiée, son prototypage pourra commencer en veillant à respecter les propriétés établies. L’objectif n’est pas d’obtenir une application distribuée utilisable dans le monde de l’industrie mais de valider les résultats de la première année et surtout d’appliquer les points spécifiés au cours de la deuxième année. Les choix techniques de réalisation ainsi que les aspects liés aux propriétés temporelles devront être consignés dans des documents spécifiques.

Chaque année de recherche donnera lieu à la présentation des résultats dans une conférence internationale reconnue dans le domaine : le travail réalisé y sera présenté. Les publications de la seconde et de la troisième année feront l’objet d’une version étendue afin d’être publiée dans une revue internationale de qualité.

Références

[1] H. FLORES, S. N. SRIRAMA, R. BUYYA, “Computational Offloading or Data Binding? Bridging the Cloud Infrastructureto the Proximity of the Mobile User”, in Mobile Cloud Computing, Services, and Engineering, Second IEEE International Conference, 2014
[2] C. DUMONT, “Système d’agents mobiles pour les architectures de calculs auto-adaptatifs”, PhD Thesis, 2014
[3] C. MAHMOUDI, F. MOURLIN, “Adaptivity of Business Process”, in The Eighth International Conference on Systems, ICONS, 2013
[4] S. SIMANTA, K. HA, G. LEWIS, E. MORRIS, M. Satyanarayanan, “A Reference Architecture for Mobile Code Offload in Hostile Environments”, in Software Architecture and European Conference on Software Architecture, 2012
[5] S. ROTTENBERG, S. LERICHE,C. LECOCQ, C. TACONET, “Vers une définition d’un système réparti multi-échelle”, in Ubimob, 2012
[6] M. SATYANARAYANAN, “Mobile Computing: the Next Decade”, in The First ACM Workshop on Mobile on Mobile Cloud Computing and Services, 2010
[7] M. SATYANARAYANAN, P. BAHL, R. CACERES, N. DAVIES, “The Case for VM-based Cloudlets in Mobile Computing”, in Pervasive Computing, vol. 8, 2009
[8] M. BERNICHI, “Surveillance logicielle à base d’une communauté d’agents mobiles”, PhD Thesis, 2009
[9] P. BOUYER, “Model-checking Timed Temporal Logics”, in Electronic Notes in Theoretical Computer Science, vol. 231, 2009
[10] R. MILNER, “The polyadic p-calculus: a tutorial”, in Technical Report ECS-LFCS-91-180, 1993

Contact

Société Leuville Objects

Laurent Nel
3 rue de la Porte de Buc, 78000 Versailles
+33(0)1 39 50 20 00 – laurent.nel@leuville.com

Directeur de thèse

Fabrice Mourlin
LACL, 61 avenue du Général de Gaulle, 94010 Créteil Cedex
+33(0)6.15.05.15.51 – fabrice.mourlin@u-pec.fr

Doctorant

Steven Enten
21 rue Charles Floquet, 94400 Vitry-sur-Seine
+33(0)7 70 32 27 55 – steven@enten.fr