Installation Gateway dans nebula » Historique » Version 9
Version 8 (Gilles Grandgérard, 21/05/2014 17:43) → Version 9/97 (Gilles Grandgérard, 21/05/2014 17:52)
h1. Avant Propos
todo
h2. Le modele de réseau
h3. Ajouter le partage 'eole-ci-tests' sur une VM
Si vous avez besoin de monter 'eole-ci-tests' sur une VM, il faut ajouter une ligne RAW dans la configuration du modèle :
<pre>
RAW=[TYPE="kvm",DATA="<devices><filesystem type='mount' accessmode='squash'><source dir='/var/lib/one/datastores/eole-ci'/><target dir='eole-ci'/></filesystem></devices>" ]
</pre> todo
Une fois la machine instanciée, pour monter le partage il faut executer :
<pre>
mkdir /mnt/eole-ci-tests
mount -t 9p -o trans=virtio eole-ci /mnt/eole-ci-tests -oversion=9p2000.L
</pre>
La mise à jour du git 'eole-ci-tests' est faite toutes les 15 minutes par Jenkins.
h3. Modèle de réseau de test pour les VM Nebula
!reseaux_type.png!
h2. Les fichiers de configuration
* ModulesConf.yaml
Ce fichier décrit globalement les modules Eole.
Il est utilisé pour :
* générer les context de chaque modele de VM
* générer les fresh install eole ( <module>-<version>-<architecure>.fi dans nebula )
* générer les daily ( <module>-<versionMajer>-daily-<architecure>.fi dans nebula )
<pre>
eoleVersions: # liste des numéros de version géré dans l'env de test
- 2.3.13-rc1
- 2.4.0
gateways: # liste des gateways par utilisateur Nebula
- user: gilles # le nom de l'utilisateur Nebula
prefixe: ggg # le prefixe a utilisé pour les templates, switchs, et vm
ipsweole: 82 # l'adresse ip sur le réseau sw-eole
modules: # La liste des modules connus
- module: base # le nom du module dans les modeles
memoire: 1024 # permet de définir la mémoire requise pour ce module
versions: # la liste des versions de ce module
- versionMajeur: 2.3 # dans la version 2.3..
menu: 1 # ... le module est en position 1 sur le menu d'installation
actif: oui # indique que le module est déactivé dans les tests
container: non # permet d'indiquer aux tests qu'il faut faire l'installation des conteneurs ou non
- versionMajeur: 2.4 ...
menu: 1
...
</pre>
* ModeleReseautestEole.yaml
Attention: Les gateway de chaque réseau est toujours l'ip .1 de chaque réseau
Il est utilisé pour :
* générer les context de chaque modele de VM
* générer les templates de chaque machine
* démarrer les VM lors des tests en Itégration Continue
<pre>
bases:
- base: eole23 # nom de la base utiliser dans la description d'une machine (cf ci dessous )
versionMajeur: 2.3 # quel est la version majeur a utiliser. La version mineur sera déduite du fichier ModulesConf.yaml
- base: winpcadmin
imageNebula: windows-xp-sp3.vm # si imageNebula est presente, alors la base n'est pas EOLE ==> windows ou autre
architecture: amd64 # dans ce cas, l'architecture doit être définie
....
switchs: # c'est la liste des switchs nécessaire à ce modele
- sw: academie # c'est l'id du switch . dans Nebula, il correspond à "SW-<pefixe>-academie"
network: 192.168.0 # c'est le réseau associé à ce switch
...
networks: # ce tag est la racine de description de tous les établissements
- etablissement: aca # ce tag correspond à un etablissement dont le nom est 'aca'. Toutes les machines définies sous l'établissement seront
# préfixées par <prefixe_user>.<etablissement>
machines: # c'est la liste des machines
- machine: eolebase # chaque machine a : un nom (eolebase).
# le template de cette machine sera <prefixe_user>.<etablissement>.<machine> (ggg.aca.eolebase)
# le nom dns sera : <machine>.<etablissement>@ac-test.fr pour les etablissement et
# <machine>@ac-test.fr pour les machines en académie
# Ce nom est important car il va définir un template dans les configurations enregistrées dans eole-ci-test
module: base # c'est le nom du module (cf ModulesConf.yaml). La valeur est obligatoire pour les modules Eole
base: eole24 # identifie l'image de base à utiliser eole23, eole24, win...
switchs: # ce tag décris les liens de la machine
- sw: academie # le nom du switch
host: 24 # l'ip sur ce switch
...
- machine: sphynx24a
module: sphynx
base: eole24
switchs: # exemple avec plusieurs switchs
- sw: academie
host: 11
- sw: agriates
host: 11
- sw: ha1
host: 11
...
- machine: pcadmin # exemple pour un poste client
base: winpcadmin
switchs:
- sw: admin1
host: 20
...
</pre>
* test.yaml
todo
h1. Installation
h2. Récupération du dépot eole-ci-test
Faire :
<pre>
ssh://git@dev-eole.ac-dijon.fr/eole-ci-tests.git
</pre>
h2. Ajout de la gateway dans le fichier ModulesConf.yaml
il faut créer une entré dans "gateways" de la forme
<pre>
- user: gilles
prefixe: ggg
ipsweole: 82
</pre>
* Le prefixe sera ajouter à tous les templates, et à toutes les VM démarrées.
Les switchs auront la forme SW-<prefixe>-<switch_dans_modele>
* ipsweole est l'ip a utilisr dans 192.168.230 comme gateway vers le réseau
h2. Ajout de la clef publique ssh dans eole-ci-tests/security/authorized_keys
Les clefs publiques SSH preentent dans eole-ci-tests/security/authorized_keys sont automatiquement concatenées dans /root/.ssh/authorized_keys au 1er démarrage de la VM.
L'acces a chaque VM peut se faire sans mot de passe.
Utiliser le nom 'user@hostname' pour votre fichier de cle.
h1. Creation d'un test
todo
h1. Lancement dans jenkins
h2. Mise à jour de "eole-ci-tests" sur toutes les VM
todo
h2.
todo
h2. Le modele de réseau
h3. Ajouter le partage 'eole-ci-tests' sur une VM
Si vous avez besoin de monter 'eole-ci-tests' sur une VM, il faut ajouter une ligne RAW dans la configuration du modèle :
<pre>
RAW=[TYPE="kvm",DATA="<devices><filesystem type='mount' accessmode='squash'><source dir='/var/lib/one/datastores/eole-ci'/><target dir='eole-ci'/></filesystem></devices>" ]
</pre> todo
Une fois la machine instanciée, pour monter le partage il faut executer :
<pre>
mkdir /mnt/eole-ci-tests
mount -t 9p -o trans=virtio eole-ci /mnt/eole-ci-tests -oversion=9p2000.L
</pre>
La mise à jour du git 'eole-ci-tests' est faite toutes les 15 minutes par Jenkins.
h3. Modèle de réseau de test pour les VM Nebula
!reseaux_type.png!
h2. Les fichiers de configuration
* ModulesConf.yaml
Ce fichier décrit globalement les modules Eole.
Il est utilisé pour :
* générer les context de chaque modele de VM
* générer les fresh install eole ( <module>-<version>-<architecure>.fi dans nebula )
* générer les daily ( <module>-<versionMajer>-daily-<architecure>.fi dans nebula )
<pre>
eoleVersions: # liste des numéros de version géré dans l'env de test
- 2.3.13-rc1
- 2.4.0
gateways: # liste des gateways par utilisateur Nebula
- user: gilles # le nom de l'utilisateur Nebula
prefixe: ggg # le prefixe a utilisé pour les templates, switchs, et vm
ipsweole: 82 # l'adresse ip sur le réseau sw-eole
modules: # La liste des modules connus
- module: base # le nom du module dans les modeles
memoire: 1024 # permet de définir la mémoire requise pour ce module
versions: # la liste des versions de ce module
- versionMajeur: 2.3 # dans la version 2.3..
menu: 1 # ... le module est en position 1 sur le menu d'installation
actif: oui # indique que le module est déactivé dans les tests
container: non # permet d'indiquer aux tests qu'il faut faire l'installation des conteneurs ou non
- versionMajeur: 2.4 ...
menu: 1
...
</pre>
* ModeleReseautestEole.yaml
Attention: Les gateway de chaque réseau est toujours l'ip .1 de chaque réseau
Il est utilisé pour :
* générer les context de chaque modele de VM
* générer les templates de chaque machine
* démarrer les VM lors des tests en Itégration Continue
<pre>
bases:
- base: eole23 # nom de la base utiliser dans la description d'une machine (cf ci dessous )
versionMajeur: 2.3 # quel est la version majeur a utiliser. La version mineur sera déduite du fichier ModulesConf.yaml
- base: winpcadmin
imageNebula: windows-xp-sp3.vm # si imageNebula est presente, alors la base n'est pas EOLE ==> windows ou autre
architecture: amd64 # dans ce cas, l'architecture doit être définie
....
switchs: # c'est la liste des switchs nécessaire à ce modele
- sw: academie # c'est l'id du switch . dans Nebula, il correspond à "SW-<pefixe>-academie"
network: 192.168.0 # c'est le réseau associé à ce switch
...
networks: # ce tag est la racine de description de tous les établissements
- etablissement: aca # ce tag correspond à un etablissement dont le nom est 'aca'. Toutes les machines définies sous l'établissement seront
# préfixées par <prefixe_user>.<etablissement>
machines: # c'est la liste des machines
- machine: eolebase # chaque machine a : un nom (eolebase).
# le template de cette machine sera <prefixe_user>.<etablissement>.<machine> (ggg.aca.eolebase)
# le nom dns sera : <machine>.<etablissement>@ac-test.fr pour les etablissement et
# <machine>@ac-test.fr pour les machines en académie
# Ce nom est important car il va définir un template dans les configurations enregistrées dans eole-ci-test
module: base # c'est le nom du module (cf ModulesConf.yaml). La valeur est obligatoire pour les modules Eole
base: eole24 # identifie l'image de base à utiliser eole23, eole24, win...
switchs: # ce tag décris les liens de la machine
- sw: academie # le nom du switch
host: 24 # l'ip sur ce switch
...
- machine: sphynx24a
module: sphynx
base: eole24
switchs: # exemple avec plusieurs switchs
- sw: academie
host: 11
- sw: agriates
host: 11
- sw: ha1
host: 11
...
- machine: pcadmin # exemple pour un poste client
base: winpcadmin
switchs:
- sw: admin1
host: 20
...
</pre>
* test.yaml
todo
h1. Installation
h2. Récupération du dépot eole-ci-test
Faire :
<pre>
ssh://git@dev-eole.ac-dijon.fr/eole-ci-tests.git
</pre>
h2. Ajout de la gateway dans le fichier ModulesConf.yaml
il faut créer une entré dans "gateways" de la forme
<pre>
- user: gilles
prefixe: ggg
ipsweole: 82
</pre>
* Le prefixe sera ajouter à tous les templates, et à toutes les VM démarrées.
Les switchs auront la forme SW-<prefixe>-<switch_dans_modele>
* ipsweole est l'ip a utilisr dans 192.168.230 comme gateway vers le réseau
h2. Ajout de la clef publique ssh dans eole-ci-tests/security/authorized_keys
Les clefs publiques SSH preentent dans eole-ci-tests/security/authorized_keys sont automatiquement concatenées dans /root/.ssh/authorized_keys au 1er démarrage de la VM.
L'acces a chaque VM peut se faire sans mot de passe.
Utiliser le nom 'user@hostname' pour votre fichier de cle.
h1. Creation d'un test
todo
h1. Lancement dans jenkins
h2. Mise à jour de "eole-ci-tests" sur toutes les VM
todo
h2.