Tuto 1 done
This commit is contained in:
parent
76495b9045
commit
49c5a27885
5 changed files with 314 additions and 103 deletions
|
|
@ -1,30 +1,34 @@
|
|||
\newpage
|
||||
|
||||
# Utiliser LXC
|
||||
# Utiliser `lxc`
|
||||
|
||||
Le but de cette première partie est d'appréhender la virtualisation légère au
|
||||
travers d'un programme, `lxc`, qui va mettre en place pour nous un
|
||||
travers d'un programme, `lxc`, qui va mettre en place pour nous tout un
|
||||
environnement distinct.
|
||||
|
||||
|
||||
## Lancer un conteneur
|
||||
|
||||
Avec le paquet LXC que vous avez installé, vous avez également récupéré un
|
||||
certain nombre de modèles de système (souvent installés dans le dossier
|
||||
`/usr/share/lxc/templates/`).
|
||||
Avec le paquet `lxc` que nous avons précédemment installé, nous avons également
|
||||
récupéré un certain nombre de *modèles* de système (souvent installés dans le
|
||||
dossier `/usr/share/lxc/templates/`) : il s'agit d'une suite de commandes
|
||||
(principalement des `wget`, `chroot` ou `debootstrap`) permettant d'obtenir un
|
||||
système basic fonctionnel, en suivant les étapes d'installation habituelle de
|
||||
la distribution.
|
||||
|
||||
La méthode la plus simple pour lancer un conteneur LXC est d'utiliser l'un de
|
||||
ces modèles qui va installer tout un environnement pour vous. On utilise pour
|
||||
cela la commande `lxc-create` :
|
||||
La méthode la plus simple pour lancer un conteneur `lxc` est d'utiliser l'un de
|
||||
ces modèles pour obtenir un nouveau système. On utilise pour cela la commande
|
||||
`lxc-create` :
|
||||
|
||||
```
|
||||
lxc-create --name toto_first --template ubuntu
|
||||
lxc-create --name toto_first --template debian
|
||||
```
|
||||
|
||||
Ce modèle va créer un dossier dans `/var/lib/lxc/` portant le nom que vous avez
|
||||
précisé. Ce dossier va contenir la configuration LXC du conteneur (`config`),
|
||||
la table des partitions (`fstab`) s'il y a besoin de faire des montages
|
||||
particuliers et enfin le dossier `rootfs` contenant le système en lui-même.
|
||||
Ce modèle va créer un dossier dans `/var/lib/lxc/` (pouvant varier d'une
|
||||
distribution à l'autre) portant le nom que nous avons précisé. Ce dossier va
|
||||
contenir la configuration `lxc` du conteneur (`config`), la table des
|
||||
partitions (`fstab`) s'il y a besoin de faire des montages particuliers et
|
||||
enfin le dossier `rootfs` contenant le système en lui-même.
|
||||
|
||||
Une fois l'installation terminée, on peut démarrer le conteneur :
|
||||
|
||||
|
|
@ -32,86 +36,147 @@ Une fois l'installation terminée, on peut démarrer le conteneur :
|
|||
lxc-start --name toto_first
|
||||
```
|
||||
|
||||
LXC va appeler `/sbin/init` et démarrer tous les services que l'on peut
|
||||
s'attendre à trouver dans n'importe quelle machine virtuelle plus classique (la
|
||||
seule différence réside donc dans le fait que le noyau est partagé avec
|
||||
l'hôte).
|
||||
`lxc` va appeler `/sbin/init` et démarrer tous les services que l'on peut
|
||||
s'attendre à trouver dans n'importe quelle machine virtuelle (et même physique)
|
||||
plus classique (la seule différence réside donc dans le fait que le noyau est
|
||||
partagé avec l'hôte).
|
||||
|
||||
Généralement on lance `lxc-start` avec l'option `--daemon`, car on ne s'attend
|
||||
pas à ce que la machine s'arrête lorsque l'on va quitter notre terminal. Dans
|
||||
ce cas, utiliser la commande `lxc-console` pour vous attacher à votre
|
||||
conteneur. À tout moment, vous pouvez vous détacher de la console (sans que
|
||||
cela n'affecte l'état du conteneur) en pressant les touches : `^A q`.
|
||||
Généralement on lance `lxc-start` avec l'option `--daemon`, car on n'a pas
|
||||
vraiment envie d'avoir un conteneur bloquant un terminal. En mode daemon, on va
|
||||
utiliser la commande `lxc-console` pour nous attacher aux conteneurs. À tout
|
||||
moment, nous pouvons nous détacher de la console (sans que cela n'affecte
|
||||
l'état du conteneur) en pressant les touches : `^A q`.
|
||||
|
||||
Connectez-vous, lancez quelques commandes puis éteignez la machine avec `sudo
|
||||
poweroff` dans le conteneur. Vous pouvez aussi lancer la commande `lxc-stop
|
||||
--name toto_first` dans un autre terminal, depuis la machine hôte.
|
||||
Connectons-nous, lancons quelques commandes puis éteignons la machine en
|
||||
lançant la commande `poweroff` dans le conteneur. Il est également possible de
|
||||
lancer la commande `lxc-stop --name toto_first` dans un autre terminal, depuis
|
||||
la machine hôte.
|
||||
|
||||
|
||||
## Le réseau
|
||||
|
||||
Le modèle ubuntu que vous avez utilisé initialise un fichier de configuration
|
||||
sans paramètres pour le réseau. Vous n'avez donc pas d'interface dans le
|
||||
conteneur pour le connecter au réseau.
|
||||
Le modèle *Debian*, que nous avons utilisé, préremplit un fichier de
|
||||
configuration sans définir de paramètre pour le réseau. Il n'y a donc pas
|
||||
d'interface dans le conteneur pour le connecter :
|
||||
|
||||
Un excellent article détaillant les différents types de réseau est accessible à
|
||||
```
|
||||
lxc.network.type = empty
|
||||
```
|
||||
|
||||
Un excellent article détaillant les différents types de configuration réseau
|
||||
est accessible à
|
||||
<https://blog.flameeyes.eu/2010/09/linux-containers-and-networking>.
|
||||
|
||||
N'ayant qu'une seule interface physique sur la machine et n'ayant pas accès à
|
||||
la configuration des VLAN de la pièce, il ne nous reste que deux méthodes pour
|
||||
obtenir du réseau dans nos conteneurs : Virtual Ethernet ou
|
||||
MACVLAN. Malheureusement, ces deux méthodes nécessitent de mettre en place un
|
||||
pont Ethernet sur votre machine :
|
||||
|
||||
|
||||
### Installation du pont réseau
|
||||
|
||||
#### Bridge interface
|
||||
|
||||
#### Port forwarding
|
||||
|
||||
|
||||
### Virtual Ethernet
|
||||
|
||||
Virtual Ethernet est la configuration la plus simple. On met en place un pont
|
||||
sur la machine hôte, puis on crée une interface `veth` par conteneur que l'on
|
||||
veut lancer. On n'oubliera pas d'ajouter ces interfaces au pont.
|
||||
|
||||
Voici un extrait de configuration correspondant au paramétrage d'une interface
|
||||
`eth0` pour un conteneur donné :
|
||||
|
||||
```
|
||||
lxc.network.type = veth
|
||||
lxc.network.flags = up
|
||||
lxc.network.link = br0
|
||||
```
|
||||
|
||||
Cette technique a pour inconvénient de laisser au noyau le soin de router les
|
||||
paquets selon leur adresse IP, ce qui peut être lent et coûteux étant donné que
|
||||
la carte est placé en mode de promiscuité.
|
||||
|
||||
obtenir du réseau dans nos conteneurs : Virtual Ethernet ou MACVLAN.
|
||||
|
||||
### MACVLAN
|
||||
|
||||
Ici, le noyau va orienter les paquets en fonction de leur adresse MAC de
|
||||
destination.
|
||||
Cette méthode est la plus simple : le noyau va orienter les paquets en fonction
|
||||
de leur adresse MAC de destination. Le conteneur sera donc comme une machine
|
||||
supplémentaire sur le réseau.
|
||||
|
||||
Modifions notre fichier de configuration afin qu'il ressemble à quelque chose
|
||||
comme :
|
||||
|
||||
```
|
||||
lxc.network.type = macvlan
|
||||
lxc.network.macvlan.mode = bridge
|
||||
lxc.network.flags = up
|
||||
lxc.network.link = br0
|
||||
lxc.network.link = eth0
|
||||
```
|
||||
|
||||
Après avoir démarré le conteneur, il devrait avoir obtenu une IP du serveur
|
||||
DHCP de l'école. L'inconvénient dans cette configuration est qu'il faille un
|
||||
client netsoul dans chaque conteneur, puisque chacun est considéré comme une
|
||||
machine différente aux yeux du routeur.
|
||||
|
||||
|
||||
### Virtual Ethernet
|
||||
|
||||
Virtual Ethernet est la configuration la moins optimale, mais sans doute la
|
||||
plus flexible.
|
||||
|
||||
Voici un extrait de configuration correspondant au paramétrage d'une interface
|
||||
virtuelle pour un conteneur donné :
|
||||
|
||||
```
|
||||
lxc.network.type = veth
|
||||
lxc.network.ipv4 = 172.23.42.2/24
|
||||
lxc.network.flags = up
|
||||
```
|
||||
|
||||
Dans cette situation, au démarrage du conteneur, `lxc` va créer une interface
|
||||
veth, avec un côté placé dans la machine hôte et l'autre côté placé dans le
|
||||
conteneur. `lxc` configure l'interface dans le conteneur, il nous appartient
|
||||
ensuite de configurer la machine hôte.
|
||||
|
||||
Commençons par attribuer une IP à cette nouvelle interface, en adaptant à votre
|
||||
identifiant d'interface :
|
||||
|
||||
```
|
||||
ip addr add 172.23.42.1/24 dev vethYJWD6R
|
||||
```
|
||||
|
||||
À partir de là, nous devrions pouvoir pinger notre conteneur depuis notre
|
||||
machine hôte : `ping 172.23.42.2`.
|
||||
|
||||
Notre conteneur ne peut cependant pas encore accéder à Internet. Pour cela, la
|
||||
machine hôte doit faire office de routeur et donc router les paquets d'un
|
||||
réseau à l'autre : en l'occurence, du réseau 172.23.42.1 vers Internet
|
||||
via 10.0.0.0/8, le réseau de l'école.
|
||||
|
||||
Pour que notre machine hôte route les paquets, exécuter la commande :
|
||||
|
||||
```
|
||||
sysctl -w net.ipv4.ip_forward=1
|
||||
```
|
||||
|
||||
Cette variable, que nous retrouvons dans `/proc/sys/net/ipv4/ip_forward`,
|
||||
indique au noyau qu'il peut faire passer les paquets réseau d'une interface à
|
||||
l'autre. Sans plus de directives, les paquets vont conserver leur adresse
|
||||
source (172.23.42.2 pour les paquets en provenance du conteneur). Cette adresse
|
||||
est une adresse privée, non routable sur Internet, ni même par le bocal. Il
|
||||
faut donc ajouter une couche de NAT/PAT pour réécrire les adresses sources
|
||||
avant d'envoyer les paquets sur internet :
|
||||
|
||||
```
|
||||
iptables -t nat -A POSTROUTING ! -o vethYJWD6R -s 172.23.42.0/24 -j MASQUERADE
|
||||
```
|
||||
|
||||
Dernière étape, dans notre conteneur, nous devons indiquer la route à utiliser
|
||||
pour accéder à internet :
|
||||
|
||||
```
|
||||
ip route add default via 172.23.42.1
|
||||
```
|
||||
|
||||
Nous avons maintenant internet dans notre conteneur !
|
||||
|
||||
|
||||
## Utilisation du conteneur
|
||||
|
||||
### Redémarrage du conteneur
|
||||
### Installation de InfluxDB
|
||||
|
||||
### Installation de InFluxDB et Graphana
|
||||
```
|
||||
apt-get update
|
||||
apt-get install wget
|
||||
wget https://s3.amazonaws.com/influxdb/influxdb_0.9.4.2_amd64.deb
|
||||
dpkg -i influxdb_0.9.4.2_amd64.deb
|
||||
```
|
||||
|
||||
### Test de l'installation
|
||||
|
||||
```
|
||||
/opt/influxdb/influxd
|
||||
```
|
||||
|
||||
Une fois que le service est démarré, vous devriez pouvoir accéder à l'interface
|
||||
à : <http://172.23.42.2:8083/>
|
||||
|
||||
Créons une nouvelle base de données "metrics", elle nous servira dans la partie suivante.
|
||||
|
||||
|
||||
## Rendu
|
||||
|
||||
|
|
@ -130,11 +195,12 @@ installés.
|
|||
|
||||
### Questions
|
||||
|
||||
1. Quel type de virtualisation réseau avez-vous utilisé ? pourquoi ?
|
||||
|
||||
1. Quels sont les autres types de virtualisation réseau existants ? Expliquez
|
||||
en chacun une phrase leurs particularités.
|
||||
|
||||
1. Quel fichier de configuration devriez-vous changer pour rendre persistante la
|
||||
valeur d'`ip_forward` ?
|
||||
|
||||
1. Dans quel langage InfluxDB a-t-il était écrit ? Quelle est la particularité
|
||||
des binaires générés par ce langage ?
|
||||
|
||||
|
|
@ -143,6 +209,6 @@ installés.
|
|||
virtualisation légère).
|
||||
|
||||
1. J'ai utilisé la méthode *Virtual Ethernet* pour relier mes conteneurs à
|
||||
Internet, via un PAT (`br0`). Quelle(s) règle(s) `iptables` devrais-je
|
||||
Internet, via l'interface `br0`. Quelle(s) règle(s) `iptables` devrais-je
|
||||
écrire sur mon hôte afin de permettre l'accès à InfluxDB depuis une autre
|
||||
machine ?
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue