Post on 13-Apr-2018
FORMATION OPENSTACKADMINISTRATEUR
CONCERNANT CES SUPPORTS DECOURS
CONCERNANT CES SUPPORTS DECOURS 1/2
Supports de cours réalisés par OsonesOsoneshttps://osones.com
Logo OsonesAUTEURS
Adrien Cunin Pierre Freund Jean-François Taltavull Romain Guichard
Kevin Lefevre
adrien.cunin@osones.compierre.freund@osones.com
jft@osones.com
romain.guichard@osones.comkevin.lefevre@osones.com
CONCERNANT CES SUPPORTS DECOURS 2/2
Copyright © 2014-2016 OsonesLicence : Sources :
Online :
Creative Commons BY-SA 4.0
https://github.com/Osones/Formations/
https://osones.com/formations.html
Licence Creative Commons BY-SA 4.0
INTRODUCTION
OBJECTIFS DE LA FORMATION :CLOUD
Comprendre les principes du cloud et sonintérêtConnaitre le vocabulaire inhérent au cloudAvoir une vue d’ensemble sur les solutionsexistantes en cloud public et privéPosséder les clés pour tirer parti au mieuxdu IaaSPouvoir déterminer ce qui est compatibleavec la philosophie cloud ou pasAdapter ses méthodes d’administrationsystème à un environnement cloud
OBJECTIFS DE LA FORMATION :OPENSTACK
Connaitre le fonctionnement du projetOpenStack et ses possibilitésComprendre le fonctionnement de chacundes composants d’OpenStackPouvoir faire les bons choix deconfigurationSavoir déployer manuellement un cloud
Savoir déployer manuellement un cloudOpenStack pour fournir du IaaSConnaitre les bonnes pratiques dedéploiement d’OpenStackÊtre capable de déterminer l’origine d’uneerreur dans OpenStackSavoir réagir face à un bug
PRÉ-REQUIS DE LA FORMATION
Compétences d’administration systèmeLinux tel qu’Ubuntu
Gestion des paquetsManipulation de fichiers de configurationet de servicesLVM et systèmes de fichiers
Notions :Virtualisation : KVM, libvirtRéseau : iptables, namespaces
Peut servir :À l’aise dans un environnement Python
LE CLOUD, VUE D'ENSEMBLE
DÉFINITION FORMELLE
CARACTÉRISTIQUESFournir un (des) service(s)...
Self serviceÀ travers le réseauMutualisation desressourcesÉlasticité rapideMesurabilité
Inspiré de la définition du NISThttp://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-
145.pdf
SELF SERVICEL'utilisateur accède directement au servicePas d'intermédiaire humainRéponses immédiatesCatalogue de services permettant leurdécouverte
À TRAVERS LE RÉSEAUL'utilisateur accède au service à travers leréseauLe fournisseur du service est distant duconsommateurRéseau = internet ou pasUtilisation de protocoles réseaux standards(typiquement : HTTP)
MUTUALISATION DES RESSOURCESUn cloud propose ses services à demultiples utilisateurs/organisations →Multi-tenantLes ressources sont disponibles en grandesquantitésLa localisation précise et le tauxd'occupation des ressources ne sont pasvisibles
ÉLASTICITÉ RAPIDEProvisionning et suppression des ressourcesquasi instantanéPossibilité d'automatiser ces actions descaling (passage à l'échelle)Virtuellement pas de limite à cette élasticité
MESURABILITÉL'utilisation des ressources cloud estmonitorée par le fournisseurLe fournisseur peut gérer son capacityplanning à partir de ces informationsL'utilisateur est facturé en fonction de sonusage précis des ressources
MODÈLESOn distingue :
modèles de service : IaaS, PaaS, SaaSmodèles de déploiement : public, privé,hybride
IAASInfrastructure as a ServiceInfrastructure :
Compute (calcul)Storage (stockage)Network (réseau)
Utilisateurs cibles : administrateurs(système, stockage, réseau)
PAAS
Platform as a ServiceEnvironnement permettant dedévelopper/déployer une applicationSpécifique à un language/framework(exemple : Python/Django)Ressources plus haut niveau quel'infrastructure, exemple : BDDUtilisateurs cibles : développeursd'application
SAASSoftware as a ServiceUtilisateurs cibles : utilisateursfinaux
QUELQUECHOSE AS A SERVICE ?Load balancing as a Service (Infra)Database as a Service (Platform)MonApplication as a Service(Software)etc.
LES MODÈLES DE SERVICE EN UNSCHÉMA
IaaS - PaaS - SaaS
CLOUD PUBLIC OU PRIVÉ ?À qui s'adresse le cloud ?
Public : tout le monde, disponible surinternetPrivé : à une organisation, disponible surson réseau
Concernant le cloud hybride : utilisation mixtede multiples clouds privés et/ou publics
CLOUD HYBRIDEConcept séduisantMise en œuvre a priori difficileCertains cas d'usages s'y prêtent trèsbien
Exemple : jobs de CICloud bursting
L'INSTANT VIRTUALISATIONMise au point.
La virtualisation est une technologiepermettant d'implémenter la fonctioncomputeUn cloud fournissant du compute peututiliser la virtualisationMais peut également utiliser :
Du bare-metalDes containers
LES APIS, LA CLÉ DU CLOUD
Interface de programmation (via le réseau,souvent HTTP)Frontière explicite entre le fournisseur(provider) et l'utilisateur (user)Définit la manière dont l'utilisateurcommunique avec le cloud pour gérer sesressourcesGérer : CRUD (Create, Read, Update, Delete)REST
POURQUOI LE CLOUD ? CÔTÉÉCONOMIQUE
Appréhender les ressources IT comme desservices “fournisseur”Faire glisser le budget “investissement”(Capex) vers le budget “fonctionnement”(Opex)Réduire les coûts en mutualisant lesressources, et éventuellement avec deséconomies d'échelleRéduire les délaisAligner les coûts sur la consommation réelledes ressources
POURQUOI LE CLOUD ? CÔTÉTECHNIQUE
Abstraire les couches basses (serveur,réseau, OS, stockage)S’affranchir de l’administration techniquedes ressources et services (BDD, pare-feux,load-balancing, etc.)Concevoir des infrastructures scalables à lavoléeAgir sur les ressources via des lignes de codeet gérer les infrastructures “comme ducode”
LE MARCHÉ
AMAZON WEB SERVICES (AWS), LELEADER
Lancement en 2006À l'origine : services web "e-commerce"pour développeursPuis : d'autres services pour développeursEt enfin : services d'infrastructureRécemment, SaaS
ALTERNATIVES IAAS PUBLICS ÀAWS
Google Cloud PlatformGoogle Cloud PlatformMicrosoft AzureMicrosoft AzureRackspaceDreamHostDigitalOceanEn France :
Cloudwatt
CloudwattNumergyOVHIkoulaScalewayOutscale
FAIRE DU IAAS PRIVÉOpenStackCloudStackEucalyptusOpenNebula
OPENSTACK EN QUELQUES MOTS
Naissance en 2010Fondation OpenStack depuis 2012Écrit en Python et distribué sous licenceApache 2.0Soutien très large de l'industrie etcontributions variées
LES CONCEPTS INFRASTRUCTUREAS A SERVICE
LA BASEInfrastructure :
ComputeStorageNetwork
RESSOURCES COMPUTEInstanceImageFlavor (gabarit)Paire de clé(SSH)
L'INSTANCEÉphémère, durée de vie typiquementcourteDédiée au computeNe doit pas stocker de donnéespersistantesDisque racine non persistant
IMAGE CLOUDImage disque contenant un OS déjàinstalléInstanciable à l'infiniSachant parler à l'API de metadata
API ... DE METADATAhttp://169.254.169.254Accessible depuis l'instanceFournit des informations relatives àl'instancecloud-init permet d'exploiter cette API
FLAVOR (GABARIT)Instance type chez AWSDéfinit un modèle d’instance en termes deCPU, RAM, disque (racine), disqueéphémèreLe disque éphémère a, comme le disqueracine, l’avantage d’être souvent local doncrapide
PAIRE DE CLÉClé publique + clé privée SSHLe cloud manipule et stocke la clé publiqueCette clé publique est utilisée pour donnerun accès SSH aux instances
RESSOURCES RÉSEAU 1/2Réseau L2
Port réseauRéseau L3
RouteurIP flottanteGroupe desécurité
RESSOURCES RÉSEAU 2/2Load Balancing as aServiceVPN as a ServiceFirewall as a Service
RESSOURCES STOCKAGELe cloud fournit deux types de stockage
BlockObjet
STOCKAGE BLOCKVolumesVolumes attachables à une instanceAccès à des raw devices type /dev/vdbPossibilité d’utiliser n’importe quel systèmede fichiersPossibilité d'utiliser du LVM, du chiffrement,etc.Compatible avec toutes les applicationsexistantes
"BOOT FROM VOLUME"Démarrer une instance avec un disque racine
sur un volumevolume
Persistance des données du disque racineSe rapproche du serveur classique
STOCKAGE OBJETPousser et retirer des objets dans uncontainer/bucketPas de hiérarchie des données, pas desystème de fichiersAccès par les APIsL’application doit être conçue pour tirerparti du stockage objet
ORCHESTRATIONOrchestrer la création et la gestion desressources dans le cloudDéfinition de l'architecture dans untemplateLes ressources créées à partir du templateforment la stack
BONNE PRATIQUES D'UTILISATION
HAUTE DISPONIBILITÉ (HA)Le control plane (les APIs) du cloud est HALes ressources provisionnées ne le sont pasforcément
PETS VS CATTLEComment considérer ses instances ?
PetCattle
INFRASTRUCTURE AS CODEAvec du code
Provisionner les ressources d'infrastructureConfigurer les dites ressources, notammentles instances
Le métier évolue : Infrastructure Developer
SCALING, PASSAGE À L'ÉCHELLEScale out plutôt que Scale up
Scale out : passage à l'échellehorizontalScale up : passage à l'échelle vertical
Auto-scaling
APPLICATIONS CLOUD READYStockent leurs données au bon endroitSont architecturées pour tolérer lespannesEtc.
Cf. http://12factor.net/
DERRIÈRE LE CLOUD
COMMENT IMPLÉMENTER UNSERVICE DE COMPUTE
VirtualisationContainersBare metal
IMPLÉMENTATION DU STOCKAGE :(SOFTWARE DEFINED STORAGE)
SDSAttentionAttention : ne pas confondre avec le sujetblock vs objet
Utilisation de commodity hardwarePas de RAID matériel
Pas de RAID matérielLe logiciel est responsable de garantir lesdonnéesLes pannes matérielles sont prises encompte et géréesLe projet CephCeph et le composant OpenStackOpenStackSwiftSwift implémentent du SDS
Voir aussi ScalityScality
SDS - THÉORÈME CAP
Consistency - Availability - Partition tolerance
OPENSTACK : LE PROJET
TOUR D'HORIZON
VUE HAUT NIVEAU
Version simple
HISTORIQUEDémarrage en 2010Objectif : le Cloud Operating System libreFusion de deux projets de Rackspace(Storage) et de la NASA (Compute)Logiciel libre distribué sous licence Apache2.0Naissance de la Fondation en 2012
LES RELEASES
Austin (2010.1)Bexar (2011.1), Cactus (2011.2), Diablo(2011.3)Essex (2012.1), Folsom (2012.2)Grizzly (2013.1), Havana (2013.2)Icehouse (2014.1), Juno (2014.2)Kilo (2015.1), Liberty (2015.2)Mitaka (2016.1), NewtonNewton (2016.2)Début 2017 : Ocata
STATISTIQUES : KILO1492 contributeurs (Liberty : 1933)169 organisations394 nouvelles fonctionnalités et 7257 bugscorrigés113 drivers/plugins792200 chaines traduites
Source :http://lists.openstack.org/pipermail/foundation-
board/2015-April/000050.html
QUELQUESSOUTIENS/CONTRIBUTEURS ...
Editeurs : Red Hat, HP, IBM, Suse,Canonical, Vmware, ...Constructeurs : Dell, Hitachi, Juniper, Cisco,NetApp, ...En vrac : NASA, Yahoo, OVH, Citrix, SAP,Rackspace, ...GoogleGoogle ! (depuis juillet 2015)
http://www.openstack.org/foundation/companies/
... ET UTILISATEURS
Tous les contributeurs précédemment citésEn France : CloudwattCloudwatt et NumergyNumergyWikimediaCERNPaypalComcastBMWEtc. Sans compter les implémentationsconfidentielles
http://www.openstack.org/user-stories/
LES DIFFÉRENTS SOUS-PROJETS
OpenStack Compute - NovaOpenStack (Object) Storage - SwiftOpenStack Block Storage - CinderOpenStack Networking - NeutronOpenStack Image Service - GlanceOpenStack Identity Service -KeystoneOpenStack Dashboard - HorizonOpenStack Telemetry - CeilometerOpenStack Orchestration - HeatOpenStack Database Service - Trove
LES DIFFÉRENTS SOUS-PROJETS(2)
Mais aussi :Bare metal (Ironic)Queue service (Zaqar)Data processing (Sahara)DNS service (Designate)Shared File Systems (Manila)Key management (Barbican)PaaS (Solum)Container (Magnum)
AutresLes clients (python-*client)
LES 4 OPENSOpen SourceOpen DesignOpen DevelopmentOpen Community
LA FONDATION OPENSTACKEntité de gouvernance principale du projetReprésentation juridique du projetLes membres du board sont issus desentreprises sponsors et élus par lesmembres individuelsTout le monde peut devenir membreindividuel (gratuitement)
LA FONDATION OPENSTACK
La fondation supporte le projet pardifférents moyens :
Événements : organisation (Summits) ouparticipation (OSCON, etc.)Infrastructure de développement(serveurs)Ressources humaines : marketing,release manager, quelques développeurs(principalement sur l’infrastructure)
500 organisations à travers le monde23000 membres individuels dans 160 pays
LA FONDATION OPENSTACK
Les principales entités de la fondation
INTERFACE WEB / DASHBOARD :HORIZON
Screenshot Horizon (Liberty)
RESSOURCES
Annonces/sécurité : openstack-announce@lists.openstack.orgDocumentation :
Gouvernance du projet :
Support :
openstack@lists.openstack.org#openstack@Freenode
SDK/APIs :
http://docs.openstack.org/
http://governance.openstack.org/
https://ask.openstack.org
http://developer.openstack.org/
RESSOURCESApplications : Actualités :
Blog officiel :
Planet : Superuser :
OpenStack Community WeeklyNewsletter
http://apps.openstack.org/
http://www.openstack.org/blog/http://planet.openstack.org
http://superuser.openstack.org/
NewsletterRessources commerciales :
entre autreshttp://www.openstack.org/marketplace/
RESSOURCES - COMMUNAUTÉFRANCOPHONE
Logo OpenStack-fr
Site web : Association des utilisateurs francophonesd’OpenStack : Meetups : Paris, Rhônes-Alpes, Toulouse,Montréal, etc.Présence à des événements tels que ParisOpen Source SummitCanaux de communication :
openstack-fr@lists.openstack.org#openstack-fr@Freenode
http://openstack.fr/
https://asso.openstack.fr/
FONCTIONNEMENT INTERNE ETMODE DE DÉVELOPPEMENT
ARCHITECTURE
Vue détaillée des services
IMPLÉMENTATIONChaque sous-projet est découpé enplusieurs servicesCommunication entre les services : AMQP(RabbitMQ)Base de données : relationnelle SQL(MySQL/MariaDB)Réseau : OpenVSwitchEn général : réutilisation de composantsexistants
existantsTout est développé en Python (Django pourla partie web)APIs supportées : OpenStack et équivalentAWSMulti tenancy
DÉVELOPPEMENT DU PROJET : ENDÉTAILS
Ouvert à tous (individuels et entreprises)Cycle de développement de 6 mois débutépar un (design) summitDéveloppement hyper actif : 25000 commitsdans LibertySur chaque patch proposé :
Revue de code (peer review) : GerritIntégration continue (continousintegration) : Jenkins, Zuul, etc.
Outils : Launchpad → Storyboard(blueprints, bugs) + Git + GitHub (code)
DÉVELOPPEMENT DU PROJET : ENDÉTAILS
Workflow de changements dans OpenStack
CYCLE DE DÉVELOPPEMENT : 6MOIS
Le planning est publié, exemple :
Milestone releasesFreezes : FeatureProposal, Feature, StringRC releasesStable releasesCe modèle de cycle de développement a évolué
https://releases.openstack.org/ocata/schedule.html
Ce modèle de cycle de développement a évoluédepuis le début du projetCas particulier de Swift et de plus en plus decomposantsDepuis Liberty, chaque composant gère son propreversionnement
VERSIONNEMENT DEPUIS LIBERTYSemantic versioningChaque projet est indépendantDans le cadre du cycle de releasenéanmoinshttp://releases.openstack.org/
LE NOUVEAU MODÈLE “BIG TENT”Évolutions récemment implémentéesObjectif : résoudre les limitations du précédent modèleincubation/intégréInclusion a priori de l’ensemble de l’écosystème OpenStackPrograms → Project Teams
Utilisation de tags factuels et objectifshttp://governance.openstack.org/reference/projects/index.html
https://www.openstack.org/software/project-navigator/
QUI CONTRIBUE ?Active Technical ContributorATC : personne ayant au moins unecontribution récente dans un projetOpenStack reconnuLes ATC sont invités aux summits et ont ledroit de voteCore reviewer : ATC ayant les droits pourvalider les patchs dans un projetProject Team Lead (PTL) : élu par les ATCs
Project Team Lead (PTL) : élu par les ATCsde chaque projetStackalytics fournit des statistiques sur lescontributions
http://stackalytics.com/
OÙ TROUVER DES INFORMATIONSSUR LE DÉVELOPPEMENT
D’OPENSTACK
Principalement sur le wiki
Les blueprints et bugs surLaunchpad/StoryBoard
Comment contribuer
https://wiki.openstack.org
https://launchpad.net/openstackhttps://storyboard.openstack.orghttp://specs.openstack.org/
http://docs.openstack.org/contributor-guide/
OÙ TROUVER DES INFORMATIONSSUR LE DÉVELOPPEMENT
D’OPENSTACK
Les patchs proposés et leurs reviews sontsur Gerrit
L’état de la CI (entre autres)
Le code (Git) et les tarballs sont disponibles
https://review.openstack.org
http://status.openstack.org
https://git.openstack.orghttp://tarballs.openstack.org/
OPENSTACK INFRAÉquipe projet en charge de l’infrastructurede développement d’OpenStackTravaille comme les équipes de devd’OpenStack et utilise les mêmes outilsRésultat : une infrastructure entièrementopen source et développée comme tel
OPENSTACK SUMMIT
Aux USA jusqu’en 2013Aujourd’hui : alternance Amérique de Nordet Asie/EuropeQuelques dizaines au début à 6000participants aujourd’huiEn parallèle : conférence (utilisateurs,décideurs) et Design Summit(développeurs)Détermine le nom de la release : lieu/ville àproximité du SummitUpstream Training
EXEMPLE DU SUMMIT D’AVRIL2013 À PORTLAND
Photo : Adrien Cunin
EXEMPLE DU SUMMIT D’OCTOBRE2015 À TOKYO
Photo : Elizabeth K. Joseph, CC BY 2.0,Flickr/pleia2
EXEMPLE DU SUMMIT D’OCTOBRE2015 À TOKYO
Photo : Elizabeth K. Joseph, CC BY 2.0,Flickr/pleia2
EXEMPLE DU SUMMIT D’OCTOBRE2015 À TOKYO
Photo : Elizabeth K. Joseph, CC BY 2.0,Flickr/pleia2
EXEMPLE DU SUMMIT D’OCTOBRE2015 À TOKYO
Photo : Elizabeth K. Joseph, CC BY 2.0,Flickr/pleia2
TRADUCTION
La question de la traduction est dorénavantprise en compte (officialisation de l’équipei18n)Seules certaines parties sont traduites,comme HorizonLa traduction française est aujourd’hui unedes plus avancéesUtilisation d'une plateforme web basée surZanata : https://translate.openstack.org/
DEVSTACK : FAIRE TOURNERRAPIDEMENT UN OPENSTACK
UTILITÉ DE DEVSTACKDéployer rapidement un OpenStackUtilisé par les développeurs pour testerleurs changementsUtilisé pour faire des démonstrationsUtilisé pour tester les APIs sans sepréoccuper du déploiementNe doit PAS être utilisé pour de laproduction
FONCTIONNEMENT DE DEVSTACKUn script shell qui fait tout le travail :stack.shUn fichier de configuration : local.confInstalle toutes les dépendances nécessaires(paquets)Clone les dépôts git (branche master pardéfaut)Lance tous les composants dans un screen
CONFIGURATION : LOCAL.CONFExemple
[[local|localrc]]ADMIN_PASSWORD=secreteDATABASE_PASSWORD=$ADMIN_PASSWORDRABBIT_PASSWORD=$ADMIN_PASSWORDSERVICE_PASSWORD=$ADMIN_PASSWORDSERVICE_TOKEN=a682f596-76f3-11e3-b3b2-e716f9080d50#FIXED_RANGE=172.31.1.0/24#FLOATING_RANGE=192.168.20.0/25#HOST_IP=10.3.4.5
CONSEILS D’UTILISATIONDevStack installe beaucoup de choses sur lamachineIl est recommandé de travailler dans une VMPour tester tous les composants OpenStackdans de bonnes conditions, plusieurs Go deRAM sont nécessairesL’utilisation de Vagrant est conseillée
UTILISER OPENSTACK
LE PRINCIPEToutes les fonctionnalités sont accessiblespar l’APILes clients (y compris Horizon) utilisent l’APIDes crédentials sont nécessaires
API OpenStack : utilisateur + mot depasse + tenant (+ domaine)API AWS : access key ID + secret accesskey
LES APIS OPENSTACKUne API par service OpenStack
Chaque API est versionnée, la rétro-compatibilité est assuréeRESTCertains services sont aussi accessibles viaune API différente compatible AWS
http://developer.openstack.org/api-ref.html
AUTHENTIFICATION ET CATALOGUEDE SERVICE
Une fois authentifié, récupération d’unjeton (token)Récupération du catalogue de servicesPour chaque service, un endpoint HTTP(API)
ACCÈS AUX APISDirect, en HTTP, via des outils comme curlAvec une bibliothèque
Les implémentations officielles enPythonOpenStackSDKD’autres implémentations, y comprispour d’autres langages (exemple :jclouds)Shade
ShadeAvec les outils officiels en ligne decommandeAvec Horizon
CLIENTS OFFICIELS
Le projet fournit des clients officiels :python-PROJETclientBibliothèques PythonOutils CLI
L’authentification se fait en passant lescredentials par paramètres ou variablesd’environnementL’option --debug affiche lacommunication HTTP
OPENSTACK CLIENTClient CLI unifiéCommandes du type openstack <ressource><action >Vise à remplacer à terme les clientsspécifiquesPermet une expérience utilisateur plushomogèneFichier de configuration clouds.yaml
DÉPLOYER ET OPÉRER OPENSTACK
CE QU’ON VA VOIRInstaller OpenStack à la main
Donc comprendre son fonctionnementPasser en revue chaque composant plus endétailsTour d’horizon des solutions dedéploiement
http://docs.openstack.org/newton/install-guide-ubuntu/
ARCHITECTURE DÉTAILLÉE
Vue détaillée des services
ARCHITECTURE SERVICES
Machines "physiques" et services
QUELQUES ÉLÉMENTS DECONFIGURATION GÉNÉRAUX
Tous les composants doivent êtreconfigurés pour communiquer avecKeystoneLa plupart doivent être configurés pourcommuniquer avec MySQL/MariaDB etRabbitMQLes composants découpés en plusieurs
Les composants découpés en plusieursservices ont parfois un fichier deconfiguration par serviceLe fichier de configuration policy.jsonprécise les droits nécessaires pour chaqueappel API
SYSTÈME D’EXPLOITATIONOS Linux avec PythonHistoriquement : UbuntuRed Hat s’est largement rattrapéSUSE, Debian, CentOS, etc.
PYTHON
Logo PythonOpenStack est aujourd’hui compatiblePython 2.7Afin de ne pas réinventer la roue, beaucoupde dépendances sont nécessairesUn travail de portage vers Python 3 est encours
BASE DE DONNÉESPermet de stocker la majorité des donnéesgérées par OpenStackChaque composant a sa propre baseOpenStack utilise l’ORM PythonSQLAlchemySupport théorique équivalent à celui deSQLAlchemyMySQL/MariaDB est l’implémentation laplus largement testée et utilisée
plus largement testée et utiliséeSQLite est principalement utilisé dans lecadre de tests et démoCertains déploiements fonctionnent avecPostgreSQL
POURQUOI L’UTILISATION DESQLALCHEMY
Logo SQLAlchemySupport de multiplesBDDGestion des migrations
Logo MySQL
PASSAGE DE MESSAGESAMQP : Advanced Message QueuingProtocolMessages, file d’attente, routageLes processus OpenStack communiquentvia AMQPPlusieurs implémentations possibles : Qpid,0MQ, etc.RabbitMQ par défaut
RABBITMQ
Logo RabbitMQRabbitMQ est implémenté en ErlangUne machine virtuelle Erlang est doncnécessaire
“HELLO WORLD” RABBITMQ
Illustration simple du fonctionnement deRabbitMQ
KEYSTONE : AUTHENTIFICATION,AUTORISATION ET CATALOGUE DE
SERVICES
PRINCIPESAnnuaire des utilisateurs et desgroupesListe des tenants/projetsCatalogue de servicesGère l’authentification et l’autorisationSupport des domaines dans l’API v3Fournit un token à l’utilisateur
API
API v2 admin : port 35357API v2 utilisateur : port 5000API v3 unifiée : port 5000L'API v2 est dépréciéeGère utilisateurs, groupes, domaines (APIv3)Les utilisateurs ont des rôles sur des tenants(projets)Les services du catalogue sont associés àdes endpoints
SCÉNARIO D’UTILISATION TYPIQUE
Interactions avec Keystone
INSTALLATION ET CONFIGURATIONPaquet : keystoneBackends : choix de SQL ou LDAP (ou AD)Backends tokens : SQL, Memcache, aucunConfiguration d’un token ADMIN pour laconfiguration initialeCréation des services et endpointsCréation d'utilisateurs, groupes, domaines
ENREGISTRER UN SERVICE ET SONENDPOINT
Il faut renseigner l’existence des différentsservices (catalogue) dans Keystone :
$ keystone service-create --name=cinderv2 --type=volumev2 \ --description="Cinder Volume Service V2"$ keystone endpoint-create \ --region=myRegion --service-id=... --publicurl=http://controller:8776/v2/%\(tenant_id\)s \ --internalurl=http://controller:8776/v2/%\(tenant_id\)s \ --adminurl=http://controller:8776/v2/%\(tenant_id\)s
TESTER$ keystone service-list...$ keystone user-list...$ keystone token-get...
NOVA : COMPUTE
PRINCIPESGère les instancesLes instances sont créées à partir desimages fournies par GlanceLes interfaces réseaux des instances sontassociées à des ports NeutronDu stockage block peut être fourni auxinstances par Cinder
INTERACTIONS AVEC LES AUTRESCOMPOSANTS
Instance, image et volume
PROPRIÉTÉS D’UNE INSTANCEÉphémère, a priori non hautementdisponibleDéfinie par une flavorConstruite à partir d’une imageOptionnel : attachement de volumesOptionnel : boot depuis un volumeOptionnel : une clé SSH publiqueOptionnel : des ports réseaux
APIGère :
InstancesFlavors (types d’instance)Indirectement : images, security groups(groupes de sécurité), floating IPs (IPsflottantes)
Les instances sont redimensionnables et
migrables d’un hôte physique à un autre.
LES GROUPES DE SÉCURITÉ
Équivalent à un firewall devant chaqueinstanceUne instance peut être associée à un ouplusieurs groupes de sécuritéGestion des accès en entrée et sortieRègles par protocole (TCP/UDP/ICMP) et parportCible une adresse IP, un réseau ou un autregroupe de sécurité
FLAVORS
GabaritÉquivalent des “instance types” d’AWSDéfinit un modèle d’instance en termes deCPU, RAM, disque (racine), disqueéphémèreUn disque de taille nul équivaut à prendre lataille de l’image de baseLe disque éphémère a, comme le disqueracine, l’avantage d’être souvent local doncrapide
NOVA API
Double rôleAPI de manipulation des instances parl’utilisateurAPI à destination des instances : API demetadataL’API de metadata doit être accessible àl’adresse http://169.254.169.254/L’API de metadata fournit des informationsde configuration personnalisées à chacunedes instances
NOVA COMPUTEPilote les instances (machines virtuelles ouphysiques)Tire partie de libvirt ou d’autres APIscomme XenAPIDrivers : libvirt (KVM, LXC, etc.), XenAPI,VMWare vSphere, IronicPermet de récupérer les logs de la consoleet une console VNC
NOVA SCHEDULERService qui distribue les demandes d’instancessur les nœuds computeFilter, Chance, Multi SchedulerFiltres, par défaut :AvailabilityZoneFilter,RamFilter,ComputeFilterTri par poids, par défaut : RamWeigher
LE SCHEDULER NOVA EN ACTION
Fonctionnement de nova-scheduler
NOVA CONDUCTORService facultatif qui améliore la sécuritéFait office de proxy entre les nœudscompute et la BDDLes nœuds compute, vulnérables, n’ontdonc plus d’accès à la BDD
TESTER$ nova list...$ nova create...
GLANCE : REGISTRE D’IMAGES
PRINCIPESRegistre d’images (et des snapshots)Propriétés sur les imagesEst utilisé par Nova pour démarrer desinstancesPeut utiliser Swift comme back-end destockage
PROPRIÉTÉS DES IMAGES DANSGLANCE
L’utilisateur peut définir un certain nombre depropriétés dont certaines seront utilisées lors
de l’instanciation
Type d’imageArchitectureDistributionVersion de la distributionEspace disque minimumRAM minimumPublique ou non
TYPES D’IMAGESGlance supporte un large éventail de types
d’images, limité par le support del’hyperviseur sous-jacent à Nova
rawqcow2amivmdkiso
BACKENDSSwift ou S3CephHTTPRépertoire local
INSTALLATIONPaquet glance-api : fournit l’APIPaquet glance-registry : démon du registred’images en tant que tel
TESTER$ glance image-list...$ glance image-create...
NEUTRON : RÉSEAU EN TANT QUESERVICE
PRINCIPES
Software Defined Networking (SDN)Auparavant Quantum et nova-networkIP flottantes, groupes de sécuriténeutron-server : fournit l’APIAgent DHCP : fournit le service de DHCPpour les instancesAgent L3 : gère la couche 3 du réseau, leroutagePlugin : OpenVSwitch par défaut, d’autresimplémentations libres/propriétaires,logicielles/matérielles existent
FONCTIONNALITÉSSUPPLÉMENTAIRES
Outre les fonctions réseau de base niveaux 2et 3, Neutron peut fournir d’autres services :
Load Balancing (HAProxy, ...)Firewall (vArmour, ...) : diffère des groupesde sécuritéVPN (Openswan, ...) : permet d’accéder à unréseau privé sans IP flottantes
Ces fonctionnalités se basent également surdes plugins
APIL’API permet notamment de manipuler ces
ressources
Réseau (network) : niveau 2Sous-réseau (subnet) : niveau 3Port : attachable à une interface sur uneinstance, un load-balancer, etc.Routeur
PLUGINS ML2Modular Layer 2OpenVSwitchOpenDaylightContrail, OpenContrailNuage NetworksVMWare NSXcf. OpenFlow
IMPLÉMENTATIONNeutron tire partie des namespaces réseauxdu noyau Linux pour permettre l’IPoverlappingLe proxy de metadata est un composant quipermet aux instances isolées dans leurréseau de joindre l’API de metadata fourniepar Nova
SCHÉMA
Vue utilisateur du réseau
SCHÉMA
Vue infra du réseau
CINDER : STOCKAGE BLOCK
PRINCIPESAuparavant nova-volumeFournit des volumes (stockage block)attachables aux instancesGère différents types de volumeGère snapshots et backups de volumesAttachement via iSCSI par défaut
DU STOCKAGE PARTAGÉ ?Cinder n’est paspas une solution de stockagepartagé comme NFSLe projet OpenStack Manila a pour objectifd’être un NFS as a ServiceAWS n’a introduit une telle fonctionnalitéque récemment
UTILISATIONVolume supplémentaire (et stockagepersistant) sur une instanceBoot from volume : l’OS est sur le volumeFonctionnalité de backup vers un objectstore (Swift ou Ceph)
INSTALLATIONPaquet cinder-api : fournit l’APIPaquet cinder-volume : création et gestiondes volumesPaquet cinder-scheduler : distribue lesdemandes de création de volumePaquet cinder-backup : backup vers unobject store
BACKENDSUtilisation de plusieurs backends enparallèle possibleLVM (par défaut)GlusterFSCephSystèmes de stockage propriétaires typeNetAppDRBD
HORIZON : DASHBOARD WEB
PRINCIPESUtilise les APIs existantes pour fournir uneinterface utilisateurHorizon est un module DjangoOpenStack Dashboard est l’implémentationofficielle de ce module
Logo du framework web Python Django
CONFIGURATIONlocal_settings.pyLes services apparaissent dans Horizon s’ilssont répertoriés dans le catalogue deservices de Keystone
UTILISATIONUne zone “admin”restreinteUne interface par tenant
SWIFT : STOCKAGE OBJET
PRINCIPESSDS : Software Defined StorageUtilisation de commodity hardwareThéorème CAP : on en choisit deuxAccès par les APIsArchitecture totalement acentréePas de base de données centrale
IMPLÉMENTATION
Proxy : serveur API par lequel passenttoutes les requêtesObject server : serveur de stockageContainer server : maintient des listesd’objects dans des containersAccount server : maintient des listes decontainers dans des accountsChaque objet est répliqué n fois (3 pardéfaut)
LE RINGProblème : comment décider quelle donnéeva sur quel object serverLe ring est découpé en partitionsOn situe chaque donnée dans le ring afin dedéterminer sa partitionUne partition est associée à plusieursserveurs
SCHÉMA
Architecture Swift
CEILOMETER : COLLECTE DEMÉTRIQUES
SURVEILLER L’UTILISATION DE SONINFRASTRUCTURE AVEC
CEILOMETER
Indexe différentes métriques concernantl’utilisation des différents services du cloudFournit des APIs permettant de récupérerces donnéesBase pour construire des outils defacturation (exemple : CloudKitty)Utilise MongoDB (par défaut) pour lestockage
GNOCCHI : TIME-SERIES DATABASEPourquoi Gnocchi ? Palier aux problème descalabilité de CeilometerInitié par des développeurs de Ceilometer etintégré à l’équipe projet CeilometerBack-end remplaçant MongoDB pourCeilometer
HEAT : ORCHESTRATION DESRESSOURCES
ORCHESTRER SONINFRASTRUCTURE AVEC HEAT
Équivalent d’Amazon Cloud FormationOrchestrer les ressources compute, storage,network, etc.Doit se coupler avec cloud-initDescription de son infrastructure dans unfichier template, format JSON (CFN) ouYAML (HOT)
AUTOSCALING AVEC HEATHeat implémente la fonctionnalité
d’autoscaling
Se déclenche en fonction des alarmesproduites par CeilometerEntraine la création de nouvelles instances
UN TEMPLATE HOTparameters - resources - outputs
heat_template_version: 2013-05-23description: Simple template to deploy a single compute instanceresources: my_instance: type: OS::Nova::Server properties: key_name: my_key image: F18-x86_64-cfntools flavor: m1.small
FONCTIONNALITÉS AVANCÉES DEHEAT
Nested stacksEnvironmentsProviders
CONSTRUIRE UN TEMPLATE ÀPARTIR D’EXISTANT
Multiples projets en cours de développement
Flame (Cloudwatt)HOT builderMerlin
TROVE : DATABASE AS A SERVICE
PRINCIPEFournit des bases de donnéesrelationnelles, à la AWS RDSA vocation à supporter des bases NoSQLaussiGère notamment MySQL/MariaDB commeback-endSe repose sur Nova pour les instances danslesquelles se fait l’installation d’une BDD
SERVICEStrove-api : APItrove-taskmanager : gère les instances BDDtrove-guestagent : agent interne àl’instance
DESIGNATE : DNS AS A SERVICE
PRINCIPEÉquivalent d’AWS Route 53Gère différents backends : BIND,etc.
QUELQUES AUTRES COMPOSANTSINTÉRESSANTS
IRONICAnciennement Nova bare-metalPermet le déploiement d’instances sur desmachines physiques (plutôt que VMs)Repose sur des technologies telles que PXE,TFTP
OSLO, OU OPENSTACK COMMONOslo contient le code commun à plusieurscomposants d’OpenStackSon utilisation est transparente pour ledéployeur
ROOTWRAPWrapper pour l’utilisation de commandesen rootConfiguration au niveau de chaquecomposant qui l’utilisePermet d’écrire des filtres sur lescommandes
TRIPLEO
OpenStack On OpenStackObjectif : pouvoir déployer un cloudOpenStack (overcloud) à partir d’un cloudOpenStack (undercloud)Autoscaling du cloud lui-même :déploiement de nouveaux nœuds computelorsque cela est nécessaireFonctionne conjointement avec Ironic pourle déploiement bare-metal
TEMPESTSuite de tests d’un cloud OpenStackEffectue des appels à l’API et vérifie lerésultatEst très utilisé par les développeurs vial’intégration continueLe déployeur peut utiliser Tempest pourvérifier la bonne conformité de son cloudCf. aussi Rally
BONNES PRATIQUES POUR UNDÉPLOIEMENT EN PRODUCTION
QUELS COMPOSANTS DOIS-JEINSTALLER ?
Keystone est indispensableL’utilisation de Nova va de paire avecGlance et NeutronCinder s’avérera souvent utileCeilometer et Heat vont souvent ensembleSwift est indépendant des autrescomposantsNeutron peut parfois être utiliséindépendamment (ex : avec oVirt)
http://docs.openstack.org/arch-design/
PENSER DÈS LE DÉBUT AUX CHOIXSTRUCTURANTS
Distribution et méthode de déploiementHyperviseurRéseau : quelle architecture et quelsdriversPolitique de mise à jour
LES DIFFÉRENTES MÉTHODESD’INSTALLATION
DevStack est à oublier pour la productionTripleO est très complexeLe déploiement à la main comme vuprécédemment n’est pas recommandé carpeu maintenableDistributions OpenStack packagées etprêtes à l’emploiDistributions classiques et gestion deconfigurationDéploiement continu
MISES À JOUR ENTRE VERSIONSMAJEURES
OpenStack supporte les mises à jour N →N+1Swift : très bonne gestion en mode rollingupgradeAutres composants : tester préalablementavec vos donnéesLire les release notesCf. articles de blog du CERN
MISES À JOUR DANS UNE VERSIONSTABLE
Fourniture de correctifs de bugs majeurs etde sécuritéOpenStack intègre ces correctifs sous formede patchs dans la branche stablePublication de point releases intégrant cescorrectifs issus de la branche stableDurée variable du support des versionsstables, dépendant de l’intérêt desintégrateurs
ASSIGNER DES RÔLES AUXMACHINES
Beaucoup de documentations font référence àces rôles :
Controller node : APIs, BDD, AMQPNetwork node : DHCP, routeur, IPsflottantesCompute node : Hyperviseur/pilotage desinstances
Ce modèle simplifié n’est pas HA.
HAUTE DISPONIBILITÉHaute disponibilité du IaaS
MySQL/MariaDB, RabbitMQ : HA classique(Galera, Clustering)Les services APIs sont stateless et HTTP :scale out et load balancersLa plupart des autres services OpenStacksont capables de scale out également
HAUTE DISPONIBILITÉ DE L’AGENTL3 DE NEUTRON
Plusieurs solutions et contournementspossiblesDepuis Juno : Distributed Virtual Router(DVR)
CONSIDÉRATIONS POUR UNEENVIRONNEMENT DE PRODUCTION
Des URLs uniformes pour toutes les APIs :utiliser un reverse proxyApache/mod_wsgi pour servir les APIslorsque cela est possible (Keystone)Utilisation des quotasPrévoir les bonnes volumétries, notammentpour les données CeilometerMonitoringBackupQoS : en cours d’implémentation dansNeutron
Guide Operations :http://docs.openstack.org/openstack-
ops/content/
UTILISATION DES QUOTASLimiter le nombre de ressourcesallouablesPar utilisateur ou par tenantSupport dans NovaSupport dans CinderSupport dans Neutron
http://docs.openstack.org/user-guide-admin/content/cli_set_quotas.html
DÉCOUPAGE RÉSEAUManagement network : réseaud’administrationData network : réseau pour lacommunication inter instancesExternal network : réseau externe, dansl’infrastructure réseau existanteAPI network : réseau contenant lesendpoints API
CONSIDÉRATIONS LIÉES À LASÉCURITÉ
Indispensable : HTTPS sur l’accès des APIs àl’extérieurSécurisation des communicationsMySQL/MariaDB et RabbitMQUn accès MySQL/MariaDB par base et parserviceUn utilisateur Keystone par service
Un utilisateur Keystone par serviceLimiter l’accès en lecture des fichiers deconfiguration (mots de passe, token)Veille sur les failles de sécurité : OSSA(OpenStack Security Advisory), OSSN (...Notes)
Guide sécurité :http://docs.openstack.org/security-guide/
SEGMENTER SON CLOUDHost aggregates : machines physiques avecdes caractéristiques similairesAvailability zones : machines dépendantesd’une même source électrique, d’un mêmeswitch, d’un même DC, etc.Regions : chaque région a son APICells : permet de regrouper plusieurs clouddifférents sous une même API
http://docs.openstack.org/openstack-ops/content/scaling.html#segregate_cloud
HOST AGGREGATES / AGRÉGATSD’HÔTES
Spécifique NovaL’administrateur définit des agrégatsd’hôtes via l’APIL’administrateur associe flavors et agrégatsvia des couples clé/valeur communs1 agrégat ≡ 1 point commun, ex : GPUL’utilisateur choisit un agrégat à travers sonchoix de flavor à la création d’instance
AVAILABILITY ZONES / ZONES DEDISPONIBILITÉ
Spécifique Nova et CinderGroupes d’hôtesDécoupage en termes de disponibilité :Rack, Datacenter, etc.L’utilisateur choisit une zone dedisponibilité à la création d’instanceL’utilisateur peut demander à ce que desinstances soient démarrées dans une mêmezone, ou au contraire dans des zonesdifférentes
RÉGIONSGénérique OpenStackÉquivalent des régions d’AWSUn service peut avoir différents endpointsdans différentes régionsChaque région est autonomeCas d’usage : cloud de grande ampleur(comme certains clouds publics)
CELLS / CELLULESSpécifique NovaUn seul nova-api devant plusieurs cellulesChaque cellule a sa propre BDD et file demessagesAjoute un niveau de scheduling (choix de lacellule)
PACKAGING D’OPENSTACK -UBUNTU
Le packaging est fait dans de multiplesdistributions, RPM, DEB et autresUbuntu est historiquement la plateforme deréférence pour le développementd’OpenStackLe packaging dans Ubuntu suit de près ledéveloppement d’OpenStack, et des testsautomatisés sont réalisésCanonical fournit la Ubuntu Cloud Archive,qui met à disposition la dernière versiond’OpenStack pour la dernière Ubuntu LTS
UBUNTU CLOUD ARCHIVE (UCA)
Support d'OpenStack dans Ubuntu via l'UCA
PACKAGING D’OPENSTACK DANSLES AUTRES DISTRIBUTIONS
OpenStack est intégré dans les dépôtsofficiels de DebianRed Hat propose RHOS/RDO (déploiementbasé sur TripleO)Comme Ubuntu, le cycle de release deFedora est synchronisé avec celuid’OpenStack
LES DISTRIBUTIONS OPENSTACKStackOpsMirantisHP Helionetc.
DÉPLOIEMENT BARE-METAL
Le déploiement des hôtes physiquesOpenStack peut se faire à l’aide d’outilsdédiésMaaS (Metal as a Service), parUbuntu/Canonical : se couple avec JujuCrowbar / OpenCrowbar (initialement Dell) :utilise ChefeDeploy (eNovance) : déploiement par desimagesIronic via TripleO
GESTION DE CONFIGURATIONPuppet, Chef, CFEngine, Saltstack, Ansible,etc.Ces outils peuvent aider à déployer le cloudOpenStack... mais aussi à gérer les instances (sectionsuivante)
MODULES PUPPET, PLAYBOOKSANSIBLE
Puppet OpenStack et OpenStack Ansible :modules Puppet et playbooks AnsibleDéveloppés au sein du projet OpenStackhttps://wiki.openstack.org/wiki/Puppethttp://docs.openstack.org/developer/openstack-ansible/install-guide/
DÉPLOIEMENT CONTINUOpenStack maintient un master (trunk)toujours stablePossibilité de déployer au jour le jour lemaster (CD : Continous Delivery)Nécessite la mise en place d’uneinfrastructure importanteFacilite les mises à jour entre versionsmajeures
GÉRER LES PROBLÈMES
PROBLÈMES : RESSOURCESFAILED/ERROR
Plusieurs causes possiblesPossibilité de supprimer la ressource?L’appel API reset-state peut servir
LES RÉFLEXES EN CAS D’ERREUROU DE COMPORTEMENT ERRONÉTravaille-t-on sur le bon tenant ?Est-ce que l’API renvoie une erreur ? (ledashboard peut cacher certainesinformations)Si nécessaire d’aller plus loin :
Regarder les logs sur le cloud controller(/var/log/<composant>/*.log)
(/var/log/<composant>/*.log)Regarder les logs sur le compute node etle network node si le problème estspécifique réseau/instanceÉventuellement modifier la verbosité deslogs dans la configuration
EST-CE UN BUG ?Si le client CLI crash, c’est un bugSi le dashboard web ou une API renvoie uneerreur 500, c’est peut-être un bugSi les logs montrent une stacktrace Python,c’est un bugSinon, à vous d’en juger
TIRER PARTI DU IAAS
DEUX VISIONSUne fois un cloud IaaS en place, deux optiques
possibles :
Garder les mêmes pratiques tout enprofitant du self service et de l’agilité de lasolution pour des besoins test/devFaire évoluer ses pratiques, tant côtéapplicatif que système “Pets vs Cattle”
SINON ?Faire tourner des applications legacy dans le
cloud est une mauvaise idée :
Interruptions de servicePertes de donnéesIncompréhensions “le cloud ça marchepas”
CÔTÉ APPLICATIONS
ADAPTER OU PENSER SESAPPLICATIONS “CLOUD READY”
1/3Cf. les design tenets du projet OpenStack et
Twelve-Factor http://12factor.net/
Architecture distribuée plutôt quemonolithique
Facilite le passage à l’échelleLimite les domaines de failure
Couplage faible entre les composants
ADAPTER OU PENSER SESAPPLICATIONS “CLOUD READY”
2/3
Bus de messages pour les communicationsinter-composantsStateless : permet de multiplier les routesd’accès à l’applicationDynamicité : l’application doit s’adapter àson environnement et se reconfigurerlorsque nécessairePermettre le déploiement et l’exploitationpar des outils d’automatisation
ADAPTER OU PENSER SESAPPLICATIONS “CLOUD READY”
3/3Limiter autant que possible lesdépendances à du matériel ou du logicielspécifique qui pourrait ne pas fonctionnerdans un cloudTolérance aux pannes (fault tolerance)
Tolérance aux pannes (fault tolerance)intégréeNe pas stocker les données en local, maisplutôt :
Base de donnéesStockage objet
Utiliser des outils standards dejournalisation
CÔTÉ SYSTÈME
ADOPTER UNE PHILOSOPHIEDEVOPS
Infrastructure as CodeScale out plutôt que scale up(horizontalement plutôt que verticalement)HA niveau application plutôtqu’infrastructureAutomatisation, automatisation,automatisationTests
MONITORINGPrendre en compte le cycle de vie desinstancesMonitorer le service plus que le serveur
BACKUPÊtre capable de recréer ses instances (et lereste de son infrastructure)Données (applicatives, logs) : block, objet
UTILISER DES IMAGES CLOUDUne image cloud c’est :
Une image disque contenant un OS déjàinstalléUne image qui peut être instanciée en nmachines sans erreurUn OS sachant parler à l’API de metadatadu cloud (cloud-init)Détails :
La plupart des distributions fournissentaujourd’hui des images cloud.
http://docs.openstack.org/image-guide/openstack-images.html
CIRROSCirros est l’image cloud parexcellenceOS minimalisteContient cloud-init
https://launchpad.net/cirros
CLOUD-INIT
Cloud-init est un moyen de tirer parti del’API de metadata, et notamment des userdataL’outil est intégré par défaut dans la plupartdes images cloudÀ partir des user data, cloud-init effectue lesopérations de personnalisation del’instancecloud-config est un format possible de userdata
EXEMPLE CLOUD-CONFIG#cloud-configmounts: - [ xvdc, /var/www ]packages: - apache2 - htop
COMMENT GÉRER SES IMAGES ?Utilisation d’images génériques etpersonnalisation à l’instanciationCréation d’images intermédiaires et/outotalement personnalisées : Golden images
libguestfs, virt-builder, virt-sysprepdiskimage-builder (TripleO)Packersolution “maison”
CONFIGURER ET ORCHESTRER SESINSTANCES
Outils de gestion de configuration (lesmêmes qui permettent de déployerOpenStack)Juju
CONCLUSION
POUR CONCLURE
Le cloud révolutionne l’ITOpenStack est le projet libre phare sur lapartie IaaSDéployer OpenStack n’est pas une minceaffaireL’utilisation d’un cloud IaaS implique deschangements de pratiqueLes métiers d’architecture logicielle et infraévoluent