Informaticiens du bâtiment

Supports de cours

Module 160 – Concevoir et mettre en service les solutions cloud

Compétence

Conçoit des prestations et des solutions de communication pour une exploitation virtualisée au niveau local (On-Premises) ou dans le cloud et les met en service.

Objet

Solution cloud pour une PME

Objectifs opérationnels

  • Conçoit des systèmes virtualisés et conseille la cliente ou le client sur les
    avantages et les inconvénients des systèmes respectifs.
  • Conçoit des systèmes de cloud et conseille la cliente ou le client sur les avantages et les inconvénients des systèmes respectifs.
  • Met en service des prestations virtualisées simples.
  • Met en service des solutions de communication virtualisées simples.

Voir le descriptif détaillé du module 160 …

Table des matières

Le module 160 sur cockpit eit…

Cloud – computing – Info nuagique

Présentation Cloud computing – Info nuagique

Au fil de l’évolution de l’informatique, les systèmes informatiques se virtualisent et sont de plus en plus caché derrière l’opacité du nuage. D’où le fait que l’on parle de cloud computing – ou d’infonuagique comme disent les Québecois.

Le symbole du nuage est celui qui symbolise Internet.

Caractéristiques du cloud computing

Le « cloud » c’est des services:

  • En ligne → la connexion Internet est indispensable
  • Automatisés → accessibles et ajustables à la demande
  • Mesurables → on ne paie que ce qu’on consomme
  • Mutualisés → en déléguant et mutualisant les ressources on économise
  • Elastiques → la taille des ressources est adaptable en fonction des besoins

(d’où les noms de Amazon ECS… )

Avantages et inconvénients

Une des origines du cloud computing est sa souplesse, son « élasticité ». C’est par exemple, c’est la vente des billets du Paléo festival qui vent tout ses billets le même jour. Il y a ainsi 200 000 visiteurs le même jour à la même heure et très peu de visite sur le site web hors festival.

Ainsi une machine virtuelle mutualisée a tout son sens pour éviter de surdimensionner les ressources inutilement à l’année.

Avantages

  • En ligne → accessible de partout avec du matériel standard
  • Automatisés → accessibles et ajustables à la demande
  • Mesurables → on ne paie que ce que l’on consomme
  • Elastiques → la taille des ressources est adaptable en fonction des besoins
  • Mutualisés → en déléguant et mutualisant les ressources on économise
  • Simple → masque la complexité. Accessible à tous. Mises à jour automatisées.

  • Géographie → data center le plus proche de l’utilisateur

Inconvénients

  • En ligne → la connexion Internet est indispensable (rapide et fiable)

  • Sécurité → On se rappelle Snowden et PRISM….
  • Droit applicable → Quelle législation s’applique ?
  • Dépendance → On devient dépendant d’un prestataire, perte de savoir faire.
  • Interopérabilité faible → Surtout pour le Paas si on utilise des fonctions.
  • Sauvegarde → où sont mes données !?! Puis-je avoir une copie ?

Voici encore une page qui parle des problèmes juridiques du cloud, des problèmes d’espionnages, etc..

IaaS, PaaS, SaaS

  • Infrastructure as a Service
  • Plateforme as a Service
  • Software as a Services

Infrastructure as a service

Je délègue le matériel, mais m’occupe de l’OS et des app.

Plateforme as a services

J’ai accès à des outils, des API, des services, un environnement de programmation qui est fourni. C’est par exemple le cas si je veux utiliser un outils spécial comme la reconnaissance de caractères (OCR) de google.

Ou encore le cloud quantique de Microsoft…

Software as a services

J’ai accès à une application directement.

Voici quelques exemples plus ou moins triés en fonction des types:

Types de cloud

  • Cloud public
  • cloud privé
  • (hybride)

En plus du type, le cloud peut être hébergé, sur l’ordinateur de quelqu’un d’autre ou sur le sien. Ce qui se dit « sur site » ou « on premises » dans le jargon.

Un cloud tourne souvent sur une machine virtuelle. Nous allons voir de quoi il s’agit.

Machine Virtuelle

En informatique, une machine virtuelle (anglais virtual machine, abr. VM) est une virtualisation ou émulation d’un appareil informatique créée par un logiciel d’émulation ou instanciée sur un hyperviseur.

Le logiciel d’émulation simule la présence de ressources matérielles et logicielles telles que la mémoire, le processeur, le disque dur, voire le système d’exploitation et les pilotes, permettant d’exécuter des programmes dans les mêmes conditions que celles de la machine simulée.

Il est temps de bien distinguer l’émulation de la virtualisation.

Emulation

L’émulation est le fait de « simuler » sur une machine le comportement d’une autre machine. C’est le plus lent. Tout doit être émulé, notamment et surtout le processeur et ses instructions.

Par exemple, les mac avec un processeur Apple Silicon, de la famille ARM n’ont pas les mêmes instructions qu’un processeur Intel x86, largement utilisé pour la plupart de PC. (et un temps sur les mac)

On utilise des émulateurs notamment pour jouer à des anciens jeux vidéos. C’est ce que l’on développe dans le module 126 avec Retropie qui tourne sur Raspeberry Pi.

Historiquement, dans les années 1970, pour utiliser des gros ordinateurs on se connectait dessus via un appareil « Terminal ». Soit un clavier et un écran en réseau. De nos jours on utilise un émulateur de terminal, soit une application qui fait pareil qu’un terminal.

(voir l’histoire de l’informatique dans le module 286 et celle des telex-terminaux dans le module 146)

Virtualisation

La virtualisation permet également de « simuler » une machine sur une autre machine. En revanche, le processeur est – généralement – le même. Par exemple, on virtualise des machines Windows et Linux sur des processeurs Intel x86.

Capture d’écran de l’émulateur UTM qui précise bien la différence entre émuler et virtualiser.

Hyperviseur

Un hyperviseur est une plate-forme de virtualisation qui permet à plusieurs systèmes d’exploitation de fonctionner en parallèle dans une seule machine physique.

Il existe deux types principaux d’hyperviseurs:

  • type 1 : natif → Bare metal
  • type 2 : hosted → sur un OS

Hyperviseur de type 1 – Natif

Un hyperviseur de type 1 est dit natif ou bare metal (métal nu) car il s’exécute directement sur le matériel. Il n’a pas besoin de système d’exploitation (OS).

Le système d’exploitation invité peut être (mais pas obligé d’être) conscient d’être virtualisé. Il s’agit donc d’une version particulière. On parle alors de para-virtualisation. (Par exemple on donne l’accès à la carte réseau matérielle plutôt que de simuler une carte réseau)

Ce type d’hyperviseur a été développé par IBM dans les années 1960 pour migrer des logiciels de machines à d’autres machines sur des OS différents.

Finalement l’hyperviseur CP et son environnement VM/370 (sorti en 1972) sont devenus très populaires en dehors des migrations pour l’avantage de faire tourner plusieurs machines avec des OS différents sur le même matériel sans se gêner.

Il faut rappeler qu’à cette époque on avait un seul ordinateur par université.

IBM 360 de 1965

De nos jours, le monde du cloud computing utilise largement des solutions d’hyperviseurs natifs open source et libres:

Hyperviseur de type 2 – Hosted

Un hyperviseur de type 2 est dit Hosted, car il s’exécute à l’intérieur d’un autre système d’exploitation hôte. (OS)

L’avantage est que l’OS invité n’est pas conscient de la virtualisation et peut être une version tout à fait standard de l’OS non adaptée à l’hyperviseur.

L’inconvénient est une couche d’abstraction de plus qui ralenti, notamment par l’émulation des anneaux de protection du microprocesseur.

Les hyperviseurs de type 2 sont ceux que l’on utilise plus volontiers dans le monde des stations de travail et serveurs d’entreprises.

Voici quelques exemples:

VPS – Virtual Private Serveur

On peut louer des Serveurs dédiés virtuels chez des hébergeurs.
(différence entre le Housing et le VPS )

VPS infomaniak…

Virtualisation par conteneur

« A virtual machine is an operating system that thinks it’s running on its own computer. A container on the other hand is an application that thinks it’s an operating system. »
– David Clinton

La virtualisation par conteneur est une sorte de virtualisation plus légère, car elle n’inclus pas le système d’exploitation.

Dans le jargon on parle volontiers d’isolateur. (par opposition à l’hyperviseur)

Voici plusieurs type d’isolateurs / conteneurs:

  • LXC → Linux Containers → Intégré par défaut dans le noyau
  • Docker → étend le principe de LXC avec une interface de haut niveau et multiplateforme
  • et d’autres…

Docker a pris beaucoup d’importance ces dernières années. Il est très utile pour embarquer une application et son environnement dans un container standard qui peut être déployé chez quasi n’importe quel fournisseur de cloud.

Son nom vient de l’idée de la standardisation des conteurs pour les bateaux. Le transporteur ne se préoccupe que de gérer des conteneurs standards, et moi je fais ce que je veux à l’intérieur.

Concepts clés

Docker est une plateforme open-source qui permet de créer, déployer et exécuter des applications dans des conteneurs.

Les concepts de base à comprendre:

  • Image → paquet à télécharger qui contient une app
  • Container → application en cours d’exécution
  • Dockerfile → fichier de description pour la création d’une image

Image Docker

Elle contient tout ce qu’une application a besoin. (code, bibliothèque, dépendances, configuration, environnement.)

Une image est figée, immutable, elle ne change pas. Une image sert à créer un container.

C’est par exemple l’image de base des distributions linux ubuntu ou alpine ou encore une base de données mysql ou le serveur web nginx ou l’application web CMS wordpress.

Container Docker

Un container est une instance en cours d’exécution d’une image Docker. Les containers se partagent le noyaux du système d’exploitation de l’hôte tout en étant isolés.

Un container à un cycle de vie. Il peut être créé, arrêté, supprimé.
Un container évolue. Il est modifiable, des fichiers changent, des données s’ajoutent. (et sont détruites lors de la suppression du container )

Dockerfile

Le dockerfile est un fichier de configuration et création d’une image Docker. Ce fichier décrit la recette de cuisine de construction d’une image (dépendances, fichiers à copier, commande à exécuter, etc).

Une image Docker peut être composée de plusieurs autres images. On peut ainsi construire des images d’environnements complexes à partir de briques de bases simples.

Cette construction d’image se fait en couche (layers) qui correspondent à des instructions. (RUN, COPY, ADD). Ces couches sont mise en mémoire cache pour éviter de les reconstruire à chaque fois.

Voici un exemple de Dockerfile simple pour une application Node.js :

# Utilise une image de base qui contient Node.js
FROM node:20-alpine

# Défini le dossier de travail dans le conteneur
WORKDIR /app

# Copie package.json et package-lock.json
COPY package*.json ./


# Installe les dépendances de l'application
RUN npm install --production

# Copie le reste des fichiers de l'application
COPY src ./src


# Expose le port sur lequel l'application est conçue pour écouter
EXPOSE 3000

# Défini la commande pour démarrer l'application
CMD ["node", "src/index.js"]

Ce Dockerfile de base permet de conteneuriser une application Node.js simple. Il suit les bonnes pratiques en copiant d’abord les fichiers de dépendances et en les installant avant de copier le reste du code source, ce qui permet d’optimiser la mise en cache des couches Docker.

Volumes

Un container a un cycle de vie. Si un container est détruit, toutes les données qu’il contient sont également détruite.

Afin de persister les données, Docker permet de monter des volumes, soit une une partie du système de fichier du système hôte. Il est ainsi possible de partager des données entre plusieurs containers.

Utiliser Docker

Docker existe en version serveur chez son hébergeur. Mais il est aussi possible de l’installer en local sur sa machine, par exemple pour faire du développement d’application. C’est un processus très courant. Ainsi je peux développer dans le même environnement que l’application sera utilisée en production.

Le processus standard c’est:

  • Installer Docker sur sa machine en local. (Docker Desktop)
  • Créer un ficher de configuration Dockerfile pour décrire son application.
  • Construire une image à partir de la description du Dockerfile.
  • Exécuter un container basé sur cette image.

Si l’on n’est pas développeur d’application, mais juste un utilisateur d’une application, on peut sauter l’étape de la construction d’une image Docker.

Il est possible d’obtenir des images docker déjà toutes faites par la vaste communauté.

Le Docker Hub contient 14 millions d’images Docker déjà prête à l’emploi. Il y a l’embarras du choix.

https://hub.docker.com

Dans les images les plus populaires on peut voir le serveur web nginx, et la distribution de linux Alpine qui a la particularité d’être très légère et donc aussi très sécurisée. (8Mo à télécharger et ~130Mo déployée)

Ainsi Alpine est souvent la base d’une application qui tourne sur un système Linux. Mais juste après vient la très populaire distribution Linux Ubuntu.

Documentation

Réseau virtuel

Quand on exploite des machines virtuelles, il est intéressant de pouvoir aussi virtualiser les équipements réseaux qui relient les machines. (Switch, routeur, firewall, loadbalancer etc…)

Ainsi on peut trouver un logiciel de switch virtuel, comme par exemple Open vSwitch.

Le switch n’étant pas le seul élément réseau, il peut être pratiques d’avoir à disposition un gestionnaire de réseau complet et pas juste des composants séparés.

Il y a plusieurs façons de faire suivant les logiciels utilisés.

VMware ESX

Dans le monde VMware ESX, l’architecture réseau repose sur plusieurs composants, dont notamment le vSwitch qui contient des ports virtuels et des uplink adapters qui font le lien entre un port virtuel et un port d’un switch physique.

Sur un serveur ESX, il est possible d’installer jusqu’à 248 vSwitches. Chacun des ces vSwitch peut avoir jusqu’à 4088 ports virtuels.

interface de création d’un Switch Virtuel dans ESXi VMware

(au passage attention à la communication multicast entre switch qu’il faut activer)

OpenStack : Neutron

Dans le domaine du cloud computing, la plateforme logicielle OpenStack est en train de prendre de l’ampleur. OpenStack permet de gérer tous les aspects d’un cloud sous forme modulaire.

Infomaniak utilise OpenStack pour la gestion de son cloud Public.

OpenStack peut gérer plusieurs hyperviseurs, plusieurs méthodes de stockage de données, et – ce qui nous intéresse ici – des composants réseaux.

Le composant réseau d’OpenStack se nomme Neutron.

Neutron permet de gérer du trafic IP, de créer des réseaux et des sous réseaux et d’assigner des adresses IP. Soit de façon statique, mais aussi de façon dynamique avec une instance d’un serveur DHCP.

Ces fonctions IP, comme le Switching L2, sont intégrés dans les plugin Core de Neutron. (il est également possible d’utiliser le plugin Open vSwitch mentionné plus haut de façon indépendante, ou d’autres comme ML2)

Neutron permet ensuite de voir de nombreux composants réseau avancés sous forme de services, donc xxx as a Service, dans la terminologie cloud:

Documentation

Fournisseurs de services cloud

Il existe de nombreuses solutions de nuages…. des connues et d’autres…

Infomaniak fait une liste de fournisseurs de services cloud en Suisse… … regardez qui est en tête 😉

Le centre de l’europe en terme de cloud computing est souvent Frankfort en Allemagne. Voici notamment les arguments de google pour s’implanter là…

Amazon Web Services

MS Azure

cours de Microsoft:

Exigence – Qualité – avantages et inconvénients

=> Le module 435 répond à pas mal de questions….

Cloud pour la téléphonie

Le module 361, parle des clouds possibles en téléphonie voip. Notamment des solutions SaaS:

Cloud pour les banques et grosses entreprise Suisse en Suisse

Google a officiellement lancé la région suisse de son cloud aujourd’hui 12 mars 2019 à Zurich. Sixième région ouverte en Europe « europe-west6 » et 19ème dans le monde, la région europe-west6 de la Google Cloud Platform (GCP) se dessine comme la plus importante d’Europe, selon les dires d’Urs Hölzle, vice-président Technical Infrastructure chez Google, de nationalité suisse et présent lors de l’inauguration.

Crédit Suisse parmi les premiers clients

Selon Urs Hölzle, le cloud suisse de Google suscite un intérêt élevé, notamment dans le secteur financier, cible suisse privilégiée de la firme (Google veut attirer des banques suisses dans son cloud). Pour rappel, Microsoft, qui a de son côté attiré UBS sur Azure, sera également bientôt en mesure d’offrir ses services cloud depuis la Suisse. Parmi ses autres clients helvétiques, Google cite Roche, Valora, Quickline, Ricardo, Swisscom, Migros et Ringier.

Journal ICT – 2019

Scroll to top