IMA4 2016/2017 P29 : Différence entre versions

De Wiki d'activités IMA
(Cahier des charges)
(Sources)
Ligne 178 : Ligne 178 :
 
==Sources==
 
==Sources==
  
* Differences entre MV et Conteneurs http://events.linuxfoundation.org/sites/events/files/slides/Container%20mechanics%20in%20rkt%20and%20Linux.pdf
+
* [http://events.linuxfoundation.org/sites/events/files/slides/Container%20mechanics%20in%20rkt%20and%20Linux.pdf PDF Differences entre MV et Conteneurs]
  
 
==Feuille d'heures==
 
==Feuille d'heures==

Version du 29 mars 2017 à 12:52

Présentation générale du projet

Ce projet s'inscrit dans le cadre d'une amélioration du système d'hébergement web.

Il s'agit principalement de réduire les ressources consommées tout en simplifiant l'administration de ces systèmes, pour cela, certains compromis doivent être fait


Premièrement il s'agit du choix entre les Machines Virtuelles et les Conteneurs.

Les machines virtuelles ont l'avantage en matière d'isolation par rapport aux conteneurs, en revanche elles monopolisent beaucoup de ressources car elles ont un OS embarqué et il est plus long de mettre à jours les fichiers sur une série de MV plutôt qu'une séries de Conteneurs sur une seule machine physique puisque les conteneurs ont une copie personnelle de l'OS de la machine fait à instant donné.

Une mise à jour pour une série de MV devraient se faire au cas par cas alors que pour les conteneurs il suffirait de mettre à jour la machine et re-envoyer les fichiers nécessaires dans les conteneurs


Cahier des charges

Contexte

Gestionnaire d'hébergement Web

Objectif du projet

Développer un environnement pour la gestion de sites Web utilisateurs isolés sur une machine physique ou sur un ensemble de machines physiques.

Description du projet

Le but ultime est de concevoir un système de création et de destruction de sites Web utilisateurs au travers d'une interface Web.

Ces sites Web doivent être isolés du système d'hébergement et entre eux. C'est à dire que les applications Web tournant sur ces sites ne doivent pas pouvoir voir les autres sites ou le système hébergeur.

Il est possible de réaliser ce type de système avec des machines virtuelles de type Xen ou des conteneurs de type Docker. Cependant l'utilisation de machine virtuelle impose que chaque écosystème entièrement isolé (chaque MV) impose un OS embarqué, ce qui malheureusement consomme de l'espace.


->Différences entre MVs et Conteneurs

[MV]

(+)Niveau d'isolation très élevé

(-)Pas de partage de ressource entre l'OS de la machine et ceux des machines virtuelles

(-)Nécessité d'embarquer un OS

(-)Lent au démarrage (temps de démarrer l'OS -> en minutes)


[Conteneur]

(+)Utilise l'OS de la machine physique -> partage de ressources simplifié et non-nécessité d'un OS embarqué

(+)Rapidité de lancement (exécution d'une commande -> en ms)

(-)Niveau d'isolation moindre (en comparant aux MVs)


Également, même les conteneurs Docker gaspillent des ressources. De plus il est assez difficile d'administrer finement les conteneurs Docker particulièrement en ce qui concerne le réseau. L'idée est d'utiliser un écosystème de gestion de conteneurs plus léger comme rkt ou runC.

->Caractéristiques de rkt et runC


Concevoir une architecture réseau pour vos conteneurs, écrire des scripts de création et de destruction de conteneurs, écrire une application Web permettant à un utilisateur de créer son site Web idéal.

Un site Web doit comporter un serveur Web (Apache2, Nginx, ...), éventuellement un module de scripting pour le serveur Web (php, python, rubis, ...) et éventuellement une base de données (mysql, postgres, ...). Le site Web doit aussi posséder une méthode de mise à jour des fichiers du site. Cet ensemble peut être implanté avec un ou plusieurs conteneurs.

Les sites Web doivent pouvoir être accédés d'Internet au travers d'une seule adresse IPv4 ou d'un seul réseau IPv6. Un système de redirection Web est donc indispensable.

Un utilitaire de réservation de sous-domaines DNS serait un plus.

Choix techniques

Comme indiqué dans la description du projet, Il s'agit de "développer un environnement pour la gestion de sites Web utilisateurs isolés sur une machine physique"

[Matériel]

J'ai donc choisi de développer cette interface web sur mon ordinateur portable personnel (OS: Ubuntu 16.04)

[Logiciel]

Choix du serveur HTTP: Apache2

Choix du module de script: PHP

Choix du type de base de données: mySQL

Conteneur: rkt

[Architecture]

   Hardware (PC portable)
   |
   |->Host OS (Ubuntu 16.04) -> super-super-user (root)
       |
       |->rkt (conteneur 1)
       |    |
       |    |-> Application (site web 1) -> super-user1
       |
       |->rkt (conteneur 2)
       |    |
       |    |-> Application (site web 2) -> super-user2
       |
       |->rkt (conteneur 3)
       |   |
       |   |-> Application (site web 3) -> super-user3
       |
       |->rkt (....)
       |   |
       |   |-> Application (....)
       |

Bien évidemment, on s'assurera que le super-userN n'a pas accès aux données de l'application du super-userK (N différent de K). En revanche, root a accès à toutes les applications (lecture et écriture), peut en ajouter ou en supprimer.

Calendrier prévisionnel

Liste des tâches à effectuer

Installation mise en place d'un conteneur

[OK]:Installer rkt et mettre en place un conteneur test

[à venir]:Mettre en place un conteneur pour un site

Configuration de base du conteneur

[Installé]:Installer Apache2 et configurer la page principale interface

[Installé]:Installer et configurer PHP et mysql pour la gestion des comptes admin/utilisateurs

[En cours]:Créer les pages de l'interface administrative

[.]:Définir comment y avoir accès via un navigateur lambda

L'interface admin globale

[.]:Permettre la création de conteneurs

[.]:Permettre l'attribution de droits sur un site à un compte donné

[.]:Écriture et test du script de suppression par le panel admin principal

[.]:Écriture et test du script de création d'un site de base par le panel admin principal -> Permettre la création et la configuration automatique d'un site (idée potentielle: à partir d'un clonage de configuration)

L'interface d'un site donné

[.]:Permettre au sous-admin (compte désigné admin par l'admin général (panel admin global)) de se connecter à une interface admin lié au site concerné

[.]:Permettre la modification des pages du site via le panel sous-admin

Calendrier

Jeudi 15/12/2016 / 14:00-17:00 / 3H

Documentation, installation, configuration, rédaction du CdC

Mercredi 25/01/2017 / 14:00-18:00 / 4H

Documentation, rectification du CdC

Mercredi 08/03/2017 / 14:00-18:00 / 4H

+ Tests de lancement de conteneurs (pods) sous rkt réalisés avec succès grâce aux images test proposées dans les exemples.

 -> prévision d'un script d'automatisation afin de faciliter la tâche

+ Début de la création des scripts de création de site web pour les rassembler dans une image .aci exploitable par rkt

 -> revoir la théorie et les documentations avant de tester les scripts
Mercredi 15/03/2017 / 14:00-18:00 / 4H

+ Acbuild, fonctionnalité à présent opérationnelle et testée (images à venir) permet de créer des .ACI (App Container Image) à partir d'applications , personnellement créées, directement compatibles avec rkt qui 'semble' les exécuter directement dans les conteneurs (pods dont je cherche encore à vérifier le fonctionnement)

-> effectuer des tests pour vérifier le niveau d'isolation attendu

+ Début de la recherche concernant la redirection web (ipv4 / ipv6) et la réservation de sous-domaines DNS

Samedi 18/03/2017 & Dimanche 19/03/17

+ Mise en place des scripts shell pour créer des applications web lancées dans des conteneurs distincts (exécutables par root uniquement)

+ Début du travail sur l'interface root

Mercredi 22/03/2017 / 14:00-18:00 / 4H

+ Recherches sur comment installer Apache2/PHP dans un conteneur et comment les rendre utilisable

-> erreur sur la commande "run" de type "Discovery Failed" lors de l'ajout d'apache2 via acbuild (résolution en cours)
[ >>> $ sudo acbuild run -- apk add apache2 ]

-> solution trouvée en activant la wifi sur mon téléphone, le proxy de l'école bloque le téléchargement des paquets

Sources

Feuille d'heures

Tâche Prélude Heures Semaine 1 Heures Semaine 2 Heures Semaine 3 Heures Semaine 4 Heures vacances Heures Semaine 5 Heures Semaine 6 Heures Semaine 7 Heures Semaine 8 Heures Semaine 9 Heures Semaine 10 Total
01) Définition/Mise-à-jour du cahier des charges P: 4h S1: 2h S2: 3h S3: S4: V: S5: S6: 1h S7: 3H ; S8: 30min S9: S10: T:
02) Installation et configuration des modules P: S1: 2h S2: 1h S3: 4h S4: 2h V: 3h S5: 1h S6: 2h S7:  ; 1h S8: 2h S9: S10: T:
03) Mise en place de conteneurs (manuellement) P: S1: 1H (tentative) S2: S3: S4: V: 5h S5: S6: 4h S7:  ; 5h S8: 1h S9: S10: T:
04) Mise en place de conteneurs (automatisée via script lancé par un panel ou une commande éxécutée par root) P: S1: S2: S3: S4: V: S5: S6: S7: 3h ; 2h S8: 30min S9: S10: T:
05) Vérification des droits attribués aux super-users (isolation) P: S1: S2: S3: S4: V: S5: S6: S7:  ; 1h S8: S9: S10: T:
06) Scripts de création de site avec configuration de base P: S1: S2: S3: S4: V: S5: S6: S7: 2h (début) ; S8: S9: S10: T:
07) Scripts de suppression de site avec back-up éventuel P: S1: S2: S3: S4: V: S5: S6: S7: ; 30min S8: S9: S10: T:
08) Développement de l'interface dédiée à root pour création et suppression P: S1: S2: S3: S4: V: S5: S6: S7:  ; 2h S8: S9: S10: T:
09) Méthode de mise à jour des fichier pour un site donné P: S1: S2: S3: S4: V: S5: S6: S7: S8: S9: S10: T:
10) Système de redirection web (1 IPv4 ou 1 reaseau IPv6) P: S1: S2: S3: S4: V: S5: S6: S7: S8: S9: S10: T:
11) bonus: utilitaire de réservation de sous-domaines DNS P: S1: S2: S3: S4: V: S5: S6: S7: 1h ; S8: S9: S10: T: