Aller au contenu

Cloud Computing

De Wiki Pat-Informatik
🏠 Accueil 📚 Index 🐧 Linux 🌐 Réseau 🔒 Cybersécurité 🖥️ Virtualisation ✅ Checklists d'intervention 📚 Tutoriels 🤝 Services


☁️ Cloud Computing
Comprendre l'informatique en nuage, les services cloud, la virtualisation, le stockage et les architectures modernes.
Guide pratique — Pat Informatik

Objectifs de cette page

  • Comprendre le fonctionnement du Cloud Computing.
  • Différencier IaaS, PaaS, SaaS et les principaux modèles de déploiement.
  • Découvrir les machines virtuelles, les conteneurs et le stockage cloud.
  • Comprendre les avantages, les limites et les coûts du cloud.
  • Sécuriser les données, les accès et les services hébergés.
  • Découvrir les solutions cloud publiques, privées et hybrides.
  • Identifier les cas où l'auto-hébergement peut être préférable.

1. Qu'est-ce que le Cloud Computing ?

Le Cloud Computing, ou informatique en nuage, désigne un modèle qui permet d'accéder à des ressources informatiques à travers un réseau, généralement Internet, sans devoir posséder ni administrer directement toute l'infrastructure physique utilisée.

Ces ressources peuvent comprendre :

  • des serveurs et des machines virtuelles ;
  • des processeurs et de la mémoire vive ;
  • des espaces de stockage ;
  • des bases de données ;
  • des réseaux virtuels ;
  • des logiciels accessibles depuis un navigateur ;
  • des outils de sauvegarde et de supervision ;
  • des services de développement et de déploiement.

Le fournisseur met les ressources à disposition selon un modèle de service. Selon l'offre choisie, il peut prendre en charge une partie plus ou moins importante de l'infrastructure et de son administration.

Exemple concret

Une entreprise souhaite héberger son site Web.

Elle peut acheter un serveur physique, l'installer dans ses locaux et assurer elle-même sa maintenance. Elle peut aussi louer une machine virtuelle chez un hébergeur cloud et y installer son serveur Web.

Dans le second cas, elle utilise une ressource informatique fournie à distance, sans devoir acheter elle-même le serveur physique sous-jacent.

Principe du Cloud Computing
💻 Ordinateur
📱 Smartphone
🏢 Entreprise
⬇ Réseau / Internet ⬇
☁️

Plateforme Cloud

Serveurs · Stockage · Réseau · Applications
⬇
🗄️ Données
🌐 Sites Web
🖥️ Serveurs

À retenir : le cloud ne signifie pas que les données sont stockées dans un espace immatériel. Elles résident sur des équipements physiques, généralement dans des centres de données, administrés par un fournisseur ou par l'organisation elle-même.

2. Comment fonctionne le cloud ?

Le cloud s'appuie sur une infrastructure matérielle et logicielle regroupée dans des centres de données.

Ces centres de données hébergent des serveurs, des équipements réseau, des systèmes de stockage, des alimentations électriques redondantes et des dispositifs de refroidissement.

Des logiciels d'administration permettent d'attribuer les ressources aux clients et de gérer leur utilisation.

Les principales briques

Élément Rôle
Serveurs physiques Fournissent la puissance de calcul, la mémoire et les interfaces réseau.
Virtualisation Permet d'exécuter plusieurs machines virtuelles sur un même serveur physique.
Conteneurs Isolent les applications et leurs dépendances dans des environnements légers.
Stockage Conserve les fichiers, les volumes, les sauvegardes et les données applicatives.
Réseau Assure les communications entre les ressources et vers les utilisateurs.
Orchestration Automatise la création, la configuration et la gestion des ressources.
Supervision Surveille la disponibilité, les performances et les événements.
Gestion des identités Contrôle les utilisateurs, les rôles et les autorisations.

Mise à disposition des ressources

Dans une plateforme cloud, l'administrateur peut généralement créer des ressources depuis une interface Web, une API ou une ligne de commande.

Selon le service, il peut par exemple :

  1. Créer une machine virtuelle.
  2. Choisir le processeur, la mémoire et le système de stockage.
  3. Configurer un réseau et les règles d'accès.
  4. Installer une application ou sélectionner une image préconfigurée.
  5. Surveiller l'utilisation et ajuster les ressources.

L'automatisation permet de répéter ces opérations et de limiter les erreurs de configuration manuelle.

3. Les principaux modèles de service

Les services cloud sont souvent classés en trois grandes catégories : IaaS, PaaS et SaaS. D'autres modèles existent, notamment les fonctions sans serveur, les services de bases de données managés et les plateformes de conteneurs.

IaaS : Infrastructure as a Service

Infrastructure as a Service signifie « infrastructure en tant que service ».

Le fournisseur met à disposition des ressources comme des machines virtuelles, des disques, des réseaux et des adresses IP.

Le client administre généralement le système d'exploitation invité, les logiciels installés, les comptes et une partie de la sécurité.

Exemple : louer une machine virtuelle Ubuntu, installer Apache, configurer un site Web et assurer les mises à jour du système.

PaaS : Platform as a Service

Platform as a Service signifie « plateforme en tant que service ».

Le fournisseur prend en charge une partie importante de l'infrastructure et de la plateforme d'exécution. Le client se concentre principalement sur son application et ses données.

Exemple : déployer une application Web sur une plateforme qui gère le système d'exécution, une partie du déploiement et la mise à l'échelle.

SaaS : Software as a Service

Software as a Service signifie « logiciel en tant que service ».

L'utilisateur utilise une application gérée par un fournisseur, souvent depuis un navigateur Web ou un client dédié.

Exemples : une messagerie hébergée, une suite bureautique en ligne ou un outil de gestion accessible sur Internet.

Comparaison des modèles

Modèle Ce que fournit le prestataire Ce que gère principalement le client Exemple d'usage
IaaS Infrastructure, virtualisation et ressources de base. Système invité, applications, données, comptes et configuration. Serveur Ubuntu hébergé.
PaaS Infrastructure et plateforme d'exécution managée. Code applicatif, données et paramètres propres à l'application. Déploiement d'une application Web.
SaaS Application complète et infrastructure sous-jacente. Utilisateurs, données, paramètres et accès selon le service. Messagerie en ligne.

La répartition exacte des responsabilités dépend du contrat et du service. Il faut vérifier la documentation du fournisseur plutôt que supposer que tous les services d'une catégorie fonctionnent de manière identique.

4. Les modèles de déploiement

Cloud public

Le cloud public est proposé par un fournisseur qui met ses ressources à disposition de plusieurs clients.

Les infrastructures peuvent être partagées, mais les ressources et les accès des clients doivent être isolés selon l'architecture du service.

Avantages :

  • Mise en service rapide.
  • Large choix de services.
  • Possibilité d'augmenter ou de réduire les ressources.
  • Pas besoin d'acheter tous les serveurs physiques.

Limites :

  • Coûts récurrents et parfois difficiles à prévoir.
  • Dépendance au fournisseur et à sa disponibilité.
  • Nécessité de maîtriser les accès, la localisation des données et les contrats.
  • Risque de frais supplémentaires liés au trafic sortant ou aux services annexes.

Cloud privé

Le cloud privé est une infrastructure réservée à une organisation. Il peut être hébergé dans ses locaux ou chez un prestataire.

Il peut utiliser la virtualisation, l'automatisation, le libre-service et la supervision pour fournir des ressources aux équipes internes.

Avantages :

  • Contrôle plus important sur l'architecture.
  • Possibilité d'adapter l'environnement aux contraintes internes.
  • Maîtrise de nombreux paramètres techniques.

Limites :

  • Investissement matériel et logiciel.
  • Besoin de compétences pour l'administration.
  • Maintenance, alimentation, refroidissement et renouvellement à assurer.
  • Responsabilité de la continuité de service.

Un serveur installé chez soi n'est pas automatiquement un cloud privé. Il faut aussi considérer la manière dont les ressources sont fournies, administrées et mises à disposition.

Cloud hybride

Le cloud hybride associe une infrastructure privée et des services cloud publics, avec des mécanismes permettant de les faire fonctionner ensemble.

Exemple : conserver une base de données sensible dans une infrastructure privée tout en hébergeant le site public dans le cloud.

La mise en œuvre demande une bonne maîtrise des identités, des réseaux, des transferts de données, de la supervision et des responsabilités de sécurité.

Multi-cloud

Le multi-cloud consiste à utiliser des services provenant de plusieurs fournisseurs cloud.

Cela peut permettre de sélectionner les services les mieux adaptés à différents besoins, mais ajoute de la complexité : outils multiples, compétences spécifiques, gestion des identités et coûts répartis entre plusieurs plateformes.

Modèle Où se trouvent les ressources ? Usage courant
Cloud public Infrastructure d'un fournisseur. Applications évolutives et services managés.
Cloud privé Infrastructure dédiée à une organisation. Besoins de contrôle et d'administration spécifiques.
Cloud hybride Combinaison d'environnements privés et publics. Répartition des charges entre plusieurs environnements.
Multi-cloud Plusieurs fournisseurs cloud. Utilisation de services complémentaires.

5. Virtualisation et machines virtuelles

La virtualisation permet de créer plusieurs environnements informatiques indépendants sur un même serveur physique.

Un hyperviseur gère les ressources matérielles et les machines virtuelles.

Chaque machine virtuelle dispose de ressources virtuelles, telles qu'un processeur, de la mémoire, des disques et des interfaces réseau. Elle peut exécuter son propre système d'exploitation.

Exemple d'architecture

🖥️ Serveur physique
⬇
Hyperviseur
VM 1
Ubuntu
Serveur Web
VM 2
Windows Server
AD DS
VM 3
Linux
Base de données

Les hyperviseurs

Un hyperviseur de type 1 s'exécute directement sur le matériel, selon l'architecture de la solution.

Un hyperviseur de type 2 fonctionne comme une application au-dessus d'un système d'exploitation hôte.

Solution Description Utilisation typique
VMware ESXi Hyperviseur destiné à la virtualisation de serveurs. Infrastructure de virtualisation.
Proxmox VE Plateforme intégrant la gestion de machines virtuelles et de conteneurs. Serveur de virtualisation.
Hyper-V Technologie de virtualisation Microsoft. Environnements Windows et infrastructures compatibles.
VMware Workstation Virtualisation hébergée sur un système d'exploitation. Laboratoires, tests et formation.
KVM Technologie de virtualisation du noyau Linux. Serveurs Linux et plateformes de virtualisation.

La virtualisation est une technologie couramment utilisée dans le cloud, mais elle n'est pas à elle seule suffisante pour constituer un service cloud complet.

6. Conteneurs et Docker

Les conteneurs permettent d'exécuter des applications dans des environnements isolés, en partageant le noyau du système hôte lorsque l'architecture le permet.

Contrairement à une machine virtuelle classique, un conteneur ne nécessite généralement pas un système d'exploitation complet distinct avec son propre noyau.

Machine virtuelle ou conteneur ?

Caractéristique Machine virtuelle Conteneur
Système d'exploitation Système invité complet. Partage généralement le noyau de l'hôte.
Isolation Fournie notamment par l'hyperviseur et le système invité. Fournie par les mécanismes d'isolation du système et le runtime.
Démarrage Généralement plus long. Généralement plus rapide.
Portabilité Dépend du format de la VM et de l'hyperviseur. Dépend de l'image, de l'architecture et de l'environnement d'exécution.
Usage fréquent Serveurs complets, systèmes distincts, environnements de test. Services applicatifs, API et déploiements reproductibles.

Docker

Docker est un ensemble d'outils permettant de construire, distribuer et exécuter des conteneurs.

Exemple de commande :

docker ps

Affiche les conteneurs en cours d'exécution.

docker images

Affiche les images présentes localement.

docker logs nom_du_conteneur

Affiche les journaux d'un conteneur identifié.

Attention : un conteneur n'est pas une sauvegarde. Les données persistantes doivent être gérées et sauvegardées séparément, par exemple au moyen de volumes et de procédures de sauvegarde adaptées.

Liens internes possibles : Docker, Podman, Proxmox et Virtualisation.

7. Le stockage dans le cloud

Le stockage cloud permet de conserver des données sur une infrastructure accessible par le réseau.

Il existe plusieurs catégories de stockage, adaptées à des besoins différents.

Stockage objet

Le stockage objet conserve des données sous forme d'objets accompagnés de métadonnées et d'un identifiant.

Il est adapté à des usages tels que :

  • les images et les documents ;
  • les fichiers statiques de sites Web ;
  • les archives ;
  • les sauvegardes ;
  • les grands volumes de données.

Des interfaces compatibles avec des API de stockage objet sont couramment utilisées pour automatiser les transferts.

Stockage bloc

Le stockage bloc fournit des volumes qui peuvent être présentés à une machine virtuelle ou à un serveur.

Il est souvent utilisé pour :

  • les disques système des machines virtuelles ;
  • les bases de données ;
  • les volumes de données applicatives.

Stockage fichier

Le stockage fichier organise les données sous forme de fichiers et de répertoires accessibles par des protocoles adaptés, par exemple NFS ou SMB.

Il convient au partage de fichiers entre utilisateurs, serveurs et applications.

Type Organisation Exemple d'utilisation
Stockage objet Objets et métadonnées. Archives, documents et sauvegardes.
Stockage bloc Volumes de blocs. Disque d'une machine virtuelle.
Stockage fichier Fichiers et répertoires. Dossiers partagés.

Points de vigilance

  • Vérifier la capacité disponible.
  • Mesurer les performances et la latence.
  • Contrôler les frais de stockage et de transfert.
  • Définir les droits d'accès.
  • Chiffrer les données lorsque cela est nécessaire.
  • Vérifier les politiques de rétention et de suppression.
  • Tester la restauration des données.

8. Sauvegarde et reprise après incident

Le stockage cloud peut être utilisé pour conserver des sauvegardes à distance, mais un espace de stockage synchronisé ne remplace pas automatiquement une véritable stratégie de sauvegarde.

Une suppression, une erreur de manipulation ou une attaque par rançongiciel peut se propager à certains systèmes synchronisés.

Principes d'une bonne sauvegarde

Une stratégie de sauvegarde doit définir :

  • les données à protéger ;
  • la fréquence des sauvegardes ;
  • la durée de conservation ;
  • les emplacements de stockage ;
  • les personnes autorisées à restaurer ;
  • les objectifs de reprise ;
  • les procédures de test.

La règle dite 3-2-1 recommande généralement de conserver trois copies des données, sur deux types de supports, dont une copie hors site. Des variantes ajoutent une copie hors ligne ou immuable.

RPO et RTO

RPO — Recovery Point Objective

Quantité maximale de données que l'organisation accepte de perdre, exprimée en durée.

Exemple : un RPO de quatre heures signifie que l'objectif est de pouvoir restaurer un état datant de moins de quatre heures avant l'incident.

RTO — Recovery Time Objective

Durée cible maximale pour rétablir un service après une interruption.

Exemple : un RTO de deux heures signifie que le service doit viser un rétablissement dans les deux heures suivant l'incident.

Ces objectifs doivent être définis en fonction des besoins métier et validés par des tests réels.

Checklist de sauvegarde cloud

  • [ ] Identifier les données et services critiques.
  • [ ] Définir les RPO et RTO.
  • [ ] Automatiser les sauvegardes.
  • [ ] Protéger les accès aux sauvegardes.
  • [ ] Conserver une copie indépendante de l'environnement principal.
  • [ ] Prévoir une protection contre les suppressions malveillantes.
  • [ ] Surveiller les échecs de sauvegarde.
  • [ ] Tester régulièrement la restauration.
  • [ ] Documenter la procédure de reprise.

9. Sécurité du Cloud Computing

La sécurité cloud repose sur une combinaison de mesures techniques, organisationnelles et contractuelles.

Le fait qu'une ressource soit hébergée chez un fournisseur ne signifie pas que toutes les tâches de sécurité sont prises en charge par celui-ci.

Le modèle de responsabilité partagée

Selon le service utilisé, le fournisseur et le client se partagent les responsabilités.

Le fournisseur prend généralement en charge une partie de la sécurité physique et de l'infrastructure. Le client reste souvent responsable de ses comptes, de ses données, de ses droits d'accès et de la configuration de ses ressources.

La répartition exacte dépend du modèle IaaS, PaaS ou SaaS et du contrat applicable.

Les principales mesures

Checklist de sécurité cloud

  • [ ] Activer l'authentification multifacteur pour les comptes sensibles.
  • [ ] Utiliser le principe du moindre privilège.
  • [ ] Supprimer les comptes et les clés inutilisés.
  • [ ] Éviter les identifiants et secrets dans le code source.
  • [ ] Chiffrer les communications.
  • [ ] Contrôler les règles réseau et les ports exposés.
  • [ ] Mettre à jour les systèmes et les applications.
  • [ ] Journaliser les opérations importantes.
  • [ ] Surveiller les coûts et les ressources anormales.
  • [ ] Vérifier la configuration des stockages et des sauvegardes.
  • [ ] Tester la restauration et les procédures d'incident.

Gestion des identités et des accès

Les droits doivent être attribués selon les besoins réels de chaque utilisateur ou service.

Il est préférable d'utiliser des rôles distincts pour l'administration, l'exploitation et la consultation plutôt qu'un compte administrateur partagé.

Les comptes d'urgence doivent être protégés et les procédures d'accès d'urgence documentées.

Chiffrement

Le chiffrement en transit protège les communications, par exemple avec TLS.

Le chiffrement au repos protège les données stockées, selon les mécanismes utilisés. Il faut aussi protéger les clés de chiffrement et limiter les personnes autorisées à les utiliser.

Le chiffrement ne remplace pas les contrôles d'accès ni les sauvegardes.

Surveillance et journaux

La supervision doit permettre de repérer notamment :

  • les connexions inhabituelles ;
  • les changements de droits ;
  • les ressources créées sans autorisation ;
  • les services exposés accidentellement ;
  • les pics de consommation ;
  • les échecs de sauvegarde ;
  • les erreurs répétées d'authentification.

10. Disponibilité et résilience

Un service cloud peut subir une panne, même lorsque le fournisseur dispose d'une infrastructure importante.

La disponibilité dépend de nombreux éléments : calcul, réseau, stockage, configuration, dépendances logicielles et services externes.

Redondance

La redondance consiste à disposer de plusieurs composants ou chemins capables de prendre le relais en cas de défaillance.

Exemples :

  • plusieurs instances d'une application ;
  • plusieurs chemins réseau ;
  • réplication des données ;
  • stockage redondant ;
  • répartition de charge ;
  • sauvegardes indépendantes.

Important : la réplication améliore parfois la disponibilité, mais elle peut aussi reproduire une suppression ou une corruption. Elle ne remplace donc pas une sauvegarde indépendante.

Répartition de charge

Un répartiteur de charge distribue les requêtes entre plusieurs instances selon une politique définie.

Cette architecture peut améliorer les performances et la résilience, mais elle nécessite une conception adaptée, des contrôles de santé et une gestion correcte des sessions et des données.

Plan de reprise

Un plan de reprise doit préciser :

  1. Les services à rétablir en priorité.
  2. Les personnes responsables.
  3. Les accès nécessaires.
  4. Les données et sauvegardes disponibles.
  5. L'ordre de restauration des dépendances.
  6. Les tests à effectuer avant de déclarer le service opérationnel.

11. Les coûts du cloud

Le cloud peut réduire certains investissements initiaux, mais il ne garantit pas un coût inférieur à celui d'une infrastructure locale.

La facturation peut dépendre de plusieurs éléments.

Élément Exemples
Calcul Temps d'utilisation des machines virtuelles et des processeurs.
Mémoire Capacité et durée d'utilisation selon le service.
Stockage Volume utilisé, type de stockage et opérations effectuées.
Réseau Transferts de données, trafic sortant et connexions entre régions selon l'offre.
Services managés Bases de données, supervision, sauvegarde et autres services.
Licences Systèmes d'exploitation et logiciels soumis à licence.
Support Contrats d'assistance et niveaux de service.

Comment maîtriser les coûts ?

  • Définir un budget et des alertes.
  • Supprimer les ressources inutilisées.
  • Arrêter les environnements de test lorsqu'ils ne sont plus nécessaires.
  • Dimensionner les machines selon les besoins réels.
  • Contrôler les volumes et les adresses réservées.
  • Examiner les frais de transfert de données.
  • Vérifier régulièrement les factures et les métriques.

Ne pas supprimer une ressource uniquement parce qu'elle semble inutilisée : vérifier d'abord qu'elle ne sert pas à une sauvegarde, à une reprise ou à une dépendance applicative.

12. Cloud public ou serveur auto-hébergé ?

Pour une activité informatique, il est utile de comparer le cloud public à un serveur administré directement, par exemple un serveur Ubuntu hébergeant Apache, une messagerie ou d'autres applications.

Critère Cloud public Serveur auto-hébergé
Investissement initial Souvent plus faible pour démarrer. Achat du matériel et des équipements nécessaires.
Évolution des ressources Souvent rapide, selon le service. Dépend du matériel et de la capacité disponible.
Administration Variable selon le service acheté. L'administrateur gère l'infrastructure et les services.
Contrôle matériel Généralement limité. Plus important.
Maintenance physique Principalement prise en charge par le fournisseur. À assurer localement.
Dépendance réseau Accès distant dépendant de la connectivité. Les services locaux peuvent rester accessibles sur le LAN même si Internet est indisponible.
Sauvegarde À configurer et à vérifier selon l'offre. À mettre en place et à maintenir.
Coûts à long terme Dépendent de l'utilisation et des services choisis. Dépendent du matériel, de l'énergie, du renouvellement et du temps d'administration.

Quel modèle choisir ?

Le cloud public est intéressant lorsque l'on souhaite déployer rapidement des services, adapter les ressources ou utiliser des services managés.

L'auto-hébergement peut être adapté à un laboratoire, à un environnement de formation, à certains services internes ou à des besoins de contrôle spécifique.

Une architecture hybride peut aussi être pertinente : garder certains services localement et externaliser les services qui bénéficient le plus du cloud.

La décision doit tenir compte du coût total, de la disponibilité attendue, de la sécurité, des compétences disponibles et des contraintes contractuelles.

13. Exemples de plateformes et de solutions cloud

Les exemples ci-dessous représentent différentes familles de solutions. Ils ne sont pas tous équivalents et ne répondent pas aux mêmes besoins.

Solution Catégorie Usage possible
Amazon Web Services (AWS) Fournisseur cloud public Calcul, stockage, réseau et services managés.
Microsoft Azure Fournisseur cloud public Infrastructure, services applicatifs et intégration avec des environnements Microsoft.
Google Cloud Fournisseur cloud public Calcul, stockage, données et services applicatifs.
OpenStack Plateforme de cloud privé Construction et administration d'une infrastructure cloud.
Proxmox VE Plateforme de virtualisation Gestion de machines virtuelles et de conteneurs dans une infrastructure privée.
Nextcloud Plateforme collaborative auto-hébergée ou hébergée Partage de fichiers, calendriers et collaboration selon les applications installées.
Docker Technologie de conteneurs Construction et exécution d'applications conteneurisées.
Kubernetes Orchestrateur de conteneurs Déploiement et gestion d'applications conteneurisées à grande échelle.

Attention : Proxmox VE, Docker et Kubernetes ne sont pas des fournisseurs cloud publics. Ce sont des technologies qui peuvent participer à la construction et à l'exploitation d'une infrastructure ou d'une plateforme.

14. Mettre en place un petit environnement cloud privé

Il est possible de créer un laboratoire informatique pour comprendre les principes du cloud sans commencer par un grand déploiement.

Exemple d'architecture

🖥️ Serveur physique Ubuntu ou compatible
⬇
Virtualisation : KVM / Proxmox VE
VM Web
Apache
VM Services
Applications
Conteneurs
Docker
Sauvegardes séparées · Pare-feu · Supervision

Étapes du projet

  1. Définir les besoins et les services à héberger.
  2. Vérifier les capacités du serveur : processeur, mémoire, stockage et réseau.
  3. Installer et mettre à jour la plateforme de virtualisation choisie.
  4. Créer un réseau de gestion et un réseau pour les services.
  5. Déployer une machine virtuelle de test.
  6. Installer une application, par exemple Apache.
  7. Configurer les règles de pare-feu et les comptes.
  8. Mettre en place les sauvegardes.
  9. Tester la restauration d'une machine virtuelle.
  10. Documenter les adresses IP, les accès et les procédures.

Exemple de commandes Linux

Afficher l'espace disque :

df -h

Afficher l'utilisation de la mémoire :

free -h

Afficher les interfaces réseau :

ip addr

Afficher les routes :

ip route

Afficher les informations système :

hostnamectl

Ces commandes fournissent des informations utiles pour préparer et surveiller un serveur Linux. Elles ne créent pas à elles seules une infrastructure cloud.

Points de sécurité pour le laboratoire

  • Ne pas exposer l'interface d'administration directement sur Internet.
  • Limiter l'accès SSH aux utilisateurs autorisés.
  • Maintenir les systèmes à jour.
  • Séparer les réseaux de gestion et les services lorsque c'est possible.
  • Prévoir une sauvegarde indépendante.
  • Tester les restaurations avant d'héberger des données importantes.
  • Documenter les ports, les adresses et les règles de filtrage.

15. Migration d'une application vers le cloud

Déplacer une application vers le cloud demande une préparation. Une migration ne consiste pas uniquement à copier des fichiers vers un serveur distant.

Étapes recommandées

1. Inventorier l'existant

Identifier les applications, les bases de données, les dépendances, les comptes, les ports et les besoins de stockage.

2. Définir les objectifs

Déterminer les performances attendues, la disponibilité, le budget, les contraintes de sécurité et la localisation souhaitée des données.

3. Choisir le modèle de service

Déterminer si l'application doit fonctionner sur une machine virtuelle, une plateforme managée ou un service SaaS.

4. Préparer le réseau et les accès

Définir les adresses, le DNS, les règles de pare-feu, les accès d'administration et les connexions entre services.

5. Préparer les données

Organiser le transfert, vérifier l'intégrité et définir la méthode de synchronisation si l'application continue de fonctionner pendant la migration.

6. Tester

Vérifier les fonctionnalités, les performances, la sécurité et les sauvegardes dans le nouvel environnement.

7. Basculer le service

Planifier la bascule, réduire les interruptions et conserver une procédure de retour arrière si cela est possible.

8. Surveiller

Contrôler les journaux, les erreurs, les coûts et les performances après la mise en production.

16. Erreurs à éviter

  • Croire que le cloud est automatiquement moins cher qu'un serveur local.
  • Supposer que le fournisseur prend en charge toute la sécurité.
  • Laisser des services d'administration accessibles à tous sur Internet.
  • Oublier les frais de transfert de données et de stockage.
  • Utiliser un compte administrateur pour toutes les opérations.
  • Négliger les mises à jour des machines virtuelles.
  • Confondre réplication et sauvegarde.
  • Ne jamais tester une restauration.
  • Conserver des clés d'accès dans un dépôt de code public.
  • Créer des ressources sans procédure de suivi ni contrôle des coûts.
  • Déployer une application sans plan de reprise.
  • Considérer une machine virtuelle ou un conteneur comme une protection suffisante contre tous les incidents.

17. Glossaire complémentaire

API
Interface permettant à des logiciels de communiquer et de demander des opérations à un service.
Cloud privé
Environnement cloud dédié à une organisation.
Cloud public
Services cloud proposés par un fournisseur à plusieurs clients.
Conteneur
Environnement isolé destiné à exécuter une application en partageant généralement le noyau du système hôte.
Centre de données
Installation hébergeant des serveurs, du stockage, des réseaux et les équipements nécessaires à leur fonctionnement.
Haute disponibilité
Architecture destinée à limiter les interruptions de service.
Hyperviseur
Logiciel ou couche système qui permet de créer et d'exécuter des machines virtuelles.
IaaS
Infrastructure as a Service, ou infrastructure en tant que service.
IAM
Gestion des identités et des accès, notamment des utilisateurs, rôles et autorisations.
PaaS
Platform as a Service, ou plateforme en tant que service.
RPO
Objectif de point de reprise : quantité de données que l'on accepte de perdre, exprimée en durée.
RTO
Objectif de délai de reprise après incident.
SaaS
Software as a Service, ou logiciel en tant que service.
Scalabilité
Capacité d'une solution à s'adapter à une augmentation ou à une diminution de la charge.
Stockage objet
Stockage de données sous forme d'objets et de métadonnées.
Virtualisation
Technique permettant de créer plusieurs environnements informatiques virtuels à partir de ressources physiques.

18. Ressources et documentation

19. Pages connexes de Wiki Pat-Informatik

Conclusion

Le Cloud Computing permet de consommer des ressources informatiques à la demande et de choisir le niveau de gestion souhaité, depuis une infrastructure virtuelle jusqu'à une application complète.

Sa réussite repose sur une architecture adaptée, une maîtrise des coûts, une gestion rigoureuse des accès, des sauvegardes fiables et une bonne compréhension des responsabilités entre le fournisseur et le client.

Le cloud n'élimine pas les contraintes informatiques : il change la manière de les gérer.