IMA4 2016/2017 ECV1 : Différence entre versions

De Wiki de Projets IMA
(→‎Étapes)
 
(3 révisions intermédiaires par le même utilisateur non affichées)
Ligne 14 : Ligne 14 :
 
# Il est d'abord demandé de mettre en oeuvre le WIki de type mediawiki sur le PC : recopier le sujet et préparer la structure pour rendre compte du travail, la sécurisation HTTPS n'est pas nécessaire vu que le wiki ne sera accédé qu'en local.
 
# Il est d'abord demandé de mettre en oeuvre le WIki de type mediawiki sur le PC : recopier le sujet et préparer la structure pour rendre compte du travail, la sécurisation HTTPS n'est pas nécessaire vu que le wiki ne sera accédé qu'en local.
 
# La gestion des conteneurs se fera en utilisant la technologie runC. IL faut donc commencer par créer un système de fichier racine pour les conteneurs. L'utilitaire <code>umoci</code> sera utilisé (option <code>new</code>).
 
# La gestion des conteneurs se fera en utilisant la technologie runC. IL faut donc commencer par créer un système de fichier racine pour les conteneurs. L'utilitaire <code>umoci</code> sera utilisé (option <code>new</code>).
−
# Les conteneurs doivent être accessibles en réseau. IL faudra utiliser <code>ip nets</code> pour créer des interfaces virtuelles dans les conteneurs dont les pairs se trouveront dans un commutateur virtuel (utilitaire <code>brctl</code>) de l'OS principal.
+
# Les conteneurs doivent être accessibles en réseau. Il faudra utiliser <code>ip nets</code> pour créer des interfaces virtuelles dans les conteneurs dont les pairs se trouveront dans un commutateur virtuel (utilitaire <code>brctl</code>) de l'OS principal.
 
# Il faudra explorer des solutions pour ajouter aux systèmes de fichier racines créés précédement le nécessaire pour faire tourner le serveur Web <code>apache2</code>.
 
# Il faudra explorer des solutions pour ajouter aux systèmes de fichier racines créés précédement le nécessaire pour faire tourner le serveur Web <code>apache2</code>.
 
# il ne reste plus qu'à configurer le serveur DNS local à l'OS principal pour donner un nom aux différents sites Web (partons sur 3 serveurs Web distincts redondés d'un facteur 2). Il est alors possible de configurer l'<code>apache2</code> de l'OS principal pour agir comme mandataire inverse et équilibreur de charge.
 
# il ne reste plus qu'à configurer le serveur DNS local à l'OS principal pour donner un nom aux différents sites Web (partons sur 3 serveurs Web distincts redondés d'un facteur 2). Il est alors possible de configurer l'<code>apache2</code> de l'OS principal pour agir comme mandataire inverse et équilibreur de charge.
Ligne 52 : Ligne 52 :
 
* Lors de la création de l'image, un fichier de configuration est fabriqué, ce n'est donc pas la peine d'en générer un autre par la commande <code>runc spec</code>. Par contre il faut préciser le chemin du répertoire de l'image au lancement du conteneur : <code>runc create -b newbundle nomduconteneur</code>.
 
* Lors de la création de l'image, un fichier de configuration est fabriqué, ce n'est donc pas la peine d'en générer un autre par la commande <code>runc spec</code>. Par contre il faut préciser le chemin du répertoire de l'image au lancement du conteneur : <code>runc create -b newbundle nomduconteneur</code>.
  
−
== Réseau pour le conteneur ===
+
== Réseau pour le conteneur ==
  
 
Pour la configuration du réseau dans le conteneur. Il faut d'abord créer une interface virtuelle :
 
Pour la configuration du réseau dans le conteneur. Il faut d'abord créer une interface virtuelle :
Ligne 69 : Ligne 69 :
 
Détailler les étapes de la création de l'image OCI avec la commande <code>umoci</code>.
 
Détailler les étapes de la création de l'image OCI avec la commande <code>umoci</code>.
  
−
root@Panga:~/mycontainer# umoci init --layout newimage
+
root@Panga:~/mycontainer# umoci init --layout newimage
 +
root@Panga:~/mycontainer# umoci new --image newimage:newtag
  
−
root@Panga:~/mycontainer# umoci create --image newimage:newtag
+
<code>umoci init</code> permet de créer une image OCI sans tag ou blobs à l'intérieur. Ensuite, <code>unmoci new</code> permet de créer une image OCI avec un tag que l'on pourra modifier comme on le souhaite par la suite.
  
−
umoci init permet de créer une image OCI sans tag ou blobs à l'intérieur. Ensuite, unmoci new permet de créer une image OCI avec un tag que l'on pourra modifier comme on le souhaite par la suite.
+
On utilisant la commande suivante, on génère un dossier <code>newbundle</code>, qui contient le bon fichier <code>config.json</code> de l'image OCI de nom <code>newimage</code>.
  
−
REX> Quel est le rapport entre mycontainer/newimage et le newbundle de la section suivante ?
+
root@Panga:~/mycontainer# umoci unpack --image newimage:newtag newbundle
−
 
 
−
On utilisant la commande suivante, on génère un dossier newbundle, qui contient le bon fichier config.json de l'image oci (newimage)
 
−
 
 
−
root@Panga:~/mycontainer# umoci unpack --image newimage:newtag newbundle
 
  
 
== Création du système de fichier racine pour les conteneurs ==
 
== Création du système de fichier racine pour les conteneurs ==
  
−
Dans mon repertoire mycontainer, je lance l'utilitaire debootstrap pour créer un système de fichier racine :
+
Dans mon répertoire <code>mycontainer</code>, je lance l'utilitaire <code>debootstrap</code> pour créer un système de fichier racine :
  
−
  debootstrap stretch newbundle/rootfs/
+
  root@Panga:~/mycontainer# debootstrap stretch newbundle/rootfs/
  
−
REX> Il reste à comparer les 250Mo de ce système de fichier avec un autre système de fichier racine d'une image docker de base.
+
Il a été demandé de comparer les 250Mo de ce système de fichiers avec un autre système de fichier racine d'une image docker de base.
−
 
 
−
[https://github.com/docker/docker/blob/master/contrib/mkimage/debootstrap]
 
  
−
On utilise docker pour créer des sytèmes de fichiers racine de taille minimale. Docker n'a pas besoin de tous les packages dont a besoin debootstrap, ou du moins il les supprime après avoir fini avec. Un système de fichier racine d'une image docker de base est donc plus petit qu'un fichier créé à partir de debootstrap stretch.
+
On utilise docker pour créer des systèmes de fichiers racine de taille minimale. Docker n'a pas besoin de tous les packages dont a besoin <code>debootstrap</code>, ou du moins il les supprime après avoir fini avec. Un système de fichiers racine d'une image docker de base est donc plus petit qu'un fichier créé à partir de notre commande. Voir le script utilisé par docker : [https://github.com/docker/docker/blob/master/contrib/mkimage/debootstrap].
  
−
REX> Il faudrait quantifier "plus petit".
+
<i>Note de l'encadrant : vous n'avez pas répondu à la question.</i>
  
−
REX> Tous les paquetages Debian installé durant le debootstrap sont-ils utiles ? Etablir une liste des paquetages peut être inutiles.
+
Il a été demandé si tous les paquetages Debian installés durant le <code>debootstrap</code> étaient utiles et d'établir une liste des paquetages inutiles.
  
 
Pour afficher les paquets installés, je lance dans mon conteneur la commande :  
 
Pour afficher les paquets installés, je lance dans mon conteneur la commande :  
 
   
 
   
−
> dpkg --get-selections
+
# dpkg --get-selections
 +
 
 +
<i>Note de l'encadrant : vous n'avez pas répondu à la question même si la réponse précédente apporte des éléments.</i>
  
 
== Lancement du conteneur ==
 
== Lancement du conteneur ==
  
−
Pour lancer le conteneur en tâche de fond, je rajoute l'option -d lors du lancement.
+
Pour lancer le conteneur en tâche de fond, je rajoute l'option <code>-d</code> lors du lancement et je modifie l'état de "terminal" dans le fichier
−
Sur le document que vous m'avez envoyé pour comprendre comment lancer un conteneur en tâche de fond, ils modifient l'état de "terminal" dans le fichier <code>config.json</code> pour le mettre à false. Est-ce que c'est nécessaire même avec l'option <code>-d</code> ?
+
<code>config.json</code> pour le mettre à false.
−
 
 
−
REX> Oui, sinon même en tâche de fond, le conteneur va utiliser le terminal comme entrée et sortie.
 
−
 
 
−
Le lancement du conteneur et la vérification du bon lancement du conteneur se font par les commandes suivantes.
 
  
 
  root@Panga:~# runc start -d -b  newbundle/ mycontainerid
 
  root@Panga:~# runc start -d -b  newbundle/ mycontainerid
  
 +
Pour lancer plusieurs conteneurs, il suffit d'exécuter les commandes suivantes (exemple pour 6 conteneurs) :
  
−
REX> Ce qui est indiqué ci-dessus est inexact. Sans l'option <code>-d</code> le lancement du conteneur reste en avant-plan.
+
  root@Panga:~# runc start -d -b newbundle/ mycontainerid1  
−
 
+
  root@Panga:~# runc start -d -b newbundle/ mycontainerid2  
−
REX> Décrivez un test complet permettant de lancer dans le même terminal plusieurs instances d'un conteneur. Précisez totalement les modifications apportées au fichier <code>config.json</code>. Comme tâche à effectuer dans le conteneur on peut imaginer une attente de quelques minutes.
+
  root@Panga:~# runc start -d -b newbundle/ mycontainerid3  
−
 
+
  root@Panga:~# runc start -d -b newbundle/ mycontainerid4  
−
Pour lancer dans le même terminal plusieurs instances d'un conteneur, il faut les rajouter dans le <code>config.json</code> plus précisément dans la partie args.
+
  root@Panga:~# runc start -d -b newbundle/ mycontainerid5  
−
 
+
  root@Panga:~# runc start -d -b newbundle/ mycontainerid6
−
REX> Non, je parle de lancer plusieurs conteneurs, pas plusieurs processus dans le même conteneur.
 
−
 
 
−
POur lancer plusieurs conteneurs il suffit d executer les commandes suivantes (exemple 6 conteneurs)
 
−
 
 
−
  root@Panga:~# runc start -d -b newbundle/ mycontainerid1  
 
−
  root@Panga:~# runc start -d -b newbundle/ mycontainerid2  
 
−
  root@Panga:~# runc start -d -b newbundle/ mycontainerid3  
 
−
  root@Panga:~# runc start -d -b newbundle/ mycontainerid4  
 
−
  root@Panga:~# runc start -d -b newbundle/ mycontainerid5  
 
−
  root@Panga:~# runc start -d -b newbundle/ mycontainerid6  
 
  
−
Pour une attente de quelques minutes par exemple, on peut rajouter dans args:["sleep","300"], le conteneur attendra donc 5 min.  
+
<i>Note de l'encadrant : sauf configuration particulière ce n'est pas vraiment conseillé de démarrer 6 conteneurs avec le même système de fichiers.</i>
  
−
REX> Oui, faites cet ajout dans le fichier de configuration (avec plutôt 5 minutes que 5 secondes) puis lancez plusieurs conteneurs en tâche de fond.
+
Pour une attente de quelques minutes par exemple, on peut rajouter dans <code>config.json</code> la directive <code>args:["sleep","300"]</code> le conteneur attendra donc 5 minutes.
−
 
 
−
Pour que le conteneur affiche la liste des répertoires existants : on peut mettre dans args:["ls"].
 
−
 
 
−
REX> Oui, mais pour un conteneur en tâche de fond c'est inutile.
 
  
 
== Mise en réseau du conteneur ==
 
== Mise en réseau du conteneur ==
Ligne 144 : Ligne 124 :
 
  mycontainerid  3537        running    /root/mycontainer/newbundle  2017-04-06T07:03:09.150496187Z
 
  mycontainerid  3537        running    /root/mycontainer/newbundle  2017-04-06T07:03:09.150496187Z
  
−
Je récupère le PID de mon conteneur : <code>3537</code>
+
Je récupère le PID de mon conteneur : <code>3537</code>.
  
 
  root@Panga:~# ip link add vifc1 type veth peer name eth0@c1
 
  root@Panga:~# ip link add vifc1 type veth peer name eth0@c1
 
  root@Panga:~# ip link set eth0@c1 netns /proc/3537/ns/net name eth0
 
  root@Panga:~# ip link set eth0@c1 netns /proc/3537/ns/net name eth0
  
−
Je crée mon bridge br0
+
Je crée mon bridge br0.
  
 
  root@Panga:~# brctl addbr br0
 
  root@Panga:~# brctl addbr br0
  
−
J'ajoute vifc1 et eth0 dans le bridge
+
J'ajoute <code>vifc1</code> et <code>eth0</code> dans le bridge.
  
 
  root@Panga:~# brctl addif br0 eth0
 
  root@Panga:~# brctl addif br0 eth0
Ligne 160 : Ligne 140 :
 
  br0 8000.5cb90180a7a6 no eth0
 
  br0 8000.5cb90180a7a6 no eth0
 
 
 
 
 +
<i>Note de l'encadrant : il faut activer <code>vifc1</code> et l'ajouter au commutateur virtuel.</i>
  
−
REX> Oui, c'est bien. Maintenant il faut mettre une adresse IP sur <code>br0</code> et une adresse IP sur <code>eth0</code>. Ces deux adresses IP doivent être dans le même réseau IP. Faire un test pour "pinguer" l'adresse IP du <code>br0</code> depuis le conteneur. Dans l'autre sens, faire une connexion <code>ssh</code> depuis <code>panga</code> sur le conteneur. Il faudra peut être modifier <code>/etc/ssh/sshd_config</code> comme dans le TP de virtualisation.
+
Pour mettre une adresse IP sur br0, on modifie le fichier <code>/etc/network/interfaces</code> de la manière suivante :
  
−
Pour mettre une adresse IP sur br0 et eth0, on modifie le fichier /etc/network/interfaces de la maniere suivante :
 
−
# This file describes the network interfaces available on your system
 
−
# and how to activate them. For more information, see interfaces(5).
 
−
 
−
source /etc/network/interfaces.d/*
 
−
 
 
  # The loopback network interface
 
  # The loopback network interface
 
  auto lo
 
  auto lo
 
  iface lo inet loopback
 
  iface lo inet loopback
 
   
 
   
 +
auto eth0
 +
iface eth0 inet manual
 +
  up ip link set dev eth0 up
 +
 
  auto br0
 
  auto br0
 
  iface br0 inet static
 
  iface br0 inet static
Ligne 179 : Ligne 158 :
 
   netmask 255.255.240.0
 
   netmask 255.255.240.0
 
   gateway 172.26.79.254
 
   gateway 172.26.79.254
−
 
−
auto eth0
 
−
iface br0 inet static
 
−
  address 172.26.79.105
 
−
  netmask 255.255.240.0
 
−
  gateway 172.26.79.254
 
  
−
On lance 6 conteneurs, puis on execute la commande suivant pour récuperer leur adresse ip (exemple mycontainerid)
+
<i>Note de l'encadrant : le fichier ci-dessus a été corrigé vous n'aviez pas tapé la bonne configuration pour l'interface Ethernet alors que sur le portable la configuration était correcte.</i>
 +
 
 +
On lance 6 conteneurs, puis on exécute la commande suivante pour récuperer leur adresse IP.
  
 
  runc exec mycontainerid ip a
 
  runc exec mycontainerid ip a
  
−
on récupère l'adresse ip puis on peut pinguer le conteneur à partir de panga avec la commande  
+
On peut alors pinguer le conteneur à partir de <code>panga</code> avec la commande :
  
 
  ping 127.0.0.1
 
  ping 127.0.0.1
 +
 +
<i>Note de l'encadrant : vous avez écrit une grosse bétise, l'adresse IP <code>127.0.0.1</code> est l'adresse de bouclage de <code>panga</code>.
 +
 +
Pour ne pas frustrer les lecteurs, voici les commandes à exécuter pour réaliser la fin de la configuration réseau.
 +
 +
Pour configurer une adresse IPv4 sur l'interface <code>eth0</code> d'un conteneur, il faut utiliser, par exemple, la commande
 +
 +
ip address add dev eth0 172.26.79.120/20
 +
 +
Pour des raisons de sécurité, la modification d'une interface réseau est interdite par défaut dans un conteneur lancé par <code>runc</code>. Taper la commande directement dans le conteneur va donc échouer. De même la commande lancée comme suit échouera :
 +
 +
  runc exec mycontainerid ip address add dev eth0 172.26.79.120/20
 +
 +
Il est facile de contourner ce blocage avec la commande <code>nsenter</code> :
 +
 +
  nsenter -t 3537 -n ip address add dev eth0 172.26.79.120/20
 +
  nsenter -t 3537 -n ip route add default gw 172.26.79.254
 +
 +
Dans cet exemple <code>3537</code> est le PID du conteneur.
 +
</i>
  
 
== Création des conteneurs de la maquette ==
 
== Création des conteneurs de la maquette ==
  
−
REX> Créez 6 conteneurs avec des adresses IP distinctes dans le même réseau et un serveur Web fonctionnel. Créez 3 pages Web facilement identifiables que vous installerez sur les 3 paires de serveurs Web. Vérifiez avec le navigateur du PC portable que les 6 pages Web sont accessibles.
+
Il est demandé de créer 6 conteneurs avec des adresses IP distinctes dans le même réseau et un serveur Web fonctionnel. Il faut aussi créer 3 pages Web facilement identifiables à installer sur les 3 paires de serveurs Web. Enfin, il faut vérifier avec le navigateur du PC portable que les 6 pages Web sont accessibles.
−
 
 
  
 
Je n'ai malheureusement pas pu arriver jusqu'à cette étape car ces dernières semaines étaient remplies de partiels et de projets à rendre. J'ai fait du mieux quue je pouvais afin de pouvoir réussir cette épreuve. Je pars en stage à partir du 8 mai et ne peut donc pas continuer à travailler dessus. J'espère vous avoir convaincu.
 
Je n'ai malheureusement pas pu arriver jusqu'à cette étape car ces dernières semaines étaient remplies de partiels et de projets à rendre. J'ai fait du mieux quue je pouvais afin de pouvoir réussir cette épreuve. Je pars en stage à partir du 8 mai et ne peut donc pas continuer à travailler dessus. J'espère vous avoir convaincu.
Ligne 210 : Ligne 204 :
 
| Configuration et installation du Wiki
 
| Configuration et installation du Wiki
 
| Effectué
 
| Effectué
−
|
+
| Sarah Zoubir
 
|-
 
|-
 
| Alimentation du Wiki
 
| Alimentation du Wiki
−
| En cours
+
| Effectué
−
| Sarah Zoubir nombreuses corrections de Xavier Redon
+
| Sarah Zoubir très nombreuses corrections de Xavier Redon (fautes d'orthographe et de formatage)
 
|-
 
|-
 
| Création de l'image OCI d'un conteneur
 
| Création de l'image OCI d'un conteneur
−
| Toujours à préciser
+
| Finalisé
−
| Sarah Zoubir
+
| Sarah Zoubir après plusieurs demandes
 
|-  
 
|-  
 
| Création du système de fichier du conteneur
 
| Création du système de fichier du conteneur
−
| A finaliser
+
| Finalisé
−
| Aide de Xavier Redon
+
| Aide massive de l'encadrant
 
|-
 
|-
 
| Lancement du conteneur en mode détaché
 
| Lancement du conteneur en mode détaché
−
| Toujours à finaliser
+
| Finalisé
−
|
+
| Aide massive de l'encadrant
 
|-
 
|-
 
| Mise en réseau du conteneur
 
| Mise en réseau du conteneur
−
| A finaliser
+
| Non terminé
−
|
+
| Malgré de nombreuses indications de l'encadrant
 
|-  
 
|-  
 
| Création des conteneurs de la maquette
 
| Création des conteneurs de la maquette
−
| A réaliser
+
| Non réalisé
−
|
+
| Pas suffisament de travail sur le projet pour arriver à cette étape
 
|}
 
|}

Version actuelle datée du 17 juin 2017 à 18:11

Cahier des charges

Cette section défini les modalités de l'épreuve complémentaire de virtualisation

Méthode

Le module étant principalement un TP de 20 heures, l'épreuve complémentaire repose donc sur la capacité de configurer un système sur une machine. Un PC portable a été fourni avec les paquetages nécessaires pour mener à bien le travail. Ce PC portable comporte également un Wiki permettant de faire rapport de l'avancée du travail.

Objectif

L'objectif est de réaliser un système de ferme de serveur Web accessible via un mandataire inverse réalisant de plus un équilibre de charge. Ce travail correspond à ce qui était demandé dans le premier tier du TP "virtualisation". Comme il est difficile de transformer un PC portable d'entrée de gamme en serveur de virtualisation, les serveurs Web seront implantés dans des conteneurs. Le mandataire inverse sera implanté dans l'OS du PC portable.

Étapes

  1. Il est d'abord demandé de mettre en oeuvre le WIki de type mediawiki sur le PC : recopier le sujet et préparer la structure pour rendre compte du travail, la sécurisation HTTPS n'est pas nécessaire vu que le wiki ne sera accédé qu'en local.
  2. La gestion des conteneurs se fera en utilisant la technologie runC. IL faut donc commencer par créer un système de fichier racine pour les conteneurs. L'utilitaire umoci sera utilisé (option new).
  3. Les conteneurs doivent être accessibles en réseau. Il faudra utiliser ip nets pour créer des interfaces virtuelles dans les conteneurs dont les pairs se trouveront dans un commutateur virtuel (utilitaire brctl) de l'OS principal.
  4. Il faudra explorer des solutions pour ajouter aux systèmes de fichier racines créés précédement le nécessaire pour faire tourner le serveur Web apache2.
  5. il ne reste plus qu'à configurer le serveur DNS local à l'OS principal pour donner un nom aux différents sites Web (partons sur 3 serveurs Web distincts redondés d'un facteur 2). Il est alors possible de configurer l'apache2 de l'OS principal pour agir comme mandataire inverse et équilibreur de charge.

Indications

Au cours du projet des indications supplémentaires ont été données à l'élève pour que le travail puisse avancer. Ces indications sont décrites ci-dessous.

Installation de mediawiki

Il faudra certainement modifier les droits sur la base de données. Pour cela, lancer les commandes suivantes en tant qu'administrateur : 

# service mysql stop
# mysqld_safe --skip-grant-tables &
# mysql -u root
> GRANT ALL PRIVILEGES on *.* to 'root'@'localhost' IDENTIFIED BY 'glopglop';
> FLUSH PRIVILEGES;
> QUIT ;
# fg
^C
# service mysql start

Création d'un système de fichiers

Les commandes umoci init et umoci new ne font que créer un conteneur avec un système de fichier vide. Il faut trouver une méthode pour obtenir un système de fichiers fonctionnel.

Une solution consiste à utiliser l'utilitaire debootstrap qui permet d'installer une distribution Debian à partir d'une distribution déjà installée. Les étapes sont les suivantes :

  • Installer le paquetage par apt-get install debootstrap (déjà effectué sur le PC portable).
  • Lancer l'utilitaire pour créer un système de fichier racine :
debootstrap stretch newbundle/rootfs/  http://debian.polytech-lille.fr/debian/

Cette solution fonctionne mais le système de fichier créé pèse 250Mo. Comparer par rapport à un autre système de fichier racine d'une image docker de base. Voir s'il est possible de réduire la taille de ce système de fichiers.

A noter :

  • La distribution Debian du PC ne comportait pas le paquetage systemd, dans ce cas le paquetage cgroupfs-mount doit être installé.
  • Le chemin PATH n'était pas défini dans le fichier de configuration du conteneur config.json, le shell ne pouvait donc pas être lancé au démarrage du conteneur.
  • Lors de la création de l'image, un fichier de configuration est fabriqué, ce n'est donc pas la peine d'en générer un autre par la commande runc spec. Par contre il faut préciser le chemin du répertoire de l'image au lancement du conteneur : runc create -b newbundle nomduconteneur.

Réseau pour le conteneur

Pour la configuration du réseau dans le conteneur. Il faut d'abord créer une interface virtuelle : 

panga# ip link add vifc1 type veth peer name eth0@c1
panga# ip link set eth0@c1 netns /proc/<PID c1>/ns/net name eth0

Le PID du conteneur se trouve avec runc list.

Il reste ensuite à mettre vifc1 dans le bridge des conteneurs. Ne pas oublier de configurer une adresse IP sur le bridge pour que panga accède à ses conteneurs.

Compte-rendu du travail réalisé

Création de la structure du conteneur

Détailler les étapes de la création de l'image OCI avec la commande umoci. 

root@Panga:~/mycontainer# umoci init --layout newimage
root@Panga:~/mycontainer# umoci new --image newimage:newtag

umoci init permet de créer une image OCI sans tag ou blobs à l'intérieur. Ensuite, unmoci new permet de créer une image OCI avec un tag que l'on pourra modifier comme on le souhaite par la suite.

On utilisant la commande suivante, on génère un dossier newbundle, qui contient le bon fichier config.json de l'image OCI de nom newimage. 

root@Panga:~/mycontainer# umoci unpack --image newimage:newtag newbundle

Création du système de fichier racine pour les conteneurs

Dans mon répertoire mycontainer, je lance l'utilitaire debootstrap pour créer un système de fichier racine : 

root@Panga:~/mycontainer# debootstrap stretch newbundle/rootfs/

Il a été demandé de comparer les 250Mo de ce système de fichiers avec un autre système de fichier racine d'une image docker de base.

On utilise docker pour créer des systèmes de fichiers racine de taille minimale. Docker n'a pas besoin de tous les packages dont a besoin debootstrap, ou du moins il les supprime après avoir fini avec. Un système de fichiers racine d'une image docker de base est donc plus petit qu'un fichier créé à partir de notre commande. Voir le script utilisé par docker : [1].

Note de l'encadrant : vous n'avez pas répondu à la question.

Il a été demandé si tous les paquetages Debian installés durant le debootstrap étaient utiles et d'établir une liste des paquetages inutiles.

Pour afficher les paquets installés, je lance dans mon conteneur la commande : 

# dpkg --get-selections

Note de l'encadrant : vous n'avez pas répondu à la question même si la réponse précédente apporte des éléments.

Lancement du conteneur

Pour lancer le conteneur en tâche de fond, je rajoute l'option -d lors du lancement et je modifie l'état de "terminal" dans le fichier config.json pour le mettre à false. 

root@Panga:~# runc start -d -b  newbundle/ mycontainerid

Pour lancer plusieurs conteneurs, il suffit d'exécuter les commandes suivantes (exemple pour 6 conteneurs) : 

root@Panga:~# runc start -d -b newbundle/ mycontainerid1 
root@Panga:~# runc start -d -b newbundle/ mycontainerid2 
root@Panga:~# runc start -d -b newbundle/ mycontainerid3 
root@Panga:~# runc start -d -b newbundle/ mycontainerid4 
root@Panga:~# runc start -d -b newbundle/ mycontainerid5 
root@Panga:~# runc start -d -b newbundle/ mycontainerid6

Note de l'encadrant : sauf configuration particulière ce n'est pas vraiment conseillé de démarrer 6 conteneurs avec le même système de fichiers.

Pour une attente de quelques minutes par exemple, on peut rajouter dans config.json la directive args:["sleep","300"] le conteneur attendra donc 5 minutes.

Mise en réseau du conteneur

root@Panga:~# runc list
ID              PID         STATUS      BUNDLE                        CREATED
mycontainerid   3537        running     /root/mycontainer/newbundle   2017-04-06T07:03:09.150496187Z

Je récupère le PID de mon conteneur : 3537. 

root@Panga:~# ip link add vifc1 type veth peer name eth0@c1
root@Panga:~# ip link set eth0@c1 netns /proc/3537/ns/net name eth0

Je crée mon bridge br0. 

root@Panga:~# brctl addbr br0

J'ajoute vifc1 et eth0 dans le bridge. 

root@Panga:~# brctl addif br0 eth0
root@Panga:~# brctl show
bridge name	bridge id		STP enabled	interfaces
br0		8000.5cb90180a7a6	no		eth0

Note de l'encadrant : il faut activer vifc1 et l'ajouter au commutateur virtuel.

Pour mettre une adresse IP sur br0, on modifie le fichier /etc/network/interfaces de la manière suivante : 

# The loopback network interface
auto lo
iface lo inet loopback

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

auto br0
iface br0 inet static
  bridge ports eth0
  address 172.26.79.105
  netmask 255.255.240.0
  gateway 172.26.79.254

Note de l'encadrant : le fichier ci-dessus a été corrigé vous n'aviez pas tapé la bonne configuration pour l'interface Ethernet alors que sur le portable la configuration était correcte.

On lance 6 conteneurs, puis on exécute la commande suivante pour récuperer leur adresse IP. 

runc exec mycontainerid ip a

On peut alors pinguer le conteneur à partir de panga avec la commande : 

ping 127.0.0.1

Note de l'encadrant : vous avez écrit une grosse bétise, l'adresse IP 127.0.0.1 est l'adresse de bouclage de panga.

Pour ne pas frustrer les lecteurs, voici les commandes à exécuter pour réaliser la fin de la configuration réseau.

Pour configurer une adresse IPv4 sur l'interface eth0 d'un conteneur, il faut utiliser, par exemple, la commande 

ip address add dev eth0 172.26.79.120/20

Pour des raisons de sécurité, la modification d'une interface réseau est interdite par défaut dans un conteneur lancé par runc. Taper la commande directement dans le conteneur va donc échouer. De même la commande lancée comme suit échouera : 

 runc exec mycontainerid ip address add dev eth0 172.26.79.120/20

Il est facile de contourner ce blocage avec la commande nsenter : 

 nsenter -t 3537 -n ip address add dev eth0 172.26.79.120/20
 nsenter -t 3537 -n ip route add default gw 172.26.79.254

Dans cet exemple 3537 est le PID du conteneur.

Création des conteneurs de la maquette

Il est demandé de créer 6 conteneurs avec des adresses IP distinctes dans le même réseau et un serveur Web fonctionnel. Il faut aussi créer 3 pages Web facilement identifiables à installer sur les 3 paires de serveurs Web. Enfin, il faut vérifier avec le navigateur du PC portable que les 6 pages Web sont accessibles.

Je n'ai malheureusement pas pu arriver jusqu'à cette étape car ces dernières semaines étaient remplies de partiels et de projets à rendre. J'ai fait du mieux quue je pouvais afin de pouvoir réussir cette épreuve. Je pars en stage à partir du 8 mai et ne peut donc pas continuer à travailler dessus. J'espère vous avoir convaincu.

Bilan du projet

Le tableau ci-dessous résume le travail effectué par l'élève sur le projet.

Tâche Etat Commentaire
Configuration et installation du Wiki Effectué Sarah Zoubir
Alimentation du Wiki Effectué Sarah Zoubir très nombreuses corrections de Xavier Redon (fautes d'orthographe et de formatage)
Création de l'image OCI d'un conteneur Finalisé Sarah Zoubir après plusieurs demandes
Création du système de fichier du conteneur Finalisé Aide massive de l'encadrant
Lancement du conteneur en mode détaché Finalisé Aide massive de l'encadrant
Mise en réseau du conteneur Non terminé Malgré de nombreuses indications de l'encadrant
Création des conteneurs de la maquette Non réalisé Pas suffisament de travail sur le projet pour arriver à cette étape
Récupérée de « https://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2016/2017_ECV1&oldid=44155 »