P24 Nuage pour sites Web : Différence entre versions

Version du 8 février 2016 à 15:16

Sommaire

1 Cahier des charges
- 1.1 Présentation générale du projet
2 Avancement du Projet
3 Fichiers Rendus
4 Liens externes

Cahier des charges

Présentation générale du projet

Contexte

Objectif du projet

Installer une infrastructure infonuagique pour la création de sites Web école.

Description du projet

Le but est d'installer une infrastructure infonuagique sur des machines de la plate-forme informatique permettant la création aisé d'un site Web pour un usager de l'école.

La couche de supervision peut être openstack installé avec un noeud contrôleur et un noeud réseau dans deux machines virtuelles.

La solution de virtualisation sera à base de conteneurs pour limiter la consommation mémoire et CPU. Vous pouvez commencer par étudier la solution Docker.

Une image de processus serveur Web avec une configuration standard (incluant PHP) doit être fournie.

L'architecture proposée ne doit consommer qu'une adresse IPv4 routée pour l'ensemble des sites Web et permettre des accès IPv4 et IPv6 et implanter HTTP comme HTTPS. La configuration du nom du site Web doit être très facile.

Avancement du Projet

Semaine 1 (14/09/2015)

Entretien avec M.Redon
Recherches sur la virtualisation, LXC, Docker et Openstack
Analyse de la portée du projet : 900 sites existant au total, moins de 200 qui sont actifs
Aucun matériel a acheter !

Semaine 2 (21/09/2015)

Premiers essais avec Docker
- Création d'un processus isolé contenant linux
- Test de sauvegarde et manipulation des images générées

Semaine 3 (28/09/2015)

Contact avec un intervenant extérieur : Alexandre chojnacki
Suite des tests avec Docker
Début des recherches sur le serveur Apache
Familiarisation avec les Dockerfiles

Semaine 4 (05/10/2015)

Suite des recherches et tests sur le serveur Apache
Architecture réseau des containers de docker
- La première interface virtuelle "docker0" qui reçoit toutes les adresses en 172.17.0.0/16
- Les paquets sont envoyés vers l'interface de l'adresse en question "veth7fe8a26"
- Cette deuxième interface envoie les paquets vers l'interface "eth0" du container
Pause des recherches sur OpenStack
- A confirmer avec A.Chojnacki, mais Docker peut suffire pour notre utilisation

Semaine 5 (12/10/2015)

Utilisation d'OpenStack qui semble ne pas être indispensable --> on met cet outil de côté
Recherches sur la para virtualisation et l'utilisation de l'hyperviseur xen.
Idée : lancer des dockers dans des machines virtuelles xen (à méditer)
DELL poweredge 2950 (specs)
- Réparation d'un dissipateur (Images à venir)
- Machine à priori opérationnel, attente de plus d'infos pour sa mise en route (où, comment...)

Semaine 6 (19/10/2015)

Résultat des discussion avec A.Chojnacki

Adoption du modèle suivant (article intéressant)

hardware > hypervisor > Docker host > container

Machine DELL opérationnelle mais en attente (anciennes données encore dessus)
Prise en main de xen

Semaine 7 (26/10/2015)

How a VM works

How docker works

Semaine 8 (02/11/2015)

Remise en question du modèle précédent : lourdeur inutiles. Juste Docker suffit.
Installation de Debian (Jessie) sur la machine Dell PowerEdge
Installation des services utiles (ssh, Docker)

Semaine 9 (09/11/2015)

Mise en place du serveur, opérationnel.

172.26.64.13

Création des 10 VM qui nous seront nécessaires

VM XEN
	IP addr
jinx	172.26.79.230
thresh	172.26.79.231
fizz	172.26.79.232
nidalee	172.26.79.233
vayne	172.26.79.234
teemo	172.26.79.235
rengar	172.26.79.236
ezreal	172.26.79.237
ziggs	172.26.79.238
shaco	172.26.79.239

Semaine 10 (16/11/2015)

Comment fonctionne notre système ?

Notre serveur rift en 172.26.64.13 Sur ce serveur :

Une petite dizaine de machines virtuelles xen dans la fourchette 172.26.79.230 à 172.26.79.239
Bridge Summoner : interface eth0 du serveur avec les interfaces virtuelles (vif) de nos machines xen

Sur chacune des machines :

Les vif du serveur correspondent à chacune des eth0 des machines, qui sont configurées de cette façon :

address 172.26.79.230 
netmask 255.255.240.0 
gateway 172.26.79.254

On configure la VM pour qu'elle ait accès à internet et puisse apt-get
On active le ssh pour ne plus être obligé d'utiliser xl console
On installe docker-engine et docker.io
A l'installation de docker, une interface docker0 est crée avec comme IP 172.17.0.1
Lorsqu'on va créer un conteneur, une nouvelle interface sera créée de la forme veth54205179. Pour le premier conteneur créé, son adresse IP sera 172.17.0.2. On a donc un sous réseau 172.17.0.0/16 qui nous permet donc de potentiellement donner 65 000 IP à 65 000 conteneurs différents.

(de 172.17.0.2 à 172.17.255.254) --> 2¹⁶

Semaine 11 (23/11/2015)

Semaine 12 (30/11/2015)

On regarde combien de conteneurs au maximul peuvent être créés sur un Vm pour un mémoire donnée :

Memory	Containers
256 Mo	30
512 Mo	180
2048 Mo	600

Sachant que notre serveur possède 4Go de mémoire, nous optons pour l'instant pour 7 VM d'une mémoire de 512 Mo chacune. Nous pourrons ainsi créer environ 150 conteneurs docker par VM.

Suite à l'entretien avec Mr. Redon du 1er décembre :

Maquette réseau (disponible en lien externe)
Mettre à plat : Bridger les interface des conteneurs (veth......) avec eth0 (fait)
Pour 10 VM : 1 associations, 3 enseignants, 6 étudiants séparés dans 3 VLAN différents (cf schéma)
Se renseigner sur le reverse DNS pour que les requêtes soient redirigées vers les bon conteneurs.

Semaine 13 (07/12/2015)

Architecture réseau de notre projet

Objectif pour semaine prochaine : Maquette du site (Wireframe)

Semaine 14 (14/12/2015)

Préparation pour soutenance

Maquette du site web de notre projet

Semaine 15 (04/01/2016)

Semaine 16 (11/01/2016)

Nous réunissons ici des informations importantes qui seront utiles pour la confection des scripts par la suite.

Création d'un bridge

Pour changer le réseau par défaut de Docker, on doit dans un premier temps détruire toute la configuration existante. En effet, bien que le bridge par défaut soit paramétrable entièrement, il est recommandé pour notre utilisation de créer et gérer son propre bridge. "While they are still available to you as techniques, it is better to avoid them and define your own bridge networks instead." [1]

service docker stop
ip link set docker0 down
brctl delbr docker0
iptables -t nat -F POSTROUTING

On peut ensuite créer un nouveau bridge qui correspond à nos attentes.

brctl addbr dockerBridge
ip addr add 10.0.0.1/8 dev dockerBridge
ip link set dev dockerBridge up
systemctl daemon-reload
service docker restart

On peut alors vérifier que notre configuration a bien été prise en compte avec les commandes suivantes :

ifconfig
iptables -t nat -L -n

Configuration Docker

Quelques informations pour la configuration réseau

vim /lib/systemd/system/docker.service

Il faut indiquer à Docker qu'il faut regarder le fichier de configuration /etc/default/docker. En effet, docker ne gère pas les distributions linux basée sur systemd, comme la Debian 8 que nous utilisons. Cette erreur, particulièrement difficile à détecter, ne survient pas sous Ubuntu ou d'autres distributions utilisant upstart ou SysVInit. Pour contourner le problème, il faut effectuer les modifications suivantes :

EnvironmentFile=-/etc/default/docker
ExecStart=/usr/bin/docker -d $DOCKER_OPTS -H fd://

On modifie ensuite le fichier de configuration référencé, pour y ajouter la ligne suivante :

echo 'DOCKER_OPTS="-b=dockerBridge"' >> /etc/default/docker

Semaine 17 (18/01/2016)

Exploration du dossier : /var/lib/docker/ qui contient :
- Les fichiers de configurations servant à créer un conteneur
- Les volumes servant de racine pour les conteneurs
Résolution d'un problème au niveau du réseau de la machine Xen
Réseau en 10.0.0.0/8 pleinement fonctionnel

Voici la configuration réseau d'une machine xen :

# The loopback network interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual
 up ip link set eth0 up
 down ip link set eth0 down

# The primary network interface
auto br0
iface br0 inet static
 bridge_ports eth0
 address 10.2.0.1
 netmask 255.0.0.0
 gateway 10.0.0.1

Ce masque de sous-réseau pose un autre problème. Lors de sa création, un conteneur choisi une adresse dans le réseau du bridge indiqué en ayant préalablement vérifier sa disponibilité. Voici la fonction qu'utilise Docker pour vérifier si une adresse IP a déja été allouée. Plus précisément, voici la fonction Go qui permet cela. Le problème est que le premier conteneur va prendre une adresse 10.0.0.3 au lieu de 10.2.0.2. Heureusement, on peut simuler un réseau plus contraignant en spécifiant à la création un masque sous-réseau plus petit.

docker run -ti --fixed-cidr=10.2.0.0/16 --name dock1 /bin/bash

Semaine 18 (25/01/2016)

On essaie durant cette semaine de donner accès à internet à nos conteneurs pour pouvoir y installer ssh. En parallèle nous essayons d'utiliser le système de reverse ssh pour pouvoir se connecter à un conteneur en ssh.

Nous avons également créé l'interface web disponible à l'adresse suivante :

https://zegbicho.lol/Projet/

Utilisation de la commande iptables pour établir une mascarade.

iptables -t nat -A POSTROUTING -s 10.0.0.0/8 -j MASQUERADE

On ajoute ensuite une interface tap avec une adresse dans le sous réseau 172.26.0.0/20. Cette interface permet la mascarade sans risquer de perdre la liaison ssh sur eth0. De plus, l'interface tap est nécessaire plutôt qu'un tunnel car la liaison se fait sur la couche OSI de niveau 2 (ethernet). Cette configuration nous permet aussi d'autoriser au conteneur l'accès à internet, ce qui nous débloque pour la suite.

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  10.0.0.0/8           anywhere

On a accès à internet depuis la machine virtuelle Xen :

root@jinx:~# ping 193.48.57.48
PING 193.48.57.48 (193.48.57.48) 56(84) bytes of data.
64 bytes from 193.48.57.48: icmp_seq=1 ttl=62 time=0.538 ms
64 bytes from 193.48.57.48: icmp_seq=2 ttl=62 time=0.542 ms

Et de même sur un conteneur Docker :

root@5c909f8a8617:/# ping 193.48.57.48
PING 193.48.57.48 (193.48.57.48): 56 data bytes
64 bytes from 193.48.57.48: icmp_seq=0 ttl=62 time=0.501 ms
92 bytes from 10.2.0.1: Redirect Host
64 bytes from 193.48.57.48: icmp_seq=1 ttl=62 time=1.542 ms
92 bytes from 10.2.0.1: Redirect Host

Semaine 19 (01/02/2016)

On vérifie tout d'abord la configuration du démon (/etc/default/docker) fixed-cidr donne la plage d'adresse à utiliser lors de la création d'un conteneur br0 est notre bridge configuré manuellement

DOCKER_OPTS="-b=br0 --fixed-cidr=10.2.0.0/16 --ip-forward=true"

Voici maintenant les commandes à exécuter afin de lancer un conteneur avec un serveur web nginx fonctionnel à partir d'une image debian :

# Création d'un conteneur avec un serveur web fonctionnel
# Jérémie Denéchaud - Thibaut Scholaert
# 02/02/2016
 
# On récupère l'image de debian (Jessie, 8.3)
 docker pull debian

# On construit une image personnalisée à partir de Debian
# Les instructions suivies sont dans ./Dockerfile
docker build -t monserveur .

# On crée une instance de cette image
# -ti permet de lier les stdin et stdout
# bash est la commande à executer lors de la création
 docker run -ti --name dock0 --hostname jdenecha monserveur

Voici le contenu du fichier de configuration Dockerfile :

# Jeremie Denechaud - Thibaut Scholaert
# Example de Dockerfile

FROM debian
RUN apt-get update -y; apt-get upgrade -y
RUN apt-get install -y nginx ssh

RUN echo "/usr/sbin/service nginx start" >> /etc/bash.bashrc
RUN echo "/usr/sbin/service ssh start" >> /etc/bash.bashrc

#ADD id_rsa /root/.ssh/id_rsa
#RUN chmod 700 /root/.ssh/id_rsa

COPY template /var/www/html

Suite à une erreur, une réinstallation complète du serveur physique (rift) est nécessaire. La réinstallation a duré beaucoup moins de temps que la première fois dû à une meilleure connaissance du système. Nous avions également mis de coté les scripts résumant les installations essentiels pour une VM xen.

@@ Ligne 315 : / Ligne 315 : @@
   COPY template /var/www/html
-Création d'une base de données pour gérer les connexions aux bons conteneurs. Chaque utilisateurs ('''identifiant polytech''') qui créée un site se voit associé le '''nom de domaine''' qu'il a choisi, le '''vlan''' auquel il appartient et enfin '''l'adresse''' fixe du conteneur associé.
+Suite à une erreur, une réinstallation complète du serveur physique (''rift) est nécessaire. La réinstallation a duré beaucoup moins de temps que la première fois dû à une meilleure connaissance du système. Nous avions également mis de coté les scripts résumant les installations essentiels pour une VM xen.
 ===Semaine 20 (08/02/2016)===