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

Projet Sécurité Cloud 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.

AN. : 2015/2016

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/

AN. : 2015/2016

3 — Enfin, il s'agit d'estimer la faisabilité d'implémenter sur un environnement Raspbian des solutions telles

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

AN. : 2015/2016

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.

AN. : 2015/2016

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.

AN. : 2015/2016

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.

AN. : 2015/2016

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

AN. : 2015/2016

- 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.

AN. : 2015/2016

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.

AN. : 2015/2016

• 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

AN. : 2015/2016

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.

AN. : 2015/2016

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 :

AN. : 2015/2016

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 :

AN. : 2015/2016

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

AN. : 2015/2016

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

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 !

AN. : 2015/2016

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)

AN. : 2015/2016

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é )

AN. : 2015/2016

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

AN. : 2015/2016

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)

AN. : 2015/2016

4. SOLUTION CIBLE IMPLEMENTEE

Architecture technique

AN. : 2015/2016

Use cases A : Indisponibilité d’un neoud NFS

But : tester la haute disponibilité des données.

AN. : 2015/2016

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.

AN. : 2015/2016

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)

/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

AN. : 2015/2016

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

AN. : 2015/2016

# 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

AN. : 2015/2016

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:

labels:

replicas: 2

selector:

template:

metadata:

labels:

containers:

- name: nginx

image: sameersbn/owncloud:9.0.0-1

args: ["app:nginx"]

- 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

AN. : 2015/2016

6.2.2 Créations un Pod owncloud :

apiVersion: v1

kind: Pod

metadata:

labels:

containers:

- name: owncloud

image: sameersbn/owncloud:9.0.0-1

args: ["app:owncloud"]

- 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"

AN. : 2015/2016

- 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

livenessProbe:

tcpSocket:

port: 9000

initialDelaySeconds: 5

timeoutSeconds: 1

volumes:

- name: data

hostPath:

path: /mnt/data/owncloud

AN. : 2015/2016

6.2.3 Créations un Pod SQLPostgre (Data base :

apiVersion: v1

kind: Pod

metadata:

labels:

containers:

- name: postgresql

image: sameersbn/postgresql:9.4-17

- 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

livenessProbe:

tcpSocket:

port: 5432

initialDelaySeconds: 30

timeoutSeconds: 5

volumes:

- name: data

hostPath:

path: /mnt/data/db

Cloud rasberryfinal

Technology

Transcript of Cloud rasberryfinal

Bases de Données Cloud « Cloud Databases »

Cloud et Sécurité©curité-V0... · cloud privé cloud communautaire cloud bancaire ? cloud ? CNIS : Cloud & Sécurit é 1 ...

Cloud Privé, Cloud Public...poursquoi choisir ?

Solutions de Cloud Privé Microsoftdownload.microsoft.com/documents/France/cloud/Livre... · chapitre « Avantages économiques du Cloud privé » de ce livre blanc. Les solutions

Le Guide du Cloud : les bases du Cloud Computing

biberons Cloud

Stockage Cloud - JRES · Cloud partout… Cloud storage, grid storage et les autres Distribué, réparti… (fichier) != clusterisé (block) Exemples d’architecture Single namespace:

2011.06.24 - Forum des Partenaires du Cloud IBM - 5 Modèles de Business Cloud - Club Cloud des Partenaires - Loic Simon

Cloud Array : Exploitez le stockage Cloud en toute simplicité

Cloud jihen

AFDIT I Les contrats Cloud : des contrats clés en main ... oct 2015/M Coulaud Contrats cloud.pdf · 3 familles de Cloud Computing coexistent : Le Cloud privé : un Cloud réservé

Guide de déploiement d'Horizon Cloud - VMware Horizon Cloud … · 2020. 7. 31. · Intégration à Horizon Cloud pour Microsoft Azure, Horizon sur site et Horizon on VMware Cloud

My Cloud™ Home & My Cloud™ Home Duo Personal Cloud … · Cloud™ Home ou sur MyCloud.com. Partage rapide et facile — Rassemblez tous vos meilleurs souvenirs et moments dans

Cloud presentation

Virtualisation, Cloud, Devops, Cloud Computing · Virtualisation, Cloud, Devops, Cloud Computing Depuis presque dix ans, la croissance du Cloud Computing est impressionnante et ne

Presentation cloud

Virtualisation, Cloud, Devops, Cloud Computing · Virtualisation, Cloud, Devops, Cloud Computing Précurseur dans le domaine de formation Cloud Computing, ORSYS propose des séminaires,

NetApp Hybrid Cloud Infrastructure...CLOUD • Deploy primary workloads to the Cloud • Gain visibility into a dynamic hybrid cloud infrastructure • Extend and migrate secondary

Cloud computing

Cloud Privé, Cloud Public, pourquoi choisir?