CLOUD › formations › pdf › cloud.fr.pdf · 2020-03-19 · OBJECTIFS DE LA FORMATION : CLOUD Comprendre les principes du cloud et son intérêt Connaitre le vocabulaire inhérent

CLOUD

1

CONCERNANT CES SUPPORTS DE COURS

2 . 1

SUPPORTS DE COURS RÉALISÉS PAR ALTER WAY CLOUDCONSULTING

ex Osones -

Copyright © 2014 - 2019 alter way CloudConsultingLicence : Sources : HTML/PDF :

Licence Creative Commons BY-SA 4.0

https://cloud-consulting.alterway.fr

Creative Commons BY-SA 4.0https://github.com/Alterway/formations/

https://osones.com/formations/

2 . 2

INTRODUCTION

3 . 1

OBJECTIFS DE LA FORMATION : CLOUDComprendre les principes du cloud et son intérêtConnaitre le vocabulaire inhérent au cloudAvoir une vue d’ensemble sur les solutions existantes encloud public et privéPosséder les clés pour tirer parti au mieux du IaaSPouvoir déterminer ce qui est compatible avec la philosophiecloud ou pasAdapter ses méthodes d’administration système et dedéveloppement à un environnement cloud

3 . 2

LE CLOUD, VUE D'ENSEMBLE

4 . 1

DÉFINITION FORMELLE

4 . 2

CARACTÉRISTIQUESFournir un (des) service(s)...

Self serviceÀ travers le réseauMutualisation desressourcesÉlasticité rapideMesurabilité

Inspiré de la définition du NISThttps://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-

145.pdf

4 . 3

SELF SERVICEL'utilisateur accède directement au servicePas d'intermédiaire humainRéponses immédiatesCatalogue de services permettant leurdécouverte

4 . 4

À TRAVERS LE RÉSEAUL'utilisateur accède au service à travers le réseauLe fournisseur du service est distant du consommateurRéseau = internet ou pasUtilisation de protocoles réseaux standards (typiquement :HTTP)

4 . 5

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

4 . 6

ÉLASTICITÉ RAPIDEProvisionning et suppression des ressources quasiinstantanéPermet le scaling (passage à l'échelle)Possibilité d'automatiser ces actions de scalingVirtuellement pas de limite à cette élasticité

4 . 7

MESURABILITÉL'utilisation des ressources cloud est monitorée par lefournisseurLe fournisseur peut gérer son capacity planning et safacturation à partir de ces informationsL'utilisateur est ainsi facturé en fonction de son usage précisdes ressourcesL'utilisateur peut tirer parti de ces informations

4 . 8

MODÈLESOn distingue :

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

4 . 9

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

4 . 10

PAASPlatform as a ServiceDésigne deux concepts :Environnement permettant de développer/déployer uneapplication (spécifique à un langage/framework - exemple :Python/Django)Ressources plus haut niveau que l'infrastructure, exemple :BDDUtilisateurs cibles : développeurs d'application

4 . 11

SAASSoftware as a ServiceUtilisateurs cibles : utilisateurs finauxNe pas confondre avec la définition économique duSaaS

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 internetPrivé : à une organisation, disponible sur son réseau

4 . 15

CLOUD HYBRIDEUtilisation mixte de multiples clouds privés et/ou publicsConcept séduisant mais mise en œuvre a priori difficileCertains cas d'usages s'y prêtent très bienIntégration continue (CI)MotivationsÉviter le lock-inDébordement (cloud bursting)

4 . 16

L'INSTANT VIRTUALISATIONMise au point.

La virtualisation est une technologie permettantd'implémenter la fonction computeUn cloud fournissant du compute peut utiliser lavirtualisationMais peut également utiliser :Du bare-metalDes containers (système)

4 . 17

LES APIS, LA CLÉ DU CLOUDRappel : API pour Application Programming InterfaceAu sens logiciel : Interface permettant à un logiciel d’utiliserune bibliothèqueAu sens cloud : Interface permettant à un logiciel d’utiliser unservice (XaaS)Interface de programmation (via le réseau, souvent HTTP)Frontière explicite entre le fournisseur (provider) etl'utilisateur (user)Définit la manière dont l'utilisateur communique avec lecloud pour gérer ses ressourcesGérer : CRUD (Create, Read, Update, Delete)

4 . 18

API RESTUne ressource == une URI (Uniform Resource Identifier)Utilisation des verbes HTTP pour caractériser les opérations(CRUD)GETPOSTPUTDELETEUtilisation des codes de retour HTTPReprésentation des ressources dans le corps des réponsesHTTP

4 . 19

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

4 . 20

EXEMPLE CONCRETGET /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É ÉCONOMIQUEAppréhender les ressources IT comme des services“fournisseur”Faire glisser le budget “investissement” (Capex) vers lebudget “fonctionnement” (Opex)Réduire les coûts en mutualisant les ressources, etéventuellement avec des économies d'échelleRéduire les délaisAligner les coûts sur la consommation réelle des ressources

4 . 22

POURQUOI LE CLOUD ? CÔTÉ TECHNIQUEAbstraire les couches basses (serveur, réseau, OS, stockage)S’affranchir de l’administration technique des ressources etservices (BDD, pare-feux, load-balancing, etc.)Concevoir des infrastructures scalables à la voléeAgir sur les ressources via des lignes de code et gérer lesinfrastructures “comme du code”

4 . 23

LE MARCHÉ

4 . 24

AMAZON WEB SERVICES (AWS), LE LEADER

AWS logoLancement en 2006À l'origine : services web "e-commerce" pourdéveloppeursPuis : d'autres services pour développeursEt enfin : services d'infrastructureRécemment, SaaS

4 . 25

ALTERNATIVES IAAS PUBLICS À AWSGoogle Cloud PlatformGoogle Cloud PlatformMicrosoft AzureMicrosoft AzureRackspaceDreamHostDigitalOceanEn France :Cloudwatt (Orange BusinessServices)Numergy (SFR)OVHIkoulaScalewayOutscale

4 . 26

FAIRE DU IAAS PRIVÉOpenStackOpenStackCloudStackEucalyptusOpenNebula

4 . 27

OPENSTACK EN QUELQUES MOTS

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

4 . 28

EXEMPLES DE PAAS PUBLICAmazon Elastic Beanstalk( )Google App Engine ( )Heroku ( )

https://aws.amazon.com/fr/elasticbeanstalkhttps://cloud.google.com/appengine

https://www.heroku.com

4 . 29

SOLUTIONS DE PAAS PRIVÉCloud Foundry, Fondation ( )OpenShift, Red Hat ( )Solum, OpenStack ( )

https://www.cloudfoundry.orghttps://www.openshift.org

https://wiki.openstack.org/wiki/Solum

4 . 30

LES CONCEPTS INFRASTRUCTURE AS A SERVICE

4 . 31

LA BASEInfrastructure :ComputeStorageNetwork

4 . 32

RESSOURCES COMPUTEInstanceImageFlavor (gabarit)Paire de clé(SSH)

4 . 33

INSTANCEDédiée au computeDurée de vie typiquement courte, à considérer commeéphémèreNe doit pas stocker de données persistantesDisque racine non persistantBasée sur une image

4 . 34

IMAGE CLOUDImage disque contenant un OS déjà installéInstanciable à l'infiniSachant parler à l'API de metadata

4 . 35

API ... DE METADATAhttp://169.254.169.254Accessible depuis l'instanceFournit des informations relatives à l'instanceExpose les userdataL'outil cloud-init permet d'exploiter cetteAPI

4 . 36

FLAVOR (GABARIT)Instance type chez AWSDéfinit un modèle d’instance en termes de CPU, RAM, disque(racine), disque éphémèreLe disque éphémère a, comme le disque racine, l’avantaged’être souvent local donc rapide

4 . 37

PAIRE DE CLÉClé publique + clé privée SSHLe cloud manipule et stocke la clé publiqueCette clé publique est utilisée pour donner un accès SSH auxinstances

4 . 38

RESSOURCES RÉSEAU 1/2Réseau L2Port réseauRéseau L3RouteurIP flottanteGroupe de sécurité

4 . 39

RESSOURCES RÉSEAU 2/2Load Balancing as aServiceVPN as a ServiceFirewall as a Service

4 . 40

RESSOURCES STOCKAGELe cloud fournit deux types de stockage

BlockObjet

4 . 41

STOCKAGE BLOCKVolumesVolumes attachables à une instanceAccès à des raw devices type /dev/vdbPossibilité d’utiliser n’importe quel système de fichiersPossibilité d'utiliser du LVM, du chiffrement, etc.Compatible avec toutes les applications existantesNécessite de provisionner l'espace en définissant la taille duvolume

4 . 42

DU STOCKAGE PARTAGÉ ?Le stockage block n’est paspas une solution de stockage partagécomme NFSNFS se situe à une couche plus haute : système de fichiersUn volume est a priori connecté à une seule machine

4 . 43

"BOOT FROM VOLUME"Démarrer une instance avec un disque racine sur un volumevolume

Persistance des données du disqueracineSe rapproche du serveur classique

4 . 44

STOCKAGE OBJETAPI : faire du CRUD sur les donnéesPousser et retirer des objetsobjets dans un containercontainer/bucketPas de hiérarchie, pas de répertoires, pas de système defichiersAccès lecture/écriture uniquement par les APIsPas de provisioning nécessaireL’application doit être conçue pour tirer parti du stockageobjet

4 . 45

ORCHESTRATIONOrchestrer la création et la gestion des ressources dans lecloudDéfinition de l'architecture dans un templatetemplateLes ressources créées à partir du templatetemplate forment la stackstackIl existe également des outils d'orchestration (plutôt que desservices)

4 . 46

BONNES PRATIQUES D'UTILISATION

4 . 47

POURQUOI DES BONNES PRATIQUES ?Deux approches :

Ne pas évoluerRisquer de ne pas répondre aux attentesSe contenter d'un cas d'usage test & devAdapter ses pratiques au cloud pour en tirer parti pleinement

4 . 48

HAUTE DISPONIBILITÉ (HA)Le control plane (les APIs) du cloud est HALes ressources provisionnées ne le sont pasforcément

4 . 49

PET VS CATTLEComment considérer ses instances ?

PetCattle

4 . 50

INFRASTRUCTURE AS CODEAvec du code

Provisionner les ressources d'infrastructureConfigurer les dites ressources, notamment lesinstances

Le métier évolue : Infrastructure Developer

4 . 51

SCALING, PASSAGE À L'ÉCHELLEScale out plutôt que Scale upScale out : passage à l'échellehorizontalScale up : passage à l'échelle verticalAuto-scalingGéré par le cloudGéré par un composant extérieur

4 . 52

APPLICATIONS CLOUD READYStockent leurs données au bon endroitSont architecturées pour tolérer lespannesEtc.

Cf. https://12factor.net/

4 . 53

DERRIÈRE LE CLOUD

4 . 54

COMMENT IMPLÉMENTER UN SERVICE DE COMPUTEVirtualisationContainers(système)Bare metal

4 . 55

IMPLÉMENTATION DU STOCKAGE : (SOFTWARE DEFINEDSTORAGE) SDS

AttentionAttention : ne pas confondre avec le sujet block vs objet

Utilisation de commodity hardwarePas de RAID matérielLe logiciel est responsable de garantir les donnéesLes pannes matérielles sont prises en compte et géréesLe projet CephCeph et le composant OpenStack SwiftOpenStack Swiftimplémentent du SDS

Voir aussi ScalityScality

4 . 56

SDS - THÉORÈME CAP

Consistency - Availability - Partition tolerance

4 . 57