IMA4 2016/2017 P29

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 niveau d'isolation

Les machines virtuelles (ex: Xen) 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 opèrent à partir l'OS de la machine

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

Deuxièmement le type de conteneur

En effet, même parmi les conteneurs, ceux de type 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.

Dans la suite on présentera principalement rkt (choix du cahier des charges)

Une fois les conteneurs créés il est nécessaire de les rendre accessible via le réseau afin de pouvoir réaliser les sites web, fort heureusement, rkt intègre les plugins (ou ont été développés) permettant de réaliser le networking l'isolation des fichiers pour les conteneurs entre eux mais laissant l'hôte (root de la machine physique) maître de la totalité des fichiers.

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.

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

[OK]:Mettre en place un conteneur pour un site

[En cours]:Le rendre accessible via le navigateur

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 le navigateur du système

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

Bilan

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 (source [2]) , 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

Tests effectué avec des programmes à boucle infinie pour vérifier que les conteneurs actifs ont bien une adresse et tentative d'interaction

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

Mercredi 29/03/2017 / 12:00-17:30 / 5H30

Importante remise à jour du wiki avec ajout de captures

Installation de CNI (Container Network Interface : cf source [3]) et tests d'utilisation

Rapport

Média:P29_Rapport_DUPONT_Jade.pdf

Sources

[1] PDF Differences entre MV et Conteneurs

[2] ACBuild - a build tool for ACIs

[3] Container Network Interface - networking for Linux containers

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: 3h	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: 1h	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: 30min	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: 30min	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: 30min	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: