Google Cloud Platform pour les utilisateurs d'OpenStack

Cet article est conçu pour familiariser les utilisateurs qui connaissent OpenStack avec les principaux concepts utiles pour démarrer avec Google Cloud Platform (GCP), qu'il s'agisse de migrer ou de mettre en œuvre un déploiement hybride.

Présentation

Cet article compare d'abord des exemples d'architectures d'applications Web à trois niveaux qui sont mis en œuvre dans OpenStack et GCP, puis les fonctionnalités d'OpenStack et de GCP. Il présente des tableaux récapitulatifs mettant en correspondance les termes et concepts relatifs à OpenStack et ceux propres à GCP.

Cet article ne compare pas les SDK, les API ni les outils de ligne de commande fournis par OpenStack et GCP.

Pour obtenir la liste complète des produits Google Cloud Platform, consultez l'article Produits et services.

Services de cloud computing

Les services de cloud computing fournissent un ensemble de prestations de base pour le calcul, le stockage, la mise en réseau, la gestion des accès et généralement les bases de données.

Les services de base d'OpenStack incluent les suivants :

  • Pour le calcul, OpenStack Compute (Nova et Glance)
  • Pour le stockage, OpenStack Block Storage (Cinder)
  • Pour la mise en réseau, OpenStack Networking (Neutron)
  • Pour la gestion des identités et des accès, OpenStack Identity (Keystone)

Les services de base de Cloud Platform incluent les suivants :

Tarifs applicables à Google Cloud Platform

La plupart des services GCP sont proposés sur la base d'un modèle de paiement à l'usage, qui inclut une facturation à la seconde ou à la minute ainsi que des remises automatiques en cas d'utilisation intensive. Combiné à un mécanisme flexible d'attribution des ressources qui s'appuie, entre autres, sur les types de machines personnalisés, le modèle de tarification GCP permet d'optimiser les performances économiques de vos applications.

Pour accéder à des informations et des outils permettant d'estimer rapidement les prix, consultez la section relative aux simulateurs de coûts.

Pourquoi choisir Google Cloud Platform ?

Depuis 15 ans, nous proposons l'une des meilleures infrastructures cloud au monde en termes de rapidité, de puissance et de qualité. Nous utilisons cette infrastructure en interne pour proposer à l'échelle mondiale des services à trafic élevé, tels que Gmail, Maps, YouTube, et la recherche Google. GCP met cette infrastructure à votre disposition.

Comparer des exemples d'architectures

Cette section compare les méthodes permettant de créer une application Web à trois niveaux dans OpenStack et dans GCP.

  • L'architecture OpenStack génère une configuration en mode "actif/sauvegarde".
  • L'architecture GCP exploite les services gérés pour fournir une configuration en mode "actif/actif".

Une application Web à trois niveaux standard inclut les éléments suivants :

  • Équilibreur de charge
  • Serveur Web
  • Serveur d'application
  • Serveur de base de données

OpenStack : configuration en mode "actif/sauvegarde"

L'exemple de configuration OpenStack illustré par la figure 1 présente les caractéristiques suivantes :

  • Vous déployez des ressources dans deux régions sous la forme de deux domaines de défaillance distincts pour la redondance.
  • Le réseau utilise un seul sous-réseau pour tous les niveaux de chaque région, et tous les serveurs correspondent à des instances de machine virtuelle (VM).
  • Vous définissez des groupes de sécurité pour les quatre rôles de serveur et les attribuez aux instances appropriées.
  • Un volume Cinder est associé au serveur de base de données en tant que volume de données. Pour assurer la redondance entre les domaines de défaillance, la base de données de la région active est sauvegardée dans un espace de stockage d'objets et restaurée sur la base de données de la région de sauvegarde si nécessaire. Cette architecture n'utilise pas la réplication de base de données en temps réel, car la bande passante est limitée entre les régions.
  • Cette architecture fournit une configuration en mode "actif/sauvegarde". Lorsque vous basculez le service vers une autre région, vous restaurez la sauvegarde la plus récente sur le serveur de base de données de la région de sauvegarde.

Application Web à trois niveaux

Figure 1 : Application Web à trois niveaux dans OpenStack

GCP : configuration en mode "actif/actif"

L'exemple de configuration GCP illustré par la figure 2 présente les caractéristiques suivantes :

  • Vous déployez des ressources dans un sous-réseau unique couvrant plusieurs zones d'une même région pour la redondance.
  • Vous déployez des serveurs Web et des serveurs d'applications en tant qu'instances de VM.
  • Vous définissez des règles de pare-feu à l'aide de tags pour spécifier la destination des paquets.
  • Vous définissez le contrôle des accès pour la connexion à la base de données en fonction de l'adresse IP source, dans le cadre de la configuration Cloud SQL. Ce dernier est un service géré de GCP pour les bases de données MySQL, qui permet la réplication de données entre plusieurs zones. Les processus de sauvegarde de données et de basculement sont automatisés, et vous pouvez accéder à la base de données à partir de plusieurs zones de la même région. Le basculement entre les zones est transparent pour les applications exécutées sur les instances de VM. Vous pouvez accéder à une instance Cloud SQL unique à partir de plusieurs zones. (Il existe deux générations Cloud SQL : Cloud SQL de première génération et Cloud SQL de deuxième génération. Leurs caractéristiques et comportements par défaut pour la réplication et le basculement sont différents.)
  • Google Cloud Load Balancing est un service d'équilibrage de charge HTTP(S) avec lequel on peut utiliser une adresse IP unique globale (VIP) pour distribuer l'accès client entre plusieurs régions et zones.
  • L'architecture fournit une configuration en mode actif/actif pour plusieurs zones, ce qui créé un service redondant pour les domaines de défaillance.

Application Web à trois niveaux

Figure 2 : Application Web à trois niveaux dans GCP

Comparer les fonctionnalités

Cette section compare les caractéristiques des fonctionnalités utilisées dans les exemples d'architectures.

Architecture de réseau

Cette section compare le mode de fonctionnement des réseaux OpenStack et GCP dans les régions et les zones. Elle traite des projets et des locataires, des adresses IP et du processus de basculement, ainsi que des règles de pare-feu.

Régions et zones

Les termes et concepts relatifs à OpenStack sont mis en correspondance ci-dessous avec ceux propres à GCP.

OpenStack GCP Notes
Région Région Dans OpenStack, une région peut couvrir plusieurs centres de données. Dans GCP, une région correspond à un site de centre de données comportant généralement plusieurs bâtiments indépendants.
Zone de disponibilité Zone Dans OpenStack, une zone de disponibilité sert généralement à identifier un ensemble de serveurs ayant un attribut commun.

Dans GCP, une zone correspond à un cluster d'un centre de données.

Dans OpenStack, une région est définie comme un cluster unique géré par des nœuds de contrôleurs dédiés. Elle est composée de zones de disponibilité. Vous pouvez utiliser les zones de disponibilité pour définir plusieurs groupes de ressources tels que des nœuds de calcul et des unités de stockage.

Dans GCP, une région correspond à un espace géographique indépendant qui est constitué de zones. Les zones des régions présentent généralement des latences réseau aller-retour inférieures à 5 ms au 95e centile. Comme les zones de disponibilité OpenStack, elles sont utilisées pour le déploiement des ressources GCP au sein d'une région. Chaque zone doit être considérée comme un domaine de défaillance unique.

GCP fournit un réseau interne dédié pour toutes les régions, de sorte que la bande passante et la latence entre les différentes zones d'une même région soient comparables à celles garanties au sein de la région. Vous pouvez déployer une application de cluster à couplage étroit dans plusieurs zones sans vous soucier de la bande passante et de la latence entre les zones.

Sur les deux plates-formes, le déploiement de l'application dans plusieurs zones ou régions offre une meilleure protection contre les défaillances inattendues. Les zones sont considérées comme des domaines de défaillance indépendants dans GCP. En revanche, dans OpenStack, ce sont les régions (et non les zones de disponibilité) qui sont définies comme des domaines de défaillance indépendants, car les zones de disponibilité d'une même région partagent les mêmes nœuds de contrôleurs. Pour obtenir la liste des zones et régions GCP, consultez Emplacements Cloud.

Projets et locataires

Les termes et concepts relatifs à OpenStack sont mis en correspondance ci-dessous avec ceux propres à GCP.

OpenStack GCP Notes
Locataire Projet Toutes les ressources GCP doivent appartenir à un projet. Les utilisateurs peuvent créer leurs propres projets.

Dans OpenStack, seuls les administrateurs peuvent créer des locataires.

Vous devez configurer un compte Google pour utiliser les services GCP. L'utilisation des services est regroupée par projet dans GCP. Vous pouvez créer plusieurs projets totalement distincts au sein d'un même compte. Par ailleurs, vos utilisateurs ont la possibilité de créer leurs propres projets avec leur compte. Les ressources d'un même projet peuvent facilement travailler de concert (par exemple, en communiquant via un réseau interne conformément aux règles applicables aux régions et aux zones). Les ressources d'un projet donné sont isolées de celles des autres projets. Vous ne pouvez les interconnecter que via une connexion réseau externe.

Ce modèle vous permet de créer des espaces de projet pour des départements ou des groupes distincts au sein de votre entreprise. Il peut également s'avérer utile pour réaliser des tests : en effet, lorsque vous avez fini de travailler sur un projet, vous pouvez le supprimer. Toutes les ressources associées à ce dernier sont alors également supprimées.

OpenStack utilise le terme locataire pour désigner une fonctionnalité similaire permettant d'isoler les ressources de différents groupes. Dans OpenStack, seuls les administrateurs système peuvent créer des locataires.

Configurations réseau

Les termes et concepts relatifs à OpenStack sont mis en correspondance ci-dessous avec ceux propres à GCP.

OpenStack GCP Notes
Neutron Cloud Virtual Network Cloud Virtual Network est un service de réseau géré. Dans GCP, vous pouvez définir plusieurs réseaux au sein de votre projet. Chaque réseau est indépendant.
Réseau privé virtuel
Réseau privé virtuel Un seul réseau privé virtuel GCP couvre toutes les régions connectées via le réseau interne de GCP. Un réseau privé virtuel Neutron englobe toutes les zones de disponibilité d'une région.

Dans un déploiement OpenStack Neutron standard, le réseau virtuel de chaque locataire est contenu dans son propre espace réseau privé. Comme le montre la figure 1, vous ne devez pas nécessairement utiliser plusieurs sous-réseaux, mais vous pouvez en configurer plusieurs en cas de besoin. La figure 3 représente un réseau virtuel OpenStack composé d'un seul routeur virtuel et de trois commutateurs virtuels. Deux des commutateurs virtuels se connectent au réseau externe via le routeur virtuel. AZ-1 et AZ-2 correspondent aux zones de disponibilité.

réseau virtuel

Figure 3 : Exemple de configuration d'un réseau OpenStack

GCP propose deux types de réseaux : les anciens réseaux et les sous-réseaux.

Les anciens réseaux fournissent un seul sous-réseau privé qui couvre toutes les régions du monde, comme illustré par la figure 4.

Dans un réseau de sous-réseaux (illustré par la figure 5), le commutateur virtuel correspond à un routeur virtuel OpenStack Neutron. Les commutateurs virtuels sont connectés via le réseau interne. Tous les sous-réseaux peuvent être redirigés les uns vers les autres via des adresses IP privées. Vous n'êtes donc pas obligé d'utiliser des adresses IP globales ou Internet pour permettre la communication entre les régions.

GCP vous permet de combiner les anciens réseaux et les réseaux de sous-réseaux dans un projet. Chaque nouveau projet comprend un réseau prédéfini par défaut, qui inclut lui-même un sous-réseau par défaut dans chaque région.

ancien réseau

Figure 4 : Exemple de configuration d'un ancien réseau Google Cloud Platform

réseau de sous-réseaux

Figure 5 : Exemple de configuration d'un réseau de sous-réseaux Google Cloud Platform

Adresses IP

Les termes et concepts relatifs à OpenStack sont mis en correspondance ci-dessous avec ceux propres à GCP.

OpenStack GCP
Les instances disposent d'adresses IP internes privées. Une adresse IP globale (flottante) peut être attribuée si nécessaire.

Les instances disposent d'adresses IP internes privées. En outre, lorsqu'une instance est créée à l'aide de l'outil de ligne de commande "gcloud", une adresse IP éphémère est automatiquement attribuée. Des adresses IP statiques peuvent également être allouées si nécessaire.
Des adresses IP globales sont requises pour la communication entre des instances situées dans différentes régions ou associées à des routeurs virtuels distincts. Les sous-réseaux de toutes les régions peuvent être redirigés les uns vers les autres via des adresses IP privées. Vous n'êtes donc pas obligé d'utiliser des adresses IP globales ou Internet pour permettre la communication entre les instances.

Dans Neutron, les instances de VM d'un réseau privé communiquent via des commutateurs et des routeurs virtuels à l'aide d'adresses IP privées qui sont attribuées lors du lancement. Les adresses IP globales ne sont pas attribuées par défaut.

Le routeur virtuel gère l'accès des instances de VM au réseau externe, de sorte que ces dernières partagent l'adresse IP globale commune qui leur est attribuée. Pour exposer une instance au réseau externe et autoriser les connexions d'utilisateurs externes, vous devez attribuer une adresse IP flottante à l'instance à partir d'un pool d'adresses IP globales.

Le réseau virtuel étant contenu dans une seule région, les instances de différentes régions doivent utiliser les adresses IP flottantes pour communiquer via le réseau externe.

Un même réseau peut inclure plusieurs routeurs virtuels. Les instances de VM connectées aux différents routeurs ne peuvent pas communiquer directement via des adresses IP privées. Toutefois, elles communiquent via le réseau externe à l'aide d'adresses IP flottantes.

Dans GCP, toutes les instances de VM disposent d'une adresse IP interne et d'une adresse IP externe lors de leur lancement. Vous pouvez dissocier de ces dernières une adresse IP externe si nécessaire.

Par défaut, une adresse IP externe est éphémère, ce qui signifie qu'elle n'existe que pendant la durée de vie de l'instance. Si vous arrêtez, puis redémarrez une instance, une autre adresse IP externe peut lui être attribuée. Vous pouvez également demander une adresse IP permanente, appelée adresse IP statique, afin de l'associer à une instance. Cette adresse vous appartient jusqu'à ce que vous décidiez de la libérer. Vous devez l'attribuer de façon explicite à des instances de VM. Les adresses IP statiques peuvent être associées aux instances et dissociées de ces dernières selon les besoins.

Comme illustré dans les exemples d'architectures d'applications Web à trois niveaux, en cas de basculement, OpenStack ne permet pas d'utiliser la même adresse IP globale dans différentes régions. Vous devez donc faire appel à un autre mécanisme, tel que le DNS dynamique, pour permettre aux clients de continuer à accéder au service au moyen de la même URL.

En revanche, dans GCP, vous pouvez utiliser une seule adresse IP globale (virtuelle) fournie par le service Cloud Load Balancing pour distribuer l'accès client entre plusieurs régions et zones. De cette façon, un basculement s'effectue entre les régions et les zones de manière transparente pour les clients.

Pare-feu

Les termes et concepts relatifs à OpenStack sont mis en correspondance ci-dessous avec ceux propres à GCP.

OpenStack GCP Notes
Applique les règles de pare-feu au moyen de groupes de sécurité. Applique les règles de pare-feu au moyen de règles et de tags. Un groupe de sécurité OpenStack contient plusieurs listes de contrôle d'accès (LCA) que vous définissez en fonction du rôle de l'instance, puis que vous attribuez à cette dernière.

Les groupes de sécurité OpenStack doivent être définis pour chaque région.

Les règles et tags GCP peuvent être définis une seule fois, et utilisés dans toutes les régions.

Dans OpenStack, un même groupe de sécurité contient plusieurs listes de contrôle d'accès (LCA) indépendantes des instances de VM. Vous devez attribuer un groupe de sécurité à une instance de VM pour lui appliquer les LCA. Les groupes de sécurité sont généralement définis en fonction des rôles des instances de VM (serveur Web ou serveur de base de données, par exemple).

Ainsi, pour l'exemple d'architecture, vous devez définir les groupes de sécurité ci-dessous pour chaque région.

Groupe de sécurité Source Protocole
load-balancer toutes HTTP/HTTPS
Sous-réseau de gestion SSH
web-server load-balancer HTTPS
Sous-réseau de gestion SSH
web-application web-server TCP 8080
Sous-réseau de gestion SSH
database web-application MYSQL
Sous-réseau de gestion SSH

Vous pouvez spécifier la source des paquets avec une plage de sous-réseaux ou le nom d'un groupe de sécurité. Dans le tableau précédent, le sous-réseau de gestion désigne une plage de sous-réseaux à partir de laquelle les administrateurs système se connectent au système d'exploitation invité à des fins de maintenance.

Cette architecture part du principe que la terminaison SSL côté client est réalisée sur l'équilibreur de charge, qui communique avec les serveurs Web à l'aide de HTTPS. Ces derniers communiquent avec les serveurs d'applications via le port TCP 8080. Le protocole MySQL est utilisé pour le serveur de base de données.

Après avoir défini ces groupes de sécurité, vous devez les attribuer à chaque instance comme indiqué ci-dessous.

Instance Groupe de sécurité
Équilibreur de charge load-balancer
Serveur Web web-server
Serveur d'application web-application
Serveur de base de données database

Le service Cloud Virtual Network de GCP vous permet de définir des règles de pare-feu qui s'appliquent à toutes les régions en combinant des règles et des tags. Un tag correspond à un libellé arbitraire qui est associé à une instance de VM. Vous pouvez attribuer plusieurs tags à une même instance. Une règle est une LCA qui permet à un paquet de circuler selon les conditions ci-dessous.

  • Source : plage d'adresses IP, sous-réseau, tags
  • Destination : tags

Par exemple, vous pouvez tout d'abord définir une règle qui autorise l'envoi de paquets utilisant le port de destination TCP 80 depuis toute adresse IP vers le tag web-server. Vous avez ensuite la possibilité d'ajouter le tag "web-server" à n'importe quelle instance de VM pour autoriser les connexions HTTP vers celle-ci. Vous devez gérer séparément les tags servant à indiquer les rôles des instances et les règles permettant de spécifier les LCA correspondant aux rôles.

La figure 6 présente certaines règles prédéfinies pour le réseau par défaut dans un nouveau projet. Par exemple, 10.128.0.0/9 est une plage de sous-réseaux qui contient les sous-réseaux sous-jacents de toutes les régions. Cette plage peut varier selon les projets. Du début à la fin du projet, les règles autorisent les connexions réseau suivantes :

  • Paquets ICMP (Internet Control Message Protocol) provenant de n'importe quelle source externe
  • Paquets échangés entre toutes les instances qui sont connectées au réseau par défaut
  • Connexion RDP (Remote Desktop Protocol) à partir de n'importe quelle source externe
  • Connexion SSH (Secure Shell) à partir de n'importe quelle source externe

Règles de pare-feu prédéfinies

Figure 6 : Règles de pare-feu prédéfinies dans Cloud Virtual Network pour le réseau par défaut

Pour en savoir plus, consultez Utiliser des réseaux et des pare-feu.

Dans les règles de pare-feu GCP, vous devez utiliser d'une part des tags pour spécifier la destination des paquets et d'autre part des plages de sous-réseaux ou des tags pour indiquer la source des paquets. Dans ce scénario, vous définissez les règles suivantes :

Source Destination Protocole
130.211.0.0/22 web-server HTTP, HTTPS
web-server web-application TCP 8080
Sous-réseau de gestion web-server, web-application SSH

Dans le tableau précédent, 130.211.0.0/22 correspond à la plage de sous-réseaux à partir de laquelle l'équilibreur de charge et le système de vérification de l'état accèdent au serveur Web. Le sous-réseau de gestion désigne une plage de sous-réseaux à partir de laquelle les administrateurs système se connectent au système d'exploitation invité à des fins de maintenance. web-server et web-application sont les tags attribués respectivement au serveur Web et au serveur d'application. Au lieu d'attribuer des règles comme si vous utilisiez des groupes de sécurité, vous allouez des tags aux instances en fonction de leur rôle.

Le contrôle des accès pour la connexion à la base de données est défini en fonction de l'adresse IP source dans le cadre de la configuration de Cloud SQL.

Espace de stockage

Les termes et concepts relatifs à OpenStack sont mis en correspondance ci-dessous avec ceux propres à GCP.

OpenStack GCP Notes
Volumes Cinder Disques persistants Espace de stockage persistant qui est associé à une instance

Avec les disques persistants GCP, les données sont automatiquement chiffrées avant leur transfert de l'instance vers l'espace de stockage persistant.

Espaces disques éphémères ND Espace de stockage éphémère qui est associé à une instance
OpenStack Swift Cloud Storage Services de stockage d'objets
Espaces disques éphémères et volumes Cinder

OpenStack propose deux options pour les disques associés à une instance : les espaces disques éphémères et les volumes Cinder.

Les espaces disques éphémères sont conçus pour être utilisés en tant que disques système contenant les fichiers du système d'exploitation, alors que les volumes Cinder sont destinés à stocker des données d'application persistantes. Les espaces disques éphémères ne permettant pas la migration à chaud, il est fréquent que les utilisateurs emploient les volumes Cinder également en tant que disques système.

Lorsqu'un espace disque éphémère est utilisé en tant que disque système, une image du modèle de système d'exploitation est copiée dans l'espace de stockage local d'un nœud de calcul, et l'image locale est associée à l'instance. Lorsque l'instance est détruite, l'image associée l'est également.

Les volumes Cinder fournissent un espace disque persistant qui réside dans des périphériques de stockage externes. Dans les déploiements standards, le périphérique en mode bloc est associé au nœud de calcul à l'aide du protocole iSCSI. Il est par ailleurs associé à l'instance en tant que disque virtuel. Lorsque l'instance est détruite, le volume associé reste dans le périphérique externe et peut être réutilisé à partir d'une autre instance.

Le logiciel d'application exécuté sur l'instance peut également accéder à l'espace de stockage d'objets fourni par OpenStack Swift.

espace disque éphémère et volume Cinder

Figure 7 : Comparaison entre les espaces disques éphémères et les volumes Cinder utilisés dans OpenStack

Disques persistants

GCP fournit un espace de stockage persistant qui est associé à une instance sous la forme de disques persistants. Ces derniers sont similaires aux volumes Cinder d'OpenStack. Vous pouvez utiliser un disque persistant en tant que disque système contenant les fichiers du système d'exploitation ainsi que pour stocker des données d'application persistantes. Les données sont automatiquement chiffrées avant leur transfert de l'instance vers le disque persistant. Vous pouvez augmenter la capacité d'un même disque persistant jusqu'à 64 To. Toutefois, la capacité totale maximale des disques associés est limitée par la taille de l'instance. Pour en savoir plus, consultez Options de stockage.

Si vous avez besoin d'une solution de stockage locale hautes performances, vous pouvez également utiliser des disques persistants SSD locaux. La taille de chacun de ces disques est de 375 Go. Il est toutefois possible d'associer jusqu'à huit disques SSD locaux par instance pour obtenir au total un espace de stockage SSD local de 3 To. Notez que la migration à chaud est disponible pour les instances associées à des disques SSD locaux. Étant donné que les données de ces disques sont copiées d'une instance à une autre lors de la migration à chaud, les performances de stockage peuvent diminuer temporairement.

Le logiciel d'application exécuté sur l'instance peut accéder à l'espace de stockage d'objets fourni par Cloud Storage, un service hébergé permettant de stocker un grand nombre d'objets binaires (ou blobs) de taille variable et d'y accéder.

Instances de VM

Les termes et concepts relatifs à OpenStack sont mis en correspondance ci-dessous avec ceux propres à GCP.

OpenStack GCP Notes
Type d'instance Type de machine Dans OpenStack, les utilisateurs standards ne peuvent pas créer de type d'instance personnalisé.

Dans GCP, tout utilisateur peut créer des types de machines personnalisés.
Service de métadonnées Serveur de métadonnées OpenStack ne fournit des informations que sur les instances.

GCP fournit également des informations sur les projets.

Lorsque vous lancez une nouvelle instance de VM dans OpenStack, vous choisissez un type d'instance pour spécifier la taille de l'instance, telle que le nombre de processeurs virtuels et la quantité de mémoire. Si l'administrateur système vous a attribué des droits d'accès appropriés, vous pouvez définir d'autres types d'instances. Les utilisateurs standards ne sont pas autorisés à ajouter des types d'instances personnalisés.

Dans GCP, les tailles des instances sont définies sous la forme de types de machines. Les utilisateurs peuvent non seulement choisir l'un des types de machines prédéfinis, mais également spécifier séparément le nombre de processeurs virtuels et la quantité de mémoire pour créer un type de machine personnalisé. Pour en savoir plus, consultez Types de machines.

Métadonnées

OpenStack fournit un service de métadonnées permettant de récupérer les informations relatives aux instances de VM (telles que le type d'instance, les groupes de sécurité et les adresses IP attribuées) à partir du système d'exploitation invité des instances. Vous pouvez également ajouter des métadonnées personnalisées sous forme de paires valeur/clé. OpenStack fournit un type de métadonnées nommé user-data. Vous pouvez spécifier un fichier texte exécutable en tant que script user-data lors du lancement d'une nouvelle instance pour que l'agent cloud-init s'exécutant dans le système d'exploitation invité effectue les tâches de configuration de démarrage (telles que l'installation des packages d'application) en fonction de son contenu. Utilisez l'URL http://169.254.169.254/latest/meta-data pour accéder aux métadonnées à partir du système d'exploitation invité.

GCP fournit un serveur de métadonnées permettant de récupérer les informations relatives aux instances et aux projets à partir du système d'exploitation invité des instances. Les métadonnées d'un projet sont partagées par toutes les instances associées à ce dernier. Vous pouvez ajouter des métadonnées personnalisées pour une instance et pour un projet sous forme de paires valeur/clé. GCP fournit des métadonnées spéciales nommées startup-script et shutdown-script, qui sont exécutées respectivement lorsque vous démarrez et arrêtez l'instance.

Contrairement au script user-data d'OpenStack, le script startup-script est exécuté à chaque redémarrage de l'instance. Les scripts startup-script et shutdown-script sont tous les deux gérés par un agent inclus dans les compute-image-packages, qui est préinstallé dans les images du modèle du système d'exploitation. Pour en savoir plus, consultez Stocker et récupérer les métadonnées d'instances.

Vous devez utiliser l'une des URL suivantes pour accéder aux métadonnées à partir du système d'exploitation invité :

  • http://metadata.google.internal/computeMetadata/v1/
  • http://metadata/computeMetadata/v1/
  • http://169.254.169.254/computeMetadata/v1/
Agent du système d'exploitation invité
OpenStack GCP Notes
Package de l'agent chargé des tâches de configuration cloud-init Package de l'agent chargé des tâches de configuration compute-image-packages L'agent OpenStack ne gère que les paramètres de démarrage initiaux.

L'agent GCP gère les paramètres de démarrage initiaux et les modifications de configuration dynamiques pendant l'exécution de l'instance.

Dans OpenStack, le package d'agent cloud-init est préinstallé dans les images standards du système d'exploitation invité. Il gère les tâches de configuration initiales lors du premier démarrage (extension de l'espace du système de fichiers racine, stockage d'une clé publique SSH et exécution du script "user-data" fourni en tant que données utilisateur, par exemple).

Dans GCP, le package d'agent compute-image-packages est préinstallé dans les images standards du système d'exploitation invité. Il gère les tâches de configuration initiales via startup-script lors du premier démarrage, ainsi que la configuration système dynamique pendant l'exécution du système d'exploitation invité (en ajoutant des clés publiques SSH et en modifiant les configurations réseau pour l'équilibrage de charge HTTP, par exemple). Vous pouvez générer ou ajouter une nouvelle clé SSH via la console Google Cloud Platform ou l'outil de ligne de commande gcloud après avoir lancé l'instance.

Dans GCP, le SDK Google Cloud est préinstallé dans les images standards du système d'exploitation invité. Vous pouvez l'employer pour accéder aux services GCP à partir du système d'exploitation invité en utilisant un compte de service disposant par défaut de certains privilèges.

Contrôle des accès

Dans GCP, Google Cloud IAM applique un contrôle des accès par instance. Par exemple, si vous souhaitez que votre application exécutée sur une instance stocke des données dans Google Cloud Storage, vous pouvez attribuer une autorisation en lecture/écriture à l'instance. Avec Cloud IAM, vous n'avez pas besoin de préparer manuellement des mots de passe ou des codes d'identification pour les applications s'exécutant sur l'instance. Pour en savoir plus, consultez la page Créer et activer des comptes de service pour les instances.

Le service Keystone d'OpenStack offre un contrôle des accès basé sur les comptes utilisateur pour les API de service. En revanche, il ne fournit pas de contrôle des accès basé sur les instances (tel que les autorisations en lecture/écriture qui s'appliquent au stockage des objets ou aux bases de données) pour les API d'application. Vous pouvez mettre en œuvre un contrôle des accès personnalisé pour les API d'application si nécessaire.

Au-delà des solutions IaaS : les offres Platform as a Service

Cet article compare les composants et services OpenStack et Google Cloud Platform qui sont essentiels pour les déploiements IaaS. Toutefois, pour tirer le meilleur parti de GCP en termes de disponibilité, d'évolutivité et d'efficacité opérationnelle, vous devez combiner les services gérés pour qu'ils constituent la base de l'ensemble du système.

La gamme complète de services GCP s'étend bien au-delà du concept traditionnel de plate-forme IaaS et comprend, entre autres, les éléments suivants :

Étapes suivantes

  • Découvrez comment intégrer Google Cloud Dataproc aux services de stockage, de calcul et de surveillance de GCP pour créer une plate-forme de traitement des données complète.
  • Obtenez plus d'informations sur les fonctionnalités de surveillance, de journalisation et de diagnostic offertes par Google Stackdriver.
  • Familiarisez-vous avec Google BigQuery, un entrepôt de données entièrement géré qui est destiné aux analyses de données. Il fournit une plate-forme sans serveur vous permettant de vous concentrer sur les tâches d'analyse SQL, même avec des ensembles de données à l'échelle du pétaoctet.
  • Découvrez les produits et services Google Cloud Platform.
Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Google Cloud Platform pour les utilisateurs d'OpenStack