Supports de cours réalisés par Particule

• ex Osones/Alterway
• Expertise Cloud Native
• Expertise DevOps
• Nos offres de formations: https://particule.io/trainings/
• Sources : https://github.com/particuleio/formations/
• HTML/PDF : https://particule.io/formations/

Copyright

• Licence : Creative Commons BY-SA 4.0
• Copyright © 2014-2019 alter way Cloud Consulting
• Copyright © 2020 particule.
• Depuis 2020, tous les commits sont la propriété de leurs auteurs respectifs

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

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
  • Gestion des paquets
  • Manipulation de fichiers de configuration/services
  • LVM et systèmes de fichiers
• Notions :
  • Virtualisation : KVM, libvirt
  • Réseau : iptables, namespaces
  • SQL
• Optionnel:
  • À l’aise dans un environnement Python

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/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)
• 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

É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é

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

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
• 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

SaaS

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

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

Cloud public ou privé ?

À qui s'adresse le cloud ?

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

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)

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)

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)

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

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
• DigitalOcean
• Alibaba Cloud
• En France :
  • Scaleway
  • OVH
  • Outscale
  • Ikoula

Faire du IaaS privé

• OpenStack
• CloudStack
• Eucalyptus
• OpenNebula

OpenStack en quelques mots

• Naissance en 2010
• Fondation OpenStack depuis 2012...
• ...rebaptisée Open Infrastructure Foundation en 2020 (https://openinfra.dev/)
• É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

• Amazon Elastic Beanstalk (https://aws.amazon.com/fr/elasticbeanstalk)
• Google App Engine (https://cloud.google.com/appengine)
• Heroku (https://www.heroku.com)

Solutions de PaaS privé

• Cloud Foundry, Fondation (https://www.cloudfoundry.org)
• OKD, Red Hat (https://www.okd.io)
• Solum, OpenStack (https://wiki.openstack.org/wiki/Solum)

Les concepts Infrastructure as a Service

La base

• Infrastructure :
• Compute
• Storage
• Network

Ressources compute

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

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

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
• Expose les userdata
• L'outil 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
• Nécessite de provisionner l'espace en définissant la taille du volume

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

"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

• 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

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)

Bonnes pratiques d'utilisation

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

Haute disponibilité (HA)

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

Pet 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
• Géré par le cloud
• Géré par un composant extérieur

Applications cloud ready

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

Cf. https://12factor.net/

Derrière le cloud

Comment implémenter un service de Compute

• Virtualisation
• Containers (système)
• 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, OpenIO, OpenSDS,...

SDS - Théorème CAP

Vue haut niveau (1/2)

Vue haut niveau (2/2)

Historique

• Démarrage du projet en 2010
• Objectif : le Cloud Operating System libre
• Fusion de deux projets : Rackspace (Storage) et la NASA (Compute)
• Logiciel libre distribué sous licence Apache 2.0
• Naissance de l'OpenStack Foundation en 2012, rebaptisée Open Infrastructure Foundation en octobre 2020

Mission

"To produce an 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."

OpenStack en 2021

"OpenStack is one of the top 3 most active open source projects and manages 10 million compute cores."

https://www.openstack.org/software/

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)
• Stein (2019.1), Train (2019.2)
• Ussuri (2020.1), Victoria (2020.2)
• Wallaby (2021.1)
• Second semestre 2021 : Xena

Sponsors/contributeurs ...

• Editeurs : Red Hat, Canonical, Mirantis, VMware, ...
• Constructeurs/puces et serveurs : IBM, Intel
• Constructeurs/réseau : Cisco, Huawei, ...
• Constructeurs/stockage : Dell EMC
• Fournisseurs de services cloud et telco : Rackspace, Vexxhost, OVH, ...
• Telco : Deutsche Telekom, Tencent, China Mobile, NTT, ATT, ...
• Google (depuis juillet 2015)

... et utilisateurs

• BBC
• Banco Santander, Société Générale
• BMW, Volkswagen AG
• Cathay Pacific
• CERN
• China Railway
• Ministère de l'Intérieur (France)
• Walmart
• Wikimedia
• et beaucoup d'autres

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

Les principaux composants d'OpenStack (1/3)

• Identity : Keystone
• Compute : Nova, Placement
• Storage : Cinder (block), Swift (object), Manila (shared file system)
• Networking : Neutron (sdn), Octavia (lbaas), Designate (dns)
• Image : Glance
• Dashboard : Horizon
• Telemetry : Ceilometer
• Alerting : AODH
• Orchestration : Heat (infra as code), Mistral (workflow), Blazar (resource reservation)

https://www.openstack.org/software/project-navigator/

Les principaux composants d'OpenStack (2/3)

Et aussi :

• Bare metal : Ironic
• Container : Magnum
• Message Queue : Zaqar
• Database : Trove
• Data processing : Sahara
• Key management : Barbican
• Billing : Cloudkitty
• Application catalog : Murano
• ...

Les principaux composants OpenStack (3/3)

Autres :

• OpenStack sdk (bibliothèque python) et OpenStack client (CLI)
• Les outils de déploiement d'OpenStack (OSA)
• Les bibliothèques utilisées par OpenStack (Oslo)
• Les outils utilisés pour développer OpenStack (git, gerrit, zuul,...)

APIs

• Chaque composant maintient sa propre API OpenStack
• Certains composants supportent l'API AWS équivalente (Nova/EC2, Swift/S3)

Software map

La Fondation OpenStack

• Rebaptisée Open Infrastructure Foundation en 2020
• Entité de gouvernance principale et représentation juridique
• Les membres du "Board of Directors" sont issus des entreprises sponsors et des membres individuels élus
• Tout le monde peut devenir membre individuel (gratuit, pas de cotisation)
• Ressources humaines : marketing, événementiel, release management, quelques développeurs (principalement sur l’infrastructure)
• 710 organisations dans le monde, 110 000 membres, 182 pays
• Rapport annuel: https://www.openstack.org/annual-reports/2020-openinfra-foundation-annual-report/
• https://osf.dev

Open Infrastructure Foundation

Open Infrastructure

• En 2018, la Fondation OpenStack s'élargit à l'Open Infrastructure

https://openinfra.dev/about/open-infrastructure/

"The integration of open alternatives for all the different forms that compute storage and networking are taking now and in the future. The interoperable open source components are production ready, scale easily, and businesses can rely on them for real and emerging workloads."

• Au-delà d'OpenStack, des nouveaux projets sont incubés :
  • Airship
  • Kata Containers
  • StarlingX
  • Zuul

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/

Ressources (1/3)

• Membres et contributeurs :
  • https://www.openstack.org/community/
• Annonces (nouvelles versions, avis de sécurité) :
  • openstack-announce@lists.openstack.org
• Documentation : https://docs.openstack.org/
• API/SDK : https://developer.openstack.org/
• Bug report : https://bugs.launchpad.net/openstack
• Gouvernance : https://governance.openstack.org/
• Versions : https://releases.openstack.org/

Ressources (2/3)

• Support :
  • https://stackoverflow.com/questions/tagged/openstack
  • https://serverfault.com/tags/openstack/info
  • openstack-discuss@lists.openstack.org
  • #openstack@Freenode
• Actualités :
  • Blog officiel : https://www.openstack.org/blog/
  • Planet : http://planet.openstack.org/
  • Expériences utilisateurs : http://superuser.openstack.org/

Ressources (3/3)

• Ressources commerciales :
  • https://www.openstack.org/marketplace/
• Job board :
  • https://www.openstack.org/community/jobs/

User Survey

• Enquête réalisée chaque année par la Fondation
• Auprès des déployeurs et utilisateurs
• Résultats publiés :
  • https://www.openstack.org/analytics

Certification : Certified OpenStack Administrator (COA)

• Seule certification OpenStack existante
• Validée par la Fondation OpenStack
• Contenu :
  • Essentiellement orienté utilisateur
  • Pré-requis : https://www.openstack.org/coa/requirements/
• Modalités :
  • Examen pratique (hands on), à distance, durée 3 heures maxi
  • Coût : USD 400
  • Inscription : https://www.openstack.org/coa/
• Ressources :
  • Handbook : https://www.openstack.org/coa/handbook/

Communauté francophone et association

• https://openstack.fr - https://asso.openstack.fr
• Meetups : Paris, Lyon, 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@oftc

Généralités

Principes

• Toutes les fonctionnalités sont accessibles par l’API
• Les clients (y compris le dashboard Horizon) utilisent l’API
• Des identifiants sont nécessaires :
• utilisateur
• mot de passe
• projet (aka tenant)
• domaine

Les APIs OpenStack

• Une API par service OpenStack :
• Versionnée, la rétro-compatibilité est assurée
• Le corps des requêtes et réponses est formatté avec JSON
• Architecture REST
• Les ressources gérées sont spécifiques à un projet

Un cloud OpenStack déployé dans les règles de l'art fournit des APIs hautement disponibles.

(La haute-disponibilité des instances est un autre sujet)

https://developer.openstack.org/#api

Accès aux APIs

• Direct, en HTTP, via des outils comme curl
• En mode programmatique, avec une bibliothèque :
• OpenStackSDK
• D’autres implémentations, y compris pour d’autres langages (gophercloud, jclouds,...)
• Avec le CLI officiel
• Avec le dashboard Horizon (WUI)
• Avec des outils tiers de plus haut niveau tels que Terraform

Clients officiels

• OpenStack fournit des clients officiels
• Historiquement : python-PROJETclient (bibliothèque Python et CLI)
• Aujourd'hui : openstackclient (CLI)
• CLI
• L’authentification se fait en passant les identifiants par paramètres, variables d’environnement ou fichier de configuration (yaml)
• L’option --debug affiche les requêtes et les réponses

OpenStack Client

• CLI unifié
• Commandes du type openstack <ressource> <action> (mode interactif disponible) openstack server list
• Vise à remplacer les clients CLI spécifiques
• Permet une expérience utilisateur plus homogène
• Fichier de configuration clouds.yaml

https://docs.openstack.org/python-openstackclient/latest/configuration/index.html#configuration-files

Keystone : identité et catalogue de services

Principes

Keystone est responsable de l'authentification, des autorisations et du catalogue de services.

• L'utilisateur standard s'authentifie auprès de Keystone
• L'administrateur intéragit régulièrement avec Keystone (pour gérer les projets, utilisateurs, autorisations,...)

APIs

• API keystone v3 --> port 5000
• Gère :
• Domaines
• Projets
• Utilisateurs, groupes
• Rôles (lien entre utilisateur et projet)
• Services et endpoints (catalogue de services)
• Fournit :
• Tokens d'authentification

Catalogue de services

• Pour chaque service, plusieurs endpoints (URLs) sont possibles en fonction de :
• la région
• le type d'interface (public, internal, admin)

Scénario d’utilisation typique

Nova : Compute

Principes

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

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

Ressources gérées :

• Instances
• Flavors : vcpu, ram, disque de boot
• Keypairs (clés ssh) : ressource propre à l'utilisateur (et non au projet)

Actions sur les instances

• Reboot / shutdown
• Snapshot
• Resize
• Migration (admin)
• Deletion
• Lecture des logs
• Accès console

Affinity/anti-affinity

• Demander à Nova de démarrer 2 ou plus instances :
• le plus proche possible (affinity)
• le plus éloigné possible (anti-affinity)
• Besoin de performances ou besoin de distribution/résistance aux pannes

Service metadata

• API pour les instances
• Pour obtenir la clé publique, l'adresse IP, les user data,...
• URL spécifique : `curl http://169.254.169.254/openstack

Cinder : Stockage block

Principes

• Fournit des volumes (stockage block) attachables aux instances (/dev)
• Gère différents types de volume
• Gère snapshots et backups de volumes

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)

Glance : registre d'images

Principes

• Registre d'images et de snapshots
• Propriétés sur les images

API

• API v2 : version courante, gère images et snapshots d'instances

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

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

Visibilité et partage des images

• Image publique : accessible à tous les projets
• Par défaut, seul l'administrateur peut rendre une image publique
• Image privée : accessible uniquement au projet auquel elle appartient
• Image partagée : accessible à un ou plusieurs autre(s) projet(s)

Images cloud

Une image cloud c’est :

• Une image disque contenant un OS déjà installé
• Un OS sachant parler à l’API de metadata du cloud (avec cloud-init)
• Détails : https://docs.openstack.org/image-guide/openstack-images.html

La plupart des distributions Linux fournissent des images régulièrement mises à jour :

• Ubuntu : https://cloud-images.ubuntu.com/
• Debian : https://cdimage.debian.org/cdimage/openstack/
• CentOS : https://cloud.centos.org/centos/

Cloud-init

• Cloud-init est un moyen de tirer parti de l’API de metadata, et notamment des user data
• 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:
 - [ vda2, /var/www ]
packages:
 - apache2
package_update: true

Neutron : réseau

API

L’API permet notamment de manipuler les ressources :

• Réseau : niveau 2
• Sous-réseau : niveau 3
• Port : attachable à une interface sur une instance, un load-balancer, etc.
• Routeur
• IP flottante
• Groupe de sécurité

Les IP flottantes

• Permettent d'exposer une instance au réseau externe
• En plus des fixed IPs portées par les instances
• Non portées directement par les instances
• Allocation (réservation par le projet) d'une IP depuis un pool
• Association à un port d'une IP allouée

Les groupes de sécurité

• Équivalents à un pare-feu devant chaque instance
• Une instance peut être associée à un ou plusieurs groupes de sécurité
• Gestion des accès en entrée (ingress) et sortie (egress)
• Règles de filtrage par protocole (TCP/UDP/ICMP) et par port
• La source d'une règle est soit une adresse IP, un réseau ou un autre groupe de sécurité

Fonctionnalités supplémentaires

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

• VPN : permet d’accéder à un réseau privé sans IP flottantes
• QoS : règles de gestion de la bande passante

Octavia : load balancer

Principes

• Fournit des fonctionnalités de load balancing aux projets
• Load balancing implémenté par des instances spécifiques, les amphores
• Gestion de la haute-disponibilité des load balancers eux-mêmes
• Agnostique des technologies sous-jacentes
• Basé par défaut sur HAProxy

Composants : vue aérienne

API

Version courante : V2

L'API Octavia permet de gérer les ressources suivantes :

• Load balancer
• Listener
• Pool
• Member
• Health monitor
• Rules
• Policies

Heat : Orchestration

Généralités

• Heat est la solution native OpenStack du service d'orchestration
• Il permet de décrire, dans des templates YAML, des ensembles cohérents de ressources virtuelles
• Heat fournit une API de manipulation de stacks à partir de templates
• Un template Heat suit le format HOT (Heat Orchestration Template)
• Il est possible de générer des templates interactivement avec le dashboard Horizon

Exemple de template

heat_template_version: 2018-08-31
description: Simple template to deploy a single compute instance
parameters:
  instance_name:
    type: string
    label: Instance Name
    default: my_instance
  subnet_id:
     type: string
resources:
  instance:
    type: OS::Nova::Server
    properties:
      name: { get_param: instance_name }
      image: cirros
      flavor: m1.small
      networks:
        - port: { get_resource: instance_port }
  instance_port:
    type: OS::Neutron::Port
    properties:
      network_id: { get_param: subnet_id }
      fixed_ips:
        - subnet_id: { get_param: subnet_id }
outputs:
  fixed_ip: { get_attr: [ instance, first_address ] 

Horizon : Dashboard web

Principes

• Fournit une interface web (WUI) à l'utilisateur et à l'administrateur OpenStack
• S'appuie sur les services déployés pour déterminer les fonctionnalités offertes dans le WUI
• Log in sans préciser un projet : Horizon détermine la liste des projets accessibles

Utilisation

• Fonctionne bien avec Firefox et Chrome
• Echanges HTTPS
• Authentification de type username/password
• Notion de projet courant, possibilité de basculer d'un projet à l'autre
• Une zone “admin” restreinte
• Support multilingue

La référence : les 12 facteurs

“The Twelve-Factor App” https://12factor.net/fr/

• Publié par Heroku https://www.heroku.com/what/
• Ecrit par des développeurs, des architectes et des ops
• Recueil de préconisations techniques issues d'expériences terrain
• Destiné aux développeurs et aux personnes en charge du déploiement et du Run
• Applicable quel que soit le langage de programmation

Les 12 facteurs en détails (1/2)

1. Base de code : unique, suivie dans un VCS, plusieurs déploiements
2. Dépendances : les isoler et les déclarer explicitement
3. Configuration : différencier les environnements via les variables de conf.
4. Services externes : les traiter comme des ressources attachées
5. Build, release, run : séparer strictement les étapes d’assemblage et d’exécution
6. Processus : exécuter l’application comme un ou plusieurs processus sans état

Les 12 facteurs en détails (2/2)

7. Ports : exporter les services de l'application via des ports TCP
8. Mise à l'échelle : utiliser le modèle de processus
9. Jetable : maximisez la robustesse avec des démarrages rapides et des arrêts en douceur
10. Parité dev/prod : gardez les différents environnements aussi proches que possible
11. Logs : les traiter comme des flux d’évènements
12. Processus d’administration et de maintenance : les lancer comme des processus one-off

Penser son application “cloud ready” 1/3

• Une base de code unique suivie dans un VCS (Git,...)
• Une configuration par environnement
• Architecture distribuée plutôt que monolithique
  • Facilite le passage à l’échelle
  • Limite les domaines de failure
• Couplage faible entre les composants

Penser son application “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

Penser son application “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 bloc
  • Stockage objet
• Utiliser des outils de journalisation standards

Modularité

• Philosophie Unix (Keep It Simple Stupid)
• Multiples composants de taille raisonnable
• Couplage faible et interface documentée

Passage à l’échelle

• Pets versus Cattle
• Vertical vs Horizontal
• Scale up/down vs Scale out/in
• Plusieurs petites instances plutôt qu’une seule grosse

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

Tolérance aux pannes

• Les APIs du cloud sont hautement disponibles
• Le cloud ne garantit pas la haute disponibilté de l'application
• L’application prend en charge sa propre tolérance aux pannes

Modèles de déploiement

• Blue-Green (attention aux quotas)
• Rolling
• Canary

Stockage des données

• Base de données relationnelle
• Base de données NoSQL
• Stockage bloc
• Stockage objet
• Stockage éphémère

Gestion des logs

• Rester "applicatif"
• Enrichir les logs
• Ne pas présupposer le backend de traitement -> dans la conf

Exemple en python

appLog.conf:

[logger_myapp]
qualname=mycompany.myapp
level=INFO
handlers=console
propagate=0

app.py:

#!/usr/bin/python
# -*- coding: utf-8 -*-
import logging
log = logging.getLogger('mycompany.myapp.maintask')
log.info('Main worker started')

2018-12-24 22:20:02 INFO appuser Main worker started

Logging flow

Migration des applications legacy

• Rappel des enjeux
• Migrer ou non : critères de décision

L'infra au service de son application

• Souplesse
• Résilience
• Performance
• Opérabilité

Une infra, ça évolue !

• Dimensionnement des clusters
• Maintenance des O.S. « guest » et du middleware
• Règles SSI : segmentation réseau, filtrage de flux, proxys, bastions, annuaires
• Ajout de nouveaux services

Mécaniser, automatiser, industrialiser

• Le niveau d'anxiété des comités face à la décision de déployer est inversement proportionnelle à la fréquence des MEP => cercle vicieux
• (re)Construire, faire évoluer et maintenir les infras hébergées dans le cloud
• Reconstruction totale ou partielle à la demande
• Reproductibilité
• C'est Automagique !

Automatisation

• Mécaniser la gestion de l’infrastructure : indispensable
• Automatiser la gestion de l’infrastructure : un plus !
• Création des ressources
• Configuration des ressources

Infrastructure as Code

• L'infra s'appréhende comme du code
• Travailler comme un développeur
• Décrire son infrastructure sous forme de code (Heat, Terraform)
• Suivre les changements dans un VCS (git), qui devient la référence
• Mettre en oeuvre un système d'intégration et de déploiement continus (CI/CD)

Approche de Heat

• Un service <-> une API OpenStack
• Notions de stack et description YAML
• Précautions d'usage (stack update)
• Cas d'usage type

Exemple Heat

---
heat_template_version: 2018-08-31
description: A single nova instance
parameters:
  flavorName:
    type: string
resources:
  instance:
    type: OS::Nova::Server
    properties:
      name: MonInstance
      image: debianStretchOfTheDay
      flavor: {get_param: flavorName}
      key_name: MaCleSSH
outputs:
  instanceId:
    value: {get_resource: instance}

Approche de Terraform

• L'aspect "cloud agnostique"
• Le DSL de Terraform
• L'exigence Infra as Code (terraform.tfstate)
• Cas d'usage type

Exemple Terraform

#  A single nova instance

# Configure the OpenStack Provider
provider "openstack" {
  user_name   = "MyName"
  tenant_name = "MyTenant"
  password    = "MyPwd"
  auth_url    = "http://myauthurl:5000/v2.0"
  region      = "RegionOne"
}

resource "openstack_compute_instance_v2" "MonInstance" {
  name            = "MonInstance"
  count           = "1"
  image_name      = ""
  flavor_name     = "${var.flavor}"
  key_pair        = "MaCleSSh"
}

Agilité et CI/CD appliquées à l'infra

• Style de code
• Vérification de la syntaxe
• Tests unitaires
• Tests d'intégration
• Tests fonctionnels de bout en bout

Tolérance aux pannes

• Notion de résilience
• Load balancers
• Floating IPs
• Groupes de serveurs stateless
• Healthchecks

Mise à l'échelle / élasticité horizontale

• Groupe d’instances similaires, autoscaling group
• Nombre d’instances variable
• Scaling automatique en fonction de métriques

Supervision

• Prendre en compte le cycle de vie des instances : DOWN != ALERT
• Monitorer les services plutôt que les serveurs
• Oublier les adresses IP ! Exposer un web service
• Prévoir un healthcheck fonctionnel (use case "métier")

Backup, PCA

• Infrastructure : être capable de reconstruire n'importe quel environnement à tout moment
• Données (de l'application, logs) : utiliser les modes de stockage bloc (volumes) et objet (dossiers)

Gérer ses images

• Utilisation d’images génériques et personnalisation à l’instanciation (cloud-init)
• Création d’images offline :
  • from scratch : diskimage-builder (TripleO)
  • from scratch avec des outils spécifiques aux distributions (openstack-debian-images pour Debian)
  • modifiées avec libguestfs, virt-builder, virt-sysprep
• Création d’images via une instance :
  • automatisation possible avec Packer, Terraform, le CLI ou les API du IaaS
  • Golden images

Pour conclure

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