Google Cloud pour les utilisateurs professionnels d'AWS : outils de déploiement d'infrastructure

Document mis à jour le 6 décembre 2017

Sur Google Cloud comme sur Amazon Web Services (AWS), vous pouvez gérer vos environnements cloud en utilisant une approche de type "infrastructure en tant que code". Google Cloud propose Cloud Deployment Manager, et AWS offre CloudFormation.

Traiter votre infrastructure en tant que code implique de définir votre environnement à l'aide de scripts, de modèles et de fichiers de configuration, ainsi que de conserver les fichiers dans un référentiel de code source. En utilisant cette approche, vous pouvez :

  • contrôler la version de votre configuration ;
  • déployer des configurations cohérentes et reproductibles ;
  • passer en revue les modifications apportées à votre configuration et effectuer des audits ;
  • utiliser la configuration dans le cadre d'un système de déploiement continu ;
  • revenir facilement à une bonne configuration antérieure connue.

Comparaison des modèles de service

Le tableau suivant présente la correspondance entre les fonctionnalités, les termes et les concepts de haut niveau spécifiques à CloudFormation et leurs équivalents dans Deployment Manager :

Fonctionnalité AWS CloudFormation Cloud Deployment Manager
Collection de ressources déployée Pile Déploiement
Fichiers de déploiement Fichier de modèle Fichiers de configuration, fichiers de modèles et fichiers de schémas
Syntaxe JSON, YAML YAML, Jinja et Python
Composition et réutilisation Piles imbriquées Modèles
Identification de chaque ressource ID logique Nom
Portée de la zone de déploiement Régional Monde
Nombre maximal de piles ou de déploiements par défaut 200 1 000
Interface utilisateur graphique Oui Non
Aperçu Oui Oui
Stratégies de pile Oui Non

Modèles et configuration

Le tableau suivant compare les fonctionnalités (relatives aux modèles et aux configurations) disponibles dans CloudFormation à celles de Deployment Manager :

Fonctionnalité AWS CloudFormation Cloud Deployment Manager
Taille maximale du modèle ou de la configuration 460,8 Ko 1 Mo
Langage déclaratif Oui Oui
Expressions conditionnelles Oui Oui
Boucles Non Oui
Paramétrage Oui Oui
Valeurs de sortie Oui Oui

AWS CloudFormation

Dans AWS CloudFormation, vous devez créer un modèle qui définit un ensemble d'actions à appliquer sur différents services, telles que la création d'un ensemble S3 ou le lancement d'une instance EC2. Un modèle AWS peut être exprimé en YAML ou JSON. AWS CloudFormation peut appeler un modèle à partir d'un ensemble S3 ou de votre machine locale. Lorsque AWS CloudFormation appelle un modèle, il appelle les API des services que vous avez définis dans le modèle pour lancer et configurer les services.

Pour utiliser les services définis dans un modèle, vous devez disposer des autorisations AWS IAM appropriées pour chaque service. Vous pouvez également définir des stratégies IAM pour restreindre ou autoriser l'utilisation de CloudFormation.

Deployment Manager

Deployment Manager utilise trois types de fichiers pour définir un déploiement :

  • Un fichier de configuration, qui définit la structure de votre déploiement et configure les ressources à déployer. Ce fichier est écrit au format YAML. Vous pouvez l'utiliser comme fichier de configuration autonome pour votre déploiement, ou le combiner à des fichiers de modèle importés pour plus de flexibilité.
  • Des fichiers de modèle, qui sont des définitions de ressources composables et réutilisables. Les fichiers de modèle sont écrits en Jinja 2.10.x ou Python 3.x. Vous pouvez ajouter des boucles pour créer plusieurs instances de la même ressource sans avoir à déclarer explicitement chaque instance.
  • Des fichiers de schéma, qui définissent des ensembles de règles qu'un fichier de configuration doit respecter pour utiliser un modèle particulier.

Vous transmettez le fichier de configuration (qui développera les modèles auxquels il fait référence) au service Deployment Manager via l'API ou l'outil de ligne de commande gcloud. Vous pouvez également lancer des configurations prédéfinies à l'aide de Cloud Marketplace.

Par défaut, Deployment Manager s'authentifie auprès d'autres API à l'aide des identifiants du compte de service des API Cloud. Vous devez accorder à l'utilisateur les autorisations appropriées pour utiliser Cloud Deployment Manager. Vous pouvez utiliser des rôles IAM prédéfinis pour limiter les autorisations de manière appropriée. Deployment Manager vous permet d'automatiser la création des projets eux-mêmes, ainsi que des ressources contenues dans ces projets.

Un fichier de configuration Cloud Deployment Manager comprend les sections suivantes :

imports:
  - path: network.jinja
resources:
- name: network
  type: network.jinja
  properties:
    region: us-central1
    subnets:
      - range: 10.177.0.0/17
        name: web
      - range: 10.177.128.0/17
        name: data
- name: web-instance
  type: compute.v1.instance
  properties:
    zone: us-central1-f
    machineType: https://www.googleapis.com/compute/v1/projects/myproject/zones/us-central1-f/machineTypes/f1-micro
    disks:
    - deviceName: boot
      type: PERSISTENT
      boot: true
      autoDelete: true
      initializeParams:
        sourceImage: https://www.googleapis.com/compute/v1/projects/debian-cloud/global/images/family/debian-9
    networkInterfaces:
    - network: https://www.googleapis.com/compute/v1/projects/myproject/global/networks/default
      accessConfigs:
      - name: External NAT
        type: ONE_TO_ONE_NAT

L'exemple de configuration de Google Cloud ci-dessus comprend les éléments suivants :

Imports : cette section indique le chemin d'accès aux modèles composables développés dans le cadre du déploiement réel. Cette partie est facultative, notamment dans le cas d'un déploiement simple pour lequel vous n'avez pas besoin de créer une configuration car vous avez placé les ressources individuelles dans des fichiers de modèle composite.

Ressources : cette section présente la liste des ressources que vous souhaitez déployer dans le cadre de votre configuration. Il s'agit de la seule "exigence obligatoire" pour une configuration. Chaque ressource est définie par les parties constitutives suivantes :

  • Name : le nom que vous définissez pour la ressource. Dans l'exemple ci-dessus, nous avons deux ressources appelées network et web-instance.
  • Type : cette valeur spécifie le type de base de la ressource. L'exemple présente deux types de ressources. La ressource web-instance est de type compute.v1.instance. La deuxième ressource fait référence au fichier d'importation déclaré dans la section imports du fichier de configuration. Dans l'exemple, il s'agit d'un fichier Jinja, mais vous pouvez également importer des fichiers Python.
  • Properties : il s'agit des propriétés associées à une ressource. La ressource appelée web-instance définit une instance Compute Engine de type machine f1-micro,, équipée d'un disque persistant qui peut être supprimé automatiquement lorsque vous supprimez l'instance. L'instance doit être déployée dans la région us-central1-f. La deuxième ressource est définie dans un fichier de modèle distinct appelé network.jinja. Pour cette ressource, vous devez définir les valeurs utilisées pour les propriétés dans le fichier de configuration. Les valeurs sont transmises au fichier de modèle réel. Cette possibilité de composition permet la création de déploiements complexes avec des définitions de ressources réutilisables, auxquelles vous pouvez transmettre des valeurs par le biais des fichiers de configuration. Par exemple, vous pouvez utiliser le même fichier de modèle pour créer plusieurs sous-réseaux avec des plages d'adresses IP et des noms différents.

Un fichier de configuration peut également avoir des sorties et des métadonnées.

Un fichier de schéma définit un ensemble de règles pour l'utilisation d'un modèle. La définition des règles dans un schéma unique permet à vos utilisateurs d'interagir avec les modèles que vous écrivez. Ils peuvent utiliser ce fichier de schéma directement. Ils n'ont pas besoin d'examiner les modèles qui constituent une configuration, d'apprendre quelles propriétés doivent être définies ou de savoir quelles propriétés ont des valeurs par défaut. Pour plus d'informations sur les fichiers de schéma, consultez la documentation de Deployment Manager.

Le modèle d'exemple utilise une image publique pour créer l'instance. GCP adopte une approche globale. Ainsi, lorsque vous sélectionnez un type d'image pour lancer une instance, vous n'avez pas besoin de créer une carte du type d'image par région. Avec AWS CloudFormation, cette opération est requise. Avec Google Cloud, vous déclarez le type de machine et l'image source. L'image source est disponible pour tous les projets.

Composition et réutilisation

AWS CloudFormation et Cloud Deployment Manager vous encouragent à composer vos propres piles ou déploiements et à les réutiliser.

AWS CloudFormation

AWS CloudFormation repose sur le concept de piles imbriquées. Avec les piles imbriquées, vous pouvez créer un modèle pour les ressources que vous souhaitez réutiliser. Vous stockez le modèle que vous souhaitez appeler à partir du modèle maître dans un bucket S3 et utilisez le type AWS::CloudFormation::Stack. Ensuite, vous transmettez l'URL S3 du modèle en tant que propriété.

Vous pouvez employer des paramètres afin de personnaliser facilement un modèle chaque fois que vous l'utilisez pour créer une pile. Vous pouvez utiliser des fonctions intrinsèques associées à des paramètres pour créer des ressources conditionnelles.

Vous pouvez utiliser des sorties pour exporter une valeur via l'ID logique qui lui est affecté, ce qui vous permet de réutiliser cette valeur ailleurs. Par exemple, vous pouvez exporter les noms des équilibreurs de charge et des ensembles S3, importer ces valeurs dans d'autres piles ou encore les exposer dans la console.

CloudFormation crée des ressources en parallèle et détermine celles qui peuvent être déployées. Vous devrez peut-être utiliser la règle de création et les attributs DependsOn pour imposer l'ordre de création des ressources. Par exemple, le déploiement peut nécessiter la création de volumes EBS avant celle de l'instance utilisant les volumes.

Vous pouvez utiliser des ressources personnalisées pour inclure des ressources non-AWS dans votre pile CloudFormation. Pour implémenter une ressource personnalisée, vous devez fournir un jeton de service dans la section Properties du modèle. Le jeton de service spécifie la destination des requêtes que CloudFormation doit envoyer.

Cloud Deployment Manager

Deployment Manager vous permet d'importer des modèles dans votre fichier de configuration. Vous devez déclarer dans l'instruction import le chemin d'accès aux modèles, qui peuvent être stockés localement ou dans un bucket Cloud Storage, ou accessibles via une URL publique comme GitHub. Cela vous permet de mettre à l'échelle et réutiliser des modèles dans le cadre de votre configuration.

Vous pouvez personnaliser les modèles Deployment Manager en transmettant des variables à vos modèles. Vous pouvez utiliser deux types de variables avec Deployment Manager : les variables de modèle et les variables d'environnement. À l'aide des variables de modèle, vous pouvez définir une valeur personnalisable dans le fichier de configuration et la transmettre aux fichiers de modèle. Les variables d'environnement sont prédéfinies et affectées automatiquement. Elles sont conçues pour être utilisées avec des éléments qui ne sont pas directement liés aux ressources que vous souhaitez déployer, tels que les ID des projets et les noms des déploiements.

Jinja et Python vous permettent tous deux de bénéficier des avantages des expressions conditionnelles natives et des fonctions de bouclage.

Deployment Manager s'appuie sur le concept de module de modèle. Vous pouvez utiliser des modules de modèle pour incorporer des extraits de modèle utilisables dans plusieurs modèles. Par exemple, vous pouvez utiliser un module de modèle pour toujours générer les noms des instances en fonction de leur environnement et de leur fonction.

Deployment Manager crée toutes les ressources en parallèle. Vous pouvez utiliser des références pour appliquer l'ordre dans lequel les ressources doivent être créées. Par exemple, si une instance fait référence à un nouveau réseau dans une configuration, vous pouvez vous assurer que Deployment Manager crée toujours le réseau avant de créer l'instance, quel que soit l'endroit où le réseau est déclaré dans le fichier de configuration.

Les sorties dans Deployment Manager sont conçues pour exposer les propriétés clés des ressources d'une manière facilement "consommable". Elles peuvent ainsi être utilisées par d'autres modèles ou exposées dans la configuration. Les sorties sont déclarées en tant que paires clé/valeur. Elles peuvent être constituées d'une chaîne statique, d'une référence à une propriété, d'une variable de modèle ou d'une variable d'environnement.

Si les types compatibles avec Google Cloud ne répondent pas à vos besoins, vous pouvez créer un fournisseur de types et générer des types supplémentaires que vous pouvez enregistrer avec Cloud Deployment Manager. Pour créer un fournisseur de types, vous devez fournir un document descripteur d'API. Il peut s'agir d'une spécification OpenAPI ou d'un document Google Discovery. Lorsque vous créez et enregistrez un fournisseur de types, toutes les ressources fournies par l'API et compatibles avec une interface RESTful gérant les opérations CRUD (créer, lire, mettre à jour et supprimer) sont exposées en tant que types que vous pouvez utiliser dans votre déploiement.

Vous pouvez étendre les types de base pour créer un type composite. Un type composite est une combinaison de plusieurs types de base configurés pour fonctionner ensemble. Par exemple, un groupe d'instances géré avec équilibrage de la charge réseau est un type composite. Un équilibreur de charge réseau nécessite plusieurs ressources Google Cloud et une certaine configuration entre les ressources. Vous pouvez paramétrer ces ressources dans une configuration, puis enregistrer le type avec Deployment Manager pour pouvoir le réutiliser.

Métadonnées, scripts d'aide et scripts de démarrage

AWS CloudFormation vous permet d'utiliser un ensemble de scripts Python qui vous aident à démarrer des services et à installer des logiciels sur des instances EC2. Les scripts sont intégrés à un référentiel ou installés sur une AMI Linux Amazon. Vous pouvez les appeler à partir de vos modèles. Vous pouvez ajouter ou récupérer des métadonnées sur vos instances à l'aide de l'attribut metadata.

Cloud Deployment Manager vous permet d'utiliser des scripts de démarrage ou d'ajouter des métadonnées aux instances de machine virtuelle de votre déploiement en spécifiant ces métadonnées dans votre modèle ou votre configuration. La clé de métadonnées de votre script de démarrage doit être startup-script et la valeur correspond au contenu de votre script de démarrage.

L'extrait de code présenté ci-dessous vous montre comment procéder :

resources:
- name: my-first-vm-template
  type: compute.v1.instance
  properties:
   zone: us-central1-f
   machineType:
   ...[snip]...
   metadata:
     items:
     - key: startup-script
       value: "STARTUP-SCRIPT-CONTENTS"

Mise à jour des piles et des déploiements

AWS CloudFormation

Vous pouvez mettre à jour les piles CloudFormation en transmettant de nouvelles valeurs de paramètres ou des modèles mis à jour. Avant d'appliquer un ensemble de modifications, vous pouvez utiliser une fonction de prévisualisation pour savoir quelles ressources et quels paramètres de pile seront modifiés.

Cloud Deployment Manager

Avec Deployment Manager, vous pouvez également mettre à jour les déploiements et prévisualiser les modifications potentielles afin d'évaluer l'effet de vos modifications. Deployment Manager n'instancie aucune ressource réelle lorsque vous prévisualisez une configuration. Au lieu de cela, il développe la configuration complète et crée des ressources de type "shell". Cela vous donne l'opportunité de visualiser le déploiement avant de le valider.

Deployment Manager propose également des stratégies que vous pouvez utiliser lorsque vous mettez à jour un déploiement. Ces stratégies vous aident à contrôler la manière dont Deployment Manager gère les mises à jour. Certaines ressources sont immuables et peuvent ne pas avoir de méthode de mise à jour. Comme avec AWS CloudFormation, vous devez vérifier les méthodes d'API appliquées aux ressources afin de comprendre les implications de l'exécution d'une mise à jour.

Vous pouvez également consulter les fichiers manifestes avant d'effectuer des mises à jour pour comprendre concrètement à quoi ressemble un déploiement. Pour ce faire, vous pouvez utiliser l'interface de ligne de commande ou la console.

Coûts

Aucuns frais ne sont facturés pour AWS CloudFormation ou Cloud Deployment Manager. Dans les deux cas, seules les ressources que vous lancez sont facturées.

Étape suivante

Consultez les autres articles Google Cloud pour les utilisateurs professionnels d'AWS :