Les APIs OpenStack
Nathan Castelein
Cloud Software Engineer
28 Novembre 2019
Brève présentation
 Since 2013
 hubiC, RunAbove, Public Cloud
 Travaille autour d’OpenStack depuis
2013
• En tant qu’utilisateur, et non contributeur
 En charge de l’équipe Integration
• Pour le produit Public Cloud
 Un peu de maitrise en Go et Perl
2
 Quelques passions diverses et variées
en dehors d’OVH
• Dont un groupe de cheerleading
OpenStack
3
OpenStack
 OpenStack software controls large pools of compute, storage, and networking resources throughout
a datacenter, managed through a dashboard or via the OpenStack API. OpenStack works
with popular enterprise and open source technologies making it ideal for heterogeneous
infrastructure.
 Un ensemble de composants fonctionnant dans un écosystème commun
 De nombreuses briques existent
• Core functionalities
4
5
6
OpenStack
illustré
7
8
Intéragir
avec
OpenStack
9
Intéragir avec OpenStack – Le Manager OVH
10
Intéragir avec OpenStack – API OVH
11
Intéragir avec OpenStack – OpenStack Horizon
12
Intéragir avec OpenStack – OpenStack CLI
13
Intéragir avec OpenStack – Outils Opensource
14
Intéragir avec OpenStack – Point commun
15
 Tous ces outils communiquent avec les composants OpenStack aux travers d’APIs
 Chaque composant OpenStack expose au moins une API – ce qu’il y a dans un composant ne vous
regarde pas !
Les APIs
OpenStack
16
Les APIs
17
 Chaque composant propose sa propre API, ses propres routes, parfois son propre fonctionnement
Les APIs – Ne pas se perdre
18
 Comment s’y retrouver ?
 Comment connaitre les URLs, les composants disponibles, etc. ?
 Grace à Keystone !
Keystone API
19
 Une API pour les gouverner toutes
 Point d’entrée des APIs OpenStack
 Gère l’authentification, les
autorisations, le catalogue
 Comment contacter OpenStack ?
• Un projet Cloud
• Un user et un mot de passe
• Une seule URL: https://auth.cloud.ovh.net
S’authentifier au Keystone
 Comme certains ou certaines diraient…RTFM !
 La documentation OpenStack est très complète et contient souvent toutes les réponses sur
l’utilisation des APIs
 https://docs.openstack.org/api-quick-start/
20
Documentation OpenStack
21
API Version
22
API Version
 Chaque API est déployée avec certaines versions disponibles
 En fonction des versions, certains appels sont disponibles ou non
 Certains paramètres peuvent changer
 L’API vous permet de connaitre les versions disponibles, en appelant l’URL racine
• https://auth.cloud.ovh.net
 Dans le cas du Keystone OVH, la v2.0 est dépréciée, et la v3 est la version stable
 Exemple de récupération d’un token
• Le token est la base de l’authentification vers les autres composants OpenStack
23
Et ensuite ?
 On regarde le catalogue !
 Le catalogue contient la liste complète des services auxquels l’utilisateur ou l’utilisatrice authentifié
a accès au sein du projet donné
 Pour chaque service ou composant, le catalogue contient les URLs des APIs des régions où le service
est disponible
 Une région est un ensemble de composants OpenStack déployés dans une zone commune, pouvant
interagir les uns avec les autres
 Ne jamais faire de suppositions sur le catalogue, toujours le parcourir de manière intelligente
• Tous les bons SDKs s’en occupent pour vous !
24
Les régions OpenStack - Illustration
25
Expiration du token
 Chaque token a une durée de vie, et une date d’expiration
 Il faut réutiliser le token si vous faites plusieurs appels vers OpenStack
• Il y a un rate limit sur la création de tokens
• La durée de vie du token peut être variable selon les providers
26
Petite démo
27
Cas d’usage concret
 Vous avez une équipe de développeurs
front-ends
 Vous souhaitez démarrer une API en
arrivant le matin, et l’éteindre en fin de
journée
28
 Vous avez un projet Public Cloud
 Vous avez un user et un mot de passe
pour OpenStack
 Vous savez faire utiliser Curl
 Ou coder avec votre langage préféré et
un SDK
L’utilisation des SDKs
 Les SDKs intègrent les parcours de catalogue, le cache du token, etc.
 Comprendre comment fonctionnent les APIs OpenStack vous aider à développer de manière plus
efficace
 Tous les SDKs ne se valent pas ! Prenez le temps de les décortiquer un minimum
29
Features
APIs
OpenStack
30
Features disponibles sur la majorité des APIs
 Limit && Marker
 Liens de pagination
 Tri
 La tenue fortement
recommandée, voire
indispensable pour une
API !
31
La documentation
 Documentation
relativement complète
 Souvent accompagnée de
nombreux exemples
 Parfois manquante sur les
projets de plus petites
envergures
32
Le mode Admin
33
Les
mauvaises
surprises
34
Manque d’homogénéité entre les briques
35
Manque d’homogénéité entre les briques
36
 Design d’API différents
 Retours d’APIs encapsulés ou non
 Guidelines à moitié suivie
 Etc.
API version et micro-versions
37
API version et micro-versions
38
APIs
OpenStack
chez OVH
39
L’API OVH
 L’API OVH !
 « Passe-plat » vers les APIs OpenStack
 Simplifier son usage
 Mieux gérer le multi-région
 Manipuler OpenStack depuis un compte OVH
 …
40
Les produits qui se construisent au dessus
d’OpenStack
41
Et tant d’autres
 Nos outils d’administration
 Nos outils d’automatisation
 Etc.
42
Conclusion
43
Ce qu’il faut retenir
 Utilisez les APIs OpenStack
 Automatisez, construisez, testez
 Apprenez des APIs OpenStack, elles sont un bon moyen de comprendre le fonctionnement et les
concepts du produit
• Elles permettent aussi de comprendre les limites
 Elles sont aussi une bonne base pour apprendre à designer vos propres APIs
• Elles posent des standards et des concepts forts
 Elles sont opensource !
44
À vous de construire des grandes choses
45

Les APIs OpenStack

  • 1.
    Les APIs OpenStack NathanCastelein Cloud Software Engineer 28 Novembre 2019
  • 2.
    Brève présentation  Since2013  hubiC, RunAbove, Public Cloud  Travaille autour d’OpenStack depuis 2013 • En tant qu’utilisateur, et non contributeur  En charge de l’équipe Integration • Pour le produit Public Cloud  Un peu de maitrise en Go et Perl 2  Quelques passions diverses et variées en dehors d’OVH • Dont un groupe de cheerleading
  • 3.
  • 4.
    OpenStack  OpenStack softwarecontrols large pools of compute, storage, and networking resources throughout a datacenter, managed through a dashboard or via the OpenStack API. OpenStack works with popular enterprise and open source technologies making it ideal for heterogeneous infrastructure.  Un ensemble de composants fonctionnant dans un écosystème commun  De nombreuses briques existent • Core functionalities 4
  • 5.
  • 6.
  • 7.
  • 8.
  • 9.
  • 10.
    Intéragir avec OpenStack– Le Manager OVH 10
  • 11.
  • 12.
    Intéragir avec OpenStack– OpenStack Horizon 12
  • 13.
    Intéragir avec OpenStack– OpenStack CLI 13
  • 14.
    Intéragir avec OpenStack– Outils Opensource 14
  • 15.
    Intéragir avec OpenStack– Point commun 15  Tous ces outils communiquent avec les composants OpenStack aux travers d’APIs  Chaque composant OpenStack expose au moins une API – ce qu’il y a dans un composant ne vous regarde pas !
  • 16.
  • 17.
    Les APIs 17  Chaquecomposant propose sa propre API, ses propres routes, parfois son propre fonctionnement
  • 18.
    Les APIs –Ne pas se perdre 18  Comment s’y retrouver ?  Comment connaitre les URLs, les composants disponibles, etc. ?  Grace à Keystone !
  • 19.
    Keystone API 19  UneAPI pour les gouverner toutes  Point d’entrée des APIs OpenStack  Gère l’authentification, les autorisations, le catalogue  Comment contacter OpenStack ? • Un projet Cloud • Un user et un mot de passe • Une seule URL: https://auth.cloud.ovh.net
  • 20.
    S’authentifier au Keystone Comme certains ou certaines diraient…RTFM !  La documentation OpenStack est très complète et contient souvent toutes les réponses sur l’utilisation des APIs  https://docs.openstack.org/api-quick-start/ 20
  • 21.
  • 22.
  • 23.
    API Version  ChaqueAPI est déployée avec certaines versions disponibles  En fonction des versions, certains appels sont disponibles ou non  Certains paramètres peuvent changer  L’API vous permet de connaitre les versions disponibles, en appelant l’URL racine • https://auth.cloud.ovh.net  Dans le cas du Keystone OVH, la v2.0 est dépréciée, et la v3 est la version stable  Exemple de récupération d’un token • Le token est la base de l’authentification vers les autres composants OpenStack 23
  • 24.
    Et ensuite ? On regarde le catalogue !  Le catalogue contient la liste complète des services auxquels l’utilisateur ou l’utilisatrice authentifié a accès au sein du projet donné  Pour chaque service ou composant, le catalogue contient les URLs des APIs des régions où le service est disponible  Une région est un ensemble de composants OpenStack déployés dans une zone commune, pouvant interagir les uns avec les autres  Ne jamais faire de suppositions sur le catalogue, toujours le parcourir de manière intelligente • Tous les bons SDKs s’en occupent pour vous ! 24
  • 25.
    Les régions OpenStack- Illustration 25
  • 26.
    Expiration du token Chaque token a une durée de vie, et une date d’expiration  Il faut réutiliser le token si vous faites plusieurs appels vers OpenStack • Il y a un rate limit sur la création de tokens • La durée de vie du token peut être variable selon les providers 26
  • 27.
  • 28.
    Cas d’usage concret Vous avez une équipe de développeurs front-ends  Vous souhaitez démarrer une API en arrivant le matin, et l’éteindre en fin de journée 28  Vous avez un projet Public Cloud  Vous avez un user et un mot de passe pour OpenStack  Vous savez faire utiliser Curl  Ou coder avec votre langage préféré et un SDK
  • 29.
    L’utilisation des SDKs Les SDKs intègrent les parcours de catalogue, le cache du token, etc.  Comprendre comment fonctionnent les APIs OpenStack vous aider à développer de manière plus efficace  Tous les SDKs ne se valent pas ! Prenez le temps de les décortiquer un minimum 29
  • 30.
  • 31.
    Features disponibles surla majorité des APIs  Limit && Marker  Liens de pagination  Tri  La tenue fortement recommandée, voire indispensable pour une API ! 31
  • 32.
    La documentation  Documentation relativementcomplète  Souvent accompagnée de nombreux exemples  Parfois manquante sur les projets de plus petites envergures 32
  • 33.
  • 34.
  • 35.
  • 36.
    Manque d’homogénéité entreles briques 36  Design d’API différents  Retours d’APIs encapsulés ou non  Guidelines à moitié suivie  Etc.
  • 37.
    API version etmicro-versions 37
  • 38.
    API version etmicro-versions 38
  • 39.
  • 40.
    L’API OVH  L’APIOVH !  « Passe-plat » vers les APIs OpenStack  Simplifier son usage  Mieux gérer le multi-région  Manipuler OpenStack depuis un compte OVH  … 40
  • 41.
    Les produits quise construisent au dessus d’OpenStack 41
  • 42.
    Et tant d’autres Nos outils d’administration  Nos outils d’automatisation  Etc. 42
  • 43.
  • 44.
    Ce qu’il fautretenir  Utilisez les APIs OpenStack  Automatisez, construisez, testez  Apprenez des APIs OpenStack, elles sont un bon moyen de comprendre le fonctionnement et les concepts du produit • Elles permettent aussi de comprendre les limites  Elles sont aussi une bonne base pour apprendre à designer vos propres APIs • Elles posent des standards et des concepts forts  Elles sont opensource ! 44
  • 45.
    À vous deconstruire des grandes choses 45