Personnellement, j'utilise SaltStack [1] et SaltCloud [2]
Le premier me permet d'industrialiser le déploiment logiciel à l'intérieur de mes instances. Ansible, Puppet, Chef, etc… remplissent la même fonction.
SaltCloud quand à lui me permet de définir des architectures complète a déployer.
Pour prendre un exemple simple, imaginons une infrastructure à 3 noeuds :
- Un load-balancer (HAProxy)
- Un server web nginx + php
- Une base de données
Dans SaltStack je commence par créer les 3 cookbooks pour installer et configurer chacun de ces rôles.
Dans SaltCloud, je vais configurer mon CloudProvider (AWS, Azure, OpenStack, etc …)
Ensuite, je vais créer la "Map" de mon architecture à 3 noeud :
Puis lance la construction:
1) Dans la map, on remarque que le load-balancer requière un webserver, et que le webserver requière une base de données.
2) La première instance qui sera provisionnée sera donc la base de données, salt-cloud va parler à mon CloudProvider et demander l'installation de cette première instance.
3) Une fois l'instance en ligne, l'agent salt (le salt-minion) sera installé dessus et configuré pour parler à mon salt-master.
4) Le salt-master est configuré pour accepter les nouveaux minion et lancer immédiatement un highstate (mise à jour)
5) Dans la configuration de la map, j'ai spécifié le 'role: database', le highstate va donc déclancher le cookbook correspondant.
6) J'ai aussi spécifier le 'site: www.exemple.com', mon cookbook injectera alors le schéma (vierge ou la restauration d'un backup) de la base de données correspondant au site www.exemple.com
7) L'installation de l'instance 'db01' est maintenant terminée, le pré-requis pour installer le webserver est donc satisfait, l'installation du webserver peut commencer.
Instancer une nouvelle infrastructure comme celle-ci se résumera alors à copier la map et à changer quelques variables (role, site, etc …)
Voilà en gros ce qu'il est possible de faire avec OpenStack + SaltStack.
Mais ça n'est qu'un bref aperçu ! On peut faire bien plus, comme ajouter ou détruire des webservers du pool du load-balancer en fonction du nombre de connexions et ce sans aucune intervention humaine. Quand on est facturé à la minute dans le cloud, ce genre de fonctionnalité prend tout son sens.
Donc à vous de voir si ce genre de gourmandise peut vous servir ou s'il n'est pas plus intéressant pour vous de perfectionner votre industrialisation voir de changer d'outils.
Quelles sont vos problématiques aujourd'hui ? Le contexte c'est bien, mais qu'entendez-vous pas "se faire déborder" ?
Question 2: Comment puis-je me former?
Il y a tout d'abord la documentation officielle, qui, sans être parfaite, à tout de même le mérite d'exister.
Pour bien débuter, je dirais que l'objectif c'est de réussir à monter une infrastructure à 3 noeuds :
- Cloud Controller
- Network Controller
- Compute Node (hyperviseur)
La communauté peut vous aidez à atteindre cet objectif, il existe un chan irc "#openstack-101" [1] si vous voulez poser vos questions et obtenir de l'aide.
Vous pouvez aussi rejoindre l'association OpenStackFr [2] qui organise réguliairement des rencontres [3] avec les utilisateurs d'OpenStack. Il est possible de discuter avec les développeurs et les Projects Leaders.
Il existe aussi des formations certifiantes (payantes) [4]
Dans ce cas, il semble que le problème soit corrigé dans la dernière version de la documentaton (Liberty)
Contents
[…]
Add the Identity service
Add the Image service
Add the Compute service
Add the Networking service
Add the dashboard
Add the Block Storage service
Add the Object Storage service
Add the Orchestration service
Add the Telemetry service
[…]
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 ?
Ca varie d'un driver à l'autre. Ca peut aussi venir d'un problème de configuration.
Dans certains cas on pouvait se retrouver avec des volumes en état "error" avec une impossibilité de les supprimer. On était donc obligé de faire le ménage en base de données directement mais fort heureusement ça à bien évolué depuis.
Il reste néanmoins qu'il faut une équipe solide pour faire de l'OpenStack en prod, bien tester, et ne pas sauter sur la dernière version dès qu'elle sort ;)
C'est mon premier post sur LinuxFr, j'arpente pourtant ces colonne depuis fort longtemps, mais ce sujet m'a décider à franchir le pas sous la forme d'un coup de gueule. (drôle d'entrée en matière :)
J'ai contribué à OpenStack sur les projets Nova et Cinder sur les versions Folsom, Grizzly et Havana.
A cette époque, la communauté était plus petite et surtout plus fournie en "vrai" contributeurs individuels.
Non pas que je déplore l'engouement des grands groupes pour ce projet magnifique, OpenStack ne serait pas ce qu'il est sans eux, mais il est extrèmement difficile aujourd'hui de faire entrer quoique ce soit en son sein.
Je vais prendre l'exemple de Cinder (mais c'est pareil dans les autres projets).
Aujourd'hui, un driver cinder se résume (pour faire simple) à interfacer l'API d'un système de stockage (quel qu'il soit) avec Cinder. Créer un binding, en gros, entre ces deux monde.
1) Avant même de commencer à écrire la moinde ligne, il faut créer un blueprint (proposition de votre fonctionnnalité auprès de la communauté). C'est très compliqué aujourd'hui de créer ce blueprint, c'est extrèment structuré, il faut passer un temps monstre à discuter avec les CoreDev pour etre certain de ne rien oublier et de faire ça dans les formes.
2) Il faut de votre blueprint soit accepté par les CoreDev. Il faut donc passer encore du temps à faire du lobbying auprès des CoreDev (payer des bières peut aider ;). Mais vous n'avez toujours pas commencé à coder.
3) Votre blueprint est accepté, super, vous avez maintenant le droit de pousser du code.
Ici, c'est du classique au niveau des choses requises pour que votre code soit mergé:
Respect de la norme PEP8 (oui on fait du Python)
Votre code doit intégrer des tests unitaires (ceux qui test, c'est ceux qui doute ?)
4) La revue de code (c'est là une des raisons qui m'a décidé à arrêter de contribuer sur ce projet)
Pour rappel, je suis un contributeur individuel et bénévole, c'est à dire que je ne suis pas payé (par un grand groupe) pour contribuer à OpenStack, je le fait simplement parce que j'aime ce projet, que j'ai l'envie de le faire et je le fais sur mon temps libre.
Le suivi de votre revue de code est très importante, tout contributeur peu participer à la revue du code de n'importe qui.
Vous aller être questionner sur la pertinance d'un bout de code, on va peut-être vous apprendre des choses ou vous dire que telle fonction existe déja dans cinder.common
Il faut répondre aux questions, expliquer, accepter de changer etc … du classique.
Sauf qu'il m'a été reprocher de ne pas répondre suffisamant vite (dans la journée). Excusez moi de bosser …
5) Infrastructure de tests d'intégration (CI)
C'est relativement récent, je ne sais plus exactement sur quelle release c'est arrivé.
Dorénavant, chaque driver doit fournir une infrastructure de tests d'intégration pour son driver.
Encore une fois, pour des grands groupes, aucun problème pour payer quelques dizaines d'instances sur AWS ou bien monter une infrastructure en propre.
Mais quand est-il des "petits" projets ? Quand est-il des drivers déja présents dans OpenStack ?
Et bien pour les petits projets, c'est très dur, voir impossible.
Pour les drivers déja présents dans OpenStack qui n'ont pas mis en place cette infrastructure de tests, il ont purement et simplement étés supprimés !
Qu'OpenStack décide d'avoir une polique visant à fournir des drivers de qualité, peux se comprendre.
Mais qu'on laisse les petits projets exister, pourquoi ne pas avoir créer un répertoire 3th-party-drivers contenant les drivers qui ne couvrent pas entièrement les pré-requis ?
Qu'est ce qu'il reste aux vrai contributeurs individuel ? Bug Triage ? Bug Fixing ? Mais aucune nouvelle features ? Ecoeurant …
Aujourd'hui, je suis toujours utilisateur d'OpenStack, je le modifie, je l'améliore mais tout ça dans mon coin et ne commit plus rien … c'est moche.
[^] # Re: Formation
Posté par MaxPower . En réponse à la dépêche Présentation d’OpenStack. Évalué à 5.
Personnellement, j'utilise SaltStack [1] et SaltCloud [2]
Le premier me permet d'industrialiser le déploiment logiciel à l'intérieur de mes instances. Ansible, Puppet, Chef, etc… remplissent la même fonction.
SaltCloud quand à lui me permet de définir des architectures complète a déployer.
Pour prendre un exemple simple, imaginons une infrastructure à 3 noeuds :
- Un load-balancer (HAProxy)
- Un server web nginx + php
- Une base de données
Dans SaltStack je commence par créer les 3 cookbooks pour installer et configurer chacun de ces rôles.
Dans SaltCloud, je vais configurer mon CloudProvider (AWS, Azure, OpenStack, etc …)
Ensuite, je vais créer la "Map" de mon architecture à 3 noeud :
Puis lance la construction:
1) Dans la map, on remarque que le load-balancer requière un webserver, et que le webserver requière une base de données.
2) La première instance qui sera provisionnée sera donc la base de données, salt-cloud va parler à mon CloudProvider et demander l'installation de cette première instance.
3) Une fois l'instance en ligne, l'agent salt (le salt-minion) sera installé dessus et configuré pour parler à mon salt-master.
4) Le salt-master est configuré pour accepter les nouveaux minion et lancer immédiatement un highstate (mise à jour)
5) Dans la configuration de la map, j'ai spécifié le 'role: database', le highstate va donc déclancher le cookbook correspondant.
6) J'ai aussi spécifier le 'site: www.exemple.com', mon cookbook injectera alors le schéma (vierge ou la restauration d'un backup) de la base de données correspondant au site www.exemple.com
7) L'installation de l'instance 'db01' est maintenant terminée, le pré-requis pour installer le webserver est donc satisfait, l'installation du webserver peut commencer.
Instancer une nouvelle infrastructure comme celle-ci se résumera alors à copier la map et à changer quelques variables (role, site, etc …)
Voilà en gros ce qu'il est possible de faire avec OpenStack + SaltStack.
Mais ça n'est qu'un bref aperçu ! On peut faire bien plus, comme ajouter ou détruire des webservers du pool du load-balancer en fonction du nombre de connexions et ce sans aucune intervention humaine. Quand on est facturé à la minute dans le cloud, ce genre de fonctionnalité prend tout son sens.
Donc à vous de voir si ce genre de gourmandise peut vous servir ou s'il n'est pas plus intéressant pour vous de perfectionner votre industrialisation voir de changer d'outils.
[1] https://docs.saltstack.com/en/latest/topics/index.html
[2] https://docs.saltstack.com/en/develop/topics/cloud/index.html
[^] # Re: Formation
Posté par MaxPower . En réponse à la dépêche Présentation d’OpenStack. Évalué à 2.
Quelles sont vos problématiques aujourd'hui ? Le contexte c'est bien, mais qu'entendez-vous pas "se faire déborder" ?
Il y a tout d'abord la documentation officielle, qui, sans être parfaite, à tout de même le mérite d'exister.
Pour bien débuter, je dirais que l'objectif c'est de réussir à monter une infrastructure à 3 noeuds :
- Cloud Controller
- Network Controller
- Compute Node (hyperviseur)
La communauté peut vous aidez à atteindre cet objectif, il existe un chan irc "#openstack-101" [1] si vous voulez poser vos questions et obtenir de l'aide.
Vous pouvez aussi rejoindre l'association OpenStackFr [2] qui organise réguliairement des rencontres [3] avec les utilisateurs d'OpenStack. Il est possible de discuter avec les développeurs et les Projects Leaders.
Il existe aussi des formations certifiantes (payantes) [4]
Références:
[1] https://wiki.openstack.org/wiki/IRC
[2] http://openstack.fr
[3] http://www.meetup.com/OpenStack-France/
[4] https://www.openstack.org/marketplace/training/
[^] # Re: Le gros point noir d'OpenStack
Posté par MaxPower . En réponse à la dépêche Présentation d’OpenStack. Évalué à 2.
Dans ce cas, il semble que le problème soit corrigé dans la dernière version de la documentaton (Liberty)
http://docs.openstack.org/liberty/install-guide-ubuntu/
[^] # 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
[^] # Re: Contribuer à OpenStack bénévolement est devenu impossible.
Posté par MaxPower . En réponse à la dépêche Présentation d’OpenStack. Évalué à 5.
Ca varie d'un driver à l'autre. Ca peut aussi venir d'un problème de configuration.
Dans certains cas on pouvait se retrouver avec des volumes en état "error" avec une impossibilité de les supprimer. On était donc obligé de faire le ménage en base de données directement mais fort heureusement ça à bien évolué depuis.
Il reste néanmoins qu'il faut une équipe solide pour faire de l'OpenStack en prod, bien tester, et ne pas sauter sur la dernière version dès qu'elle sort ;)
# Contribuer à OpenStack bénévolement est devenu impossible.
Posté par MaxPower . En réponse à la dépêche Présentation d’OpenStack. Évalué à 10.
Bonjour à toutes et à tous,
C'est mon premier post sur LinuxFr, j'arpente pourtant ces colonne depuis fort longtemps, mais ce sujet m'a décider à franchir le pas sous la forme d'un coup de gueule. (drôle d'entrée en matière :)
J'ai contribué à OpenStack sur les projets Nova et Cinder sur les versions Folsom, Grizzly et Havana.
A cette époque, la communauté était plus petite et surtout plus fournie en "vrai" contributeurs individuels.
Non pas que je déplore l'engouement des grands groupes pour ce projet magnifique, OpenStack ne serait pas ce qu'il est sans eux, mais il est extrèmement difficile aujourd'hui de faire entrer quoique ce soit en son sein.
Je vais prendre l'exemple de Cinder (mais c'est pareil dans les autres projets).
Aujourd'hui, un driver cinder se résume (pour faire simple) à interfacer l'API d'un système de stockage (quel qu'il soit) avec Cinder. Créer un binding, en gros, entre ces deux monde.
1) Avant même de commencer à écrire la moinde ligne, il faut créer un blueprint (proposition de votre fonctionnnalité auprès de la communauté). C'est très compliqué aujourd'hui de créer ce blueprint, c'est extrèment structuré, il faut passer un temps monstre à discuter avec les CoreDev pour etre certain de ne rien oublier et de faire ça dans les formes.
2) Il faut de votre blueprint soit accepté par les CoreDev. Il faut donc passer encore du temps à faire du lobbying auprès des CoreDev (payer des bières peut aider ;). Mais vous n'avez toujours pas commencé à coder.
3) Votre blueprint est accepté, super, vous avez maintenant le droit de pousser du code.
Ici, c'est du classique au niveau des choses requises pour que votre code soit mergé:
4) La revue de code (c'est là une des raisons qui m'a décidé à arrêter de contribuer sur ce projet)
Pour rappel, je suis un contributeur individuel et bénévole, c'est à dire que je ne suis pas payé (par un grand groupe) pour contribuer à OpenStack, je le fait simplement parce que j'aime ce projet, que j'ai l'envie de le faire et je le fais sur mon temps libre.
Le suivi de votre revue de code est très importante, tout contributeur peu participer à la revue du code de n'importe qui.
Vous aller être questionner sur la pertinance d'un bout de code, on va peut-être vous apprendre des choses ou vous dire que telle fonction existe déja dans cinder.common
Il faut répondre aux questions, expliquer, accepter de changer etc … du classique.
Sauf qu'il m'a été reprocher de ne pas répondre suffisamant vite (dans la journée). Excusez moi de bosser …
5) Infrastructure de tests d'intégration (CI)
C'est relativement récent, je ne sais plus exactement sur quelle release c'est arrivé.
Dorénavant, chaque driver doit fournir une infrastructure de tests d'intégration pour son driver.
Encore une fois, pour des grands groupes, aucun problème pour payer quelques dizaines d'instances sur AWS ou bien monter une infrastructure en propre.
Mais quand est-il des "petits" projets ? Quand est-il des drivers déja présents dans OpenStack ?
Et bien pour les petits projets, c'est très dur, voir impossible.
Pour les drivers déja présents dans OpenStack qui n'ont pas mis en place cette infrastructure de tests, il ont purement et simplement étés supprimés !
Qu'OpenStack décide d'avoir une polique visant à fournir des drivers de qualité, peux se comprendre.
Mais qu'on laisse les petits projets exister, pourquoi ne pas avoir créer un répertoire 3th-party-drivers contenant les drivers qui ne couvrent pas entièrement les pré-requis ?
Qu'est ce qu'il reste aux vrai contributeurs individuel ? Bug Triage ? Bug Fixing ? Mais aucune nouvelle features ? Ecoeurant …
Aujourd'hui, je suis toujours utilisateur d'OpenStack, je le modifie, je l'améliore mais tout ça dans mon coin et ne commit plus rien … c'est moche.