Вы находитесь на странице: 1из 280

OPENSTACK

1
INTRODUCTION

3.1
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 et de
développement à un environnement cloud

3.2
OBJECTIFS DE LA FORMATION
Assimiler les concepts et le vocabulaire liés au cloud
Manipuler et orchestrer des ressources dans un cloud
OpenStack
Définir, déployer et maintenir une infrastructure dans le
cloud
Architecturer une application cloud-ready

3.3
PRÉ-REQUIS DE LA FORMATION
À l'aise dans un environnement Linux (shell)
Notions de virtualisation
Optionnel :
À l’aise dans un environnement Python

3.4
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
3.5
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 (Logical Volume Management) et systèmes de
fichiers
Notions :
Virtualisation : KVM (Kernel-Based Virtual Machine), libvirt
Réseau : iptables, namespaces
SQL
Optionnel :
À l’aise dans un environnement Python
3.6
LE CLOUD, VUE D'ENSEMBLE

4.1
DÉFINITION FORMELLE

4.2
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
https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication8
145.pdf

4.3
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

4.4
À 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)

4.5
MUTUALISATION DES RESSOURCES
Un cloud propose ses services à de multiples
utilisateurs/organisations (multi-tenant)
Tenant ou projet : isolation logique des ressources
Les ressources sont disponibles en grandes quantités
(considérées illimitées)
Le taux d'occupation du cloud n'est pas visible
La localisation précise des ressources n'est pas visible

4.6
ÉLASTICITÉ RAPIDE
Provisionning et suppression des ressources quasi
instantané
Permet le scaling (passage à l'échelle)
Possibilité d'automatiser ces actions de scaling
Virtuellement pas de limite à cette élasticité

4.7
MESURABILITÉ
L'utilisation des ressources cloud est monitorée par le
fournisseur
Le fournisseur peut gérer son capacity planning et sa
facturation à partir de ces informations
L'utilisateur est ainsi facturé en fonction de son usage précis
des ressources
L'utilisateur peut tirer parti de ces informations

4.8
MODÈLES
On distingue :
modèles de service : IaaS, PaaS, SaaS
modèles de déploiement : public, privé,
hybride

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

4 . 10
PAAS
Platform as a Service
Désigne deux concepts :
Environnement permettant de développer/déployer une
application (spécifique à un langage/framework - exemple :
Python/Django)
Ressources plus haut niveau que l'infrastructure, exemple :
BDD
Utilisateurs cibles : développeurs d'application

4 . 11
SAAS
Software as a Service
Utilisateurs cibles : utilisateurs finaux
Ne pas confondre avec la définition économique du
SaaS

4 . 12
QUELQUECHOSE AS A SERVICE ?
Load balancing as a Service (Infra)
Database as a Service (Platform)
MonApplication as a Service
(Software)
etc.

4 . 13
LES MODÈLES DE SERVICE EN UN SCHÉMA

IaaS - PaaS - SaaS (source : Wikipedia)


4 . 14
CLOUD PUBLIC OU PRIVÉ ?
À qui s'adresse le cloud ?
Public : tout le monde, disponible sur internet
Privé : à une organisation, disponible sur son réseau

4 . 15
CLOUD HYBRIDE
Utilisation mixte de multiples clouds privés et/ou publics
Concept séduisant mais mise en œuvre a priori difficile
Certains cas d'usages s'y prêtent très bien
Intégration continue (CI)
Motivations
Éviter le lock-in
Débordement (cloud bursting)

4 . 16
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 (système)

4 . 17
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)
4 . 18
API 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
4 . 19
REST - EXEMPLES
GET http://endpoint/volumes/
GET http://endpoint/volumes/?size=10
POST http://endpoint/volumes/
DELETE http://endpoint/volumes/xyz

4 . 20
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
}
}

4 . 21
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

4 . 22
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”

4 . 23
LE MARCHÉ

4 . 24
AMAZON WEB SERVICES (AWS), LE LEADER

AWS logo
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

4 . 25
ALTERNATIVES IAAS PUBLICS À AWS
Google Cloud Platform
Microsoft Azure
Rackspace
DreamHost
DigitalOcean
En France :
Cloudwatt (Orange Business
Services)
Numergy (SFR)
OVH
Ikoula
Scaleway
Outscale 4 . 26
FAIRE DU IAAS PRIVÉ
OpenStack
CloudStack
Eucalyptus
OpenNebula

4 . 27
OPENSTACK EN QUELQUES MOTS

OpenStack logo
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

4 . 28
EXEMPLES DE PAAS PUBLIC
Amazon Elastic Beanstalk
(https://aws.amazon.com/fr/elasticbeanstalk)
Google App Engine (https://cloud.google.com/appengine)
Heroku (https://www.heroku.com)

4 . 29
SOLUTIONS DE PAAS PRIVÉ
Cloud Foundry, Fondation (https://www.cloudfoundry.org)
OpenShift, Red Hat (https://www.openshift.org)
Solum, OpenStack (https://wiki.openstack.org/wiki/Solum)

4 . 30
LES CONCEPTS INFRASTRUCTURE AS A SERVICE

4 . 31
LA BASE
Infrastructure :
Compute
Storage
Network

4 . 32
RESSOURCES COMPUTE
Instance
Image
Flavor (gabarit)
Paire de clé
(SSH)

4 . 33
INSTANCE
Dédiée au compute
Durée de vie typiquement courte, à considérer comme
éphémère
Ne doit pas stocker de données persistantes
Disque racine non persistant
Basée sur une image

4 . 34
IMAGE CLOUD
Image disque contenant un OS déjà installé
Instanciable à l'infini
Sachant parler à l'API de metadata

4 . 35
API ... DE METADATA
http://169.254.169.254
Accessible depuis l'instance
Fournit des informations relatives à l'instance
Expose les userdata
L'outil cloud-init permet d'exploiter cette
API

4 . 36
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

4 . 37
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

4 . 38
RESSOURCES RÉSEAU 1/2
Réseau L2
Port réseau
Réseau L3
Routeur
IP flottante
Groupe de sécurité

4 . 39
RESSOURCES RÉSEAU 2/2
Load Balancing as a
Service
VPN as a Service
Firewall as a Service

4 . 40
RESSOURCES STOCKAGE
Le cloud fournit deux types de stockage
Block
Objet

4 . 41
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
Nécessite de provisionner l'espace en définissant la taille du
volume

4 . 42
DU STOCKAGE PARTAGÉ ?
Le stockage block n’est pas une solution de stockage partagé
comme NFS
NFS se situe à une couche plus haute : système de fichiers
Un volume est a priori connecté à une seule machine

4 . 43
"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

4 . 44
STOCKAGE OBJET
API : faire du CRUD sur les données
Pousser et retirer des objets dans un container/bucket
Pas de hiérarchie, pas de répertoires, pas de système de
fichiers
Accès lecture/écriture uniquement par les APIs
Pas de provisioning nécessaire
L’application doit être conçue pour tirer parti du stockage
objet

4 . 45
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
Il existe également des outils d'orchestration (plutôt que des
services)

4 . 46
BONNES PRATIQUES D'UTILISATION

4 . 47
POURQUOI DES BONNES PRATIQUES ?
Deux approches :
Ne pas évoluer
Risquer de ne pas répondre aux attentes
Se contenter d'un cas d'usage test & dev
Adapter ses pratiques au cloud pour en tirer parti pleinement

4 . 48
HAUTE DISPONIBILITÉ (HA)
Le control plane (les APIs) du cloud est HA
Les ressources provisionnées ne le sont pas
forcément

4 . 49
PET VS CATTLE
Comment considérer ses instances ?
Pet
Cattle

4 . 50
INFRASTRUCTURE AS CODE
Avec du code
Provisionner les ressources d'infrastructure
Configurer les dites ressources, notamment les
instances
Le métier évolue : Infrastructure Developer

4 . 51
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
Géré par le cloud
Géré par un composant extérieur

4 . 52
APPLICATIONS CLOUD READY
Stockent leurs données au bon endroit
Sont architecturées pour tolérer les
pannes
Etc.
Cf. https://12factor.net/

4 . 53
DERRIÈRE LE CLOUD

4 . 54
COMMENT IMPLÉMENTER UN SERVICE DE COMPUTE
Virtualisation
Containers
(système)
Bare metal

4 . 55
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

4 . 56
SDS - THÉORÈME CAP
Consistency - Availability - Partition tolerance

4 . 57
OPENSTACK : LE PROJET

5.1
TOUR D'HORIZON

5.2
VUE HAUT NIVEAU

Version simple

5.3
HISTORIQUE
Démarrage en 2010
Objectif : le Cloud Operating System libre
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

5.4
MISSION STATEMENT
To produce a ubiquitous Open Source Cloud Computing p

5.5
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), Pike (2017.2)
Queens (2018.1), Rocky (2018.2)
Premier semestre 2019 : Stein

5.6
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, Rackspace, Yahoo, OVH, Citrix, SAP, ...
Google ! (depuis juillet 2015)
https://www.openstack.org/foundation/companies/

5.7
... 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/

5.8
LES DIFFÉRENTS SOUS-PROJETS
https://www.openstack.org/software/project-navigator/
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
5.9
LES DIFFÉRENTS SOUS-PROJETS (2)
Mais aussi :
Bare metal (Ironic)
Queue service (Zaqar)
Database Service (Trove)
Data processing (Sahara)
DNS service (Designate)
Shared File Systems (Manila)
Key management (Barbican)
Container (Magnum)
Autres
Les clients CLI et bibliothèques
Les outils de déploiement d'OpenStack
Les bibliothèques utilisées par OpenStack
Les outils utilisés pour développer
OpenStack
5 . 10
APIS
Chaque projet supporte son API OpenStack
Certains projets supportent l'API AWS équivalente (Nova/EC2,
Swift/S3)

5 . 11
LES 4 OPENS
Open Source
Open Design
Open Development
Open Community
https://governance.openstack.org/tc/reference/opens.html
https://www.openstack.org/four-opens/

5 . 12
LA FONDATION OPENSTACK
Entité de gouvernance principale et 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)
Ressources humaines : marketing, événementiel, release
management, quelques développeurs (principalement sur
l’infrastructure)
600 organisations à travers le monde
80000 membres individuels dans 170 pays
5 . 13
LA FONDATION OPENSTACK

Les principales entités de la Fondation

5 . 14
OPEN INFRASTRUCTURE
Récemment, la Fondation OpenStack s'élargit à l'Open
Infrastructure
Au-delà d'OpenStack, nouveaux projets chapeautés :
Kata Containers
Zuul
Airship
StarlingX

5 . 15
RESSOURCES
Annonces (nouvelles versions, avis de sécurité) : openstack-
announce@lists.openstack.org
Portail documentation : https://docs.openstack.org/
API/SDK : https://developer.openstack.org/
Gouvernance du projet : https://governance.openstack.org/
Versions : https://releases.openstack.org/
Support :
https://ask.openstack.org/
openstack-discuss@lists.openstack.org
#openstack@Freenode

5 . 16
RESSOURCES
Actualités :
Blog officiel : https://www.openstack.org/blog/
Planet : http://planet.openstack.org/
Superuser : http://superuser.openstack.org/
Ressources commerciales :
https://www.openstack.org/marketplace/ entre autres
Job board : https://www.openstack.org/community/jobs/

5 . 17
USER SURVEY
Sondage réalisé régulièrement par la Fondation (tous les 6
mois)
Auprès des déployeurs et utilisateurs
Données exploitables : https://www.openstack.org/analytics

5 . 18
CERTIFICATION CERTIFIED OPENSTACK ADMINISTRATOR (COA)
La seule certification :
Validée par la Fondation OpenStack
Non liée à une entreprise particulière
Contenu :
Essentiellement orientée utilisateur de cloud OpenStack
https://www.openstack.org/coa/requirements/
Aspects pratiques :
Examen pratique, passage à distance, durée : 2,5 heures
Coût : $300 (deux passages possibles)
Ressources
https://www.openstack.org/coa/
Tips : https://www.openstack.org/coa/tips/
Handbook : http://www.openstack.org/coa/handbook
Exercices (non-officiels) :
https://github.com/AJNOURI/COA
5 . 19
RESSOURCES - COMMUNAUTÉ FRANCOPHONE ET ASSOCIATION

Logo OpenStack-fr
https://openstack.fr/ - https://asso.openstack.fr/
Meetups : Paris, Lyon, Toulouse, Montréal, etc.
OpenStack Days France (Paris) :
https://openstackdayfrance.fr/
Présence à des événements tels que Paris Open Source
Summit
Canaux de communication :
openstack-fr@lists.openstack.org
#openstack-fr@Freenode 5 . 20
FONCTIONNEMENT INTERNE

5 . 21
ARCHITECTURE

Vue détaillée des services


5 . 22
IMPLÉMENTATION
Tout est développé en Python (Django pour la partie web)
Chaque projet est découpé en plusieurs services (exemple :
API, scheduler, etc.)
Réutilisation de composants existants et de bibliothèques
existantes
Utilisation des bibliothèques oslo.* (développées par et pour
OpenStack) : logs, config, etc.
Utilisation de rootwrap pour appeler des programmes sous-
jacents en root

5 . 23
IMPLÉMENTATION - DÉPENDANCES
Base de données : relationnelle SQL (MySQL/MariaDB)
Communication entre les services : AMQP (RabbitMQ)
Mise en cache : Memcached
Stockage distribué de configuration (à venir) : etcd

5 . 24
MODÈLE DE DÉVELOPPEMENT

5 . 25
STATISTIQUES (2017)
2344 développeurs
65823 changements
(commits)
https://www.openstack.org/assets/reports/OpenStack-
AnnualReport2017.pdf

5 . 26
DÉVELOPPEMENT DU PROJET : EN DÉTAILS
Ouvert à tous (individuels et entreprises)
Cycle de développement de 6 mois
Chaque cycle débute par un Project Team Gathering (PTG)
Pendant chaque cycle a lieu un OpenStack Summit

5 . 27
LES OUTILS ET LA COMMUNICATION
Code : Git (GitHub est utilisé comme miroir)
Revue de code (peer review) : Gerrit
Intégration continue (CI: Continous Integration) : Zuul
Blueprints/spécifications et bugs :
Launchpad
StoryBoard
Communication : IRC et mailing-lists
Traduction : Zanata

5 . 28
DÉVELOPPEMENT DU PROJET : EN DÉTAILS

Workflow de changements dans OpenStack


5 . 29
CYCLE DE DÉVELOPPEMENT : 6 MOIS
Le planning est publié, exemple :
https://releases.openstack.org/stein/schedule.html
Milestone releases
Freezes : Feature, Requirements, String
RC releases
Stable releases
Cas particulier de certains composants :
https://releases.openstack.org/reference/release_models.html

5 . 30
PROJETS
Équipes projet (Project Teams) :
https://governance.openstack.org/reference/projects/index.html
Chaque livrable est versionné indépendamment - Semantic
versioning
https://releases.openstack.org/

5 . 31
QUI CONTRIBUE ?
Active Technical Contributor (ATC)
Personne ayant au moins une contribution récente dans un
projet OpenStack reconnu
Droit de vote (TC et PTL)
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/

5 . 32
OÙ TROUVER DES INFORMATIONS SUR LE DÉVELOPPEMENT
D’OPENSTACK
Comment contribuer
https://docs.openstack.org/project-team-guide/
https://docs.openstack.org/infra/manual/
Informations diverses, sur le wiki
https://wiki.openstack.org/
Les blueprints et bugs sur Launchpad/StoryBoard
https://launchpad.net/openstack/
https://storyboard.openstack.org/
https://specs.openstack.org/

5 . 33
OÙ TROUVER DES INFORMATIONS SUR LE DÉVELOPPEMENT
D’OPENSTACK
Les patchs proposés et leurs reviews sont sur Gerrit
https://review.openstack.org/
L’état de la CI (entre autres)
http://status.openstack.org/
Le code (Git) et les tarballs sont disponibles
https://git.openstack.org/
https://tarballs.openstack.org/
IRC
Réseau Freenode
Logs discussions et infos réunions :
http://eavesdrop.openstack.org/
Mailing-lists
http://lists.openstack.org/
5 . 34
UPSTREAM TRAINING
Deux jours de formation
Apprendre à devenir contributeur à
OpenStack
Les outils
Les processes
Travailler et collaborer de manière ouverte

5 . 35
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 : Infrastructure as code open source
https://opensourceinfra.org/
Utilise du cloud (hybride)
Développe certains outils
Zuul
yaml2ical

5 . 36
OPENSTACK SUMMIT
Tous les 6 mois en milieu de cycle de développpement
Aux USA jusqu’en 2013, aujourd'hui alternance Amérique de
Nord et Asie/Europe
Quelques dizaines au début à des milliers de participants
aujourd’hui
En parallèle : conférence (utilisateurs, décideurs) et Forum
(développeurs/opérateurs, remplace une partie du précédent
Design Summit)
Détermine le nom de la prochaine release : lieu/ville à
proximité du Summit

5 . 37
EXEMPLE DU SUMMIT D’AVRIL 2013 À PORTLAND
5 . 38
EXEMPLE DU SUMMIT D’OCTOBRE 2015 À TOKYO
Photo : Elizabeth K. Joseph, CC BY 2.0, Flickr/pleia2

5 . 39
EXEMPLE DU SUMMIT D’OCTOBRE 2015 À TOKYO
Photo : Elizabeth K. Joseph, CC BY 2.0, Flickr/pleia2

5 . 40
EXEMPLE DU SUMMIT D’OCTOBRE 2015 À TOKYO
Photo : Elizabeth K. Joseph, CC BY 2.0, Flickr/pleia2

5 . 41
EXEMPLE DU SUMMIT D’OCTOBRE 2015 À TOKYO
5 . 42
PROJECT TEAM GATHERING (PTG)
Depuis 2017
Au début de chaque cycle
Remplace une partie du précédent Design
Summit
Dédié aux développeurs

5 . 43
TRADUCTION
Équipe officielle 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 Zanata :
https://translate.openstack.org/

5 . 44
DEVSTACK : FAIRE TOURNER RAPIDEMENT UN OPENSTACK

5 . 45
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

5 . 46
FONCTIONNEMENT DE DEVSTACK
Support d'Ubuntu 16.04/17.04, Fedora 24/25, CentOS/RHEL 7,
Debian, OpenSUSE
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

5 . 47
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

5 . 48
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

5 . 49
UTILISER OPENSTACK

6.1
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 + projet (tenant) +
domaine
API AWS : access key ID + secret access key

6.2
LES APIS OPENSTACK
Une API par service OpenStack
Chaque API est versionnée, la rétro-compatibilité est assurée
Le corps des requêtes et réponses est formatté avec JSON
(auparavant XML était supporté aussi)
Architecture REST
https://developer.openstack.org/#api
Certains services sont aussi accessibles via une API différente
compatible AWS

6.3
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 (bibliothèque Python incluant la business logic)
Avec les outils officiels en ligne de commande
Avec Horizon
Au travers d'outils tiers, plus haut niveau (exemple :
Terraform)
6.4
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

6.5
OPENSTACK CLIENT
Client CLI unifié
Commandes du type openstack <ressource ><action >
Ou shell interactif
Vise à remplacer à terme les clients spécifiques
Permet une expérience utilisateur plus homogène
Fichier de configuration clouds.yaml
https://docs.openstack.org/python-
openstackclient/pike/configuration/index.html#clouds-yaml

6.6
KEYSTONE : AUTHENTIFICATION, AUTORISATION ET CATALOGUE
DE SERVICES

6.7
PRINCIPES
Annuaire des utilisateurs et des groupes
Gère des domaines
Liste des projets (tenants)
Catalogue de services
Gère l’authentification et l’autorisation
Fournit un token à l’utilisateur

6.8
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)

6.9
API
API v2 (dépréciée) : admin port 35357, utilisateur port
5000
API v3 : port 5000
Gère utilisateurs, groupes, domaines
Les utilisateurs ont des rôles sur des projets (tenants)
Les services du catalogue sont associés à des endpoints

6 . 10
SCÉNARIO D’UTILISATION TYPIQUE
Interactions avec Keystone

6 . 11
NOVA : COMPUTE

6 . 12
PRINCIPES
Gère principalement 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

6 . 13
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

6 . 14
API
Gère :
Instances
Flavors (types d’instance)
Keypairs
Indirectement : images, security groups (groupes de
sécurité), floating IPs (IPs flottantes)
Reboot / shutdown
Snapshot
Lecture des logs
Accès VNC
Redimensionnement
Migration (admin)
6 . 15
GLANCE : REGISTRE D'IMAGES

6 . 16
PRINCIPES
Registre d'images et de snapshots
Propriétés sur les images
Est utilisé par Nova pour démarrer des instances

6 . 17
API
API v2 : actuelle
API artifacts : future

6 . 18
TYPES D’IMAGES
Glance supporte un large éventail de types d’images, limité par
le support de la technologie sous-jacente à Nova
raw
qcow2
ami
vmdk
iso

6 . 19
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

6 . 20
NEUTRON : RÉSEAU

6 . 21
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
IP flottante, groupe de sécurité

6 . 22
LES IP FLOTTANTES
En plus des fixed IPs portées par les instances
Allocation (réservation pour le projet) d'une IP depuis un pool
Association d'une IP allouée à un port (d'une instance, par
exemple)
Non portées directement par les instances

6 . 23
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é

6 . 24
FONCTIONNALITÉS SUPPLÉMENTAIRES
Outre les fonctions réseau de base niveaux 2 et 3, Neutron peut
fournir d’autres services :
Load Balancing
Firewall : diffère des groupes de sécurité
VPN : permet d’accéder à un réseau privé sans IP
flottantes
QoS

6 . 25
CINDER : STOCKAGE BLOCK

6 . 26
PRINCIPES
Fournit des volumes (stockage block) attachables aux
instances
Gère différents types de volume
Gère snapshots et backups de volumes

6 . 27
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)

6 . 28
HEAT : ORCHESTRATION

6 . 29
GÉNÉRALITÉS
Heat est la solution native OpenStack
Heat fournit une API de manipulation de stacks à partir de
templates
Un template Heat suit le format HOT, basé sur YAML
Des alternatives externes à OpenStack existent, comme
Terraform

6 . 30
UN TEMPLATE HEAT ORCHESTRATION 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

6 . 31
CONSTRUIRE UN TEMPLATE À PARTIR D’EXISTANT
Multiples projets en cours de développement
Flame (Cloudwatt)
HOT builder
Merlin

6 . 32
DÉPLOYER OPENSTACK

7.1
CE QU’ON VA VOIR
Installer OpenStack à la main
https://docs.openstack.org/install-guide/
Donc comprendre son fonctionnement
Passer en revue chaque composant plus en détails
Tour d’horizon des solutions de déploiement

7.2
ARCHITECTURE DÉTAILLÉE

Vue détaillée des services


7.3
ARCHITECTURE SERVICES
7.4
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

7.5
SYSTÈME D’EXPLOITATION
OS Linux avec Python
Ubuntu
Red Hat
SUSE
Debian, Fedora, CentOS,
etc.

7.6
PYTHON

Logo Python
OpenStack est compatible Python 2.7
Comptabilité Python 3 presque complète
Afin de ne pas réinventer la roue, beaucoup de dépendances
sont nécessaires

7.7
BASE DE DONNÉES MYSQL/MARIADB
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 (et
support des migrations)
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

7.8
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

7.9
RABBITMQ

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

7 . 10
“HELLO WORLD” RABBITMQ

Illustration simple du fonctionnement de RabbitMQ

7 . 11
CACHE MEMCACHED
Plusieurs services tirent parti d'un mécanisme de
cache
Memcached est l'implémentation par défaut

7 . 12
KEYSTONE : AUTHENTIFICATION, AUTORISATION ET CATALOGUE
DE SERVICES

7 . 13
INSTALLATION ET CONFIGURATION
Paquet APT : keystone
Intégration serveur web WSGI (Apache par défaut)
Fichier de configuration: /etc/keystone/keystone.conf
Backends utilisateurs/groupes : SQL, LDAP (ou Active
Directory)
Backends projets/rôles/services/endpoints : SQL
Backends tokens : SQL, Memcache, aucun (suivant le type de
tokens)

7 . 14
DRIVERS POUR TOKENS
Uuid
PKI
Fernet

7 . 15
BOOTSTRAP
Création des services et endpoints (à commencer par
Keystone)
Création d'utilisateurs, groupes, domaines
Fonctionnalité de bootstrap

7 . 16
CATALOGUE DE SERVICES
1 service, n endpoints (1 par
région)
1 endpoint, 3 types :
internalURL
adminURL
publicURL

7 . 17
NOVA : COMPUTE

7 . 18
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

7 . 19
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

7 . 20
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

7 . 21
LE SCHEDULER NOVA EN ACTION

Fonctionnement de nova-scheduler
7 . 22
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

7 . 23
GLANCE : REGISTRE D’IMAGES

7 . 24
BACKENDS
Swift ou S3
Ceph
HTTP
Répertoire
local

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

7 . 26
NEUTRON : RÉSEAU EN TANT QUE SERVICE

7 . 27
PRINCIPES
Software Defined Networking (SDN)
Auparavant Quantum et nova-network
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 : LinuxBridge par défaut, d’autres implémentations
libres/propriétaires, logicielles/matérielles existent

7 . 28
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

7 . 29
PLUGINS ML2
Modular Layer 2
LinuxBridge
OpenVSwitch
OpenDaylight
Contrail, OpenContrail
Nuage Networks
VMWare NSX
cf. OpenFlow

7 . 30
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

7 . 31
SCHÉMA
Vue utilisateur du réseau

7 . 32
SCHÉMA
7 . 33
CINDER : STOCKAGE BLOCK

7 . 34
PRINCIPES
Auparavant nova-volume
Attachement via iSCSI par défaut

7 . 35
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

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

7 . 37
HORIZON : DASHBOARD WEB

7 . 38
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


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

7 . 40
UTILISATION
Une zone “admin”
restreinte
Une interface par tenant

7 . 41
SWIFT : STOCKAGE OBJET

7 . 42
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

7 . 43
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)

7 . 44
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

7 . 45
SCHÉMA

Architecture Swift 7 . 46
CEILOMETER : COLLECTE DE MÉTRIQUES

7 . 47
SURVEILLER L’UTILISATION DE SON INFRASTRUCTURE AVEC
CEILOMETER
Indexer et stocker différentes métriques concernant
l’utilisation des différents services du cloud
Fournir des APIs permettant de récupérer ces données
Base pour construire des outils de facturation (exemple :
CloudKitty)

7 . 48
CEILOMETER
Récupère les données et les stocke
Historiquement : stockage MongoDB
Aujourd'hui : stockage Gnocchi

7 . 49
GNOCCHI : TIME-SERIES DATABASE
Pourquoi Gnocchi ? Palier aux problème de scalabilité de
Ceilometer + MongoDB
Initié par des développeurs de Ceilometer et intégré à
l’équipe projet Ceilometer
Fournit une API pour lire et écrire les données
Se base sur une BDD relationnelle et un système de stockage
objet

7 . 50
HEAT : ORCHESTRATION DES RESSOURCES

7 . 51
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)

7 . 52
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

7 . 53
QUELQUES AUTRES COMPOSANTS INTÉRESSANTS

7 . 54
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

7 . 55
OSLO, OU OPENSTACK COMMON
Oslo contient le code commun à plusieurs composants
d’OpenStack
Son utilisation est transparente pour le déployeur

7 . 56
ROOTWRAP -> PRIVSEP
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

7 . 57
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

7 . 58
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

7 . 59
OPENSTACK EN PRODUCTION ET OPÉRATIONS

8.1
BONNES PRATIQUES POUR UN DÉPLOIEMENT EN PRODUCTION

8.2
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)
https://docs.openstack.org/arch-design/

8.3
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

8.4
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

8.5
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 https://openstack-in-
production.blogspot.fr/

8.6
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

8.7
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.

8.8
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 : https://docs.openstack.org/ha-guide/

8.9
HAUTE DISPONIBILITÉ DE L’AGENT L3 DE NEUTRON
Distributed Virtual Router (DVR)
L3 agent HA (VRRP)

8 . 10
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
Guide Operations : https://docs.openstack.org/openstack-
ops/content/
8 . 11
UTILISATION DES QUOTAS
Limiter le nombre de ressources
allouables
Par utilisateur ou par tenant
Support dans Nova
Support dans Cinder
Support dans Neutron
https://docs.openstack.org/user-guide-
admin/content/cli_set_quotas.html

8 . 12
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

8 . 13
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é : https://docs.openstack.org/security-guide/
8 . 14
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
https://docs.openstack.org/openstack-
ops/content/scaling.html#segregate_cloud

8 . 15
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

8 . 16
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

8 . 17
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)

8 . 18
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)

8 . 19
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

8 . 20
UBUNTU CLOUD ARCHIVE (UCA)

Support d'OpenStack dans Ubuntu via l'UCA


8 . 21
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

8 . 22
LES DISTRIBUTIONS OPENSTACK
StackOps : historique
Mirantis : Fuel
HP Helion : Ansible custom
etc.

8 . 23
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

8 . 24
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)

8 . 25
MODULES PUPPET, PLAYBOOKS ANSIBLE
Puppet OpenStack et OpenStack Ansible : modules Puppet et
playbooks Ansible
Développés au sein du projet OpenStack
https://wiki.openstack.org/wiki/Puppet
https://docs.openstack.org/developer/openstack-
ansible/install-guide/

8 . 26
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

8 . 27
GÉRER LES PROBLÈMES

8 . 28
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

8 . 29
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

8 . 30
OPÉRATIONS

8 . 31
GESTION DES LOGS
Centraliser les logs
Logs d'API
Logs autres composants
OpenStack
Logs BDD, AMQP, etc.

8 . 32
BACKUP
Bases de données
Mécanisme de déploiement, plutôt que les fichiers de
configuration

8 . 33
MONITORING
Réponse des APIs
Vérification des services OpenStack et
dépendances

8 . 34
DIVERS
Étendre CIDR Neutron
Nova compute maintenance mode

8 . 35
ARCHITECTURES CLOUD-READY

9.1
CONCEVOIR UNE APPLICATION POUR LE CLOUD

9.2
12-FACTOR
“The Twelve-Factor App” https://12factor.net/
Écrit par Heroku
Suivre (tout) le code dans un VCS
Configuration

9.3
ADAPTER OU PENSER SES APPLICATIONS “CLOUD READY” 1/3
Cf. les design tenets du projet OpenStack et Twelve-Factor
https://12factor.net/
Architecture distribuée plutôt que
monolithique
Facilite le passage à l’échelle
Limite les domaines de failure
Couplage faible entre les composants

9.4
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

9.5
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

9.6
MODULAIRE
Multiples composants de taille
raisonnable
Philosophie Unix
Couplage faible et interface documentée

9.7
PASSAGE À L’ÉCHELLE
Vertical vs Horizontal
Scale up vs Scale out
Plusieurs petites instances plutôt qu’une grosse instance

9.8
STATEFUL VS STATELESS
Beaucoup de stateful dans les applications legacy
Nécessite de partager l’information d’état lorsque plusieurs
workers
Le stateless élimine cette contrainte

9.9
TOLÉRANCE AUX PANNES
L’infrastructure n’est pas hautement disponible
L’API d’infrastructure est hautement disponible
L’application doit anticiper et réagir aux
pannes

9 . 10
STOCKAGE DES DONNÉES
Base de données relationnelles
Base de données NoSQL
Stockage bloc
Stockage objet
Stockage éphémère
Cache, temporaire

9 . 11
DESIGN TENETS D’OPENSTACK (EXEMPLE) 1/2
1. Scalability and elasticity are our main goals
2. Any feature that limits our main goals must be optional
3. Everything should be asynchronous. If you can’t do
something asynchronously, see #2
4. All required components must be horizontally scalable

9 . 12
DESIGN TENETS D’OPENSTACK (EXEMPLE) 2/2
5. Always use shared nothing architecture (SN) or sharding. If
you can’t Share nothing/shard, see #2
6. Distribute everything. Especially logic. Move logic to where
state naturally exists.
7. Accept eventual consistency and use it where it is
appropriate.
8. Test everything. We require tests with submitted code. (We
will help you if you need it)
https://wiki.openstack.org/wiki/BasicDesignTenets

9 . 13
CONCEVOIR UNE INFRASTRUCTURE POUR LE CLOUD

9 . 14
AUTOMATISATION
Automatiser la gestion de l’infrastructure :
indispensable
Création des ressources
Configuration des ressources

9 . 15
INFRASTRUCTURE AS CODE
Travailler comme un développeur
Décrire son infrastructure sous forme de code
(Heat/Terraform, Ansible)
Suivre les changements dans un VCS (git)
Mettre en place de la revue de code
Utiliser des mécanismes de tests
Exploiter des systèmes d'intégration et déploiement continue

9 . 16
BESOIN D’ORCHESTRATION
Manager tous les types de ressources par un point
d’entrée
Description de l’infrastructure dans un fichier (template)
Heat (intégré à OpenStack), Terraform

9 . 17
TESTS ET INTÉGRATION CONTINUE
Style de code
Validation de la syntaxe
Tests unitaires
Tests d'intégration
Tests de déploiement complet

9 . 18
TOLÉRANCE AUX PANNES
Tirer parti des capacités de l'application
Ne pas tenter de rendre l'infrastructure compute
HA

9 . 19
AUTOSCALING GROUP
Groupe d’instances similaires
Nombre variable d’instances
Scaling automatique en fonction de métriques
Permet le passage à l'échelle horizontal

9 . 20
MONITORING
Prendre en compte le cycle de vie des instances : DOWN !=
ALERT
Monitorer le service plus que le serveur

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

9 . 22
COMMENT GÉRER SES IMAGES ?
Utilisation d’images génériques et personnalisation à
l’instanciation
Création d’images plus ou moins personnalisées :
Modification à froid : libguestfs, virt-builder, virt-sysprep
Modification au travers d'une instance : automatisation
possible avec Packer
Construction from scratch : diskimage-builder (TripleO)
Construction from scratch avec des outils spécifiques aux
distributions (openstack-debian-images pour Debian)

9 . 23
CONCLUSION

10 . 1
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

10 . 2