Ce qu'il faut comprendre c'est qu'OpenStack à énormément évolué depuis ses débuts.
Il suffit de jeter un oeil à la liste des projets intégrés en fonction des versions. [1]
C'est d'une complexité ridicule. C'est dommage pour un projet de cet envergure
Bien au contraire, c'est justement ce qui fait sa force et sa modularité !
Tous les projets fonctionnent sur la même base :
Une base de données (SQL)
Un bus pour communiquer (AMQP) [2]
Et quelques daemons :
Une API REST
Un ordonnanceur
Des agents
Exemple avec Cinder :
cinder-api
cinder-scheduler
cinder-volume
L'intérêt de ce découpage, c'est de pouvoir faire grossir l'infrastructure facilement.
Ces daemons peuvent être placés sur différents serveurs, il n'ont pas besoin d'être l'un à coté de l'autre sur une même machine.
Si un daemon devient un goulet d'étranglement, il suffit d'en lancer un autre sur un autre serveur.
La communication entre les daemons s'effectue à travers un bus AMQP [2]
Tous les projets qui composent OpenStack ne sont pas forcément indispensables. C'est à vous de savoir lesquels vous seront utiles.
Parmis les briques indispensables, celles qui composent le tronc commun à toute infra OpenStack sont les suivantes :
Keystone (Il gère (entre autrechoses) l'authentification des utilisateurs et des services)
Glance (On peut le voir comme un dépot d'images de systèmes d'exploitation à déployer)
Nova (Prend en charge la virtualisation, il pilote les hyperviseurs, place intelligeament les nouvelles instances dans l'infrastructure)
Cinder (Pilote le stockage SAN en mode block, il permet de créer des disques durs virtuels pour vos instances)
Neutron (prend en charge la partie réseau)
Je ne cite pas Horizon parmis les briques indispensables parce qu'il ne s'agit pas d'un service OpenStack comme les cinq cités précédement.
C'est une application qui utilise les API REST des differents projets et présente un portail web permettant de gérer (plus ou moins) votre infrastructure. On ne peut pas tout faire avec Horizon, d'où le "plus ou moins".
Pour moi, ce qui peut en rebuter plus d'un, c'est la documentation.
Je me souviens à la version Essex, on pouvait trouver pas mal de tuto accompagnés d'explications, de schemas, c'était vraiment plus simple d'entrer dans le projet. (c'était moins touffu aussi, ça aide)
Aujourd'hui, la documentation [3] n'est pas du tout adapter à un publique de débutant, c'est plus un pense-bête pour des gens qui connaissent déja.
Je n'ai pas trouvé de tuto simple qui ne recopiait pas la documentation officiel.
Un simple exemple avec la configuration de Keystone. La plupart des docs, vous invites à saisir des lignes de commandes à ralonge comme celles-ci :
$ openstack service create --name keystone --description "OpenStack Identity" identity
$ openstack endpoint create \
--publicurl http://controller:5000/v2.0 \
--internalurl http://controller:5000/v2.0 \
--adminurl http://controller:35357/v2.0 \
--region RegionOne identity
Et ceci pour chaque brique ! Ca ne donne pas franchement envie n'est-ce pas ?
Alors qu'il existe un script [4] qui est disponible dans l'arborescence du projet.
Est-ce qu'il y en a, parmis vous, qui ont essayé OpenStack et qui ont trouvé que la documentation n'était pas adapté/suffisante/complète ?
[^] # Re: Le gros point noir d'OpenStack
Posté par MaxPower . En réponse à la dépêche Présentation d’OpenStack. Évalué à 3.
Ce qu'il faut comprendre c'est qu'OpenStack à énormément évolué depuis ses débuts.
Il suffit de jeter un oeil à la liste des projets intégrés en fonction des versions. [1]
Bien au contraire, c'est justement ce qui fait sa force et sa modularité !
Tous les projets fonctionnent sur la même base :
Et quelques daemons :
Exemple avec Cinder :
L'intérêt de ce découpage, c'est de pouvoir faire grossir l'infrastructure facilement.
Ces daemons peuvent être placés sur différents serveurs, il n'ont pas besoin d'être l'un à coté de l'autre sur une même machine.
Si un daemon devient un goulet d'étranglement, il suffit d'en lancer un autre sur un autre serveur.
La communication entre les daemons s'effectue à travers un bus AMQP [2]
Tous les projets qui composent OpenStack ne sont pas forcément indispensables. C'est à vous de savoir lesquels vous seront utiles.
Parmis les briques indispensables, celles qui composent le tronc commun à toute infra OpenStack sont les suivantes :
Je ne cite pas Horizon parmis les briques indispensables parce qu'il ne s'agit pas d'un service OpenStack comme les cinq cités précédement.
C'est une application qui utilise les API REST des differents projets et présente un portail web permettant de gérer (plus ou moins) votre infrastructure. On ne peut pas tout faire avec Horizon, d'où le "plus ou moins".
Pour moi, ce qui peut en rebuter plus d'un, c'est la documentation.
Je me souviens à la version Essex, on pouvait trouver pas mal de tuto accompagnés d'explications, de schemas, c'était vraiment plus simple d'entrer dans le projet. (c'était moins touffu aussi, ça aide)
Aujourd'hui, la documentation [3] n'est pas du tout adapter à un publique de débutant, c'est plus un pense-bête pour des gens qui connaissent déja.
Je n'ai pas trouvé de tuto simple qui ne recopiait pas la documentation officiel.
Un simple exemple avec la configuration de Keystone. La plupart des docs, vous invites à saisir des lignes de commandes à ralonge comme celles-ci :
$ openstack service create --name keystone --description "OpenStack Identity" identity
$ openstack endpoint create \
--publicurl http://controller:5000/v2.0 \
--internalurl http://controller:5000/v2.0 \
--adminurl http://controller:35357/v2.0 \
--region RegionOne identity
Et ceci pour chaque brique ! Ca ne donne pas franchement envie n'est-ce pas ?
Alors qu'il existe un script [4] qui est disponible dans l'arborescence du projet.
Est-ce qu'il y en a, parmis vous, qui ont essayé OpenStack et qui ont trouvé que la documentation n'était pas adapté/suffisante/complète ?
Références :
[1] https://fr.wikipedia.org/wiki/OpenStack
[2] https://fr.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol
[3] http://docs.openstack.org/kilo/install-guide/install/apt/content/
[4] https://github.com/openstack/keystone/blob/master/tools/sample_data.sh