Mise en place d’un cloud privé : pourquoi choisir OpenStack ?

L’agence d’expérience digitale SQLI dispose d’un Innovation Service Centre (ISC) dont je fais partie. Les équipes en France, basées à Bordeaux et à Nantes, développent au sein des locaux SQLI des applications métiers pour différentes organisations. Ces dernières assurent elles-mêmes l’hébergement en production. Les développeurs ont besoin de tester ce qu’ils produisent sur une infrastructure appartenant à SQLI avant toute livraison. Pour ce faire, deux solutions existent :

• Déployer les applications sur une infrastructure publique
• Déployer les applications sur une infrastructure privée

Pour assurer une forte confidentialité des données et de leur localisation géographique, nous avons fait le choix d’utiliser une infrastructure de Cloud privé, qui sera le sujet de cet article.  

Cloud : solutions existantes et limitations

Comme beaucoup d’entreprises, nous utilisions historiquement la solution VMware ESX, hébergée dans nos locaux et servant à la fois à Bordeaux et à Nantes. ISC a connu une croissance importante depuis plusieurs années. Nous avons, par conséquent, rencontré différentes contraintes et limitations sur cette plateforme. En voici quelques-unes :

Licences payantes

Il est nécessaire d’investir dans des licences. Le coût de ces dernières dépend de la taille de l'infrastructure en fonction du nombre de serveurs et de la puissance de calcul. Ce qui signifie que pour augmenter la taille d’une infrastructure VMware existante, il faut prévoir le budget qui augmente en fonction.

Mouvement DevOps

ISC a pris le virage DevOps et automatise un maximum d'actions pour les projets entrepris (création automatisée d’environnements, environnement de développement “dockerisé”, génération de bases de données à la volée, etc.). Dans ce contexte, de multiples outils et méthodologies émergent. Cela nécessite d’avoir une infrastructure compatible fournissant différents services d’automatisation. VMware fournit des API et un CLI (Command Line Interface) permettant d’automatiser certaines tâches, mais cela manque de praticité et de performance (réactivité, possibilités, prise en main, intégration dans un écosystème Linux, Unix, etc.).

Vie d’une machine virtuelle

Nous avons vécu une expérience avec le serveur Gitlab (gestionnaire de code source), pendant laquelle les Ops ont été contraints de corriger un problème en faisant du rétro-engineering directement sur l’environnement de production. Cette expérience nous a conduit à la conclusion suivante : après plusieurs mois ou même années de fonctionnement d’un environnement virtuel, celui-ci est souvent amené à être modifié/corrigé manuellement (suite à un bug rencontré ou à une montée de version par exemple). Toutes ces modifications/corrections sont rarement documentées de façon exhaustive et ne sont pas rejouées… ce qui amène progressivement à une perte de connaissances, et donc de maîtrise ! Pour ces principales raisons, nous nous sommes tournés vers un autre type d’hébergement : le Cloud privé.

Présentation du Cloud privé

Un cloud privé offre tous les mécanismes d’un cloud public à une différence près. Comme son nom l’indique, l’infrastructure physique (et donc sa maintenance) reste à la charge d’ISC et peut par conséquent être taillée sur mesure. Au lieu d’une facturation à la consommation ou via un abonnement sur une plateforme de Cloud public (exemples : AWS, Microsoft Azure, et Google Cloud Platform), une plateforme de type Cloud privé présente des coûts non négligeables :

• Le coût matériel (semblable à une solution comme VMware)
• Le coût de la montée en compétences sur la solution, intégrant des technologies plus complexes qu’une solution comme VMware ainsi qu’une philosophie différente

Nous avons pour cela choisi la solution open source OpenStack.

OpenStack est un projet open source créé initialement par Rackspace et la NASA. Il s’agit d’une galaxie de composants adaptables à n’importe quel type d’infrastructure (pas d’adhérence matérielle). Elle permet de gérer une infrastructure de type Cloud privé, sans coût de licence et donc « scalable » à souhait. La solution propose des API très puissantes qui offrent une automatisation à tous les niveaux : création de réseaux virtuels cloisonnés, déploiement de machines virtuelles, création de volumes persistants ou éphémères, etc. Tous ces services d’automatisation intègrent également des mécanismes de haute disponibilité permettant une continuité d’activité de la plateforme en cas d’incident. Parmi les technologies de haute disponibilité utilisables au cœur de cette plateforme, nous recensons KeepAlived, HAProxy, Pacemaker/Corosync, MariaDB Galera, et RabbitMQ.  

Intégration de la solution OpenStack

La solution OpenStack mise en place chez ISC est aujourd’hui utilisée pour tous les nouveaux projets. Elle permet à l’équipe Ops de fournir un service davantage réactif aux différentes équipes (Bordeaux et Nantes confondues). La création d’un nouvel environnement sur la plateforme OpenStack ne prend que quelques secondes, versus une heure sur l’ancienne plateforme VMware. De plus, cette création peut être très facilement scriptée. Tous nos outils internes sont de ce fait redéployables facilement : les documents d’installation ne sont désormais ni plus ni moins que des scripts (on parle alors d’Infra As Code). Nous avons également connecté notre plateforme d’intégration continue (PIC) à la solution OpenStack. Le bénéfice principal est que nous pouvons créer à la volée des environnements sans aucune intervention de l’équipe Ops, rendant ainsi les équipes davantage autonomes. Pour résumer quelques avantages et inconvénients d’OpenStack :

 

Conclusion

Une solution de type Cloud privé peut radicalement changer le métier d’un Ops/SysAdmin “classique” car non seulement les technologies ne sont plus les mêmes, mais la philosophie non plus. Une infrastructure Cloud, qu’elle soit privée ou publique, permet de gérer les environnements virtuels d’une manière différente : elle nous pousse à détruire régulièrement les environnements pour les recréer, rendre les déploiements immuables et reproductibles, et donc plus rapides et fiables. Cela fait prendre de nouveaux réflexes aux Ops, mais également à tous les développeurs qui peuvent se concentrer sur leur développement. Ils ne sont pas contraints de résoudre des problématiques systèmes sur leurs environnements, entraînant à terme des pertes de savoir. Le coût de migration vers ce type de solution n'est pas négligeable par rapport à la montée en compétences. Le choix doit donc être réfléchi en amont et fait en adéquation avec les besoins de l’entreprise.