Différences entre les pages « Lxc » et « Lxc guest »

De Cliss XXI
(Différence entre les pages)
Sauter à la navigation Sauter à la recherche
 
(Nouvelle page : === conversion d'une image linux en LXC === Un serveur virtuel LXC est la partie utilisateur ("userland") par oposition à la partie noyau ("kernel"). Pour convertir une image c'es...)
 
Ligne 1 : Ligne 1 :
== Construire un serveur LXC ==
+
=== conversion d'une image linux en LXC ===
  
LXC offre les possibilités d'un chroot avec quelques points en plus:
+
Un serveur virtuel LXC est la partie utilisateur ("userland") par oposition à la partie noyau ("kernel").
* séparation des process (une sorte de chroot des process)
 
* virtualisation du réseau (il est possible de simuler un circuit réseau avec
 
les bridges (brctl) le routage/NAT (iptables)
 
  
LXC souffre encore de quelques problèmes de jeunesse:
+
Pour convertir une image c'est assez simple en ce sens qu'on va plutôt enlever des choses qu'en mettre:
* lxc-stop est un vilain kill -9 -1 exécuté dans le container. Il faudrait que lxc-stop fasse un shutdown propre (init 0)
+
* tout les scripts de démarrage servant a faire l'initialisation matérielle
* le système de fichier /sys montre des éléments faisant partie de l'hôte et n'est pas encore suffisamment étanche.
+
* les scripts chargeant les modules kernel
  
 +
Très bien, enlevons, mais d'abord, quels sont les scripts lancé au démarrage. La réponse pourrait être simple,
 +
c'est les script rc du système V et c'est marre.
  
* Construction de la machine hôte [[lxc_host]]
+
Oui mais, avec Squeeze, Debian introduit 2 changements importants dans ces scripts:
* Construction/conversion de la machine invitée [[lxc_guest]]
+
# il existe maintenant 2 modes de démarrage (classique systemV et "makefile like" avec startpar)
 +
# même dans le mode classique, (rcN.d/[KS]XYscript.sh) les numéros d'execution (le XY) ne sont plus
 +
forcément figés, ils sont calculé par la commande "insserv". L'installation d'un paquet peut donc
 +
potentiellement faire changer l'ordre de démarrage.
  
== Todo ==
+
Restons calme, il s'agit de machine virtuelles, donc l'ordre d'exécution des scripts de démarrage
=== Questions résolues (et développées) ===
+
est moins critique que sur une machine physique.
* quels scripts enlever dans /etc/rc{S,3,0}.d et comment cf [[lxc_guest]]
+
Une machine physique doit savoir jongler avec des trucs comme: j'ai besoin de monter un volume raid,
 +
mais les binaires qui me permettront de le manipuler se trouve sur le volume raid en question...
 +
C'est précisément dans ce genre de cas que l'ordre d'exécution des scripts de démarrage est critique
 +
et que l'utilisation d'initrd et des modules noyau est indispensable.
  
=== Questions résolues (a développer) ===
+
Sur une machine virtuelle on va essentiellement lancer des applicatifs. Lancer apache longtemps avant
* mise en place du réseau avec veth, brctl et consort
+
la base de donnée sur laquelle il va travailler n'est pas une bonne idée, mais ça reste (la plupart
* modif de base: inittab et /dev
+
du temps) plus une gêne au démarrage qu'un plantage pur et simple.
* lxc-console sans mot de passe (modif inittab)
 
  
=== Questions partiellement résolues ===
+
Bref, revenons à ces scripts de démarrage qu'il faut élaguer:
* Serveur IMAP et inotify (FAM/gamin) ? est ce que le serveur IMAP est prévenu de manière efficace de l'arrivée de nouveaux mails?
+
# Quel est le type de démarrage ?
** Reponse rapide: installer gamin a la place de fam: '''apt-get install gamin'''
+
** Lenny -> sysV
* Arreter proprement un serveur lxc depuis l'hote (methode ssh, lxc-console + expect, lxc-attach quand ca voudra bien marcher ?)
+
** Squeeze:
 +
*** si CONCURRENCY=none dans /etc/default/rcS -> sysV
 +
*** sinon, si les fichiers /etc/init.d/.depend.{boot,start,stop} existent et ne sont pas vide -> "startpar" version "makefile"
 +
*** tout les autres cas -> sysV
  
=== liens ===
+
Voir le détail sur l'ordre d'exécution des scripts de démarrage [[script_rc_debian]]
* un wiki pratique sur different type de vm: [[http://wiki.pcprobleemloos.nl/using_lxc_linux_containers_on_debian_squeeze/]]
 
* le site de developpement lxc: [[http://lxc.sourceforge.net]]
 
* un howto bien fourni: [[http://lxc.teegra.net]]
 
* le wiki debian / lxc: [[http://wiki.debian.org/LXC]]
 
* conversion vserver -> lxc : [[http://schmidi2.blog.com/2010/10/25/migrating-from-vserver-to-lxc/]]
 
* un autre site interessant: [[http://www.jotschi.de/?p=554]]
 

Version du 1 mars 2012 à 18:22

conversion d'une image linux en LXC

Un serveur virtuel LXC est la partie utilisateur ("userland") par oposition à la partie noyau ("kernel").

Pour convertir une image c'est assez simple en ce sens qu'on va plutôt enlever des choses qu'en mettre:

  • tout les scripts de démarrage servant a faire l'initialisation matérielle
  • les scripts chargeant les modules kernel

Très bien, enlevons, mais d'abord, quels sont les scripts lancé au démarrage. La réponse pourrait être simple, c'est les script rc du système V et c'est marre.

Oui mais, avec Squeeze, Debian introduit 2 changements importants dans ces scripts:

  1. il existe maintenant 2 modes de démarrage (classique systemV et "makefile like" avec startpar)
  2. même dans le mode classique, (rcN.d/[KS]XYscript.sh) les numéros d'execution (le XY) ne sont plus

forcément figés, ils sont calculé par la commande "insserv". L'installation d'un paquet peut donc potentiellement faire changer l'ordre de démarrage.

Restons calme, il s'agit de machine virtuelles, donc l'ordre d'exécution des scripts de démarrage est moins critique que sur une machine physique. Une machine physique doit savoir jongler avec des trucs comme: j'ai besoin de monter un volume raid, mais les binaires qui me permettront de le manipuler se trouve sur le volume raid en question... C'est précisément dans ce genre de cas que l'ordre d'exécution des scripts de démarrage est critique et que l'utilisation d'initrd et des modules noyau est indispensable.

Sur une machine virtuelle on va essentiellement lancer des applicatifs. Lancer apache longtemps avant la base de donnée sur laquelle il va travailler n'est pas une bonne idée, mais ça reste (la plupart du temps) plus une gêne au démarrage qu'un plantage pur et simple.

Bref, revenons à ces scripts de démarrage qu'il faut élaguer:

  1. Quel est le type de démarrage ?
    • Lenny -> sysV
    • Squeeze:
      • si CONCURRENCY=none dans /etc/default/rcS -> sysV
      • sinon, si les fichiers /etc/init.d/.depend.{boot,start,stop} existent et ne sont pas vide -> "startpar" version "makefile"
      • tout les autres cas -> sysV

Voir le détail sur l'ordre d'exécution des scripts de démarrage script_rc_debian