1. Introduction

Dans le cadre du projet de fin d'étude à Polytech Grenoble, Nous avons choisi de travailler dur le projet CoCaas (Collaborative Containers as a service)

En informatique, certains domaines exigent une grande puissance de calcul ou un nombre conséquent de machines pour créer un système distribué. A l’heure actuelle, ces plateformes coûtent extrêmement cher auprès des acteurs du cloud, ou sont dédiées à la recherche (comme Grid’5000). Il est donc assez compliqué pour des entreprises, des chercheurs ou même des étudiants d’avoir accès à une telle plateforme.

Avec une telle plateforme, chaque utilisateur pourrait mettre à disposition des ressources qu’il n’utilise pas sur son ordinateur, dont pourraient se servir les membres en demande de ressources. Notre projet peut être utilisé dans un intranet d'une entreprise par exemple ou (avec l'utilisation de OpenVPN), il permettra d'utiliser les ressources d'un cluster à distance .

1.1 Equipe

ARRADA Imad
FAURE Quentin
FOUNAS Abdelaziz
HALLAL Marwan
MEDEWOU Cenyo (Scrum Master)
VOUTAT Manuel (Chef de projet)

Personnes Ressources :

Comité de pilotage : Didier Donsez
Chef de projet du groupe de l'année dernière : Robin EUDES

1.2 Principe du projet

Nous avons choisi comme sujet de continuer un projet étudié l’année dernière par un autre groupe (IaaS Collaboratif). L’objectif de leur projet était de créer une solution de partage de ressources entre utilisateurs basée sur la virtualisation. Pour ce faire, ils utilisaient des méthodes de containers (Docker), afin de partager les ressources de plusieurs machines et ainsi améliorer la vitesse de calcul, sans influencer l’utilisation du propriétaire de la machine.

L’objectif du projet est de permettre de créer une plateforme collaborative permettant de déployer des containers sur les machines constituant cette plateforme, basée sur Docker Swarm. La plateforme est constituée de deux types de machines : les workers et les managers.

La plateforme sera constituée d’une partie front-end, qui permet de déployer des services, et d’une partie back-end qui gérera les services et les ressources en se basant sur swarm.

1.3 Vocabulaire et Définitions

Partage de ressource :

En informatique, il est parfois nécessaire d’effectuer des calculs qui nécessitent une grande puissance de calcul. Si ces calculs sont exécutés sur une seule machine, cela peut prendre énormément de temps (par exemple, la durée d’un calcul pour casser le chiffrement RSA, un chiffrement courant sur internet, se compte en année). Dans un cas comme celui-là, il est intéressant de réunir plusieurs PC pour disposer de plus de ressources de calcul, pour gagner du temps.* http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Presentations/PPTX/Ch4.pptx

Virtualisation :

La virtualisation consiste à faire fonctionner un système d’exploitation dans un autre système d’exploitation, comme s’il s’agissait d’un simple logiciel. Ainsi, il est possible de faire fonctionner Linux dans Windows, comme si c’était une simple application. Dans ce cas là, le système Linux est appelé système invité (ou machine virtuelle en abus de langage, abrégé VM en anglais), et le système Linux est appelé système hôte (ou host en anglais). Docker : Docker est une technologie de virtualisation dite « légère ». Basée sur des technologie du noyau Linux (LXC, cgroups, …), elle permet de virtualiser uniquement une application plutôt qu’un système d’exploitation complet. De fait, une machine virtuelle mets beaucoup plus de temps à démarrer et prend beaucoup plus de ressource sur un système hôte que Docker, qui utilise les containers.

Container :

Un container dans Docker peut être comparé à ce qu’est une machine virtuelle dans la virtualisation. Si le nom est différent, c’est que le procédé l’est aussi. Là où, avec la virtualisation, un système complet est disponible (avec son interface graphique, ses applications de bases, …), un container ne dispose que des outils nécessaires à son bon fonctionnement. Par exemple, si une machine virtuelle est créée pour faire un site web, elle embarquera tous les logiciels de base de son système d’exploitation, alors que le container ne contiendra que les application pour faire le site web.

Images Docker :

Les images sont la base des containers. Elle contiennent un ensemble de logiciels et d’outils sur lequel se basent les containers. C’est une image d’un système à un moment donné. Une image n’est jamais modifiée, alors qu’un container va évoluer au cours du temps, selon les interactions qu’il subit (par exemple, pour un site web, des informations vont être ajoutées).

Docker Swarm (+ worker/manager) :

Là où Docker permet de lancer des containers sur une machine précise, Docker Swarm permet de constituer un ensemble de machines (appelé swarm) sur lesquelles les containers vont être déployés. Dans un swarm, il existe deux types de machines : les workers et les managers. Les workers sont des machines qui sont ici seulement pour effectuer des tâches (dans swarm, il s’agit de services); de leur côté, les managers sont présent pour coordonner le swarm, et définir les services à effectuer. Pour chaque swarm, il faut au minimum un manager, alors que les workers ne sont pas nécessaires (un manager effectue les mêmes tâches qu’un worker).

Service dans Docker Swarm :

Dans Docker Swarm, un service correspond à une tâche à effectuer, comme pour un container avec Docker. Pour créer un service, il est nécessaire d’indiquer une image sur laquelle se baser, et un nombre de containers, qui vont être répartis sur les machines du swarm.

Front-end :

Partie visuelle d’un projet. Dans notre projet, il s’agit de l’interface utilisateur, accessible par un site web.

Back-end :

Ensemble de fonctionnalités qui permettent de faire fonctionner le projet. Dans notre cas, il s’agit de toute la partie qui permet au site d'interagir avec les différentes machines du swarm

1.4 Liens pour le projet

Page du projet

Depots GitHub : Cocaas Front-end

Projet de l'année dernière

Installation Docker swarm

Installation Docker Engine

Install machine docker

Docker Community edition

OpenVPN

2.Description Générale

2.1 Architecture générale du produit

Archi_CoCaas

Archi2_CoCaas

2.2 Réalisation du produit

2.2.1 Structure du Back-end

Back-end

RestAPI.py : Appel REST pour les fonctions front-end (voir partie front-end)
config.json : configuration pour la base de données et le Docker Swarm
DockerSwarm.py : Toutes les fonctions de manipulation de l'API Docker
ManagerDB.py : Toutes les fonctions de l'API mongoDB

Scripts locals

common.py : fonctions et constantes communes à tous les scripts
init.py: vérification d'instalaltion et join du swarm
monitoring.py : fonction qui renvoit les stats du systèmes
RestCall.py : appel aux fonctions du backend (REstAPI.py)
Remove.py : désinscrit du site et remove du swarm

2.2.2 Structure du Front-end

Client_CoCaas

Provider_CoCaas

Fonctions du Front-end

Inscriptions de l'utilisateur
Connexion de l'utilisateur
Déconnexion de l'utilisateur
Consulter la page d'accueil
Consulter l'aide
Partie Client :
- Demande Services
- Scale de Service
- Supprimer un container
- Supprimer un service
- Supprimer tout les services
- Overview :
  - Nombre de services pour le client
  - Nombre de Containers pour le client
  - Nombre d'images différentes pour le client
  - Nombre de machines différentes que lequel tourne les services du client
Partie Provider :
- Overview performances données / performances de la machine de l'utilisateur
- Overview performances utilisés / performances données par le provider
- Inserer une docker machine (script d'installation)
- Supprimer docker machine (script de desinstallation)
- Informations sur le provider:
  - Containers de l'utilisateurs
  - Images disponibles
  - Noeud du provider

Diagramme Use-Case

UseCase_CoCaas

2.2.3 Structure de la base de données

BD_CoCaas_NonRelationnel

2.3 Utilisateurs

Le client et le provider ne doivent pas être familier avec la programmation.
Le client et le provider doivent avoir des connaissances basiques en commandes UNIX.
Le client et le provider doivent savoir comment lancer un script dans un terminal base UNIX.
Le client et le provider doivent avoir tout les packages/ frameworks nécessaire (Docker...) pour lancer l'application.
Le client et le provider ne doivent pas avoir besoin d'autres installations et compétences, tout doit être géré dans le serveur qui héberge notre application.
Les utilisateurs potentiels de l'application appartiennent soit à un réseau local (intranet entreprise par exemple) ou peuvent travailler chacun sur des machines distantes sur le net.

2.4 Contraintes Générales

Langage utilisé, Frameworks et autres outils :

Back-end
- Python (Compatible avec Python 2.7)
- Commande UNIX
- Flask
- MongoDB
- Docker Swarm
- OpenVPN

Front-end
- JavaScript
- AngularJS
- JQuery
- HTML5, CSS3
- Bootstrap

2.5 Hypothèses et Dépendances

Le projet est réalisé sur console Unix et la compatibilité avec Windows est ignoré pour le moment.

3.Evolution du produit

Plusieurs améliorations sont possibles pour le projet, notamment en utilisant OpenVPN, les performances sont nettement diminué.

Pour pallier à plusieurs problèmes, nous avons choisi de deployer un service swarm par container ce qui peut poser un problème si on attend la limite au niveau des ports disponibles.

Une autre amélioration possible serait de rendre accessible les services sur toutes les machines par exemple, en utilisant le même port

Système de crédit

Un système de crédit a été pensé par le groupe de projet afin de bien répartir le nombre de provider et de client pour le système tournant sur internet. En effet, dans l'hypothèse d'une utilisation collaborative sur le net de notre application, on doit pouvoir avoir assez de providers pour le nombre de demande de ressources des clients.

Le système serait le suivant :

L'utilisateur gagne quelques crédits pour son inscription sur le site de l'application
L'utilisateur gagne des crédits quand il choisi de devenir provider (calcul basé sur la performance et le temps up)
L'utilisateur utilise des crédits pour demander des ressources sur le cluster (calcul basé sur la performance et le temps up)

4. Structure du SRS

The document is based on template of the Software Requirements Specification (SRS) inspired of the IEEE/ANSI 830-1998 Standard.

SRS-CoCaas