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

Guide HA : http://docs.openstack.org/ha-guide/

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