Formation OpenStack administrateur

Concernant ces supports de cours

Concernant ces supports de cours 1/2

Supports de cours réalisés par Osones https://osones.com

Logo Osones
Logo Osones

Auteurs

Concernant ces supports de cours 2/2

Licence Creative Commons BY-SA 4.0
Licence Creative Commons BY-SA 4.0

Introduction

Objectifs de la formation : Cloud

  • Comprendre les principes du cloud et son intérêt
  • Connaitre le vocabulaire inhérent au cloud
  • Avoir une vue d’ensemble sur les solutions existantes en cloud public et privé
  • Posséder les clés pour tirer parti au mieux du IaaS
  • Pouvoir déterminer ce qui est compatible avec la philosophie cloud ou pas
  • Adapter ses méthodes d’administration système à un environnement cloud

Objectifs de la formation : OpenStack

  • Connaitre le fonctionnement du projet OpenStack et ses possibilités
  • Comprendre le fonctionnement de chacun des composants d’OpenStack
  • Pouvoir faire les bons choix de configuration
  • Savoir déployer manuellement un cloud OpenStack pour fournir du IaaS
  • Connaitre les bonnes pratiques de déploiement d’OpenStack
  • Être capable de déterminer l’origine d’une erreur dans OpenStack
  • Savoir réagir face à un bug

Pré-requis de la formation

  • Compétences d’administration système Linux tel qu’Ubuntu
    • Gestion des paquets
    • Manipulation de fichiers de configuration et de services
    • LVM et systèmes de fichiers
  • Notions :
    • Virtualisation : KVM, libvirt
    • Réseau : iptables, namespaces
  • Peut servir :
    • À l’aise dans un environnement Python

Le cloud, vue d'ensemble

Définition formelle

Caractéristiques

Fournir un (des) service(s)...

  • Self service
  • À travers le réseau
  • Mutualisation des ressources
  • Élasticité rapide
  • Mesurabilité

Inspiré de la définition du NIST http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf

Self service

  • L'utilisateur accède directement au service
  • Pas d'intermédiaire humain
  • Réponses immédiates
  • Catalogue de services permettant leur découverte

À travers le réseau

  • L'utilisateur accède au service à travers le réseau
  • Le fournisseur du service est distant du consommateur
  • Réseau = internet ou pas
  • Utilisation de protocoles réseaux standards (typiquement : HTTP)

Mutualisation des ressources

  • Un cloud propose ses services à de multiples utilisateurs/organisations → Multi-tenant
  • Les ressources sont disponibles en grandes quantités
  • La localisation précise et le taux d'occupation des ressources ne sont pas visibles

Élasticité rapide

  • Provisionning et suppression des ressources quasi instantané
  • Possibilité d'automatiser ces actions de scaling (passage à l'échelle)
  • Virtuellement pas de limite à cette élasticité

Mesurabilité

  • L'utilisation des ressources cloud est monitorée par le fournisseur
  • Le fournisseur peut gérer son capacity planning à partir de ces informations
  • L'utilisateur est facturé en fonction de son usage précis des ressources

Modèles

On distingue :

  • modèles de service : IaaS, PaaS, SaaS
  • modèles de déploiement : public, privé, hybride

IaaS

  • Infrastructure as a Service
  • Infrastructure :
    • Compute (calcul)
    • Storage (stockage)
    • Network (réseau)
  • Utilisateurs cibles : administrateurs (système, stockage, réseau)

PaaS

  • Platform as a Service
  • Environnement permettant de développer/déployer une application
  • Spécifique à un language/framework (exemple : Python/Django)
  • Ressources plus haut niveau que l'infrastructure, exemple : BDD
  • Utilisateurs cibles : développeurs d'application

SaaS

  • Software as a Service
  • Utilisateurs cibles : utilisateurs finaux

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 un schéma

IaaS - PaaS - SaaS
IaaS - PaaS - SaaS

Cloud public ou privé ?

À qui s'adresse le cloud ?

  • Public : tout le monde, disponible sur internet
  • Privé : à une organisation, disponible sur son réseau

Concernant le cloud hybride : utilisation mixte de multiples clouds privés et/ou publics

Cloud hybride

  • Concept séduisant
  • Mise en œuvre a priori difficile
  • Certains cas d'usages s'y prêtent très bien
    • Exemple : jobs de CI
  • Cloud bursting

L'instant virtualisation

Mise au point.

  • La virtualisation est une technologie permettant d'implémenter la fonction compute
  • Un cloud fournissant du compute peut utiliser la virtualisation
  • Mais peut également utiliser :
    • Du bare-metal
    • Des containers

Les APIs, la clé du cloud

  • Rappel : API pour Application Programming Interface
    • Au sens logiciel : Interface permettant à un logiciel d’utiliser une bibliothèque
    • Au sens cloud : Interface permettant à un logiciel d’utiliser un service (XaaS)
  • 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'utilisateur communique avec le cloud pour gérer ses ressources
  • Gérer : CRUD (Create, Read, Update, Delete)
  • REST

REST

  • Une ressource == une URI (Uniform Resource Identifier)
  • Utilisation des verbes HTTP pour caractériser les opérations (CRUD)
    • GET
    • POST
    • PUT
    • DELETE
  • Utilisation des codes de retour HTTP
  • Représentation des ressources dans le corps des réponses HTTP

REST - Exemples

GET http://endpoint/volumes/
GET http://endpoint/volumes/?size=10
POST http://endpoint/volumes/
DELETE http://endpoint/volumes/xyz

Exemple concret

GET /v2.0/networks/d32019d3-bc6e-4319-9c1d-6722fc136a22
{
   "network":{
      "status":"ACTIVE",
      "subnets":[ "54d6f61d-db07-451c-9ab3-b9609b6b6f0b" ],
      "name":"private-network",
      "provider:physical_network":null,
      "admin_state_up":true,
      "tenant_id":"4fd44f30292945e481c7b8a0c8908869",
      "provider:network_type":"local",
      "router:external":true,
      "shared":true,
      "id":"d32019d3-bc6e-4319-9c1d-6722fc136a22",
      "provider:segmentation_id":null
   }
}

Pourquoi le cloud ? côté économique

  • Appréhender les ressources IT comme des services “fournisseur”
  • Faire glisser le budget “investissement” (Capex) vers le budget “fonctionnement” (Opex)
  • Réduire les coûts en mutualisant les ressources, et éventuellement avec des économies d'échelle
  • Réduire les délais
  • Aligner les coûts sur la consommation réelle des ressources

Pourquoi le cloud ? côté technique

  • Abstraire les couches basses (serveur, réseau, OS, stockage)
  • S’affranchir de l’administration technique des ressources et services (BDD, pare-feux, load-balancing, etc.)
  • Concevoir des infrastructures scalables à la volée
  • Agir sur les ressources via des lignes de code et gérer les infrastructures “comme du code”

Le marché

Amazon Web Services (AWS), le leader

  • Lancement en 2006
  • À l'origine : services web "e-commerce" pour développeurs
  • Puis : d'autres services pour développeurs
  • Et enfin : services d'infrastructure
  • Récemment, SaaS

Alternatives IaaS publics à AWS

  • Google Cloud Platform
  • Microsoft Azure
  • Rackspace
  • DreamHost
  • DigitalOcean
  • En France :
    • Cloudwatt (Orange Business Services)
    • Numergy (SFR)
    • OVH
    • Ikoula
    • Scaleway
    • Outscale

Faire du IaaS privé

  • OpenStack
  • CloudStack
  • Eucalyptus
  • OpenNebula

OpenStack en quelques mots

  • Naissance en 2010
  • Fondation OpenStack depuis 2012
  • Écrit en Python et distribué sous licence Apache 2.0
  • Soutien très large de l'industrie et contributions variées

Exemples de PaaS public

Solutions de PaaS privé

Les concepts Infrastructure as a Service

La base

  • Infrastructure :
    • Compute
    • Storage
    • Network

Ressources compute

  • Instance
  • Image
  • Flavor (gabarit)
  • Paire de clé (SSH)

L'instance

  • Éphémère, durée de vie typiquement courte
  • Dédiée au compute
  • Ne doit pas stocker de données persistantes
  • Disque racine non persistant

Image cloud

  • Image disque contenant un OS déjà installé
  • Instanciable à l'infini
  • Sachant parler à l'API de metadata

API ... de metadata

  • http://169.254.169.254
  • Accessible depuis l'instance
  • Fournit des informations relatives à l'instance
  • cloud-init permet d'exploiter cette API

Flavor (gabarit)

  • Instance type chez AWS
  • Définit un modèle d’instance en termes de CPU, RAM, disque (racine), disque éphémère
  • Le disque éphémère a, comme le disque racine, l’avantage d’être souvent local donc rapide

Paire de clé

  • Clé publique + clé privée SSH
  • Le cloud manipule et stocke la clé publique
  • Cette clé publique est utilisée pour donner un accès SSH aux instances

Ressources réseau 1/2

  • Réseau L2
    • Port réseau
  • Réseau L3
    • Routeur
    • IP flottante
    • Groupe de sécurité

Ressources réseau 2/2

  • Load Balancing as a Service
  • VPN as a Service
  • Firewall as a Service

Ressources stockage

Le cloud fournit deux types de stockage

  • Block
  • Objet

Stockage block

  • Volumes attachables à une instance
  • Accès à des raw devices type /dev/vdb
  • Possibilité d’utiliser n’importe quel système de fichiers
  • Possibilité d'utiliser du LVM, du chiffrement, etc.
  • Compatible avec toutes les applications existantes

"Boot from volume"

Démarrer une instance avec un disque racine sur un volume

  • Persistance des données du disque racine
  • Se rapproche du serveur classique

Stockage objet

  • Pousser et retirer des objets dans un container/bucket
  • Pas de hiérarchie des données, pas de système de fichiers
  • Accès par les APIs
  • L’application doit être conçue pour tirer parti du stockage objet

Orchestration

  • Orchestrer la création et la gestion des ressources dans le cloud
  • Définition de l'architecture dans un template
  • Les ressources créées à partir du template forment la stack

Bonne pratiques d'utilisation

Haute disponibilité (HA)

  • Le control plane (les APIs) du cloud est HA
  • Les ressources provisionnées ne le sont pas forcément

Pets vs Cattle

Comment considérer ses instances ?

  • Pet
  • Cattle

Infrastructure as Code

Avec du code

  • Provisionner les ressources d'infrastructure
  • Configurer les dites ressources, notamment les instances

Le métier évolue : Infrastructure Developer

Scaling, passage à l'échelle

  • Scale out plutôt que Scale up
    • Scale out : passage à l'échelle horizontal
    • Scale up : passage à l'échelle vertical
  • Auto-scaling

Applications cloud ready

  • Stockent leurs données au bon endroit
  • Sont architecturées pour tolérer les pannes
  • Etc.

Cf. http://12factor.net/

Derrière le cloud

Comment implémenter un service de Compute

  • Virtualisation
  • Containers
  • Bare metal

Implémentation du stockage : (Software Defined Storage) SDS

  • Attention : ne pas confondre avec le sujet block vs objet

  • Utilisation de commodity hardware
  • Pas de RAID matériel
  • Le logiciel est responsable de garantir les données
  • Les pannes matérielles sont prises en compte et gérées
  • Le projet Ceph et le composant OpenStack Swift implémentent du SDS
  • Voir aussi Scality

SDS - Théorème CAP

Consistency - Availability - Partition tolerance
Consistency - Availability - Partition tolerance

OpenStack : le projet

Tour d'horizon

Vue haut niveau

Version simple
Version simple

Historique

  • Démarrage en 2010
  • Objectif : le Cloud Operating System libre To produce a ubiquitous Open Source Cloud Computing platform that is easy to use, simple to implement, interoperable between deployments, works well at all scales, and meets the needs of users and operators of both public and private clouds.
  • Fusion de deux projets de Rackspace (Storage) et de la NASA (Compute)
  • Logiciel libre distribué sous licence Apache 2.0
  • Naissance 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), Newton (2016.2)
  • Ocata (2017.1)
  • Fin 2017 : Pike

Quelques soutiens/contributeurs ...

  • Editeurs : Red Hat, Suse, Canonical, Vmware, ...
  • Constructeurs : IBM, HP, Dell, ...
  • Constructeurs/réseau : Juniper, Cisco, ...
  • Constructeurs/stockage : NetApp, Hitachi, ...
  • En vrac : NASA, Yahoo, Rackspace, OVH, Citrix, SAP, ...
  • Google ! (depuis juillet 2015)

https://www.openstack.org/foundation/companies/

... et utilisateurs

  • Tous les contributeurs précédemment cités
  • En France : Cloudwatt et Numergy
  • Wikimedia
  • CERN
  • Paypal
  • Comcast
  • BMW
  • Etc. Sans compter les implémentations confidentielles

https://www.openstack.org/user-stories/

Les différents sous-projets

  • OpenStack Compute - Nova
  • OpenStack (Object) Storage - Swift
  • OpenStack Block Storage - Cinder
  • OpenStack Networking - Neutron
  • OpenStack Image Service - Glance
  • OpenStack Identity Service - Keystone
  • OpenStack Dashboard - Horizon
  • OpenStack Telemetry - Ceilometer
  • OpenStack Orchestration - Heat
  • OpenStack 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)
  • Autres
    • Les clients (python-*client), CLI et bibliothèques
    • Les bibliothèques utilisées par OpenStack
    • Les outils utilisés pour développer OpenStack

Les 4 Opens

  • Open Source
  • Open Design
  • Open Development
  • Open Community

La fondation OpenStack

  • Entité de gouvernance principale du projet
  • Représentation juridique du projet
  • Les membres du board sont issus des entreprises sponsors et élus par les membres individuels
  • Tout le monde peut devenir membre individuel (gratuitement)

La fondation OpenStack

  • La fondation supporte le projet par différents moyens :
    • Événements : organisation (Summits) ou participation (OSCON, etc.)
    • Infrastructure de développement (serveurs)
    • Ressources humaines : marketing, release manager, quelques développeurs (principalement sur l’infrastructure)
  • 500 organisations à travers le monde
  • 60000 membres individuels dans 160 pays

La fondation OpenStack

Les principales entités de la fondation
Les principales entités de la fondation

Ressources

Ressources

Ressources - Communauté francophone

Logo OpenStack-fr
Logo OpenStack-fr
  • Site web : http://openstack.fr/
  • Association des utilisateurs francophones d’OpenStack : https://asso.openstack.fr/
  • Meetups : Paris, Rhônes-Alpes, Toulouse, Montréal, etc.
  • Présence à des événements tels que Paris Open Source Summit
  • Canaux de communication :
    • openstack-fr@lists.openstack.org
    • #openstack-fr@Freenode

Fonctionnement interne et mode de développement

Architecture

Vue détaillée des services
Vue détaillée des services

Implémentation

  • Chaque sous-projet est découpé en plusieurs services
  • Communication entre les services : AMQP (RabbitMQ)
  • Base de données : relationnelle SQL (MySQL/MariaDB)
  • Réseau : LinuxBridge, OpenVSwitch
  • En général : réutilisation de composants existants
  • Tout est développé en Python (Django pour la partie web)
  • APIs supportées : OpenStack et équivalent AWS
  • Multi tenancy

APIs

  • Chaque projet supporte son API OpenStack
  • Certains projets supportent l'API AWS équivalente

Mode de développement

Statistiques

  • 2581 contributeurs à Newton
  • 309 organisations contributrices à Newton
  • 20 millions de lignes de code écrites depuis le début du projet
  • Développement hyper actif : 25000 commits dans Liberty

Développement du projet : en détails

  • Ouvert à tous (individuels et entreprises)
  • Cycle de développement de 6 mois débuté par un (design) summit

Les outils

  • Revue de code (peer review) : Gerrit
  • Intégration continue (continous integration) : Jenkins, Zuul, etc.
  • Blueprints/spécifications et bugs :
    • Launchpad
    • Storyboard
  • Code : Git + GitHub

Développement du projet : en détails

Workflow de changements dans OpenStack
Workflow de changements dans OpenStack

Cycle de développement : 6 mois

  • Le planning est publié, exemple : https://releases.openstack.org/ocata/schedule.html
  • Milestone releases
  • Freezes : FeatureProposal, Feature, String
  • RC releases
  • Stable releases
  • Ce modèle de cycle de développement a évolué depuis le début du projet
  • Cas particulier de Swift et de plus en plus de composants
  • Depuis Liberty, chaque composant gère son propre versionnement

Versionnement depuis Liberty

Le nouveau modèle “big tent”

Qui contribue ?

  • Active Technical Contributor
  • ATC : personne ayant au moins une contribution récente dans un projet OpenStack reconnu
  • Les ATC sont invités aux summits et ont le droit de vote
  • Core reviewer : ATC ayant les droits pour valider les patchs dans un projet
  • Project Team Lead (PTL) : élu par les ATCs de chaque projet
  • Stackalytics fournit des statistiques sur les contributions

http://stackalytics.com/

Où trouver des informations sur le développement d’OpenStack

Où trouver des informations sur le développement d’OpenStack

OpenStack Infra

  • Équipe projet en charge de l’infrastructure de développement d’OpenStack
  • Travaille comme les équipes de dev d’OpenStack et utilise les mêmes outils
  • Résultat : une infrastructure entièrement open source et développée comme tel

OpenStack Summit

  • Aux USA jusqu’en 2013
  • Aujourd’hui : alternance Amérique de Nord et Asie/Europe
  • Quelques dizaines au début à 6000 participants aujourd’hui
  • En parallèle : conférence (utilisateurs, décideurs) et Design Summit (développeurs)
  • Détermine le nom de la release : lieu/ville à proximité du Summit
  • Upstream Training

Exemple du Summit d’avril 2013 à Portland

Photo : Adrien Cunin
Photo : Adrien Cunin

Exemple du Summit d’octobre 2015 à Tokyo

Photo : Elizabeth K. Joseph, CC BY 2.0, Flickr/pleia2
Photo : Elizabeth K. Joseph, CC BY 2.0, Flickr/pleia2

Exemple du Summit d’octobre 2015 à Tokyo

Photo : Elizabeth K. Joseph, CC BY 2.0, Flickr/pleia2
Photo : Elizabeth K. Joseph, CC BY 2.0, Flickr/pleia2

Exemple du Summit d’octobre 2015 à Tokyo

Photo : Elizabeth K. Joseph, CC BY 2.0, Flickr/pleia2
Photo : Elizabeth K. Joseph, CC BY 2.0, Flickr/pleia2

Exemple du Summit d’octobre 2015 à Tokyo

Photo : Elizabeth K. Joseph, CC BY 2.0, Flickr/pleia2
Photo : Elizabeth K. Joseph, CC BY 2.0, Flickr/pleia2

Traduction

  • La question de la traduction est dorénavant prise en compte (officialisation de l’équipe i18n)
  • Seules certaines parties sont traduites, comme Horizon
  • La traduction française est aujourd’hui une des plus avancées
  • Utilisation d'une plateforme web basée sur Zanata : https://translate.openstack.org/

DevStack : faire tourner rapidement un OpenStack

Utilité de DevStack

  • Déployer rapidement un OpenStack
  • Utilisé par les développeurs pour tester leurs changements
  • Utilisé pour faire des démonstrations
  • Utilisé pour tester les APIs sans se préoccuper du déploiement
  • Ne doit PAS être utilisé pour de la production

Fonctionnement de DevStack

  • Un script shell qui fait tout le travail : stack.sh
  • Un fichier de configuration : local.conf
  • Installe toutes les dépendances nécessaires (paquets)
  • Clone les dépôts git (branche master par défaut)
  • Lance tous les composants dans un screen

Configuration : local.conf

Exemple

[[local|localrc]]
ADMIN_PASSWORD=secrete
DATABASE_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORD
SERVICE_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’utilisation

  • DevStack installe beaucoup de choses sur la machine
  • Il est recommandé de travailler dans une VM
  • Pour tester tous les composants OpenStack dans de bonnes conditions, plusieurs Go de RAM sont nécessaires
  • L’utilisation de Vagrant est conseillée

Utiliser OpenStack

Le principe

  • Toutes les fonctionnalités sont accessibles par l’API
  • Les clients (y compris Horizon) utilisent l’API
  • Des crédentials sont nécessaires
    • API OpenStack : utilisateur + mot de passe + tenant (+ domaine)
    • API AWS : access key ID + secret access key

Les APIs OpenStack

  • Une API par service OpenStack
  • http://developer.openstack.org/api-ref.html
  • Chaque API est versionnée, la rétro-compatibilité est assurée
  • REST
  • Certains services sont aussi accessibles via une API différente compatible AWS

Authentification et catalogue de service

  • Une fois authentifié, récupération d’un jeton (token)
  • Récupération du catalogue de services
  • Pour chaque service, un endpoint HTTP (API)

Accès aux APIs

  • Direct, en HTTP, via des outils comme curl
  • Avec une bibliothèque
    • Les implémentations officielles en Python
    • OpenStackSDK
    • D’autres implémentations, y compris pour d’autres langages (exemple : jclouds)
    • Shade
  • Avec les outils officiels en ligne de commande
  • Avec Horizon

Clients officiels

  • Le projet fournit des clients officiels : python-PROJETclient
  • Bibliothèques Python
  • Outils CLI
    • L’authentification se fait en passant les credentials par paramètres ou variables d’environnement
    • L’option --debug affiche la communication HTTP

OpenStack Client

  • Client CLI unifié
  • Commandes du type openstack <ressource ><action >
  • Vise à remplacer à terme les clients spécifiques
  • Permet une expérience utilisateur plus homogène
  • Fichier de configuration clouds.yaml

Déployer et opérer OpenStack

Ce qu’on va voir

Architecture détaillée

Vue détaillée des services
Vue détaillée des services

Architecture services

Machines "physiques" et services
Machines "physiques" et services

Quelques éléments de configuration généraux

  • Tous les composants doivent être configurés pour communiquer avec Keystone
  • La plupart doivent être configurés pour communiquer avec MySQL/MariaDB et RabbitMQ
  • Les composants découpés en plusieurs services ont parfois un fichier de configuration par service
  • Le fichier de configuration policy.json précise les droits nécessaires pour chaque appel API

Système d’exploitation

  • OS Linux avec Python
  • Historiquement : Ubuntu
  • Red Hat s’est largement rattrapé
  • SUSE, Debian, CentOS, etc.

Python

Logo Python
Logo Python
  • OpenStack est aujourd’hui compatible Python 2.7
  • Afin de ne pas réinventer la roue, beaucoup de dépendances sont nécessaires
  • Un travail de portage vers Python 3 est en cours

Base de données

  • Permet de stocker la majorité des données gérées par OpenStack
  • Chaque composant a sa propre base
  • OpenStack utilise l’ORM Python SQLAlchemy
  • Support théorique équivalent à celui de SQLAlchemy
  • MySQL/MariaDB est l’implémentation la plus largement testée et utilisée
  • SQLite est principalement utilisé dans le cadre de tests et démo
  • Certains déploiements fonctionnent avec PostgreSQL

Pourquoi l’utilisation de SQLAlchemy

Logo SQLAlchemy
Logo SQLAlchemy
  • Support de multiples BDD
  • Gestion des migrations
Logo MySQL
Logo MySQL

Passage de messages

  • AMQP : Advanced Message Queuing Protocol
  • Messages, file d’attente, routage
  • Les processus OpenStack communiquent via AMQP
  • Plusieurs implémentations possibles : Qpid, 0MQ, etc.
  • RabbitMQ par défaut

RabbitMQ

Logo RabbitMQ
Logo RabbitMQ
  • RabbitMQ est implémenté en Erlang
  • Une machine virtuelle Erlang est donc nécessaire

“Hello world” RabbitMQ

Illustration simple du fonctionnement de RabbitMQ
Illustration simple du fonctionnement de RabbitMQ

Keystone : Authentification, autorisation et catalogue de services

Principes

  • Annuaire des utilisateurs et des groupes
  • Liste des tenants/projets
  • Catalogue de services
  • Gère l’authentification et l’autorisation
  • Support des domaines dans l’API v3
  • Fournit un token à l’utilisateur

API

  • API v2 admin : port 35357
  • API v2 utilisateur : port 5000
  • API v3 unifiée : port 5000
  • L'API v2 est dépréciée
  • Gère utilisateurs, groupes, domaines (API v3)
  • 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
Interactions avec Keystone

Installation et configuration

  • Paquet : keystone
  • Backends : choix de SQL ou LDAP (ou AD)
  • Backends tokens : SQL, Memcache, aucun
  • Configuration d’un token ADMIN pour la configuration initiale
  • Création des services et endpoints
  • Création d'utilisateurs, groupes, domaines

Enregistrer un service et son endpoint

Il faut renseigner l’existence des différents services (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

Principes

  • Gère les instances
  • Les instances sont créées à partir des images fournies par Glance
  • Les interfaces réseaux des instances sont associées à des ports Neutron
  • Du stockage block peut être fourni aux instances par Cinder

Interactions avec les autres composants

Instance, image et volume
Instance, image et volume

Propriétés d’une instance

  • Éphémère, a priori non hautement disponible
  • Définie par une flavor
  • Construite à partir d’une image
  • Optionnel : attachement de volumes
  • Optionnel : boot depuis un volume
  • Optionnel : une clé SSH publique
  • Optionnel : des ports réseaux

API

Gère :

  • Instances
  • Flavors (types d’instance)
  • Indirectement : images, security groups (groupes de sécurité), floating IPs (IPs flottantes)

Les instances sont redimensionnables et migrables d’un hôte physique à un autre.

Les groupes de sécurité

  • Équivalent à un firewall devant chaque instance
  • Une instance peut être associée à un ou plusieurs groupes de sécurité
  • Gestion des accès en entrée et sortie
  • Règles par protocole (TCP/UDP/ICMP) et par port
  • Cible une adresse IP, un réseau ou un autre groupe de sécurité

Flavors

  • Gabarit
  • Équivalent des “instance types” d’AWS
  • Définit un modèle d’instance en termes de CPU, RAM, disque (racine), disque éphémère
  • Un disque de taille nul équivaut à prendre la taille de l’image de base
  • Le disque éphémère a, comme le disque racine, l’avantage d’être souvent local donc rapide

Nova api

  • Double rôle
  • API de manipulation des instances par l’utilisateur
  • API à destination des instances : API de metadata
  • L’API de metadata doit être accessible à l’adresse http://169.254.169.254/
  • L’API de metadata fournit des informations de configuration personnalisées à chacune des instances

Nova compute

  • Pilote les instances (machines virtuelles ou physiques)
  • Tire partie de libvirt ou d’autres APIs comme XenAPI
  • Drivers : libvirt (KVM, LXC, etc.), XenAPI, VMWare vSphere, Ironic
  • Permet de récupérer les logs de la console et une console VNC

Nova scheduler

  • Service qui distribue les demandes d’instances sur les nœuds compute
  • Filter, Chance, Multi Scheduler
  • Filtres, par défaut : AvailabilityZoneFilter,RamFilter,ComputeFilter
  • Tri par poids, par défaut : RamWeigher

Le scheduler Nova en action

Fonctionnement de nova-scheduler
Fonctionnement de nova-scheduler

Nova conductor

  • Service facultatif qui améliore la sécurité
  • Fait office de proxy entre les nœuds compute et la BDD
  • Les nœuds compute, vulnérables, n’ont donc plus d’accès à la BDD

Tester

$ nova list
...
$ nova create
...

Glance : Registre d’images

Principes

  • Registre d’images (et des snapshots)
  • Propriétés sur les images
  • Est utilisé par Nova pour démarrer des instances
  • Peut utiliser Swift comme back-end de stockage

Propriétés des images dans Glance

L’utilisateur peut définir un certain nombre de propriétés dont certaines seront utilisées lors de l’instanciation

  • Type d’image
  • Architecture
  • Distribution
  • Version de la distribution
  • Espace disque minimum
  • RAM minimum
  • Publique ou non

Types d’images

Glance supporte un large éventail de types d’images, limité par le support de l’hyperviseur sous-jacent à Nova

  • raw
  • qcow2
  • ami
  • vmdk
  • iso

Backends

  • Swift ou S3
  • Ceph
  • HTTP
  • Répertoire local

Installation

  • Paquet glance-api : fournit l’API
  • Paquet glance-registry : démon du registre d’images en tant que tel

Tester

$ glance image-list
...
$ glance image-create
...

Neutron : Réseau en tant que service

Principes

  • Software Defined Networking (SDN)
  • Auparavant Quantum et nova-network
  • IP flottantes, groupes de sécurité
  • neutron-server : fournit l’API
  • Agent DHCP : fournit le service de DHCP pour les instances
  • Agent L3 : gère la couche 3 du réseau, le routage
  • Plugin : OpenVSwitch par défaut, d’autres implémentations libres/propriétaires, logicielles/matérielles existent

Fonctionnalités supplémentaires

Outre les fonctions réseau de base niveaux 2 et 3, Neutron peut fournir d’autres services :

  • Load Balancing (HAProxy, ...)
  • Firewall (vArmour, ...) : diffère des groupes de sécurité
  • VPN (Openswan, ...) : permet d’accéder à un réseau privé sans IP flottantes

Ces fonctionnalités se basent également sur des plugins

API

L’API permet notamment de manipuler ces ressources

  • Réseau (network) : niveau 2
  • Sous-réseau (subnet) : niveau 3
  • Port : attachable à une interface sur une instance, un load-balancer, etc.
  • Routeur

Plugins ML2

  • Modular Layer 2
  • OpenVSwitch
  • OpenDaylight
  • Contrail, OpenContrail
  • Nuage Networks
  • VMWare NSX
  • cf. OpenFlow

Implémentation

  • Neutron tire partie des namespaces réseaux du noyau Linux pour permettre l’IP overlapping
  • Le proxy de metadata est un composant qui permet aux instances isolées dans leur réseau de joindre l’API de metadata fournie par Nova

Schéma

Vue utilisateur du réseau
Vue utilisateur du réseau

Schéma

Vue infra du réseau
Vue infra du réseau

Cinder : Stockage block

Principes

  • Auparavant nova-volume
  • Fournit des volumes (stockage block) attachables aux instances
  • Gère différents types de volume
  • Gère snapshots et backups de volumes
  • Attachement via iSCSI par défaut

Du stockage partagé ?

  • Cinder n’est pas une solution de stockage partagé comme NFS
  • Le projet OpenStack Manila a pour objectif d’être un NFS as a Service
  • AWS n’a introduit une telle fonctionnalité que récemment

Utilisation

  • Volume supplémentaire (et stockage persistant) sur une instance
  • Boot from volume : l’OS est sur le volume
  • Fonctionnalité de backup vers un object store (Swift ou Ceph)

Installation

  • Paquet cinder-api : fournit l’API
  • Paquet cinder-volume : création et gestion des volumes
  • Paquet cinder-scheduler : distribue les demandes de création de volume
  • Paquet cinder-backup : backup vers un object store

Backends

  • Utilisation de plusieurs backends en parallèle possible
  • LVM (par défaut)
  • GlusterFS
  • Ceph
  • Systèmes de stockage propriétaires type NetApp
  • DRBD

Horizon : Dashboard web

Principes

  • Utilise les APIs existantes pour fournir une interface utilisateur
  • Horizon est un module Django
  • OpenStack Dashboard est l’implémentation officielle de ce module
Logo du framework web Python Django
Logo du framework web Python Django

Configuration

  • local_settings.py
  • Les services apparaissent dans Horizon s’ils sont répertoriés dans le catalogue de services de Keystone

Utilisation

  • Une zone “admin” restreinte
  • Une interface par tenant

Swift : Stockage objet

Principes

  • SDS : Software Defined Storage
  • Utilisation de commodity hardware
  • Théorème CAP : on en choisit deux
  • Accès par les APIs
  • Architecture totalement acentrée
  • Pas de base de données centrale

Implémentation

  • Proxy : serveur API par lequel passent toutes les requêtes
  • Object server : serveur de stockage
  • Container server : maintient des listes d’objects dans des containers
  • Account server : maintient des listes de containers dans des accounts
  • Chaque objet est répliqué n fois (3 par défaut)

Le ring

  • Problème : comment décider quelle donnée va sur quel object server
  • Le ring est découpé en partitions
  • On situe chaque donnée dans le ring afin de déterminer sa partition
  • Une partition est associée à plusieurs serveurs

Schéma

Architecture Swift
Architecture Swift

Ceilometer : Collecte de métriques

Surveiller l’utilisation de son infrastructure avec Ceilometer

  • Indexe différentes métriques concernant l’utilisation des différents services du cloud
  • Fournit des APIs permettant de récupérer ces données
  • Base pour construire des outils de facturation (exemple : CloudKitty)
  • Utilise MongoDB (par défaut) pour le stockage

Gnocchi : time-series database

  • Pourquoi Gnocchi ? Palier aux problème de scalabilité de Ceilometer
  • Initié par des développeurs de Ceilometer et intégré à l’équipe projet Ceilometer
  • Back-end remplaçant MongoDB pour Ceilometer

Heat : Orchestration des ressources

Orchestrer son infrastructure avec Heat

  • Équivalent d’Amazon Cloud Formation
  • Orchestrer les ressources compute, storage, network, etc.
  • Doit se coupler avec cloud-init
  • Description de son infrastructure dans un fichier template, format JSON (CFN) ou YAML (HOT)

Autoscaling avec Heat

Heat implémente la fonctionnalité d’autoscaling

  • Se déclenche en fonction des alarmes produites par Ceilometer
  • Entraine la création de nouvelles instances

Un template HOT

parameters - resources - outputs

heat_template_version: 2013-05-23
description: Simple template to deploy a single compute instance
resources:
  my_instance:
    type: OS::Nova::Server
    properties:
      key_name: my_key
      image: F18-x86_64-cfntools
      flavor: m1.small

Fonctionnalités avancées de Heat

  • Nested stacks
  • Environments
  • Providers

Construire un template à partir d’existant

Multiples projets en cours de développement

  • Flame (Cloudwatt)
  • HOT builder
  • Merlin

Trove : Database as a Service

Principe

  • Fournit des bases de données relationnelles, à la AWS RDS
  • A vocation à supporter des bases NoSQL aussi
  • Gère notamment MySQL/MariaDB comme back-end
  • Se repose sur Nova pour les instances dans lesquelles se fait l’installation d’une BDD

Services

  • trove-api : API
  • trove-taskmanager : gère les instances BDD
  • trove-guestagent : agent interne à l’instance

Designate : DNS as a Service

Principe

  • Équivalent d’AWS Route 53
  • Gère différents backends : BIND, etc.

Barbican - Key management as a Service

  • Gère des secrets / clés privées
  • Backends possibles :
    • Fichiers chiffrés
    • PKCS#11
    • KMIP
    • Dogtag

Quelques autres composants intéressants

Ironic

  • Anciennement Nova bare-metal
  • Permet le déploiement d’instances sur des machines physiques (plutôt que VMs)
  • Repose sur des technologies telles que PXE, TFTP

Oslo, ou OpenStack common

  • Oslo contient le code commun à plusieurs composants d’OpenStack
  • Son utilisation est transparente pour le déployeur

rootwrap

  • Wrapper pour l’utilisation de commandes en root
  • Configuration au niveau de chaque composant qui l’utilise
  • Permet d’écrire des filtres sur les commandes

TripleO

  • OpenStack On OpenStack
  • Objectif : pouvoir déployer un cloud OpenStack (overcloud) à partir d’un cloud OpenStack (undercloud)
  • Autoscaling du cloud lui-même : déploiement de nouveaux nœuds compute lorsque cela est nécessaire
  • Fonctionne conjointement avec Ironic pour le déploiement bare-metal

Tempest

  • Suite de tests d’un cloud OpenStack
  • Effectue des appels à l’API et vérifie le résultat
  • Est très utilisé par les développeurs via l’intégration continue
  • Le déployeur peut utiliser Tempest pour vérifier la bonne conformité de son cloud
  • Cf. aussi Rally

Bonnes pratiques pour un déploiement en production

Quels composants dois-je installer ?

  • Keystone est indispensable
  • L’utilisation de Nova va de paire avec Glance et Neutron
  • Cinder s’avérera souvent utile
  • Ceilometer et Heat vont souvent ensemble
  • Swift est indépendant des autres composants
  • Neutron peut parfois être utilisé indépendamment (ex : avec oVirt)

http://docs.openstack.org/arch-design/

Penser dès le début aux choix structurants

  • Distribution et méthode de déploiement
  • Hyperviseur
  • Réseau : quelle architecture et quels drivers
  • Politique de mise à jour

Les différentes méthodes d’installation

  • DevStack est à oublier pour la production
  • TripleO est très complexe
  • Le déploiement à la main comme vu précédemment n’est pas recommandé car peu maintenable
  • Distributions OpenStack packagées et prêtes à l’emploi
  • Distributions classiques et gestion de configuration
  • Déploiement continu

Mises à jour entre versions majeures

  • OpenStack supporte les mises à jour N N+1
  • Swift : très bonne gestion en mode rolling upgrade
  • Autres composants : tester préalablement avec vos données
  • Lire les release notes
  • Cf. articles de blog du CERN

Mises à jour dans une version stable

  • Fourniture de correctifs de bugs majeurs et de sécurité
  • OpenStack intègre ces correctifs sous forme de patchs dans la branche stable
  • Publication de point releases intégrant ces correctifs issus de la branche stable
  • Durée variable du support des versions stables, dépendant de l’intérêt des intégrateurs

Assigner des rôles aux machines

Beaucoup de documentations font référence à ces rôles :

  • Controller node : APIs, BDD, AMQP
  • Network node : DHCP, routeur, IPs flottantes
  • Compute node : Hyperviseur/pilotage des instances

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 balancers
  • La plupart des autres services OpenStack sont capables de scale out également

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

Haute disponibilité de l’agent L3 de Neutron

  • Plusieurs solutions et contournements possibles
  • Depuis Juno : Distributed Virtual Router (DVR)

Considérations pour une environnement de production

  • Des URLs uniformes pour toutes les APIs : utiliser un reverse proxy
  • Apache/mod_wsgi pour servir les APIs lorsque cela est possible (Keystone)
  • Utilisation des quotas
  • Prévoir les bonnes volumétries, notamment pour les données Ceilometer
  • Monitoring
  • Backup
  • QoS : en cours d’implémentation dans Neutron

Guide Operations : http://docs.openstack.org/openstack-ops/content/

Utilisation des quotas

  • Limiter le nombre de ressources allouables
  • Par utilisateur ou par tenant
  • Support dans Nova
  • Support dans Cinder
  • Support dans Neutron

http://docs.openstack.org/user-guide-admin/content/cli_set_quotas.html

Découpage réseau

  • Management network : réseau d’administration
  • Data network : réseau pour la communication inter instances
  • External network : réseau externe, dans l’infrastructure réseau existante
  • API network : réseau contenant les endpoints API

Considérations liées à la sécurité

  • Indispensable : HTTPS sur l’accès des APIs à l’extérieur
  • Sécurisation des communications MySQL/MariaDB et RabbitMQ
  • Un accès MySQL/MariaDB par base et par service
  • Un utilisateur Keystone par service
  • Limiter l’accès en lecture des fichiers de configuration (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 cloud

  • Host aggregates : machines physiques avec des caractéristiques similaires
  • Availability zones : machines dépendantes d’une même source électrique, d’un même switch, d’un même DC, etc.
  • Regions : chaque région a son API
  • Cells : permet de regrouper plusieurs cloud différents sous une même API

http://docs.openstack.org/openstack-ops/content/scaling.html#segregate_cloud

Host aggregates / agrégats d’hôtes

  • Spécifique Nova
  • L’administrateur définit des agrégats d’hôtes via l’API
  • L’administrateur associe flavors et agrégats via des couples clé/valeur communs
  • 1 agrégat 1 point commun, ex : GPU
  • L’utilisateur choisit un agrégat à travers son choix de flavor à la création d’instance

Availability zones / zones de disponibilité

  • Spécifique Nova et Cinder
  • Groupes d’hôtes
  • Découpage en termes de disponibilité : Rack, Datacenter, etc.
  • L’utilisateur choisit une zone de disponibilité à la création d’instance
  • L’utilisateur peut demander à ce que des instances soient démarrées dans une même zone, ou au contraire dans des zones différentes

Régions

  • Générique OpenStack
  • Équivalent des régions d’AWS
  • Un service peut avoir différents endpoints dans différentes régions
  • Chaque région est autonome
  • Cas d’usage : cloud de grande ampleur (comme certains clouds publics)

Cells / Cellules

  • Spécifique Nova
  • Un seul nova-api devant plusieurs cellules
  • Chaque cellule a sa propre BDD et file de messages
  • Ajoute un niveau de scheduling (choix de la cellule)

Packaging d’OpenStack - Ubuntu

  • Le packaging est fait dans de multiples distributions, RPM, DEB et autres
  • Ubuntu est historiquement la plateforme de référence pour le développement d’OpenStack
  • Le packaging dans Ubuntu suit de près le développement d’OpenStack, et des tests automatisés sont réalisés
  • Canonical fournit la Ubuntu Cloud Archive, qui met à disposition la dernière version d’OpenStack pour la dernière Ubuntu LTS

Ubuntu Cloud Archive (UCA)

Support d'OpenStack dans Ubuntu via l'UCA
Support d'OpenStack dans Ubuntu via l'UCA

Packaging d’OpenStack dans les autres distributions

  • OpenStack est intégré dans les dépôts officiels de Debian
  • Red Hat propose RHOS/RDO (déploiement basé sur TripleO)
  • Comme Ubuntu, le cycle de release de Fedora est synchronisé avec celui d’OpenStack

Les distributions OpenStack

  • StackOps
  • Mirantis
  • HP Helion
  • etc.

Déploiement bare-metal

  • Le déploiement des hôtes physiques OpenStack peut se faire à l’aide d’outils dédiés
  • MaaS (Metal as a Service), par Ubuntu/Canonical : se couple avec Juju
  • Crowbar / OpenCrowbar (initialement Dell) : utilise Chef
  • eDeploy (eNovance) : déploiement par des images
  • Ironic via TripleO

Gestion de configuration

  • Puppet, Chef, CFEngine, Saltstack, Ansible, etc.
  • Ces outils peuvent aider à déployer le cloud OpenStack
  • ... mais aussi à gérer les instances (section suivante)

Modules Puppet, Playbooks Ansible

Déploiement continu

  • OpenStack maintient un master (trunk) toujours stable
  • Possibilité de déployer au jour le jour le master (CD : Continous Delivery)
  • Nécessite la mise en place d’une infrastructure importante
  • Facilite les mises à jour entre versions majeures

Gérer les problèmes

Problèmes : ressources FAILED/ERROR

  • Plusieurs causes possibles
  • Possibilité de supprimer la ressource ?
  • L’appel API reset-state peut servir

Les réflexes en cas d’erreur ou de comportement erroné

  • Travaille-t-on sur le bon tenant ?
  • Est-ce que l’API renvoie une erreur ? (le dashboard peut cacher certaines informations)
  • Si nécessaire d’aller plus loin :
    • Regarder les logs sur le cloud controller (/var/log/<composant>/*.log)
    • Regarder les logs sur le compute node et le network node si le problème est spécifique réseau/instance
    • Éventuellement modifier la verbosité des logs dans la configuration

Est-ce un bug ?

  • Si le client CLI crash, c’est un bug
  • Si le dashboard web ou une API renvoie une erreur 500, c’est peut-être un bug
  • Si les logs montrent une stacktrace Python, c’est un bug
  • Sinon, à vous d’en juger

Tirer parti du IaaS

Deux visions

Une fois un cloud IaaS en place, deux optiques possibles :

  • Garder les mêmes pratiques tout en profitant du self service et de l’agilité de la solution pour des besoins test/dev
  • Faire é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 service
  • Pertes de données
  • Incompréhensions “le cloud ça marche pas”

Côté applications

Adapter ou penser ses applications “cloud ready” 1/3

Cf. les design tenets du projet OpenStack et Twelve-Factor http://12factor.net/

  • Architecture distribuée plutôt que monolithique
    • Facilite le passage à l’échelle
    • Limite les domaines de failure
  • Couplage faible entre les composants

Adapter ou penser ses applications “cloud ready” 2/3

  • Bus de messages pour les communications inter-composants
  • Stateless : permet de multiplier les routes d’accès à l’application
  • Dynamicité : l’application doit s’adapter à son environnement et se reconfigurer lorsque nécessaire
  • Permettre le déploiement et l’exploitation par des outils d’automatisation

Adapter ou penser ses applications “cloud ready” 3/3

  • Limiter autant que possible les dépendances à du matériel ou du logiciel spécifique qui pourrait ne pas fonctionner dans un cloud
  • Tolérance aux pannes (fault tolerance) intégrée
  • Ne pas stocker les données en local, mais plutôt :
    • Base de données
    • Stockage objet
  • Utiliser des outils standards de journalisation

Côté système

Adopter une philosophie DevOps

  • Infrastructure as Code
  • Scale out plutôt que scale up (horizontalement plutôt que verticalement)
  • HA niveau application plutôt qu’infrastructure
  • Automatisation, automatisation, automatisation
  • Tests

Monitoring

  • Prendre en compte le cycle de vie des instances
  • Monitorer le service plus que le serveur

Backup

  • Être capable de recréer ses instances (et le reste de son infrastructure)
  • Données (applicatives, logs) : block, objet

Utiliser des images cloud

Une image cloud c’est :

  • Une image disque contenant un OS déjà installé
  • Une image qui peut être instanciée en n machines sans erreur
  • Un OS sachant parler à l’API de metadata du cloud (cloud-init)
  • Détails : http://docs.openstack.org/image-guide/openstack-images.html
  • La plupart des distributions fournissent aujourd’hui des images cloud.

Cirros

  • Cirros est l’image cloud par excellence
  • OS minimaliste
  • Contient cloud-init

https://launchpad.net/cirros

Cloud-init

  • Cloud-init est un moyen de tirer parti de l’API de metadata, et notamment des user data
  • L’outil est intégré par défaut dans la plupart des images cloud
  • À partir des user data, cloud-init effectue les opérations de personnalisation de l’instance
  • cloud-config est un format possible de user data

Exemple cloud-config

#cloud-config
mounts:
 - [ xvdc, /var/www ]
packages:
 - apache2
 - htop

Comment gérer ses images ?

  • Utilisation d’images génériques et personnalisation à l’instanciation
  • Création d’images intermédiaires et/ou totalement personnalisées : Golden images
    • libguestfs, virt-builder, virt-sysprep
    • diskimage-builder (TripleO)
    • Packer
    • solution “maison”

Configurer et orchestrer ses instances

  • Outils de gestion de configuration (les mêmes qui permettent de déployer OpenStack)
  • Juju

Conclusion

Pour conclure

  • Le cloud révolutionne l’IT
  • OpenStack est le projet libre phare sur la partie IaaS
  • Déployer OpenStack n’est pas une mince affaire
  • L’utilisation d’un cloud IaaS implique des changements de pratique
  • Les métiers d’architecture logicielle et infra évoluent