Introduction à OpenStack (2/2) : installation Devstack et utilisation via console web Horizon

Logo DevStack

Pour faire suite à l’article précédent présentant les différents modules composant OpenStack, voici comment installer et utiliser cette stack logicielle libre permettant de déployer un Cloud de type IaaS sur votre propre infrastructure. L’objectif est d’abord d’installer OpenStack intégralement sur une unique VM afin de pouvoir ensuite tester les services (via console web et APIs). Inutile de préciser que cette installation mono-VM n’a pour seul objectif que de servir à des fins de développement et de tests et ne peut en aucun cas servir pour de la production. J’utiliserai Vagrant et VirtualBox comme support d’installation et Devstack comme installeur d’OpenStack. Une fois la plate-forme prête, je vous expliquerai les quelques premières manipulations que vous pourrez effectuer via la console web d’administration. Je donnerai ensuite dans le prochain article (je pensais tout faire dans cet article, mais je me rends compte que le contenu risque d’être – trop – dense :o)) un certain nombre d’exemples d’utilisation des APIs des différents services qui vous permettent d’accéder aux mêmes fonctionnalités que la console web (et plus encore), mais avec du code ou des lignes de commandes. Les services que j’installe dans mon exemple sont les suivants : Nova, Glance, Cinder, Swift (avec un seul réplicat), Quantum, Keystone, Ceilometer et Horizon. Pour plus de détails sur chacun des modules précités, je vous invite à lire cet article : Introduction à OpenStack (1/2) : les modules.

Logo VirtualBox

Les outils

Tout d’abord, je tiens à préciser que j’utilise une machine host Windows 7 Pro SP1 et que, pour cette installation, je n’utilise pas réellement toutes les capacités nativement intégrées dans Vagrant, à savoir la gestion de configuration par Puppet ou Chef, et utilise uniquement les commandes de démarrage/arrêt/packaging. Tout cela pour dire que si vous avez un outil vous permettant démarrer des VMs et de les exporter une fois que tout est bien installé et configuré, vous pouvez passer l’étape des outils.

Je mets les versions que j’ai utilisées à titre indicatif : prenez de préférence toujours les dernières versions des outils, quitte à ajuster la configuration de Vagrant dans le fichier Vagrantfile si il y a eu des modifications de syntaxe avec la montée de version.

Vous devez tout d’abord télécharger les outils suivants :

Une fois Vagrant installé, il faudra ajouter dans la liste de ses box de base la box suivante : Ubuntu precise 64 (voir la liste complète à l’adresse suivante : Vagrantbox.es). La commande à passer pour ajouter la box (à partir de votre Git Bash) :

vagrant box add precise64 http://files.vagrantup.com/precise64.box

Une fois la box importée, vous devriez la voir grâce à la commande :

vagrant box list

Logo Vagrant

La configuration de la VM

Maintenant que vous avez à disposition la box de base souhaitée, il va falloir passer à l’étape suivante, à savoir configurer la VM qui va être générée à partir de cette box. A noter pour ceux qui ne connaissent pas les outils que la box initiale stockée dans votre référentiel Vagrant sera toujours conservée telle qu’elle est et ce sont les VM instanciées dans VirtualBox (à partir de cette box) que vous pourrez modifier et qui conserveront vos modifications d’un démarrage/arrêt à un autre.

Créez vous un répertoire de travail dans lequel vous allez pouvoir initialiser votre environnement Vagrant, puis placez vous dans ce répertoire et générez le fichier Vagrantfile :

vagrant init precise64

Ouvrez ce fichier et paramétrez les éléments suivants :

  • RAM minimum pour exécuter cette configuration d’OpenStack avec tous les modules précédemment cités et un Swift avec un ReplicatSet de 1 :

config.vm.customize ["modifyvm", :id, "--memory", 1536]

A noter que si vous ne disposez pas de la RAM nécessaire sur votre host, vous aurez des problèmes lors de l’initialisation de la stack (MySQL qui ne se lance pas et donc Keystone en vrac, mais ce n’est qu’un exemple… ;ob).

  • Configuration du réseau :

config.vm.network :hostonly, "192.168.33.10"

  • La liste des ports pour accéder aux services OpenStack depuis votre machine locale via 127.0.0.1:<port> :

config.vm.forward_port 80, 8085 # Horizon, port shifting to avoid conflicts with ports on local machine
config.vm.forward_port 8774, 8774 # Compute
config.vm.forward_port 9696, 9696 # Network
config.vm.forward_port 9292, 9292 # Image
config.vm.forward_port 8777, 8777 # Metering
config.vm.forward_port 8776, 8776 # Volume
config.vm.forward_port 5000, 5000 # Identity
config.vm.forward_port 8080, 8086 # Object Store, port shifting to avoid conflicts with ports on local machine
config.vm.forward_port 8773, 8773 # EC2
config.vm.forward_port 3333, 3333 # S3

Il est à présent temps de créer et démarrer votre VM grâce à la commande :

vagrant up

Vous pouvez maintenant vous connecter en ssh via la commande :

vagrant ssh

L’installation d’OpenStack

Passons maintenant à l’étape de l’installation de la stack OpenStack sur cette nouvelle VM. Si on se réfère au site Devstack, la mise en place semble réellement succincte (ça c’est la théorie :o)) :

git clone https://github.com/openstack-dev/devstack.git
cd devstack && ./stack.sh

Pour être un peu plus complet, on peut mettre les commandes suivantes dans un script à exécuter :

#!/bin/sh
apt-get update
apt-get install -qqy git
git clone https://github.com/openstack-dev/devstack.git
cd devstack
echo ADMIN_PASSWORD=password > localrc
echo MYSQL_PASSWORD=password >> localrc
echo RABBIT_PASSWORD=password >> localrc
echo SERVICE_PASSWORD=password >> localrc
echo SERVICE_TOKEN=tokentoken >> localrc
./stack.sh

Il s’agit globalement des mêmes étapes que dans les 2 lignes précédentes, mais on met d’abord à jour son repo de packages et on installe Git avant de pouvoir récupérer les composants de Devstack. Ensuite, une fois positionné dans le répertoire devstack, une étape de création d’un fichier localrc est ajoutée. Il s’agit du fichier dans lequel vous aller pouvoir configurer votre installation DevStack : les modules à installer, leurs configurations respectives, les mots de passe, …

Par défaut, vous aurez accès aux modules Nova et Horizon. Donc si vous voulez tester un set complet de modules, vous allez devoir configurer votre localrc de manière beaucoup plus pointue. Je ne vais pas vous faire attendre plus longtemps, alors voici mon script complet comprenant la création d’un fichier localrc bien plus complet (complexe ?) permettant d’avoir à disposition une plate-forme OpenStack composée des modules précités (à savoir Nova, Glance, Cinder, Swift, Quantum, Keystone, Ceilometer et Horizon) :

#!/bin/sh
apt-get update
apt-get install -qqy git
git clone https://github.com/openstack-dev/devstack.git
cd devstack
echo ADMIN_PASSWORD=password > localrc
echo MYSQL_PASSWORD=password >> localrc
echo RABBIT_PASSWORD=password >> localrc
echo SERVICE_PASSWORD=password >> localrc
echo SERVICE_TOKEN=tokentoken >> localrc
echo "ENABLED_SERVICES=g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-sch,n-cauth,horizon,mysql,rabbit,sysstat,cinder,c-api,c-vol,c-sch,n-cond,quantum,q-svc,q-agt,q-dhcp,q-l3,q-meta,q-lbaas,n-novnc,n-xvnc,ceilometer-acompute,ceilometer-acentral,ceilometer-collector,ceilometer-api,swift" >> localrc
echo "EXTRA_OPTS=(notification_driver=nova.openstack.common.notifier.rabbit_notifier,ceilometer.compute.nova_notifier)" >> localrc
echo SWIFT_HASH=66a3d6b56c1f479c8b4e70ab5c2000f5 >> localrc
echo SWIFT_REPLICAS=1 >> localrc
echo SWIFT_DATA_DIR=/os-data/swift >> localrc
echo 'export no_proxy="localhost,127.0.0.1"' >> localrc
./stack.sh

Logo Vagrant Fun
Outre la liste des services et des options, j’ai ajouté quelques éléments de configuration pour Swift afin de :

  • le faire fonctionner sur un unique réplicat (SWIFT_REPLICAS=1),
  • ne pas avoir à saisir manuellement (c’est le mal !) lors de l’installation la chaîne aléatoire et unique à assigner à un cluster Swift (SWIFT_HASH=66a3d6b56c1f479c8b4e70ab5c2000f5),
  • modifier le répertoire de destination des objets (SWIFT_DATA_DIR=/os-data/swift).

A noter que le nombre de réplicats par défaut est 3 et que cela consommerait un nombre certain d’IOs et de mémoire, plus que nécessaire dans le cas d’un simple test.

Vous mettez donc tout cela dans un fichier avec des droits en exécution dessus et… vous pouvez aller prendre un café et un croissant (ou une bière et des chips). Lors du premier lancement, le script va télécharger tout le nécessaire (packages, code OpenStack, …) et installer puis démarrer tous les services. Tout cela prend entre 20 et 30 minutes. Si tout c’est bien passé, vous devrez avoir à la fin de l’output :

Horizon is now available at http://10.0.2.15/
Keystone is serving at http://10.0.2.15:5000/v2.0/
Examples on using novaclient command line is in exercise.sh
The default users are: admin and demo
The password: password
This is your host ip: 10.0.2.15
stack.sh completed in 184 seconds.
bash: /root/.bashrc: Permission denied

Concernant le temps de complétion expéditif, cela vient du fait que j’ai déjà exécuté l’installation une première fois, puis ajouté dans mon localrc le paramètre :

OFFLINE=True

Après une installation réussie et en ajoutant ce paramètre, lors d’un ./stack.sh ultérieur, vous n’essaierez pas de récupérer les sources & Co et travaillerez en local.

A noter que ce script d’installation qui met à jour les packages, clone le repo Git, crée le localrc, … n’est à exécuter qu’une fois. Pour les démarrages ultérieurs de la stack, vous n’avez qu’à exécuter directement le ./stack.sh qui va se baser sur le localrc.

Concernant l’output :

bash: /root/.bashrc: Permission denied

C’est juste que j’ai lancé mon script dans la home de root (oups !) et que le script Devstack crée un user stack dès le début pour travailler avec. Mais cela ne pose pas de problème.

UPDATE : Je retire ce que j’ai dit, cela pose problème à partir du moment où on commence à développer. Pour bien faire, il faut avant toute chose créer un user stack soi-même avec la commande adduser, puis il faut ajouter le user au groupe sudo : adduser stack sudo. Il reste à configurer le fichier /etc/sudoers de la sorte : %sudo   ALL=(ALL:ALL) NOPASSWD:ALL. Passez en user stack et allez ensuite dans la home du user stack et procédez comme indiqué en début d’article en créant votre script d’installation. Une modification sera à apporter dans le script du fait que vous travaillez maintenant en stack sudo apt-get update et sudo apt-get install -qqy git (ajout du sudo). Ne quittez plus ce user à partir de maintenant, que ce soit pour démarrer la stack ou bien pour développer. J’ai rencontré des problèmes sur le passage de tests unitaires avec tox (par exemple) liés au fait que je travaillais en root.

Si vous obtenez une erreur, c’est que probablement la branche master du repo Git OpenStack n’était pas cohérente à un instant « t » ou bien que le script d’installation Devstack ne prenait pas en compte un changement récent du code OpenStack. Cela m’est arrivé plus d’une fois avant de réussir à avoir une installation complètement opérationnelle. Dans ce cas, 3 options :

  • être patient et réessayer plus tard sur la branche master,
  • définir explicitement la branche (stable/grizzly, stable/folsom, milestone-proposed, …) que vous pointez pour chaque module souhaité dans le localrc, par exemple :

CINDER_BRANCH=stable/grizzly
GLANCE_BRANCH=stable/grizzly
HORIZON_BRANCH=stable/grizzly
KEYSTONE_BRANCH=stable/grizzly
KEYSTONECLIENT_BRANCH=stable/grizzly
NOVA_BRANCH=stable/grizzly
NOVACLIENT_BRANCH=stable/grizzly
QUANTUM_BRANCH=stable/grizzly
SWIFT_BRANCH=stable/grizzly
...

  • supprimer les modules qui posent problème si vous ne souhaitiez pas les tester (mais vous aurez une installation incomplète en termes de fonctionnalités dans ce cas).

A noter que vous pouvez également pointer sur un autre repo, par exemple si vous développez sur le vôtre et que vous voulez tester une fonctionnalité :

NOVA_REPO=https://github.com/mon-repo/nova.git

Analyse des erreurs

Vous trouverez éventuellement des informations dans /var/log. Mais vu que c’est un problème au démarrage de la stack, faut pas rêver, il va falloir aller un peu plus loin. Chaque service (g-api, g-reg, key, n-api, n-crt, …) est lancé dans un screen indépendant. Si vous n’êtes pas en user stack, loguez vous ainsi :

su stack

Listez ensuite vos processus screen (il doit y en avoir un) :

screen -ls
There is a screen on:
4193.stack (07/02/2013 01:36:16 PM) (Detached)
1 Socket in /var/run/screen/S-stack.

Connectez-vous ensuite au processus grâce à cette commande :

screen -r 4193.stack

Vous obtiendrez peut-être une réponse de la sorte :

Cannot open your terminal '/dev/pts/0' - please check.

Reconnectez-vous alors en tant que root et exécutez

chmod 666 /dev/pts/0

Revenez ensuite en tant que stack et ré-exécutez la commande screen -r 4193.stack pour accédez au processus qui supporte les screens de votre stack.

Devstack - screen

Devstack - screen

Vous avez 2 commandes à connaître :

  • Ctrl+a " pour avoir accès à la liste de sélection des fenêtres,
  • Ctrl+a d pour détacher le screen et retourner sur votre terminal d’origine.

Lorsque vous serez dans les fenêtres, attention a ne pas « killer » le processus de la stack qui tourne en foreground avec un Ctrl+c ou autre ! Xo)

Pour plus d’informations sur les possibilités de screen, consultez ce manuel.

Test d’OpenStack en utilisant Horizon

Vous devriez à présent être capable d’utiliser votre Stack démarrée et complètement opérationnelle.

Accédez à Horizon depuis un navigateur sur votre poste local via http://127.0.0.1:8085/ et connectez-vous avec les credentials demo/password ou admin/password.

Je vais vous donner un petit mode opératoire pour démarrer une instance et vous y connecter. Je vous laisse tester le reste des fonctionnalités par vous-même ! :o)

Pour démarrer une instance dans le projet demo en tant qu’utilisateur demo, vous devrez :
Avant :

  • (accessible uniquement en admin, donc logout/login admin) créer une flavor « nano » avec 64Mo RAM, 1VCPU et 20Go de disque Root (logout/login demo),
  • définir un Security Group (autre que default) et donner les droits à 0.0.0.0/0 sur le protocole TCP et le port 22,
  • importer une clé publique,
  • créer un routeur qui lie un internal (private) network et un external (public) network afin que votre instance soit accessible (http://127.0.0.1:8085/project/network_topology/).

 

OpenStack - Horizon - Quantum - Network Topology

OpenStack - Horizon - Quantum - Network Topology

Pendant :

  • associer le Security Group et la clé,
  • associer le réseau private.

Après :

  • Associer une Floating IP.

A noter que vous pourrez accéder aux instances démarrées (en SSH par exemple) sur leur Floating IP à partir de la VM et non de votre machine locale.

Si vous rencontrez des problèmes pour vous connecter en SSH avec votre clé, vous pouvez utiliser : « login as ‘cirros’ user. default password: ‘cubswin:)’. use ‘sudo’ for root. »

Arrêter la stack et la VM

Arrêter les services OpenStack :

sudo su
cd /root/devstack/
./unstack.sh --all

Sortir des shells (exit, exit, exit, …), se déconnecter de la VM (exit) et arrêter la VM (vagrant halt).

Une fois votre installation complète, je vous invite à faire une box à partir de votre VM afin d’éviter de devoir refaire une installation complète si vous faites quelques manipulations imprudentes ou bien si vous tentez de mettre à jour des modules via git pull dans les répertoires respectifs des différents modules de la stack dans /opt/stack. Pour ce faire, vous pouvez lire la documentation Vagrant concernant le packaging des box à cette adresse : VagrantDocs – Packaging.

Une dernière note : Si vous packagez votre box Devstack et que vous souhaitez démarrer une nouvelle VM à partir de cette box, vous ne pourrez pas changer le hostname de la nouvelle VM (config.vm.host_name dans le Vagrantfile), sous peine de voir le RabbitMQ de votre stack ne pas démarrer car il ne retrouverait pas le nom de son node (qui contient le hostname : rabbit@hostname).

Conclusion

Nous sommes arrivés au bout de cette installation de la stack OpenStack en utilisant la méthode Devstack et du premier test via l’IHM Horizon. Vous pouvez à présent tester les services Nova, Glance, Cinder, Swift (avec un seul réplicat), Quantum et Keystone via Horizon. Ceilometer, quant à lui, n’est accessible qu’en API car non encore intégré dans Horizon. Vous pouvez retrouver la description de tous les modules OpenStack dans le premier article Introduction à OpenStack (1/2) : les modules de la série sur OpenStack. Dans le prochain et dernier article, l’article 2.5/2 (si ! si !), j’expliquerai l’utilisation directe des APIs des différents services.

Frédéric FAURE @Twitter @Ysance

3 commentaires pour Introduction à OpenStack (2/2) : installation Devstack et utilisation via console web Horizon

Répondre

 

 

 

Vous pouvez utiliser ces balises HTML

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>