Cloud rasberryfinal

Projet Sécurité Cloud
CloudBerryPi
Réalisation par:
Mr Ahmed Benslimane
Mr El-hadi FALAH
Mr Gérard Bonneto
Mr Yacine Sebihi
A.N. 2015-2016 Mastère Spécialisé Cloud Computing

CloudBerryPi AN. : 2015/2016
ISEP 2015/2016 : CloudBerryPi
Page : 2 / 30
Table des matières
1. INTRODUCTION .............................................................................................................................. 3
1.1 DESCRITPION DU PROJET ..............................................................................................................................3
2. ETUDE THEORIQUE ......................................................................................................................... 4
2.1 ANALYSE ET COMPARAISON DES SOLUTIONS.....................................................................................................4
2.2 APPROCHE DE TYPE CLUSTER .........................................................................................................................5
2.2.1 le projet de cluster de l'université de Glasgow...............................................................................5
2.2.2 le projet de cluster de l'université de Southampton.......................................................................6
2.2.3 le projet de cluster de l'université de Boise :...................................................................................8
2.2.4 le projet de cluster de Richard S. Huntrods:....................................................................................9
2.2.5 le projet de cluster de "Raspberry Pi Cluster":................................................................................9
2.2.6 Kubernetes:...................................................................................................................................10
2.3 ETUDE DE FAISABILITE ................................................................................................................................12
2.3.1 Docker...........................................................................................................................................12
2.3.2 Hadoop .........................................................................................................................................14
2.3.3 Openstack.....................................................................................................................................15
2.3.4 NodeJs...........................................................................................................................................16
3. CONCLUSION.......................................................................................ERREUR ! SIGNET NON DEFINI.

Page : 3 / 30
1. INTRODUCTION
1.1 DESCRITPION DU PROJET
Ce projet consiste à utiliser des micro ordinateurs Raspberry Pi pour créer une infrastructure Cloud
en vue de tests.
L'objectif est de faire une analyse de faisabilité, puis de monter une maquette afin de pouvoir faire
des tests. Il faudra tenir compte des performances des Raspberry Pi 2 dans les conclusions qui
pourront être tirées et dans les choix qui seront faits.
A terme, on pourra envisager de simuler un Fournisseur d'Energie Cloud (ou CSP, Cloud Service
Provider), chaque Raspberry Pi pouvant alors simuler des centres informatiques répartis.
Il s'agit d'un projet technique nécessitant une bonne connaissance de l'environnement Linux
(Debian de préférence). Le matériel mis à disposition sera constitué de :
o 2 à 6 Raspberry Pi 2 tournant sous Raspbian Jessie Lite version du 21.11.2015 (basé sur uneimage
minimaliste de Debian Jessie et sur un Kernel Linux 4.1), un accès SSH pour administrer les
Raspberry Pi par SSH au travers d'une connexion Internet
o 2 à 4 périphériques de stockage de 8 Go par Raspberry Pi
Le projet est divisé en 2 parties :
1ère partie : étude théorique et de faisabilité.
Il s'agit d'établir un panorama des solutions dites "de Cloud" qui sont disponible pour Raspbian, ainsi que
celle de type"cluster". Ce panorama pourra être composé de 3 parties :
1 — Il est souhaitable d'analyser et de comparer — au moins sur le papier — les solutions suivantes :
 ownCloud : https://owncloud.org/
 Cozy : https://cozy.io/fr/
 Nimbus : http://cloudnimbus.org/
 Tonido : http://www.tonido.com/
 Cloud9 : https://c9.io/
 Emit Cloud : https://www.emitcloud.com/
2 — Il s'agit aussi de rechercher des approches de type cluster ou d'ordonnancement telles que :
 le projet de cluster de l'université de Glasgow : https://raspberrypicloud.wordpress.com/
 le projet de cluster de l'université de Southampton :
https://www.southampton.ac.uk/~sjc/raspberrypi/
 le projet de cluster de l'université de Boise : http://coen.boisestate.edu/ece/raspberry-pi/
 le projet de cluster de Richard S. Huntrods : http://huntrods.com/teaching/raspberrypi.html
 le projet de cluster de "Raspberry Pi Cluster" : http://raspberrywebserver.com/raspberrypicluster/
 Kubernetes : http://kubernetes.io/

Page : 4 / 30
3 — Enfin, il s'agit d'estimer la faisabilité d'implémenter sur un environnement Raspbian des solutions telles
que :
 Docker : https://www.docker.com/
 Hadoop : http://hadoop.apache.org/
 Node.js : http://nodejs.org/
 OpenStack : http://www.openstack.org/
2ème partie : maquette.
Il s'agit d’implémentation sur une plateforme basée sur des processeurs Raspberry Pi.
2. ETUDE THEORIQUE
2.1 ANALYSE ET COMPARAISON DES SOLUTIONS
Une analyse et comparaison a été amenée sur les différentes solutions ci-dessous :
 ownCloud : https://owncloud.org/
 logiciel libre offrant une plateforme de services de stockage et partage de fichiers et
d’applications diverses en ligne.
 Cozy : https://cozy.io/fr/
 Permet d’installer des applications tierces au sein d’une interface web auto hébergée.
 Nimbus : http://cloudnimbus.org/
 Cloud personnel sur raspberry PI
 Tonido : http://www.tonido.com/
 Solution de cloud personnel (Windows, Linux, Mac)
 Cloud9 : https://c9.io/
 Solution de développement en ligne
 Emit Cloud : https://www.emitcloud.com/
 Solution de stockage synchronisée en ligne
La comparaison a été faite sur les critères de sécurité suivants :
o Connexion à un annuaire pour l’authentification,
o Gestion des groupes pour le contrôle d’accès aux actifs
o Sécurisation de la connexion (HTTPS, SSL,..).
o Gestion de quotas.
o Gestion des logs
o Antivirus
o Firewall
.

Page : 5 / 30
Le tableau ci-dessous résume la comparaison :
2.2 APPROCHE DE TYPE CLUSTER
2.2.1 le projet de cluster de l'université de Glasgow
https://raspberrypicloud.wordpress.com/
C’est un projet construit par des étudiants et de chercheurs de l’université de Glasgow dans le but est de
faciliter l’enseignement et la recherche dans le domaine du Cloud Comptuting.
Le « PiCloud » est un Data center en modèle réduit construit autour d’un cluster de 56 Rasberry PI2.
Chaque PI pouvant contenir confortablement 3 VMs.
Des applis typiques incluent des serveurs Web comme « lighttpd » s’exécutant dans une instance de
conteneur. Ces applis peuvent migrer de conteneur au sein d’un PI ou entre 2 PI différents.
Cela consiste en l’exécution (gestion) des conteneurs Linux *LXC+ au-dessus de Raspian Linux, avec une
« substile » configuration réseau.
Docker a été configuré pour s’exécuter avec flanneld pour le mapping des adresses réseaux.
La version finale du PiCloud utilise « kubernetes » comme orchestrateurs de ressources pour gérer et
déployer les conteneurs.

Page : 6 / 30
La synchronisation des différents Pis du cluster est faite à l’aide de ntpd installé sur toutes les machines.
Conclusion
- Pas de management sécurisé.
- Pas de réplication
2.2.2 le projet de cluster de l'université de Southampton
https://www.southampton.ac.uk/~sjc/raspberrypi/
C’est un projet construit par ingénieurs de l’université de Southampton dans le but est d’exécuter des
calculs parallèles sur un cluster de 64 Rasberry PI2.
L’“Iridis-Pi » est un super computer basé sur 64 PI interconnectés.
L’application typique à réaliser est le calcul du nombre « pi » sur un clusters de PI fonctionnant en parallèle.
MPI (Message Passing Interface) au-dessus de Raspian Linux pour calcul parallèle.
MPI permet d'exploiter des ordinateurs distants ou multiprocesseur par passage de messages.
File système distribué
Le cluster a une capacité de stockage de 1TB distribué sur les 64 Pis.
Le système utilise HDFS de Hadoop qui est un système de fichiers distribué.
Ce système permettant l'abstraction de l'architecture physique de stockage, afin de manipuler un système
de fichiers distribué comme s'il s'agissait d'un disque dur unique.
Hadoop est configuré pour permettre une seule réplication par fichier.
Calcul distribué
Hadoop implémente MapReduce qui permet de manipuler de grandes quantités de données en les
distribuant dans un cluster de machines pour être traitées.

Page : 7 / 30
Configuration du cluster
1 PI : Hadoop noeud principal
1 PI : Gestion du fichier système exclusivement
1 PI : Gestion des ressources exclusivement
7 Pis : Spare
Les autres PI (59) : DataNode et NodeManager.
PI : Modèle B, 700Mhz, 512 Mb Ram, 32Go pour le stockage local.
400 MB swap file.
Les PI sont interconnectés par un lien Ethernet à 100Mb/s.
Conclusion
- Pas de management centralisé. Les 64 cartes SD doivent être préparées manuellement ou par
script.
- Utilisation d’outils « python » pour la configuration.
- Pas de sécurité.
- Pas des synchro.

Page : 8 / 30
2.2.3 le projet de cluster de l'université de Boise :
http://coen.boisestate.edu/ece/raspberry-pi/
C’est un projet construit par ingénieurs de l’université de Bois dans le but est d’exécuter des calculs
distribués (plutôt que parallèles) sur un cluster de 32 Rasberry PI2.
C’est un super computer basé sur 33 PI interconnectés (Beowulf)
L’application typique à réaliser est le calcul du nombre « pi » sur un cluster de PI fonctionnant en parallèle.
Architecture
MPI (Message Passing Interface) aus-dessus de Raspian Linux pour calcul parallèle.
Basé sur Raspbian «wheezy » (basé sur Ubuntu 11.10), “Hard-float” version.
MPI permet d'exploiter des ordinateurs distants ou multiprocesseur par passage de messages.
Le système utilize la solution QEMU pour la virtualisation. QEMU est une solution d'émulation complète
dite « hyperviseur de type 2 ». Le matériel vu par le système d'exploitation invité est émulé, et le
processeur lui-même peut être émulé.
Conclusion

Page : 9 / 30
- Pas de management centralisé. Les 33 cartes SD doivent être préparées manuellement.
- Pas de sécurité, pas de réplication.
- Pas de synchronisation.
2.2.4 le projet de cluster de Richard S. Huntrods:
http://huntrods.com/teaching/raspberrypi.html
C’est un projet construit par Huntrods en se basant sur l étude faite par l’université de Glasgow.
L’objectif est de créer un cluster de 10 Raspberry Pi
En se basant sur l étude faite par l’université Glasgow pour construire un supercomputer et des corrections
qui a ont été identifiés et faites, Huntrods a réalisé un cluster de 10 Pi en 3 phases :
- Premier cluster avec un seul Pi (nœud maitre configuré suivant la documentation d’université
Glasgow)
- Second cluster avec 4 Raspberry Pi (utilisation la configuration du nœud maitre)
- Cluster final avec 10 Pi (le cluster est connecté avec un routeur wifi).
Conclusion :
- Avantage : utilisation du cluster augmente la capacité.
2.2.5 le projet de cluster de "Raspberry Pi Cluster":
http://raspberrywebserver.com/raspberrypicluster/
L’étude a été faite par Raspberry Pi foundation pour évaler la performance du cluster. Lors de l’étude il y
avait des tests sur un seul et plusieurs Raspberry dans un cluster avec un nombre varié d’utilisateurs
concurrents. Le cluster mise en place a été utilisé comme un serveur web.
Le site http://raspberrywebserver.com/raspberrypicluster/ est hébergé sur un cluster Raspberry Pi. Les
noeuds sont des serveurs Web standard qui contiennent un contenu identique.
Après la construction du cluster Raspberry PI, plusieurs tests ont été mise en place pour étudier la
performance du cluster.
Test équilibreur de charge avec un seul Raspberry PI :
L’étude faite pour identifier comment un seul Raspberry Pi gère le trafic avec et sans équilibreur de charge.
Le graphe montre le temps de réponse moyenne pour un nombre varié des utilisateurs concurrents.

Page : 10 / 30
Test l’amélioration de la performance avec plus de nœuds.
L’étude faite en ajoutant des noeuds au cluster pour visualiser la performance. Le graphe figure le temps de
réponse min et max en augmentant le nombre des nœuds avec un nombre varié des concurrents.
Le graphe montre que le temps de réponse min n’a pas été amélioré après l’ajout des nœuds. Le temps de
réponse min est le même pour tous les nœuds du cluster, l’ajout des nœuds ne change rien.Cependant le
temps de réponse max a été diminué en ajoutant plus de nœuds (ex 4 nœuds) .
Conclusion :
- Avantage : utilisation du cluster augmente la capacité.
2.2.6 Kubernetes:
Kubernetes est un projet open source pour gérer un cluster de conteneurs Linux comme un système
unique, la gestion et l’exécution conteneurs Docker entre plusieurs hôtes.
Le projet sert à deux fins. Comment lancer des conteneurs à travers plusieurs hôtes Docker, équilibrer les
conteneurs à travers eux. Il ajoute également une API de plus haut niveau pour définir la façon dont les
conteneurs sont regroupés de manière logique, permettant de définir des pools de conteneurs,
l'équilibrage de charge et de l'affinité.
L'architecture Kubernetes est définie par un serveur maître et plusieurs noeuds. Les outils de ligne de
commande se connectent à l'extrémité de l'API dans le maître, qui gère et orchestre tous les noeuds , les
hôtes Docker qui reçoivent les instructions du maître et exécutent les conteneurs.
Master : Le serveur maître avec le service API Kubernetes .
• Minion : chacun des multiples Docker hôtes avec le service Kubelet qui reçoivent les ordres du maître, et
gère les conteneurs d'accueil en cours d’exécution.

Page : 11 / 30
• Pod : Définit une collection de récipients attachés ensemble qui sont déployés dans le même Minion, par
exemple une base de données et un conteneur de serveur Web.
• Replication controller: définit le nombre de pods ou conteneurs doivent être en cours d’exécution. Les
conteneurs sont prévus sur plusieurs minion.
• Service: Une définition qui permet la découverte de services / ports publiés par conteneurs, et des
communications proxy externes. Un service mappe les ports de conteneurs en cours d'exécution sur les
pods sur plusieurs minion à l'extérieur des ports accessible.
• kubecfg : ligne de commande qui se connecte au maître pour administrer Kubernetes

Page : 12 / 30
2.3 ETUDE DE FAISABILITÉ
Cette partie sera dédiée à l’étude de faisabilité pour 4 solutions ci-dessous :
- Docker : https://www.docker.com/
- Hadoop : http://hadoop.apache.org/
- Node.js : http://nodejs.org/
- OpenStack : http://www.openstack.org/
2.3.1 Docker
Docker est une plate-forme ouverte pour des développeurs et des administrateurs système pour
construire, expédier et exécuter des applications distribuées. Avec Docker, les développeurs peuvent
construire n'importe quelle application dans n'importe quelle langue utilisant n'importe quel toolchain. Les
applications "Dockerizées" sont complètement portables et peuvent fonctionner n'importe où. Une
application dockerizée contient l'application, son environnement, dépendances et même l'OS.
Docker fonctionne sous linux et Windows.
Qu’apporte vraiment Docker au Raspberry Pi ?
Le Raspberry peut couvrir 80% de nos besoins informatiques (NAS, routeur, serveurs vidéo, serveur
Minecraft…). Mais son succès induit également quelques contraintes :
 Limitation en ressources : un Raspberry ne peut exécuter qu’un ensemble limité de services ce qui
conduit à une prolifération.
 Exploitabilité : c’est une conséquence du point précédent car plus le nombre de Raspberry est
élevé, plus il est pénible de les gérer
Docker apporte une aide précieuse pour solutionner ces problèmes.
D’abord sur la limitation des ressources. Docker permet d’activer et de désactiver très simplement un
containeur avec une fonction start / stop qui peut même être exécutée via l’interface Shipyardmentionnée
ci-dessous.
Autre contribution de Docker pour aider à mieux gérer les ressources : certaines distributions comme
Alpine Linux sont résolument dédiées à limiter les tailles disque et mémoire nécessaires pour un service. Il
est ainsi fréquent de voir des containeurs d’une taille inférieure à 15 Mo ce qui permet en théorie d’en
mettre une cinquantaine sur un Raspberry.
Enfin Docker bénéficie d’un système de clustering (création de grappes de plusieurs Raspberry) appelé
Swarm qui permet de gérer un ensemble d’hôtes comme un pool de ressources unique. Vous voulez
rajouter un Raspberry à votre pool, rien de plus simple ! Il suffit de rajouter un noeud au cluster Swarm et
votre Raspberry vient s’ajouter à votre configuration existante.
Il est relativement facile d'installer docker sur le Rasberry PI. Si on utilise l’OS Arch Linux, Docker fait déjà
partie du manager de paquet.Autrement, il faut tout simplement utiliser la version netinstall dans laquelle
on va lui indiquer d’utiliser les dépôts jessie.

Page : 13 / 30
La configuration typique est la suivante :
Chaque hôte disposant d’un containeur Docker se connecte sur le maître du Cluster Swarm via VPN et
participe ensuite à l’ensemble du cluster.
L’outil Shipyard assure l’interface graphique pour un accès web distant.
Conclusion
Docker semble être la solution idéale si l’on souhaite utiliser des micro ordinateurs Raspberry Pi pour créer
une infrastructure Cloud en vue de tests ou d’apprentissage.
En effet, Docker exige beaucoup moins de ressources que si on utilise des machines virtuelles. Un process
Docker fonctionne directement sur l'hôte, avec des performances CPU quasi natives. L'utilisation de
Docker entraîne un leger « overhead » au niveau de la mémoire et du réseau.
Docker permettra alors de :
 déployer de manière centralisée les containeurs Docker sur les Raspberry
 arrêter, démarrer, se connecter en console, analyser chaque containeur
 vérifier si un Raspberry est toujours opérationnel
La version 1.9 de docker permet de gérer:
 la persistence aux niveaux des volumes,
 le networking (communication entre conteneurs de différentes machines)
 la gestion des plantages (redémarrage automatique du container)
Docker Swarm (docker 1.9) permet de déployer des conteneurs sur un cluster de Rasberry PI. Il peut être
sécurisé en lui associant des certificats TLS, ce qui permet alors :

Page : 14 / 30
 l'authentification du serveur ;
 la confidentialité des données échangées (ou session chiffrée) ;
 l'intégrité des données échangées ;
 de manière optionnelle, l'authentification du client (mais dans la réalité celle-ci est souvent assurée
par le serveur).
2.3.2 Hadoop
Hadoop est un Framework Java destine à faciliter la création d’applications distribuées et scalables,
permettant aux applications de travailler avec des milliers de noeuds et des pétaoctects de données.
Architecture:
Hadoop Distributed File System: HDFS
Une architecture de machines HDFS (aussi appelée cluster HDFS) repose sur deux types de composants
majeurs : NameNode ‘MasterNode’ , DataNode ‘WorkerNode’
MapReduce
MapReduce est un patron d'architecture de développement informatique, dans lequel sont effectués
des calculs parallèles, et souvent distribués, de données potentiellement très volumineuses, typiquement
supérieures en taille à 1 téraoctet.
Conclusion :
Hadoop peut être déployé sur un cluster Rasbperry pour traiter les calculs parallèles.
L’architecture à mettre en place est la suivante :

Page : 15 / 30
MPI (message Passing Interface) est une norme pour obtenir de bonnes performances sur des clusters à
mémoire distribuée.
2.3.3 Openstack
OpenStack est un ensemble de logiciels open source permettant de déployer des infrastructures de cloud
computing (infrastructure en tant que service). La technologie possède une architecture modulaire
composée de plusieurs projets corrélés (Nova, Swift, Glance...) qui permettent de contrôler les différentes
ressources des machines virtuelles telles que la puissance de calcul, le stockage ou encore le réseau
inhérents au centre de données sollicité.
Name Service Description
Horizon Dashboard A graphical user interface for managing
your cloud
Keystone Identity Authentication, authorization,
and OpenStack service
information
Nova Compute Spin up, manage, and terminate
virtual machines
Cinder Block Storage Disk volumes (that outlive an
instance) and snapshots of instances

Page : 16 / 30
Swift Object Storage Shared, replicated, redundant
storage for images, files, and
other media accessible via Hypertext
Transfer Protocol (HTTP)
Neutron Network Provide secure tenant networking
Glance Image Provide storage and access to VM
images and snapshots
Heat Orchestration Spin up groups of machines,
networks, and other resources
via templates
Designate DNS Create domains and records in
the DNS infrastructure
Ceilometer Telemetry Monitor resources usage across the
cloud
Trove Database Provide access to private tenant
databases
Ironic Bare Metal Spinup instances on physical hardware
Magnum Containers Manage containers within instances
Murano Application Deploy packaged applications
across multiple instances
Sahara Data Processin
Cluster
Provides a Hadoop or Spark cluster as a
service
Conclusion
Dans l'installation d'Openstack, l'hyper viseur utilisé par défaut est Kernel-based Virtual Machine (KVM)
pour la gestion de VMs. on peut l'échanger par ESXi, Xen, ou d'autres hyperviseurs, mais sur les
Raspberry Pi , le processeur (ARM) n'a pas les interruptions de virtualisation. Ce serait une mauvaise cible
pour la virtualisation avec les hyperviseurs (KVM, ESXi , Xen,...). En outre, il est moins performant en terme
de ressources (espace disque, mémoire et CPU). Cependant on pourrait utiliser pour les solutions Cloud
par conteneurisation (LXC, OpenVZ ou Docker).
2.3.4 NodeJs
Node.js offre un environnement côté serveur qui permet aussi d'utiliser le langage JavaScript pour générer
des pages web. En gros, il vient en remplacement de langages serveur comme PHP, Java EE, etc.
Node.js permet d'utiliser le langage JavaScript sur le serveur. Il nous permet donc de faire du JavaScript en
dehors du navigateur !

Page : 17 / 30
Node.js bénéficie de la puissance de JavaScript pour proposer une toute nouvelle façon de développer des
sites web dynamiques.
Avec Node.js, vous pouvez créer des applications rapides comme :
 Un serveur de Chat
 Un système d'upload très rapide
 ... et de façon générale n'importe quelle application qui doit répondre à de nombreuses requêtes
rapidement et efficacement, en temps réel
Si Node.js est rapide, cela tient principalement à deux choses : le moteur V8 et son fonctionnement non
bloquant.
Le moteur V8
Node.js utilise le moteur d'exécution ultrarapide V8 de Google Chrome. Ce moteur V8 avait fait beaucoup
parler de lui à la sortie de Google Chrome, car c'est un outil open source créé par Google qui analyse et
exécute du code JavaScript très rapidement.
Le modèle non bloquant
Comme JavaScript est un langage conçu autour de la notion d'évènement, Node.js a pu mettre en place une
architecture de code entièrement non bloquante.
Avantages
Dans les applications web, il est courant d'avoir des opérations longues et bloquantes comme :
 Les appels aux bases de données
 Les appels à des services web (ex : l'API de Twitter)

Page : 18 / 30
Node.js nous évite de perdre du temps en nous permettant de faire d'autres choses en attendant que les
actions longues soient terminées. socket.io est l'une des bibliothèques les plus prisées par ceux qui
développent avec Node.js. Elle permet de faire très simplement de la communication synchrone dans votre
application, c'est-à-dire de la communication en temps réel !
« The last but not the least ». Node.js permet de faire limitation Preemptive ce qui induit de la
robustesse: L’application ne s’ecroule pas quand la charge dépasse la capacité de traitement. Ce qui
correspond à un contrôle d’accès.
Ex de code :
var toobusy = require('toobusy');
app.use(function(req, res, next){
if(toobusy()) res.send(503,"I'm busy right now, sorry.");
else next();
});
Avantages
- Open Source , sous licence MIT
- Projet très actif et soutenu par de grands comptes ( Microsoft, Google )
- Un seul langage Frontend et Backend
- Obfuscationdes paramètres des requêtes (sécurité)
- Gestionnaire de modules performant et très simple
- Langage connu de tous , pas de réapprentissage ( ou juste une mise à niveau )
- Pas besoin d'une infra "Lourde" ( Apache ) pour développer l'appli
- Perfs au rendez-vous
- De très nombreux modules disponibles
- Mode Mono Thread basé sur la gestion d’événements ( comme Nginx ), d’où cette vélocité
- Simplicité de mise en oeuvre ( installation et tests )
- Simplicité de mise en place d'une répartition des traitements sur plusieurs nœuds ( distants ou non )
- Permet de mettre en place un serveur RealTime websocket.IO idéal pour les "applications web".
Inconvénients :
- Projet jeune et encore très changeant ( je trouve )
- Documentation peu clair
- Pas de communauté française ( en tt cas , je n'ai pas trouvé )

Page : 19 / 30
3. ARCHITECTURE: LE CLUSTER DE RASPBERRY PI2
3.1 ARCHITECTURE CIBLE
Après l’étude faite sur les différentes solutions, nous proposons l’architecture suivante à mettre en place
afin d’assurer la haute disponibilité et la persistance des données.
- Docker pour la containérisation
- Kubernetes comme solution d’orchestration
- Cluster Raspberry (master node, slave nodes)
- OwnCloud (authentification)
Remarque concernant la persistance des données : Docker peut créer un volume de données au niveau
de l’hôte (très pratique dans les clusters). Ce volume de données peut être un volume local ou un volume
NFS montésurles nœuds.
Architecture : disponibilité applicative

Page : 20 / 30
Architecture : disponibilité et persistance des données
Donc la deuxième architecture (3 nodes Raspberry et 02 Raspberry NFS), semble plus adaptée à notre
projet.
3.2 TESTSDE FAISABILITE TECHNIQUE EFFECTUES
Dans le but de valider la solution, nous avons effectué les tests suivants :
o Installation de Docker, Docker Swam sur Raspberry
o Installation et la configuration la solution Owncloud, Docker surRaspberry et sur VM ESXi (Centos)
o Installation et configuration Kubernetes , Docker sur Debian sur VM ESXi
3.3 PROBLEMES LIES AU CHOIX DE RASPBERRY PI POUR L’IMPLEMENTATION
Durant les tests de faisabilité techniques, nous avons rencontré les problèmes suivants :
o Peu d’images « trust » disponibles fonctionnant sur Raspberry, ce qui nécessite la création des
images (compilations)
o Peu de nœuds disponibles pour réaliser le cluster (3 PI2 seulement).
En conséquence, étant donné le temps disponible pour réaliser le projet, nous avons proposer de réaliser
l’implémentation du cluster sur une solution à base de VMs sur ESXi.La solution cible sera implémentée sur
6 VM (ESXi),
o 3 VM Centos (Master, 2 nodes)
o 2 VM Debian (NFS)
o 1 VM FreeBSD (Firewall)

Page : 21 / 30
4. SOLUTION CIBLE IMPLEMENTEE
Architecture technique

Page : 22 / 30
Use cases A : Indisponibilité d’un neoud NFS
But : tester la haute disponibilité des données.

Page : 23 / 30
Use cases B : Insdisponibilité d’un neoud « worker »
But : tester la haute disponibilité de l’applicatif.
5. CONCLUSION
L’étude et la mise en place de la solution ont montré qu’il était assez facile de mettre en place une solution
cloud sécurisée et hautement disponible avec des logiciels open sources disponibles dans la
communauté.Nous avons néanmoins fait les constats suivants:
 Simplicité du déploiement de Kubernetes et de docker sur le cloud public.
 Il faut 5 min par défaut pour répliquer les pods Kubernetes sur une autre nœud (impact sur
l’engagement de service : GTR)
 Problématique du stockage des images, volumes et historiques dans le dossier racine.

Page : 24 / 30
6. ANNEXE
6.1 SECURISATION DE SERVEUR
La première précaution consiste avant tout à se tenir informé :
il existe des mailing-lists spécialisées dans la sécurité, telles que Debian Security Announce et à procéder à
des mises à jour régulières (via apt-get upgrade par exemple).
1- Modifier le mot de passe root
2- Configuration SSH (port autre que 22)
3- Alerte login Root (envoie email automatique)
4- Enlever les services inutiles (non utilisés)
Ex:
/etc/init.d/portmap stop
/etc/init.d/nfs-common stop
update-rc.d -f portmap remove
update-rc.d -f nfs-common remove
update-rc.d -f inetd remove
apt-get remove portmap
apt-get remove ppp
5- Autorisations diverses
N'autorisons les compilateurs et installeurs que pour root (le numéro de version est à adapter selon la
fraîcheur de l'installation) :
chmod o-x /usr/bin/gcc-4.1
chmod o-x /usr/bin/make
chmod o-x /usr/bin/apt-get
chmod o-x /usr/bin/aptitude

Page : 25 / 30
chmod o-x /usr/bin/dpkg
6- Fail2ban
Fail2ban est un script surveillant les accès réseau grâce aux logs des serveurs.
Lorsqu'il détecte des erreurs d'authentification répétées, il prend des contre-mesures en bannissant
l'adresse IP grâce à iptables. Cela permet d'éviter nombre d'attaques bruteforce et/ou par dictionnaire.
=> en cas de necessité: iptables -A INPUT -s adresse_ip -j DROP
7- Protection contre les inondations de requêtes de connexions (`syn-flood') :
=> iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT
8- Installation d'un programme anti-rockits (Rkhunter)
=> Rootkit Hunter est un programme de détection de rootkits. envoie de notifications par e-mail si
détection.
9- IPtables / Netfilter (Firewall)
=> vi /etc/init.d/firewall
#!/bin/sh
# Vider les tables actuelles
iptables -t filter -F
# Vider les règles personnelles
iptables -t filter -X
# Interdire toute connexion entrante et sortante
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT DROP
# Ne pas casser les connexions etablies
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Page : 26 / 30
# Autoriser loopback
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT
# ICMP (Ping)
iptables -t filter -A INPUT -p icmp -j ACCEPT
iptables -t filter -A OUTPUT -p icmp -j ACCEPT
# SSH In
iptables -t filter -A INPUT -p tcp --dport 2222 -j ACCEPT
# SSH Out
iptables -t filter -A OUTPUT -p tcp --dport 2222 -j ACCEPT
# DNS In/Out
iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -t filter -A INPUT -p udp --dport 53 -j ACCEPT
# NTP Out
iptables -t filter -A OUTPUT -p udp --dport 123 -j ACCEPT
#Seveur web (Apache) :
# HTTP + HTTPS Out
# HTTP + HTTPS In

Page : 27 / 30
6.2 SCRIPTS D'ORCHASTRISATION ET D'AUTOMATISATION DE CONTENEURS DOCKER AVEC KUBERNETES
6.2.1 Créations un Pod nginx (serveur web fronted) :
apiVersion: v1
kind: ReplicationController
metadata:
name: nginx
labels:
name: nginx
spec:
replicas: 2
selector:
name: nginx
template:
metadata:
labels:
name: nginx
spec:
containers:
- name: nginx
image: sameersbn/owncloud:9.0.0-1
args: ["app:nginx"]
env:
- name: OWNCLOUD_URL
value: http://10.254.10.10
- name: OWNCLOUD_PHP_FPM_HOST
value: 10.254.10.30
- name: OWNCLOUD_PHP_FPM_PORT
value: "9000"
ports:
- name: http
containerPort: 80
protocol: TCP

Page : 28 / 30
6.2.2 Créations un Pod owncloud :
apiVersion: v1
kind: Pod
metadata:
name: owncloud
labels:
name: owncloud
spec:
containers:
- name: owncloud
image: sameersbn/owncloud:9.0.0-1
args: ["app:owncloud"]
env:
- name: FR
value: Europe/France
- name: DEBUG
value: "false"
- name: OWNCLOUD_URL
value: http://10.254.10.10
- name: OWNCLOUD_ADMIN_USER
value: admin
- name: OWNCLOUD_ADMIN_PASSWORD
value: password
- name: OWNCLOUD_UPLOAD_MAX_FILESIZE
value: 4G
- name: OWNCLOUD_MAX_FILE_UPLOADS
value: "20"

Page : 29 / 30
- name: DB_TYPE
value: pgsql
- name: DB_HOST
value: 10.254.10.20
- name: DB_PORT
value: "5432"
- name: DB_USER
value: owncloud
- name: DB_PASS
value: password
- name: DB_NAME
value: owncloud_db
ports:
- name: php-fpm
containerPort: 9000
protocol: TCP
volumeMounts:
- mountPath: /var/lib/owncloud
name: data
livenessProbe:
tcpSocket:
port: 9000
initialDelaySeconds: 5
timeoutSeconds: 1
volumes:
- name: data
hostPath:
path: /mnt/data/owncloud

Page : 30 / 30
6.2.3 Créations un Pod SQLPostgre (Data base :
apiVersion: v1
kind: Pod
metadata:
name: postgresql
labels:
name: postgresql
spec:
containers:
- name: postgresql
image: sameersbn/postgresql:9.4-17
env:
- name: DB_USER
value: owncloud
- name: DB_PASS
value: password
- name: DB_NAME
value: owncloud_db
ports:
- containerPort: 5432
protocol: TCP
volumeMounts:
- mountPath: /var/lib/postgresql
name: data
livenessProbe:
tcpSocket:
port: 5432
initialDelaySeconds: 30
timeoutSeconds: 5
volumes:
- name: data
hostPath:
path: /mnt/data/db

Cloud rasberryfinal

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (9)

Similar to Cloud rasberryfinal

Similar to Cloud rasberryfinal (20)

Cloud rasberryfinal