IMA4 2016/2017 P29 : Différence entre versions
(→Feuille d'heures) |
(→Calendrier) |
||
Ligne 154 : | Ligne 154 : | ||
+ Début de la recherche concernant la redirection web (ipv4 / ipv6) et la réservation de sous-domaines DNS | + 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 | ||
+ | |||
====Prévisionnel==== | ====Prévisionnel==== | ||
Version du 19 mars 2017 à 23:03
Sommaire
Cahier des charges
Présentation générale du projet
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
Prévisionnel
J'ai pris en note les observations vis-à-vis de mon wiki, je tacherai à l'avenir :
- De revoir la rédaction et de mettre à jour le wiki plus régulièrement (car jusqu'à présent les informations étaient sur un gdoc brouillon, en raison d'un manque de temps personnel et de matière (j'ai installé... , j'ai testé.. mais ça plante pour X raison) pour présenter au propre)
- D'ajouter un maximum de captures d'écran/vidéo sur les tests effectués
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: | 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: | 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: | 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: | 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: |